How do you manage computers without Active Directory?
Solution 1:
Microsoft offer a special licensing program for charities, the discounts are quite big and for just running an AD you can use two old PC's with a couple of gigs of ram.
See for details
Solution 2:
I would weigh the initial cost of setting up 10 computers one time with minimal administrative work vs. the management of a domain. For example, two domain controllers would be advisable for redundancy/reliability's sake and their configuration can take a fair bit of time. This contributes to a greater financial cost and might contribute to a greater cost in man-hours. It also adds to the complexity of your network, which will more than likely make more work for you down the line without much tangible benefit.
On the other hand, working with 10 machines local policies is comparatively cut and dry. I doubt you will be micromanaging security policies in your day to day activities. Updates can be troublesome, but properly applied once you've tested them. AV/malware/intrustion utilities can also be annoying with some minimal administration.
Solution 3:
You might want to try TechSoup. If your organization qualifies you could probably get a copy of Window Server 2008 R2 for less than $100 dollars. I believe you'll get about 50 seat licenses with it as well. And as previously pointed out, you don't need heroic hardware to run Active Directory in your situation. You can even run other server roles without significant trouble.
If you are actually in a situation that requires Active Directory, you will find that every substitute falls far short.
Solution 4:
I'm an IT manager for a small business. I don't have much of a budget so I do the best I can with what I have. As an open-source advocate, if I can reliably and robustly solve a problem with free and open source software, I do it. I've found something that works well enough without Active Directory. Here is how I do it:
FOG Project
FOG is an open source solution for disk imaging. (ex: Create a disk image of a virtual machine, sysprep and deploy that one image to ten computers.) FOG can also remotely install snap-ins. A snap-in can be any executable file. If I want to change something group policy related on one or more machines, I would create a registry file with the group policy registry values that need updated. I create batch scripts to call regedit /s on the .reg files and update the registry.
7-zip & 7-zip SFX maker
SFX maker creates me nice .exe files that can be configured to silently extract the contents and run an arbitrary program. In the example above I use SFX maker to pack the .cmd and .reg files into an .exe which can then be uploaded to fog and deployed as a snapin.
Misc. enterprise IT deployment tools
For installing new programs on all workstations, I first look for enterprise IT deployment tools for the software in question. For example, Google Chrome provides Chrome for Business which has a pre-configurable, easily deployable and optionally silent installer. Many printer manufacturers also have tools to help you deploy their printer drivers. HP and Brother have nice tools for this. You just have to find the right printer driver for your OS, then use their tools to create a silent installer which can be used as a FOG snapin.
AutoIT
Lots of software developers don't make deployment tools, even some big name titles like Quickbooks. Active Directory can't help you here. In cases where every computer needs it, it's sometimes easier to bake the software into your disk image, then deploy the disk image with all commonly used applications. For everything else, there's AutoIT. While it can be extremely time consuming to do so, you can write AutoIT scripts to automate software installations, either by detecting windows and simulating mouse and keystrokes or by duplicating the file and registry changes installers would normally do.
TightVNC
Every computer I manage has a TightVNC server. Basically remote desktop. When the workstation isn't in use, I can connect to a workstation and manually change settings as if I were sitting in front of the machine.
Feet
For small changes that don't need changing on every machine, feet come in very handy to transport me to the computer in question and fiddle with it. Bonus here is that I can get some exercise to make up for my otherwise sedentary lifestyle :P. While this isn't a good solution for managing a large amount of computers, it is good for making small changes to a small number of computers. (for everything else, there's AutoIT, remember?)
Conclusion
FOG is really the backbone of this whole process. FOG lets me assign machines to groups, which can be assigned specific disk images and snapins that are suited to those groups. Groups can be "room1", "room2" etc. with specific printer snapins deployed where needed. This process probably doesn't scale very well, isn't without it's flaws, but in my case where I manage around 20 computers, it works pretty well.
Solution 5:
Ansible Windows Modules.
I manage a stillup with a CEO who for whatever reason is against the idea of a Windows domain.
My workaround is to use Ansible playbooks to remotely make stuff happen on workstations. I can Install MSIs, install Chocolatey packages, configure RDP/VNC, ensure Windows updates are installed, create startup or login scripts to map network drives, schedule robocopy backups, etc.
Ansible doesn't use an agent, meaning there is no Ansible service which runs on the end user's PC. Ansible simply leverages WinRM to remotely log in and send instructions to the computer.
I maintain a git repository containing all my Ansible playbooks, deployable scripts, and some provisioning scripts which automate the setup process for ading a Windows machine to Ansible management. I'm the only IT person here who touches desktops, but in theory the git repo contains everything another IT person would need to do what I do.
Also in the git repository is an Ansible inventory file which is a .INI style text document containing IP addresses or domain names for each machine managed by Ansible. (Our pfSense office router handles the DNS resolution)
When a new computer is added in the office, I run the Ansible provisioning script on it. The provision script satisfied .NET and Windows Management Framework (PowerShell) dependencies, configures the computer for Ansible remoting, and installs Chocolatey. After that, I don't need to touch the computer again, because I can do everything else remotely. I have an internal Nuget feed which serves packaged EXEs specific to our industry.
Using this method, I can create Ansible playbooks which mimic some of the functionality of Windows Group Policy. For example, I can create an Ansible playbook called generalpolicy.yml, which targets a specific group of machines in the Ansible inventory file. When run, generalpolicy.yml would remote into each machine in the group, and ensure a specific set of conditions are met on said machines.
Those conditions could be anything, such as Notepad++ is installed, Terminal Server is enabled in the registry, and ICMP PING is not blocked in the firewall. The playbook can be run over and over again, and thanks to Ansible's idempotency, nothing will change on the target computer unless the condition is not satisfied.