Sysprep Removing Device Drivers

In a recent, Mark Russinovich wrote about the implications of having duplicate machine Security Identifiers (machine SIDs). As it turns out, there are likely very few situations where having duplicate machine SIDs causes issues. Unfortunately, some have gotten the mistaken impression that the discontinuation of NewSID means that nothing needs to be done to prepare an installation of Windows for imaging.

(Mark even specifically states that otherwise.) Microsoft Knowledge Base article may also leave this impression since the beginning of the MORE INFORMATION section focuses solely on duplicate SIDs. (I will be pushing our Support folks to clarify this.) As I will show, the real “myth” is the idea that changing the SID is the only thing that needs to be done to prepare Windows for cloning. It is true that one of the reasons we do not support the use of tools other than Sysprep is because these other tools don’t necessarily know about all the places where Windows stashes away references to the machine SID. However, the main reason is that Sysprep does much more than reset the SID. Even as far back as Windows NT 4.0, Sysprep has been used to enable a two stage process for deployment.

The first stage was actually running Sysprep. This would prepare the operating system to be duplicated.

The next stage, Mini-Setup, would run to change the operating system in such a way that it would act as a new, unique installation of Windows. These stages are now named “generalize” and “specialize” respectively in Windows Vista and higher operating systems. To simplify things, I will refer to this two stage process as the duplication stages. Mere Naseeb Mein Tu Hai K Remix Song Mp3 Download there. The Windows NT 4.0 duplication stages only did a relatively small number of things such as resetting the SID, changing the OEM branding strings, changing the Product ID, and changing the computer names.

However, since Windows 2000 the duplication stages have been tasked with many more items such as disabling/enabling System Restore, removing/regenerating TAPI settings, cleaning the device database/reinitiating full Plug and Play device detection, removing/regenerating network settings, resetting user first run settings and others. Also, apart from its internal tasks the duplication stages call external “providers” that allow the Windows component developers and third-party application vendors to prepare their components for duplication. Artem, It will depend upon what your goals are.

May 02, 2012 Windows 7 Forums is the largest. I came to the conclusion that using Sysprep with Generalize will uninstall the driver but not remove. Sysprep - Windows. ImageAssist: MS SysPrep and Device Driver Removal. To prepare a Windows image for deployment to multiple computers, you must use the System Preparation (Sysprep) tool to generalize the Windows image. When you set up your reference computer, Windows Setup installs drivers for any detected devices.

If you are trying to do all of the following, then rejoining the existing account makes sense. •Keep the existing computer name. •Preserve the existing computer account direct resource access. •Preserve the existing computer account group membership (for resource access via group membership and Group Policy security group filtering).

•Preserve container (OU) location If you wish to do none of this, then deleting the old account and creating a new one may make more sense. Where it gets tricky is if you only want to do some of the above items. For example, supposed you want a new computer name and a new OU location for the account while preserving the group membership.

Then there are several ways you can do this. You could script a rename and move of the existing account after the old OS has been shut down for the last time but before the new OS join occurs.

(You would use this method if you needed to preserve access to resources ACLed directly with the computer account.) Alternately, you could capture the computer group membership while in the old OS delete the account (here’s an example of that – ), create the new account in the correct OU on join, and write a script to restore the membership to the new account. Michael Murgolo. Hi Guys Thanks for the informative article, it is much appreciated I have just found your blog and I am very impressed. I am wondering if you may be able to help me with a problem I am having with XP Pro SP3, Sysprep and Acronis Up until a few months ago I would make my images for IBM Thinkcentre and HP Desktop computers that I support in various businesses. These updated images would be have XP Pro SP3 and current Microsoft updates and as a final step I would sysprep the machine, Shut down and use Acronis to image the machine ready for deployment.

This procedure was working great until last week when I decided to update my images with the latest microsoft updates and applications that the user used. When I then go to use the images for deployment, the machine now gets into a loop at the point where you specify the computer name and description. It just keeps coming back to this same point. I have tried rebuilding another model of HP from scratch that I haven’t used before and I still get the same problem. I am thinking that the issue is related to some of the latest MS updates that have come out in the last few months or so, however I am not sure. Help would be much appreciated Craig Williams.

As part of a team that creates Enterprise SOEs (Sysprep Resealed) that are then provided to regional Field services personal who then add region specific content we are finding that they are using Disk Cloning. What they are doing is taking a completed build, adding content, then re-running sysprep reseal. They would then capture that image and deploy it to like devices.

Is it appropriate for them to be running Sysprep Reseal on an instance of the OS that has already been resealed? I have not been able to find Microsoft support statement on running Sysprep reseal multiple times on a given instance of an OS. In a conversation I had several years ago with a Microsoft engineer that we had in to help he specifically told me that it was not recommended or supported.

Thanks for taking the time to read this. WSUS is a more complex issue, because the a WSUS ID is stored in the registry on each PC from the point at which it first contacts a WSUS server. Due to poor decisions at Microsoft, this was not cleared by sysprep in many cases. To make matters worse, the WSUS server itself foolishly took 2 client PCs with different FQDNs, BIOS version, OSs, SIDs but identical WSUS IDs as being the same client.

If they HAD used the SID to differentiate these problems would have been avoided, but Microsoft invent their standards and best-practices for /other/ people to use not to use themselves. Hi Michael, Good article.

