@Wayne-Workman See post! I just updated it. Ha!

At this moment I have very less time to investigate (reasons which I don’t want to share on a public forum).
From the supplier I got a response:
Why “create partition primary” would not work as expected (=reserve all available space for a single partition), is not quite clear to me. It might depend on the version of “diskpart” (and its specific flaws), as well as the cyl/head/sector information read from the SSD, or the C/H/S mapping the BIOS applies which may differ from what the SSD tells (yes, this mapping stuff is still around after all these years of LBA…), and may as well depend on the setting of ACPI vs. IDE in BIOS (not sure if the hardware has this at all).

The suggestion to use the tools lsblk and fdisk is very interesting, to see the information which Linux reads from the SSD.
I’m not familiar with Linux, but we can learn. Takes only time.
I have still the idea, there is a mismatch between the SSD configuration, the BIOS information about the SSD, the information windows is using during diskpart and the Linux information.
I’m using FOG very basic. With the Windows Tooling I’m creating an working setup on my golden hardware model (8GB SSD and 16GB SSD). With the FOG tooling I create an image (Multiple Partition Image – Single Disk, Windows 7, not resizable).
The created image is distributed to many identical hardware models (without any modification on the image).
Now, if I create the 16GB image with the windows tooling, while I use the Create partition primary with the size parameter set to 15.2GB, everything works. FOG is not generating any error.
Later (September) I will check in more detail the mismatch ….

@Wayne-Workman Its been a long road but I finally have everything working. Tested on 3 different systems. A Daktech, An old Gateway, And an older Dell Optiplex all deployed perfectly with 1 Golden image. Drivers and all. The solution i came up with was to create a reboot.bat using “shutdown -t 0 -r -f” and at the end of setupcomplete.cmd place “CALL C:\xx\xx\reboot.bat”. It seems the slow systems just need a reboot to get the service to load properly as Joe suggested and of course we all want it to be automated. The delay could possibly work as well but i cant confirm since i came up with my solution before seeing this. At least the information is there if someone else stumbles across this. Thank you everyone for helping me tackle this. I greatly appreciate it.

@george1421
I"m betting it’s the order in which the script performs it’s tasks. I have the fog client reactivation set at the very end of the script. I’ll try adjusting the script and re-imaging.

This image is being used on identical hardware for this test.

@JoeG I have debated on just installing AV with a plugin. We’ve installed it with group policy in the past. It does work that way.

We have had a multitude of issues this summer and I’m trying to just get things ironed out on the last part of my installs before the school year starts next month. I’ve been thrown into the role of network admin after many years of being out of the tech world and I"ve been trying to learn the “proper” way of doing things.

Thanks for all of the advice!!! I appreciate the help!

Cheers,

Joe

To answer your question that article was written specifically for windows 7. So yes you need to use winpe10 drivers for windows 10 (its on the same dell driver page). Everything still works as documented , with the exception of the registry change. For windows 10 you have to add a section to your unattend.xml file to tell windows 10 OOBE to look for the drivers in a location you choose.

@george1421 This is also true for Windows 8 and 8.1.

@Tom-Elliott Thanks Tom You guys rock Love FOG and Thanks for getting back to me so fast Its all up and running

@Wayne-Workman Thanks that setting was already done But I had to change it at the host level and now it work Thanks everybody for there help Now have a bigger problem will open a new tread Again Thanks

@Wayne-Workman But sharing is caring. And it’s so much easier to maintain just one file in a shared location.

@Boyan-Biandov I also have basically re-used my Win7 unattend, though I did run it through the Win10 SIM to validate it. The only place I put it is in C:\Windows\Systems32\Sysprep folder. However, I have had the “Windows could not parse…” error and in looking at the setuperr.log in C:\Windows\Panther\UnattendGC folder (this one is different than the setuperr.log in C:\Windows\Panther, I don’t recall how though), it pointed me in the general direction of the <ProductKey>xxx</ProductKey> entry in “Specialize” pass. I ended up removing all product key entries and don’t have the error anymore. I have never really used audit mode, I just enter product key during installation and run “c:\Windows\System32\SLMGR.VBS” /ato" to re-activate after imaging (in setupcomplete.cmd). Good luck!

Edit: Forgot to mention that it always seemed to me that the unattend in C:\Windows\Panther was a post-sysprep record with all the sensitive data removed from the file by Windows as it processed it. I never before ran into any instructions to put it both places so I never have. Now if someone could tell me how they make the Win10 Default User profile keep the pinned icons on the taskbar I’d be the happiest camper alive.

