how are you preparing the windows 10 image and what source you using? i.e. physical / vm?
sysprepped or not? how many partitions? is it GPT or MBR?
how are you preparing the windows 10 image and what source you using? i.e. physical / vm?
sysprepped or not? how many partitions? is it GPT or MBR?
@Tom-Elliott this is exactly what i do which is why i caused confusion when posting code regarding injecting drivers with “/fog” directory throwing ppl off lol. postdownloadscripts are only limited to your imagination, i honestly believe it’s very under-utilized. i even use it to update the snapin state to give a detailed progress of where it is at (using snapintaskstate plugin too) as i have one snapin script for all our builds, each snapin definition just has an argument set so the script knows what software to install, settings to set etc… essentially i only have to manage one image and one snapin otherwise if i had a snapin per software i’d be managing 100’s potentially 1000’s! although i guess this is where snapin packs comes in to play! i’d already got this setup before snapin packs where introduced. Can see the appeal to snapin packs and how useful they can be but rely on having the fog client and if you don’t use fog to manage existing systems can be the only downfall i guess.
your config copy scenario you could do with postscripts using snapcheck.php and the concept would be: if cisco anyconnect client snapin is queued to be installed on the pc, copy config" that way if you need to update config file, just copy new version to server and next time cisco anyconnect client is installed so will the new config.
however if you’re looking to use fog + fog client to update existing config files you’ll need to write a script/snapin
i use postscripts + setupcomplete.cmd for our builds solely on the basis we have another system that manages deployed machines and fog to build and the setupcomplete.cmd purely for the fact it runs interactively outside a profile as we have unattended builds remotely and that way can have a “progress” indication without having to have an admin profile potentially accessible…
but i highly highly recommend the FOG Client as the developer works hard on getting it to be awesome, which it is and fits the build for practically every environment!
@Wayne-Workman the custom things Tom’s referring to is stuff like hooks, where you have created additional or enabled built in one’s which are turned off by default and any plugins & custom pxe backgrounds etc… which will get reverted back to system default going forward.
postscripts once setup, its literally the case of dropping drivers onto server, you could even setup permissions and map drive onto windows machine so you can “inject” there without even needing to go on the server (or give engineers permission to whole server)… pretty much what ur asking for but rather than through web interface, its network share
@george1421 said in FOG Post install script for Win Driver injection:
This script can be used to update files on the target computer. In this case we’ll use it to update the unattend.xml file with install time data like host name, connect to AD or what ever you need. I can say if you use the FOG client to do this stuff, then this script isn’t really needed. But its here to show you what’s possible.
#!/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
@george1421 nice write-up - think this needs updating to be inline with hostinfo.php variables?
apologies both - i could of jumped in sooner to point out about the /fog directory confusion and assisted with the partition code but been swamped as of late but luckily @Tom-Elliott had already sorted partition bit of magic for you guys!
@THEMCV if you do only have dell machines and want to use cab files - you can use cabextract which is built into the FOS.
something like:
cabextract -d /ntfs/Windows/DRV "/fog/Drivers/$osn/${machine}"/*.CAB &>/dev/null;
/ntfs/Windows/Drv - Change to wherever you want your drivers to be extracted to
/fog/Drivers/etc… - Change to match the directory you store the .cab file on the server. i.e. /images/Drivers/E7270-WIN7-A02-8924F.CAB
if you go down the .cab route - use the enterprise cabs as they are tested and put together specifically for image deployment.
http://en.community.dell.com/techcenter/enterprise-client/w/wiki/2065.dell-command-deploy-driver-packs-for-enterprise-client-os-deployment
if for whatever reason the cab isn’t sufficient and you need to add drivers, you could incorporate both .cab and folders using both sets of code. if you know what i mean?
as @george1421 pointed out scripts are a lil’ flawed but where written and posted sometime ago and for my own environment at the time and my own postscripts have come a long way since then.
the wiki post would be a very good idea as easier to keep up to date, once that’s done it may be worth changing any old posts with code in, redirecting users to the wiki so they don’t put conflicting or outdated code together. but like @george1421 said, a lot of it is personal preference and there is so many ways of achieving the same thing…
Glad you got there in the end though
@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
what issues are you having with the hooks? @george1421? happy to assist where possible
to test a theory - try separating the storage nodes into separate storage groups. so create a storage group and move audubon storage node into it and then check location storage group /node both point to audubon storage node and new storage group.
and try to image at audubon again, remember to create new task and not use an existing task.
@ITCC to setup how you want so no image goes across the wan but replication, setup like below (Be mindful you will have no resillience and if JS is busy for example and you want to image a machine at JS it will wait rather than use SS - which by the sounds of things is how you want it to work anyway)
Storage Group Definitions:
Storage Group - SS
Storage Group - JS
Storage Node Definitions:
Storage Node - SS - In Storage Group SS
Storage Node - JS - In Storage Group JS
Location Definitions:
Location SS - Storage Node - SS - Storage Group - SS
Location JS - Storage Node - JS - Storage Group - JS
Image Definitions:
ImageA - Storage Group - SS AND JS
ImageA - Storage Group - SS AND JS
make sure you tick whichever is primary (that you will upload your image to and want replication to come from)
so Location JS will only have Node JS available and vice versa.
You will be utilizing the use of Group to Group Replication which @TomElliott awesomely implemented sometime ago.
Whenever you upload an image, whatever location you choose will be the node it uploads to, just make sure you do it to whichever you set as primary otherwise you newly upload image with be overwritten.
Hope this helps
@Greg-Plamondon where are you calling the unattend.xml from and how are u verifying the unattend.xml is beinf edited correctly? Also are is it x86 or x64?
Sorry i couldn’t attend but glad it went well, especially for the first one - certainly productive, well done guys!
can you send me both your fog.postdownload and fog.drivers file and i’ll take a look - (i mean physically send, not paste the code on here :-))
@george1421 that’s the same approach i’ve taken for my driver script very similar in fact - only thing i’d suggest is your script is assuming main partition is always /dev/sda2 so wouldn’t work where it is not for like example EFI apart from that our scripts are pretty identical nice work i didn’t even realise DevicePath was no longer used in windows 10 - so thanks for that
T/here is definitely a need for a Driver plugin or to incorporate FOG handling drivers and we’ve known that, we’ll see what the future may bring, in all honesty - it’s fighting to find the time and resources.
@gwhitfield as you’re using /images as your driver location you do not need to mount a share as it’s already mounted, so /fog mount is irrelevant to you. as you’re only doing one arch or having both drivers on the image, i’m assuming as you commented it out, make sure your folder layout for drivers matches this for example a Windows 7 build OptiPlex 7010 would be:
“/images/Drivers/Win7/OptiPlex 7010” and all your drivers for the 7010 would be within that folder
Try these and let me know how you get on
fog.postdownload:
#!/bin/bash
case $osid in
[5-7]|9)
clearScreen
getHardDisk
getPartitions $hd
if [[ ! -d /ntfs ]]; then
mkdir -p /ntfs >/dev/null 2>&1
[[ ! $? -eq 0 ]] && echo " * Failed to Mount Device"
fi
for part in $parts; do
umount /ntfs >/dev/null 2>&1
ntfs-3g -o remove_hiberfile,rw $part /ntfs >/dev/null 2>&1
[[ ! $? -eq 0 ]] && continue
done
. ${postdownpath}fog.drivers
umount /fog /ntfs /images >/dev/null 2>&1
;;
esac
fog.drivers:
#!/bin/bash
ceol=`tput el`;
machine=`dmidecode -s system-product-name`;
machine="${machine%"${machine##*[![:space:]]}"}"
if [ $osid == "5" ]; then
osn="Win7"
elif [ $osid == "7" ]; then
osn="Win8.1"
elif [ $osid == "9" ]; then
osn="Win10"
fi
dots "Preparing Drivers";
mkdir /ntfs/Windows/DRV &>/dev/null;
echo -n "In Progress";
rsync -aqz "/images/Drivers/$osn/${machine}" /ntfs/Windows/DRV &>/dev/null;
regfile="/ntfs/Windows/System32/config/SOFTWARE"
key="\Microsoft\Windows\CurrentVersion\DevicePath"
devpath="%SystemRoot%\inf;%SystemRoot%\DRV";
reged -e "$regfile" &>/dev/null <<EOFREG
ed $key
$devpath
q
y
EOFREG
echo -e "\b\b\b\b\b\b\b\b\b\b\b${ceol}Done";
Hi Gregg,
What version of fog are you using?
@Arrowhead-IT certainly a nice clean approach… glad you got it figured out! and thanks for sharing with the community… i’m sure it’ll become useful as people start to move over to win10.
in my research i found, that cortana/windows search breaks if you make any customization to the start menu - test my theory build another image but leave start menu as default. making all other custom changes + unattend.xml or whatever you used on your image that has broken cortana/windows search