Posts made by RobTitian16

@george1421 Hi George,
I’m just taking a look at this now (I became swamped with other things, unfortunately and thus the FOG server was forgotten for a while).
I just have a few questions about your instructions in: https://forums.fogproject.org/topic/7391/deploying-a-single-golden-image-to-different-hardware-with-fog/5?loggedin

Specifically, you say at the end of part 1 that you have a batch file that runs sysprep with the required parameters. Is this set-up as a task in MDT before you capture the reference image using MDT itself? Or, is it separate from everything we’ve done in MDT so far, and is done just to capture the image with FOG?

Also, in part 2 you say to set-up the Windows directory like so:

/images/drivers/{hardware_type}/{os_type}/{arch}/{driver files}

However, the CAB file just comes with WinPE x86 and WinPE x64 folders (with network and storage folders containing the drivers in each, respectively). Do we simply create folders like the below, and copy the drivers from the WinPE x64 and WinPE x86 folders into each one?

C:\Drivers\LatitudeE6410\win10\x64\{all driver files from dell cab}

If so, couldn’t we just use a single folder for the drivers instead? The CAB file doesn’t seem to specify what systems it can be applied to.

@george1421 Thanks, George.
I’m a little confused with the installation of the applications and MDT. Is this done within MDT itself? What if I’ve already built it on the Dell laptop? How would I then get the image across to MDT to apply the driver cab file and the registry change you mention in the guide?
Were there any guides/resources you used to get acquainted with MDT?

@george1421 Hi George,

Just a quick one: my company is using different builds depending on what their job title is (i.e. software developer, tester, IT Support, etc.) and each of these builds has a completely different configuration with software, changes to the registry, etc. Is it possible to simply capture these builds as they are with the necessary software already installed (using a method like dism), add those wim files into MDT along with the Dell cab files and create the image for FOG that way?

It seems your method in the link can only be used for golden images and you install/configure the software afterwards through scripts, etc. Unfortunately for us we can’t do that as there’s a lot of fiddling about with things like Visual Studio (and installing custom scripts, etc.).

@george1421 Sorry, I meant when deploying the image and trying to turn it on. For some reason when using a Hyper-V VM to upload an image to the FOG server, it will not be pushed out as a UEFI image (and thus Bitlocker cannot be enabled).

@george1421 Great stuff - thanks once again, George. I’ll give this a go this afternoon/tomorrow and test it out.
Unfortunately I can’t use a VM to create the image. For some reason whenever I do it’s not uploaded as a UEFI system and I run into countless errors with Bitlocker when the image is deployed. The only way I’ve been able to get around it is to use a physical system. I haven’t really had time to find out why this is the case, unfortunately.

@george1421 The laptop now displays “no bootable devices” - the same message as the Dell OptiPlex 390 now.
Your guess is probably correct - I had forgot to set-up the drivers on the FOG server (doh!). I suppose I simply follow your instructions here? https://forums.fogproject.org/topic/7391/deploying-a-single-golden-image-to-different-hardware-with-fog/2

@george1421 Yep, the image was also from a UEFI-based system (a Dell E7270).

Oddly enough I just tested deploying this same image to a computer (a Dell OptiPlex 390) and that claims it has no hard drive (it can’t see it at all whilst in UEFI mode). So, with that in mind, could it be something I’m not doing correctly when building the image?

The steps I take are:
Set the system to upload the image to boot from the network and disable secure boot.
Build the image from the ground up with necessary software, etc.
Copy the unattend file (I can post this if necessary) to C:\Windows\Panther and, using an elevated command prompt, type: sysprep.exe /oobe /unattend:C:\Windows\Panther\Unattend.xml /shutdown
I then schedule the upload through the FOG gui, watch with popcorn until it finishes, and then watch sysprep work its magic on the system I used to upload the image. (Note: this works absolutely fine.)

The 6410 does indeed support UEFI as well as pxe booting (I have it checked in the BIOS). The only thing it doesn’t support is secure boot - there’s no option for it at all in the BIOS. The client OS is Windows 10 Professional 64-bit.

Server

• FOG Version: 1.3.5-RC-9
• OS: Ubuntu 14.04

Description

Hi all,
I uploaded a sysprepped image to the FOG server on Tuesday and have just tried deploying it to a laptop this morning. However, I’ve run into an issue where I receive a recovery screen, saying:

