As you probably know, Windows Server went to General Availability yesterday. So, I took the opportunity to upgrade my virtualization host from 2008 R2 to Windows Hyper-V Server 2012. Hyper-V Server, which was introduced in the 2008 R2 era, is based on Server Core, meaning it has no GUI, and it comes with the Hyper-V role preinstalled. Hyper-V Server has no licensing cost of its own - it's free - but it comes with no free guest VM licenses.
I'll say right off the bat that I love Server Core. I'm sad that I don't get to play with Server Core much in production environments, but I firmly believe that will be changing in the near future. The fact that there is literally nothing that you cannot do on the command line and/or Powershell, makes Server 2012 the absolute most scriptable and automatable Windows Server ever. By far. And on top of that, the newest version of Hyper-V is bursting at the seams with improvements over the last version, such as shared-nothing live migrations, a much more flexible and extensible virtual switch that can be modified with plugins, and improvements on every metric in regards to how much vRAM, vCPUs, VHD size, etc., that can be allocated to virtual machines. Server 2012 feels super-polished, and runs faster than any previous version of Windows, especially Core.
Now that I've drooled over the new server OS, let's talk about my real-world experiences with it so far.
I downloaded the Hyper-V Server 2012 ISO, and uploaded the installation wim file to my local Windows Deployment Server. After scooting all my existing virtual machines off the box, I rebooted it into PXE mode and began installing the new 2012 image. The install was quick and painless. No issues recognizing my RAID volumes, etc. When the newly created server booted up, it asked for a local administrator password. Standard stuff. Then, I was dumped into a desktop with two Cmd.exe shells open, one of which was running Sconfig.
Sconfig is a basic command-line program that comes with Server Core as a supplement to help administrators do some routine setup and administration tasks on their new Core servers, since they don't have a GUI to rely on. Sconfig can do basic things like rename the computer, join a domain, set up an IP address, enable remote management, etc.
The point is that all of that stuff can be done without Sconfig, but Sconfig just makes it simpler to get up and running. Enabling remote management is particularly important, because that means we will be able to connect to this server remotely using MMC snapins, Powershell sessions, and the Remote Server Administration Tools (RSAT.) RSAT is not out for Windows 8/Server 2012 yet. But since I'm running Windows 8 on my workstation, and Windows 8 comes with client Hyper-V capabilities, that means I can add the Hyper-V Management Console on my workstation via the "Turn Windows features on or off" thing in the Control Panel. I'll then be able to connect to the Server 2012 hypervisor remotely and be able to play around with a GUI.
Speaking of Windows 8 - the Windows key is now your best friend. Hit Win+X on your keyboard. Now hit C. Try that a few times. Have you ever opened a command prompt that quickly before? No, you haven't.
So I did all the setup tasks there in Sconfig, and that's when I noticed that it doesn't seem that Sconfig is capable of setting IPv6 addresses on my network cards:
Bummer, I'll have to do that later. All my servers run dual-stacked, so IPv6 addresses are important to me. After joining my domain, setting up the time zone, and setting up IPv4 addresses on the two NICs in this server, I figured I'd done all the damage I could do with Sconfig and logged out.
Now that remote desktop and remote management were enabled, I could do the rest of the setup of the server from the comfort of my Win8 desktop. First, I wanted to enter a remote Powershell session on the server:
PS C:\Users\ryan> New-PSSession -ComputerName hyper2012 | Enter-PSSession
[hyper2012]: PS C:\Users\ryan\Documents>
A one-liner and I'm in. First, let's set those IPv6 addresses. At first I thought to do it with netsh. But upon executing it, netsh gives me a little warning about how it will eventually be deprecated and that I should use Powershell instead. Well I don't want to use anything but the latest, so Powershell it is!
PS C:\Users\ryan> New-NetIPAddress -AddressFamily IPv6 -InterfaceIndex 13 -IPAddress "fd58:2c98:ee9c:279b::3" -PrefixLength 64
That's it. The cmdlet will accept the IP address without the Prefix Length, but the Prefix Length is very important. If you omit that, you will wonder why it's not working. Prefix length is the same thing as subnet mask. So if this were an IPv4 address, with a subnet mask of 255.255.255.0, I would use 24 as the prefix length. My IPv6 addresses use a 64 bit prefix length. Since these cmdlets are brand new, they're not fully documented yet. The Get-Help cmdlet did not help me beyond giving me the parameters of the cmdlet. But the cool thing about Powershell is that it's simple enough that you can pretty easily guess your way through it. Plus that's the coolest thing about using a new OS that's hot of the presses, is that you're getting to run through exercises that not many people have yet, and you can't just Google all the answers because the info is just not out there yet.
Now let's put some IPv6 DNS servers on these NICs to go along with our IP addresses:
PS C:\Users\ryan> Set-DnsClientServerAddress -Addresses fd58:2c98:ee9c:279b::1,fd58:2c98:ee9c:279b::2 -InterfaceIndex 13
One thing I noticed is that even though I enabled Remote Management on the server, that did not enable the firewall rules that allow me to remotely administer the Windows Firewall via MMC. So I needed to enable those firewall rules on the server:
PS C:\Users\ryan> Set-NetFirewallRule -Name RemoteFwAdmin-RPCSS-In-TCP -Enabled True
PS C:\Users\ryan> Set-NetFirewallRule -Name RemoteFwAdmin-In-TCP -Enabled True
I am in favor of using the Windows Firewall and I like to control it across all my servers via Group Policy. Almost every organization I have worked with unilaterally disables the Windows firewall on all their devices. I don't know why... you have centralized control of it on all your computers via Active Directory and it adds another layer of security to your environment. In fact, had I not been in such a hurry and if I had let the Group Policy run on this server, those firewall rules would have been automatically enabled and I wouldn't have had to do that manual step.
So far I'm loving it. You're reading this blog post right now on a virtual machine that is hosted on Hyper-V Server 2012. I've never been as excited about a new Windows Server release as I am about 2012, and I make sure that everyone around me knows it, for better or worse. :)