Office Interop Access is denied fix for .NET automation of Microsoft Office

Problem, Could not load file or assembly … or one of its dependencies. Access is denied

This is the solution to a perplexing issue around Office automation, that many people do not seem to be finding a solution for on forums.

The story, on a newly deployed set of PCs, a big issue arose where the Microsoft Office Interop for our .NET application would fail with errors of “Access is denied” when launching our integrating application. Solutions that were attempted proved only to be a temporary fix, with the problem reverting back again, often overnight.

Could not load file or assembly Microsoft.Office.Interop.Excel.dll or one of its dependencies. Access is denied.

Could not load file or assembly Microsoft.Office.Interop.Outlook.dll or one of its dependencies. Access is denied.

It turns out this is to do with permissions to the Interop assemblies that are put in the Global Assembly Cache (GAC) and the Centennial version of the Office App.

 

Solutions attempted

 

In an attempt to resolve the issue, the usual culprits were investigated including many more ideas that I’ve now forgotten about:

  • Changing the permissions within the COM, component services control panel for the access, launch and activation permissions etc
  • Taking control of the assembly cache permissions and granting access for directories and files including…
    "C:\Windows\assembly\GAC_MSIL\Microsoft.Office.Interop.Outlook\15.0.0.0__71e9bce111e9429c\Microsoft.Office.Interop.Outlook.dll"
    "C:\Windows\assembly\GAC_MSIL\Microsoft.Office.Interop.Excel\15.0.0.0__71e9bce111e9429c\Microsoft.Office.Interop.Excel.dll"
    "C:\Windows\assembly\GAC_MSIL\Microsoft.Office.Interop.Word\15.0.0.0__71e9bce111e9429c\Microsoft.Office.Interop.Word.dll"
  • Uninstalling restarting, reinstalling Office
  • Uninstalling restarting, installing the Office interop via the Office installer options
  • Removing and replacing the local Office interop assemblies for the integrating application
  • Embedding the Interops in the application (difficult with Nuget packages tho?)
  • Using cacls.exe to update DCAL

Some of the above would work for the rest of that day, fixing the issue,  yet the problem would return the next morning (machines left on overnight).

 

Root cause

Finally, a hint of the issue was found from digging deeper and deeper in the forums, revealing the root cause.

“Office in the Windows Store” was released which is a different version of Office that is available through the windows store in Windows 10. This version of office is often referred to as Office Centennial version, as it utilises Project Centennial to allow office to be ported to an Office store app. Project Centennial is a bridging solution intended to make it easier for software developers to migrate existing applications to the store and app architecture in windows. This bridge was used to create the version of office in the store, which is distinct from the standard Office you would install from other media sources.

This store version of Office has been included in the Windows system image used by some OEM manufacturers of PCs, so new users have it ready to go on the machine when they get it to the Office or home. Being a store app, it gets refreshed by the auto updates of the Windows store… you can see where this is going?…

It would seem that this version of Centennial Office was installed on the disk image of these PCs and when full Office professional was installed on the machine, all is fine, until the (not in use) Centennial version of Office decides to repair itself overnight during the store update, corrupting the permissions on the Interop assemblies in the GAC, leaving them with only SYSTEM permissions, thus rendering them inaccessible to the end users.

Doing many of the aforementioned attempts to fix the issue, would overlay the correct permissions, but only until the Centennial version of Office went and undid the work overnight.

What is more annoying is that early on in the diagnostics for this issue I had a suspicion around this being the issue, but found no installer under, Start>>Apps and Features for  Microsoft Office Desktop Apps or Office, other than the pro copy. Also nothing in the programs and apps. Hence I’d assumed it can’t be the issue, wrongly as it turns out.

This seems to be an issue that has been hitting people from early 2019 through to 2020 when this blog post was written, although the OEMs were asked not the include the version of Office in the images anymore, so this should fade away over time.

It is a bit concerning that few people in forums seem to have found solutions, other than rebuilding the machine, but pushing on…

 

Removing Centennial Office

It seemed the obvious solution was to remove the store version of Office. It was not required and thus removing it should stop it overwriting the good install of Office. As noted before, there seemed to be no “uninstall” option anywhere in windows to get rid of the application. There were a few ways to remove this Office listed on internet forums, but the only one that worked for me was to launch power shell as an admin user. Then to run the following three commands, each in turn.

"(Get-AppxPackage -Name Microsoft.Office.Desktop).Dependencies | Remove-AppxPackage"
"Get-AppxPackage -Name Microsoft.Office.Desktop | Remove-AppxPackage"
"(Get-AppxPackage -Name Microsoft.Office.Desktop).Dependencies"

The final command should just confirm removal, by not returning anything.

Immediately it could be seen the assemblies had been removed from the “C:\Windows\assembly\GAC_MSIL\*” directories and after running the afflicted application, the issue would seem to be resolved. The professional office install was also repaired, via the Office Pro installer, for good measure.

A very annoying, obscure problem finally resolved!

 

References:

How do I uninstall Office 365 Windows Store version?

how to uninstall office 365 preloaded in windows 10

