@george1421 We were successful yesterday when we used the image we created on our Stem machine. We were able to do perhaps 4 PC and all worked perfect. To say we were excited at the possibility to knock these out so fast is a gross understatement.

Today using the same image we have the boot issue. Now to be fair perhaps it is a driver issue. I am not sure if we have all possible drivers loaded.

I am 95% sure we tried a capture from the reference image (swap the hard drive with a blank one) and deploy back to the same hardware and it didn’t work. But I might be wrong since we tried maybe 10 different things today on top of trying to manage our 11 store 600 PC environment. It can get a bit confusing at times.

I will try that for sure next as well as making sure we have the right driver packs.

Auto logon values are stored in the registry. Run the following PowerShell script to determine your current AutoLogon settings.

$path = 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon' $AutoAdminLogon = (Get-ItemProperty -Path $path).AutoAdminLogon $DefaultUserName = (Get-ItemProperty -Path $path).DefaultUserName $DefaultPassword = (Get-ItemProperty -Path $path).DefaultPassword $AutoLogonCount = (Get-ItemProperty -Path $path).AutoLogonCount Write-Host "Current AutoLogon Settings:" -ForegroundColor Yellow Write-Host "AutoAdminLogon: $AutoAdminLogon" Write-Host "DefaultUserName: $DefaultUserName" Write-Host "DefaultPassword: $DefaultPassword" Write-Host "AutoLogonCount: $AutoLogonCount"

Output from my Windows 10 1607 laptop:

Current AutoLogon Settings: AutoAdminLogon: 0 DefaultUserName: Administrator DefaultPassword: AutoLogonCount:

AutoAdminLogon has two states. If it’s 0, then it’s disabled. If it’s 1, then it’s turned on.
AutoLogonCount indicates the remaining number of automatic logons. This number decreases by one every time the computer restarts, until it reaches 0. When it reaches 0, it changes AutoAdminLogon to 0 and clears the DefaultPassword. Setting this to any number below 0 will effectively set your computer to automatically logon forever.

Try using defprof. It can transfer a lot of the settings to default profile.

https://www.forensit.com/support-downloads.html

@joe-gill well done.

@avaryan FWIW, you can start with a online generator to build your basic win10 unattend.xml file: http://windowsafg.no-ip.org/win10x86_x64.html To that we add in the section to load the drivers from a known location. We have to do this because some driver are needed for the OOBE process (we use a single image developed on a vm for all computers in our fleet) to run successfully. Then in the setup complete we use dism to inject any drivers missed during the initial OOBE process (mainly because some hardware is hidden behind other devices that needs it driver loaded first).

In our deployment process we use the unattend.xml file to connect to AD and not the fog client. We calculate the target OU based on several factors that is calculated at deployment time. This dynamic OU selection isn’t possible using the standard FOG environment. So we use a post install script in fog to update the system’s host name, location, timezone, OU location and a few other things that escapes me right now.

Since we use MDT to build our reference image you don’t need to mess with audit mode to default user profiles that is managed by the mdt process.

@john-sartoris Hmm, seems they’ve switched back and forth between the two on several occassions, bah.

@m144 said in Windows desktop shortcuts... .ico images gone after sysprep!:

@avaryan WOW that was quick… Did you just make this!

Modified from something I previously wrote so that I could apply auto login values in bulk via IP addresses exported from DHCP and saved in a csv file. This was at a time when our DNS records weren’t reliable so the tool that I typical use to set auto login wasn’t working reliably.

The original, in case anyone ever needs it for something:

<# .Synopsis Enables Automatic Login with supplied credentials. .DESCRIPTION Logs off all users, sets AutoLogon registry keys with entered values, restarts the computer. .EXAMPLE ./Set-AutoLogon.ps1 -ComputerName PTSD-TestComputer -Username PTSD\TestAccount -Password Password123 -TimesToLogin 3 This will automatically logon to PTSD-TestComputer three times as the TestAccount user. The computer will revert to the normal logon procedure after the third automatic logon. .NOTES Supplied credentials are stored in plain text in the registry. They are removed from the registry when the number of automatic logons is depleted. #> Param( [parameter(Mandatory=$true)] [String[]] $ComputerName, [parameter(Mandatory=$true)] [String] $Username, [parameter(Mandatory=$true)] [String] $Password, [parameter(Mandatory=$false)] [Int] $TimesToLogin = 1 ) $credentials = Get-Credential Invoke-Command -ComputerName $ComputerName -Credential $credentials -ScriptBlock { Param($Times, $User, $Pass) $shutdown = $env:SystemRoot + "\System32\shutdown.exe" Start-Process -FilePath $shutdown -ArgumentList '-l -f' -Wait Start-Sleep -Seconds 2 $path = 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon' Set-ItemProperty -Path $path -Name AutoAdminLogon -Value 1 Set-ItemProperty -Path $path -Name DefaultUserName -Value $User if (-Not (Get-ItemProperty -Path $path | Select-Object -ExpandProperty "DefaultPassword" -ErrorAction SilentlyContinue )) { New-ItemProperty -Path $path -Name DefaultPassword -Value $Pass | Out-Null } Set-ItemProperty -Path $path -Name DefaultPassword -Value $Pass | Out-Null if (-Not (Get-ItemProperty -Path $path | Select-Object -ExpandProperty "AutoLogonCount" -ErrorAction SilentlyContinue )) { New-ItemProperty -Path $path -Name AutoLogonCount -Value $Times | Out-Null } Set-ItemProperty -Path $path -Name AutoLogonCount -Value $Times | Out-Null Restart-Computer -Force } -ArgumentList $TimesToLogin,$Username,$Password