@kc7mdl Beside the already requested information a picture of the error will speak more than a thousand words. Please take and upload one.

I don’t see any relevant reads on this issue at this time.

Well I do find a lot of posts on surface 3 - have you read through all of those?
https://forums.fogproject.org/topic/6227/surface-3-fails-to-image
https://forums.fogproject.org/topic/6116/surface-pro-3-fog-1-2-compatibility
https://forums.fogproject.org/topic/5689/surface-3-imaging
https://forums.fogproject.org/topic/3662/surface-pro-3-pxe
https://forums.fogproject.org/topic/2432/surface-pro-pxe-boot-need-to-image-for-mass-deployment
…

Great thanks I’ll give it a try.

It’s a 2008 R2 DHCP server.
Joe’s suggestion is a great idea. I’ll try that!
Thanks again!

I might have to try it. I’ll have to play with it.

Thanks!!

@echo off rem The fileserver IP set FILESERVER=192.168.1.155 rem Share on the fileserver. set SHARE=INSTALLERS\ISOFILES\0-WINPE rem Username for the share set SHAREUSER=root rem Password for the share set SHAREPASS=root rem amd64 or x86 set ARCH=amd64 rem Path to hold working files. Needs about 500MB of free space. set PEPATH="c:\winpe_%ARCH%" rem ########################################################## rem Don't edit anything below here rem ########################################################## echo Creating the PE image call copype.cmd %ARCH% %PEPATH% > NUL echo Mounting the image dism /Mount-Wim /WimFile:%PEPATH%\media\sources\boot.wim /index:1 /MountDir:%PEPATH%\mount /quiet echo Adding commands to the startup script in PE echo. >> %PEPATH%\mount\windows\system32\startnet.cmd echo ping %FILESERVER% >> %PEPATH%\mount\windows\system32\startnet.cmd echo net use z: \\%FILESERVER%\%SHARE% %SHAREPASS% /u:%FILESERVER%\%SHAREUSER% >> %PEPATH%\mount\windows\system32\startnet.cmd echo z: >> %PEPATH%\mount\windows\system32\startnet.cmd echo z:\64.bat >> %PEPATH%\mount\windows\system32\startnet.cmd echo Creating the pxeboot directory mkdir %PEPATH%\pxeboot > NUL mkdir %PEPATH%\pxeboot\Fonts > NUL copy /y %PEPATH%\mount\windows\boot\Fonts\*.* %PEPATH%\pxeboot\Fonts\ > NUL copy /y "%WinPERoot%\%ARCH%\Media\Boot\boot.sdi" %PEPATH%\pxeboot\ > NUL copy /y "%WinPERoot%\%ARCH%\Media\Boot\BCD" %PEPATH%\pxeboot\ > NUL echo Unmounting the image dism /unmount-Wim /MountDir:%PEPATH%\mount /Commit /quiet echo Optimizing the image imagex /EXPORT %PEPATH%\media\sources\boot.wim 1 %PEPATH%\pxeboot\boot.wim > NUL echo. echo All the files you need for your PXE server are in: %PEPATH%\pxeboot\

I use that batch file to easily create WinPE media for different Windows versions. It does require the imaging tools of the Windows Kits though, but I’m guessing most people will have that installed already.

You can add and remove certain commands as needed of course, for eg adding drivers using dism and such.

Any news on this…?

The important thing is that you upgrade your server. Until you do that the clients won’t be able to talk to it. When you do update it, your clients will automatically upgrade to 0.11.2 if that feature is enabled.

@Wayne-Workman That’s odd. I know that I had to create a different profile for LTSB but it certainly worked in LTSB. The profile I made in Win 10 Enterprise CB won’t work in LTSB and vice versa. Gotta create a new one. It’s lame I know.
My login times are much longer than 4 seconds though. But I have a lot of customziations. Little common fixes and startup scripts and backgrounds and stuff, so my first login for any user is like 2 or 3 minutes, but only a few seconds after that first time.

Do you want best practices to to get FOG to deploy to this system? The answer is pretty different.

If you want FOG to deploy to this system then you can either use FOG 1.2.0 stable (with current kernels) or deploy FOG 1.2.0 trun (which is a dev release of the soon to be FOG 1.3.0). You can use FOG 1.2.0 stable (I’ll assume what you have installed already??). That will work with win7 no problem. If you want to deploy win10, gpt disks, or to a uefi system you will need to be on the trunk release.

We can go into best practices once its clear what you are shooting for.