Another Domain Join Issue

Jay Bosworth

@Sebastian-Roth Thanks for the reply. Here is the screenshot:

As I said, nothing has been physically changed on the server from this work vs. not working. The only key thing that has been changed is I am using Windows 10 1903 instead of 17xx in my audit image.

Sebastian Roth

@Jay-Bosworth said in Another Domain Join Issue:

The only key thing that has been changed is I am using Windows 10 1903 instead of 17xx in my audit image.

While I don’t have a 1903 machine in my test environment yet I don’t think this is actually causing the problem. We’d have way more issue reports on this if there’d really be a problem with 1903 in general I suppose.

Thanks for the picture. My guess was you had the option Join Domain after deploy unchecked but it’s not.

I really wonder why HostnameChanger module does not seem to try to join at all. I might compile a new Modules.dll for you later on so we know what exactly it does. Will get back to you in about two hours.

Jay Bosworth

@Sebastian-Roth Okay, thank you. I will adjust my audit image and add the new client. Maybe it not having to update that will fix things.

Sebastian Roth

@Jay-Bosworth Before you deploy your next machine may I ask you to use this debug enabled Modules.dll so we get more helpful output in the log file: https://github.com/FOGProject/fog-client/releases/download/0.11.16/Modules_debug_HostnameChanger.dll

Stop FOGService (Windows services.msc), then go to C:\Program Files (x86)\FOG\ and rename Modules.dll. Now download the one from above and put in place of the original one. Now capture your master image from that machine and deploy to another host. Please grab fog.log after deployment and post the full contents here.

Jay Bosworth

@Sebastian-Roth Oh crap, I already captured my image already. I am running out of time today, so I might not be able try and create a whole new image again until tomorrow.

Sebastian Roth

@Jay-Bosworth There is an easy way around this. Don’t start the host immediately after you deployed the image to it. Copy the downloaded Modules.dll to a USB drive. Then schedule another debug deploy task for this same host, PXE boot it and when you get to the shell run the following commands (assuming your hard disk drive is /dev/sda and your USB drive is /dev/sdb

mkdir -p /mnt/usb
mkdir -p /mnt/win
mount /dev/sdb1 /mnt/usb
mount /dev/sdaX /mnt/win
cd /mnt/win/Program\ Files\ \(x86\)/FOG/
mv Modules.dll Modules_orig.dll
cp /mnt/usb/Modules.dll .
cd
umount /mnt/win
umount /mnt/usb

Something along these lines. This is untested and I can’t promise you it’s working exactly like this as I don’t know your partition layout or drive specs.

george1421

@Sebastian-Roth @Jay-Bosworth Understand I’ve only read the last 2 posts, so I’m not sure where the thread is headed.

BUT I can offer a comment. During Windows golden image development I’ve used a modified post download script (similar to the one for sending the drivers to the target computer) to patch the unattend.xml and replace dlls in a previously captured image. I only did this during golden image development or until the next time I built a golden image.

The principles of this is outlined in this article: https://forums.fogproject.org/topic/11126/using-fog-postinstall-scripts-for-windows-driver-injection-2017-ed

The fog.copydrivers script could be modified to just copy over the one needed file from the fog server. In this section. Where clientdriverpath is the destination path and remotedriverpath is the path of the files to copy.

dots "Preparing Drivers"
clientdriverpath="/ntfs/Drivers"
remotedriverpath="/images/drivers/$machine/$osn/$arch"

debugPause

if [[ ! -d "${remotedriverpath}" ]]; then
    echo "failed";
    echo " ! Driver package not found for ${machine}/$osn/$arch ! ";
    debugPause;
    return;
fi
echo "Ready";

debugPause

[[ ! -d $clientdriverpath ]] && mkdir -p "$clientdriverpath" >/dev/null 2>&1
echo -n "In Progress"

rsync -aqz "$remotedriverpath" "$clientdriverpath" >/dev/null 2>&1

[[ ! $? -eq 0 ]] && handleError "Failed to download driver information for [$machine/$osn/$arch]"

debugPause

Jay Bosworth

I apologize, I had to put this on the back burner for a couple of days. It is the beginning of the school year and things are nuts. I am starting to wonder if it does have something to do with my Sysprep process and changes between 17xx and 19xx that the file doesn’t like. When I pushed my audit image to remove the older FOG client and install the newer one, I forgot to uncheck the box in FOG that says “Name Change/AD Join Forced Reboot”. As soon as I installed the new FOG client on the audit image, it joined itself to the domain. I wiped it back to my original audit image and followed the same process but I first unchecked that box. I uploaded my audit image and then rechecked that box before uploading my sysprepped image. Upon deploy the sysprep image will still not automatically join to my domain.

Sebastian Roth

@Jay-Bosworth said in Another Domain Join Issue:

Upon deploy the sysprep image will still not automatically join to my domain.

Did you use the Modules.dll I provided? Please check the fog.log file on the client an post here.

Jay Bosworth

@Sebastian-Roth No, this was just something I noticed before you posted that request. Sorry, like I said, things have been nuts and I am a couple of days behind to work on this.

Jay Bosworth

@Sebastian-Roth I apologize for the log delay in this. Here is the file after I used the other Modules.dll file.fog.log

Sebastian Roth

@Jay-Bosworth Sorry but there is no valuable information in that log. every loop cycle on hostname changer is either “Users still logged in and enforce is disabled, delaying any further actions” or “A power operation is pending, aborting module” (offical scheduled reboot via fog-client). We can’t help you if we don’t see what’s exactly going on when it tries to join.

Jay Bosworth

@Sebastian-Roth So that’s it? I am just SOL? I can’t really change what it is doing automatically. I did exactly what you asked me to.

george1421

@Jay-Bosworth Its possible that changes in release 1903 have caused difficulties with the fog client. I’ve noticed a lot of posts regarding the fog client and 1903 lately. There has to be something going on that we don’t understand just jet.

While I can’t really help with the fog level connect to domain, I can say that I don’t use the fog client for naming the host or connecting it to AD, I let the unattend.xml file do that. I don’t have a problem using this method.

Quazz

@Jay-Bosworth That client is awaiting a scheduled reboot as far as I can tell, which is why other actions aren’t happening, you need to sort that out before any useful info is logged to begin with.

Jay Bosworth

@george1421 Thanks for the reply. That makes sense to me. I figured it has to be something small and new with 1903 because it never happened before and nothing on my server has changed. Luckily right now I only have a handful of machines to image and I can wait it out until a new version comes out or something. Worst case as you said, I can add it to my unattend file. Thanks again.

Sebastian Roth

@george1421 While we did have several requests about fog-client issues on Windows 10 1903 none of them had clearly to do with 1903 as far as I remember (feel free to prove me wrong on this - I have so many things going on and can’t follow it all 100%).

@Jay-Bosworth From the logs posted so far I simply can’t see there being a fog-client issue. Don’t get me wrong. I am not saying there is none but we just have not nailed it down if there is one!

Sebastian Roth

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

Jay Bosworth

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

Thank you,

Sebastian Roth

@Jay-Bosworth try this (ref

sc.exe config FOGService start=delayed-auto
sc.exe failure FOGService actions= restart/60000/restart/60000/restart/ reset= 120

Another Domain Join Issue

269

11.6k

17.1k

154.6k