potentially this means for rename, ad, snapins you wouldn’t need to use fog client… although fog client would be there as a backup if anything failed and i would always recommend still utilizing the FOG Client especially the new one when it comes out, you’d be silly not to!!!

now this is completely up to you, whatever you want it to do … i use it so that it downloads needed data for unique snapins and i also use it to get switch from fog so that i’m only actually using one script for all our “builds” and the script knows what’s needed by that switch. that way i only ever have to maintain one “snapin”

i.e. snapin 1 = myscirpt.exe with a switch of /DefaultBuild in my script catches switch so if /DefaultBuild set $somevariable to true then
if $somevariable = true then
install these pieces software, add these shortcuts etc etc etc

a one snapin rules all type scenario

[CODE]#!/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[/CODE]

this will remove the 2 needed reboots to rename and join domain (if hostname early is not used)

not much info needed on this pretty self explanatory, uses sed to manipulate unattend.xml to be unique to that machine setting the name and ad details.

only prereq is that your unattend.xml MUST include:
<JoinWorkgroup>Workgroup</JoinWorkgroup>
<Credentials>
<Password></Password>
<Username></Username>
</Credentials>
<JoinDomain></JoinDomain>
<MachineObjectOU></MachineObjectOU>

and other prereq is your ad username should be the new way of just username rather than old domain\username

nice thing also, it’s not static info and uses fog variables for name and ad details

one more thing to add, if machine is not set to join ad in fog, it will not add ad details to unattend

fog.ad
[CODE]#!/bin/sh

