Utilizing Postscripts (Rename, JoinDomain, Drivers, Snapins)

Tom Elliott

The beauty of the postdownloadscripts are that you can do whatever it is you need to do.

If we’re unsure of where to find the unattend.xml (or whatever you wanted to name it) you can use basic linux utilities to locate them.

For example, instead of:

#!/bin/bash
hostadpwd="ADPASSWDHERRE"; #only downside to this method- this is the plain ad password
unattend="/ntfs/Windows/Panther/unattend.xml";
[[ ! -f $unattend ]] && return
dots "Preparing Sysprep File"
rm -f /ntfs/Windows/System32/sysprep/unattend.xml >/dev/null 2>&1
if [[ ! $? -eq 0 ]]; then
    echo "Failed"
    debugPause
    handleError "Failed to remove original unattend file"
fi
echo "Done"
debugPause
dots "Writing Computer Name"
sed -i "/ComputerName/s/*/$hostname/g" $unattend >/dev/null 2>&1
if [[ ! $? -eq 0 ]]; then
    echo "Failed"
    debugPause
    handleError "Failed to update originating unattend file"
fi
echo "Done"
echo "ComputerName set to $hostname"
debugPause
[[ -z $addomain ]] && return
dots "Set PC to join the domain"
sed -i "/<JoinWorkgroup>/d" $unattend >/dev/null 2>&1
if [[ ! $? -eq 0 ]]; then
    echo "Failed"
    debugPause
    handleError "Failed to remove the Workgroup setter"
fi
sed -i \
    -e "s|<Password></Password>|<Password>${hostadpwd}</Password>|g" \
    -e "s|<Username></Username>|<Username>${addomain}\\\\${aduser}</Username>|g" \
    -e "s|<MachineObjectOU></MachineObjectOU>|<MachineObjectOU>${adou}</MachineObjectOU>|g" \
    -e "s|<JoinDomain></JoinDomain>|<JoinDomain>${addomain}</JoinDomain>|g" $unattend >/dev/null 2>&1
if [[ ! $? -eq 0 ]]; then
    echo "Failed"
    debugPause
    handleError "Failed to update user, pass, ou, and domain setter"
fi
echo "Done"
debugPause

You could actually locate any unattend.xml file and make the edits to them with:

#!/bin/bash
hostadpwd="ADPASSWDHERRE"; #only downside to this method- this is the plain ad password
unattends=$(find /ntfs/ -iname "unattend.xml")
for unattend in $unattends
    [[ ! -f $unattend ]] && return
    dots "Preparing Sysprep File"
    #rm -f /ntfs/Windows/System32/sysprep/unattend.xml >/dev/null 2>&1
    #if [[ ! $? -eq 0 ]]; then
        #echo "Failed"
        #debugPause
        #handleError "Failed to remove original unattend file"
    #fi
    echo "Done"
    debugPause
    dots "Writing Computer Name to $unattend"
    sed -i "/ComputerName/s/*/$hostname/g" $unattend >/dev/null 2>&1
    if [[ ! $? -eq 0 ]]; then
        echo "Failed"
        debugPause
        handleError "Failed to update originating unattend file"
    fi
    echo "Done"
    echo "ComputerName set to $hostname in $unattend"
    debugPause
    [[ -z $addomain ]] && continue
    dots "Set PC to join the domain"
    sed -i "/<JoinWorkgroup>/d" $unattend >/dev/null 2>&1
    if [[ ! $? -eq 0 ]]; then
        echo "Failed"
        debugPause
        handleError "Failed to remove the Workgroup setter"
    fi
    sed -i \
        -e "s|<Password></Password>|<Password>${hostadpwd}</Password>|g" \
        -e "s|<Username></Username>|<Username>${addomain}\\\\${aduser}</Username>|g" \
        -e "s|<MachineObjectOU></MachineObjectOU>|<MachineObjectOU>${adou}</MachineObjectOU>|g" \
        -e "s|<JoinDomain></JoinDomain>|<JoinDomain>${addomain}</JoinDomain>|g" $unattend >/dev/null 2>&1
    if [[ ! $? -eq 0 ]]; then
        echo "Failed"
        debugPause
        handleError "Failed to update user, pass, ou, and domain setter"
    fi
    echo "Done"
    debugPause
