I was putting together a PoC late last year and encountered an issue that I’ve not seen before that was caused by some functionality within Windows 2008 that I did not know existed at the time. In fact, no one who I’ve mentioned it to since knew about it either. It seemed sufficiently obscure that I thought I should write about it quickly.
In the PoC, I had created a Windows domain based on Server 2008 R2. Setting that up was simple enough and I’d done it many times before. What I began to notice though was that DNS queries forwarded outside of my PoC infrastructure were failing more often than not. This made Microsoft Updates impossible to install amongst other issues.
After fiddling with the DNS timeouts and talking with the hosting provider at the remote datacenter to no avail, I discovered this Microsoft KB article:
Some DNS name queries are unsuccessful after you deploy a Windows Server 2003 or Windows Server 2008 R2-based DNS server
After following the workaround instructions and issuing the following command on the Windows DNS server…
[text]dnscmd /config /enableednsprobes 0[/text]
…external DNS queries were successfully resolved 100% of the time. Following up with the hosting provider, they confirmed that the larger UDP packets would have been dropped by their firewalls.
I often forget half of this stuff so I thought it might be cunning to put some of it into a post. Sorry if it goes on a bit, some of the numbers change depending on your choice of Service Pack and it was easier to split that sort of thing into separate tables. Continue Reading
I’ve lost track of the number of clusters that I have implemented or supported over the last few years. With each edition of Windows server that comes out clustering has improved. It was a bit of a dark art with Windows 2000 and in Windows 2008 it’s pretty much all point and click (and not many clicks at that). Most clusters that I encounter at the moment are still 2003. In a lot of organisations the joys of 2008 are still to come.
Clustering in 2003 offers few built in options for notifying anybody that a resource group has moved or failed over to another node. Ideally, the fact that it has should not be any cause for alarm but there are occasions when it is useful to know. Fortunately for some a well trained piece of monitoring software running on your network can alert you to events as they unfold and allow you time to resolve any issues and move the resource group back. For others, they must either check manually on a regular basis or find out at some later time when something else goes wrong and can be traced back to the resource group moving. Examples of such problems that I have encountered include:
- The local drive used for SQL database backups in a cluster running multiple instances not being big enough to cope with the backup files from both instances. If the two instances ended up on the same node then several scheduled tasks failed to complete.
- Exchange 2003 backups that only worked from one node of a two node cluster.
- Restrictive change control policies that required a restrospective change request to be raised within a number of hours or the world would end (really!)
In these instances I have found that a simple email notification can be quite handy. Sadly, Windows 2003 Clustering does not have such a facility. One can be created though.
I found the following script somewhere a few months ago that I have reused several times. It is a simple VBS script that, once customised slightly with correct values for your environment, is placed on every node in the cluster.
'Program Cluster Monitor
'Author: Pat Lee
'Date: 24 April 2008
'This program runs as a generic cluster application. When the cluster fails over/back it will send an email
'indicating the current owner. Change the constants as appropriate for your environment. It's advisable To
'send this email to a distribution group to facilitate administration of email. Refer to:
'http://support.microsoft.com/kb/260527 for instructions on setting up the generic cluster app.
Const strMailFrom = "[email protected]"
Const strMailTo = "[email protected]"
Const strMailSubject = "Node moved to: "
Const strMailBody = "Mailbody"
Const strMailServer = "myExchangeServer.myCompany.com"
Set WshNetwork = WScript.CreateObject("WScript.Network")
strNodeName = WshNetwork.ComputerName
strNodeSubject = strMailSubject & " " & strNodeName & " @ " & Now()
sendEmail strMailFrom, strMailTo, strNodeSubject, strMailBody, strMailServer
Sub sendEmail(mailFrom, mailTo, mailSubject, mailBody, mailServer)
Set objEmail = CreateObject("CDO.Message")
objEmail.From = mailFrom
objEmail.To = mailTo
objEmail.Subject = mailSubject
objEmail.Textbody = mailBody
objEmail.Configuration.Fields.Item("http://schemas.microsoft.com/cdo/configuration/sendusing") = 2
'careful on this one - use a parameter rather than a global for mailserver
objEmail.Configuration.Fields.Item("http://schemas.microsoft.com/cdo/configuration/smtpserver") = MailServer
objEmail.Configuration.Fields.Item("http://schemas.microsoft.com/cdo/configuration/smtpserverport") = 25
On Error Resume Next
If Err.Number <> 0 Then
Call logMessage(3, "Error sending mail - " & Err.Number & " " & Err.Description)
On Error GoTo 0
Set objEmail = Nothing
The other component that is required is a single line batch file on each node that calls the VBS file above.
Finally, a resource needs to be added to the resource group that you want to be alerted about using the instructions in this Microsoft KB article.