NEW osName for Windows 10 Builds

[klaus.jauk]

I use FOG 1.5.4 and generate unattend.xml for Windows Setup and Domainjoin automatically . To seperate the unattend.xml for different Windows 10 Builds I added in the Database:

±-----±----------------±----------------+
| osID | osName | osDescription |
±-----±----------------±----------------+
| 51 | Chromium OS | Chromium OS |
| 100 | W10_LTSC | Windows 10 LTSC |
| 101 | W10_LTSB | Windows 10 LTSB |
| 102 | W10_1703 | Windows 10 1703 |

At ID 102 I got the error “invalid OS_ID”. Is there a check in the System ?
I couldn’t find a database-schema or system values to resolve the error.

Best regards
Klaus

[george1421]

I’m pretty sure you can’t add OS IDs that way and expect FOG to understand them. Well you can add them to the database but the innerworkings of FOG will not understand them.

What is your real goal here? I have a complex domain structure in my company so I don’t use FOG to connect the target computer to AD, but instead use the unattend.xml file with some post install scripts to calculate the target OU, then update the unattend.xml file before WinSetup runs. What are you trying to accomplish here?

[klaus.jauk]

@george1421 said in NEW osName for Windows 10 Builds:

What is your real goal here? I have a complex domain structure in my company so I don’t use FOG to connect the target computer to AD, but instead use the unattend.xml file with some post install scripts to calculate the target OU, then update the unattend.xml file before WinSetup runs. What are you trying to accomplish here?

Hi George, thank you for your answer.

My Situation: We use 5 Fog Server with more than 30 Images and different os (Win7, Win8.1 and Win10 different builds). The goal is to integrate all images into 1 new FOG System.

To do this, I have to seperate in unattend.xml:

• kms product-key
• input and system-locale (differnet locations and languages)
• wireless settings
• OU’s
• Domains

Actually I use different unattend.xml files.

Also I have to split drivers and ms-hotfixes for the differnt os and builds.
I will not do this with $ImageID in FOS. $OsID would be the best way I think.

Best regards
Klaus

[george1421]

@klaus-jauk Well I can say you do have a complex situation. You might not be able to do everything with this method but you should be able to automate most of things.

The concept is this: FOG has the ability to run bash scripts during imaging. This bash scripts run from the perspective of FOS. Once set of scripts can run just before FOS starts imaging (postinit) and the second set of scripts run just after the image has been placed on the target computer but before FOS exits (post install). In this case you will want to focus on the post install scripts. In my environment I use the post install scripts to copy the model specific drivers to the target computer as well as update the unattend.xml file with the (calculated) location specific information.

The concept is covered in this tutorial: https://forums.fogproject.org/topic/11126/using-fog-postinstall-scripts-for-windows-driver-injection-2017-ed The part worth looking at is covered in the fog.updateunattend section.

More advanced post install scripting can be found here: https://forums.fogproject.org/topic/7740/the-magical-mystical-fog-post-download-script The one section that maybe useful is how to detect location based on IP address. I’ve even copied in updated unattend.xml files as I’m developing the image instead of having to recapture the entire system again just to make a change to the unattend.xml file.

You have to understand that not everything can be done in FOS and post install scripts. This is because the post install scripts run in the context of FOS which is linux not windows. You may have to push some functions into windows and have them run in the context of windows (DISM commands come to mind). The setupcomplete.cmd batch file is a good location to run scripts to update windows environment or in the unattend.xml first run section if the commands need to run within a profile.

[klaus.jauk]

@george1421 : Thank you for your fast answer. I think you didn’t understand me.

I use fog for years and read many posts and inspect the fos files on github. Postinit and postdownload scripts are not the problem. I mount the ntfs, copy drivers, software, bios, startup-scripts for Windows - all nop.
Also i generate unattend.xml with domain-join credentials and set autologon from the fog database (I use the aduser and adpass fields)- it works perfectly.

My problem:
I will not use the $imgid variable for selecting the correct settings in the script fog.createunattend.

Why:
If I work with 5 Images with Windows 10 LTSB, 2 Images with Windows 10 LTSC (new Images) and 3 Images with Windows 10 1809, with $imgid in the script, I need to definate 10 KMS-Key-Declarations in the bash-script.
With $osid it would be 3. Fog offers me only today 1$osid for Windows 10.

