[Updated May’09: Windows Storage Server 2008 now available to MSDN/TechNet subscribers. Checkout Jose Barreto's Blog for details.]

Familiar with Virtual Server 2005 and shared disks for creating virtual clusters?  Well its different with Hyper-V.  The shared disk option is no longer available (which I did not know when I started testing).  You have to use iSCSI instead.  Here is a step by step method for creating a fail-over cluster within Hyper-V.  Its a cheap way of setting up a test lab (assuming you don’t have access to Windows Storage server).  In this post I use StarWind to simulate iSCSI storage … its not an endorsement of the product, I just picked it from amongst the crowd.

Windows Server 2008 fail-over clusters support Serial Attached SCSI (SAS), iSCSI and Fibre Channel disks as storage options.  So, how would you go about setting up a virtual Windows Server 2008 test cluster using the new Hyper-V vitalisation product?  The method I am about to outline is a little different to what you might be used to Virtual Server 2005.  The following steps detail how I managed to setup a test cluster using simulated iSCSI storage.  Before beginning it’s worth reviewing this article that outlines the storage options that are available to Hyper-V.  By the end of this post you should have a simple two node cluster up and running using simulated iSCSI storage.

Tools for the job:

• A Windows Server 2008 server x64 server with the Hyper-V role enabled (I used a Dell Precision 390)
• One Windows Server 2008 VM to act as a Domain Controller (Clusters must be part of a domain) 
• Two Windows Server 2008 VMs to act as Cluster Nodes
• One Windows Server 2003 SP2 VM (or you could use Windows Server 2008 in a Core install to maximise VM performance)
• iSCSI Target Software: I used the StarWind product that is available as a 30 day eval.  Windows Storage Server is now available to MSDN/TechNet subscribers.
• iSCSI Initiator software (built into Windows Server 2008)

I wont go into how to create a VM but you can find more info from Virtual Guys weblog.

Before I began looking into the iSCSI simulated storage option for my cluster nodes I tried to expose a single VHD to each of my cluster nodes in the hopes that they would share it.  I didn’t get very far and was presented with the following error when powering on the VMs:

This error is by design (thanks Justin Zarb for point this out) as Windows Server 2008 Hyper-V does not support this sort of storage (see link above for Hyper-V storage options).  The above error is simply a file system error as the VHD “is being used by another process” … should have spotted that

SETTING UP THE LAB

Note: I’m assuming that you know how to install Windows Server 2003 and 2008.  I’m also assuming that you know how to install and configure a Window Server 2008 Domain Controller.  If you have any questions leave me a comment and I will see if I can point you in the right direction.

VIRTUAL NETWORK

Create the network with a connection type of “Internal Only”.  I enabled Virtual LAN identification and set the default ID to 2 as this will be my public LAN.  Setting the default to 2 means that if I dont specify a VLAN on subsequent NICs they will be classified as public connections.

VLAN ids:

• VLAN 2: Public 10.1.1.x/24
• VLAN 3: Heartbeat 192.168.1.x/24
• VLAN 4: iSCSI 192.168.2.x/24

SERVER SETUP

Tip: Be sure to rename each network card on the hosts to make identification easier.  If its the public NIC, call it public etc.

Domain Controller: dc01

• Windows Server 2008 x32 
• One VHD IDE fixed size disk 10GB
• 1 x NIC connected to my Virtual Network in VLAN 2

Network settings:

• IP Addr: 10.1.1.10
• Mask: 255.255.255.0
• Gateway: I didn’t bother setting one
• DNS: 10.1.1.10

Cluster Nodes:

• Windows Server 2008 x32
• 1 x VHD IDE fixed size disk 10GB
• 3  x NICs connected to my Virtual Network in the following VLANs
  • Public card: VLAN 2
  • Heartbeat card: VLAN3
  • iSCSI: VLAN4

Node01

Public NIC: VLAN 2

• IP Addr: 10.1.1.20
• Mask: 255.255.255.0
• Gateway: I didn’t bother setting one
• DNS: 10.1.1.10

Heartbeat NIC: VLAN 3

• IP Addr: 192.168.1.4
• Mask: 255.255.255.0

iSCSI NIC: VLAN 4

• IP Addr: 192.168.2.4
• Mask: 255.255.255.0

Note: On all NICs in VLAN 3/4 be sure to disable the Client for Microsoft Networks, disable DNS registration and disable NetBIOS.  Be sure to check your binding order too.   The public NIC should be first.

Node02

Public NIC: VLAN 2

• IP Addr: 10.1.1.21
• Mask: 255.255.255.0
• Gateway: I didn’t bother setting one
• DNS: 10.1.1.10

Heartbeat NIC: VLAN 3

• IP Addr: 192.168.1.5
• Mask: 255.255.255.0

iSCSI NIC: VLAN 4

• IP Addr: 192.168.2.5
• Mask: 255.255.255.0

Note: On all NICs in VLAN 3/4 be sure to disable the Client for Microsoft Networks, disable DNS registration and disable NetBIOS.  Be sure to check your binding order too.

iSCSI Target

• Windows Server 2003 SP2 x32 (see here for notes on W2K3 hosts in Hyper-V)
• 1 x VHD IDE fixed sized disk 10GB
• 2 x VHD SCSI fixed sized disks 1GB and 10GB for Cluster disks
• StarWind iSCSI Target Software
• 2 x NICs  connected to my Virtual Network in the following VLANs:
  • Public : VLAN 2
  • iSCSI : VLAN 4

Public NIC: VLAN 2

• IP Addr: 10.1.1.22
• Mask: 255.255.255.0
• Gateway: I didn’t bother setting one
• DNS: 10.1.1.10

iSCSI NIC: VLAN 4

• IP Addr: 192.168.2.2
• Mask: 255.255.255.0

Note: On all NICs in VLAN 3/4 be sure to disable the Client for Microsoft Networks, disable DNS registration and disable NetBIOS.  Be sure to check your binding order too.  Make sure you format and assign drive letters to the SCSI VHDs on this VM.

Setting up the Cluster

Update 17/10/2008: I've also found that using the Image Files option works quite well too.   Image files will allow you to pack more than one VM onto a disk partition.  Check out http://www.starwindsoftware.com/images/content/StarWind_MSCluster2008.pdf for more info.

Note: Check out the how to the same with Windows Storage Server 2003 R2.  http://www.microsoft.com/windowsserversystem/wss2003/productinformation/overview/default.mspx

Update May 09: Windows Storage Server 2008 has now RTM’d and is available online through MSDN and TechNet.  http://www.microsoft.com/windowsserver2008/en/us/WSS08.aspx

Configuring the iSCSI target software (Starwind)

• Install the StarWind software on your iSCSI target VM. 
• Launch the StarWind management console. 
• Under the Connections you should see localhost:3260.  Right click on localhost and select Connect.  If I remember correctly the first username and password becomes the default (which you can change later).

• Right click localhost:3260 and select add Device 
• Select Disk Bridge Device as the Device type and click next

• Select the first SCSI disk from the list (more than likely \\.\PhysicalDisk1). 

• Select Asynronous Mode and Allow multiple iSCSI connections (clustering) and click next 
• Give the disk a friendly name
• Repeat the steps to add the second disk

Adding disks to the cluster nodes

Each cluster node now needs to be connected to the iSCSI target.  Launch the built in iSCSI initiator and follow the steps below:

• If prompted to unblock the Microsoft iSCSI service always click Yes otherwise the 3260 port will be blocked. 
• Click on the Discovery tab and select Add Portal.
• Enter the IP address for the iSCSI target [192.168.2.2]

• Click the Targets tab and you should now see a list of the disks available on the target

• For each disk in the list click Log on and select Automatically restore this connection
• Click on the Volumes and Devices tab and select AutoConfigure.  You disks should now appear as Devices.
• Reboot each cluster node as you add the disks.
• Disks will be offline when you reboot.  Ensure that you bring them online in Disk Management.

When completed (and hosts connected) you should see something like this on the iSCSI target VM.

Installing the Cluster

The new fail-over cluster wizard is quite straight forward and much easier to follow when compared with Windows Server 2003.  There isn't much point in going into too much detail … you’ll find plenty of info on the web.

Here is a step by step guide to installing a two node file cluster in Windows Server 2008.

I recently gave an overview of NAP at a Windows Server 2008 event.  For the purposes of the event I focused and demo’d DHCP enforcement.  From some customers DHCP enforcement was not enough.  What about 802.1x enforcement ?  Our pals on the NAP team have already blogged this (quite sometime back) as an introduction to what the real world options are.  Check it out : NAP 802.1x enforcement.  I’d also point you in the direction of the Step by Step lab guide.

For a real world view of NAP in action with Cisco switches check out Michael Kleefs blog here.  When I asked about real world implementations Michael's demos where recommended.

While on the topic of NAP…. I was also asked about how much traffic does it generate.  Yet again Michael Kleef had the answers.

Update:  No sooner had I posted this (7 minutes after to be exact) Jeff Sigman (NAP guru) commented that he setup a rack with 10+ switches.  Check out his posting http://blogs.technet.com/nap/archive/2008/04/15/video-nap-world-tour-rsa-2008-san-francisco.aspx.  How is that for fast information update! :)

In my post yesterday I spoke about virtualisation candidates (amongst other things) and how we now know what loads and systems are viable.  Have a look at the Microsoft Assessment and Planning (MAP) tool.  Its the tool for identifying candidates.  There is also a nice video demo from Baldwin Ng, showing the tool in action.  The tool will remotely gather information regarding your enterprise without installing agents.  The MAP tool then generates a candidacy report(s) that can be used to justify the investment including the hardware requirements for your virtualisation environment. 

Note: The RTM version of MAP v3.0 only includes Virtual Server 2005.  You will need MAP v3.1 Beta for Hyper-V.  Check out this posting for details on joining the beta.  It is still worth running the MAP v3.0 against your environments as virtualisation candidates should be the same regardless.

I was recently asked (two hours ago) how to tell if a server was running Terminal Services in Application Mode.  The customer wanted to run a different script if users were logged into a Terminal Server.

They had looked through the registry and came across the TSEnabled value in :

HKLM\Software\System\CurrentControlSet\Control\Terminal Server

While this key does indicate whether or not TS is enabled, it does not tell you if the server is in Application Mode.  To compound the issue this key is also set to 1 by default on Windows XP.  So, surely there was a more appropriate way to check?  Indeed there is … the Win32_TerminalServiceSetting WMI class will allow you to check.  See the code below:

Dim strComputer, objWMIService, colClass, objClass, strTSMode

strComputer = "."

Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")

Set colClass = objWMIService.ExecQuery("Select * from Win32_TerminalServiceSetting")

For Each objClass in colClass

    strTSMode = objClass.TerminalServerMode

    If strTSMode = 1 Then

        Wscript.Echo "Terminal Server is in Application Server mode."

    Else

        Wscript.Echo "Terminal Server is in Remote Administration mode."

    End If

Next

Note: This will not work under Windows 2000 as the WMI class does not exist.  I have not checked it in Windows 2008.

The print spooler is a temperamental beast at the best of times.  Print servers end up with a whole myriad of drivers, print monitors and print processors.  The more queues and printers there are the greater the potential for problems. Clustering your print server makes sense but it does add another layer of complexity for you to manage.  I recently tackled a problematic print cluster and thought Id blog about it.  In this post I have pulled together information on how to “clean up” a clustered print spooler.  I’ve drawn information from a few sources for this post.  Big thanks to Paul Cook (Premier Field Engineer in the UK) for his advice … the man knows his print clusters :)

