Hyper-V and Workgroups Part 1

Normally, I always talk about Hyper-V as though it were in a domain environment. Part of this is simply a matter of me staying within my comfort zone. I’ve only got a limited amount of time and space, so I try to limit it to what I know best. There is no intention of excluding those of you who might be using Hyper-V in a workgroup environment. This will be the first of a three-part series. This first part will deal with the how-tos; or, more correctly, it will point you to resources that can help you with the how-to portion. In the second and third installments, I’ll provide my raw opinions on why I think everyone should embrace an Active Directory domain environment for Hyper-V.

The Hard Line

To very badly misquote Tip O’Neill, “All security is local”. That should be the one thing you don’t forget in a workgroup environment. Any time something doesn’t appear to make any sense, reorient yourself to this one simple fact. A computer in a workgroup doesn’t trust anyone or anything that it doesn’t have a record of in its own local security account manager (SAM) database. There are three broad categories that you have to take into account when using Hyper-V: users, computers, and services.

• Users: User accounts have to be created on each individual machine that they need to have access to.
• Computers: Computers represent the security boundaries in a workgroup environment. This is the level at which you control access.
• Services: All programs run in the context of a user. Most people think in terms of the programs that they initiate. So when you start Outlook, Outlook is running as you and has the same permissions as your user account; no more, no less. A service is a program that runs without an interface, but otherwise it has to follow the same rule: it runs as a user. However, services can also run under special accounts, like “LocalSystem”. Due to the fact that the computer is a security boundary, these accounts mean nothing anywhere else.

Significance

The reason this information is important is that a lot of the tools don’t operate the way that many people expect them to. If you start Hyper-V Manager using an account that exists on a target host and try to connect, you’ll have problems. As an example, import and export are likely to behave in ways that aren’t immediately obvious. The reason is that Hyper-V Manager is a front-end to a service. The service itself (by default) runs as LocalSystem. LocalSystem is most easily understood as an account that represents the computer itself. You could change the service to run as a user, but this isn’t recommended for several reasons that won’t be covered here. You’ll run into similar issues with other management tools. Computer SAM databases contain users and groups, not other computer accounts. In most cases, there is no way for any computer to trust the identity of another.

Remote Management

Remotely managing a Hyper-V host in workgroup mode is usually the largest issue that administrators face. I didn’t have the exact steps to do this when I started writing this blog, so I hunted around a bit. The instructions I found were more or less what I expected, which is to say that they’re quite involved. Here is a link to a user-created article on allowing anonymous connections. Here is a link to a Microsoft-created document that includes directions for configuring a remotely-stored username/password combination in a 2012 environment and here is a blog post by Ben Armstrong on configuring a similar thing for a 2008 R2 environment. Even if you have a 2012 system I’d encourage you to check the second link as it’s substantially more thorough and may help you through any sticking points. Following those instructions will make connectivity possible. If you haven’t got the tools, we provided instructions on obtaining those in an earlier post.

Replica and LiveMigration (2012 Environments)

Replica and migration rely on intercommunication between two hosts. In a workgroup, the hosts have no reliable way to know to trust each other. Replica can be effected using certificates. Use the instructions in this post to make that happen. LiveMigration faces the same challenge, but there isn’t a certificate solution. Domain membership is the only answer in that situation.

Outtro

This concludes the how-to portion of the series on Hyper-V and workgroups. In the next two parts, I’ll switch into opinion-mode and try to talk you into replacing that workgroup with a domain.

Part 2 – Countering Reasons to use a Workgroup
Part 3 – Showcasing my favorite features