@gaptoothgonni So while this can be done, FOG is designed to capture an image from where windows is already installed and sysprep’d, not to boot to a wim. Of course it can be done, but I just wanted to make sure that’s clarified.

All that said, doing it that way may or may not get past your problem, because it may just be a client pc bios setting.
If you manually boot to that iso on a usb on that pc, does it see the disks?
That message generally means it’s missing the storage driver.
Does the host you’re trying to deploy to have VMD/RAID enabled in the bios settings?
It is possible, and not even that hard if you’re already customizing the iso, to add the storage driver to the wim. I’ve never used NTLite, but in powershell you can mount the wim of the image with Mount-WindowsImage and use Add-WindowsDriver to add the inf you need to that image. You probably need to mount the boot.wim and setup.wim images and add it there too as you’re booting to the boot.wim and using winpe. This page might also be helpful https://learn.microsoft.com/en-us/windows/deployment/update/media-dynamic-update#update-windows-installation-media

I would also say, if you’re going this route, to consider making a autounattend.xml if NTLite doesn’t do that, as it can automate the install of windows and then have it kick things off into provisioning. We customize an iso like this and use it to create and capture our base image in FOG.

I got a little off topic there, TL;DR
Make sure the disks are seen if you boot to the iso manually, if they are not, then adjust the bios/uefi settings to use AHCI mode for disks as it works universally. If the disks are seen when manually booting, then something else is causing it not to see the local hardware.

@sebastian-roth Hey that’s me!

@Chris-Whiteley I do this all the time. So 100% yes you can do this. I even have some pre-built helper functions for it in the published powershell module FogApi.
So step one is install and setup the fogapi powershell module (check the links in my signature)

I actually do pretty much that exact process in my provisioning of machines.
Check out

• Set-fogsnapins for setting a list of snapins to a host https://fogapi.readthedocs.io/en/latest/commands/Set-FogSnapins/
  (I just noticed I forgot to remove the $dept parameter in that function, that was for my internal use, you can just ignore it)
• Start-FogSnapins for starting the deploy all snapins task on a host
  https://fogapi.readthedocs.io/en/latest/commands/Start-FogSnapins/
• Remove-FogObject for removing the snapins from a host, looks like I haven’t published a helper function for removing the snapins just yet.
  https://fogapi.readthedocs.io/en/latest/commands/Remove-FogObject/
  • here’s an example of how you would remove the snapins. To remove them you have to remove the snapinassociation object.

#create a list/array of the snapins you want to remove
$snapinsToRemove = @('snapin','names','here'); 

#get all the snapin associaion objects
$AllAssocs = (Get-FogObject -type object -coreObject snapinassociation).snapinassociations

# Get the snapins associated with your host
$AllHostSnapins = Get-FogAssociatedSnapins -hostId $hostID;

#get the ids of the snapins you want to remove, from the list of snapins attached to your host.
$snapinIds = ($AllHostSnapins | Where-Object name -in $snapinsToRemove).id

#Get a list of the snapinassociation ids that match your host id and are in the list of snapin ids attached to your host
$assocsToRemove = $allAssocs | Where-Object { $_.hostID -eq $hostID -AND $_.snapinID -in $snapinIds}

# loop through the found associations and remove them
$assocsToRemove | ForEach-Object {
    Remove-FogObject -type object -coreObject snapinassociation -IDofObject $_.id;
}

That should do the trick.

Figured I should add, my speed issue was related to running PHPIPAM (a ip management tool) on my storage node server. It was slowing my image deploys down, not the zstd. It’s crazy fast at compression level 19 now.

@amerhbb
I’m pretty sure there’s definitions of this elsewhere in the forum or in documentation/wiki that is more thorough.

But here’s a quick overview

Exit Types

EFI exit type

• Used for computers in EFI/UEFI mode. This is used in all modern computers for the last few years
• Setting the efi exit type is the behavior fog will use when ‘booting to hard drive’ the pxe menu was booted to via an efi/uefi boot option

Bios

• For older computers or computers using legacy/bios mode
• This defines the behavior when the fog boot menu is accessed via a legacy/bios boot option and then ‘boot to hard drive’ is selected

SANBOOT

• Works for bios exits by issuing a sanboot command to boot to hard drive
• Doesn’t work with efi in my experience EDIT: iPxe has since updated the behavior of SANBOOT and it now works with EFI and is the recommended option.
• This is a good standard default for bios exit type

GRUB

• Uses a grub boot loader hosted on fog to attempt to boot to the OS
• This can work with efi or bios, but it isn’t always super reliable in my experience. It’s a good option to use when troubleshooting a computer that is having trouble exiting the fog boot menu to get to the hard drive

GRUB Sub options

• The sub options like first_HDD, first_windows etc. attempt to do exactly what they say. They are just GRUB bootloader options

rEFInd

• This uses a tool called rEFInd, which re-finds all efi boot options
  • The fog refind conf just boots to the harddrive/os option it finds. It can be configured to give a menu of options
• This can work with bios options in theory, but it’s meant for EFI exit
• This is a good default for efi boot options You can now use SANBOOT instead and it should work properly in EFI, though rEFInd is still a powerful tool

Hope that helps.

