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

@mark.dangelo said in Some laptops cannot get past "Starting Windows":

Where do you store the drivers folder and do you specify this location in the unattend.xml script?

Sorry for the delay this one slipped through the cracks.

The driver directory can be stored anywhere on the target computer that windows can reach during the OOBE process. I have seen some place the drivers in c:\driver, c:\windows\drivers, c:\windows\drv

Then in your unattend.xml file you need to add this section

<settings pass="offlineServicing"> <component name="Microsoft-Windows-PnpCustomizationsNonWinPE" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <DriverPaths> <PathAndCredentials wcm:action="add" wcm:keyValue="1"> <Path>C:\Windows\DRV</Path> </PathAndCredentials> </DriverPaths> </component> </settings>

ref: https://forums.fogproject.org/topic/8889/fog-post-install-script-for-win-driver-injection/4

It appears it’s an issue with the Unattend.xml file. I’ve tried one that has worked in the past and that’s absolutely fine.

Thanks for the help, gents!

the recovery/reserved partitions are automatically detected and should be set in the “fixed” partition list. Chances are, it would seem, that this didn’t get set for some reason? It looks at the label’s that windows typically defines. If the recovery/reserved was setup as a custom partition, most likely the label didn’t get applied as would happen in a “default” scenario?

You should be able to correct this behaviour by adding the partition number to the fixed partition file. For windows 10, I believe the partition number used for recovery|reserved is number 3.

Resizable partitions use the filesystem volume to determine if it’s viable for resize. Windows reserved/recovery from at least windows 7 on typically has this as an NTFS partition.

@Jonathan-Cool Use this: http://windowsafg.no-ip.org/