Bigger problem: If new Images will added, I have to change the postdownload-bash-script to place the correct settings.

So multiple Windows 10 $osid Variables would be nice in future.
Do you have an other resolution for this problem ?

[Tom Elliott]

@klaus-jauk As @george1421 suggested, postinit scripts are most likely what you’re looking for.

You can make a copy of the /bin/fog.download (or whatever script you want to use) and edit it to make the adjustments you so require.

Use the postinit script to drop your version of the relevant script file before it is actually called. This would allow you to add your own entries and has the scripts do what’s intended for them more natively. You adding the OSID isn’t a problem. The scripts use the OSID to determine how to operate. If you don’t modify the relevant script for your needs with the appropriate adjustments for your OSID the script will most likely fail.

Postinit scripts would be able to do what you need, without requiring us to recode the entirety of FOS everytime Microsoft releases a new Service Pack.

That’s not to say we won’t add OSID’s down the road, but for right now Windows 10 works fine as far as I’m aware for all of the different service pack releases. It’s only specific elements that are being changed every so slightly.

[george1421]

@klaus-jauk Ah OK, you are at a more advanced level then I expected.

If you look at this post: https://forums.fogproject.org/topic/7740/the-magical-mystical-fog-post-download-script/4

If your script makes that curl call in your postdownload script:

if [[ ! -z $mac ]]; then
    curl -A "" -Lkso /tmp/hinfo.sh ${web}/fog/service/hinfo.php -d "mac=$mac"
    if [[ -f /tmp/hinfo.sh ]]; then
        . /tmp/hinfo.sh
    fi
fi

You will have access to these FOG run time variables.

shutdown	# Shut down at the end of imaging
hostdesc	#Host Description from Host Managment-General
hostip		# IP address of the FOS client
hostimageid	# ID of image being deployed
hostbuilding	# ??
hostusead	# Join Domain after image task from Host Management-Active Directory
hostaddomain	# Domain name from Host Management-Active Directory
hostaduser	# Domain Username from Host Management-Active Directory
hostadou	# Organizational Unit from Host Management-Active Directory
hostproductkey	# Host Product Key from Host Management-Active Directory
imagename	# Image Name from Image Management-General
imagedesc	# Image Description from Image Management-General
imageosid	# Operating System from Image Management-General
imagepath	# Image Path from Image Management-General (/images/ assumed)
primaryuser	# Primary User from Host Management-Inventory
othertag	# Other Tag #1 User from Host Management-Inventory
othertag1	# Other Tag #2 from Host Management-Inventory
sysman		# System Manufacturer from Host Management-Inventory (from SMBIOS)
sysproduct	# System Product from Host Management-Inventory (from SMBIOS)
sysserial	# System Serial Number from Host Management-Inventory (from SMBIOS)
mbman		# Motherboard Manufacturer from Host Management-Inventory (from SMBIOS)
mbserial	# Motherboard Serial Number from Host Management-Inventory (from SMBIOS)
mbasset		# Motherboard Asset Tag from Host Management-Inventory (from SMBIOS)
mbproductname	# Motherboard Product Name from Host Management-Inventory (from SMBIOS)
caseman		# Chassis Manufacturer from Host Management-Inventory (from SMBIOS)
caseserial	# Chassis Serial from Host Management-Inventory (from SMBIOS)
caseasset	# Chassis Asset from Host Management-Inventory (from SMBIOS)
location	# Host Location (name) from Host Management-General

If you use hostimageid then you might be able key off that for your parameter settings.

[klaus.jauk]

@tom: Thank you for your answer. Below you find parts of my postdownload-scripts.
@George: Thank you also. I use curl request for checking the installation (for security - I have modified some values for this post).

Example:http://{$fogip}/fog/service/computerinfo.php?mac=b0:0c:d1:53:e2:7b
hostdesc="b00cd153e27b"
imageosid="9"
imagepath="IMG_NAME"
hostusead="1"
hostaddomain="DOMAIN"
hostadou="OU"
hostaduser="AUTOLOGON_USER"
hostadpass="AUTOLOGON_PASS"
hostproductkey=""
primaryuser=""
othertag=""
othertag1=""
sysman="HP"
sysproduct="HP EliteDesk 800 G4 DM 35W"
sysserial="8CC9033P2X"
mbman="HP"
mbserial="PGVXV0D8JBTTZG"
mbasset=""
mbproductname="83E2"
caseman="HP"
caseserial="8CC9033P2X"
caseasset="8CC9033P2X"