hostadpwd=“PasswordtojoinAD”; #only downside to this method- this is the plain ad password
unattend=“/ntfs/Windows/Panther/unattend.xml”;
if [ -f “$unattend” ]; then
dots “Preparing Sysprep File”;
rm -f /ntfs/Windows/System32/sysprep/unattend.xml;
echo “Done”;
dots “Writing Computer Name”;
sed -i “/ComputerName/s/*/$hostname/g” $unattend
echo “Done”;
dots “ComputerName Set To”;
echo $hostname
dots “Set PC To Join The Domain”;
if [ “$addomain” != “” ]; then
sed -i “/<JoinWorkgroup>/d” $unattend
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
echo “Done”;
else
echo “Skipped”;
fi
fi[/CODE]

Always remove notation and you’ll see just how minimal lines of code it is
fog.drivers
[CODE]#!/bin/sh

ceol=tput el;
machine=dmidecode -s system-product-name; # Gets machine model
machine=“${machine%”${machine##*[![:space:]]}“}” #Removes Trailing Space
system64=“/ntfs/Windows/SysWOW64/regedit.exe”; # dirty way to determine if it’s 64bit or not
if [ -f “$system64” ]; then
setarch=“x64”
else
setarch=“x86”
fi
#############################################
#this is not section necessary needed, it’s just to make the path “human readable”
#rather than using osid for filepath
if [ $osid == “5” ]; then
osn=“Win7”
elif [ $osid == “6” ]; then
osn=“Win8”
elif [ $osid == “7” ]; then
osn=“Win8.1”
fi
#############################################
dots “Preparing Drivers”;

below creates local folder on imaged pc

#this can be anywhere you want just remember
#to make sure it matches throughout!
mkdir /ntfs/Windows/DRV &>/dev/null;
echo -n “In Progress”;

#there’s 3 ways you could handle this,
#driver cab file, extracted driver files or both
#so on the server put extracted driver files to match below folder tree
#i.e. Model Latitude E5410, Windows 7 x86 image would be:
#/fog/Drivers/Win7/Latitude E5410/x86
rsync -aqz “/fog/Drivers/$osn/${machine}/$setarch” /ntfs/Windows/DRV &>/dev/null;

#if you wanted to use driver.cab use this line below.
#i.e. /fog/Drivers/Win7/Latitude E5410/E5410-Win7-A07-KTT4G.CAB
cabextract -d /ntfs/Windows/DRV “/fog/Drivers/$osn/${machine}”/*.CAB &>/dev/null;

#if you wanted to mix both cab and extracted use these:
rsync -aqz --exclude='.CAB’ “/fog/Drivers/$osn/${machine}/$setarch” /ntfs/Windows/DRV &>/dev/null;
cabextract -d /ntfs/Windows/DRV “/fog/Drivers/$osn/${machine}”/.CAB &>/dev/null;

#this next bit adds driver location on pc to devicepath in registry (so sysprep uses it to reference)

remember to make devicepath= match the path you’ve used locally

#also do not remove %SystemRoot%\inf
#and to add more locations just use ; in between each location
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”; # this just removes “In Progress and replaces it with done :-)”[/CODE]

Hi All,

i haven’t got round to it until now but i thought i’d share how i used postscripts to give the community ideas of how it could be used and how potentially powerful postscripts really can be. i’ll try to notation anything that may not make sense and try not to fill this thread full of code! i’ll seperate each “file script” into a new post

so under /images/postdownloadscripts i have the following files:
fog.ad, fog.drivers, fog.postdownload, fog.snapins (rather than having a bulk of code just in fog.postdownload - keeps it nice and seperate)

THE FOG.POSTDOWNLOAD (the script that directs everything i guess you could say)
fog.postdownload contains:

[CODE]if [ $osid == “5” -o $osid == “6” -o $osid == “7” ]; then #only handling Win7/8/8.1
clearScreen;
mkdir /ntfs &>/dev/null
ntfs-3g -o force,rw $part /ntfs #mount image (remember this is mounting partition [U][B]after[/B][/U] new image is deployed)
mkdir /fog &>/dev/null
mount -o nolock,proto=tcp $storageip:/fog/ /fog #this is a share created on server under /fog which contains drivers, software etc… (just add /fog to exports but you could use existing location i.e. /images and if you do, do not need to do this mount as /images is still mounted at this point)
dots “Mounting Device”;
if [ “$?” = “0” ]; then
echo “Done”;
. ${postdownpath}fog.drivers # run fog.drivers script
. ${postdownpath}fog.ad # then run fog.ad … you get the jist
. ${postdownpath}fog.snapins
umount /ntfs; # unmount when all is done
else
echo “Failed To Mount Device”;
sleep 30;
fi
fi[/CODE]

well… may be causing you more work/testing here but you could get postscripts to handle your drivers too for you so they get installed during sysprep rather than after?

i’ll write a quick thread about setting up AD and Drivers and even snapins in postscripts, it’s long overdue anyway and might be helpful to others, it don’t fit all scenarios but ppl could take chunks from it :-)…

postscripts are native to FOG it’s the capability to run any custom script after the image has finished deploying right before it reboots. it’s easy to use as you just use the variable passed by FOG i.e. $addomain, $adou so maintainence free and technically could be clientless really.

sounds like you’ve got it covered now though

not to throw a spanner in the works (now that you’ve got it working and all) but as you’re using sysprep, you could do host renaming during postscripts (getting it to modify the unattend.xml on the new downloaded image). and/or domain join if needs be. that way no need for reboots as the name is set (and domain details) correctly in unattend pre-sysprep.

Just an alternative

Win7 has better handling of SATA controllers than vista did/does which is why ur seeing the error on vista but no win7 - i’d still put my money on that being the issue, IDE would prove that theory

sounds to me like driver issue could be the culprit, specifically SATA/HDD Controller drivers but would need more info to determine that . especially if u can reimage ur reference machine and it works fine… how are you including the drivers in your VM? you adding them to vm or post image? using sysprep? also if your using win7/vista on standard build (i.e. 100MB part + system part) i would just use single disk resizeable as FOG can handle it fine and it’s much easier to expand disk in the post install script then (also get the added benefit of ur image being smaller as single disk automatically remove pagefile + hiberfil.sys)

Personally VM is much easier and cleaner than using physical, guess it’s personal preference really. both have pros and cons in their on ways.

other thing to consider you may need IP-helpers configured if it’s layer 3

turn off Display_Errors also

from ur description above about keeping traffic going across “rings” to a minimum you will want to enable tftp from node then… only thing you can’t “control” with location is the snapins but there are ways… we have 25 sites across the country and only traffic is initial tftp request, snapin script and a few db queries everything else is local to the site so you’re talking mbs if not kbs of traffic

the tftp from node is basically the same methodology as the imagin it reports to main server for the initial tftp but the init and kernel it downloads from the local node so 20MB doesn’t come from the main server but locally the location plugin is intended for you to be able to manage where the image comes from as storage nodes are designed as load balancing where the location plugin “directs” the traffic. so you can tell the host by location which node to get it’s image from. simplistic setup is:-

Setup a location for each location/node so
For Remote Location 1.

Create a Location Definition Called: Remote Location 1
Add the storage node for Remote Location 1 to that Location
and when you want the host to image from Remote Location 1 under host choose Remote Location 1 under host then deploy

This way keeps it “centralised” so you only need 1 Main Server, 1 SQL database etc etc but get the ability to do “local” imaging for that remote site

Hope this makes sense

sorry i didn’t make it very clear - this is what i meant, i’m using a port say :25280 but doing an internal rewrite (so u don’t have to specify port in web address) but ALL traffic fitting the pattern for fog gets directed to apache/fog box using the port:25280 and have no issues… with ur port-translation it seems the initial traffic i.e. /fog/ is going to apache but further traffic is not… try looking into apache config, also check logs they will give u a clue with what is wrong and whether apache is seeing the request. like tom said it is environment/routing issues not fog gui, fog gui doesn’t care what port it’s ur apache doing the listening u could test the theory by getting apache to listen on 25280

this is a forwarding issue, your initial “redirect” or however u’ve set it up reaches fog but it sounds like u’ve got the rule on set to …/fog/ or /fog/management so anything like /fog/management/index.php?node= etc will not fit in the “rule” you have set.

regarding key in bios, it’s the “new” way to act as a deterrent and also remove the need for key labels and ppl losing keys cause they’re worn/illegible or peeling them off and using them on other machines, greener, easir blah blah etc etc etc… if u do have the new version of key (no sticker) then aslong as ur using same version os that the key is for then u certainly dont need to specify a product key in ur unattend and if u want to automate activation just run: cscript //b c:\windows\system32\slmgr.vbs /ato as postscript if u dont trust sysprep will automatically activate

you don’t actually have to specify unattend:unattend.xml if it’s in the default location i.e. C:\Windows\System32\sysprep\unattend.xml
how many times has this machine been sysprepped? check /panther folder also. have you always had <ProductKey>xxx-xx etc in ur unattend.xml if so that would cause it to fail - try this: remove ur unattend file from sysprep folder, open sysprep.exe leave as is and click ok, when/if machine reboots goes to oobe and asks u for pc name press ctrl, alt F3. let me know the outcome btw just to check it is win7pro x64 on the machine isn’t it?

this only works for partclone images, are you using partimage?

In theory it shudnt of populated as a dropdown if u only had one or no ou listed and reason it didnt get a big mention is we are/were still testing it