done

This will enable you to make the same edits to ANY unattend file found. I think this way is a bit more dynamic, and we’re not having to delete any files. You can also add a nested loop system to scan ANY partition for this to make the edits.

The intent of the postdownloadscripts are to allow people to do whatever it is they may need to do without having to continuously update their own scripts (of course are more than welcome if you feel you need to). So think of the postdownload scripts as a way to enable a kind of mechanism to enable the admins to make their edits however they deem necessary.

george1421

One point that I found if you use the /Windows/System32/sysprep folder, that name changes under Win10 to /Windows/System32/Sysprep this caused me a little pain (case change on the sysprep folder), until Tom gave me the hint to use find function. It does slow down the install a bit while find does its magic. You can cut down some of the time by specifying a path a bit closer like /ntfs/Windows since the unattend.xml file should be in there.

george1421

Two additional comments.

This is the search command I had to use on Centos 7 to find the unattend file in the sysprep folder. It was a bit of a cheat (not looping through the found entries, but this way I knew only one file would be returned).

 unattendfile=`find /ntfs/Windows -type f -iname "unattend.xml"|grep ystem32`

We since moved the only unattend file to the Panther folder since that is where Win10 searches first (we do specify the full path anyway when the system is sysprep’d). We did this to simplify the script since the case doesn’t change on Panther.

