However, when it attempts the update, we’re having a number of issues. First, is that the update most often just fails stating Cloudflare was running. Of course it’s running, it runs all the time. :)
Second, is that if an update fails, the laptops network stack is quite impacted. This is more of a WARP client issue, but it needs to be accounted for.
What is the best practice way to patch the Cloudflare WARP client with Automox.
Anyone with tips on how to handle patching and updating CF WARP, please share. I have been quite unimpressed by CF WARP / ZeroTrust so far, it’s borderline snake-oil.
Page 1 / 1
Hello KirkH,
The best approach I have found is to use a Worklet leveraging Winget. This will kill Cloudflare and not even relaunch it however, the end user will need to relaunch it.
We have found that the following is true with winget, so far.
It does a great job installing Cloudflare WARP initially.
It doesn’t do great with updating Cloudflare WARP.
Because our default update policy is attempting to address the cloudflare client version, I’ll need to create an exception there I think to ensure we are not doubling our efforts on the upgrade front.
I will keep poking at the winget logic to see if I can solve this. It’s proving to be a difficult solve to reliably and rapidly update the CF WARP client. When updates do not succeed the failed attempt can leave a devices networking in a bad state, which makes the repair / re-install very difficult for a primarily remote deployment use-case.
Here is what I have so far, but it’s not quite getting it done. I moved to a try/catch logic as it was the only way I have been able to get usable logs into the activity logs.
Here is the current error, which indicates winget is not properly found in the AM agents system path.
Attempting CloudFlare WARP Upgrade An error occurred: The term '.\winget.exe' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
I have worked with CGPT and Otto to try and solve the pathing issues. So far, no dice.
Strangly, the path .\winget.exe works during install, but not upgrade. I can’t determine why there seems to be a behavior difference in the path for winget for install vs. upgrade.
An error occurred: The term '.\winget.exe' is not recognized as the name of a cmdlet, function, script file, or operable program.
This is unrelated to the Automox agent and is directly related to whether or not Winget is installed on the device. Powershell is returning this error. Try to run ./winget locally on the endpoint and you would see the same message.
What is the operating system of the device in question?
The devices are Windows 10.
It sounds like a policy to install Winget in the system space might be required first?
I thought we were setting the path in the start of the script to use a system based winget. Perhaps, I need to ensure that exists first.
Your post here has me headed the right direction, I think. I’ll let you know how I fare.
Step 1: solve winget install with remediation winget
Step 2: re-test CF upgrade.
You’re understanding is correct, the start of the example scripts sets the location of where winget.exe exists, but if its not there we see the error you are encountering. I have this script which can be run as a Worklet to install winget. I haven’t used it in a while but let me know if it works:
Mode LastWriteTime Length Name ---- ------------- ------ ---- d----- 2/27/2024 8:32 AM CustomScripts Winget is not installed. Downloading Winget... Installing MSIXBundle for App Installer... Installed MSIXBundle for App Installer
The script appears to have worked. The “C:\Program Files\WindowsApps dir is protected, so I can’t validate the install even with local admin rights, the steps to take ownership of the dir risk impacting the system, so I didn’t attempt to do this.
There is no error I can see, but the update still didn’t work. I will add try/catch logic around it and see if the error has changed, or if winget is still not accessible to the AM System user.
Despite reporting success, winget is not installed.
Once I solve this, I think the other worklets / policies will fall inline.
While not new, the above issue covers why winget is difficult to run as a system user. In short, it’s guarded against as part of the security model of winget design.
The solution to install winget as a system user, requires that we “hack around” those protections. It may be unwise to do this from a security standpoint.
So I have a follow up question:
Is it possible for the automox agent to impersonate the logged in user during installs?
If winget must run as a user, it may be better to try and targer running winget commands as the user, if possible.
The benefit of the .msix packages is that they do not require admin to install. They have higher signing standards achieve this, I believe. If we can act as the user, this may be a better solve.
Also considering just throwing winget out the window and taking a look at Chocolaty.
The hassle with Chocolaty, as I understand it, is if it did not install the software it cannot update it. So I have to first remove CF WARP, then re-install with Chocolaty, then I can patch with a SYSTEM user.
