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.

About the Author

Paul Cunningham

Paul is a former Microsoft MVP for Office Apps and Services. He works as a consultant, writer, and trainer specializing in Office 365 and Exchange Server. Paul no longer writes for Practical365.com.

Comments

  1. Rudy

    Thanks for the headsup, this solution has come in really helpfull. This has saved me hours of work, glad to know people out there know this stuff better than me!

  2. chris scott

    thanks for this link, it came up in google and saved many hours of work doing another ris install. keep blogging, even though you don’t see that many readers, we are here 😉 and google to the rescue again!

Leave a Reply