Does anyone have a good idea how to accomplish this update w/out user interruption?
I can’t find an MSI switch that will finish on reboot, which would be fantastic.
So now I’m looking at scheduled task, which I prefer not too do.
Pushing w/ NinjaRMM. Debated custom fields for subnets and push when VPN is not connected. Or if there is a cli to test VPN in anyconnect, that may work too.
Any ideas here? I’m not familiar with the client, but I’m pushing this update. Checked cisco site. Not very helpful w/o umbrella
AnyConnect is capable of auto updating. Put the package on your ASA or VPN head-in hardware and it will download and install the new version on the next connection. This is how we performed updates to the AnyConnect client for years until we pushed out the umbrella roaming agent which is capable of keeping the client up to date itself.
Can you just put the updated client on your FDM?
Apparently that wasn’t configured even during deployment. Hooray!
So I think I’m stuck using an MSI and checking if VPN is in connected status. I just wish finish on reboot was an option
There are a number of gotchas here.
VPN gateway alias’ , if not the fqdn, may not resolve after update.
We’ve also seen occasions where the old version gets uninstalled but the new version fails to install.
I have updated AnyConnect version with the MSI many times. Can you go into detail more about what “finish on reboot” means? Are you simply trying to avoid the reboot? Or are you removing the old, rebooting, then installing new?
I’ll keep that in mind. Obviously lots of testing will need to be done.
I’m trying to not allow the MSI to close dependancies and have it finish the install on reboot. I’ve been working with Orca MSI tool to allow the update/install from 4.4 to 4.10 w/out dropping the connection. No avail yet, been a few hours of messing with switches and research to do that.
Edit: Pulling from the ASA and umbrella is off the table.
Edit a few times.
Edit: been drinking - This > “removing the old, rebooting, then installing new?”
msiexec.exe /i {guidshit} /quiet /norestart
Install completes with a 3010 exit code, you can reboot whenever you want at this point, 30 min, 9 days, next year. App may not work until you do but this how I install everything.
Maybe you should change your strategy and accept some user downtime/impact in your process. All my installs that interrupt users run at 10pm on the nose, the end-user (if present) then gets a countdown for a reboot that will occur in 6 hours. Plenty of time to finish up their zoom meeting/sales call. For something like a VPN they lose connection at 10pm, too bad so sad, we are patching this unit. We message out messy upgrades like that but really nobody complains that maintenance occurs at 10pm. I even have one script that changes the computer name and they get zero warning on the reboot, I can’t wait 6 hours on that rename. Users don’t own that box, I do. Stop trying to make it pleasant for the end-user.
There is no way to update a VPN and not have it drop. Just resign yourself to your end-users being impacted by change. That’s what your Change Control team handles, notifications of impact.
Trust me, I really want too do that. Place I am at now likes IT too be a shadow, not in a bad way. I’ll admit enjoying the 30 reboots I’ve done to attempt success. It is killing me that I can’t just default that option already built in to the msi to select that bubble too finish on reboot instead of close apps. It’s already there! And I don’t like giving up since a solution could open doors.
I’m leaning heavily on a login scheduled task to install. It keeps the configuration on update. So at worst the icon may not be in the system tray for a bit.
Thank you for your response as well. I discovered Orca in this thread which is a fantastic tool
If you don’t manage the firewalls, it’s not your problem. Throw the ticket at whomever manages the firewalls and get them to setup a headend update. It is enforced on connect (as long as the version is newer), doesn’t require a reboot and is non-disruptive to users currently connected, as it only kicks in the next time they connect.
Yea, ended up using IP detection w/ install via NinjaRMM. At least now they have a run on install task sequence, which I love.
It went through well.