@petěrko I actually noticed this same problem. Hadn’t gotten around to reporting it yet. I just used an FTP client to upload to /opt/fog/snapins as a workaround. I share a script for many snapins so deleting and recreating wasn’t really an option.
Maybe @Sebastian-Roth can help us out.

@george1421 I was intending on sharing my changes in that 2017 post on drivers and on the unattend updates by the end of this month (still making sure everything is stable and will have to universalize a bit)
Granted, the only changes I made for the drivers related to how I structure my driver packs. Like I don’t have anything other than 64 bit windows 10, so I didn’t need all the os code stuff or a structure matching that. I also have driver packs that fit multiple models, in windows/powershell I found ways to match models based on the folder name but wasn’t able to recreate that syntax in bash (I’m sure it can be done, I just didn’t want to put in the time). So instead I added a ModelList.txt file in each driver pack and have it use grep to search all of those files for the model of the machine. This also helps in handling spaces in the folder structure and model name, as I didn’t want to recreate my entire driver folder structure without spaces. So I didn’t need the bit that removes spaces from the make\model (I also change manu to make and machine to model). I also had to add bits as mentioned below for the makes that have a ‘.’ as it was seeing that as a command in some cases.

I also had some notes on how and when the drivers are added in windows, as you can use the unattend.xml to deploy them during the specialize phase before it gets to oobe. You also can do pnputil without the /install flag first so that all the drivers are added to the pnp store so once they are visible they will auto add in windows.

Also the unattend update example mentions putting the password in plaintext, but the fos console has access to the $adpass variable from the host information. So it can pass that to the unattend without displaying it. I would also add a note about being sure the unattend.xml files should be deleted.

I don’t know why I waited so long to play with the driver injection and other postdownload scripts, once I did I added so many improvements in speed and stability to my provisioning system.

I also added a log file for what is copied down that is visible inside of windows, basically had it pipe to said log file instead of to null.

This is what my snippet looks like for getting the model

ceol=`tput el`;
make=`dmidecode -s system-manufacturer`;
make="${make%.*}";

dots "Identifying hardware"

if [[ "${make}" == "Hewlett-Packard" ]]; then make="hp"; fi
if [[ "${make}" == "HP" ]]; then make="hp"; fi
if [[ "${make}" == "Hp" ]]; then make="hp"; fi
if [[ "${make}" == "VMware, Inc" ]]; then make="VMware"; fi


case $make in
    [Ll][Ee][Nn][Oo][Vv][Oo])
        model=$(dmidecode -s system-version)
        ;;
    *[Ii][Nn][Tt][Ee][Ll]* | *[Aa][Ss][Uu][Ss]*)
        # For the Intel NUC and intel mobo pick up the system type from the
        # baseboard product name
        model=$(dmidecode -s baseboard-product-name)
        ;;
    *)
        # Technically, we can remove the Dell entry above as it is the same as this [default]
        model=$(dmidecode -s system-product-name) 
        ;;
esac

# if the model isn't identified then no need to continue with this script, just return to caller
if [[ -z $model ]]; then 
    echo "Unable to identify the hardware for manufacturer ${make}";
    debugPause;
    return;
elif [["${model}" == "Surface Go"]]; then
    echo -en "\n\nSurface Go will also match other generations of Surface Go, adding a 1\n\n"
    model="Surface Go 1";
fi 

echo "${model} Identified";

Then I find the driver pack to copy like this

dots "Preparing Drivers"
#folder to copy into, I create this when I setup my image and also embed a small selection of storage drivers that aren't included in the default windows install (.i.e any that require loading a driver when installing windows manually such as intel vmd/raid types or vmware paravirtual scsii) These are added during audit system phase of sysprep
clientdriverpath="/ntfs/Out-Of-Box Drivers"
#the driverstore is organized as make/model but that Model folder can apply to multiple models (i.e. hp shares a driver pack for all the form factors of hp elitedesk/prodesk 400/600/800 g#)
#define the base make path, and cd to it, helps with handling spaces in the path
makePth="/images/drivers/${make}"
cd $makePth;
#find the model in a modellist.txt using grep. I used the API to get all my hosts and then sorted the inventory to show me all the unique makes/models and used that to built the modellist.txt files so that they would match what is found here.
listFile=`grep -il "$model" ./*/*-ModelList.txt`
#set the remote driver path to the parent folder of the modellist.txt where it was found
remotedriverpath="$makePth/${listFile%/*}"
#define the log file that will be visible
injectLog="/ntfs/logs/driverInjection.log"

