Finally, with all you explanation it’s really my image who’s corrupt. I was able to recreate it with another PC with the fog version 1.2 and now I can deploy it on my HP Prodesk G3.

Thanks for your time

@egregers For a single drive there is no advantage. But I can say with my fleet of computers they are all dells and all are in the raid-on mode with a single drive. Its not clear why you are having this issue. But again I don’t have a T5810 to confirm or deny with. As always do you have the latest firmware installed on that T5810?

@Wayne-Workman The solution from Tom Elliott worked perfectly. However, after installing some software and trying to take a new image, new problems appeared. Will make a separate topic for this.

I’m going to update this thread because the only thing worse than finding no solution to your problem on Google is finding a problem listed without a solution.

These machines can in with 8gb of RAM. Some came in with 4 2gb sticks of memory and some came with 1 4gb and 2 2gb sticks. The machines without the 4gb stick work perfectly. They will image just fine. If I image them and then add the 4gb stick back in, they blue screen. So Tom was correct, it was a RAM issue. The 4gb stick of RAM is causing the issue. Thanks for all the help!

@Quazz Actually on the new Gen 4 there isn’t to many bloatware and “management” tools.

But I will actually look at building a native windows 10 enterprise 1607 iso.

No issues. It just worked.

The Gen1 (Legacy) adapter appears to still be only 100Mb.

@Dave-Misco So your issue is resolved?

I guess lets start with 2 questions.

What version of FOG are you using? On the T3620 are you using the built in RAID controller and have the disks in a RAID array? (I have a T3610 so I’m familiar with the model).

@dustindizzle11 Sorry for my late reply. There is a side way you could go with this now that you know how to modify the init.xz image. Grep yourself a copy of the current script and exchange the one you posted with this new one. See if you can make it work with this. Just an idea for a quick dirty fix.

Try different hdd exit types. Look up the host in Host Management, and on it’s general page you’ll see two drop downs towards the bottom for hdd exit types, one is BIOS the other is UEFI. so the mode that the computer is operating in determines which of these settings will apply. I would first recommend trying Grub, then if that doesn’t work just try one at a time - do a full reboot between each try.

@george1421 Yes the grub menu that is specified as exit. As with goes into bios i meant that even if i don’t boot to network (no cable), computer wont boot from deployed (Win10 image) hard drive and since it can’t find operating system it goes into bios settings. But that is problem with my image or with bios settings. Maybe the problem is only one partition i tend to merge recovery 500mb partition with the rest. But that is fixable i guess, i am just glad that now after fog upgrade the deployment to NVMe disks works. Also thank you for the tip about KBs updates for Win7.

@Tom-Elliott @george1421 you guys been a world of help and I just want to help back anyways I can with what I got.

So it is all good, I got the USB FOS disk working, but no need. All I had to do was use the OneLine+ Ethernet adapter and it resolved all my issues. I was able to capture and deploy images with in 2~5 mins. This X1 Gen 4 was a big headache but this PCIE 3.0 x4 SSD should be worth it… I hope.

@maria_reed Given that it works fine on other models, I’m guessing the issue here will come down to drivers. Some of them likely have slightly different hardware (bluetooth tends to be a bitch here) that will cause BSODs/reboots, etc

If not drivers, then most likely something to do with the unattend.xml file.

@george1421 I’ll double check and see if there are any updates and let you know 🙂 I didn’t actually think to check the firmware. cheers.

@Chubert There are some bits just need to be flushed out. The easies way is to use the fixparts command. If you reload windows you will end up in the same spot and only have accomplished just burning time.

IF you want to reload windows, use a brand new hard drive or one that has never seen a gpt format. That is the way around this issue.

You may be able to clean the disk (destructively) using this process. I say “may” because I haven’t done this route I use fixparts. https://technet.microsoft.com/en-us/library/cc725797(v=ws.11).aspx The downside is that you will have to reload windows and recreate your reference image.

@Sebastian-Roth You are right that firmware is for the fiber (10G) adapter. While it did fix the error in the log its not adding any real value for the OP or for FOG in general. But too, I’m still not seeing FOG as a good tool for cloning servers because of the other mix of hardware (you won’t find in desktops). I would say remove the firmware and have the OP test again now that its working in his environment (because the other roadblocks have been removed).

@george1421 it depends how the nic is designed to handle the fw but typically yes a full/cold power start should correct for that iteration.

@Wayne-Workman I already thought in create a virtual server to work as DHCP in a specific scope and connect the FOG server and the clients in this special scope.

I think is the only possibility inside my environment.

I can say I have both the Extreme 12 (7204) and Extreme 14 (7404) on my campus and I’m running the 1.3.0-rcX series of FOG and both image properly. I have mine setup in legacy (bios) mode. They imaged with our standard Win7 build. You will need the newer kernels to support the intel nics as well as the NVMe disk (if that is in your model).

@sloeckle Just for clarity I was wrong in my post. If you are running FOG 1.2.0 the newest kernels you can run must be less than version 4.4. That means you will need 4.1.X and less than 4.4.0. The kernels 4.4 and newer requires code that only exists in FOG 1.3.0.

Your final answer may be to upgrade to the 1.3.0-rc7 (or what ever is the latest in the 1.3.0 series.