Need help resealing activated windows 7.

[esgaroth]

We are a small oem installing windows 7 and windows 8 on our desktop systems for our customers. We are using WDS and/or MDT to deploy our images to the system. After deployment to the target system I would like to be able to enter audit mode for final customization and software installations and then activate windows before resealing for the customer. Now the question of how to preserve activation while resealing with sysprep has come up many times. I should be able to enter the key into the unattend.xml file and set SkipRearm to 1 in the appropriate sections. Although I haven't gotten this to work yet I am left with another concern. This is a very manual step in an otherwise rather automatic solution. The unattend.xml file would have to be manually edited to enter the key. Manual steps are easily forgotten. Also most of our techs who are doing the actual deployment know little about sysprep. I need to keep this process as automated as possible. Does any one have another method that does not involve manually editing the unattend.xml file for each deployment?

[Tripredacus]

I never bothered. I've not heard any complaints from customers about having to type in the product key themselves and having to activate the PC.

[esgaroth]

Hmm, from my testing, I install windows 7 from the dvd or our deployment server and then enter audit mode and activate. Then reseal with sysprep.exe /oobe /shutdown. Upon starting up windows will ask me for a product key.

Do you have nothing in your unattend.xml to retain the product key? Do you use /generalize with sysprep before sending to the customer?

[Tripredacus]

On a standard system I do not use an answer file with sysprep, and never with the OEM System Builder kit OS. Only time I use an XML is for a custom setup. I store generalized images on the deployment server.

Typical image creation method:

- deploy OS from DVD using answer file specifying install key and Audit Mode.

- sysprep /generalize /audit /shutdown

- capture image

- add drivers and updates (DISM)

- deploy image (it would boot to audit mode)

- verify drivers, then sysprep /oobe /shutdown

- ship

NOTE: I do not use MDT.

[esgaroth]

Well that sounds like what I would like to happen. Although every time I try windows asks me for the product key after running sysprep /oobe /shutdown

What type of licenses are you deploying? Just normal oem home/pro? I assume you are entering the activation product code during the final audit mode just before the last sysprep?

[Tripredacus]

See the thing is, using OEM System Builder Kit, you aren't allowed to accept the EULA as an OEM. So there is no reason why you would ever boot the system after sysprep /oobe /shutdown. Notice in my generic workflow says "ship" as in "ship the PC to customer" after that step. But yes, it asks for the product key if you go through OOBE. For testing purposes I may go through this process (to verify if sysprep removes drivers) but never enter a product key or activate the OS.

An image can safely operate in Audit Mode and not activated for up to 30 days. So as long as your production process isn't that slow, you should be fine with not activating it for the end user.

Now also understand this, I know it is allowed for an OEM to pre-activate an OEM System Builder Kit image before shipping, so this isn't a licensing thing. I am just offering an alternative. If you require specific information on how to pre-activate the OS, you can definately find that information online, if not this site. However I would recommend that you contact your Microsoft Account Manager to request the officially supported walkthroughs and best practices guides on this topic. This information is not covered in the OPK documentation for Windows 7.

[esgaroth]

I don't intend to be booting up these machines after running sysprep. I'm only doing so now to test the end user out of box experience. As it is now the customer would have to enter the product key. I don't expect that any of them would see that screen and have any idea what to do.

I figured that most documentation would be here or on technet but I may contact our Microsoft rep as well if need be.