I read Mark’s original post and was amazed and rather worried that so many people commenting either missed the point, or refused to believe Mark because they had duplicated machines and had problems. Am sorry Emanuel, I see you point about standards. You made the assumption WSUS uses SIDs albeit in good faith. That glosses over the point of logic failure of cloning: keep it clean. The whole point of cloning is to keep the source clean as a whistle. Sysprep is there to do just that cleaning but it can only clean out so much. It doesn’t clean WSUS values because cloning a machine with WSUS IDs is 'a bad idea' ™.

WSUS is working by design to ignore everything but the ID it handed out, probably because some people DO indeed make bad clones that have identical SIDs. So they play safe and don’t assume. Poor decisions are not Microsoft’s. It’s the people who clone things they shouldn’t who do, and then blame Microsoft when it doesn’t work. It all reminds of a variation of film 'The Fly'. Althou I do understand sysprep need, but having using Altiris to clone WinXP computers it really means that I save *ALOT* of time when I simply clone computer by making a 'perfect' sample computer with perfectly setupped user (In school envoroment with 21 computers, all using same username 'Student', no AD) and then simply taking a snapshot of computer and multicasting it to other computers. It was fast and easy way.

Altiris had sysgen that made changes to computers so there would not be dual SID’s. Using Sysprep resets so many setup tasks in computers (f.ex. Notorious IE 8 'kazillion' steps to start browing, all small little details in other computers) and now in our Win7’s it destroys f.ex. Display drivers which means that after almost installing all compueters by hand (sysprep destroys so much.) I have to reinstall drivers also. Is there ANY way to get back to old ways of simple and fast procedure of cloning and setting up or are we forced to use 20th century tools and ineffentiel ways? Hello Michael.

Thank you for your article. I do need your help. I am almost in the same situation that Craig Williams described. Up until recently, I did not have any problems in using sysprep to 'reseal' my images. We have a variety of IBM thinkpads and I have to update the cloned images regularily with updates, etc. What happens now with ThinkPad T60 image is that after I 'reseal' the computer with all new updates and patches, as soon as I go through the initial setup and login for the first time, I am unable to see 'Windows IP Configuration'.

Training Tools For Company. It is just blank – it doesn’t show any adapters, it doesn’t say 'Media disconnected', nada. Although, in 'Device Manager' I can see all network adapters and they are also present in 'Network Connections' I was, unsuccesfully recetting TCP/IP stack, applied WinsockFix, etc to no avail. I exported registry keys (HKLM/SYSTEM/CurrentControlSet/Services/Rcpip and HKLM/SYSTEM/CurrentControlSet/Control/Network from a working machine and imported them into freshly sysprep’ed – that didn’t work either. I am at the end of my wits! Please, help.

I strongly agree with A.J.!!! For me, it seems to be full intention of Microsoft, to make things difficult and work against K.I.S.S. It COULD be SO EASY to deploy an identical OS image to IDENTICAL (maybe virtual) hardware, but running sysprep is making a magic box out of it, not being able to take any influence of what is REALLY required. Maybe, I do not want to trigger PnP detection, or do not want to delete local users or any specific thing. But being forced to using sysprep does not give you any choice. And what is even worse: Even sysprep has (or had) bugs, e.g. The WSUS issue, because one SID is not enough.

One problem I do understand: The OS could already be activated Just my five cents Marcus. Hi, I'm attempting to determine the implications of testing DR scenarios for server systems. If storage replication is used from the active site to the passive site, and we want to test the DR plan by turning on the passive site servers while the active is still running (changing IPs) will this cause an issue? Obviously, everything about the computer will be identical except for the IP address. We're essentially cloning it. Now, if the duplicate Domain SID issue is purely related to security, I'm not concerned about that.

The passive DR instance should have the same permissions as its active instance anyway. And if it's an actual DR scenario, there would be no difference from test other than there would be only one server accessing the domain and other applications at a time. The only issue I can see with this is the DR (passive) instance registering with DNS and changing the IP. I suppose we could disable that somehow, perhaps by firewall, etc. How is this handled typically?

Any insight is greatly appreciated.

Note This content applies to Windows 7. For Windows 8 content, see. A common deployment scenario is to capture a single Windows® image from a reference computer and to apply it to a group of destination computers with identical hardware configurations. To save time during installation and to speed up the out-of-box experience for end users, you can instruct Windows Setup that the hardware on the reference computer and the destination computers are identical.

By doing this, Windows Setup maintains driver configurations during image capture and deployment. Background The Windows® 7 and Windows Server® 2008 R2 in-box driver packages include device drivers that support a wide variety of popular hardware. If your specific hardware requires additional device drivers to boot, you can preinstall additional device drivers on your Windows image. These additional device drivers are often supplied with their device hardware by independent hardware vendors (IHVs). For more information about how to add device drivers, see the topic in the Windows® OEM Preinstallation Kit (Windows OPK) User's Guide or Windows® Automated Installation Kit (Windows AIK) User's Guide.

To prepare a Windows image for deployment to multiple computers, you must use the System Preparation tool (Sysprep) tool to generalize the Windows image. Generalizing a Windows image removes the computer-specific information and prepares the device drivers for first boot. This preparation includes the following steps: • Device state for hardware is removed. • Boot-critical driver settings are reset to their default values.

• Device log files are purged. The unattended-Setup setting: Microsoft-Windows-PnpSysPrep PersistAllDeviceInstalls can save time by preventing Windows Setup from removing and reconfiguring the device state for identical hardware. On first boot, the detected device drivers are already preconfigured, potentially enabling a quicker first-boot experience.