Currently we are facing an issue where a bunch of Windows 10 Netskope clients attempted to auto update from v94 to v95 based on the setting in the cloud console. We had a large amount of upgrade failures where the person is then left with no Netskope client installed. We disabled the auto update functionality on our steering config once it started to become a major problem to prevent the rest of our users dealing with this.
We currently also use NPA for managing these machines remotely through SCCM and for access to internal resources and we require the Netskope client to be installed for any access to cloud resources. Essentially every user that this happened to is completely unable to work and fixing the issue after the fact becomes difficult as we were switching to relying on a VPN for remote access to Netskope.
Is anyone else facing this issue?
We had pretty much the same issue. Our clients tried to auto update from v93 to 94 and failed, leaving a non-working client and installation failure in the device status. We were unable to reinstall the client but we worked with Netskope support to understand the cause of the failure for the client reinstall and now use a couple of lines of Powershell to clean up the registry keys. This allows us to now install v95 of the client. We manage these through LogMeIn Central while we transition to Intune management.
I am concerned if the issue is also happening with 94 to 95 updates as that means the problem has not been fixed as we were advised. Our support ticket has been escalated for a root cause analysis.
We have the same issue on 96.0 and 96.1. Users unable to access internet once new update was installed. NS console shows expected NS client version, Programs and Features doesn't shows up NS Client, Event viewer shows msi installed with exit code 0, %PROGRAM FILES% and %PROGRASMDATA% folder shows files, Regkey for uninstall exists. I can't uninstall from Program and Feature (appwiz.cpl) since the entry doesn't exist. I install an older version of the client and let it cloudupdate again to the latest version and it starts working. We have a fleet of 26K device and it is annoying and high support overhead if this occurs in every version. I think the msi validation on cloud update packages required a bit more attention to avoid this occurance.
We have been chasing our issue updating from R93 to R94 around 17th May, having been told it was fixed in R95, and instead we were issued with the Root Cause Analysis for clients updating to R96.0 that occurred on 13th July. This stated the issue was fixed in R96.1. We have left autoupdate disabled for the time being.
Being cautious I put just my user in a separate client config with autoupdate enabled. I was running R96.1 and then it upgraded fine early yesterday to R184.108.40.2060. Last night it tried to update to R220.127.116.111 and failed, leaving me with a non-functioning client. Netskope refer to this as 'degraded' but the correct term would be unprotected.
I was able to reboot and reinstall 18.104.22.1681 from the command line.
Our confidence in Netskope code at the moment is at an all time low and we will be escalating.
I think the current issue with NS 96.1.1 https://support.netskope.com/hc/en-us/articles/8386682794775-Netskope-Windows-Client-Auto-update-to-... is different to this issue that we have raised in this thread.
Our issue is for every cloudupdate version a subset of cloud update causes clients to break though it installs the latest version. Netskope identifies it as degraded client where the client looks healthy but fails to connect.
Can anyone from Netskope please provide some light on this degraded client resolution status. Any tools, process or checklist that tier 2 support can follow to identify and resolve this issue. Thanks in advance.
I've commented to our support team that it would be a fantastic enhancement is there was a log in the device events indicating "Client upgrade to xx.yy.zz.www started". Can't recall offhand if that became an official FR or not though. Would at least give us as administrators something to look for when devices drop to an unprotected state because of a failed auto-upgrade.