As a side note:
The image type description in the wiki (I got there from the balloon help: https://wiki.fogproject.org/wiki/index.php?title=Managing_FOG#Images) points to a non-existing page (404): https://docs.fogproject.org/en/latest/management/image-management.html

Thanks! @JJ-Fullmer would you find the time to fix that quickly?

Fixed!
@medchemii thanks for letting us know. We changed the structure of the new docs page a bit and it affected the links. We’re working on getting redirection working for old links still

@Sebastian-Roth I think you’re thinking of this post https://forums.fogproject.org/topic/16720/hp-elitebook-840-g9-cannot-deploy-image

@Laurent said in Problem with FOG Service …:

I use an encrypted password because I don’t want other fog users to see my password in plain text

I would recommend using a separate domain admin account rather than any 1 user’s domain account. Partly because of the issue you describe (though that’s not something that can be seen in the web gui) but also so that it’s a password that won’t expire with a user leaving and it’s a password that can be rotated without affecting other services.

Just my 2 cents.

@Wayne-Workman
Well it’s not technically a fog issue, but it is an imaging issue and I figured that my fellow image making peers might have some thoughts. I would love to see your documentation on that process

@Andrew-Single This post I made many moons ago at my old job might be helpful to you. It may require some adaptation, but I still use it on a daily basis to update my fog to the latest version…

https://forums.fogproject.org/topic/4578/automated-latest-fog-svn-update-script-1-0-and-later-and-other-helpful-productivity-things

Also this is the wiki on how to install the svn version manually
https://wiki.fogproject.org/wiki/index.php/SVN

hope that helps

@Sebastian-Roth I have a work in progress concept for permanent links. But things have gotten busy and I haven’t had much free time to get it working in full.
Short version is that we’ll be able to create uuids for all pages and that can be used as a permanent link even if it moves elsewhere in the doc.

@AlexMaxwell I don’t suppose you’d be willing to share how you got winPE to work through pxe using an iso? I tried to do that many moons ago to no avail.
Please and thank you =D

Just to answer some of your questions. The delayed task time thing is a bug that I have had too, haven’t actually found a solid fix for it. But with a little testing you can figure out how many hours it’s off and get delayed tasks working. However, this time issue doesn’t effect active directory joining.

Also the fog server not being on the domain is also not an issue. My fog server isn’t on the domain and the AD joining works no problem.

Can you show us a screenshot of the active directory default settings you have set in the fog gui?

Sadly the resizable download doesn’t work on nvme drives. mps and mpa do work though.

I mount my /images from an attached array straight into the /images folder and it works without issue. But I’m using ubunutu 14.04 and the drive is formatted as ext4. But regardless I imagine it would still work.

What does your /etc/exports look like?

cat /etc/exports

what does your /etc/fstab say? That’s where the options for mounting it in the os would be

cat /etc/fstab

what are the permissions currently on /images?

ls -l /images

Are you on the latest trunk of FOG 1.2? I think FOG 1.2 had a fogstorage user that needed permissions to the storage nodes and its password needs to be set correctly in the gui storage node settings.

Does the graph of the space usage display on the fog gui homepage?

Are you able to mount the nfs drive elsewhere?
for example if you happen to have an enterprise version of windows install the
“client for NFS” in the “turn windows features on and off” found in the “add or remove programs” control panel.

If that client is installed you can mount an NFS share in windows by either
running this command in a run prompt…

\fog-server\images

or
In command line

mount \\fog-server\images Z:
cd /d Z:
Z:\>dir
images directory listing pops up

Granted @Wayne-Workman is probably right saying you should add it as a separate storage node since its hosted on a different machine and a different OS and all. But some of this might help troubleshoot this if getting it to work is possible through your current configuration

@AlexMaxwell You are a beautiful and wonderful person.

@anthonyglamis said:

Arrowhead,

I am wondering if this is a DNS issue? My host are all “unable to resolve”.

So the unable to resolve thing doesn’t necessarily affect the active directory issue, but it is something of a dns issue. For example, If your dns or perhaps dhcp server assigns hostnames to the computers based on ip address unless you reserve it in the server (It’s an issue I had at my last job where the university had a custom dhcp server that set the hostname based on the ip address unless you manually reserved by mac address, it was annoying). My point is they could relate, but I’ve seen the active directory join work even when the host isn’t showing as green/up in fog. So I would make sure everything else is right first before seeing if this is the cause. For example, does wake on lan work, because that only works if the host is down, because well it has to wake it from being off. Point is the ad join functionality doesn’t depend on the gui host up/down function in my experience.

Are you also setting the hosts to join the active directory in the gui, or are you doing it in the pxe imaging menu at the computer. Your configuration looks correct for the joining default settings. So as long as that user can join a computer to the domain and the hostname doesn’t already exist on the domain it should work. Just want to make sure you’re clicking the checkbox to tell the host to join the domain.

Also, is the latest fog client/service installed on the computer’s in question?
Also once that box is checked it typically just joins the domain right then restart and all. And if someone takes it off the domain it will just join right back again.

Hope that helps in some way

@Tom-Elliott How might I test this hunch?

If you want to make it so you don’t have to comment out port=0 then you can fix this by fixing the resolvconf missing dns server issue.

See this old post for a ton of detail…
https://forums.fogproject.org/topic/2799/dnsmasq-kills-dns-lookup-on-fog-server/6
I know I’ve posted it in a more readable form more recently, but found that one first.

TL:DR
just edit the interface-order at /etc/resolvconf/interface-order to have your main ethernet adapter at the top and be sure to have nameserver lines defined in your static ip definitions if not using dhcp.

How is your FOG server configured for dhcp?
Do you use a dnsmasq dhcp proxy?
Is fog the dhcp server?
Do you have a linux or windows dhcp server externally?

@anthonyglamis So what is the current status? Did the new image upload and download successfully? Is AD working like magic with the new version?