@amerhbb Please look inside of the FOG Client’s log file on one of your hosts - it’s generally here: C:\fog.log Look through the log, do you see any errors? Feel free to post (enough) of the log for us to help.

@dawidh From your description so far I don’t think this is an issue with iPXE or the DELL laptops in particular. I reckon the switch you are using is not configured to work nicely. As a quick test grab a dumb mini switch and hook it between the laptop and you other switch. Give it a try again and see if you still have the same issue.

Here is what my unattend.xml looks like. I have made some redactions and comments to help out. I made mine using Windows System Image Manager. This is one of many webpages I used to learn about building my unattend file (and lots of trial and error): https://www.tenforums.com/tutorials/3020-customize-windows-10-image-audit-mode-sysprep.html

<?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"> <ProductKey>Your key</ProductKey> <TimeZone>Your TimeZone</TimeZone> </component> <component name="Microsoft-Windows-Deployment" 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"> <!--I had to add this as FOG wasn't expanding my OS partition all the way after OOBE ran--> <ExtendOSPartition> <Extend>true</Extend> </ExtendOSPartition> </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> <UserLocale>en-US</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> <UserAccounts> <!--If you skip account creation in OOBE, you need to enable local Administrator account or create another admin account in unattend file --> <AdministratorPassword> <Value>Your AdministratorPassword==</Value> <PlainText>false</PlainText> </AdministratorPassword> </UserAccounts> <StartTiles> <PromoteOEMTiles>false</PromoteOEMTiles> </StartTiles> <AutoLogon> <Password> <Value>password again</Value> <PlainText>false</PlainText> </Password> <LogonCount>1</LogonCount> <Username>Administrator</Username> <Enabled>true</Enabled> </AutoLogon> <FirstLogonCommands> <SynchronousCommand wcm:action="add"> <CommandLine>reg add &quot;HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon&quot; /v AutoLogonCount /t REG_DWORD /d 1 /f</CommandLine> <Description>Set AutoLogin count back to zero</Description> <Order>1</Order> <RequiresUserInput>false</RequiresUserInput> </SynchronousCommand> </FirstLogonCommands> </component> </settings> <settings pass="offlineServicing"> <component name="Microsoft-Windows-PnpCustomizationsNonWinPE" 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"> <DriverPaths> <!--If you are using the postdownload script for driver injection, you will need this --> <PathAndCredentials wcm:action="add" wcm:keyValue="1"> <Path>C:\Windows\DRV</Path> </PathAndCredentials> </DriverPaths> </component> </settings> <!--don't think the offline image part is needed, but it's part of the one that get's made when I use Windows System Image Manager --> <cpi:offlineImage cpi:source="source" /> </unattend>

@joe-schmitt Have tried that, actually just used a different username and password entirely and it worked. Not sure why the other password was being sent incorrectly after re-populating the field with the other credentials.

The stop code error I got was “Critical Process Died”, Tried sysprepping, with and without an answer file and neither of those options have worked. I have verified in the bios that storage drivers are the same on all of these models. Sorry for the delay in responses I only get a couple of hours a week dedicated to this project.

So far our other 3 models, Dell OptiPlex 9020, 7040, and our Dell Lattitude 5580 have not had any issues. It is just when we get to these older models that we have problems.

@george1421 Ok so not an issue with the network, R620 works just fine off the same switch.

I am gonna chalk it up to the Dell 3620’s firmware (which is the latest) being problematic. Its not the first time it proved to be, likely wont be the last.

I guess I can live with the issue as it always eventually runs setup.exe. As long as its not a wide spread issue and limited to that model machine I am gonna move on and just live with it.

Thanks for the help though, always good to have another person to bounce ideas off and to get other ideas from.

@sameer
Try going by this link to correct this problem on your DHCP server.
https://wiki.fogproject.org/wiki/index.php/Modifying_existing_DHCP_server_to_work_with_FOG

This morning, I have the problem on several machines which have get 1803 update…
I have changed the dhcp configuration for this machine to point to my testing fog server. (1.5.2)
On this server, I have applied Quazz solution to set grub in place of sanboot and now my Dell machines on 1803 have started passing by PXE…

Now I have to set it to my production fog server…

Thanks for your help

@wayne-workman
Think I figured it out… The image I was able to capture worked and everything was the same except for on the one that did not work I ran some powershell scripts that removed the windows 10 apps and microsoft edge. So I think that just broke stuff I am guessing. Because when it captured it didn’t even try to resize the file system.

So I just added the files in the image to a folder in C:\ rather than to run the scripts. So far it is capturing.

@fogjam this is definitely not expected behavior, thanks for reporting it. I’ll look into it and post in this thread with my findings.

Found a work around. Found one old image that works. Thanks for you all help

@ssh-jon said in PostdownloadFile Copy: Folders but no files?:

I did just think of a minor difference between the Windows 7 and Windows 10 images: for deploying Windows 7 to capture I create the partition structure manually using the latest version of diskpart, rather having Windows Setup build it. (This is because I build the image in a Hyper-V VM, but want to deploy it via UEFI, so I capture it as a WIM and re-deploy it on a UEFI compatible machine for capture.) It’s still the same structure, I just do it via diskpart.

This doesn’t appear to be standard activity or in line with the MS design guide. Most people don’t have this level of skills, so you may be one of the few who will run into this issue.

I take it the Hyper-V Gen1 VMs only have bios/legacy mode?

I can’t envision this is a FOG related issue. But, if you sysprep an image and then reboot it on the same machine (removing fog from the picture) do you still have keyboard and mouse function?

I would tend to think its a driver issue where you started with an earlier release of windows and its drivers, upgraded to 1803. Maybe the earlier windows drivers were still intact and then when you sysprep all of those drivers are reset to 1803. Understand this is just a guess. Also watch the revisions of your firmware to see if there is an update that solves your issue.

@itcc I do – please send me yours. I’ve done million tests, I’ve had MS case open (we have EA with unlimited cases but you get what you pay for - shit) and the issue with windows.immersivecontrolpanel is plaguing us. If you don’t know about this in 1709 it has to do with search not working and from there IE and ton of other crap. The lousy fix is to copy windows.immersivecontrolpanel to each future user c:\users\xxx profile. As I said a lousy fix.

If anyone can share their working xml that would be awesome!

alt text

@tom-elliott That solved my problem. Thanks!

@tom-elliott Ah. I haven’t yet ever found a need to run x86 powershell on x64 machine.

Perhaps I should expand.

This is what I did up to v1607.

My sysprep answer file sets autologon of Administrator for 99 times. It enables the Administrator account and has the password included (hashed by sysprep). It also includes a FirstLogonCommands to run a cleanup script.

That cleanup script performs the first part to remove security, rewrites the RunOnce registry value, then restarts the computer. Because the RunOnce registry value was recreated, the auto logon of Administrator launches that script again to perform further functions. After 3 more restarts the script turns off autologon, does not rewrite the RunOnce, re-enables security, then shuts the system down.

With v1709 I changed how I harvest driver files and have been able to install all drivers without the need to dumb down the security. I now install all general drivers from setupcomplete.cmd .

@tom-elliott Is this rolled into the master branch now or should i move over to the working branch?