@psycholiquid Have you tried reverting the FOG Server refind version to 0.11.0 and older? That’s the current workaround.

@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
• 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

Hope that helps.

@mecsr Use powershell instead of bat scripts, you’ll have more power. Pun intended, but it’s also just true. Especially when it comes to licensing tools. Sometimes the tools just don’t have command line options. Powershell has more user friendly tools for editing registry keys and environemnet variables which licenses sometimes require.

Also use the windows system image manager included in the windows ADK for creating an unattend.xml file

Snapins are an excellent method.

@victorkrazan6267 I just read this part after making my domain central store reccomendations.
We have some non-domain computers and I utilized copying the admx files to C:\Windows\PolicyDefinitions for setting the policies in local group policies. You could theoretically embed them in your image as well.

You can also use the policyfileeditor module https://www.powershellgallery.com/packages/PolicyFileEditor/3.0.1
to edit the local group policy as part of that script.

i.e. to set chrome to always open pdfs externally you could do

$machinePol = "C:\WINDOWS\system32\grouppolicy\machine\Registry.pol";
$chromeKey= "Software\policies\google\chrome";

Set-PolicyFileEntry $machinePol -key $chromeKey -ValueName "AlwaysOpenPdfExernally" -Data 1 -Type DWord;

It takes a little time to learn that module. But it’s pretty useful to have a way to script changes to local group policies.

So this is an idea unrelated to your script syntax
Do you have access to your active directory central store and are all the computers involved in AD?
Based on what you have written you’re using the adm policy templates for applying chrome policies via group policy that you had set at the AD level.

If you copy the admx files to the central store they’ll get copied down to each AD joined computer automatically. Is that an option for you?

I believe that the folder you’re copying to has some extra security built into it or something. I remember reading that once upon a time. You can use the chrome.admx file and the googleUpdate.admx files from where you got the adm files and copy them to c:\windows\policyDefinitions and that will work fine. I used to do it that way before I started just including them in the domain central store which can be accessed (read\write) remotely via \\domainControllerHostname\C$\Windows\SYSVOL\sysvol\domainFqdn\Policies\PolicyDefinitions You may have to login to the domain controller and find the local folder of that share.
I think you can copy adm files to either the central store or local store too, but I’ve read that admx files are the better option. I can’t remember why but I recall it being convincing.

I hope that helps.

@jgallo
in User/Channel to post to you either choose to sent it to a user or a channel.
You are setting the destination, the access token is going to make it send from your user. This integration doesn’t create a bot like other slack integrations. You could create a separate slack user called fogbot to connect this integration and that would make it send as a different user.
But lets say you don’t do that, here’s what will happen in 2 different fixes

So if you change User/Channel to post to to @fogbot

then it will send updates from your slack user in a direct message to fogbot in slack.

If you change User/Channel to post to to #fogimaging then updates of imaging actions will send from your slack user to the #fogimaging channel.

Hopefully that helps as I’m guessing that you’re thinking that you’re setting a user to post as because many other slack integrations require that. This one is a bit more basic as it just uses the user in the access token and sends it to a choice of destination.

So think of access token as the source and User/Channel to post to as the destination

@quinniedid I haven’t heard from the rEFInd developer since the initial contact. As soon as I know something I’ll post it here.

@george1421 I meant to put that I volunteered as tribute when I quoted his reply.
I’m sure he’d appreciate more testers as well if anyone’s interested.

@george1421 The developer has replied, I have quoted it below

Thanks for the bug report. Upon reading the thread, I think the bug may be related to changes I made to work around problems caused by changes to the way macOS stored its files on APFS volumes, as noted in the release notes for version 0.11.1:

: As a follow-on to the preceding change, I discovered that compiling
: rEFInd with GNU-EFI resulted in a failure to properly track some
: files on APFS volumes. I don’t know if this failure reflected a bug
: in Apple’s EFI, in GNU-EFI, or in rEFInd; but I changed the way
: rEFInd tracks boot loader files internally to work around the
: problem. Although I’ve tested this version on an unusually wide
: number of computers, it’s possible that this change will introduce
: new bugs. Thus, if you upgrade and have problems with boot loaders
: not being detected or not launching, dropping back to version 0.11.0
: may be worth trying. (Be sure to contact me with a bug report, too!)

I can look over these code changes for any obvious bugs, but tracking this down may require testing with debug versions that display debugging data. If you or somebody else who’s affected can help with that, it might speed up the process.
FWIW, some of the reports mentioned HP EliteDesk computers. I happen to own an EliteDesk 705, and I have NOT seen the problem on it. Thus, I suspect that the problem appears as an interaction with a very limited set of EFIs and/or something quirky about the partition table, filesystem, or other system-specific setup. This isn’t to say the bug exists in some other component, but it’s likely manifesting only in some rare circumstance.

In the meantime, using version 0.11.0 makes sense as a workaround.
–
Rod Smith

@quinniedid I changed my fog’s refind.efi out with rEFInd 0.11.0 (The first version I used for local installs) and it started working for me too. I think there must be some sort of bug in 0.11.1 and 0.11.2 that affects HP pro/elite Desk systems. I am reporting it to the developer of rEFInd.
So would you say your problem is now fixed by reverting to the older version of rEFInd? Or are there still some different problems happening?