Hi all,

I’ve not been able to secure a time block to test and provide results/follow up, however I’m confident the sysprep issue was fully related to the fact that I wasn’t using a proper image source. This issue can be marked resolved.

I’ll test this when time allows, I expect I’ll need to work on the unattend script as well - all in due time.

Can’t thank you all enough for providing guidance, it’s truly appreciated.

Thanks again,
Brian

Hi @george1421 and @andreiv ,

Thank you for the feedback/replies.

I was using the OEM image as a base/reference, and think this is the primary source of my problems. I’ve read more on the licensing parameters and think I have a better understand now.

We have a VLK of Win10 Pro, I’ll work on using the VL media/key to build out a VM to generate our image source.

Below is my unattand for SysPrep for reference. I’ll post another update once I’ve had a chance to test using the VLK media route.

<?xml version="1.0" encoding="utf-8"?>
<unattend xmlns="urn:schemas-microsoft-com:unattend">
    <settings pass="oobeSystem">
        <component name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">            <OOBE>
                <HideEULAPage>true</HideEULAPage>
                <HideLocalAccountScreen>true</HideLocalAccountScreen>
                <HideOEMRegistrationScreen>true</HideOEMRegistrationScreen>
                <HideOnlineAccountScreens>true</HideOnlineAccountScreens>
                <HideWirelessSetupInOOBE>true</HideWirelessSetupInOOBE>
                <NetworkLocation>Work</NetworkLocation>
                <ProtectYourPC>3</ProtectYourPC>
                <SkipMachineOOBE>true</SkipMachineOOBE>
                <SkipUserOOBE>true</SkipUserOOBE>
                <UnattendEnableRetailDemo>false</UnattendEnableRetailDemo>
            </OOBE>
        </component>
    </settings>
</unattend>

Thanks again,
Brian

Greetings,

I’m using FOG (v1.5.5) running on top of a Ubuntu (v18.04.2 LTS) install, which is a VM running on HyperV.

I’m buying new (HP or Dell, from manufacturer, & no refurbs) systems in bulk orders, between 10-100 machines with same specs and presumably the same hardware. The goal being to take 1 machine from the batch, update it, install client-specific apps (Office, web browsers, anything that can be done before it goes on site and gets joined to the domain/starts playing with their servers).

The first set I tried this on I staged 1 system, installed apps/updates, ran sysprep, booted using PXE, ran a quick registration/inventory using Fog, assigned an image to the host, and captured my ‘master image’.

When I applied this master image to the other systems and turned them on they went through the OOBE process, everything seemed fine. However, flash forward a few days and the systems were deployed at their respective sites to discover all of the systems that got imaged also now have the same MachineGUID (HKLM>Software>Microsoft>Cryptography>MachineGuid) and matching network MAC address as the master image system. It seemed like an exact clone, the sysprep process had the opposite of the intended goal. Further testing replicated this issue exactly and consistently.

At this point, I’m taking a new machine, updating/installing apps, I then capture the system in this state and deploy it to the batch. Each system, after being imaged using the master image, has a sysprep run on it which seems to have the desired results. There’s no matching GUIDs, no matching MACs, they look to be unique. This process requires more labor (sysprep on each computer), and seems counter intuitive to everything I know of imaging solutions. Isn’t Sysprep supposed to be run before the replication of the image? What gives? Can anyone advise?

I’m happy to do leg work for a resolution, send me KBs/articles, many thanks in advance for any insight.

Kindly,
Brian