Sorry for the late response. I have not solved the issue but I also need to get some other items finished. I believe the root cause in this situation is not FOG but SCCM getting in the way. I might not have time to circle back to this until next month. I am leaving for our Florida office in a few days to help with things down there and attending Microsoft Ignite that last week of the month.

Hi,
Thank for answers …

@george1421 :
I’m not sure if i really understood your things …

You said :
you may need to use persistent groups to set some default actions
Can you write an example ?

You will have the most flexibility if you use the post install scripts to connect to AD
I use post install scripts to connect my AD with the desktop computer. But, for theses laptops, i don’t need to connect to AD …

I think, i’m not really need to alter the unattend.xml because i use a specific unattend file for theses laptops.

You can only install “things” that windows will find during installation : yes, i understood this part 🙂

I use my specific unattend file to create my user Utilisateur. But i can’t personnalize this user with unattend …

@Seb-B : i will try your way 🙂

I will be back !

@kevinaguiar said in ComputerName in OOBE Windows 10 Pro Sysprep Machine:

Returning to FOG, I thought of solutions like CloneDeploy (http://clonedeploy.org/), where it edits the unattend file, editing the <ComputerName> </ ComputerName> tag and putting the hostname that was defined in Web interface. Is it possible to do something similar in FOG?

Yes you can do this in a fog post install script. That is how I do it in my company. I don’t use fog to rename the computers, because our computer names are calculated based on where the image is deploying, what image type is used and then the asset tag is appended to the end of the that other prefix info. So it is possible to do.

If you have found a solution then great, if not let me know and I will show you how it can be done.

@lebrun78 Thanks for letting us know. Good you got this solved! Marked as solved.

@espynn In such case, I’d recommend creating a fresh & clean image to try out next.

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