Windows Sysprep Breaking



  • In several attempts to create a windows 10 golden Image, I keep receiving the error “Windows could not finish configuring the system. To attempt to resume configuration, restart the computer.” I then restart the computer and it gives me the same error.

    In prep for the image, I enter Audit mode, as explained here:(https://forums.fogproject.org/topic/9877/windows-10-pro-oem-sysprep-imaging).
    In my order of operations, I enter audit mode, join our domain, install required software, leave domain, sysprep.



  • After testing with the FOG client on my reference/golden image I found my issue which may help. I would task my client PC to be added to AD when the Auto Delayed service starts. Well, when a computer is being restored with the Windows 10 image it will start the services. Since it is starting the services it is trying to join the domain while the system is being sysprepped. This caused Windows to come up with an error to install or boot and various other errors. After the service was stopped in the reference/golden image then restoring had no issues. I manually have to enable the service and start it as well. The big issue turned into a okay fix.


  • Moderator

    @agray I would register the FOG server before you get into syspreping the device. In my case I have a VM that always build the reference image on, so it has been registered in FOG from day one.



  • @george1421 Should i register before sysprep or during the sysprep boot? Or does it even matter?


  • Moderator

    @agray said in Windows Sysprep Breaking:

    How do i capture without register with FOG?

    You can’t. You have to register your golden image computer with FOG to be able to capture it. You can deploy without registering with FOG right from the iPXE menu.



  • @george1421 How do i capture without register with FOG?


  • Moderator

    @agray If you want fog to manage the computers after deployment you would normally install the fog client and then register the target computer with FOG. But in your case the FOG Server will never see the target computer once it has been deployed. In this case you don’t need/want the fog client on the target computer and you don’t “need” to register the target computer with FOG. Once you have the golden image captured, you can deploy subsequent target computers right from the iPXE menu. There is a deploy image option. If you use this menu you don’t need to register the computer. This is kind of like a load and go menu. The only system that needs to be registered is the golden image computer so it can be captured.



  • @george1421

    When you say register, do you mean activate? If that is the case, I typically don’t activate it while building the golden image. You really have 3 days to play with the image before it starts to complain about activation. We activate it post image deploy in the setupcomplete.cmd batch file.

    fog, the first time it sees a machine, it asks you to register the machine, either full or quick.

    This is one way to do it. Its not a problem. The only issue is when you deploy your image, you can’t/shouldn’t boot the system into windows while its connected to the imaging network if the target computer needs to connect to AD. In your setup you will when you create the deploy task, tell FOG to power off the target computer after image deployment. That way you can move the target computer to the business network before its powered on.

    Not sure, if for what ever reason, I’m imaging different and it’s working. we boot UEFI>tell fog to quick register it>Select capture (on fog machine)>boot into “onboard NIC” and it captures or deploys the image we select on the fog machine


  • Moderator

    @agray said in Windows Sysprep Breaking:

    FOG is on it’s own network with not net access. Completely off our network since our network is 100% static.

    Not a problem either on an isolated network or on your business network. The FOG server does need internet access to install fog, but after that it doesn’t. I know some people that have the isolated imaging network will install a second interface in their fog server and connect that to their business network. That way they can manage FOG from the business network, yet deploy only to the imaging network.

    Setup PC on our network -> Set to DHCP and hook up to switch connected to FOG and capture

    This is one way to do it. Its not a problem. The only issue is when you deploy your image, you can’t/shouldn’t boot the system into windows while its connected to the imaging network if the target computer needs to connect to AD. In your setup you will when you create the deploy task, tell FOG to power off the target computer after image deployment. That way you can move the target computer to the business network before its powered on.


  • Moderator

    @agray said in Windows Sysprep Breaking:

    I will attempt to set this up in a VM on my FOG machine and then update this thread.

    I’m not sure I understand what the FOG machine has to do with your reference image. They should be separate entities.

    Should I register the device before i sysprep or after? This could have been part of my problem as well.

    When you say register, do you mean activate? If that is the case, I typically don’t activate it while building the golden image. You really have 3 days to play with the image before it starts to complain about activation. We activate it post image deploy in the setupcomplete.cmd batch file.

    Rules of thumb are: Don’t connect to AD and don’t use OEM. right?

    Correct don’t connect to AD before sysprep. You can access network shares on your domain by just providing your domain credentials when connecting if you need to access applications to install. As for OEM, physically you can use the media, but legally its against the MS EULA to do so. The volume license media should be used, and then the MSVLC key to activate it post winsetup/oobe. That way you are not burning mak keys until you need them.

    Would the Media creation tool work or do I need to burn our volume license iso to a usb?

    Typically… well I can say how I do it. In my vm host server I have the Windows VLSC media iso image. When I go to setup my VM, I will connect the virtual CDROM in the VM to the .ISO image. When I boot the VM it will boot from the ISO image. That way I don’t have to burn anything to physical media.

    (truth on how I build my reference image) I actually use the Microsoft Deployment Toolkit (MDT) to create my reference image. I have it setup to do the lite touch method that automatically builds my reference image with all of the windows updates and applications without having to go into audit mode and load everything by hand. When I go to build the reference image I just boot the MDT ISO image select the task sequence to run to build the reference image. I don’t touch the reference image until its time to sysprep.



  • I guess I’m confused and having the issue with order of operations.

    My set up is:
    FOG is on it’s own network with not net access. Completely off our network since our network is 100% static.

    How we capture images:
    Setup PC on our network -> Set to DHCP and hook up to switch connected to FOG and capture
    Deploy it the same only reversed.

    Does this pose a problem with creating a Golden img?



  • @Tom-Elliott I’m sorry, what service are you referring to?
    @george1421 I will attempt to set this up in a VM on my FOG machine and then update this thread.
    Should I register the device before i sysprep or after? This could have been part of my problem as well.
    Rules of thumb are: Don’t connect to AD and don’t use OEM. right?
    Would the Media creation tool work or do I need to burn our volume license iso to a usb?


  • Senior Developer

    @agray I think the biggest issue is the speed at which fog renames. It’s blazingly fast. Faster than windows has time to finish completing. Simple to disable the service and reenable it when ready. That’d be the first step and I’m pretty sure it will fix most of the issues you’re seeing.

    I’m quiet but always readying. Sorry for not helping sooner.```
    Insert Code Here


  • Moderator

    @agray unattend.xml configuration is a bit out of scope for the FOG Project but there are a number of sites that explain what to do with it. You could also use one of those online unattend.xml file generators to create a baseline config file for you like this one: http://www.windowsafg.com/ Just don’t put any private information in the online tool. Tweak the unattend.xml file after you have the framework build with your private information.

    When you run sysprep without command line it should launch the gui interface. I have not use the gui since I have a batch file setup to call sysprep with the proper settings. Be sure you have sysprep power off the windows computer when its done. This way you are sure the system is powered off in a state that can be cloned. The windows gui shutdown menu doesn’t actually power off the computer.

    I can say building your reference image in a vm (even using virtual box) gives you several opportunities not available on physical machines like creating a vm snapshot before you do a destructive step where on a physical machine you would have to start over if something went wrong. On a VM you would just restore to the last snapshot and then continue again. When I was first setting up my reference image, I would snapshot the VM just before sysprep. That way I could return to that step if I discovered I missed something in the deployed image without having to either reseal the image or start over.



  • Answering the questions don’t take long. Is there a tutorial on how to properly set up an unattened.xml file and using it properly?
    Was a physical machine but I’ll probably try VM on my fog server.
    I don’t use command line, I went to the file location and just used the application.

    I feel I’m doing this 80% wrong.


  • Moderator

    @agray said in Windows Sysprep Breaking:

    unattened.xml

    If you don’t use an unattend.xml file then you will have to answer the OOBE questions during install. Its not a problem if you want to do that for every deployment.

    Did you install the fog client in your golden image?

    Are you creating your golden image on a vm or a physical machine?

    What command line switches are you using to sysprep the system?



  • I’m not using an unattened.xml file because I don’t quite understand it and, from what I have read, it’s not required for a golden image.
    It was an OEM installation of window.

    Could the problem be the OEM/AD?


  • Moderator

    First of all lets start out with what you shouldn’t do.

    1. You should not connect your reference computer to AD because AD will tattoo it causing you issues in the future. Its better to leave it a workgroup computer then sysprep it.
    2. While you didn’t state it, OEM versions of windows do not have redistribution rights. Its against the Microsoft EULA, only volume licensed software may be customized and deployed. OEM licenses can only be deployed from the original OEM media. If you fall into that category you can purchase 1 volume license for each version (not individual PC) of windows you want to deploy. So if you are deploying Win10Pro to 100 computers, you only need 1 Volume license for Win10Pro. That 1 Volume license doesn’t allow for version upgrades such as you have Win10Pro and you want to deploy Win10Enterprise. For that you will need 1 license for each PC you are upgrading.

    Now in regards to your error, this one is sometimes tough to find and fix.

    We have seen if you have the fog client installed but did not disable the service before you sysprep’d the computer, when you deploy the image the fog client starts doing its thing too early in the WinSetup/OOBE process causing a botched deployment. If you did not follow the fog client wiki page then this is probably your issue.

    I have also seen this type of error if you have something not right in your unattend.xml file that causes winsetup to abort. Or your unattend.xml file can’t be found. FWIW, place your unattend.xml file in c:\windows\panther only.

    I’ve also seen bad drivers break imaging causing the setup to not be able to continue.

    So how to you figure out where the issue is? Depending on where your unattend.xml file is, windows creates log files that will help you figure out what happened. The log files should be in c:\windows\panther or c:\windows\setup\sysprep directory. The log files you are interested in have a .log extension. You will need to comb through those files to figure out why windows setup is not happy if resolving the above doesn’t help.


Log in to reply
 

404
Online

5.7k
Users

13.0k
Topics

122.0k
Posts