none
Deploying an image to different hardware - what are the downsides?

    Question

  • I recently tested capturing an image of one laptop (a Lenovo Yoga x380) and then deploying the capture to a Dell Inspiron P69g. I'm trying to figure out if this is a bad idea, and why? So far I've only seen advice along the lines of "don't do that" or "it's bad practice" but very scant on the details. I need more convincing arguments to take to the next prep meeting. 

    I used DISM directly to capture the image so the machine was not sysprepped before capture. This means that all the settings we require are maintained, which is good.

    So far I haven't run into any major problems, the hardware all seems to have the correct drivers and everything looks like it should work great. 

    What are the downsides I may not know about? 

    Wednesday, May 16, 2018 11:44 AM

All replies

  • The cleanest possible image you can get is one you capture on virtual hardware, simply because all necessary drivers are already included in the OS. On a physical box you may end up with various artefacts after the sysprep and may face various issues down the line. As a rule of thumb: test on real hardware, but build in a virtual environment - it is faster, more convenient and you will get a better OS image.

    Cheers,
    Anton

    Vacuum Breather Blog | Wing Commander Saga | Twitter

    Note: Posts are provided "AS IS" without warranty of any kind. If posts are helpful please don't forget to rate them as "Helpful" or as "Answer".

    Wednesday, May 16, 2018 11:59 AM
  • We have hardware dependent settings, such as WiFi settings for preferred band that we set on the laptops, and these are captured when using DISM directly without sysprepping. After deployment these settings are preserved, possibly because both of these laptop types have the same Wifi chip, I don't know. 
    Wednesday, May 16, 2018 1:11 PM
  • Sysprep matters - in fact, you will most likely end up in an unsupported state if you do not prepare your images properly for cloning. You may want to go these two articles to fully understand the implications: https://blogs.technet.microsoft.com/deploymentguys/2009/12/03/sysprep-machine-sids-and-other-myths/ + https://blogs.technet.microsoft.com/markrussinovich/2009/11/03/the-machine-sid-duplication-myth-and-why-sysprep-matters/

    Cheers,
    Anton

    Vacuum Breather Blog | Wing Commander Saga | Twitter

    Note: Posts are provided "AS IS" without warranty of any kind. If posts are helpful please don't forget to rate them as "Helpful" or as "Answer".

    Wednesday, May 16, 2018 1:20 PM
  • Thanks for the info. Those articles are from 2009, has nothing changed? Sysprep removes too much of the settings we need, and if not running it results in some maybe problems possibly further down the line, it's hard for me to convince the management why we need to do it...

    "Cloning without running Sysprep can affect components such as the Windows Update client when used with Windows Server Update Services, Network Load Balancing, MSDTC, Vista and higher Key Management Server activation, and others."

    None of those components are really relevant in our scenario as most of these machines will never be in the same building / network as each other. 

    Wednesday, May 16, 2018 3:24 PM
  • Those articles are still highly relevant today. You need to understand that by omitting sysprep and using duplicate SIDs, you are operating outside of every supported scenario. Duplicate SIDs can compromise file access controls. You may also encounter issues joining machines to Active Directory. Model-specific settings can be set using scripts, DSC, and other mechanisms. Whichever path you take is ultimately up to you, I just wanted to make sure you understand the risks involved.

    Cheers,
    Anton

    Vacuum Breather Blog | Wing Commander Saga | Twitter

    Note: Posts are provided "AS IS" without warranty of any kind. If posts are helpful please don't forget to rate them as "Helpful" or as "Answer".

    Wednesday, May 16, 2018 4:21 PM
  • I Agree with Anton, VMs with sysprep is the way to go. If your trying to configure wireless NIC settings, once the driver is imported to MDT, you can edit the inf of the driver. The inf can contain default settings that you can modify, be careful. I have done it twice, once with Surface Ethernet driver to turn off selective suspend and an Intel wireless nic to disable wake on pattern match because of a sleep issue.
    Saturday, May 19, 2018 11:22 PM