# Thursday, October 22, 2009

Windows 2008 Cluster and Getting the Private Network to Work

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

# Tuesday, October 06, 2009

W08 Cluster Validator Error: Found duplicate IP address

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!!!

# Wednesday, August 05, 2009

Windows 2008 Print Services, HP LaserJet Printers and SLOW Printing

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
# Wednesday, July 29, 2009

Windows 2008 Spooler Warning on clustered print server - Event ID 4 -> Missing S-1-5-18\Printers\Connections

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.

# Thursday, July 16, 2009

Windows 2008 and the User Account Control and Clustered drives...

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


I don't even get a chance to say that "YES, I WANT TO ACCESS THAT FOLDER" which you normally get with UAC, just a big red X.

What are the possible choices? It seems that there are two:
  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).
I prefer #2 since (hopefully) the only people who will EVER be logging directly onto your server are Administrators anyway. Once the UAC is turned off you will be able to access all the appropriate folders, etc. Note that changing the UAC setting requires a reboot (one of the few things that still does in Windows - yeah!) so I would suggest you do it on the non-active nodes first so you are not constantly moving your active node from one node to the next.

I am not sure firstly, why this happens; and secondly, why there is no prompt to override it (I am, after all, a Domain Admin and therefore in the Administrators group of the servers) but it does happen. There is no way that I am aware of to set UAC to allow groups, or even to add more people. It is on (and only the default Administrator account can do the work) or it is off.

Hope this helps...

Note: MSoft reports that this is unique (or at least they have never heard of it). One interesting note - I can run the Cluster Configuration Validator even logged in as a non-default Admin with UAC turned on. Go figure...


# Wednesday, July 15, 2009

HP Laserjet 8060, Digital Sending, and Network Folder setup resolution (in Windows 2008)

I am moving our old windows 2003 clustered file share over to a brand, spanking new w08 clustered file share. There are things to note about the differences (another name, another IP???) but the thing I want to note about today had to do with one of our Multi-Function Printers, specifically the HP 8060.

We have that beast setup so that staff can scan documents and it gets sent to our public folder where they can get it. I guess when it was setup they were having trouble with specifying the network share and so my cohorts were advised to use the IP address of the share ->
\\10.10.10.10\public\scanner\folder.

This worked.

HOWEVER............

There always seems to be something that throws a wrench in the works and the wrench in this case is that in w08 you CAN NOT get to a share via IP address, but only by the name of the server. Let me state that again:

\\myserver\myshare\myfolder appears
\\10.10.10.10\myshare\myfolder does not

It seems that in w08 clustered file shares do not share on IP addresses. I have not mucked with this to see if there is a way around it, but out of the box there is no way to get to a shared folder via IP address. This, of course, means that the HP 8060 is throwing a hissy fit.

I was poking around in the Networking settings for the printer when I noticed that under the TCP/IP settings, in the Network Identification tab there was no entry for the DNS Suffixes. So I added our domain extension (ourdomain.com) and it worked!

Just to note, I had previously tried mapping \\myserver.ourdomain.com\myshare\myfolder on the printer and that did not work, but this did.

Hope that helps...
m