Jump to content

Wim files not working


Recommended Posts

Hi folks!

Not sure what to call this thread :rolleyes:

I have a problem and don't know what is happening....

I have tried a couple of times now to restart my computer after applying a wim file and it just hangs....??

I have done this so many times I am sure I could do it in my sleep.....lol

I install my computer and update it and then add all my software (not antivirus software) and then create a wim file of the installation...

nothing special with that....

Usually after restarting the computer I run repair to make sure boot info is working...

I then can log in to Windows without any problems...., but for some reason it goes to setting up the computer and a window pops up and says the computer needs to be restarted....The thing is the whole screen is blue and I have a " This copy of windows is not genuine" and that is all I get....?!

I have never experienced anything like this before....

I now have restarted as instructed and it just goes to a light blue screen and hangs there.

I dont get any errors when creating the wims either...

The hard drives are not showing any errors either and they aren't that old any way...

Has anyone any ideas?

bookie32

Link to comment
Share on other sites


Hi mate :thumbup

Long time no see...lol

Well, I have a retail Windows 7 Ultimate and I installed it on a drive and updated etc...captured a wim and deployed it to another drive.

I am not sure if I have actually done that before, but from what I have been reading that is a common problem...Windows 7.

Just about to test that theory...will get back to you on that...if it is true - then this is a big problem for me...

bookie32

Link to comment
Share on other sites

Hi again!

Well, that seems to be the case and it stinks!!

Microsoft need to get their act to gether and sort this...

Many are like me and create a wim without sysprepping because of the limitations of sysprep...

It is my Windows 7 Ultimate and I paid a lot when it came out...

So, at the moment I can't capture an image as a wim and put it on another drive on the same computer?!

Let us look at the logic of that....no logic....lol

Let's face it...the drive you have now might not be around in a couple of years and you need to use a large one etc...

I don't want to have to reinstall everything just because Windows is fixated with the information taken from the original drive when creating the wim file....?!

Can't believe I am the only one that thinks this is plain madness...

Well, I will have to be a bit more careful untill Microsoft deal with this problem...

bookie32

Link to comment
Share on other sites

Hi Tripredacus :blushing:

OK! I have just woken up....lol

While I can understand that many are complaining of the problems with deploying to another hard drive when you haven't run sysprep (including me)...which I found out - one forgets the ****** obvious and do exactly what you said...run sysprep and avoid the problems of a different computer or drive....

I do hope I am right in saying that I can deploy to a different size hard drive after using sysprep?

If that is the case - then that solves my problem for the time being...lol

bookie32

Link to comment
Share on other sites

WIM files contain no partition or filesystem information - as long as the destination partition or drive contains enough space to hold the contents of the WIM (aka the drive is not smaller than the data in the WIM), you can put a WIM file onto any size drive or partition. 2TB max partition (and disk) size for an MBR disk, and 256TB partitions (18EB disk size) for a GPT disk - those are Windows' artificial limitations.

Link to comment
Share on other sites

Hi cluberti :hello:

Nice to hear from you....

to be quite honest I hadn't given much thought to what size of drive or even make of drive I deploy my wims to...That said a lot of people are getting the same errors coming up and that makes you wonder a little.

I had created a wim on a wd black 500GB drive and tried to deploy that to a wd blue 320GB drive and it would not take?

I then installed everything on the 320GB drive created my wim and tried to then deploy it to the 500GB drive and the same error.

Because I had cleaned the 500GB drive I thought...what the hell I will try to reinstate the original wim from the 500BG drive and see what gives... and it worked?

Hence my post to say it worked after fixing boot as normal?

I have since tried again to deploy to the 320GB drive and the same error occurs?

What is the cause of this then?

bookie32

Link to comment
Share on other sites

Hi Mate

Can't account for why this has been giving me a headache today.....already had one when I got up this morning....lol

I agree with what you are saying, but it has been a pain...

Thanks for stopping by

bookie32

Link to comment
Share on other sites

Have you tried using sysprep and hen create the wim and deploy to both HDs to see what results you get? It seems as if the drive change is being interpreted as hardware change (and perhaps incompatible hardware).

Another issue might be the bootsector on the HDs and the bcd store. You might want to look at the bcd store configuration and edit it manually, and perhaps also apply the bootsect /nt60 /s <drive:> command to update MBR code. Also check out the status of your HD and partitions. The disk (or partition) where you apply/extract your WIM file needs to be the Active disk/partition. Since you have 2 HDs, the boot order may be causing issues in determining the OS drive/boot drive (BIOS boot order???), or some problem along those lines of thought....

Other ideas you can try/test out:

1. you can create a small boot partition (say 500 mb or so) on one specfic HD which is to be set as Active, and to only contain the bootmgr and the bcd store. Don't make any changes to that partition. Make your installation of win 7 on another partition or disk which will contain the OS and apps except the bootmgr and the bcdstore (which will be loacted at the designated small partition!) Create a WIM and deploy the wim to another HD or partition and see what happens?