Before we begin, have a read of the following posts:

http://blogs.technet.com/askperf/archive/2007/07/20/windows-2003-print-clusters-part-one.aspx

http://blogs.technet.com/askperf/archive/2007/07/27/windows-2003-print-clusters-part-two-recommendations.aspx

http://blogs.technet.com/askperf/archive/2007/08/07/windows-2003-print-clusters-part-three-troubleshooting-missing-print-queues.aspx

Right, so now you know how it all ties together.  Let’s tackle a few problems that I encountered:

1. Unsupported Print Monitors were installed
2. Print Queues were using third party Print Processors
3. Third party printer drivers

Unsupported Print Monitors are a common explanation for the spooler biting back. 

WARNING 

Use the Printing tool to take a backup of your current configuration BEFORE continuing.  I would also advise that you take a system state backup to ensure that the cluster configuration is safe and sound.  Let me re-iterate again, TAKE A BACKUP.  Oh, and don’t forget to test everything before tackling your production systems! 

Unsupported Print Monitors

When a printer is installed into a cluster using a driver that ships with Windows Server 2003, the cluster service only uses the standard TCP/IP or LPR monitors. No third-party monitors are supported on server clusters.

The following monitors are considered supported:

• BJ Language Monitor
• Local Port
• LPR Port
• Microsoft Document Imaging Writer Monitor
• Microsoft Shared Fax Monitor
• PJL Language Monitor
• Standard TCP/IP Port
• USB Monitor
• Windows NT Fax Monitor

