Exchange Server Pro » Server 2003

MS08-037 causes port conflicts with DNS and IAS services

Paul Cunningham — Wed, 28 Jan 2009 01:32:52 +0000

You may encounter an issue with servers running both the DNS and IAS services that have installed update MS08-037 (Vulnerabilities in DNS could allow spoofing – 953230). The IAS services will fail to start and any authentication that relies on IAS (such as VPNs) will fail.

When connecting to the IAS server with the IAS management console the following errors may appear:

Event ID 7023 will appear in the System event log of the IAS server.

Event Type:    Error
Event Source:    Service Control Manager
Event Category:    None
Event ID:    7023
Date:        28/01/2009
Time:        9:15:17 AM
User:        N/A
Computer:    SERVER
Description:

The Internet Authentication Service service terminated with the following error:

Only one usage of each sock address (protocol/network address/port) is normally permitted.

The cause of the issue is explained in KB956188:

You experience issues with UDP-dependent network services after you install DNS Server service security update 953230 (MS08-037)

This issue occurs because the service cannot obtain the port that it requires to function correctly. This issue occurs because of changes to the port allocation in the DNS Service after security update 953230 is installed.

Read full article

The solution is to reserve the IAS ports from the ephemeral port range to ensure that the DNS Server service does not dynamically allocate those ports to itself. To determine which ports are being used by IAS open the IAS management console, right-click the server name and select Properties.

Navigate to the Ports tab and note the port numbers in use.

Follow the instructions in KB812873 (How to reserve a range of ephemeral ports on a computer that is running Windows Server 2003) and enter the correct ports in the registry key like this.

The server must be restarted for the change to take effect. After the restart the DNS Server will no longer allocate the IAS ports to itself, which will allow IAS to start properly.

Get more Exchange Server tips at ExchangeServerPro.com

Microsoft Certification – The Mark Russinovich Exam

Paul Cunningham — Wed, 30 Jul 2008 20:00:55 +0000

Microsoft has released information for exam 70-660, TS: Windows Internals. This might be an odd sounding title to anyone who has never heard of Mark Russinovich or Sysinternals. From the MS Learning site:

This exam validates deep technical skills in the area of Windows Internals. Including troubleshooting operating systems that are not performing as expected or applications that are not working correctly, identifying code defects, and developing and debugging applications that run unmanaged code or that are tightly integrated with the operating system, such as Microsoft SQL Server, third party applications, antivirus software, and device drivers.

If that makes little sense take a look at Mark’s blog on Technet and you’ll see the type and depth of content they are talking about.

Candidates for this exam are engineers, developers, or IT staff who work with Windows at a level that requires Windows Internals knowledge. Candidates for this exam are typically in the upper echelon of the technical staff at their companies. These individuals typically hold such positions as escalation engineer, technical lead, and software design engineer. Their level of knowledge spans products both inside and outside the Microsoft Corporation. These individuals are involved in resolving problems that require deep understanding of Windows Internals rather than problems about planning and infrastructure development or how to use or configure a product that runs on Windows.

Sounds like a pretty tough exam, and the preparation looks even tougher. Though the exam is (apparently) available from October 10th this year, currently the preparation materials listed are as follows:

Classroom Training – There is no classroom training currently available.
Microsoft E-Learning – There is no Microsoft E-Learning training currently available.
Microsoft Press Books – There are no Microsoft Press books currently available.
Practice Tests – There are no practice tests currently available.

So that makes preparing for a tough exam pretty difficult. But its a pretty safe bet that the exam is going to cover the topics listed in Mark’s two books, Windows Internals 4th Edition (for 2000, XP, and 2003) and Windows Internals 5th Edition (for Vista and 2008).

Get more Exchange Server tips at ExchangeServerPro.com

Slipstreaming Service Pack 2 into your Windows Server 2003 R2 media

Paul Cunningham — Tue, 19 Feb 2008 01:59:15 +0000

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

Get more Exchange Server tips at ExchangeServerPro.com

Recovering a single Domain Controller from a USN Rollback

Paul Cunningham — Thu, 07 Feb 2008 11:58:02 +0000

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.

Get more Exchange Server tips at ExchangeServerPro.com

Event ID 3006 and Exchange Server 2007 performance counters

Paul Cunningham — Mon, 10 Sep 2007 09:10:34 +0000

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.

Get more Exchange Server tips at ExchangeServerPro.com

Event ID 2095 and The USN Rollback Adventure

Paul Cunningham — Fri, 01 Jun 2007 14:15:18 +0000

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.

