I have been in contact with Citrix and tried the fixes outlined in the links below, with none poviding mitigation to this issue.
Lookng for any additional advice or information that may help in fixing this issue.
After setting the registry value to '2af8', does it automatically revert to '2711' upon launching Outlook? Can you also provide the registry path you are using?
Additionally, can you please upgrade to current version and let me know if the issue persists? Current version can be downloaded here: https://www.citrix.com/downloads/sharefile/clients-and-plug-ins/citrix-files-for-outlook.html
Installing the newest version of the plugin and changing the registry key HKCU\Software\Policies\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BROWSER_EMULATION
HKEY\outlook.exe to 02af8 worked to correct the issue for User 1.
User 2 still gets the Browser Out of Date message when trying to sign in using the Sharefile plugin Button on her Outlook ribbon, but when she actually creates a new message, she has full functionality to send or request secured files. (Note: I also deleted the config file under %user%\AppData\Roaming\Sharefile for all users)
I have removed and reinstalled the newest version and deleted configs for Users 3 and 4 but I am waiting for them to return to their offices before we can edit their registry keys and test .
On User 2, the registry key did not change once Outlook was restarted.
Once set up, we had to reinstall the plugin yet again, but now Outlook does not see it at all. It does not appear as an add on under options despite running install four times. Further, both after the first reinstall and after the new profile, the registry key HKEY_CURRENT_USER\Software\Policies\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BROWSER_EMULATION does not exist. Key HKCU\Software\Cirtix\ShareFile\SSO does not exist. (They do not for users who have no issues either though).
What's worse, as of this morning, User 1, who we were able to fix by installing the latest version of the plugin, now gets the browser out of date message again.
If not, go to HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\ExperimentTas\outlook\Flights
and see if
exists, if it does, remove it and relaunch outlook
That is not the recommended action. There is no need to uninstall the add-in or recreate profiles. Those have nothing to do with the "browser out of date" error.
Please try setting the value as described in this article:
Specifically set the value in the key path containing "\Policies\" (step 4). Alternatively you can set the value in HKLM, but be sure to take the WOW6432NODE into account.
If the key does not exist, please create it. Let us know if that works.
I'm not sure what you mean when you say that the users do not have the policies key shown in step 4? Who doesn't have the key? The ones not experiencing the problem?
Can you please confirm a few things for me from the PCs where you're still experiencing the issue:
What version of Outlook? Is it Office 365?
Can you provide the full path of the registry key and value you set? Did you create the value as a DWORD? What integer value did you use?
Are you setting it in HKCU or HKLM? If on a 64 bit system, are you changing the value under "HKLM\Software\WOW6432NODE\Policies\..."?
If you set the value in the original key (below) to 0x2af8 and then start outlook, is it reset to 0x2711?
Basically I want to narrow down the issue. Setting the value in the "policies" key has worked on all the systems we've tested.
To answer your questions in order:
Upon initial installation of the Sharefile Plugin, none of my users have the registry key: HKEY_CURRENT_USER\Software\Policies\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BROWSER_EMULATION.
This key value does not exist for any of my users, whether they have the Out of Date message or not. I have manually created it for the effected users with the dword value “outlook.exe” set at 2af8. The remaining users who ARE NOT experiencing the issue DO NOT HAVE this registry key.
Version is Outlook 2016 Version 1809 (Build 10827.20181 Click-to-Run)
The full registry path is hkey_current_user\software\policies\microsoft\internet explorer\main\feature_browser_emulation\ dword: outlook.exe (value: 2af8)
I am setting the key value in HKCU. I have CREATED an outlook.exe dword value 2af8 under HKLM\Software\WOW6432NODE\Policies\... The value did not exist at all after installation. I had to create it manually in each case. I have checked other, unaffected PCs, and this value does not exist for them either.
Outlook does NOT change the value on either string at start up from 2af8 to 2711.
Again, it’s not a matter of simply setting these values, as the keys themselves do not exist on any of my machines whether the user can function normally or not. Further, the user who had been corrected by a simple plugin update had both strings manually created and again started getting the error message, but neither dword value was changed from 2fa8. As far as I can narrow down, it is something in the specific user profile, as someone else can log into these four machines and set up their outlook and sharfile and never see this error.
To simplify how I refer to the keys below:
"Non-policies" key ==>
"Policies" key ==>
Upon add-in installation, the PC probably will not have the "policies" registry key. It is not created as part of add-in installation. It is purely a work around that must be set manually. If the key does not exist it must be created.
I understand that the keys do not exist on the affected machines. This is expected. They must be manually created. That's what the article describes. The add-in installer does not create the "policies" key. It does however create the "non-policies" key and sets the outlook.exe=2af8 value there. But that value is overwritten by Outlook in new versions of Outlook 365.
Note: the same applies to the SSO key. It is not created by the installer and won't exist after installation. You need to manually create it.
The instructions for setting the "policies" key only applies to Office 365 as far as we can tell.
For users on non-office365 outlook, this will not need to be done. The registry value that the add-in installer DOES set should be sufficient:
For a little history: Previous to a Microsoft Office 365 update, the outlook.exe=2af8 value was required to be set in the "non-policies" key to address the browser out of date error. The add-in installer sets that value automatically.
About two months ago, Microsoft pushed an update to Outlook 365 which causes Outlook to overwrite this value every time it starts. This renders the value set by the installer in the "non-policies" key useless and causes the browser out of date error to be shown.
As a work around to this, we can set a value in the "policies" key. Outlook will prefer this value, if it is set, and ignore the old ("non-policies" key) value.
There is no support for creating the "policies" key or setting the outlook.exe value in the add-in installer and there will be none going forward because of technical limitations.
So bottom line - If you're running Outlook 365, and you're seeing the browser out of date error, you must create the "policies" key, if it doesn't exist, and set the DWORD value outlook.exe=2af8.
Hope this helps.
Why does it affect some users and not others? Note we are experiencing this on computers with identical builds as users who are not experiencing this issue.
So to reiterate Josh's statement...
"This key value does not exist for any of my users, whether they have the Out of Date message or not. I have manually created it for the effected users with the dword value “outlook.exe” set at 2af8. The remaining users who ARE NOT experiencing the issue DO NOT HAVE this registry key. "
My question is why does this "fix it" even though users who don't have this are NOT experiencing the issue?
In case you hadn't seen, we released Citrix Files for Outlook v6.2 yesterday.
We did our best to help with the Browser Out of Date issue with this release and will continue to look at ways to improve it in future releases.
We recommend updating to the latest version and continuing to use the Policies entries in the Registry discussed above.