Win 10 Clones NOT Unique On Network

[QuikFixer]

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

[andreiv]

Something is wrong with your sysprep settings and/or answer file (if you use one).
I used this same process many times and never had this issue:

Install windows on one system. During install, I created a temp account (without a password), to use for the setup process. Installed all the apps.
Ran sysprep and rebooted in audit mode. Deleted the temp account and ran sysprep again with a custom unattend.xml file. The system shuts down.
Capture the entire drive with FOG.
Deploy to clients. Worked perfectly.

The strange thing in your case is the MAC address. That is something set in the network interface itself, so it should be different by default. Unless you explicitly changed it in Windows, before capture. But even if you did that, sysprep should remove that setting.

Review your steps carefully, something is wrong there. Outline your steps in detail here, maybe I can spot the issue.

[george1421]

I can also state that we do a similar process and have not had this issue at all. To me this appears to be a windows issue and not FOG. in a way FOG is doing exactly what its suppose to (clone a reference image onto target computers). So for now you can pull FOG out of the problem equation. This sounds like sysprep is not properly preparing the reference (golden) image before image capture. Running sysprep should reset the maching guid to be set during WinSetup/OOBE on first boot after cloning. I expect you would get the same results if you built a reference image, sysprep’d it and then powered back on the reference computer. Whatever system prep process you are using should give you the same results without using FOG.

My typical workflow is this (we use a single golden image for all hardware, by letting FOG copy the model specific drivers to the target computer during the image push process).

1. We build the golden image in a VM to eliminate all hardware specific drivers. We use MDT to create a consistent and repeatable golden image. You can do this by hand in audit mode, but using MDT gives us a fully automated way to do it. Note at this point the VM has already been resisted in FOG with a new image definition created to hold the golden image.
2. We run the MDT boot to build the reference image using the lite touch methodology.
3. Apply any last minute tweak needed. (note during the MDT build process our custom unattend.xml file is copied over to the reference image)
4. We run the sysprep command referencing the copied over unattend.xml file (stored in the c:\windows\panther directory) and have sysprep power off the reference VM (this is important to have the reference computer powered off correctly or cloning will not work)
5. We then schedule a capture task in the FOG UI for this VM. Be sure to have FOG power OFF the reference computer after image capture or the reference computer will reboot after image capture where it will start WinSetup/OOBE (which maybe an unwanted experience)
6. We pxe boot the reference computer and complete the image capture process.
7. From there once the image has been captured we move on to the deployment workflow.

While you haven’t said this, I’m going to read between the lines. The Windows OEM license EULA doesn’t allow image cloning using OEM media. You need to use/have a volume licensing key and media to be able to properly image machines. If all of your target systems currently hold a Win10 Pro OEM license key then you only need 1 Win10 Pro VLK key. The reason why I state this is:

1. To ensure you understand the legal impact of the MS Windows EULA.
2. The OEM media reacts a little different than the MS Volume license media in that for the OEM media the setupcomplete.cmd batch file is not called as well as a few other things. I can’t speak for sysprep but that might explain why sysprep is not giving you the expected results as we normally see (yes I use vlk media).

[QuikFixer]

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

[george1421]

@QuikFixer Your unattend.xml file is not complete. Here is an example of what it should look like: https://forums.fogproject.org/topic/11920/windows-10-1803-sysprep-problem/7

There may be extra bits in mine that you don’t need, but it should get you pretty close.

[andreiv]

I agree with George. Your unattend.xml is not complete/correct.

Use Windows System Image Manager to create and verify the XML file.

You can get the WSIM from Windows ADK:
https://docs.microsoft.com/en-gb/windows-hardware/get-started/adk-install

Here is one of my sysprep files:

<?xml version="1.0" encoding="utf-8"?>
<unattend xmlns="urn:schemas-microsoft-com:unattend">
	<settings pass="specialize">
		<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">
			<TimeZone>GTB Standard Time</TimeZone>
			<ProductKey>NW6C2-QMPVW-D7KKK-3GKT6-VCFB2</ProductKey> <!-- This is the Enterprise Edition key -->
			<!-- <ProductKey>VK7JG-NPHTM-C97JM-9MPGT-3V66T</ProductKey> --> <!-- This is the Professional Edition key -->
			<ComputerName>*</ComputerName>
			<RegisteredOrganization>CUNBM</RegisteredOrganization>
			<RegisteredOwner>LABSWKS</RegisteredOwner> <!-- LabS WorKStation -->
			<CopyProfile>true</CopyProfile>
		</component>
		<component name="Microsoft-Windows-UnattendedJoin" 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">
			<Identification>
				<JoinWorkgroup>LABSWKS</JoinWorkgroup>
			</Identification>
		</component>
	</settings>
	<settings pass="oobeSystem">
		<component name="Microsoft-Windows-International-Core" 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">
			<InputLocale>en-US</InputLocale>
			<SystemLocale>en-US</SystemLocale>
			<UILanguage>en-US</UILanguage>
			<UILanguageFallback>en-US</UILanguageFallback>
			<UserLocale>ro-RO</UserLocale>
		</component>
		<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>
				<ProtectYourPC>1</ProtectYourPC>
			</OOBE>
			<AutoLogon>
				<Enabled>true</Enabled>
				<Username>Student</Username>
				<Password>
					<Value>student</Value>
					<PlainText>true</PlainText>
				</Password>
			</AutoLogon>
		</component>
	</settings>
	<!-- 	<settings pass="generalize">
		<component name="Microsoft-Windows-PnpSysprep" 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">
			<PersistAllDeviceInstalls>true</PersistAllDeviceInstalls>
		</component>
	</settings> -->
</unattend>

[QuikFixer]

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