A Simple USN Rollback Scenario

You can create a USN rollback condition by deliberately performing one of the restoration methods mentioned above. Here I have created two virtualised Domain Controllers named TESTDC1 and TESTDC2, both in the testing.local domain. Looking at the servers I can see that they appear to be in a healthy state of replication. Active Directory Users and Computers shows the same user objects that I created have replicated between the servers.

Replmon.exe indicates successful replication is occurring.

Running DCDiag.exe /q (the /q switch suppresses all output except for errors, so if there is no output there is no errors) indicates all is well.

Next I shut down TESTDC2 and make a copy of the virtual hard disk. I then boot TESTDC2 again, and confirm once more that replication is healthy. I can then make a few changes to Active Directory to demonstrate the problems with USN rollback. Using the Active Directory Users and Computers console I create the user object User3 while connected to TESTDC1, and the user object User4 while connected to TESTDC2. As you can see here the user objects appear in the Active Directory of the Domain Controllers, but are yet to replicate between the two servers.

In a real world environment some event might occur such as a hardware failure on TESTDC2, or simply a human decision to roll the server back to the last image or snapshot. I shut down TESTDC2, remove the current virtual hard disk, and copy back the virtual hard disk file from before. As soon as I boot TESTDC2 again everything starts to go bad.

Administrators might first become aware of the problem when they notice that changes they make in the course of their day are not replicating to all the domain controllers. For example, I notice that User3 is appearing on TESTDC1 but not on TESTDC2, even after several hours of waiting. If I attempt to force replication between the two servers in Active Directory Sites and Services I receive an error. A similar error is also now appearing in Replmon, and the Directory Services Event log is showing some critical errors.

The event ID to look out for in this scenario is 2095. The full details of this event are as follows.

Event Type: Error
Event Source: NTDS Replication
Event Category: Replication
Event ID: 2095
Date: 1/06/2007
Time: 4:40:20 PM
User: NT AUTHORITY\ANONYMOUS LOGON
Computer: TESTDC2
Description:
During an Active Directory replication request, the local domain controller (DC) identified a remote DC which has received replication data from the local DC using already-acknowledged USN tracking numbers.

Because the remote DC believes it is has a more up-to-date Active Directory database than the local DC, the remote DC will not apply future changes to its copy of the Active Directory database or replicate them to its direct and transitive replication partners that originate from this local DC.

If not resolved immediately, this scenario will result in inconsistencies in the Active Directory databases of this source DC and one or more direct and transitive replication partners. Specifically the consistency of users, computers and trust relationships, their passwords, security groups, security group memberships and other Active Directory configuration data may vary, affecting the ability to log on, find objects of interest and perform other critical operations.

To determine if this misconfiguration exists, query this event ID using http://support.microsoft.com or contact your Microsoft product support.

The most probable cause of this situation is the improper restore of Active Directory on the local domain controller.

User Actions:
If this situation occurred because of an improper or unintended restore, forcibly demote the DC.

Remote DC:
d63ef566-f3a9-4700-ae27-a5c5ac7c9fe0
Partition:
DC=testing,DC=local
USN reported by Remote DC:
16435
USN reported by Local DC:
16387
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

There are also instances of event ID 2013.

Event Type: Error
Event Source: NTDS General
Event Category: Service Control
Event ID: 2103
Date: 1/06/2007
Time: 4:40:20 PM
User: NT AUTHORITY\ANONYMOUS LOGON
Computer: TESTDC2
Description:
The Active Directory database has been restored using an unsupported restoration procedure.

Active Directory will be unable to log on users while this condition persists. As a result, the Net Logon service has paused.

User Action
See previous event logs for details.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

You definitely want to know about these errors when they occur. If you are running any kind of monitoring system that scrapes event logs and alerts you for certain events then these are two you want to be alerted for. If you are not paying attention this problem can surface and go unnoticed for quite some time. Your admins might just be scratching their heads a little as to why some odd behaviour is occurring in Active Directory. Meanwhile your server event logs are overwriting older events and may remove this crucial evidence, as happened to a customer of ours.

If you do not have the benefit of seeing those events in the Directory Services Event Log there are some other clues you can look out for. Firstly the repadmin.exe command can help identify the state of replication on the Domain Controller.

C:\>repadmin /options repadmin running command /options against server localhost Current DC Options: (none)

If the output is as above, then replication is not explicitly disabled on the Domain Controller. Note that a Global Catalog server will show an “IS_GC” option as being active instead of “(none)”. However if the output is as follows then replication has been disabled on the Domain Controller.