Make sure that each queue is using the Standard TCP/IP port monitor.  You can see the monitors installed on the cluster by viewing:

HKLM\Clusters\Resources\<resource id>\Parameters\Monitors

You should remove any unsupported print monitors from the above registry key once all queues are configured to use supported monitors.

Print Queues using third party Print Processors

The official line is that third party print processors ARE supported but NOT recommended (Microsoft recommend using the WinPrint processor).  Print processors are user-mode dynamic-link libraries that are responsible for converting the spooled data of a print job to a format that can be sent to a print monitor. Print processors are also responsible for handling program requests to pause, to resume, and to cancel print jobs.

You wont know what processor a particular driver will use unless you edit the INF before installing.  Realistically editing the INF is not an enticing option. I prefer changing the queue to WinPrint after you have set it up.  So the the first challenge is to identify what Print Queues are not using the WinPrint processor.  You could manually go through each subkey in 

HKLM\Cluster\Resources\<resource id>\Parameters\Printers

Or, you could script your way out of the problem like this:

This script creates a log file called results.txt listing the print processors for each print queue.  Now you know what queues are not using WinPrint, how do you go about changing them?  You have three options:

1. Change it manually by going into the advance properties the queue, click Print Procesor and select WinPrint.

   

   

2. Change it manually in the registry HKLM\Cluster\Resources\<resource id>\Parameters\Printers\<queue>\Print Processor
3. Write a script to change all print processors to WinPrint.

   Const HKEY_LOCAL_MACHINE = &H80000002 strLogfile = "C:\results.txt" strComputer = "target server" intCounter = 0 Set objFSO = CreateObject("Scripting.FileSystemObject") Set objFile = objFSO.CreateTextFile(strLogFile) Set objReg=GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & strComputer & "\root\default:StdRegProv") strKeyPath = "Cluster\Resources\<resource id>\Parameters\Printers\" objReg.EnumKey HKEY_LOCAL_MACHINE, strKeyPath, arrSubKeys For Each strSubkey in arrSubKeys     objReg.GetStringValue HKEY_LOCAL_MACHINE, strKeyPath & strSubkey,"Print Processor", strPrintProcessor     If LCase(strPrintProcessor) <> "winprint" Then         objReg.SetStringValue HKEY_LOCAL_MACHINE, strKeyPath & strSubkey,"Print Processor", "WinPrint"         objFile.WriteLine "Printer: " & strSubkey & vbTab & "Print Processor was: " & strPrintProcessor & " but has now been changed to WINPRINT"         intCounter= intCounter + 1     End if Next WScript.Echo "Finished.  Modified " & intCounter & " printer processors" objFile.WriteLine "Modified" & intCounter & " printer processors" WScript.Quit