2. if you are using win 7 ultimate (or enterprise), then you can install win 7 to a VHD, and create a wim from the vhd. Then you can test if the wim could be deployed to either of the HDs. I know that you can just move the vhd from one physical disk (partiton) to another, and only need to edit the reference to the location of VHD file in the bcd store to get it working, but it will be interesting to see if the wim file (of a VHD) can be deployed to either of the disks with minimal issues/problems.

Edited by daremo
Link to comment
Share on other sites

and perhaps also apply the bootsect /nt60 /s <drive:> command to update MBR code.

For the record, that command WILL NOT update the MBR code, it will update the bootsector or PBR one, you need to have the Windows 7 version of bootsect.exe and add the switch /mbr to it to modify the MBR code.

The original article:

http://technet.microsoft.com/en-US/library/49ded4da-b66f-4b42-9563-04c218a1a6ac.aspx

Bootsect.exe updates the master boot code for hard disk partitions to switch between BOOTMGR and NTLDR. You can use this tool to restore the boot sector on your computer.

leads to confusion.

The Windows 7 version has the added /mbr switch:

http://technet.microsoft.com/en-us/library/dd744577(v=ws.10).aspx

Updates the master boot record without changing the partition table on sector 0 of the disk that contains the partition specified by SYS, ALL, or <drive letter>. When used with the /nt52 option, the master boot record is compatible with operating systems older than Windows Vista. When used with the /nt60 option, the master boot record is compatible with Windows® 7, Windows Vista, Windows Server® 2008 or Windows Server® 2008 R2.

jaclaz

Link to comment
Share on other sites

Thank you, Jaclaz, for the corrections and clarifications over MBR/PBR.

It is unfortunate that so many companies are using terminology in an ambiguous manner (even using words interchangably and wrongly), or use technical descriptions that are imprecise.

I have come across a good web-site on the subject of multi-boot and multi-boot process that deal with Windows and other boot managers and the details of booting (theoretical/practical) and HD boot sector/MBR, etc. which I hope would be of some use to us to get a better understanding, especially, in the light of your corrections:

Boot and MultiBooting (as related Windows XP, Vista booting, and details of multibooting the 2 different types of Windows booting - ntldr and bootmgr)

Link to comment
Share on other sites

Woohoo... I know the answer to this problem!

Sorry, I have gailned tons, and tons of knowledge from this forum and it is nice to be able to give back :-P

Your problem is the BCD store you are restoring does not understand what is on the drive, this happens 100% of the time when I restore a WIM to a new drive.

I'm going to start at the beginning, I apologize if I go over things that you already know.

Assuming you boot into WinPE, are using Diskpart to configure your partitions, and the disk you are applying the image to is Disk 0 use the following diskpart commands to prepare the drive:

(Please Note, I am creating two partitions, the first one is the "system recovery" partition that Win7 makes during a normal install, the second is the OS partition. If you don't have an OS partition just omit the SIZE parameter from the partition creation command and ignore the creation of the second partition.)


diskpart
select disk 0
clean
create partition primary align=2048 size=100
active
format fs=ntfs quick
assign letter=c

create partition primary
format fs=ntfs quick
assign letter=d

exit

The commands will clean the drive (BEWARE this will destroy all data on the drive), create the 100 MB System Restore Partition (increase the size if you like, I use a 10 GB partition and store a restore WIM on it myself) make the parition bootable, format it as NTFS and assign a letter to it. It will also assign the remaning space to a second partition and assign it to drive letter D.

At this point, you need to restore your WIM. WIM files are not "system images" they are an image of the files, file structure, and the permissions associated with them. This is important as it allows you to restore to drives smaller than the origional, but also means you have additional maintenence to complete after restoring an image.

Assuming the system restore image was restored to the C drive, and the OS was restored to the D drive we need to edit the BCD store to tell the booloader how to load the OS.

The BCD store is located on the C drive... the system restore partition.

To enumerate the BCD store on the C drive you will need to use the following command:

bcdedit /store C:\Boot\BCD

This will give you a display of the BCD store as it sits currently. It is in a broken state, we need to repaire two entries, the device and osdevice.

We will be pointing both the device and osdevice to the D dive if the system restore partition was restored, if there is only one partition on the drive change the following commands to point ot C:


bcdedit /store C:\boot\bcd /set {default} device partition=D:
bcdedit /store C:\boot\bcd /set {default} osdevice partition=D:

The BCD will now know to run winload from the D drive (D is relational to the partiion order the BCD and bootloader sees, not what is displayed in Windows).

You should be able to reboot and load up Windows :-)

You can use the bootrec command to scan for the os and automatically rebuild the BCD store... you will have to do this if you did not get the BCD store in the intial WIM creation (unless you want to build it from scratch, line by line).

