FOG Multicast Issues / AD Join Issue
First off I’m using FOG Running Version 8515 SVN revision 5882…
@Developers So the past couple labs I’ve fogged (using Multicast) I’m finding that some machines hang at the Particlone screen. Most times when this happens I let it sit for 10 - 15 minutes just to make sure I’m not jumping the gun before I pull the trigger on it and kill the process and clean up the SQL database. After I do this and restart the service on the server and fog storage server, things work fine. I might have 1 or 2 or 8 hosts out of a multicast session that do this. I haven’t had one session go perfect where every single host is successful from the beginning.
Is their any particular reason this occurs?
@Joe-Schmitt Also, I have had an issue with hosts joining the AD post image. The message I get is, “The trust relationship between this workstation and the primary domain failed.” I haven’t seen this until a recent FOG update. The client version that is installed on these machines is Ver. 0.11.3. Our AD server is Windows Server 2008
My process when I FOG the machines is to install all host software, add fog client, add to domain, then fog. I add to domain to get user specific shortcuts installed on their desktop.
Any advice is greatly appreciated!
@Joe-Gill How is it better to do it manually, when powershell can do the same identical thing but faster and in mass and without visiting each computer? It’s simple:
Remove-Computer -UnjoinDomaincredential Domain01\Admin01 -PassThru -Verbose -Restart
Only thing to remember is to definitely delete the snapin after you’re done with it, because it’s associated it’ll run every time you image - which would cause problems.
@Wayne-Workman Thanks! That may be an option down the road. The other admin wasn’t too concerned. He said we will be re-doing our AD entirely next school year. At this point in the game, he seems fine with re-adding all the hosts manually to the domian… PITA in my opinion but… I guess it is what is is.
If you got that route, you must/should really use the built in snapin reboot option . That option exists for a reason.
@Joe-Gill It could be possible to use snapins to deploy a powershell script that would un-join all computers, give a reboot too using either powershell or the snapins reboot option. You’d delete all hosts from AD before this. Then, the FOG Client should just join them all back.
Thanks for the advice. We’ll figure it out. I’m sure it’ll be more work but at least we’ll have a clean slate. The good thing is that all of the hosts have been registered with FOG server. So it won’t be as much work as it has been up until now. Plus the multicast issues have been mostly resolved so that’s a plus. Gotta stay positive!
@Joe-Gill I am in a different position in terms of setup than you are probably.
Personally, I’d delete all the computers from AD, correct the image, and then just re-image the building.
I have WOL turned on for all computers. I have NIC set as first boot option on all computers. I have all computers registered. I have all computers in the building connected to power and network. My FOG server is live, and on our production network.
You may be in a different situation though. You have to figure out what’s best for you.
@Wayne-Workman More like a disaster that IS happening! smh… Live and learn. Better now to figure this out than once school is in session. Any advice on how to straighten it out? I’ll have to re-add everything that is out there… I’m assuming it’ll need to get corrected in AD…
Like I said, I’m the new guy… Arrf!
I might have 1 or 2 or 8 hosts out of a multicast session that do this. I haven’t had one session go perfect where every single host is successful from the beginning.
Is their any particular reason this occurs?
Bad patch cables, bad drops, bad ports on the switch, loose connections. The simple things commonly cause this.
Having your source image be part of the domain is a mess waiting to happen
Not just a mess waiting to happen, It’s an absolute disaster that will happen.
@Joe-Schmitt Good to know now. It’ll be a mess to straighten out now.
I tested the theory out on one machine that was not joining the domain properly and added it to a workgroup. Rebooted and voila, it’s happily on the domain. I’ll have to go check everything. Live and learn.
Nothing has changed concerning how the client binds a machine to the domain since v0.8 or so. Having your source image be part of the domain is a mess waiting to happen, especially if you didn’t sysprep.
Essentially all your machines post-imaged have the same security ids, the same domain binding and membership, the same everything. So right out of the gate post-imaged they would have massive domain membership conflicts.
@Joe-Schmitt What’s crazy is that I didn’t have any issue (that I’m aware of) doing it that way before. I’ll start changing my images.
If you are using the client to join AD after imaging, do not join your image to the domain. More than likely that is causing your issue.