Once you have changed all queues to WinPrint you could now remove the third party print processors from the cluster.  However, think about the consequences before decide to delete them. 

If a print queue is configured to use a print processor that no longer exists it will not appear when the print spooler is restarted.  To get the queue back you have to edit the registry to change the print processor to WinPrint and restart the spooler.

Should you still wish to delete the print processors you will find them, depending on the environment in:

HKLM\Cluster\Resources\<resource id>\Parameters\Environments\Windows NT x86\Print Processors

Regardless of whether you delete the third party print processors every time you create a new queue or install a new driver, make sure you change the print processor to WinPrint. 

In some instances using the WinPrint Processor can reduce functionality on a printer e.g. twisty text or watermarks and the likes.  So, there may be instances where you have to use third party print processors.  You could consider creating a new Print Spooler resource on the cluster for third party processors and leave all of the WinPrint queues on another spooler.  Each spooler resource on a Windows 2003 cluster can have its own set of drivers, processors and monitors located in HKLM\Cluster\Resources\<resource id>\Parameters

Third party printer drivers

Third party drivers can impact the stability of your print cluster.    As a general rule, see if you can use the drivers that ship with Windows Server 2003 before considering the installation of third party ones. Another thing that really kills print servers is running the setup program that comes with printer drivers.  Not only is this not the supported method for adding a driver to a print cluster it also installs a whole lot of unwanted “stuff” (like system tray icons).  Check out the Cluster Server Resource Centre for more details.  Check out How to set up a clustered print server for details on how to setup the spooler and create print queues.

Conclusion

If you tackle the Print Monitors, Print Processors and Drivers you have gone a long way to ensuring that your print server is stable.  However, there is one thing that very quickly undoes all of your hard work and that’s Terminal Services Printer Redirection.  Imagine you’ve cleaned up your drivers, removed unsupported port monitors and set everything to use the WinPrint processor… all of a sudden different drivers start appearing on your cluster!  I recommend disabling client printer redirection on ALL print servers, not just the clusters (in fact, I have in the past disabled it completely on all servers to stop printer drivers being installed).  You can find the option to disable client printer redirection under:

Computer Configuration\Policies\Administrative Templates\Windows Components\Terminal Services\Terminal Server\Printer Redirection

Enable the Do not allow client printer redirection setting.

One last word

Windows Server 2008 Fail-over clusters are well worth looking into.  There have been improvements across the board.  Print Clusters are now easier to install, configure and manage.  Click on the image below to learn more about Windows Server 2008.