Question

Cloudflare WARP fails to update, running.

  • 27 February 2024
  • 11 replies
  • 128 views
K
Badge

Automox supports the updating of cloudflare warp, per this url: https://www.automox.com/patching/software/cloudflare-warp-client

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.

11 replies

MarkH-Automox
Userlevel 3
Badge

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. 

Pros and cons :(

 

$ResolveWingetPath = Resolve-Path "C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_*_x64__8wekyb3d8bbwe"
    if ($ResolveWingetPath){
           $WingetPath = $ResolveWingetPath[-1].Path
    }

$config
Set-Location $wingetpath
.\winget.exe upgrade Cloudflare.Warp -s winget -h

 

K
Badge

Mark, thank you for the reply.

We have found that the following is true with winget, so far.

  1. It does a great job installing Cloudflare WARP initially.
  2. 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.

 

$ResolveWingetPath = Resolve-Path "C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_*_x64__8wekyb3d8bbwe"
    if ($ResolveWingetPath){
           $WingetPath = $ResolveWingetPath[-1].Path
    }

$config
Set-Location $wingetpath
try {

    Write-Host "Attempting CloudFlare WARP Upgrade"
    .\winget.exe upgrade --id "Cloudflare WARP"

    } catch {

    Write-Host "An error occurred: $($_.Exception.Message)"

}

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.

 

K
Badge

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.

MarkH-Automox
Userlevel 3
Badge

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?
 

K
Badge

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.

K
Badge

Winget | Community (automox.com)

 

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.

MarkH-Automox
Userlevel 3
Badge

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:

#WebClient
$dc = New-Object net.webclient
$dc.UseDefaultCredentials = $true
$dc.Headers.Add("user-agent", "Inter Explorer")
$dc.Headers.Add("X-FORMS_BASED_AUTH_ACCEPTED", "f")

#temp folder
$InstallerFolder = $(Join-Path $env:ProgramData CustomScripts)
if (!(Test-Path $InstallerFolder))
{
New-Item -Path $InstallerFolder -ItemType Directory -Force -Confirm:$false
}
	#Check Winget Install
	Write-Host "Checking if Winget is installed" -ForegroundColor Yellow
	$TestWinget = Get-AppxProvisionedPackage -Online | Where-Object {$_.DisplayName -eq "Microsoft.DesktopAppInstaller"}
	If ([Version]$TestWinGet. Version -gt "2022.506.16.0") 
	{
		Write-Host "WinGet is Installed" -ForegroundColor Green
	}Else 
		{
		#Download WinGet MSIXBundle
		Write-Host "Not installed. Downloading WinGet..." 
		$WinGetURL = "https://aka.ms/getwinget"
		$dc.DownloadFile($WinGetURL, "$InstallerFolder\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe.msixbundle")

		#Install WinGet MSIXBundle 
		Try 	{
			Write-Host "Installing MSIXBundle for App Installer..." 
			Add-AppxProvisionedPackage -Online -PackagePath "$InstallerFolder\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe.msixbundle" -SkipLicense 
			Write-Host "Installed MSIXBundle for App Installer" -ForegroundColor Green
			}
		Catch {
			Write-Host "Failed to install MSIXBundle for App Installer..." -ForegroundColor Red
			} 

		#Remove WinGet MSIXBundle 
		#Remove-Item -Path "$InstallerFolder\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe.msixbundle" -Force -ErrorAction Continue
		}

 

I got this script from Jumpcloud forums: https://community.jumpcloud.com/t5/community-scripts/install-winget-in-the-system-context-and-applications-via-winget/m-p/1399

K
Badge

Directory: C:\ProgramData


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.

 

K
Badge

Despite reporting success, winget is not installed.

Once I solve this, I think the other worklets / policies will fall inline. 

 

K
Badge

Install winget into allusers vs. userprofile for the ability to run winget as SYSTEM · Issue #1627 · microsoft/winget-cli · GitHub

 

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. 

 

 

 

 

K
Badge

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.

 

 

Reply


Terms & ConditionsCookie settings