If you are like most people you will have Windows Server 2003 R2 installation media that only includes Service Pack 1. This means that any R2 server you deploy needs to have SP2 installed afterwards, which is time consuming and also pretty boring.
The good news is you can slipstream SP2 into your R2 media just as easily as with previous versions of Windows Server. Both the Disc 1 and Disc 2 media need to be slipstreamed or you will run into errors if you try to add the R2 components onto the server.
Simply copy your R2 Disc 1 and Disc 2 media to your hard drive, download the Windows Server 2003 Service Pack 2 Download, and run the slipstream commands.
C:\>WindowsServer2003-KB914961-SP2-x86-ENU.exe /integrate:C:\Temp\Windows2003R2\Disc1
C:\>WindowsServer2003-KB914961-SP2-x86-ENU.exe /integrate:C:\Temp\Windows2003R2\Disc2
Some time ago I wrote about my experience recovering a customer’s Active Directory from a USN Rollback condition that had been caused by some virtualisation work. There has been some discussion in the comments in that post about what to do when you have a single domain controller that thinks it is in a USN Rollback condition (eg has disabled outbound replication and paused the NetLogon service).
Logic would suggest that once a DC knows it is the only DC in the Forest that it would shake off the USN Rollback blues and start humming away normally again. Not the case unfortunately.
Rob P recently spent some time and effort with Microsoft support and came up with a solution that can be applied.
!!!Warning!!! !!!Warning!!! !!!Warning!!!
I’m not 100% sure why I’m warning you, but I’ll take Rob’s word on the matter. Apparently this fix is quite dangerous and not for the faint of heart. My heart is not the least bit faint, particularly when it comes to my VMWare test environment, so I didn’t mind testing this out. At the very least you should make sure you have a backup of the server you can go back to if this doesn’t work.
To get a single domain controller out of USN Rollback:
- Open Regedit
- Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
- Locate the key “Dsa Not Writable”=dword:00000004
- Delete the entire key
- Enable replication by running repadmin /options servername -DISABLE_OUTBOUND_REPL and repadmin /options servername -DISABLE_INBOUND_REPL
- Reboot
Once your domain controller has rebooted you should find that NetLogon is running again and repadmin /options no longer shows replication as being disabled.
I performed this test on a Windows Server 2003 R2 domain controller and I imagine it works fine on Small Business Server 2003 as well.
An Exchange Server 2007 server with incorrectly loaded performance counters may result in many instances of event ID 3006 being logged to the Application Event Log.
Event Type: Warning
Event Source: LoadPerf
Event Category: None
Event ID: 3006
Date: 10/09/2007
Time: 12:51:51
User: N/A
Computer: SERVER
Description:
Unable to read the performance counter strings of the 011 language ID. The Win32 status returned by the call is the first DWORD in Data section.
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Data:
0000: 02 00 00 00 20 01 00 00 …. …
One solution to these Event Log warnings is to run “Lodctr /r” from a command line. A description of the Lodctr utility is available here.
Running this command may cause the following errors to appear in the Application Event Log, which identify the particular performance counters that are causing the issue.
Event Type: Error
Event Source: LoadPerf
Event Category: None
Event ID: 3009
Date: 10/09/2007
Time: 12:52:05
User: N/A
Computer: SERVER
Description:
Installing the performance counter strings for service MSExchangeFDS:UM (%2) failed. The Error code is the first DWORD in Data section.
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Data:
0000: 27 05 00 00 d1 11 00 00 ‘…Ñ…
Event Type: Warning
Event Source: LoadPerf
Event Category: None
Event ID: 2007
Date: 10/09/2007
Time: 12:52:05
User: N/A
Computer: SERVER
Description:
Cannot repair performance counters for MSExchangeFDS:UM service. Please re-install manually using LODCTR tool.
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Data:
0000: 27 05 00 00 17 05 00 00 ‘…….
In this situation the performance counters must be reloaded manually. In the case of Exchange Server 2007 the performance counters can be reloaded from C:\Program Files\Microsoft\Exchange Server\Setup\Perf. In this example the MSExchangeFDS:UM counter is the cause of the error, which is loaded from the FDSUMPerformanceCounters.ini file.
C:\Program Files\Microsoft\Exchange Server\Setup\Perf>lodctr fdsumperformancecounters.ini
If the reload is successful the following event is logged.
Event Type: Information
Event Source: LoadPerf
Event Category: None
Event ID: 1000
Date: 10/09/2007
Time: 13:06:27
User: N/A
Computer: SERVER
Description:
Performance counters for the MSExchangeFDS:UM (MSExchangeFDS:UM) service were loaded successfully. The Record Data contains the new index values assigned to this service.
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Data:
0000: 88 18 00 00 90 18 00 00 ……
0008: 89 18 00 00 91 18 00 00 ……
This will resolve the repeated logging of the event ID 3006 entries to the Application Event Log.
There are two things I tend to see a lot of at the moment. Firstly virtualisation is pretty hot right now. Everyone seems to be virtualising their infrastructure as much as possible, particularly their servers such as Domain Controllers. Secondly, some companies are too cheap (or just haven’t gotten around to it yet) to setup a proper backup and recovery solution for their servers. This often means they are relying on some ad-hoc Ghost or Acronis images for server recovery. This includes recovery of their Domain Controllers.
I specifically mention Domain Controllers twice there because both of these very common scenarios introduce the serious risk of a “USN rollback” condition occurring (USN stands for “update sequence number”). If you want to get deeply technical with the concept you can read this article from Microsoft:
How to detect and recover from a USN rollback in Windows Server 2003
If you just want the summary version, basically a USN rollback condition can occur when the Active Directory database is restored to an earlier version in an improper fashion. Microsoft makes available methods for restoring Active Directory databases such that the Domain Controller can properly resynchronise with its replication partners afterwards. Restoring in an improper fashion, such as restoring a DC using an earlier Ghost or Acronis image, or rolling back to an earlier snapshot of a virtualised DC, will cause a USN rollback condition to occur.
Read the rest of this article…
I was out at a customer site on the weekend setting up their new computer. Should be no problems at all as it was the same Dell model as one they had purchased a few months before, and I had taken the time to create a RIS image when I built that first one.Having used different disk imaging tools over the years I’d never had a problem with disk sizes, as long as the image was smaller than the disk you were putting it on. So for example a Ghost image made with a 60Gb disk would happily load onto a 20Gb disk as long as the actual data was less than 20Gb.
This is not the case with RIS, as many have found out before me it seems. If you create a RIS image on say a 160Gb disk (because Dell was running a special that day) and then later try to apply that RIS image to an 80Gb disk, you receive an error documented here. There are a couple of causes of this problem, the applicable one in this case was (in Microsoft’s words):
The hard disk on the source computer is larger than the hard disk on the destination computer. The disk volume information is contained in the Imirror.dat file during the creation of the RIS image, and is stored on the RIS server for that image.
Bingo, I thought. The exact problem I’m having, lets see the solution…
Re-create the RIS image on a smaller hard disk.
Install a larger hard disk on the destination computer. The hard disk must be as large as or larger than the hard disk in the source computer.
Ah… thats no help. I don’t have a larger disk available to install, and I don’t really want to have to go through the process of reinstalling Windows XP from scratch to create a new RIS image when I have a perfectly good one already on the server.
Google to the rescue. The Microsoft article mentioned the IMirror.dat file, so searching for “imirror.dat” I came across Bart De Smet’s blog where he has documented a simple solution. In his case he suggests starting a RIS upload from a computer with a smaller disk, just long enough for the IMirror.dat file to be created, and then snagging that file and copying it into the source of the RIS image you want to install. Fortunately in my case I had RIS images for older hardware models on the server as well, that had smaller disk in them when the images were created.
So it was a simple matter to grab the IMirror.dat file from one of those, copy it over to the image I wanted to install, and start the RIS install again. This worked great, and got me out of the woods on this problem.
While the image was installing I looked around for a bit more information on the topic and found this forum thread (and here is a Google Cache link in case it won’t load). Johan Arwidmark describes how to use WinHex to edit the values in the IMirror.dat file that contain the disk size information. I downloaded WinHex and opened the file and saw the values he referred to. Comparing those to the values in the IMirror.dat for a smaller image I modified them to match and retested the RIS load. This method worked perfectly as well.
So there you have it, two methods of applying the same solution to the problem of trying to load a RIS image on a smaller disk than it was created on.
