Impact of using ForceShellExecute=1 in Office 2007, 2010 and 2013

For different reasons (such as this), your company may find that it has a need of changing the way that Office opens links, and force Office to use the Windows way of opening links. To achieve this, you will use this registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\9.0\Common\Internet
and a Reg_Dword called ForceShellExecute with value 1
(N.B. this key refers to 9.0 for all versions of Office)

This will make Office use Windows way of linking instead of Office way of linking. So it will basically be the same as if the user opened the link by Start – Run – Paste the link – Enter. The below article summarizes and discusses the known behavior changes and problems you may see when setting this key, so that you can make a meaningful decision about if you should use it or not.

Difference 1: Files opened from Office will open in separate instances
With ForceShellExecute=1 set, the links you click will open in separate Office instances in the Task Manager. And when you are working with 2 Office files in separate instances, some limitations apply. Here is an example of such a limitation: You cannot paste any attributes into a workbook in another instance of Excel.
Another issue could be that some add-ins may not be constructed for the scenario that 2 Excel/Word/PPT files are running in separate instances. You will need to check with the developers of the add-ins that you use if they will be impacted by this.

Difference 2: A linked workbook does not open when you click a hyperlink in an Excel 2010 workbook
This is documented in https://support.microsoft.com/kb/2597992. If you make sure you install updates from Microsoft Update, you will not need to take any action on this one.

Difference 3: A second presentation does not start until the original presentation is finished in PowerPoint
This is documented in https://support.microsoft.com/kb/916776. As seen there, you will need to set another (low impact) registry key to solve this one.

Difference 4: A warning message will come up when opening files from within Office
You may find that you get the following warning after setting this key:
Some files can contain viruses or otherwise be harmful to your computer. It is important to be certain that this file is from a trustworthy source. Would you like to open this file?
You can disable this by following this article.
(You may however want to make the changes in“HKEY_LOCAL_MACHINE\Software\Classes” instead of“HKEY_CLASSES_ROOT”in order to avoid this.)

Difference 5: Links to Excel open without going to the right sheet, and links to Word open without going to the right bookmark
After setting this key, you may find that Excel links open without switching to the requested sheet, and that Word files open without scrolling to the requested bookmark. The reason is that Windows linking, which this key enforces, does not support linking to bookmarks. This can be considered the major tradeoff of using this registry key.

Security impact of using this key:
Unless there is a security problem in your environment with opening files from Start – Run, using this key should not have any security impact.

Supportability impact of using this key:
ForceShellExecute=1 is documented in a KB and is therefore considered a supported registry key, and as clearly can be seen in the links above, there have been an amount of fixes released in the past to ensure that it keeps working.

Summary:
Hopefully the above gave you an overview of the impact that usage of this key will have on your organization, from a technical, compatibility, security and supportability point of view. As seen above, not using the key will save you from some trouble, but most of this trouble already has a solution if you run an updated version of Office. Difference 5 will be your main tradeoff, and Difference 1 will be the one whose impact will vary greatly depending on your environment.

Comments

• Anonymous
  January 01, 2003
  Thanks!
• Anonymous
  January 01, 2003
  Hi Yunus,
  
  Putting the key in anything but 9.0 will not have any effect. If 9.0 does not exist, it must be created. The best way of ensuring that it is read is to use ProcessMonitor.
• Anonymous
  January 01, 2003
  Hi Sergei,
  
  This may be relevant: http://msdn.microsoft.com/en-us/library/windows/desktop/ms724072(v=vs.85).aspx
  I would suggest checking with ProcessMonitor, to check exactly where it expects this registry key to be.
  
  For further support, I would recommend our forum or opening a support case.
  
  Kind Regards Erik
• Anonymous
  January 01, 2003
  Hi Doug,
  Did you see the linked http://support2.microsoft.com/kb/905248/en-us ? It suggests you should make the change in HKLM instead. Anyway, a 2nd possitibility is likely going to be to make changes to that web page or web application in order to not need the registry key. I understand this might not always be feasible. In theory, a VBA "parser" workaround to convert the links into opening the right thing could likely be another possibility.
