@george1421 Sorry, clearly I wasn’t with it this morning.
So, for the 7280, even after injecting the drivers into the golden image, it still isn’t working. I still receive ‘no bootable devices found’, and I am also using the updated Windows 10 Unattend.xml file. Do you know of any standard Dell drivers I can try? At this point I’m only interested in getting the hard drive recognised post-download.
@george1421 No, I meant the driver store, as in C:\Windows\System32\DriverStore\FileRepository, but after looking at it, I can see that’s where the .inf files are after they’ve been installed.
So, moving forward with this, I’ll now have to inject the drivers into the reference image from now on (thereby having multiple images for different types of systems)?
@george1421 Me too! I’m not sure how… maybe they were using some kind of driver picked up as I was building the image in Hyper-V, though I haven’t seen anything of the such in the golden image.
Theoretically, couldn’t I edit the script to put the drivers in the driver store? According to the below link, that’s where Windows 8 and later first searches for drivers and installs them onto the device.
https://docs.microsoft.com/en-us/windows-hardware/drivers/install/where-setup-searches-for-drivers
@george1421 said in Driver Issues With Dell Latitude 7280 - No Bootable Devices:
And just for clarity your post install script is for win7 not win10. Win10 will only look for drivers defined in the unattend.xml. It does not reference the registry entry that is being set in your post install script. It doesn’t hurt to set it, the registry key just won’t be used.
Bah, when did that happen? I could never get the unattend.xml driver injection to work for whatever reason. I guess I’ll go back to including the drivers in the reference image and test it out.
Edit: I must have misread your comment. I just need to edit the unattend.xml to point to C:\Windows\DRV for the drivers, instead of relying on the registry change?
@Tom-Elliott I haven’t had any issues with Windows 10 so far on the different systems (also Latitude E6 something or other - there are a few of them). This is the post-download script I mentioned previously:
# Script here to mount the drive...
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"; #Determine if it's 64 bit or not
dots "Creating driver folder on local system" # < This is fine on a new line.
# Check if the DRV folder exists on the local PC. If not, create it:
if [ ! -d "ntfs/Windows/DRV" ]
then
mkdir /ntfs/Windows/DRV &>/dev/null;
echo -n "Done"
fi
# Check if the drivers exist on the FOG server.
# If not, copy them across to the local PC (they must be extracted first on the FOG server):
dots "Checking for Drivers on FOG Server" # < This bunches with the previous dots command.
if [ -d "/images/Drivers/${machine}" ]
then
echo -n "Drivers found"
dots "Copying Drivers to local system" # < This also bunches with the previous dots command.
cp -r "/images/Drivers/${machine}/." "/ntfs/Windows/DRV"
else
echo -n "No drivers were found"
# Give the reader a chance to see what the error was.
sleep 10;
# Terminate the post driver script.
exit 1;
fi
# Add the driver location on the PC to devicepath in Registry:
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
# Remove the "In Progress" and replace it with: "Done"
echo -e "\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b${ceol}Done";
esac ```@Tom-Elliott I’m not sure - I haven’t mounted the drive and checked in during a debugging phase. The script does say that the files have been successfully transferred however, and this does always work. If they aren’t transferred then the script fails.
Hey all,
Is anyone having issues imaging Dell Latitude 7280 laptops?
I downloaded the CAB drivers from: http://en.community.dell.com/techcenter/enterprise-client/w/wiki/2065.dell-command-deploy-driver-packs-for-enterprise-client-os-deployment
Neither the 7280 nor the Win10PE drivers seem to work at all. I know my process for injecting the drivers works as we resolved that in another thread, and I have been using it since with other systems. (It’s a post-download script that copies the contents of the appropriate driver folder to the 
drive).
Any help with this would be appreciated 
Hi all,
We had an issue a while ago where we were replicating our images from the UK to our FOG server in the US. This was perfectly fine for a time, though we ran into the issue with our ISP where they cut our network down significantly due to the amount of data being transferred. I’ve since shrinked the image sizes, but I’m wondering if there’s some kind of setting that says to only replicate at a certain time of day that wouldn’t impact business hours? Or even have it on a schedule so it only replicates once a month? Is that possible at all?
@Tom-Elliott @george1421
Ah, so simple! Thanks very much gents!
@adukes40 Thanks, that helps a lot! I’ve managed to get it working now doing exactly that
My one remaining question is… how do you get dots to appear on a new line? At the moment mine bunch up together, which isn’t very pretty at all 
# Script here to mount the drive...
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"; #Determine if it's 64 bit or not
dots "Creating driver folder on local system" # < This is fine on a new line.
# Check if the DRV folder exists on the local PC. If not, create it:
if [ ! -d "ntfs/Windows/DRV" ]
then
mkdir /ntfs/Windows/DRV &>/dev/null;
echo -n "Done"
fi
# Check if the drivers exist on the FOG server.
# If not, copy them across to the local PC (they must be extracted first on the FOG server):
dots "Checking for Drivers on FOG Server" # < This bunches with the previous dots command.
if [ -d "/images/Drivers/${machine}" ]
then
echo -n "Drivers found"
dots "Copying Drivers to local system" # < This also bunches with the previous dots command.
cp -r "/images/Drivers/${machine}/." "/ntfs/Windows/DRV"
else
echo -n "No drivers were found"
# Give the reader a chance to see what the error was.
sleep 10;
# Terminate the post driver script.
exit 1;
fi
# Add the driver location on the PC to devicepath in Registry:
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
# Remove the "In Progress" and replace it with: "Done"
echo -e "\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b${ceol}Done";
esac
@Quazz Thanks, that was my mistake (doh!)
I’ve since fixed it, though I suspect the dmidecode part isn’t working as it doesn’t extract the CAB file from the FOG server into the DRV folder on the Windows machine (I’m not altogether certain that machine='dmidecode -s system-product-name'; returns “Latitude E6410”).
The full script is below and doesn’t rely on anything else. In the meantime I’ll try it again and try running the dmidecode part in a debugging session to see if I can figure it out.
EDIT: Doh! I had a typo… it’s dmidecode - NOT dmiedecode.
Unfortunately, the CAB extraction still doesn’t seem to be working
#!/bin/bash
. /usr/share/fog/lib/funcs.sh
case $osid in
5|6|7|9)
clear
[[ ! -d /ntfs ]] && mkdir -p /ntfs
getHardDisk
if [[ -z $hd ]]; then
handleError "Could not find hdd to use"
fi
getPartitions $hd
for part in $parts; do
umount /ntfs >/dev/null 2>&1
fsTypeSetting "$part"
case $fstype in
ntfs)
dots "Testing partition $part"
ntfs-3g -o force,rw $part /ntfs
ntfsstatus="$?"
if [[ ! $ntfsstatus -eq 0 ]]; then
echo "Skipped"
continue
fi
if [[ ! -d /ntfs/windows && ! -d /ntfs/Windows && ! -d /ntfs/WINDOWS ]]; then
echo "Not found"
umount /ntfs >/dev/null 2>&1
continue
fi
echo "Success"
break
;;
*)
echo " * Partition $part not NTFS filesystem"
;;
esac
done
if [[ ! $ntfsstatus -eq 0 ]]; then
echo "Failed"
debugPause
handleError "Failed to mount $part ($0)\n Args: $*"
# Give the reader a chance to see what the error was
sleep 12;
# Terminate the post driver script
exit 1;
fi
ceol='tput el';
machine='dmidecode -s system-product-name'; #Gets machine model
machine="${machine%"${machine##*[![:space:]]}"}" #Removes trailing space
dots "Preparing Drivers";
#Check if the DRV folder exists on the local PC:
if [ ! -d "ntfs/Windows/DRV" ]
then
mkdir /ntfs/Windows/DRV &>/dev/null;
echo -n "In progress"
fi
# Only use CAB files for the drivers.
# Place the cab files for the specific system on the FOG Server:
# i.e. Model Latitude E5410, Windows 7 x64 image would be:
# /fog/Drivers/Win7/Latitude E5410/x64
cabextract -d /ntfs/Windows/DRV "/images/Drivers/${machine}"/*.CAB &>/dev/null;
# Add the driver location on the PC to devicepath in Registry:
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
# Remove the "In Progress" and replace it with: "Done"
echo -e "\b\b\b\b\b\b\b\b\b\b\b${ceol}Done";
esac
@Quazz Thanks very much!
I’ve just tried this through a debugging task, and I would expect it to at least make the directory C:\Windows\DRV, but it hasn’t for some reason. I couldn’t actually see it calling the script at all, even though it’s definitely being called in the fog.postdownload script.
@Quazz Unfortunately, it doesn’t seem to be working even after I’ve changed the permissions, which suggests the format of the script is wrong. I’m currently using this:
#!/bin/sh
ceol='tput el';
machine='dmiedecode -s system-product-name'; #Gets machine model
machine="${machine%"${machine##*[![:space:]]}"}" #Removes trailing space
system64="/ntfs/Windows/SysWOW64/regedit.exe"; #Determine if it's 64 bit or not
if [ =f "$system64" ]; then
setarch="x64"
else
setarch="x86"
fi
dots "Preparing Drivers";
#Create the local folder on the imaged PC:
mkdir /ntfs/Windows/DRV &>/dev/null;
echo -n "In Progress";
# Only use CAB files for the drivers.
# Place the cab files for the specific system on the FOG Server:
# i.e. Model Latitude E5410, Windows 7 x64 image would be:
# /fog/Drivers/Win7/Latitude E5410/x64
cabextract -d /ntfs/Windows/DRV "/images/Drivers/${machine}"/*.CAB &>/dev/null;
# Add the driver location on the PC to devicepath in Registry:
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
# Remove the "In Progress" and replace it with: "Done"
echo -e "\b\b\b\b\b\b\b\b\b\b\b${ceol}Done";
And this was admittedly taken from: https://forums.fogproject.org/topic/4278/utilizing-postscripts-rename-joindomain-drivers-snapins/3
@Quazz Ah, thanks! That’s fixed the issue
I’ll test it out whilst imaging a laptop and post back if I run into any further issues. And no, I didn’t create the script in Windows - I typed it out using vi on the Ubuntu box.
Hi all,
I’ve got a driver injection scrip that should be called after the image has completed, though it doesn’t seem to be working at the moment. It’s definitely being called by the fog.postdownload script, but when I run list the directory of postdownloadscripts, I see that fog.postdrivers is white whereas the others are green. The script starts with #!/bin/sh… is there anything I’m missing?
It appears it’s an issue with the Unattend.xml file. I’ve tried one that has worked in the past and that’s absolutely fine.
Thanks for the help, gents!
@george1421 Sorry; to clarify: the FOG client is installed from the setup.cmd script. The fog.postdownload script calls fog.postclient, which copies the setup.cmd script from the FOG server across to the Windows installation and then appends the .cmd script with the instructions to install the FOG client.
That step isn’t being hit yet, though.
I don’t think it could be drivers considering this is a Hyper-V VM… I haven’t had to install any.
Checking the sysprep error log in C:\Windows\System32\Sysprep\Panther, it says:
"[0x0f0043] SYSPRP WinMain: The sysprep dialog box returned FALSE.
(This repeats for 5 lines)
[0x0f00a4] SYSPRP WinMain: Unable to parse command-line arguments to sysprep;m GLE = 0x0
@sudburr I don’t have any anti-virus installed on the image.
@Psycholiquid I’m capturing a Windows 10x64 system.
I put the system into Audit mode to build the image, copied the unattend.xml file across and then told it to perform a sysprep with the out of box experience. I also checked the ‘generalize’ box.
I haven’t installed the FOG client on this system (it’s installed using a postdownload script on the FOG server) and I haven’t installed any drivers, either (I intend to install them using a postdownload script depending what machine it is).
Hi all,
I’ve just built an image in a Hyper-V VM, set-up an unattend.xml file using the Windows System Image Manager and set the VM to sysprep. However, upon boot I now receive: “Windows could not complete the installation. To install Windows on this computer, restart the installation”. This then loops repeatedly, until I open a command prompt and start ms oobe to bypass the user account screen.
Has anyone come across this before? I know how to fix it, but how do I prevent it in the first place? I can post my unattend.xml file if it helps.