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

@aharrison For in the FWIW bucket. The for win10 the panther folders gets searched first for the unattend file first and then on down the line: https://technet.microsoft.com/en-us/library/cc749415(v=ws.10).aspx

MS Recommends that you place the file in the panther folder (either unattend, or panther directly). Then calling out the specific path to it isn’t required. I always do include the specific path out of habit.

@Quazz Yep, after shutdown and wol i get pxe. It may well be a bios issue, but I think the hybrid shutdown is happening even when fast startup is disabled. I have just put the question on Dell forums, I’ll see if they have any ideas and report back if they do.

Just Kidding :))))) I just added the other architectures under the helpful little NOTE: and it works just great! I Skim too much and don’t read enough. You guys are great.

@Raj-G under <settings pass=“specialize”>

<component name=“Microsoft-Windows-UnattendedJoin” 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”>
<Identification>
<JoinWorkgroup>Workgroup</JoinWorkgroup>
<Credentials>
<Password></Password>
<Username></Username>
</Credentials>
<JoinDomain></JoinDomain>
<MachineObjectOU></MachineObjectOU>
</Identification>
</component>

the above is for 64-bit… if you’re ever unsure use WAIK to generate your unattend file for you if you don’t feel comfortable doing it manually

Yeah, not closed until it’s actually working.

@Troye-Johnson this issue is patched in v0.11.12.

@Joe-Schmitt Thank you for your post, this was the problem.

@RobTitian16

Q1 Batch file: This is an independent batch file from MDT. We do a few clean up actions just before sysprep and power off. We do this via a batch file and at the end of the batch file it runs the sysprep command with a consistent syntax. That way we get the same exact action every time we build a master image and then sysprep it. It could be done manually by copy and paste, but its much easier to run the batch file. We do have the sysprepit.cmd file as well as some branding stuff installed as a MDT package. That is how it gets copied over to the reference image as a MDT package.

Q2 CAB file: Understand there are 2 different cab files in play here. We install the winpe cab file in the reference image since that contains the core drivers we need post deployment. The driver path /images/drivers/{hardware_type}/{os_type}/{arch}/{driver files} is the extract of the model specific cab file. If you give me a specific dell model I can point you to the proper cab file.

@dustindizzle11 Thank you for sharing what you’ve learned> I’m sure it will help others as they find this thread in the future. Well done!!