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 !

@cgauthier said in Windows 10 Upload:

Thank you, george1421 and others. I’m going to try upgrading to Fog version 1.4.3
chrisg

ref: https://wiki.fogproject.org/wiki/index.php/Upgrade_to_trunk

You will be better prepared for dealing with Win10 and new hardware (i.e. nvme disks)

@luiztpd which certificate did you download

Configuring sysprep is beyond the scope of the FOG Project, so its not specifically a FOG concern. But I can give you some guidance on your next steps.

You need to configure the unattend.xml script to fit your company’s environment there isn’t a one size fits all solution here. There is a few sizes that fit most approach you can take. There are a few online sources that will let you dynamically create your unattend.xml file with the settings specific for your site. One place to start is here: http://windowsafg.no-ip.org/ Construct your unattend.xml file with your required settings (or generic /anonymous info and then hand edit it with a text editor later) and download that to your target computer. Place that updated file in c:\windows\panther or c:\windows\sysprep. When you invoke the sysprep command be sure to reference the full path to your unattend.xml file. There is nothing specific you need in your unattend.xml file related to FOG.

You WILL need to create a setupcomplete.cmd file to reenable the fog client once OOBE is done. Don’t forget to install the FOG client in your golden image but disable the service. We do it this way so that the fog client doesn’t start doing its thing too early in the OOBE process before OOBE finishes.

Now let talk about your key management. If you have a KMS environment available, you should USE IT. MAK keys are use once. Once you burn through all of your MAK keys you will have to call the MS Licensing center and request more keys to be added to your account. With KMS you are in charge of your keys. When you retire computers your KMS keys are returned to your key pool. With KMS you can revoke or send out platform upgrade keys. You can also use KMS for MS Office and other components too. Its a great tool if you have more than just a handful of computers.

@BiologyBen It sounds like pxe booting was only the beginning of your challenge. Good luck!!

If you find new difficulties, please post to new thread and we will help you get started again.

@peer2peer The pxe booting computer finds out about the fog server from the dhcp server. To get a target computer to boot into fog the dhcp server must be updated. You must set dhcp option 66 with the IP address of the fog server. You must set dhcp option 67 with the file name undionly.kpxe for bios (legacy mode) computers and ipxe.efi for uefi mode computers.

@louis.tasse

Problem solved! Thanks!

Louis.

@wciws
Just checking to see if there have been any updates on your end of things?