Hyper-V and Workgroups Part 3

In Part 1 of this series, we looked at some of the technical steps required to operate and manage Hyper-V in a workgroup environment. In Part 2, I provided responses to some of the common reasons I’ve heard to use workgroups. In this third and final installment, I will try to use this space to convince you to start using Active Directory domains by showcasing some of my favorite features.

I very clearly remember the release of Windows 2000 and all the changes it made. I was still fairly new to server operating systems in those days and I was more comfortable with Novell Netware than Windows NT 4.0. But, it wasn’t long before it was obvious that among all the changes introduced in Windows 2000, Active Directory was clearly the “killer app”. Active Directory and its integration into Windows and by third-party applications is approaching ubiquity. When evangelists from other systems try to goad me into using Mac or Linux or UNIX, my response is, and probably always will be: what do they have that compares to Active Directory and how well do system components and applications leverage it? To date, Microsoft is so far ahead of everyone else on this that Active Directory continues to be the “killer app”, even after more than a decade.

Single Sign-On

This has become so expected anymore that it’s almost passé to even talk about it. However, the deep reaches of its effects are worth a little rehashing. When Active Directory was new, we used to have a demonstration in which we would copy a large number of small files from one workgroup computer to another. Then we’d perform the exact same copy with the only difference being that both computers were members of the same domain. The difference in the amount of time required was substantial. Of course, modern hardware makes this test much less impressive, so we now have to use crude analogies.

First, the workgroup. Think of a workgroup has a hallway with multiple locked doors. Anyone can get into the hallway, but if they want to go into a door, there is an individual checking identification against a list that is specific to that door. Every time you want to go into a door, you have to be checked against the list. It doesn’t matter if you’ve been in recently; security policy dictates that you be checked each and every time.

Next, reconsider the hallway after it’s been converted to a domain. There’s now a checker at the initial entryway. Once you prove to the checker that you are who you say you are, the checker puts a colored stamp on your hand. Now, when you want to access one of the doors in the hallway, you just show your hand-stamp to the door’s guardian. The guardian doesn’t really need to reference the list; it just needs to know which shapes or colors of stamps it’s supposed to allow through today. If you’re in the hallway long enough, you’ll eventually need to go back and get your stamp updated.

Like most analogies, the above is crude and imperfect. The take-away is that the domain structure is more organized, has fewer management points, and its security process is less intrusive on legitimate traffic. This is all possible because the entire domain represents a security boundary. The “hand-stamps” (Kerberos tickets) issued by the domain controller are recognized by all members of the domain. With this trusted arbiter, computers can now even trust that other computers are who they say they are. In a workgroup, each member computer is its own security boundary and doesn’t recognize anyone else’s authority at all. Things like SSL certificates can be used as arbiters, but this requires a lot of extra work and application support is sparse.

Domain Security Model

Workgroup Security Model

This alone pretty much explains all the hoops you have to jump through if you want to connect from one workgroup member to another, or just to a computer that’s a workgroup member. Many workarounds have been developed, but these require a not-insignificant amount of effort and they are nothing more than workarounds. You can, for instance, tell some applications to trust certain hosts; what you are actually doing is telling the application to trust any computer claiming to be that host, or more correctly, that has that host name. Unlike a domain environment, you can’t actually get one computer to trust another without using SSL certificates or something comparable. Additionally, inter-computer authentication involves passing around entire user name and password combinations.

Centralized Management

The next big thing Active Directory boasts is centralized management. This provides multiple benefits. One that I often leverage is Group Policy. You can control machines without visiting them. Just the act of joining a domain and placing a machine in a configured organizational unit will almost immediately apply predefined settings to it. You can install Hyper-V, assign a management IP, join it to the domain, and move it into its destination organizational unit while it’s rebooting. Assuming the group policy is configured properly, you’ll be able to remotely connect to it because its remote connection and firewall policies will come down through group policy assignments. Once you’re in, you can configure any computer-specific settings. Anything not specific to that machine can be delivered by group policy.

Application-Awareness

Many applications are Active Directory aware, but this blog is specific to Hyper-V. In Hyper-V Server 2012, a new “Hyper-V Administrators” group exists on the local system. You can place users and groups from the domain into this group and they’ll be allowed to manage Hyper-V. Clusters, LiveMigration, SMB shares, and many other technologies highly valued in a Hyper-V deployment are Active Directory dependent.

Ease of Use

One of the things that set Active Directory apart from other LDAP systems right from the start is the ease in which it can be implemented. Hyper-V is more difficult to use than Active Directory, especially in a smaller organization. If you’ve figured out how to get Hyper-V going, Active Directory isn’t going to be much trouble at all. The only thing that tends to catch people by surprise is its dependence on DNS, but there aren’t many technologies in data centers today that are easier to learn than DNS. If you run into any troubles, there are literally millions of people who have been there before and help is just a forum click away. Any independent Microsoft-focused service provider in your area should have many Active Directory experts on staff, so you should have few troubles finding local help if you prefer. Tutorials and training resources for Active Directory exist in abundance. Also, you don’t need an elaborate setup to benefit from Active Directory.

Wrap-Up

There are, of course, many more positive things that could be said about Active Directory, but these are the ones that usually grab the attention of the uncertain. The more you use it, the more you become familiar with it, and it doesn’t take long before you don’t want to be in any environment that doesn’t have it. Personally, I would be resistant to working on any non-home environment that didn’t employ domains unless there was an extremely well-reasoned explanation. The only one I’ve seen yet is restrictions enforced by cloud providers. Even then, my instinct is to seek out alternate providers before accepting this limitation. If domain separation is truly desirable, employ sub-domains instead of workgroups. Stop dragging those feet and get those domain controllers spun up!

Part 1 – How to use Hyper-V in a Workgroup Environment
Part 2 – Countering Reasons to use a Workgroup

Have any questions?

Leave a comment below!

Backing up Hyper-V

If you’d like to make backing up your Hyper-V VMs easy, fast and reliable, check out Altaro Hyper-V Backup v4. It’s free for up to 2 VMs and supports Hyper-V Server 2012 R2! Need more? Download a 30-day trial of our Unlimited Edition here: http://www.altaro.com/hyper-v-backup/.

(Don’t worry, we hate spam too!)