“The application or operating system couldn’t be loaded because a required file is missing or contains errors.
File: \windows\system32\winload.efi
Error code: 0xc0000225
You’ll need to use the recovery tools on your installation media. If you don’t have any installation media (like a disc or USB device), contact your system administrator or PC manufacturer.”

I’ve checked the forum posts here and ensured secure boot was disabled before uploading the image. There is no secure boot option on the laptop I’m deploying to (a Dell Latitude E6410). The laptop I used to upload the image completed sysprep without any issues, so it seems to be a FOG/deployment to different hardware issue.

Has anyone else come across this before? Any help would be greatly appreciated as I need to get this image working for our production systems.

Ryan’s link worked! This can be marked as solved Thanks gents!

@Jaymes-Driver No, I had data on it prior to imaging (it’s a laptop ordered from Dell so it had a preinstalled Windows 10 Pro 64-Bit OS).

I’ll try it once more with sysprep, etc. and see how it goes.

Server

• FOG Version: 1.3.4 Revision 6064
• OS: Ubuntu 14.04

Client

• Service Version:
• OS: Windows 10 64-Bit

Description

Hi all,

I’m currently trying to upload a sysprepped image to the FOG server, but everytime I do, I receive the following error:

The thing is, I’ve already run chkdsk /f before running sysprep - twice and rebooted the system twice each time. Then, I can’t load the OS at all - the system stays at a blank screen, as if it can’t read the hard drive correctly. But when simply running sysprep and not doing anything with FOG at all, the system will work (this is after re-imaging it with a non-sysprepped version of the image).

Has anyone come across this before?
Any help would be appreciated.

@ryan.mckenzie
@Joe-Schmitt
@x23piracy
Many thanks, gents. I’ll take a look at this when I get into the office and see what happens It’s nice to know it’s not just me having issues with sysprep this week!

Server

• FOG Version: 1.3.4 Revision 6064
• OS: Ubuntu 14.04

Client

• Service Version:
• OS: Windows 10 64-Bit

Description

Hi all,

I’m having a weird issue when I sysprep a Windows 10 64-bit system - it seems to get stuck in a reboot loop. The Dell logo will appear, the white spinning circle will show for a few seconds, and then all will go black and the laptop I’m working on will reboot.
I suspect it could be my unattend.xml file and that there’s something wrong with it. 0_1486047107562_unattendTest.xml
You can see I’m trying to call SetupComplete.cmd (as I’m using an OEM version of Windows) in the FirstLogonCommands, but I don’t get as far as logging on so I don’t think it’s that.
Has anyone else experienced this issue or perhaps know what the cause could be?
The only way out of it is to re-image the system with the image taken before running sysprep.

@george1421 Thanks! We always update the system with the correct license after being imaged.

Thanks as well for pointing out that section. I’m just about to test it

@george1421 Thanks, George. Because I’m using an OEM version of windows, sysprep doesn’t run setupcomplete.cmd. The workaround, or so I’m told, is to use the unattend file.
Thanks for posting it - I’ll take a look shortly.

Server

• FOG Version: 1.3.2
• OS: Ubuntu 14.04

Description

Hi all,

Just a quick one: is there any guide to setting up the unattend.xml for sysprepped images? I recall creating it before, but I can’t exactly remember how. I’ve downloaded the Windows System Image Manager and need to create an unattend.xml file that will run setupcomplete.exe in C:\System\Panther.
Any help with this would be appreciated.

@Tom-Elliott The register and image setup is confirmed to be working in the latest release Thanks!

@Quazz Thanks - they’ve been adjusted.
I found that SetupComplete wasn’t actually running (but was being copied across). I now know why:

@Tom-Elliott said in Rolling FOG out to US Site:

@RobTitian16 It will run as soon as the system completes sysprep steps (Setting up your device).

The last thing it does is “SetupComplete.cmd”.

The path should be:

C:\Windows\Setup\Scripts\SetupComplete.cmd (though you can try with setupcomplete.cmd) as well.

Of not, for Windows 8 and Windows 10, if the image is sysprepped using an OEM version of the software it will NOT run the setupcomplete.

So I’ll have to adjust my unattend.xml file to run the SetupComplete.cmd instead.