• Anonymous
  January 01, 2003
  Hi Yunus,
  
  Great to hear. See e.g. http://support.microsoft.com/kb/932118, and the section about logon-page redirections. As you can see, logon-page redirections are not unheard of. If this does not help, I suggest opening a support case, because there are many possibilities. IE and Office update level and versions are some possibilities, as well as settings and 3rd party applications.
  
  Kind Regards, Erik
• Anonymous
  January 01, 2003
  Hi again Doug. To set your expectations right, I am not aware of any other workarounds for that.
• Anonymous
  April 08, 2014
  The comment has been removed
• Anonymous
  April 09, 2014
  Hi Frank
  I hope I understood you right. As I understand it, http://support.microsoft.com/kb/2597992 describes an issue that comes up when you -already have- set this registry key. Because this registry key is listed both in Symptoms, -and- Resolution, in that article you linked to.
• Anonymous
  April 10, 2014
  Ciao Erik
  
  Thank you for you answer.
  
  We have an issue: When a user open a hyperlink from office 2010 its works only the first time. it means, when the user try it again to open the same or another hyperlink in the same file, it doesn't work.
  
  We can fix the Symptom whit this workaround http://support.microsoft.com/kb/2597992, it means setting this reg key 32-Bit: HKEY_LOCAL_MACHINESOFTWAREMicrosoftOffice9.0CommonInternet
  
  My problem is, i don't know if I should roll out this fix / reg key for all clients (4000)?
  
  I hope it is clearly for you now?
  
  Best regards
  Frank
• Anonymous
  April 10, 2014
  Ciao Erik
  
  Thank you for you answer.
  
  We have an issue: When a user open a hyperlink from office 2010 its works only the first time. it means, when the user try it again to open the same or another hyperlink in the same file, it doesn't work.
  
  We can fix the Symptom whit this workaround http://support.microsoft.com/kb/2597992, it means setting this reg key 32-Bit: HKEY_LOCAL_MACHINESOFTWAREMicrosoftOffice9.0CommonInternet
  
  My problem is, i don't know if I should roll out this fix / reg key for all clients (4000)?
  
  I hope it is clearly for you now?
  
  Best regards
  Frank
• Anonymous
  April 14, 2014
  Hi Frank,
  This article lists some known considerations and behavior changes that will occur when you set this key. After you have taken each point in this article into account, you should have an overview of what it changes, and be able to make a more justified decision whether or not to use it in your environment.
• Anonymous
  July 25, 2014
  Hi Frank,
  
  Before I had Office 2013 x64 and this fix helped.
  Now I migrated to Office 2013 x86 (uninstall x64 and install x86).
  After that I apply this fix, but link doesn't work corretly yet (fix not help).
  What will I do?
  
  Thank you
  
• Anonymous
  July 25, 2014
  Oh, sorry, not Frank. I meant Eric - the author.
• Anonymous
  October 03, 2014
  We are considering an enterprise deployment of this reg update to address an issue opening a web page. My major concern is that testing with this key shows that Difference #4 is going to be a bear to deal with. It seems like the hyperlink warning only applies to Office files, but there are a LOT of possible Office file types that could be linked to. The group policy preference item we're building to suppress this via HKCR is looking pretty awful. Is there really no way to prevent ForceShellExecute from being required to resolve the web page opening issue?
  
  Thanks
• Anonymous
  December 10, 2014
  Thanks Erik. It's been over a month since we implemented ForceShellExecute across the enterprise. So far, things have been mostly quiet. However, something new and unexpected has developed and wondering if you had any thoughts on how to address it before I open a case with Microsoft. As you noted in difference 4, there's a security warning that appears when opening links to Office files from other Office files. The suggested fix described in the KB article you linked to ONLY works if you apply changes to the EditFlags value, which we've also deployed to the enterprise. The DisableHyperlinkWarning reg update in all of its iterations doesn't seem to do anything to suppress the warning. The really bad thing about the EditFlags fix is that there's no mention of how that changes other behavior. Specifically, when opening files from certain web pages there is no longer a prompt to open/save/saveas. This is obviously a problem for users who have business processes that rely on being able to save a file instead of opening it immediately, which is what is happening. Do you know if there's a way to truly prevent the hyperlink warning without altering EditFlags?
