Weird Snap-in script behavior

[Stuffandsht]

Hello, I have a strange problem with snap-ins that I’m losing my mind over. I have a situation where I need to push an image to a computer lab and the computers need to be joined to a different domain than the fog server is connected to. I’ve done testing with offline domain joining using djoin.exe and it’s been working well. I push the image to the computer, then use a snapin pack to transfer all of the djoin provisioning files to the lab, then each machine copies the one that it needs to another folder and tries to request the djoin. After I djoin them, I can connect them to the other network, reboot them, then they’ll pull policy and work as expected.

If I have it copy the following script to the desktop and then I run it as admin, it works fine. I can also use psexec to start cmd as SYSTEM and the script also works. However, when I have FOG execute the script as part of the snapin pack, it just skips over the djoin command. I can see the provisioning package on the C drive and the script on the desktop, but the djoin never goes off.

cd %~dp0
xcopy %computername%.txt c:\ /y
djoin /requestodj /loadfile c:\%computername%.txt /windowspath %systemroot% /localos
xcopy ~OfflineJoin.bat "C:\users\*******\desktop\" /i /y

To try to see what was going on, I added a redirect to see if djoin was posting any errors or anything

cd %~dp0>c:\log.txt
xcopy %computername%.txt c:\ /y>>c:\log.txt
djoin /requestodj /loadfile c:\%computername%.txt /windowspath %systemroot% /localos >>c:\log.txt
xcopy ~OfflineJoin.bat "C:\users\********\desktop\" /i /y >>c:\log.txt

The contents of that file are

C:********-******.txt
1 File(s) copied
C:~OfflineJoin.bat
1 File(s) copied

If I run that script as SYSTEM, I get this

C:********-******.txt
1 File(s) copied
Loading provisioning data from the following file: [c:\********-******.txt].



The provisioning request completed successfully.

A reboot is required for changes to be applied.

The operation completed successfully.

C:~OfflineJoin.bat
0 File(s) copied

I tried one more method just to see if I could get it to work, and it also failed. I changed the snapin pack arguments to the following:

/c "djoin /requestodj /loadfile "[FOG_SNAPIN_PATH]\%computername%.txt" /windowspath %systemroot% /localos"

I’m really at a loss here. I don’t understand why it just won’t run the djoin command as part of the snapin. Does anyone have any suggestions for me?

[george1421]

@stuffandsht Let me make sure I understand the situation here because fog server doesn’t care about windows domains or DNS domains for that matter.

You are pushing out an image that has never been joined to a domain. You need to connect this computer to a domain.?? You can use fog for this if you have the fog client on the target computer. OR you can have the unattend.xml file do this if you sysprep the image.

In my case I use the latter since I don’t have the fog client installed on my target images. To take it a step more I also use a post install script to not only set which domain to connect to, I also update the unattend.xml script to place the computer in the proper OU. During OOBE/WinSetup the computer needs to be an OU that doesn’t have certain GPO policies attached, so in the setupcomplete.cmd batch file I have call a VB script (could be updated to a PS script0 to move the computer from the imaging OU to the destination OU. This destination OU is calculated by the post install script based on the site the image is being deployed and the image name that is being pushed. I know its a bit more complicated than you probably need here.

Back to your post, what is actually failing the join to domain or the copy command? Remember the FOG client runs as SYSTEM and SYSTEM only has local admin rights and zero rights outside of the local computer. We have just seen lately that SYSTEM doesn’t have rights to install printers now. So MS is restricting what SYSTEM can do too.

Edit looking at the post a bit more, you may need to run the djoin command as a user that has rights to add computers to your domain. SYSTEM can’t do that.

[Stuffandsht]

@george1421 Correct. The image has never been joined to the domain. I also include the fog client in all of my images. I also don’t sysprep the image as I’ve never run into any issues before with it. The main problem here is that fog doesn’t have access to the domain that the computers need joined to. Lets say that in my network, FOG is running on vlan101 with the abc.net domain. After I push the image, I need to manually switch all the computers in the lab over to vlan102 and join them to the def.net domain.

I have a script that I run as a domain administrator on a domain connected computer in def.net. It generates a djoin.exe provision package for each computer in the lab and I push them to the clients with the snapin pack.

The problem is that the djoin.exe command in the batch file that the snapin is running just doesn’t execute or something. I can run the script myself using “psexec.exe -i -s cmd.exe” then calling the batch file, and everything works as expected. You can see in the 3rd and 4th block in my first post the difference between FOG running the script and me running the script. When fog does it, it just skips over the djoin line it seems.

“Edit looking at the post a bit more, you may need to run the djoin command as a user that has rights to add computers to your domain. SYSTEM can’t do that.”
The user running the script doesn’t need rights in the domain. I’m able to run from the local admin account on the system just fine, as well as the SYSTEM profile. The authorization comes from generating the package from a domain account on another computer.

[george1421]

@stuffandsht said in Weird Snap-in script behavior:

When fog does it, it just skips over the djoin line it seems.

That SYSTEM account is special that the FOG service runs as. It would be interesting to see if you can cast the user account that runs the service to a low level domain user using the runas command. Acutally I don’t think the runas command will work because you can’t embed a password in the command.

Maybe something like this psexec -user domain\userr -p password "cmd" would work better. I would think too if you had the djoin.exe as part of your base image (cause you will always need to run it) you could just preload it on your golden image then your snapin task would be just to run the psexec command or call the batch file directly. In your batch file you could also include a flag creation just to prove the batch file is executing something like echo hello > c:\windows\temp\djoin.txt much like you are piping the results of the djoin command into a log file. If you see the djoin.txt file but not the log file then its something in the djoin.

Another debugging step is to see if you can from within windows use the gui run as to switch to SYSTEM user. Then try to run the command as SYSTEM. See if there are any useful console messages that come back.

[Sebastian Roth]

@Stuffandsht From what I see in your post you have done a fair amount of testing already. I too find it strange that running your script as SYSTEM works when running it manually but seems to not do the right thing when running it as a snapin.

For debugging I suggest you copy the djoin line and add echo in front of the first one to actually see the full command. As well add output redirection for stdout and stderr to the actual call:

...
echo djoin ...  >C:\temp\djoin_cmd.log
djoin ... >C:\temp\djoin.log 2>C:\temp\djoin_err.log
...