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

@quinniedid Hmmm that is interesting for sure. Now that I think about the versions, maybe some of my problems showed up when I updated things to the most recent refind.
However I noticed another thing, which may or may not be related to the version of rEFInd. In the HP bios boot options, when I installed my local refind, it used to show a normal uefi boot option to the disc drive, a windows boot manager option, and my custom refind option. Now it seems that the custom refind option overrides the other options.
Perhaps windows 10’s bcdedit is now able to control hp bios boot options? I’m just spitballing here. But perhaps refind can’t find any boot loaders because the bios/firmware doesn’t see those boot options either. It wouldn’t fully explain why the fog rEFInd isn’t seeing the boot options during its scan but it could be something. Another possibility is a csm type of issue (I think that’s the right acronym). Where you have both legacy and uefi boot options enabled. I currently disable legacy completely, but refind has the ability to scan for those legacy options, perhaps re-enabling legacy options will allow it to find those and maybe that will help it find the uefi options as well. Gonna keep playing with it and see if I can find a clear answer. If None of these combinations of things work then I’m gonna say you’re right and the newest version of refind is what breaks things.

The funny part is that the point of refind is that it’s supposed to scan all the volumes for you to solve this very problem. So something is very weird here.

@quazz Where did you read the numbering labels are based on bios boot orders? If that is indeed the case one can control boot order to some extent and that would work. You would just want to make sure usb and disc options were always lower on the list, maybe even disabled and just utilize refind to boot to them.