To SysPrep or Not, That is the Question.
-
At work, it is standard practice to install Windows 7 OS, 3rd party software, map some network drives, then image the system as-is. To be fair the deployment systems are identical hardware, with the only variation being wireless cards. Are these best practices? I feel as if critical steps are being missed. The network is rather simple, DHCP, no AD, or any other complications that I can think of. Feel free to ask for more information, as I really want to learn from the community here. I have read some articles and stack exchange threads which seem to be uncertain.
-
This question comes up from time to time on the forums.
Let me first say that I don’t sysprep. Everyone keeps telling me I need to, but I am doing just fine without it and I take care of 20+ models and have been involved with the imaging of over 4,000 individual computers with FOG, and without sysprep. This sort of endevor wouldn’t be possible without the FOG Client (kudos to @Joe-Schmitt for creating such an amazing tool), and without extensive FOG know-how. FOG can automate basically everything you need done post-imaging. Without FOG (or a tool with comparable features), you’d need a massive workforce to do that sort of endeavor, or a hodge-podge of software deployment methods. With fog, a one to two person team could do it - if you’re only talking about the imaging and configuration process.
You don’t have to use sys-prep. But there are environments and demands were it would be very helpful. There’s also environments and demands where it’d just be an un-needed extra step.
If you use an internal WSUS server, you might want to sysprep because there have been issues reported on the internet about duplicate clients in WSUS that causes problems. I’ve used WSUS without sysprep with Win7 Pro and have not had this issue, and WSUS got the job done.
Not sys-prepping has zero negative effect on the domain-joining process. If it did, I would absolutely have known about 6 years ago when I first started imaging using Norton Ghost. I am responsible for several large domains, none of the computers joined to them are sys-prepped and we don’t have issues concerning it.
If you use an internal KMS server for activation (and not MAK keys), you might want to sysprep or you will have an issue reaching the initial threshold for activating Windows and Office and such. The issue with this is that when each individual host makes a request to the KMS box for activation, it sends with it it’s SID too. For Windows and Office, there’s a unique request threshhold that must be reached before the KMS box will actually activate anything. I don’t sysprep and I have heavily used KMS at work. I got around the threshold issue by using a “charger” program that I found online, this application just sends a bunch of fake requests to the KMS box until the threshold is reached. Then all computers in the environment happily activate without issue. KMS boxes do not communicate with Microsoft after they are setup, so you have no issues there.
If you have more than maybe 5 models of hardware, you might want to consider sysprep for the purposes of making a hardware-independent image that has all the drivers and software it needs for the models you need to deploy to. I help with over 20 models of computers, and I don’t sysprep. We used to make an image per-model in the summertime for each model we have, and we’d just deploy that image out to those models. With the driver improvements in Win10 many here on the forums are reporting they don’t have to sysprep to take a Win10 image from one model and deploy it to a totally different model PC. I myself haven’t tried it yet but people here and my co-workers have and they said it works.
Another thing to consider is deployment times. Sysprepping does slow down the image deployment time, because it’s just extra stuff that has to be done to a host before it’s ready for the user to begin using. Often times this isn’t an issue, but it is a real thing, it does slow down deployment by a minute or more depending on what you’re doing in the unattend file.
My experience is real-world experience on an enterprise level. I consider myself to have a lot of imaging experience. Now, just because I’ve done all this stuff without issue and never sysprepping, that doesn’t mean that’s what is best for you.
You might want to sysprep so you can use an unattend.xml file to do all sorts of cool post-configuration inside of FOG’s postinstallscripts area like @george1421 does where he works. You might want to sysprep just so you don’t have to worry about WSUS issues or KMS server issues, you might want to sysprep so you are sure you won’t have driver issues. You might want to sysprep simply because Microsoft recommends you do it.
-
I sysprep because I create generic, or all purpose images. We get basically any model you can think of in here, so I can’t make hardware specific images.
It’s the only reason I use it though.
-
In your environment, based on what you posted, do you need to sysprep, no. As for best practices, do you want to sysprep yes.
In my environment we have a single image for all platforms so we do sysprep the base image and then inject the drivers using post install scripts. But we also have KMS, WSUS, and other software that relies on a unique system suid.
-
Many thanks to Wayne, your contribution to the topic demonstrated great breadth of knowledge. Summarily, I am elated to know that I do not have any bad habits to break it seems. I do however, need to research and experiment with the options that are provided for post imaging configuration.
-
@Wayne-Workman said in To SysPrep or Not, That is the Question.:
I don’t sysprep and I have heavily used KMS at work. I got around the threshold issue by using a “charger” program that I found online, this application just sends a bunch of fake requests to the KMS box until the threshold is reached. Then all computers in the environment happily activate without issue
In any case, this is definitely not the right way to do this.
If you’re not going to Sysprep and you are using KMS, you should be re-arming your Windows and Office installation immediately before capturing the image:
–Windows: slmgr -rearm
–Office: %OfficeProgramDirectory%\ospprearm.exe
