I rebooted my clustered Hyper-V server. When I logged back on a test Virtual Server was showing a 'Saved-Critical' state. Attempting to start it resulted in the error message 'failed to restore virtual machine state'.

The issue? I had not made the VM clustered, so it was trying to launch the server without having access to the drive where the VM was stored. DOH!!!

Roll it back and start it, no problemo....

When clustering two servers together you may still want to set up private network connections. If you do hook a crossover cable and give it a different set of IPs from your domain you may find that the private network does not working. Pinging will return no responses. What you may have run into is that the Windows Firewall is interpreting your little private network as being 'Public' and so is block all communications in.

The solution depends on what flavor of w08 you are running. If you are running w08 you can go into the "Network and Sharing Center" and customize the network to be "Private" which will allow communication through. If you are running w08r2 it is not so simple. You have to go into Windows Firewall and explicitly tell it NOT to apply "Public" rules to the adapter you are using for your private network. 

Because a picture is worth a thousand words:

Windows 2008 (non-R2)

Windows 2008 R2

If you have tried installing the Windows 2008 Failover clustering one of the nice things that MSoft provides out of the box is a Cluster Validator. Not merely does it allow a more robust set of options for hardware, but it runs through a basic checklist of necessary and suggested configurations so you do not have to.

However, you may run into the following error under "Validate IP Configuration" -> Found duplicate IP address blahblahblah on node blahblah adapter Local Area Connection *blah and node blahblah2 adapter Local Area Connection *blah.

The reason for this is what is called the Teredo Tunneling Pseudo-Interface (TTPI). Which, as you can intuitively tell from its name is used to tunnel IPv6 traffic over an IPv4 interface. It turns out that the TTPI gives IDENTICAL IPv6 addresses to all the servers. Since the IP address is going through a unique IPv4 already this is not a problem (and prevents it from bumping against a different IPv6). When you apply it to clustering, however, this is flagged as an issue.

The basic solution is to disable the TTPI. The method I use is very simple:

1. Open up Server Manager to get to your Device Manager and under View select "Show hidden devices". (It is hidden, in case that was not obvious).

2. The TTPI should magically appear.

3. Now right-click and select disabled. I suggest you do this on all nodes

And you are good to go.

If this STILL does not work, take a look at Symon Perriman's entry here -> http://blogs.msdn.com/clustering/archive/2008/07/26/8773796.aspx

Have fun clustering!!!

If you have moved to Windows 2008 for your Print Server and have encountered slow printing to your HP Laserjets, the issue may be the driver.

According to this support document by HP the issue lies in the HP Bidirectional Channel component - namely hpzbid.dll and hpzbidXX.msi). You can read all about the symptoms/cause there but to make a long story short it appears that this lies with issues where it continually tries to reinstall the .dll and fails.

The solution, according to HP, is NOT to call up and get updated .dlls (they probably will not give them to you) but to use their updated Universal Print Driver (UPD) version 5.0. This changes the .dll to cioum.dll for the bidirectional channel control rather than hpzbid.dll. HP has no intention of updating hpzbid.dll so get used to it.

The symptoms are hard to miss (for example it takes 30 seconds just to view the properties of a printer on a client machine) so this one should not be hard to miss. Just remember to use the 5.0 version of the UPD.

Printers noted by HP:

• Laserjet 4250 series
• Laserjet 4350 series
• Laserjet 9040 series
• Laserjet 9050 series
• Laserjet 5200 series
• Laserjet P3005 series
  

After installing our clustered w08 Print Server I noticed that there was a particular Warning in the System Log. Event ID 4 "The print spooler failed to reopen an existing printer connection because it could not read the configuration information from the registry key S-1-5-18\Printers\Connections. The print spooler could not open the registry key. This can occur if the registry key is corrupt or missing, or if the registry recently became unavailable."

I looked in the registry and, no surprise, that key was missing. I hunted around a bit and found this entry. Basically to resolve this was fairly simple - add the key back in:

1. Open up the registry on the computer (I did it on all nodes individually)
2. Go to HKEY_USERS/S-1-5-18/Printers
3. Add a new Key called "Connections" (no quotes)
4. Right-click and select Permissions on the new key to verify that System has "Full Control"

Now I am not sure if this is an issue with Clustering or just a strange whacky event that happened. But if it happens to you, hopefully this will resolve it.

NOTE: This is NOT an issue with clustering, but appears to be an issue with w08 (and w08r2) regardless of whether the drive is clustered or local. For more info look here -> http://www.myfriedmind.com/techBlog/2009/10/14/UACAndDomainAdminsPermissionsIssueOnWindows2008.aspx

============ The information below is misleading - see the above link for correction

Another addition to w08 that might trip you up is the use of the User Account Control (or UAC) to prevent Administrator accounts (other than the default created one) from doing anything useful (unless prompted). Connect that with the fact that you can only sign onto a machine once per account (see this) and you have a case where you have to log on as the non-default Administrator but are hampered in doing your work.

Put aside the annoying popups (are you SURE you want to see the security permissions? Really? Really?) there is are more serious issues. Case in point - we have a Cluster server with the Role of File Services. Logged on as a lowly Domain Admin I can not get to the actual drive that it is sharing. Let me state that again clearly

1. I am working on a Clustered w08 server with the Role of File Services
2. I am logged on with a Domain Admin account (but not with the default Administrator account)
3. UAC is turned on
4. I can NOT access the drive(s) (much less the shares) that the Cluster uses

1. Always use the default Administrator account when logging on to a Clustered w08 account. This always gives you access.
   
2. Turn off UAC ON ALL CLUSTERED SERVERS (since if it is not turned off on the host server, whichever one that is, you are going to run into the same problem).