Another Domain Join Issue
-
@Jay-Bosworth Ok, re-reading the whole topic again I think we should try to tackle this from scratch again:
- Have the new 0.11.16 fog-client installed before capturing the image.
- Exchange the file
C:\Program Files (x64)\FOG\Modules.dll
with the one downloaded here. - Make sure there is no task scheduled for the host you want to test this on (as we have seen in one of the fog.log files)!
- Enable the checkbox to forced rename/join for this host (FOG web UI -> host list -> test host’s settings -> Active Directory tab -> Name Change/AD Join Forced reboot?
Now deploy the machine, let it boot up, wait for it to do all the automatic background stuff plus another 10 minutes. Then grab a copy of
fog.log
and post here. -
@Sebastian-Roth Okay, I am apparently a bit of a dolt, but it has led to another issue along the same lines… Let me explain.
Somewhere between upgrading to the new FOG client 0.11.16 and capturing my audit image, I failed to create the scripts folder and add my setup complete file to it. FOG Service was remaining disabled, that is why the log file was recording no information.
I took care of that and recaptured the image. Now when I deploy the image, it is not starting the FOG service it is setting the service to “automatic” but the service is never actually starting. Each time I go into the system after restarting, the FOG service is stopped. Is there something I needed to change in the setupcomplete file for the new FOG client?
This is the contents of my setupcomplete file that I have been using flawlessly for the past several years:
sc config FOGService start= auto
shutdown -t 0 -rThank you,
-
@Jay-Bosworth try this (ref
sc.exe config FOGService start=delayed-auto sc.exe failure FOGService actions= restart/60000/restart/60000/restart/ reset= 120
-
@Sebastian-Roth I replaced the code I had in my “setupcomplete” file with what you sent me in the previous message. I am still seeing the same behavior. After deploy, the Fog service is stopped even though it is set to Delayed-Automatic. When I try to start the Fog Service manually, it immediately stops. I don’t see anything in the FOG log that indicates why it is immediately stopping.
I went into Event viewer and here are the two errors it is showing when I try to start the service.
-
@Jay-Bosworth Can you please scroll further down in the message for the second event log entry where it says: “Exception Info: System.IO.FileNotFoundException” - does it say which file is not found??
-
@Sebastian-Roth Is this what you need?
-
@Jay-Bosworth Do you have the file
Modules.dll
inC:\Program Files (x86)\FOG\
?? -
@Sebastian-Roth Let me check that. I have had to change my audit and sysprep images so many times through this troubleshooting that it is possible I moved the file you sent into the folder and didn’t rename it to modules.dll.
-
@Sebastian-Roth I think we are close. FOG is still not starting automatically though. I checked the event viewer and there are no errors there so I think it just isn’t getting the command to start as opposed to last time when it was trying but was erroring out. I tried starting it manually and then restarting and it does eventually start running in that case. Without doing that, I have been waiting about 45 minutes and the status hasn’t changed to running yet.
-
@Jay-Bosworth Do you have all the latest Windows updates installed on the image before capturing? Just asking because we have reports of the FOG client failing on systems where Windows Update kicks in.
It sounds strange that the service wouldn’t properly start by itself. Have not seen this before. Do other services start normally?
-
@Sebastian-Roth Yes, all of the Windows updates have been applied. I do all of that before I capture my audit image. I even double checked this time before I created it. Other services appear to be starting just fine.
-
@Jay-Bosworth Do you see if the service is starting and crashing over and over again?
-
@Sebastian-Roth No, nothing in the event viewer like the last time. Like I said, if I manually start the service the first time it then automatically starts after about ten minutes or so on subsequent reboots.
-
@Jay-Bosworth
Jay on a side note while the guys are trying to troubleshoot the problem with services, ect., can you go ahead and try to spin up a new virtual machine and load widows from scratch. Mabey every try audit mode again but dont disable services (i never do and it works perfect) like you mentioned in your original post. Just install fog client and %WINDIR%\system32\sysprep\sysprep.exe /generalize /shutdown /oobe
If your running a unattended.xml, please make sure your not doing post scripts for the test. Just try to make it as bare bones as possible. This will test to make sure
1 your fog enviroment is running functionally
2 you are building your windows images correctlyIf it works, you need to evaluate on how your building your images.
If it doesnt work, then im going to leave it to the other guys -
@David-Osinski Okay, I can try to start from scratch. It has been working fine for years with dozens of images that I created, so I am pretty sure that process is fine. I might have missed something on the past two I created, but I kind of doubt it. The only thing that is really different this time is the addition of the 1903 update.
-
I think we can chalk this one up as solved. I went back to my original audit image and I undid pretty much everything I had tried with the exception of using the newer FOG client. With my original SetupComplete file and everything else back to the way it was, it seems to be working now.
I truly believe the fix was just a matter of updating the FOG client to 11.16 I apologize for all of the hassle but I appreciate all of the help you tried to give me.
-
I have been experiencing similar issues since moving to 1903… Though I am using the 11.16 FOG client. I didn’t find that adding those two sc.exe lines in my SetupComplete helped, and after checking for errors I have ruled out the Win update issue. I am considering starting a new image from scratch again, because like Jay, I’ve gone through about a dozen different changes and might be missing something crucial.
@Sebastian-Roth Is that Modules.dll for a small fix or for debugging? I’ve seen on other posts that you can join domain the in unattend.xml file. Is there a way to join domain AND change the name?
Looking for any sort of fix or recommendations here. For now, I’m fine with throwing some duct tape on it to get back off the ground!
-
@ayy_nelson said in Another Domain Join Issue:
I have been experiencing similar issues since moving to 1903
Did you do an in-place upgrade or fresh install of 1903??
What do you mean by similar? The fog-client software not joining a domain or renaming the host can have a dozen or so different reasons. I’d suggest you post you full story in a new topic, add a full fog-client log and we’ll have a look at it.
Is that Modules.dll for a small fix or for debugging?
Only debugging.
I’ve seen on other posts that you can join domain the in unattend.xml file. Is there a way to join domain AND change the name?
I am not an expert on unattend.xml stuff. Maybe @george1421 can give you an answer on this.
-
@ayy_nelson said in Another Domain Join Issue:
Is there a way to join domain AND change the name?
Yes there is. In my case I don’t use the FOG Client at all for regulatory reasons. So I do everything in the unattend.xml file. My unattend.xml file connect the computer to AD as well as sets its host name. I do this using a FOG Post install script that connects to the windows drive just after the image is copied, updates the unattend.xml file with deploy time data, and finally disconnects from the drive before FOG finishes its deploy sequence.
The post install script how to is covered here: https://forums.fogproject.org/topic/11126/using-fog-postinstall-scripts-for-windows-driver-injection-2017-ed
You are probably most interested in the “fog.updateunattend” script. I know the sed scripts will melt your brain, but that’s where all of the action is. They search for the key word(s) then replace the key words with the keywords + the proper values.
Here is a sanatized version of my unattend.xml script. I’m using the same one for Win10 1903 as I used for Win7. https://forums.fogproject.org/topic/11920/windows-10-1803-sysprep-problem/7 The point is if its in a text file and can be searched by
sed
the value(s) can be replaced bysed