Opinions and facts regarding Sysprep Windows XP
We use one standardized image at our organization for all of our machine deployments. A few of our techs want to take an image that has already been deployed and joined to our domain and add software to it, disjoin the domain and then resyprep the machine to use as an image to save time on the software loading from the network. I also add a version number for our images to identify different builds for troubleshooting potential issues with specific image builds in the future.
We're using Group Policy and Altiris to deploy all of our software. When the techs use this process they duplicate the Altiris GUID across multiple workstations and also duplicate the image build version identifier we use to identify the particular build of our images(which makes identifying the image build version no longer accurate for troubleshooting since the image has now been modified).
I build our image inside of a VM and do all of the OS customization using Group Policy, Altiris, and vbs startup scripts to keep the Windows XP OS as standardized as possible.
Does anyone here have any information or opinions or facts (specifially looking for hardcore facts to deter our techs from re-sysprepping machines) on why its not a good practice to clone a machine that has been previously deployed or to re-sysprep an image repeatedly?
Long story short, we have techs who won't believe that creating an image in an uncontrolled non standardized way can lead to problems with an image build later on down the road as time goes on. I've had problems with duplicated WSUS GUID's, Altiris Agent GUIDs and AutoDesk product licensing after cloning computers in the past.
Sorry for the long post...
We're using Group Policy and Altiris to deploy all of our software. When the techs use this process they duplicate the Altiris GUID across multiple workstations and also duplicate the image build version identifier we use to identify the particular build of our images(which makes identifying the image build version no longer accurate for troubleshooting since the image has now been modified).
I build our image inside of a VM and do all of the OS customization using Group Policy, Altiris, and vbs startup scripts to keep the Windows XP OS as standardized as possible.
Does anyone here have any information or opinions or facts (specifially looking for hardcore facts to deter our techs from re-sysprepping machines) on why its not a good practice to clone a machine that has been previously deployed or to re-sysprep an image repeatedly?
Long story short, we have techs who won't believe that creating an image in an uncontrolled non standardized way can lead to problems with an image build later on down the road as time goes on. I've had problems with duplicated WSUS GUID's, Altiris Agent GUIDs and AutoDesk product licensing after cloning computers in the past.
Sorry for the long post...
0 Comments
[ + ] Show comments
Answers (10)
Please log in to answer
Posted by:
squeakstar
14 years ago
dude - keep an un-sysprepped image and update that - then clone it and sysprep for deployment - this will save work and trouble down the line. can't think of sources for facts but I do remember the warnings whilst studying my certs not to re-sysprep!!!!
Posted by:
Sierra8
14 years ago
I do start with an un-sysprepped image everytime. No software loaded. Only thing I ever include are MS updates so our WSUS server doesn't throw down 100+ updates over time.
At work I've just been getting lots of questions as to why this approach is the best. To me it's obvious. There's a standardized process to create our baseimage that is documented and since our image is based off of an unsysprepped fresh Windows XP build we can usually rule out capturing a lot of unnecessary garbage in the image. Believe it or not this doesn't even register as a reason to not resysprep exisiting machines or images where I'm working to most of the tech folk so I was hoping to get some concrete reasons why resysprepping an image could cause issues such as capturing a unique SEP11 Anti-Virus computer identifier in the image after the AV client has loaded which causes all computers to appear as the same computer to the Symantec console and only show one computer in the console itself...etc etc. I've had problems with Altiris GUIDs duplicated stomping on other machines in the NS console, WSUS identifiers being duplicated in some cases and stomping on other workstations in the console etc....
Any really specific tech info I could arm myself with other than the obvious reasons (Especially information from MS)? (standardization, reliability, documented recreatable process, and image versioning to be able to identify an image once deployed in the event something does get captured into a particular image build and needs to be fixed in mass using vbs, Altiris, or GPO?
And yes...after reading this. I am the king of run on sentences :)
Thanks for any help or replies...
At work I've just been getting lots of questions as to why this approach is the best. To me it's obvious. There's a standardized process to create our baseimage that is documented and since our image is based off of an unsysprepped fresh Windows XP build we can usually rule out capturing a lot of unnecessary garbage in the image. Believe it or not this doesn't even register as a reason to not resysprep exisiting machines or images where I'm working to most of the tech folk so I was hoping to get some concrete reasons why resysprepping an image could cause issues such as capturing a unique SEP11 Anti-Virus computer identifier in the image after the AV client has loaded which causes all computers to appear as the same computer to the Symantec console and only show one computer in the console itself...etc etc. I've had problems with Altiris GUIDs duplicated stomping on other machines in the NS console, WSUS identifiers being duplicated in some cases and stomping on other workstations in the console etc....
Any really specific tech info I could arm myself with other than the obvious reasons (Especially information from MS)? (standardization, reliability, documented recreatable process, and image versioning to be able to identify an image once deployed in the event something does get captured into a particular image build and needs to be fixed in mass using vbs, Altiris, or GPO?
And yes...after reading this. I am the king of run on sentences :)
Thanks for any help or replies...
Posted by:
squeakstar
14 years ago
hey, i had a a quick google myself looking for something definitive saying you shouldn't re-sysprep a pc, but found little except experiences exactly as you describe. WSUS configuration IDs (WSUS doesn't do on SIDs by the way) don't get cleared by sysprep, and AV id's are also not within sysprep's remit to clear and reset.
Sysprep only really sets off the driver search on hardware upon the OS first launching post sysprep, and reset's SIDs when you run actually sysprep and seal the machine, maybe more than this really, but you get the idea sysprep is limited in what it can reset. Sysprep isn't going to know in advance all these other permutation of software that creates it's own ID for other consoles and administration software used to monitor clients.
I my self have once tried to shortcut the entire process, by just cloning a pc and running sysinternals newsid - but then i ran into all the same problems as you describe, duplicate WSUS IDs and stuff. actually i don't even sysprep our AV software as NOD32 didn't seem to like it a few years back and made the frontend look all badly skinned.
You're colleagues are doofuses, if the experience that happens in front of their very eyes is not proof enough as to sysprepping sysprepped machines is wrong. maybe you need to spell it out to them in a report, or continue to do it your way and let them sort out their own mess when they do it.
Sysprep only really sets off the driver search on hardware upon the OS first launching post sysprep, and reset's SIDs when you run actually sysprep and seal the machine, maybe more than this really, but you get the idea sysprep is limited in what it can reset. Sysprep isn't going to know in advance all these other permutation of software that creates it's own ID for other consoles and administration software used to monitor clients.
I my self have once tried to shortcut the entire process, by just cloning a pc and running sysinternals newsid - but then i ran into all the same problems as you describe, duplicate WSUS IDs and stuff. actually i don't even sysprep our AV software as NOD32 didn't seem to like it a few years back and made the frontend look all badly skinned.
You're colleagues are doofuses, if the experience that happens in front of their very eyes is not proof enough as to sysprepping sysprepped machines is wrong. maybe you need to spell it out to them in a report, or continue to do it your way and let them sort out their own mess when they do it.
Posted by:
squeakstar
14 years ago
here's some resources i've used in the past, aswell as MCP training on XP...
http://support.microsoft.com/kb/302577 - nuts and bolts on sysprerp
http://www.vernalex.com/guides/sysprep/ - excellent standalone flash tutorial to download with explanations as you go along, on this site as to what's doing what. The dude also priovides a free tool for applying drivers to your answer file!!!
http://support.microsoft.com/kb/302577 - nuts and bolts on sysprerp
http://www.vernalex.com/guides/sysprep/ - excellent standalone flash tutorial to download with explanations as you go along, on this site as to what's doing what. The dude also priovides a free tool for applying drivers to your answer file!!!
Posted by:
squeakstar
14 years ago
oh, just re-reading the vernalux site again was reminded of a kb as to what Microsoft officially supports:
http://support.microsoft.com/?id=828287
etc.... sock it to 'em!!!
http://support.microsoft.com/?id=828287
Sysprep is only supported on clean installations. This restriction also applies to in-place upgrades, such as Windows XP-to-Windows XP upgrades.
Microsoft does not support the use of Sysprep to create a new image of a Windows installation on a computer that has been running in a production role.
etc.... sock it to 'em!!!
Posted by:
anonymous_9363
14 years ago
I think what Matthew really means is keeping build candidates in VM snapshots, ready for SysPreping. You can then snapshot the release version once it's SysPrepped. At each stage, you then have a fall-back to return to, if it all goes TU. As you're no doubt aware, the beauty of VMWare is that you can keep as many snapshots as you want, disk space permitting.
Posted by:
squeakstar
14 years ago
er, well wasn't actually explaining anything along those lines - but that's what i do anyway (though in Hyper-V) and is the way to go to manage your images in an efficient manner - getting the right image prepared and sysprepped properly, as opposed to being a lazy sod and re-sysprepping a deployed client image!
Posted by:
Sierra8
14 years ago
Thanks for the replies. We're still using the standardized image process but it's a true test of will almost daily.
Sounds like everyone uses just about the same process nowadays. I've been using VMWare for the last few years to keep 3rd party drivers out of the master build. I think our current build is working on 19 different hardware platforms from desktops to laptops.
I'll just keep trucking along with our current process as usual until I either go insane from the daily "everyone has a better way" or finally hit the lotto and can retire to a place that has no electricity.
Sounds like everyone uses just about the same process nowadays. I've been using VMWare for the last few years to keep 3rd party drivers out of the master build. I think our current build is working on 19 different hardware platforms from desktops to laptops.
I'll just keep trucking along with our current process as usual until I either go insane from the daily "everyone has a better way" or finally hit the lotto and can retire to a place that has no electricity.
Posted by:
Sierra8
14 years ago
This link is exactly the kind of info I've been looking for.
http://support.microsoft.com/?id=828287
Thanks again...
http://support.microsoft.com/?id=828287
Thanks again...
Posted by:
squeakstar
14 years ago
Microsoft does not support the use of Sysprep to create a new image of a Windows installation on a computer that has been running in a production role.
importance of that above note is, and don't forget to stress, is if you need MS's support, they could just turn around and say "bugger off you're on your own"
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.