@Quazz Thanks - I realised I had copied over some old script. This is the new one with still no luck in getting it to run:

#!/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 /ntf >/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 install script 
            exit 1;
        fi

        # This next section determines the IP of the host system, cuts the last two octects and sets the FOGIP variable to
        # the correct IP address of the FOG server depending on the location (as the subnets are designed by location - i.e.
        # 10.1 is for the UK, 10.2 is for the US, etc.)   

        myip=$(ip route get 8.8.8.8 | awk 'NR==1 {print $NF}' | cut -d "." -f1-2)

        case "${myip}" in
	        10.1)
		        sitecode="UK";
		        timezone="Greenwich Mean Time";
		        FOGIP="10.1.0.102";
			sitelocal="en-GB";
			uilang="en-US";
		        ;;
	        10.2)
		        sitecode="US";
		        timezone="Eastern Standard Time";
		        FOGIP="10.2.1.103";
			sitelocal="en-US";
			uilang="en-US";
		        ;;
	        *)
		        # Default code for the unknowns - we set the FOGIP to the development server in the UK. 
		        sitecode="CompanyName";
		        timezone="Greenwich Mean Time";
		        FOGIP="10.1.0.102";
			sitelocal="en-GB";
			uilang="en-GB";
		        ;;
        esac
	
	# Check if the direcotry /ntfs/Windows/Setup/Scripts exists, and if not then create it.
	if [ ! -d "ntfs/Windows/Setup/Scripts" ]
	then	
		mkdir /ntfs/Windows/Setup/Scripts
	fi 

	# Copy the FOGService.msi across to the target computer.
	[[ -f ${postdownpath}FOGService.msi ]] && cp ${postdownpath}FOGService.msi "/ntfs/Windows/Setup/Scripts/FOGService.msi"
       
 
	# Check if the file SetupComplete.cmd exists in the source folder and then copy it to the destination on 
        # the C: drive. 

        if [ -f "/images/drivers/Common/SetupComplete.cmd" ]; then
	        cp /images/drivers/Common/SetupComplete.cmd /ntfs/Windows/Setup/Scripts/SetupComplete.cmd
			# append the msiexec command to the end of the setupComplete.cmd file 
			echo "msiexec.exe /i %windir%\Setup\Scripts\FOGService.msi  /quiet USETRAY=\"0\" WEBADDRESS=\"${FOGIP}\" " >> /ntfs/Windows/Setup/Scripts/SetupComplete.cmd
			# Re-enable the FOGService and then reboot the computer
			echo "sc config FOGService start= auto
			shutdown -t 0 -r" >> /ntfs/Windows/Setup/Scripts/SetupComplete.cmd
			# just in case we edited the setupcomplete.cmd file in unix lets filter it to make it DOS compatible
			unix2dos /ntfs/Windows/Setup/Scripts/SetupComplete.cmd
        fi
		
		# now lets use the timezone variable and update the unattend.xml file. You may need to edit the variable to 
		# point to where your unattend.xml file exists. Remember case IS important. 
		unattendfile="/ntfs/Windows/Panther/unattend.xml";
		sed -i -e "s#<TimeZone>\([^<][^<]*\)</TimeZone>#<TimeZone>$timezone</TimeZone>#gi" $unattendfile
		
		# now lets deal with the internationalization stuff in the unattend.xml file 
		sed -i -e "s#<InputLocale>\([^<][^<]*\)</InputLocale>#<InputLocale>$sitelocal</InputLocale>#gi" $unattendfile
		sed -i -e "s#<SystemLocale>\([^<][^<]*\)</SystemLocale>#<SystemLocale>$sitelocal</SystemLocale>#gi" $unattendfile
		sed -i -e "s#<UILanguage>\([^<][^<]*\)</UILanguage>#<UILanguage>$uilang</UILanguage>#gi" $unattendfile
		sed -i -e "s#<UserLocale>\([^<][^<]*\)</UserLocale>#<UserLocale>$sitelocal</UserLocale>#gi" $unattendfile
        ;;
    *)
        echo "Non-Windows Deployment"
        debugPause
        return
        ;;
esac

Going through Shellcheck.net only pointed out variables I assume are called from other scripts (like the fog.postdownload script).

@Wayne-Workman Thanks both - I’m now on 1.3.1-RC-5 and these problems are still occurring.