@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?

The thread will likely help someone in the future.

@irfan4701 - @sudburr is correct. Windows server 2012 is based on Windows 8 / is called Windows Server 8. Likewise, Windows server 2016 is based on Windows 10.

the error appeared after we changed the ip address of the fog server
we reinstalled the client after the ip change
We don’t use snappin
I am lokking if there are persistent file mount…