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

@amerhbb that’s up to you. If checked it forces the machine to reboot regardless of if a user is logged in or not. The forcing occurs for hostnames and/Or ad joining.

Just for clarity the issue is only with Win10 1709. Win7 and 2008 still deploys without issue?

As a test, can you capture and deploy back to the same hardware? Then deploy to a different target computer, but the same model?

The no boot device available is either:

You don’t have the disk controller drivers in your golden image for all hardware combinations You are deploying a BIOS image to a UEFI computer (or swapped around) FOG is having an issue restoring the boot sector

Can you tell us a bit more about what your reference image computer is configured and the configuration of a target system? This includes firmware mode, disk technology used (sata vs nvme)

@eazis said in PXE UEFI boot problems:

NBP filename is ipxe.efiÿ

Did you copy&paste the filename into the Unifi DHCP settings page? Maybe just clear the setting and re-type by hand to make sure there is no hidden character in that filename field. I can clearly see 0xff in the PCAP file… So either the Unifi DHCP is doing something really weird or there is a character in that field.

@x23piracy That looks like it might be exactly what we’re experiencing but I have no clue why it would only show up intermittently. I’ll test this out and see if it fixes the issue when I can get it to trigger again. Thanks for the info.

@zingaro why? We take a backup then put ours in place. We can’t use bcdedit in Linux as those are Windows tools.

Start-Transcript -Path C:\$([Environment]::Is64BitProcess).txt "Is 64?" [Environment]::Is64BitProcess $pwd if ([Environment]::Is64BitProcess) { $a = Get-BitLockerVolume -MountPoint C: $a | Out-File C:\file.txt -append } else { $arguments = "-ExecutionPolicy Bypass -NoProfile -File temp.ps1 " start-process C:\WINDOWS\sysnative\WindowsPowerShell\v1.0\powershell.exe -ArgumentList $arguments -Wait -WorkingDirectory $pwd }

I know its not pretty, but its a proof of running 64 powershell. In essence, I need the 32bit to launch a 64bit version of powershell. Can’t just run powershell.exe because it goes still into x86.

@imagingmaster21 said in Fails at NTFS:

Any ideas on this?

Definitely looks like the drive is dying. Try have a look at the S.M.A.R.T data of the drive, back up data and get rid of it.