C:\>repadmin /options repadmin running command /options against server localhost Current DC Options: DISABLE_INBOUND_REPL DISABLE_OUTBOUND_REPL

More evidence is if the NetLogon service is in a “paused” state on the Domain Controller.

C:\>sc query netlogon SERVICE_NAME: netlogon TYPE : 20 WIN32_SHARE_PROCESS STATE : 7 PAUSED (STOPPABLE, PAUSABLE, IGNORES_SHUTDOWN)) WIN32_EXIT_CODE : 0 (0x0) SERVICE_EXIT_CODE : 0 (0x0) CHECKPOINT : 0x0 WAIT_HINT : 0x0

If you attempt to restart NetLogon and re-enable replication with Repadmin while the USN rollback condition is still in effect then the event IDs 2095 and 2013 will appear again in the Directory Services Event Log, which gives you further evidence of the issue. The final clue is by checking the USN that each Domain Controller believes is correct for itself and its replication partners.

On TESTDC1:
C:\>repadmin /showutdvec testdc1 dc=testing,dc=local Caching GUIDs. .. Default-First-Site-Name\TESTDC2 @ USN 16435 @ Time 2007-06-01 16:37:49 Default-First-Site-Name\TESTDC1 @ USN 14272 @ Time 2007-06-01 16:52:08

On TESTDC2:
C:\>repadmin /showutdvec testdc2 dc=testing,dc=local Caching GUIDs. .. Default-First-Site-Name\TESTDC2 @ USN 16409 @ Time 2007-06-01 16:52:49 Default-First-Site-Name\TESTDC1 @ USN 14146 @ Time 2007-06-01 16:04:22

The condition you are looking for is if the direct replication partners have a higher USN for the Domain Controller than the Domain Controller has for itself. In the above output you can see that TESTDC2 has a USN for itself of 16409, whereas TESTDC1 has an USN for TESTDC2 of 16435.

More Complex USN Rollback Scenarios

In the simple scenario above is it relatively easy to conclude that TESTDC2 is the cause of the USN rollback condition occuring. However in an environment with more than two Domain Controllers the evidence can present in different ways. Using the example of our customer, the virtualised Domain Controller that had been rolled back to an earlier snapshot was not showing event ID 2095, its NetLogon service was running, and it did not have inbound and outbound replication disabled. However both of its replication partners were showing those symptoms.

By analysing the USN numbers in the output of the “repadmin /showutdvec” commands on each Domain Controller it was ultimately shown that the virtualised Domain Controller was still the one causing the USN rollback condition.

Because of this type of variance in the real world it is important to investigate the situation carefully and assess all of the available information before making a decision as to how to proceed with resolving the issue.

Recovering from a USN Rollback

The Microsoft article mentioned at the start of this post contains instructions as to how to recover from USN rollbacks.

1. Remove Active Directory from the server causing the USN rollback condition. If you try to run DCPromo.exe on the server you will receive an error.

In order to demote the server you need to run DCPromo.exe with the /forceremoval switch. This is a last resort option for removing a Domain Controller when it cannot be removed by the conventional method.

2. Shut down the demoted server.

3. On a healthy Domain Controller, clean up the metadata of the demoted Domain Controller. This is explained in detail in this Microsoft article.

How to remove data in Active Directory after an unsuccessful domain controller demotion

The enhanced NTDSUtil application in Windows Server 2003 SP1 and above allows you to remove the metadata.
C:\>ntdsutil ntdsutil: metadata cleanup metadata cleanup: connections server connections: connect to server testdc1 Binding to testdc1 ... Connected to testdc1 using credentials of locally logged on user. server connections: quit metadata cleanup: select operation target select operation target: list domains Found 1 domain(s) 0 - DC=testing,DC=local select operation target: select domain 0 No current site Domain - DC=testing,DC=local No current server No current Naming Context select operation target: list sites Found 1 site(s) 0 - CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=testing,DC=local select operation target: select site 0 Site - CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=testing,DC=local Domain - DC=testing,DC=local No current server No current Naming Context select operation target: list servers in site Found 2 server(s) 0 - CN=TESTDC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,D C=testing,DC=local 1 - CN=TESTDC2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,D C=testing,DC=local select operation target: select server 1 Site - CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=testing,DC=local Domain - DC=testing,DC=local Server - CN=TESTDC2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configurat ion,DC=testing,DC=local DSA object - CN=NTDS Settings,CN=TESTDC2,CN=Servers,CN=Default-First-Sit e-Name,CN=Sites,CN=Configuration,DC=testing,DC=local DNS host name - TESTDC2.testing.local Computer object - CN=TESTDC2,OU=Domain Controllers,DC=testing,DC=local No current Naming Context select operation target: quit metadata cleanup: remove selected server Transferring / Seizing FSMO roles off the selected server. Removing FRS metadata for the selected server. Searching for FRS members under "CN=TESTDC2,OU=Domain Controllers,DC=testing,DC= local". Deleting subtree under "CN=TESTDC2,OU=Domain Controllers,DC=testing,DC=local". The attempt to remove the FRS settings on CN=TESTDC2,CN=Servers,CN=Default-First -Site-Name,CN=Sites,CN=Configuration,DC=testing,DC=local failed because "Element not found."; metadata cleanup is continuing. "CN=TESTDC2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=t esting,DC=local" removed from server "testdc1" metadata cleanup: quit ntdsutil: quit Disconnecting from testdc1...