The problem with bootrec is that it is hard to script properly, the two lines above are easy to scritpt and have served me very well.

I hope this helps, please let me know if you have any quesitons. I will try to get back in a timely fashion.

Link to comment
Share on other sites

Assuming the system restore image was restored to the C drive, and the OS was restored to the D drive we need to edit the BCD store to tell the booloader how to load the OS.

The BCD store is located on the C drive... the system restore partition.

To enumerate the BCD store on the C drive you will need to use the following command:

bcdedit /store C:\Boot\BCD

This will give you a display of the BCD store as it sits currently. It is in a broken state, we need to repaire two entries, the device and osdevice.

We will be pointing both the device and osdevice to the D dive if the system restore partition was restored, if there is only one partition on the drive change the following commands to point ot C:


bcdedit /store C:\boot\bcd /set {default} device partition=D:
bcdedit /store C:\boot\bcd /set {default} osdevice partition=D:

The BCD will now know to run winload from the D drive (D is relational to the partiion order the BCD and bootloader sees, not what is displayed in Windows).

You should be able to reboot and load up Windows :-)

You can use the bootrec command to scan for the os and automatically rebuild the BCD store... you will have to do this if you did not get the BCD store in the intial WIM creation (unless you want to build it from scratch, line by line).

The problem with bootrec is that it is hard to script properly, the two lines above are easy to scritpt and have served me very well.

I hope this helps, please let me know if you have any quesitons. I will try to get back in a timely fashion.

I am pretty sure the original post mentioned that after a wim file is applied to a drive, the user has also run repair operation which usually scans and fixes the BCD store issues. So, yes, editing BCD store manualllyor running repair (or booting with original win 7 DVD and choosing repair int he install screen) should fix the problem, but it user complains about blue screen + Non Genuine Windows message.

Sooo... what is exactly going on and after doing the following:

1. create wim

2. deploy wim to another drive

how can you get the system working from the new drive without issues (and solve the issues that arise?)

I think sysprep is a necessity. I also remember (though I am not sure 100% where I have seen/read it but possibly at MS technet) that wim cannot be used as a sort of backup to restore a system...

Link to comment
Share on other sites

A WIM can most definitely be used to backup and restore a system. This is the primary restore method we use for deploying our customized gold images to terminals.

WIMs are very versatile, have many deployment options, and can be maintained offline... just to name a few advantages.

The WIM capture process does not affect activation in any way, when booting into Windows, the OS will verify activation information... information from various hardware components will be used to verify validity of the activation. Some items queried are: parts of the BIOS, MAC address of the first network adapter found, and information from the firmware of the HD (that is not a complete list of items, just a few). There is a threshold that Windows has for changes to the core hardware... if only a MAC changes then you typically don't need to re-activate... if a mainboard changes and the BIOS information does not match, then you most likely will need to reactivate the product. If you are applying the WIM to different hardware, then it is possible that this threshold is being broken and that is why the issue with WGA is appearing.

A few questions about your setup...

Are you applying the WIM to a different set of hardware than it was created on?

Do you standardize your Hardware with a particular vendor... Dell. HP, etc... ?

Are there any massstorage driver changes between the WIM creation system and the WIM deployment system?

Are any of the systems (source or destination) you are using setup as a RAID array?

We use only Dell and NCR hardware in our organization so we don't have to worry about activation as the SLP keys and the BIOS licenses take care of that for us. But moving WIMs between VMs and physical machines caused a small setback. We got around it by using SysPrep with a custom answer file and without the Generalize option. This allowed us to reactivate the software but not change the configuration of the image as we moved them between physical and virtual machines.

Another idea would be to service the WIM offline using DISM and inject the latest massstorage drivers for the machine you are deploying to. I had some issue with the DELL PERC S100 drivers that caused machines to blue-screen after restored using a WIM when the destination was a RAID 1 array. Dell resolved it in a driver update and it has worked great since.

Have you checked out Windows 7 driverpacks from driverpacks.net? I use those on WIMs that will need to support a wide variety of hardware. I inject the entire set of massstorage and LAN driverpacks which allow me to deploy to almost any hardware platform.

The last option I can think of right now is a Sysprep with a generalize and a custom answerfile with your key and the settings to rearm the activation period. This would be done before the WIM was taken... one nice thing about this process is that you can use the copy profile setting to make all the custom settings configured on the profile that run Sysprep the default profile in the deployed image. Then whenever you deploy the image you can enter audit mode at the username prompt by hitting CTRL + SHIFT + F3. This will allow you to deploy the WIM, make your needed changes in audit mode, reboot and pull a new WIM, then automatically enter the deployment screen after deployment. Windows will not re-arm the activation until the oobe has executed so you can audit the image many, many times without the worry of having to rearm each time.

I hope some of those ideas help.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...