How to manage IE Plugin updates for non-admin users Skip to main content
How satisfied are you with the Okta Help Center?
Thank you for your feedback!
How satisfied are you with the Okta Help Center?
Very Dissatisfied
Very satisfied
Enter content less than 200 characters.
Ask Search:
Darren SiegelDarren Siegel 

How to manage IE Plugin updates for non-admin users

We are new to Okta -- just now rolling out to our first pilot group.  We noticed yesterday that our users are seeing a message at the top of the Okta homepage in Internet Explorer: "Important: Install the new version of the Okta browser plugin."  Our users do not have the admin rights required on their workstations to install the new plugin.

Per Okta support the only way to disable this message is to set the global "IT manages Okta Plugin" option, but this unfortunately also disables the "Install Plugin" prompts in other browsers such as Chrome (where admin rights are not required), as well as if they access Okta from a personal machine at home.  They'll see a notification saying "plugin required" and none of their SWA apps will work, but there will be no instruction on how/where to get the required plugin.

Okta support has confirmed there is zero flexibility on this and suggested I post my question here instead:

How do organizations with non-admin users manage IE plugin upgrades so that users don't ever see the "Important!" new plugin notification that they can't do anything about, WITHOUT setting the global "IT manages Okta Plugin" option.
Raja NejemRaja Nejem (Okta, Inc.)

Typically, other organizations deploy the plugins via group policy or through a client management tool like Altiris or Landesk.  How do you currently deploy apps to those users now?  We would suggest using that process.

Also, using SAML or WS-Fed only enabled apps don't require browser plugins.

Darren SiegelDarren Siegel
We do deploy the plugin using a package management tool.  Part of the problem is we get little to no notice from Okta when a new plugin is being released (per Okta support we may only have a week or so to work with; not practical in any size organization).

Yes I'm aware SAML doesn't require the plugin.
Harry MeierHarry Meier
Ditto on this issue. The release notes method of notifying us that a new version of the plugin will hit GA within a week is too little notice to package and test and distribute a new plugin for a large organization. Plus the all-or-nothing approach of the "IT manages Okta Plugin" switch doesn't allow any flexibility. IT only manages the plugin on corporate workstations. Users need to also access Okta from home where they can install it themselves. 

Another issue is the "Important!" new plugin notification that users get when there is any diff between installed vs available plugin versions. It would be nice if users got a more friendly notice that didn't grey out their app buttons if there's no compatibility issues with their current plugin version. If users have a functioning plugin, just a .0.1 dot revision behind current then there shouldn't be a need to rush them into updating unless there's a critical vulnerability or major incompatibility. 
Jim O'ConnorJim O'Connor
I agree with both Darren and Harry. It's one thing to manage the plugin on corporate machines but what about users on non-IT managed computers? Are they supposed to google to find the plugin they need? This is very poor design and needs to be addressed by Okta.
Cesar MatiasCesar Matias
I'll post to bring this back to the top, but I am facing the same issue where its not a centralized environment. What would be the best approach if any beyond app managed apps. 
Jim O'ConnorJim O'Connor
What I ended up doing for non-IT managed computer users was creating a free one-drive account and putting all the various Okta browser plugins along with documentation on how to install for each browser into a folder and then created a bookmark app in Okta to the one-drive folder and making it available to all users in case they even need to install.