You must manually remove the records in the Forest and Domain DNS zones for the demoted Domain Controller, and remove if from the list of Name Servers for each of the zones.

Finally you must remove the demoted server from Active Directory Sites and Services.

4. If the demoted server held FSMO roles you can seize them with NTDSUtil.

Using Ntdsutil.exe to transfer or seize FSMO roles to a domain controller

5. Turn on the demoted server.

6. Promote the server to a Domain Controller again using DCPromo (if you wish it to have this role again).

7. If the server was a Global Catalog readd this role.

8. Restore FSMO roles to the server (if applicable).

9. Restore the System State (optional). This is only applicable if there was a previous, valid System State backup of the server from before the USN rollback condition occured in which there are Active Directory changes that you require to be restored.

Once the server is fully restored you can check that replication is occuring again with Replmon. You can also observe whether changes to the Active Directory are replicating properly by performing tests such as creating a new user object and waiting for it to replicate between servers.

Finally the Event Log, Repadmin output and the state of the NetLogon service of all of your Domain Controllers can be checked as well.

C:\>repadmin /options repadmin running command /options against server localhost Current DC Options: (none)

C:\>sc query netlogon SERVICE_NAME: netlogon TYPE : 20 WIN32_SHARE_PROCESS STATE : 4 RUNNING (STOPPABLE, PAUSABLE, IGNORES_SHUTDOWN)) WIN32_EXIT_CODE : 0 (0x0) SERVICE_EXIT_CODE : 0 (0x0) CHECKPOINT : 0x0 WAIT_HINT : 0x0

Once the recovery is complete you may not be out of the woods yet. As you may have noticed in the screenshots above the User4 object no longer exists in the Active Directory. This is because the object was never able to replicate outbound from TESTDC2 and was therefore lost when the server was forced demoted. You should be aware that aside from objects completely disappearing, some other strange issues may pop up after the recover, such as users reporting that their new password no longer works, but their old password does. In the case of our customer one of the Domain Controllers immediately threw some SAM errors into the Event Log due to a replication conflict for a particular computer account. As a result the computer account was deleted automatically by the Domain Controller, a change which then replicated across the network and required the computer in question to be rejoined to the domain.

As you can see the USN rollback condition is a very serious situation that threatens the integrity of your Active Directory environment. Aherence to proper backup and restore processes for your Active Directory, and caution when dealing with projects that involve virtualising Domain Controllers, can help you avoid this condition in your network. However if you do unfortunately experience this problem in your production environment, careful analysis of the evidence and a clear recovery process as demonstrated here can get your environment back into a healthy condition again.

Get more Exchange Server tips at ExchangeServerPro.com

Modifying RIS Images For Smaller Hard Disks

Paul Cunningham — Wed, 08 Nov 2006 00:57:28 +0000

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.

Get more Exchange Server tips at ExchangeServerPro.com

Exchange Server Pro » Server 2003

MS08-037 causes port conflicts with DNS and IAS services

Related posts:

Microsoft Certification – The Mark Russinovich Exam

Related posts:

Slipstreaming Service Pack 2 into your Windows Server 2003 R2 media

Related posts:

Recovering a single Domain Controller from a USN Rollback

!!!Warning!!! !!!Warning!!! !!!Warning!!!

Related posts:

Event ID 3006 and Exchange Server 2007 performance counters

Related posts:

Event ID 2095 and The USN Rollback Adventure

Related posts:

Modifying RIS Images For Smaller Hard Disks

Related posts: