JasonSamuel.com

Always remember to sysprep when cloning a node! MSMQ (Microsoft Message Queuing) uses a registry valued called QMId located at:

HKLM\Software\Microsoft\MSMQ\Parameters\Machine Cache

which has to be unique on all your servers or it will cause all sorts of issues. Sysprepping a server generates a new SID which also generates a new QMId in the process. If you don’t do this and have multiple servers out there with the same QMId, you will see strange things like messages remaining in the outgoing queue in limbo and sometimes just disappear completely with no trace in journaling anywhere. Bottom line, don’t confuse MSMQ! It’s fragile!

Thankfully John Breakwell (MSMQ guru at Microsoft) blogged about this exact issue which made me realize what was going on in the environment I was troubleshooting. Well done John!

http://blogs.msdn.com/b/johnbreakwell/archive/2007/02/06/msmq-prefers-to-be-unique.aspx

I simply ran sysprep and resealed the clone to fix it. It automatically generated a new QMId in the process so I didn’t have to follow the exact steps John had blogged about. It was a simple mistake which can be avoided in the future by using the Guest Customization Wizard in VC to automatically sysprep when creating the clone.

BTW, you can check if your SIDs are identical on a server by using getsid.exe. Download the Windows XP Service Pack 2 Support Tools:

http://www.microsoft.com/downloads/details.aspx?FamilyId=49AE8576-9BB9-4126-9761-BA8011FABF38&displaylang=en

and use the getsid.exe tool to compare SIDs on your Windows servers. Usage syntax is here:

http://technet.microsoft.com/en-us/library/cc784314%28WS.10%29.aspx

Since I’m blogging about MSMQ, let me take a moment to plug QueueExplorer (http://www.cogin.com/mq). This is hands down the best MSMQ management software I have ever used and the developer is very open to feature requests. Give them some business and tell them Jason sent ya! Check out a screenshot of it below:

IP Address conflict? Have you narrowed the MAC down to being a VM in one of your ESX/vSphere clusters? Well use vSphere PowerCLI to figure out what device and adapter is causing the conflict.

Example, if your MAC is 005056b60b13:

Get-vm | Select Name, @{N="Network";E={$_ | Get-networkAdapter | ? {$_.macaddress -eq "00:50:56:b6:0b:13"}}} |Where {$_.Network-ne ""}

And it will output the VM name and the Network Adapter causing the conflict.

Disasters happen and with a bit of skill and some luck, you might be able to get back into your operating system.  But you might notice a bunch of things out of place or missing if you had to do a Windows repair or use the Recovery Console to set things back to factory settings.

One of the tools I like to use is System File Checker (sfc.exe) which compares your file system against the original install disk and replaces missing or corrupt system files as needed.  Just go to a command prompt and type:

sfc /scannow

and Windows File Protection will begin scanning all your protected system files immediately.  If you get a prompt asking you to insert a disk, just cancel out and edit your registry key here:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup

and verify SourcePath is set to your CD-ROM drive with your install CD in it.  You’ll have to reboot to make sure the changes take effect.  Also you might want to verify:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup\ServicePackSourcePath

is set to C:\WINDOWS\ServicePackFiles just so your service packs you have installed after installing the original OS are taken into account and not overwritten by older versions.