Hyper-V and Workgroups Part 2

Save to My DOJO

Countering Reasons to Use a Workgroup
What’s Next

In the first post on Hyper-V and Workgroups, we went over the how-tos of running Hyper-V in a workgroup environment. This part will serve as the first of two opinion pieces on why I believe that workgroups are an inferior solution. Some of the discussion will be general commentary but I will also touch on the specifics as they pertain to Hyper-V. In this installation, I’ll address common reasons that people choose to use workgroups.

We absolutely invite alternate and conflicting viewpoints. You are reminded that the comments section is moderated and we have a zero tolerance policy for abusive language and posts that add no value to the conversation (as in, if you just say that you disagree and don’t bother explaining why, your post won’t be displayed).

Quite simply, it is my belief that as a general rule, any time there is an environment that contains a Windows Server and one or more Windows clients, an Active Directory domain is worthwhile.

Countering Reasons to Use a Workgroup

“Workgroups are Easier”

For initial set up, workgroups are easier because there’s really not much to set up. For everything after, they seem to me to be substantially harder. As an example, the previous post details all the steps needed just to connect to a Hyper-V Server to manage that single role. Connecting to a Hyper-V Server that is a member of the same or a trusting domain is mostly a matter of ensuring the firewall is open and that you’re connecting as a member of a group with sufficient privileges. Many difficulties arise in security, which is the focus of the next section.

“Having Hyper-V Servers in Workgroups Apart from the Domain Increases Security”

There is absolutely no sense in which a Windows computer in workgroup configuration is more secure than the same system in a domain environment. All else being equal, the local security accounts manager database is far easier to compromise than the Active Directory database. It is entirely possible to secure an active directory domain member without exposing the domain to unnecessary risks. If it is truly desirable to split Hyper-V hosts away from your primary domain, it is preferable to create a subdomain or a second forest and use trusts. It’s more work and probably not going to substantially increase security, but overall it’s still simpler than dealing with the boundaries creating by workgroup separation.

With the workgroup model, it’s necessary to keep a good user account structure on each system. Those accounts are not identical, so they need to be tracked. That usually winds up with password spreadsheets and papers which wind up getting printed, copied, and distributed, stuck to monitors, and left out in plain view. These are the sorts of things that security breaches are made of.

“A Domain Controller is Another Server License a Small Business Can’t Afford”

This belief is a result of a collision between a best practice and reality. When possible, you should not combine a domain controller with any other function. However, it’s not always possible from a financial standpoint. As long as careful precautions are taken, domain controllers can provide other roles. In an environment small enough for this to be acceptable, domain controller functions require almost no resources to operate. One thing that a domain controller cannot serve as is the Hyper-V host. This was never a good plan under previous editions but it is no longer supported in 2012 and there are documented cases of problems being sourced to mixing the roles. However, I have seen domain controllers perform double (or more) duty as file servers, print servers, Exchange servers, and SQL servers. The Small Business Server (now Essentials) line of products has been mixing roles for many years. To reiterate, there are definitely steps that must be taken to properly mix roles and it is always recommended to make a domain controller run no other role if possible. However, running in a workgroup just because of the expense of another Server license is not a good excuse.

“It’s Harder to Get Support and Help for a Domain”

This should never be true. Any third-party solutions provider that can’t properly support a domain environment should be promptly replaced or augmented with one that can. There are Technet forums and any number of non-Microsoft computer support sites filled with experts that are just dying to help out.

“Some Software Doesn’t Support a Domain Environment”

Unfortunately, this is true. However, none of that software should be running on a Hyper-V host so the point should be moot. Hopefully none of that software still exists that must be installed on every computer in an organization. If so, the using organization should be leaning on the manufacturer to move into this century and/or be scouring for competition that’s more with the times. Usually, applications with that requirement also require archaic operating systems that represent a very serious security threat for any organization.

“It’s Easier to Train the End Users to Use a Workgroup”

I’ve heard this from some solutions providers that work primarily with very small businesses. This argument simply does not make sense. What the provider usually does is go around to each workstation and put the same user accounts and passwords on each one. The users believe that these are the same. So then their computer-savvy grandchild comes in and explains why they need to rotate their passwords, and they do it. Then they don’t understand why they can only log on to one computer. This is just one of many examples. Conversely, I’ve trained fairly novice users on the basics of Active Directory (account management mostly) in fifteen minutes. A notepad with instructions on how to get into ADUC and perform a few simple tasks usually solves 90% of the problem. If it’s a common issue, a nice cheat sheet would be very appreciated. As far as I’m concerned, solutions providers who give this answer are just being lazy and/or don’t understand Active Directory and don’t want to admit it.