Notes From The Field : Hyper-V

A Small Concern When Virtualizing Domain Controllers - Time Sync

jdphilli — Fri, 13 Feb 2009 20:48:00 GMT

I'm sure this might open a can of worms, but it's a discussion that needs to happen. As virtualization technologies come into maturity, customers are more and more leaning towards virtualizing all of their infrastructure services. This includes Active Directory. Virtualizing Domain Controllers has been going on for some time now and was at first completely unsupported and even recommended against. That stance is changing considerably now, and we're beginning to see some official recommendations addressing this issue.

Let me first emphasize following the guidance set forth in this article: http://technet.microsoft.com/en-us/library/dd363553.aspx which contains official recommendations when virtualizing domain controllers in Hyper-V. The big 3 “don’t dos” are: never user differencing disks, don’t clone the guest without SYSPREPing it first, and don’t copy a VHD of a previously installed DC as the base for a new one. Those are all pretty straight forward to keep you from having SID conflicts or USN rollback issues which will totally mess up your AD installation.

Now, the next big issue is Time Sync. Microsoft recommends disabling host to guest time synchronization so that all DCs will use the default Windows Time service hierarchy just like a physical server. That’s not so hard, right? Just go into Hyper-V and disable that feature from the Integration Services settings. Easy. Done.

But: what about DCs running virtualized on VMWare [for the sake of discussion, let’s assume the SVVP supported version]? What does VMWare recommend? According to their KB article http://kb.vmware.com/selfservice/viewContent.do?language=en_US&externalId=1318, they say to turn of Windows Time service and use their host-to-guess time sync, except for the PDC Emulator of course, but then they want you to leave that on with “NoSync” turned on.

So: what is one to do?

First, I’d suggest a compromise – one that may avoid some of the issues. Don’t virtualize all your DCs. In fact, this is outlined in the Microsoft article above. You should really keep at least one hardware-based copy of your domain, and it should be the PDC emulator of the root domain of the forest. Preferably, in multi-domain forests, you’d want to keep a physical server for the PDC emulator of each child domain as well. This doesn’t have to be a very large machine, unless you’re a very large organization.

Now, if you virtualize all other DCs on Hyper-V (which I’d recommend not just because it’s Microsoft’s solution and I’m an employee, but because I’ve used both and Hyper-V is SO much easier to manage and configure), then the answer is clear: for DCs, leave the Windows Time service running on the guest DCs, with the root PDC Emulator’s time service configured to point to a highly-accurate external clock and disable Time Synchronization in the Integration settings. The Hyper-V hosts should then be joined to the domain. This will keep all hosts and guests synched to the proper time.

For guest running on VMWare, this is a tough decision since there are competing recommendations. Anecdotally, I have heard of no particular issues with disabling time sync in the VMWare tools and leaving Windows Time to synch the DC time clocks, but I have heard of issues the other way around: letting VMWare tools manage the time sync. In my opinion, such a custom solution as VMWare recommends should only be used if you’ve experience problems with the regular way of doing things. That’s why it’s the default: it generally works well when left that way. You should also configure the hosts to retrieve their time from the physical PDC Emulator in the root domain.

So, in summary, use a physical DC for at least one of your DCs per domain, and when you have to use VMWare, I’d recommend disabling the time sync from host to guest on domain controllers, and setting the hosts to obtain their time information from the root PDC Emulator. All other guests can be configured to obtain time from the host. But, as always, carefully monitor all your event logs for your servers and make sure you don’t have any issues.

A New Better Hypervisor

jdphilli — Fri, 03 Oct 2008 16:37:00 GMT

If you've been following the news (and by news I mean the important stuff like technology and virtualization, not that political stuff) then you know that Microsoft just realeased and new virtualization product called Microsoft Hyper-V Server 2008. I know what you might be thinking - "Didn't that already come out months ago?" Well, not exactly. Hyper-V is a virtualization technology. Previously, it was released as an installable role on Windows Server 2008. Now, however, there's a BIG difference. This Hyper-V Server now installs as a stand alone product - no Windows operating system at all. Wow.

Back a couple of years ago when I first heard of some of the planned features of Windows Server 2008 such as Server Core, I thought that it would be just the thing to compete with other vendors' dedicated virtual hosting platforms, but it didn't turn out to be as thin as I though. What Server Core really does is make the interface lean and take away some of the unnecessary extras such as a GUI, but the core of the OS is still there. Hyper-V Server 2008 is the final step to a dedicated application platform - without any graphical user interface or any other installable services. It's dedicated for hosting virtual machines only.

What that really means in practical terms is better performance, manageability, and security. Better performance because as our competitors have boasted about their products there is now no "user" application space and the overhead associated with that so that more resources can be dedicated to the guest machines. Manageability and security since you now do not have to worry near as much about patching and attack footprints on the host box.

All this and the fact that it will do BItLocker encryption means that this may be the perfect host server for a branch office configuration (like I mentinoed in a previous post).

It also means that I'm now going to have to rebuild my lab...

Remote Office Server Consolidation With Hyper-V and BitLocker

jdphilli — Wed, 04 Jun 2008 19:28:00 GMT

Do you remember the days when servers for remote offices were under someone's desk or in a janitor's closet? How about in a reconfigured bathroom stall? (Yes, I've actually seen these) Are those days still now for you? The problem of securing remote branch office servers is still a common one. I've seen broom closets, dusty storage rooms, and even a server being used as the local administrator's desktop workstation all as part of major enterprise branch office infrastructures.

A main concern with these kinds of installations is security. Since there isn't usually a dedicated, secure server room to house these servers, they share access with what are normally commonly accessed areas: like an office trailer at a construction site, or under the receptionist's desk. Another concern with branch offices is space - which is why these servers end up under desks or next to the water cooler in the copy room. Maybe the site has enough room for one server, but two? Three? Five? Not likely.

How do you secure these servers as well minimize the number of servers you deploy to the branch office?

First, let's start with Hyper-V. What is Hyper-V? It's the new virtualization engine for Windows Server 2008. It is a radical change from Virtual Server and the performance is much, much better. Among the many benefits with Hyper-V, you can run native x64-based guest OS installs. This is especially important when installing products like Exchange 2007.

For small branch offices, Hyper-V provides the option of packing several virtual servers on one physical box, thereby simplifying the amount of infrastructure necessary for site deployments: less power requirement, fewer network drops, fewer cables, less space, etc.

Now that you've decided that virtualization is a good thing for small offices, you think: "But wait! If someone swipes the server from the construction trailer, they'll have copies of my sensitive data!" This is where BitLocker comes in.

First introduced with Windows Vista, BitLocker is full volume encryption for Windows (Vista and Server 2008). That small branch office server with Hyper-V you just built can now be configured to use BitLocker to encrypt its drives, thereby securing the installed virtual machines and making them practically inaccessible even to those who would steal the hardware.

You can even put a more secure spin on this combination by making the host OS a Server Core installation. This will greatly decrease you attack footprint on the host as well as simplifying the patching process. A smaller OS footprint means fewer vulnerabilities. Fewer vulnerabilities means fewer patches for Server Core. Fewer patches means fewer reboots, which is always a good thing.

Installing Server Core as the host OS also provides an additional layer of security: the command line interface. There's no GUI with this OS which makes it harder for the amateur site administrator to inflict any damage.

In summary, a Server Core installation of Hyper-V protected with BitLocker (and possibly a Read Only DC installed as a VM, but we can talk abou that later) will give you a great option for deploying to less secure and “infrastructure challenged” environments.

You should try it.