Then I get ready to copy

#I set up a generic/universal driver pack of network/storage/chipset drivers that I've found aren't included in the default windows install that I've found through trial and error. It probably has a bunch of duplicates (so I call it a hodgepodge) but it helps to get the machine on the network so it can find the drivers it needs when a driver pack wasn't found. 
if [[ ! -d "${remotedriverpath}" ]]; then
    echo "failed";
#output to console and output to log
    echo " ! Driver package not found for ${model} copying hodgepodge! ";
    echo " ! Driver package not found for ${make} ${model} copying hodgepodge universtal oobe drivers ! " > $injectLog;
    remotedriverpath="/images/drivers/generic/universal"
    debugPause;
else 
# output to console and output to log
    echo " Driver package for ${make} ${model} found! ${removedriverpath} will be copied to ${clientdriverpath}";
    echo " Driver package for ${make} ${model} found via ${listFile}! ${removedriverpath} will be copied to ${clientdriverpath}" > $injectLog;
fi 

cd /;
echo "Ready";

echo -en "Driver Injection In Progress\n\n\n"

echo -en "Driver Injection In Progress\n\n"
#I removed the -q and tried to add a progress bar to no avail, but also found that rsync displayed a message saying to use -zz instead of -z for sending with compression, since the output is piped to a log, I kept -q out of it to get more verbose logging
rsync -azz "$remotedriverpath" "$clientdriverpath" >> $injectLog;

echo -en "Drivers.cmd Injection In Progress\n\n"
#this is the drivers.cmd file used during specialize to add drivers
rsync -azz "/images/drivers/drivers.cmd" "/ntfs/drivers.cmd" >> $injectLog;
# I also copy additional files here following this same syntax

[[ ! $? -eq 0 ]] && handleError "Failed to download driver information for [$model] or other files failed to copy"

debugPause

This is the contents of drivers.cmd

echo "Adding drivers to driver store...."
start pnputil.exe /add-driver "C:\Out-Of-Box Drivers\*.inf" /subdirs
echo "Installing drivers for present devices...."
start pnputil.exe /add-driver "C:\Out-Of-Box Drivers\*.inf" /install /subdirs

This is the part of the sysprep unattend under the specialize phase I use to call it

 <component name="Microsoft-Windows-Deployment" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
            <!-- I have other settings inside this component, this is just to show the synchronous command in the component-->
            <!-- commands to run in order during specialize -->
            <RunSynchronous>
            <!-- add and or install the injected drivers and then reboot -->
                <RunSynchronousCommand wcm:action="add">
                    <Path>C:\drivers.cmd</Path>
                    <Order>1</Order>
                    <Description>Add Injected Drivers</Description>
                    <WillReboot>Always</WillReboot>
                </RunSynchronousCommand>
                <!-- Additional commands to run before getting to oobe, I use this for configuring built in windows features using dism powershell commands and I have a powershell function that detects nvidia drivers and attempts to install the graphics driver. This .cmd file just opens a .ps1 file -->
                <RunSynchronousCommand wcm:action="add">
                    <Order>2</Order>
                    <Description>Pre-req steps</Description>
                    <Path>C:\step0.cmd</Path>
                    <WillReboot>Always</WillReboot>
                </RunSynchronousCommand>
            </RunSynchronous>
            <!-- I have a case statement in my unattend updater to set the correct device form. This affects some UI settings in windows, I use 3 as a default as it is a normal desktop pc, there are also ones for detachable or convertible tablets, all in one machines, and many others. You can also just omit this-->
            <DeviceForm>3</DeviceForm>
        </component>

This above component needs to be in the specialize settings block, i.e.

   <settings pass="specialize">
        <!-- other specialize components-->
       <component name="Microsoft-Windows-Deployment" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
           <!-- stuff from above -->
       </component>
   </settings>

