Continuing with Errors and Warnings, Causes and Solutions topic, let’s talk today about a classic (and annoying) one:
“Error 87 Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))
Error 88 at Microsoft.BizTalk.Gac.Fusion.IAssemblyCache.InstallAssembly(AssemblyCacheInstallFlag flags, String manifestFilePath, IntPtr referenceData)
at Microsoft.BizTalk.Gac.Gac.InstallAssembly(String assemblyPathname, Boolean force)
at Microsoft.BizTalk.Deployment.BizTalkAssembly.GacInstall(String assemblyLocation)
at Microsoft.BizTalk.Deployment.BizTalkAssembly.PrivateDeploy(String server, String database, String assemblyPathname, String applicationName)
at Microsoft.BizTalk.Deployment.BizTalkAssembly.Deploy(Boolean redeploy, String server, String database, String assemblyPathname, String group, String applicationName, ApplicationLog log)
Error 89 Unspecified exception: “
Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))”
Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))
Error 90 Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))
Error 91 Failed to add resource(s). Change requests failed for some resources. BizTalkAssemblyResourceManager failed to complete end type change request. Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))
Error 93 Assembly “<name of the assembley>, Version=1.0.0.0, Culture=neutral, PublicKeyToken=6d6ddb8f4f8e0e50” references the following assemblies that must be deployed before deploying this assembly:
Assembly “<name of the assembley>, Version=1.0.0.0, Culture=neutral, PublicKeyToken=6d6ddb8f4f8e0e50“
Error 94 Deploy operation failed.
“”
Assembly “<name of the assembley>, Version=1.0.0.0, Culture=neutral, PublicKeyToken=6d6ddb8f4f8e0e50” references the following assemblies that must be deployed before deploying this assembly:
Assembly “<name of the assembley>, Version=1.0.0.0, Culture=neutral, PublicKeyToken=6d6ddb8f4f8e0e50″”
while trying to deploy a BizTalk solution from Visual Studio.
This is actually very common in the recent versions of BizTalk Server, especially because some additional security settings are present in recent Windows Server versions.
📝 One-Minute Brief
This post explains how to resolve the 0x80070005 (E_ACCESSDENIED) error that occurs when deploying a BizTalk solution from Visual Studio, typically caused by missing permissions or incorrect user roles in BizTalk and SQL Server environments.
Causes
There are several possible causes for you to get access denied errors when deploying BizTalk solutions directly from Visual Studio. Here are some of the most common causes that you need to take into consideration and check for:
- You are not a local Administrator: make sure you have administrator rights on the BizTalk Server. This is required because BizTalk assemblies must be deployed to the GAC.
- You don’t have the right BizTalk privileges to deploy artifacts: Make sure the user account that is trying to deploy the Visual Studio BizTalk Solution is a member of:
- BizTalk Server Administrators group.
- And also, a member of the SSO Administrators or the SSO Affiliate Administrators group.
This is required because BizTalk artifacts need to be “registered” in BizTalk databases, and these memberships should grant you the required access to the databases.
- Visual Studio BizTalk Deployment properties are incorrect: Visual Studio uses the settings on the Deployment tab of each BizTalk project in the Visual Studio solution to correctly deploy the artifacts (DLLs). You should verify that your deployment configurations are correct by right-clicking the project in Visual Studio, selecting Properties, and then clicking the Deployment tab. The most important properties to check are the Configuration Database and Server; validate that they are what you expect them to be, and also check the Application Name property. Check more about Deployment Properties here: How to Set Deployment Properties in Visual Studio.
- You are not running Visual Studio as an administrator: If you have UAC enabled, or sometimes even disabled, there are additional security settings in recent Windows Server versions that, by default, prevent Visual Studio from running with elevated permissions. Again, this is required because BizTalk assemblies must be deployed to the GAC.
- Some process is locking the files: in some situations, some other processes, other Visual Studios or BizTalk Host Instances, may have a lock on the file(s) you are trying to replace, in these cases, stopping or restarting these services before deploying the solution should help.
Solutions
In the causes section, I already described the basic steps to solve this error based on the situation you are in, so I will not address all possible solutions in detail here. In my case, and I think that is the most common situation, was that, despite having disabled the UAC, I was running the Visual Studio without elevating permissions.
There are several ways to solve this problem (running Visual Studio with elevated permissions). The simple way, of course, is to:
- On the Start screen, type Visual Studio.
- Right-click under Visual Studio and choose the Run as administrator option.

The problem with this approach is that I need to remind myself to do it whenever I want to run Visual Studio. Otherwise, the next time it will fail again with the same error.
To resolve once and for all, you can opt for two approaches:
- Option one:
- Access to the devenv.exe file on the file system, for example: C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE.
- Right-click devenv.exe and select Troubleshoot compatibility.

- On the Select troubleshooting option page, select Troubleshoot compatibility.

- On the What problems do you notice? page, select the The program requires additional permissions option, and then click Next.

- On the Test compatibility settings for the program page, click Test the program…, wait for the program to launch, and then click Next.
- Select Yes, save these settings for this program.
- And then click Close.
- Back to the Visual Studio … Properties windows, click OK.
Hope you find this helpful! If you liked the content or found it useful and would like to support me in writing more, consider buying (or helping to buy) a Star Wars Lego set for my son.