Why ‘Office in the Windows Store’ isn’t really Microsoft Office

Office.dll access denied to VSTO add-in

.NET 4.6.1 or 4.6.2 seem to break IsInRole()

Upgraded application using IsInRole(), now only returns false (vb.net)

Read to the end before making code changes as there is a more obvious thing to check!
 
To support TLS1.2 for PCI requirements I was upgrading one of the applications to 4.6.1, after deployment behaviour controlled by our active directory groups was broken. It was like no one was a member of any AD groups anymore. First I thought it must be a coincidental screw up by someone in AD. It turns out it was something else…
 
The following code is used to check against a list of security groups to see if the current user belongs to any of them.
 
Public Shared Function IsInAdSecurityRole(RoleName() As String) As Boolean
Dim aName As String = Principal.WindowsIdentity.GetCurrent.Name
Dim aDomain As String = aName.Substring(0, aName.IndexOf("\") + 1)
AppDomain.CurrentDomain.SetPrincipalPolicy(
Principal.PrincipalPolicy.WindowsPrincipal)
For index = 0 To RoleName.Count - 1
If Thread.CurrentPrincipal.IsInRole(aDomain & RoleName(index)) Then
Return True
End If
Next
Return False
End Function

The code is ancient, has been in our applications for a very long time but on upgrading to .NET framework 4.6.1 it returns false for all roles. Checked casing and ran in debug inspection and yet failed to see why it stopped behaving as it always had before.
 
Unable to figure out what had happened and with a need to get systems running again I imported the namespace System.Security.Principal
then using the following method all seems well again.
 
Public Shared Function IsInAdSecurityRole(RoleName() As String) As Boolean
Dim currPrincipal As New WindowsPrincipal(New WindowsIdentity(Environment.UserName))
For index = 0 To RoleName.Count - 1
If currPrincipal.IsInRole(RoleName(index)) Then
Return True
End If
Next
Return False
End Function

I used this reference:

My.User.IsInRole() is not working after migrating to 4.6.2 framework in vb.net

 

Authentication mode in project settings Application-defined vs Windows

VB.NET has a setting in the project to say you wish to use application provided authentication method or use the default windows one. This was something that I had totally forgotten existed. It looks like the Authentication mode of the project got changed during the migration. Check the properties of the project, Authentication mode, see if changing it from Application-defined to Windows helps, it did in my case, bringing behaviour back to that which is expected.

 

2018-06-14_12-14-50

Change the drop down combo box to “Windows”

2018-06-14_12-23-38

 

Reference: https://social.msdn.microsoft.com/Forums/en-US/d00b65dd-61d8-4368-b2d2-eaedfc66af40/myusername-is-now-returning-empty-string?forum=vbgeneral

WCF Registered base address schemes are []

Moved WCF service from old server to 2012 server to find the WCF service would not run. It complained that

"Could not find a base address that matches scheme http for the endpoint with binding WebHttpBinding. Registered base address schemes are []"

Stack overflow post below was the lead as to how to resolve it:

WCF Registered base address schemes are [] error with https

With a fake IP address for purposes of this post, the WCF config section had the follow lines, removing the <add prefix… line from the .config brought the service to life.

<baseAddressPrefixFilters>
<add prefix="http://127.0.0.1/DataService/"/>
</baseAddressPrefixFilters>
 
So what is the baseAddressPrefix? –it is for dealing with where there are multiple IIS bindings for a site providing a listening filter for the service.

To quote MS documents:

“A prefix filter provides a way for shared hosting providers to specify which URIs are to be used by the service. It enables shared hosts to host multiple applications with different base addresses for the same scheme on the same site.+

IIS Web sites are containers for virtual applications which contain virtual directories. The application in a site can be accessed through one or more IIS bindings. IIS bindings provide two pieces of information: binding protocol and binding information. Binding protocol (for example, HTTP) defines the scheme over which communication occurs, and binding information (for example, IP Address, Port, Hostheader) contains data used to access the site.

IIS supports specifying multiple IIS bindings for each site, which results in multiple base addresses for each scheme. Because a WCF service hosted under a site allows binding to only one base address for each scheme, you can use the prefix filter feature to pick the required base address of the hosted service. The incoming base addresses, supplied by IIS, are filtered based on the optional prefix list filter.”

TF400409 you do not have licensing right to access this feature

Setting up a new user for team foundation server, although user has been added to all the licencing groups and project groups, they cannot expand the root node of the team collection. They can also not access the portal security pages as it gives the above error.

Turned out to be that they needed the access level for the user setting.

This is outlined within the document here: https://docs.microsoft.com/en-gb/vsts/security/change-access-levels

 

You may follow this route to the access level admin (in the version we use)

Select Security from the Team Explorer Settings menu from Visual Studio

2018-01-26_10-42-17

Navigate to the root of the control panel

2018-01-26_10-44-00

Navigate to the Access Levels tab

2018-01-26_10-46-10

 

Put the user under the appropriate access level of Basic or Advanced. This should then allow them to access the web portal without error and expand the source control collection node to see the individual projects (assuming you’ve set them up correctly with those too).