@Joe-Gill said in AD Re-Join?:

Basically it’s caused by NOT sysprepping machines. Hence the reason you’ve never seen it before… This lab was NOT sysprepped… Ugh!!

We don’t sysprep. 4,500+ machines.

Sounds like the image isn’t clean, to me.

When I make images - they absolutely never are allowed to be on the domain. If they accidentally get put on the domain by fog or us - we start over. Our images are absolutely clean. We always start with a clean slate.

The issue could also be that - your image was joined to the domain during capture.

@Wayne-Workman

Bad sectors on the hard drive caused disc part to fail after 2.7gb of 63gb, so I imagine windows was literally waiting to load files that did not exist… solved! Different machine, Fog uploaded the image and deployed it flawlessly!

@Tom-Elliott
@Wayne-Workman

Windows 7 Pro. I didn’t intend to use legacy client in that lab. It happened to be one I completed earlier in the Summer.

Is their an easy way to upgrade the client on those machines?

Have you checked what the settings are under SATA Operation in the BIOS/UEFI? I noticed on some of our machines if SATA operation is set to ATA on the image and then the machine was set to AHCI or SCSI that it would not image properly. The image installs correctly and it starts to boot but it does not function at all until you change the setting in the BIOS/UEFI.

Cheers!

Joe

@Tom-Elliott Wanted to clarify what @Scott-Adams was saying for future readers.

If you have a host that is pre-existing in FOG, and you then set AD defaults, those don’t automatically get applied to already-existing hosts. If you want to re-set or re-assign or update AD settings on pre-existing hosts enmass, use groups to do it.

Code 87 threads. I glanced through these, most are configuration issues - people not re-assigning settings to the individual hosts.

https://forums.fogproject.org/topic/3846/domain-join-not-working-since-moving-to-v1-2-0-error-87/4

https://forums.fogproject.org/topic/8341/the-parameter-is-incorrect-code-87

https://forums.fogproject.org/topic/1937/help-with-domain-joing

https://forums.fogproject.org/topic/5812/samba-domain-integration/61

https://forums.fogproject.org/topic/6879/i-can-t-join-machines-on-domain

https://forums.fogproject.org/topic/7126/hosts-unable-to-join-domain

https://forums.fogproject.org/topic/3140/domain-join-is-not-working-fog-server-1-1-1

@Wayne-Workman I agree with you, in working in a lab environment in which we perform all kinds of penetration/defensive tests, I need people to be able to save their work before their stuff gets nuked. It wouldn’t hurt anything to have free control of how long the pop-up will stay up.

FOG 1.2.0 and the legacy fog client does not support windows 10. You need the newer version of fog (1.3.0-rcX at the time of this post) and the new fog client (0.9.X or newer) for win10 support.

For sure you will need the 1.3.0 series for native FOG server support for uefi firmware, gpt disk format, NVMe disks, and Win10 support running on current hardware (i.e. latests FOS engine running linux 4.7).

Well it looks like this is definitely a problem with this model of laptop. The Windows 7 Enterprise installer finished copying and expanding all of it’s files and then as soon as the first reboot happens the computer hangs at the same black screen I receive after imaging it. Looks like I’m destined for the HP support line to kick this up the chain for a fix :(.

Edit: I just rebooted without the network cable plugged in and now the installer continued without an issue. More testing needed but maybe an issue with how the FOG boot menu is handing back off to the boot cycle on this model. I’ll update once I’ve done more thorough testing.

Edit 2: The solution for this is that the “Host Bios Exit Type” for this model must be set to “GRUB” or it will hang before the OOBE portion of the Windows install process starts. “SANBOOT” causes this 100% of the time on our units and “EXIT” returns an error. Presumably any of the “GRUB” options would work but I haven’t verified any other than the basic “GRUB” option.

For future readers - FOG 1.2.0 has poor support for Windows 10, and the legacy fog client that comes with FOG 1.2.0 isn’t supported on Windows 10.

To gain full support for Windows 10, GPT disks, UEFI, newer nvme type disks, SSD disks, and numerous other hardware support to include Surface Pros, and better support for non-standard partition layout, along with incredible performance improvements, new features, and security benefits,

Please install the latest FOG 1.3.0 Release Candidate, and use the new FOG Client that comes with it.

25% Packetloss… Guess China’s firewall doesn’t like it…

Sorry for the prolonged absence. I’ve created a new legacy image, using the same driver deployment process. This image deploys successfully to the Z70-80. There are some other machines that we absolutely do need the legacy image for, so it’s not too much overhead to just use that image for the Z70-80.

@Wayne-Workman We do. 🙂 I tried that, we’ll see what happens! As you know our domain setup needs improvement. I’m doing my best to straighten it out. Ugh!

@BedCruncher said in Host does not boot into PXE after reboot:

@Joe-Gill
I would suggest setting network boot as first priority and then setting a timeout of 5 seconds on the menu so that if there is no task, then at most your boot time is impacted maybe 40 seconds.

You can also “hide” the fog boot menu. It’s an option inside Web Interface -> FOG Configuration -> iPXE Boot Menu

There’s also the “no menu” option.

There’s a hide timeout, and a regular timeout. The regular time out applies when hiding isn’t being used.

OP had AntiVirus installing inside SetupComplete.cmd before the FOG Client was re-enabled and started. The specific AntiVirus installation caused a reboot, which left the SetupComplete.cmd un-finished, and therefore all these other problems happened.

Consider building a snapin for the AntiVirus, which will auto-queue for any computer that is told to image and has the snapin associated with it, and the snapin will deploy after imaging is completed.

@MattPayerle said in FOG Client on Windows does not create host record on server:

the GIT pull runs but then doesn’t change the version number.

You have to re-run the installer.

@kyle.heath Does the bios updates only run in windows or is there a DOS option?

In our case we use a WinPE boot disk that has all of our dell bios drivers on it. We boot from usb flash drive that has WinPE on it then we launch the proper bios driver to update the system. We have scripted an automated process for this now, but that is the basics of how we install a consistent bios version on all of our bare metal computers (we use a winpe boot disk).

@PageTown I know it was a long path to get to this point, BUT know in your heart you are in a better place for the pain you went through. (just channeling Dr. Phil).

You are on a current and supported release of the your OS and for FOG. When 1.3.0 stable is finally released you will be on a solid platform that you can use for a few years.

@Tom-Elliott I have tried a VBScript and have been unable to run it on the domain without having admin rights. How would I set admin rights with VBscript?

@Wayne-Workman I thought about something like that but did not know if it would work or not.

I’ll be working on this stuff more later this week. I may try that.

Cheers,

Joe Gill