• Anonymous
  December 31, 2014
  
  Hi Erik,
  
  I've tried the suggested ForceShellExecute solution, but it didn't help me to browse an already authenticated webpage from an Excel Hyperlink. If you can assist me with any other possible solutions, I will greatly appreciate your help.
  
  Here are the details of my problem:
  
  1) A link from an excel file, that requires authentication, fails to show the web page, but rather goes to the login page.
  
  2) Observing the web traffic shows that the authentication cookie is missing in the request header (used Fiddler)
  
  3) The exact same link works perfectly from an email or from the Start-Run (as explained above) on the same computer.
  
  4) The problem does happen only on certain computers in our network. They are workstations which successfully opens the link from the excel. There is no ForceShellExecute value on those computers' registry.
  
  5) The problem happens on both 32-bit and 64-bit Excel installed machines (Excel 2010)
  
  6) There is no registry key on my machine as "HKEY_LOCAL_MACHINESOFTWAREMicrosoftOffice9.0". I've seen some people suggested to use similar keys as yours (probably based on the version). Since I am not much familiar with the registry keys & versions, I found the following similar keys in my registry and in all of them I've created the ForceShellExecute DWORD value and then rebooted my machine. Still the link doesn't work.
  
  HKEY_LOCAL_MACHINESOFTWAREMicrosoftOffice11.0CommonInternetForceShellExecute
  HKEY_LOCAL_MACHINESOFTWAREMicrosoftOffice14.0CommonInternetForceShellExecute
  HKEY_LOCAL_MACHINESOFTWAREMicrosoftOffice8.0CommonInternetForceShellExecute
  HKEY_LOCAL_MACHINESOFTWAREMicrosoftOfficeCommonInternetForceShellExecute
  
  HKEY_LOCAL_MACHINESOFTWAREWow6432NodeMicrosoftOffice11.0CommonInternetForceShellExecute
  HKEY_LOCAL_MACHINESOFTWAREWow6432NodeMicrosoftOffice12.0CommonInternetForceShellExecute
  HKEY_LOCAL_MACHINESOFTWAREWow6432NodeMicrosoftOffice14.0CommonInternetForceShellExecute
  HKEY_LOCAL_MACHINESOFTWAREWow6432NodeMicrosoftOfficeCommonInternetForceShellExecute
  
  HKEY_CURRENT_USERSoftwareMicrosoftOffice12.0CommonInternetForceShellExecute
  HKEY_CURRENT_USERSoftwareMicrosoftOffice14.0CommonInternetForceShellExecute
  HKEY_CURRENT_USERSoftwareMicrosoftOffice8.0CommonInternetForceShellExecute
  HKEY_CURRENT_USERSoftwareMicrosoftOffice9.0CommonInternetForceShellExecute
  HKEY_CURRENT_USERSoftwareMicrosoftOfficeCommonInternetForceShellExecute
  
  Best,
  
  Yunus.
• Anonymous
  January 02, 2015
  
  Erik,
  
  Creating the exact key HKEY_LOCAL_MACHINESOFTWAREMicrosoftOffice9.0CommonInternetForceShellExecute with the DWORD value 1 worked. I removed the unnecessary keys I created as well. Thanks a lot for your help.
  
  At this point, I am still wondering one thing: How come some of the other machines in our network open the hyper links from excel successfully which require authentication cookie, even though they don't have this key in their registry.
  
  Yunus
• Anonymous
  December 18, 2015
  I've been using this trick for years, to prevent the "very slow" loading of links from within Office (especially when on a slow internet connection), as Office seems to verify the destination of a link before allowing it to be visited. I've used it on Windows 7 & Windows 8. However, just setting up my first Windows 10 PC, it no longer seems to work.
  
  Can you confirm? If so, is there another workaround?
• Anonymous
  December 25, 2015
  Sorry, I don't recognize the slowness issue, nor why that would work in the first place.