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

@arduinoandmore

Pointers to be looking for

1.The bus connecting the hard disk to the mother board is faulty.

2.The master boot record (MBR) on the hard disk got corrupted.

3.SMPS (Switch Mode Power Supply) failure. In this case, your computer may not boot at all. But there are times when only one of the power plugs may fail.

If anyone has encountered any other points of failure, please follow this solutions provided below.
https://www.errorsolutions.tech/error/a-disk-read-error-occurred/
Solution 1. Reconnect hard disk drive (HDD) or solid state drive (SSD)
Solution 2. Recover Master Boot Record (MBR)
Solution 3. Check Hard Disk Drive (HDD)
Solution 4. Replace the Hard Disk Drive (HDD)/ Solid State Drive (SSD) and Install Windows

Seems to be the hard-drives of the machines.

@flipwalker If you have dell systems (sorry I don’t remember) you can get the cab files from here: http://en.community.dell.com/techcenter/enterprise-client/w/wiki/2065.dell-command-deploy-driver-packs-for-enterprise-client-os-deployment (Hint: They are all in one place.) Just extract the drivers using 7zip and build the required directory structure.

@wayne-workman It’s working

Problem solved.
I forgot to disable the option reboot after install in the snapins

@cronsloth did you make any headway on this?

I’ve just updated to RC12 (didn’t know it was out when I posted) and that is working correctly. So, I guess, Solved?

@Joe-Schmitt, I encountered the same issue after recently upgrading from FOG Server 0.32 and the old FOG Client to 1.4.4 and 0.11.12, respectively. Deploying the same snapin that previously modified the AutoAdminLogon key on Windows 7 64, no longer seemed to affect the registry (still deploying to the same OS).

After some testing, I found that Windows File System redirection was the culprit. FOGService runs the snapin with the 32-bit executable (cmd.exe, cscript.exe, reg.exe, etc.) because Windows redirects %windir%\system32 to %windir%\SysWOW64. This caused my registry update to modify

HKLM\Software\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Winlogon

instead of

HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon

Don’t know why my old FOG ecosystem was unaffected, but here are some workarounds I’m exploring on the snapin side (links document the ideas—YMMV):

Prefix the command with %windir%\sysnative (only works on Windows 64 bit in a 32-bit shell), which can be done in directly in Snapin Run With or coded into the script
File System Redirector mentions using %windir%\sysnative

Create a symbolic link to call a 64-bit version of the executable
Open 64bit command prompt in 32 bit command prompt

Force REG.exe to write to 64-bit registry location with /reg:64
https://ss64.com/nt/reg.html

Example VB Script that sets Autologin - untested

@dclark v0.11.13 of the client (in the newest RC) patches the win1709 issues, thank you for your help debugging this!

@x23piracy a windows service can impersonate one of the logged in users without their password. Essentially the service grabs a process running as the user you wish to impersonate, and obtains a handle on the process’s access token (OpenProcessToken). The service then needs to duplicate the token so it can “impersonate” the user without affecting the process we lifted the token from (DuplicateToken), activate that token, and then perform the work. Finally the token handle must be closed.

Its a pretty win32 api heavy approach. The client does not use this technique as there is no guarantee a user is logged in at any given point.

TL;DR: grab an existing process running as that user, and perform multiple win32 API calls to impersonate that user.

@lukebarone said in Windows 10 SysPrep not working:

@loosus456 Yea, I have no objection to that. But I can’t get the Taskbar Customization to work (even after fixing the .xml file that is generated), so I gave that part up. It resets the taskbar to just Edge and Explorer, and allows users to customize it how they wish.

Hi,

you need to apply taskbar customs via group policy, if so the user has change rights:

https://social.technet.microsoft.com/Forums/windows/en-US/83b725f4-90f8-476a-bba0-3193e4e47d2e/windows-10-1607-enterprise-taskbar-items-pinned-via-layoutmodificationxml-and?forum=win10itprosetup

IMPORTANT

If you use a provisioning package to configure the taskbar, your configuration will be reapplied each time the explorer.exe >process restarts. If your configuration pins an app and the user unpins that app, the user’s change will be overwritten the >next time the configuration is applied. To apply a taskbar configuration and allow users to make changes that will >persist, apply your configuration by using Group Policy.

https://technet.microsoft.com/en-us/itpro/windows/manage/configure-windows-10-taskbar?f=255&MSPPError=-2147217396

What ever can be done by gpo should be done with gpo (ms philosopy). If you don’t have a domain controller for gpo applyment you can simply use gpedit.msc locally to set this on your golden image.

Regards X23

This feels much better!

Upgraded Fog to 1.4.4, and captured the image, deployed it, and was presented with my AD Login screen! It logged me in, then restarted… Then let me log in properly.

A couple things I need to change on the image, but over all, this is much better than where I was before! Thank you for the advice

@thesavagetony said in Capture and Deploy Question!:

Thanks! That’s what I was finding, but maybe I misunderstood the Wiki while following it.

Can you give me a link to the article you are referring to please?