Help troubleshooting why we can not update agents via the ControlUp Console?

A user asked why agents cannot be updated via the ControlUp console. It is likely due to lack of admin rights, but AppVolumes can interfere with unzipping files. A possible workaround could be using the monitor command, updating the .NET version to 4.8, or using an Appvolume with the ControlUp agent. The Appvolume method has so far worked successfully. Title: Troubleshooting ControlUp Agent Updates with AppVolumes

Read the entire ” thread below:

Any clues on why we can not update the agents via the controlup console?

Chances are its lack of admin rights. If you right click that machine do all the "diagnostics" pass?

I believe so, The 05 has been updated to the current version and the 08 is running the previous version, but I can still see everything

So you were able to update some of the machines in the pool but not others?

These two tests are the most important.

Do you happen to be using AppVolumes on those machines? We’ve seen some problems with extracting zip files on appvolumes.. volumes.

Yes we do use AppVolumes.

@member Yes I can do both of those Admin$ and TestWMI@member Also on the two machines, I had connected, I manually update 05, and then attempted to push the update via the ControlUp Console to 08“`$files = get-childitem "c:\program files\smart-x\controlupmonitor" -filter "powershell.user.dll" -Recurse

$latest = $files | Sort-Object -Descending -Property LastWriteTime | Select-Object -first 1

Import-Module $latest.FullName

set-ExtractLocal -EnableExtractLocal $true“`

You have to run that on a monitorThe 1st section loads the monitor PS module.

The 2nd section changes a hidden setting. By default the console copies a zipped version of the agent to the remote machine and then extracts it. This extracts the agent files locally and then copies individual files. A little bit less efficient but seems to solve the issue.

PS, the actual issue seems to be when the ZIP extraction library tries to rename temporary files. It only seems to happen on appvolumes enabled machines. We’ve had a customer open a ticket with VMware, but were never able to find a solution.

So we’ve developed this workaround instead@member This has to be done on the Site/Monitor server correct?

yeah. Any monitor will do as it is a global setting

There just isn’t a UI for ityou using writable or regular appvolumes? Looks like they changed a lot with appvols4 writable volumes https://communities.vmware.com/t5/App-Volumes/Appvolumes-4-issue-User-Writable-contains-lot-more-random/td-p/2856545

@member FYI

Anyone ever thought about just creating and Appvolume with the ControlUp agent and push it to the machines that only the users are logged into? Instead of installing on the golden image?

you will most probably miss critical data if the app volume is added after the user logs on.

What kind of data are you referring to Sir?

logon times would be broken for example

So if we assign it to the pool when the machines are spun up, we would not loose that login data, correct?

Any issues here or thoughts?

that would work indeed

Thank you Sir, we are testing that concept now.

I would prefer the regular msi in the golden image above that btw as there is no problem with a difference between agent & console version btw

We can not update the agents on all our machines, we believe it’s got something to do with Appvolumes, so testing this, we can quickly upgrade the appvolume, with the correct version.

Hey Bill, out of curiosity. Did the monitor command work around the issue?

We saved that Mr. Dennis, but didn’t run it on the monitors, we decided to go with the agent in an Appvolume, So far so good. Seems to be working well, and when there is an update, we can just upgrade the appvolume and we are done.

Had a similar issue updating a monitor and it failed until I updated .net to 4.8

Continue reading and comment on the thread ‘Help troubleshooting why we can not update agents via the ControlUp Console?’.  Not a member? Join Here!