First - I need the $osid, because Driverpacks are different in Windows Builds:
As an example for HP-Driverpacks see: http://ftp.hp.com/pub/caps-softpaq/cmit/HP_Driverpack_Matrix_x64.html
The Packs are different for each Windows-Build on such devices … with no declaration, I have to copy all Drivers (that costs much time! ) and have to seperate it in the FirstLogonCommand-Script.

#Get Informations from Hardware
BiosVersion=`dmidecode -s bios-version`
Manufacturer=`dmidecode -s system-manufacturer | sed 's/ /./g'`
ComputerType=`dmidecode -s system-product-name | sed 's/ /./g'`
SerialNumber=`dmidecode -s system-serial-number | sed 's/ /./g'`
BiosDate=`dmidecode -s bios-release-date`

# Copy Device-Drivers to force-install with pnputil - the image has always the newest drivers:
rsync -a --delete --exclude='@eaDir' /images/Drivers/$Manufacturer/$ComputerType/$osid/* /ntfs/Tools/Drivers > /dev/null 2>&1

#Copy newest Bios-Release:
rsync -a --delete --exclude='@eaDir' /images/BIOS/$Manufacturer/$ComputerType/* /ntfs/Tools/Bios > /dev/null 2>&1
#Copy Hotfixes for Windows Builds and install it with Powershell to have the newest hotfixes:
rsync -a --delete --exclude='@eaDir' /images/Hotfixes/$osid /ntfs/Tools/Hotfixes > /dev/null 2>&1
#Copy the SXS Folder of the Windows Build:
rsync -a --delete --exclude='@eaDir' /images/SXS/$osid/* /ntfs/Tools > /dev/null 2>&1

Also I need it for the KMS-Key in the unattend - an example for you, how I will do it:

# Update unattend
if [ $adon = 1 ]
then

unattend=/ntfs/Windows/Panther/Unattend/unattend.xml
cp /images/unattend.xml $unattend > /dev/null 2>&1

# KMS Keys: https://docs.microsoft.com/en-us/windows-server/get-started/kmsclientkeys
KMSKEY_LTSB:DCPHK-NFMTC-H88MJ-PFHPY-QJ4BJ
KMSKEY_LTSC:M7XTQ-FN8P6-TTKYV-9D4CC-J462D
KMSKEY_W10:NPPR9-FWDCX-D2C8J-H872K-2YT43

IF [[ $osid -eq 10 ]]; then kmskey=$KMSKEY_W10 fi
IF [[ $osid -eq 101 ]]; then kmskey=$KMSKEY_LTSB fi
IF [[ $osid -eq 102 ]]; then kmskey=$KMSKEY_LTSC fi


dots "Set KMS-KEY in unattend.xml"
sed -i \
	-e "/ProductKey/s/*/$kmskey/g" $unattend >/dev/null 2>&1	
if [[ ! $? -eq 0 ]]; then        
echo "Failed"	
handleError "Failed to update unattend file"	
fi
echo "done"

fi

Without KMS-Key Defination in unattend, I have to activate Windows in the FirstLogonCommand, that costs also more time or have to define it for each $imgid (If new images will added, the script has to be update).

I know, Hotfixes and Drivers should be in the image, but we use more than 30 Images! The problem today is, that many vendors update the drivers once a quater (with microsoft updates).

[george1421]

@klaus-jauk I understand for $osid and driver packs. In the case of drivers, using FOG’s built in $osid is not a problem, because for Win10 for example a win10 drive works across all win10 platforms. The same for Win8 and so on.

Here is an idea: What I see is at issue is the KMS key where you think you need custom $osid values. There is a key management plugin for FOG. Where you load the KMS/MAK keys into a key table and then associate that key with a host. I don’t know if that will solve your problem with kms keys or not, but the resultant link key should show up in hostproductkey so you don’t need to do anything special in the post install scripts.

The issue I see with creating custom $osid values is that FOG uses that $osid values internally when creating the disk partitions and how to deal with boot block. If you create your own $osid values then the internal programs that look for $osid (9) for example would not work because it would see your custom $osid value. Now of FOG internally would mask off (only look at) the lower 8 bits of $osid for FOG’s internal use then you could do what you want by creating custom IDs with the upper 8 bits of that $osid value.