This is definitely unrelated to a “FOG Update”, more something with how the image was stood up. If it worked in the past, it was most likely luck.

@RLane simple add this section into unattend.xml

<FirstLogonCommands> <SynchronousCommand wcm:action="add"> <CommandLine>REG ADD &quot;HKLM\System\CurrentControlSet\Control\Network\NewNetworkWindowOff&quot; /F</CommandLine> <Order>1</Order> <RequiresUserInput>false</RequiresUserInput> </SynchronousCommand> </FirstLogonCommands>

it solve my issue

As a temporary solution, I have removed the auto login portion of my unattend.xml file … I’m not sure if this is the ideal solution but it worked.

When I remove the autologin portion, I do not need to force FOG to rename when users are logged in. In the past, 1511 and 1607, it didn’t seem to mind the local administrator account being logged in after an imaging task to rename, join domain and reboot. It appears it matters now?

If I keep the autologin, I have to ensure FOG is set to force changes despite a user being logged in. For those using my unattend - remove this:

<AutoLogon> <Password> <Value>password here</Value> <PlainText>false</PlainText> </Password> <Enabled>true</Enabled> <LogonCount>1</LogonCount> <Username>administrator</Username> </AutoLogon>

If I had to guess, 1703 had a couple of changes that will require a FOG Client update.

@Tom-Elliott got it to work… very weird because i didn’t hard reset or anything.I tried to do a regular shutdown and it worked. Must have had a hiccup somewhere

@Tom-Elliott another FOG parameter. Not very clean but typically FOG will be installed in a unique local and not traverse across.

Possibly also something in the language file to control what the system "thinks’ the system partition is called?

same of @markus1204 deploy ubuntu 16.04 server on hyper-v virtual machine it work fine

The process you described below worked great, feel free to mark this as solved and thanks again for your help and support, this software is going to make things a lot easier and more efficient for us here!!

@george1421 Thanks George. I understand about the IP reasons.

That site makes sense, now that I can see where the offline service bit had to be put. I had it in the wrong spot on mind, which meant drivers weren’t being picked up. Moved it, and it’s working great.

Thanks!

Or install the update, then install the client. I’ve seen things like this before and that’s how I addressed the issue. Uninstall the client. Perform update, Reinstall the client. This way the .NET framework is readily accessible before the client is installed. Of course this worked for my case, this doesn’t mean 4.7 isn’t breaking something, or that it will make the client start working, but at least it’s more information we can work from.

“Remove update, all works” (Yay/Nay)?
“Update the .NET Framework, reinstall client, all works” (Yay/Nay)?

@Wayne-Workman

You rock! It was not expired but set to user must change password on next logon. Thank you!

Jesse

OK.
I put the right fog version : 1.4.3

I thank you, 1.4.4 version fix my issue!!

@Tom-Elliott
Thanks Tom! I’ll check that out. That sounds like it could be the issue!

I’m rebuilding the FOG Server today! 🙂
Everything is set to go. I backed up all of my images locally. We migrated to a new physical server. So this is a brand new install. I’m going with Debian.

My bad …
After many waste of time to find the culprit, i finally found it … : me !
Why ?
Because i realized many many MANY tests (upload task, download task) to create my best-dream-universal-win7x64-image …

So … i simply forgot to disable FOG service BEFORE ran sysprep on the Golden Image … (did it in the small test image)

Now, the Sysprep works fine …

But now, i know all sysprep logs … :

cbs.log setup.etl session.xml setupact.log in Windows folder setupact.log in Windows\Panther folder setupact.log in Windows\Panther\unattendGC folder setupapt.dev in Windows\inf setupapt.offline in Windows\inf setuperr in Windows\Panther …

Shame on me !