@Joe-Schmitt said in Snapin Pack:

the one thing I’m seeing from those screenshots is that you have a sub-directory in your zip file.

I knew this would be confusing for folks, and there’s no way around it, people just need to understand the pathing. It took me months of here-and-there moments to wrap my head around it. So nobody would have to go through that, In the SnapinPacks wiki article, I explained this at very great length.
https://wiki.fogproject.org/wiki/index.php?title=SnapinPacks

@sapeurorca highly recommend updating to the RC builds. You may not want to but I’m confident it will improve your chances of success.

@Wayne-Workman Alright, I will have to test it out. Thanks!

Thanks for the tip @george1421 I’m not sure it works for the scenario I am working on, but none the less, good idea for future items too, more than just name changes.

@coldenburg Did you try a mini-switch yet?

Depending on your hardware, you may need the right driver.

Or if you’re in a VM, you need to select the right device to emulate.

Read through this, ask if you still have issues.
https://wiki.fogproject.org/wiki/index.php?title=FOG_Client#FOG_Client_with_Sysprep

@DEMONTECH
You need to run the Fogcrypt command passing all the path where fogcrypt file is, or add the location to path variable.
eg. “C:\Test\FogCrypt.exe” …

an advice:
when you hear: “legacy client”, run in the opposite direction as fast as possible … save your life … 🙂

@Wayne-Workman said in FOG Client Service Updater:

If you go the PDQ route, be sure to include some way to first remove the legacy client. If it’s still there, the new client will not install.

Following Wayne’s instructions then you should create a batch script and deploy that with PDQ Deploy.

In that batch script you will issue the FOG client uninstall command

@echo off msiexe /X <guid of fog client> REM then install the new FOG client with msiexec /i fogclient.msi <what ever option switches>

Thanks George and Wayne for your advise.

@Wayne-Workman Thanks! That worked!

@Wayne-Workman said in Setup is preparing your computer for first use after imaging:

You should read this:
https://wiki.fogproject.org/wiki/index.php?title=FOG_Client#FOG_Client_with_Sysprep

Also, sounds like you need to update the fog server too. 7981 is behind, we already have release candidates.

I’m going to bet this is the solution… I’m rebuilding the image now, and will disable the service (I never saw that Wiki page before - lots of good info). I also just updated to the Release Candidate (using Git), so hopefully that combination works.

@Quazz

You are the best @Quazz it’s good everything is working properly now
And thank you for taking the time to Have Reply

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