I recommend using windows system image manager (https://docs.microsoft.com/en-us/windows-hardware/customize/desktop/wsim/windows-system-image-manager-technical-reference) for creating your initial unattend file.

@dvbnl Looking at it again, that makes sense, the old code had it setting all Dell manufactured systems to nothing.

@dvbnl It’s the “.” in “Dell Inc.”
I was just implementing this and found an issue with “Vmware Inc.” specifically the “.” not being seen as part of the string.

I chose to remove any trailing dots in the manufacturer name.

add this second manu definition, and it should help move you forward.

manu=`dmidecode -s system-manufacturer`;
manu="${manu%.*}";

I would also add below it something like

if [[ "${manu}" == "Dell Inc" ]]; then manu="Dell"; fi

If you are structuring your folders with the name “Dell” rather then Dell Inc

@drewgau Also, fog isn’t supported on Ubuntu 22.04 because of a PHP 8 incompatibility. So for Ubunutu, 20.04 is the latest supported version.

@drewgau There may be some sort of package or repo pre-requiste you’re missing. It also says it failed to stop the web service in your screenshot, did apache/httpd not get installed either. Is apt-get/yum working to install normal packages?

@geekyjm If your old fog server was on a version pre-ssl then it may have been pretty dated. There was an older update_unattend script where you would have to put the domain join password in plain-text. Now you can use the $adpass variable that pulls from the foghost’s settings. Then the domain password isn’t passed in plaintext in any script files. So you may need to update how that password is stored on your hosts under ad settings (I believe there’s a global method in the fog settings GUI) and then try again.

I just started using the update_unattend postdownload script myself and was successful without having to have the password in plain text anywhere and the machines joined the domain.

As @george1421 mentioned there may be more going on here, as there may be some new steps needed for your fog install, but we can get this working the way you’re expecting again none the less.

@geekyjm Yes lets see what the script looks like. I have some theories on what’s going on.
What version of fog were you using and what version are you on now?

@geekyjm Are you using a postdownload script to dynamically update your unattend.xml file so sysprep will join the domain with the settings given by fog?
Or are you using the fog service to join the domain during the oobe firstlogon phase, or after that?

@r-pawlowski I would be happy to help in anyway I can. Personally, I deploy a bootmanager (grub2win) and the ipxe.efi file to each machines efi partition. Then I can just change the boot managers default to boot straight to fog. It takes a bit of time to get setup, but I found it to be the most reliable as I then didn’t have to worry as much about the bios settings. Theoretically you can use bcdedit commands to change the boot order to boot to network, but that also differs on different hardware.

I digress though, the easy bit for queueing an image to deploy

• Follow the setup instructions for the fog API (involves installing the module from powershell gallery and then inputting your API keys and fog server address)
• Then make sure the host you’re imaging is assigned the correct image, this can be changed in the API if you need that, but for this quick example, we’ll pretend it’s set correct.
• For an example, we’ll say the hostname of a computer in fog is ‘test-computer’, so this will find the host in fog, then queue an image to deploy on it right now

$hostID = (Get-FogHost -hostname 'Test-Computer').id
#create a quick json string, this can also be done in a powershell object and converted, but this is just a quick example.
#tasktypeID of 1 is a deploy task, if no runtime/schedule time is specified, it defaults to instant deploy
# shutdown = 0 is not scheduling with shutdown
# I believe other2 = 0 means not a debug
# other4 = 1 means to enable wol
# isactive =1 means the task is active
$jsonData = "{`"taskTypeID`": 1,`"shutdown`":`"0`",`"other2`":`"0`",`"other4`":`"1`",`"isActive`":`"1`" }";
# make the API call to create the new task for your host
New-FogObject -type objecttasktype -coreTaskObject host -jsonData $jsonData -IDofObject $hostId;

Once you have this all setup in a powershell module or script internally, you can get things automated pretty smoothly. It’s meant to be modular so it can be applied to any infrastructure or workflow and built upon.

If you need more help let me know and I’ll see what I can do.

@jape You can use the api (See the powershell api module links in my signature). You can use it to create the scheduled task. i.e. (provided you got the module all setup prior) the following would create a scheduled deploy task for host with id ‘1234’
at 8 pm tonight. The following is all powershell that can be run from your admin workstation.

#define the schedule time in the linux format
$startAtTime = (get-date 8pm)
$EpochDiff = New-TimeSpan "01 January 1970 00:00:00" $($startAtTime)
$scheduleTime = [INT] $EpochDiff.TotalSeconds - [timezone]::CurrentTimeZone.GetUtcOffset($(get-date)).totalseconds
#define the schedule time in human readable format
$runTime = get-date $StartAtTime -Format "yyyy-M-d HH:MM"
$jsonData = @"
                    {
                        "name":"Deploy Task",
                        "type":"S",
                        "taskTypeID":"1",
                        "runTime":"$runTime",
                        "scheduleTime":"$scheduleTime",
                        "isGroupTask":"0",
                        "hostID":"1234",
                        "shutdown":"0",
                        "other2":"0",
                        "other4":"1",
                        "isActive":"1"
                    }
"@
#create the scheduled deploy task with the defined json
New-FogObject -type object -coreObject scheduledtask -jsonData $jsonData

@wayne-workman My first instinct is to say “whoa there, lets not abandon centos and its enterprise grade security”.
But at the same time, I’m still using CentOS 7 for Fog and never took the time to upgrade to 8 as I’ve read in this forum and other places of troubles. I didn’t even know there was a thing called CentOS Stream (keeping up with windows constant OS version upgrades takes up all my OS research time). So, despite my instinctive hesitance I’m all for this idea, simplifying development requirements for the win.

However, there are many that were taught the mentality in various ways that RHEL = better for business, and ubunutu = for linux beginners. This isn’t a true statement, especially nowadays, it is a mentality that still exists though. So if we’re going to discontinue native installer support for CentOs, I think we should write something up for our public pages, like on the fogproject.org download page, to help not deter users with this old thinking of ‘RHEL is better for business’ engrained in their soul. Just my 2 cents.

Also, for those 122 of us on the older CentOS 7/8, would this change to the installer make it so we need to move distros for future updates?

Also, if we’re going to focus the installed on ubuntu and debian, might we look at creating and publishing an apt package to make installs even easier?

@jj-fullmer I haven’t done a full thorough fog windows 11 test. But it seems that some of the cpu and bios security “requirements” aren’t hard requirements. As long as your cpu supports TPM 1.2 you can do a clean install of windows 11, you just can’t in place upgrade (without a registry change).

I am also posting this on a computer with windows 11 on it, with an i7-6700. I didn’t use fog, and secure boot got enabled by the windows 11 installer (it might have already been enabled, I didn’t double check sadly). However I just disabled secure boot and could still boot.

So the concerns about a secure boot requirement may be unfounded. This is my home computer and I don’t have a fog server at home, but I’ll come back here once I get a chance to test creating and deploying a windows 11 image to see if there are any issues with secure boot. If anyone wants to test this out @testers before I get some time, you can download a windows 11 iso here https://www.microsoft.com/en-us/software-download/windows11?ranMID=24542&ranEAID=0JlRymcP1YU&ranSiteID=0JlRymcP1YU-aILwA1rXpThxrraz01AUgg&epi=0JlRymcP1YU-aILwA1rXpThxrraz01AUgg&irgwc=1&irclickid=_2cqgd3xf9kkf6xflm1yfj9km9e2xoz2ov3bwz2yp00

@sebastian-roth I need to get back into those docs. Things have been just so crazy lately. When you have something working let me know and we’ll get it documented.

My solution for this problem has been to use the api the remove usb macs when my provisioning script is done. I have it working by using the client.
The basics are

• Computer gets registered with usb adapter
• My custom provisioning starts and the fog service is started which will add pending macs
• I leave the usb adapter plugged in until my provisioning is complete (so software install and whatnot happens over ethernet not wifi)
• Last step of provisioning uses a powershell api function to remove any existing usb macs (I have a saved list in the powershell of macs in my code)
• Adapter can then be removed and used on the next device

My custom functions uses my published fogapi powershell module, particularly this function https://fogapi.readthedocs.io/en/latest/commands/Remove-UsbMac/
Here’s a link to the code on github https://github.com/darksidemilk/FogApi/blob/master/FogApi/Public/Remove-UsbMac.ps1
The function also handles making a new mac the client found be the primary mac if the usb mac is the current primary.
If you’re not using the client, you could also create a custom automation to find the mac addresses of the machine during a postscript/firstlogon/provisioning step and have it use https://github.com/darksidemilk/FogApi/blob/master/FogApi/Public/Add-FogHostMac.ps1 to add a new unique mac then use the remove-usbmac function to remove specified usb macs.

If you’d like more info or examples I’d be happy to help, just wanted to offer a quick overview of a possible solution.

@sebastian-roth said in boot php - denied:

@robertkwild said in boot php - denied:

the desktop in question that gets the error is a hp z640

Searching the forum I found that @JJ-Fullmer also has used HP Z640 machines some time ago. I am wondering if you have HTTPS enabled on your FOG server as well?

Holy cow that was a long time ago. That’s when we added nvme support. Good times.

Glad to hear you got it working @robertkwild sounds like it probably was the cmos/time issue.

@austinjt01 Have you tried different versions of bzImage and or init.xz?
i.e. try downloading the latest kernel from the kernel update screen in your fog gui and giving it a name like bzImage5 and then set that case sensitive name as the kernel on the fog host in question and see if it makes a difference.

Also, have you checked in the fog web task manager when it is stuck to see if it shows progress there? It’s rare, but I remember once seeing it look like it was stuck but the computer just wasn’t displaying the progress and it was actually working.

@cello said in How to create a Windows 10 Image:

Is it also possible without Sysprep?

It’s a trap!

While there are ways that appear to work without sysprep, you’ll have a much better time if you just use sysprep.
I learned this the hard way. Sysprep has gotten faster and a bit easier (in some respects at least).
If you don’t use it, you’ll end up with windows licenses with the same universal identifiers, which breaks volume license activation tools.
You can also end up with driver problems if the image wasn’t created on the same model computer and you don’t use sysprep.

If I were to sum up our steps for creating a win 10 image (but like @george1421 said it’s a bit out of scope and would take days to answer in full detail, also we don’t use MDT, just to provide another method) I would say

1. Download iso of latest version of most recent windows 10 H2 release (i.e. 20H2, ltsb versions are also a trap unless truly neccessary)
2. Create an unattend file using windows system image manager (see also https://docs.microsoft.com/en-us/windows-hardware/customize/desktop/wsim/windows-system-image-manager-how-to-topics) I personally took the time a few years ago to ready through all the options available, it’s pretty extensive. But you can also make it pretty basic with setting some simple settings, adding some first logoncommands, and then just make sure you read up on using the ‘reseal’ options to make the sysprep phases go in your desired order. (i.e. I have mine go Audit System - adds (but doesn’t install) network drivers to the driver store -> Audit User - reseals to generalize -> Generalize - removes drivers not added by sysprep and makes the image general for any device -> I have it send to shutdown from here -> I Upload it to fog -> When it deploys it starts the specialize phase -> Then it goes through oobe (which you can make unattended, there are some skip oobe options to be sure it doesn’t show, but you want to be sure all settings that would be set during interactive oobe are set by your unattend.xml created with windows system image manager)
3. Install the iso on a vm (or whereever you want to capture your image from), at the oobe screen after install hit ctrl+shift+f3 to enter audit mode
4. DO NOT OPEN THE WINDOWS STORE (if apps are updated in the store, sysprep won’t run, it’s a whole thing)
5. Add customizations/files you want on all machines (some will be removed by sysprep, figuring it out involves some reading and trial and error) and add the unattend.xml file to “C:\Unattend.xml” and “C:\Windows\System32\Sysprep\Unattend.xml” (I like using both places as a fail safe to be sure its used). I personally use custom powershell modules to automate this whole process, scripting it in some way is a good idea once you get it dialed in. I suggest limiting program installation at this step, I have found its better to use a provisioning method such as snapins and or chocolatey triggered by the firstlogoncommands to add programs, easier to keep them up to date and if something goes wrong with an install it’s not then on every single one of your computers.
6. Run sysprep (i.e. sysprep.exe /audit /reboot /unattend:"C:\unattend.xml") and capture the image to fog
7. Deploy the image with fog and watch the magic happen

Part of the oobe phase can involve auto-logging in as the administartor and running the firstlogoncommands, which is where (if you didn’t add it during audit mode) you can make sure the fogservice is there and will get your computer connected to your domain.

This is all a very high level overview and there may be some steps in between beyond creating scripts and other infrastructure. docs.microsoft.com has many helpful guides for the available unattend.xml options and creating images, I thought I had some of the more helpful ones bookmarked/referenced in internal docs but I can’t find them at the moment. I’ll share them if I find them later and remember.

If you take the time to do it right and get it all setup, it becomes very easy to create new images and deploy them.
You could also easily use fogs scheduled tasks to deploy the image nightly on machines. You’ll just need to dial in the firstlogoncommands to work they way you want it to.

According to the official page from microsoft https://www.microsoft.com/en-us/windows/windows-11-specifications it just says “secure boot capable” I guess we’ll just have to wait till it’s released to insiders to get some real world information.

I realize this was only just announced today, but windows 11 is coming as early as this year and it now (allegedly) requires secure boot and tpm to be enabled to be installed (see also https://www.windowscentral.com/windows-11-system-requirements)

There’s been past discussion about getting secure boot supported for fog, but it looks like the time soon comes where we have to do it (which seems to be a theme with a lot of things in tech recently and in the coming year)

So I just wanted to open up a new thread to get the discussion going to see what needs to be done.