You know how it is. A nice, nested OU structure in AD. Everything beautifully organised in containers with weird and wonderful names. There’s a new guy who needs an account creating. Needs the same permissions as you. Simplest answer is to copy the account. But you didn’t set your account up so you have no idea where in the beautifully organised tree it is.
For a quick answer, run this VBScript:
[text]set objSysInfo = CreateObject("ADSystemInfo")
set objUser = GetObject("LDAP://" & objSysInfo.UserName)
wscript.echo "DN: " & objUser.distinguishedName[/text]
Ah, found it. Of course, things would be much quicker with PowerShell but 4 hours ago I was the new guy and PowerShell doesn’t really exists that side of the firewall yet 🙂
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.