The second thing we do is use this sed search to replace the computer name (just in case there is something for the computer name that isn’t a star ( * ). Its a little be more complex of a regex expression but it works in all cases.

sed -i -e "s#<ComputerName>\([^<][^<]*\)</ComputerName>#<ComputerName>$hostname</ComputerName>#gi" $unattendfile

MarkP

I have been using the vendor/hardware ID to supply drivers to machines (this works well for the random bits we get from time to time that need re-imaging)

However would ideally like to be able to utilise the scripts in this document to download the drivers based on vendor and machine type, while still retaining the functionality of pulling the drivers if the machine type does not exist (if for instance we didn’t have Windows 10 drivers for a Dell Optiplex 3020 then it would pull drivers based on vendor and hardware ID).

Is anyone else doing anything like this or is it just not possible?

Thanks

Raj G

Hi all,

New user here, working with my team head to get a FOG server setup; all these scripts have been super useful for drivers and such. Just need to SysPrep our image and we’re good to go. That being said, I have a question about the Snap-Ins script here.

We have just about the same software setup for most of the users for a client we service; however, we have about half our users who have a full Office 365 (Office 2016 install) and the others don’t, while we have a hodgepodge of users that use some specific apps for their work (scattered between folks who use Office 2016 and not).

Do I simply put in the installation executables in the SnapinData/Map Files folders or does this script for Snap-Ins need to change? I’m not great at scripting at all, but I wondering what would need to change in this script.

Script from @Lee-Rowlett as follows:

#!/bin/sh
 
snpchk=`wget -O - --post-data="mac=${mac}" "http://${web}service/snapcheck.php" 2>/dev/null` #checks for snapintask
if [ "$snpchk" == "1" ]; then
    setupcmd="/ntfs/Windows/Setup/Scripts/SetupComplete.cmd";
    mkdir /ntfs/Windows/Setup/Scripts
    #this line below pulls my latest build script from server
    cp /fog/CompleteBuild/CompleteBuild.exe /ntfs/Windows/Setup/Scripts/CompleteBuild.exe  &>/dev/null
    #copies lastest setupcomplete.cmd from server
    #which only actually contains one line to execute
    #C:\Windows\Setup\Scripts\CompleteBuild.exe
    cp /fog/CompleteBuild/SetupComplete.cmd $setupcmd #above script
    sloc="/ntfs/Windows/Setup/Scripts/Node.txt"; # this is just so my above script
    #knows which node to use to run software from (if needed) left in to give you
    #guys ideas....
    echo "$storageip" >> "$sloc"; # writes node ip to the text file
    #next line gets snapin name
    snapname=`wget -O - --post-data="mac=${mac}&getSnapnames=1" "http://${web}service/snapcheck.php" 2>/dev/null`
    #next gets snapin argument/switch
    snaparg=`wget -O - --post-data="mac=${mac}&getSnapargs=1" "http://${web}service/snapcheck.php" 2>/dev/null`
    #this next line adds the switch to the setupcomplete.cmd
    # so if switch was /DefaultBuild .cmd line would now look like:
    #C:\Windows\Setup\Scripts\CompleteBuild.exe /DefaultBuild
    #if switch empty just nothing gets added
    sed -i -e "s|$| ${snaparg}|g" $setupcmd
 
    #this is self explanatory - some of our builds rely on 24GB of map files
    #rather than adding them to the "general" image
    #as it's the select few machines
    #i get fog to add it for me after imaging
    #so if they ever change, just update on server, job done.
    if [ "$snapname" == "MAP Build" -o "$snapname" == "Example Build" -o "$snapname" == "Test Build" ]; then
        dots "Downloading Map Files";
        echo "In Progress";
        rsync -a --info=progress2 "/fog/SnapinData/Map Files" /ntfs
        echo " * Downloading Map Files Completed.";
    fi
else
    echo "No Snapin Task Found - Snapin Setup Skipped";
fi```

Lee Rowlett

@Raj-G If you just put the executables in folder /fog/MapFiles they will just copy to root the of the imaged machine.

all the fog.snapins script does it put things in place, set which node to use and which snapin to run.

you’ll need to write the script to actually run and execute the installers etc… (setupcomplete.cmd)

if you are unsure or uncomfortable scripting, you may be better off with the FOG client doing all the work for you, it’s very stable and much better going forward to maintain your image.

this script/scenario is best suited if you already have another solution managing your clients but you want fog to handle the initial imaging. otherwise FOG Client is defo your friend

Raj G

@Lee-Rowlett
Silly question on the FOG client, but I gather you’re referring to the web client on the FOG server we’re using correct? The FOG Service on the host PC would pull from the information/data we have on the FOG server for printers, snap-ins, etc. correct?

Thanks!

Wayne Workman

@Raj-G said in Utilizing Postscripts (Rename, JoinDomain, Drivers, Snapins):

Silly question on the FOG client, but I gather you’re referring to the web client on the FOG server we’re using correct?

Correct.

@Raj-G said in Utilizing Postscripts (Rename, JoinDomain, Drivers, Snapins):

The FOG Service on the host PC would pull from the information/data we have on the FOG server for printers, snap-ins, etc. correct?

Right. You have to install this on your reference machine prior to image capture of course, and ensure it’s working before capturing by looking at the log file, typically located at C:\fog.log. The FOG Client is what enables lifetime management of hosts registered with the FOG Server.

You may also find this wiki article very informative:
https://wiki.fogproject.org/wiki/index.php?title=FOG_Client

Lee Rowlett

This post is deleted!

Raj G

This post is deleted!

agray

@Lee-Rowlett Would this still work with Win 10? If so, is this how you would do it?

if [ $osid == “5” -o $osid == “6” -o $osid == “7” -o $osid == "8" ]; #8 being for Win 10

Is there anything else I would need to change?

Lee Rowlett

@agray there are muc more uptodate versions of this done by @george1421 collaberating his version and mine which i’d suggest looking over but for just osid replace if statement with this:

case $osid in
    5) osn="Win7" ;;
    6) osn="Win8" ;;
    7) osn="Win8.1" ;;
    9) osn="Win10" ;;
esac

Tutorial By George

Utilizing Postscripts (Rename, JoinDomain, Drivers, Snapins)

138

11.7k

17.2k

154.7k