I have a problem when I published web application in IIS
sometimes the WorkBook.SaveAs method works fine, sometimes not.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.Runtime.InteropServices.COMException: The remote procedure call failed. (Exception from HRESULT: 0x800706BE)
Source Error:
workbook.Saved = True
workbook.SaveAs(Server.MapPath("~/MyFolder/Excel.xlsx"))
workbook.Close()
APP.Quit()
and sometimes the error is on APP.Quit
Well the first thing to note, is that office interop is not supported server side by Microsoft, due to both licensing and stability/reliability issues:
Microsoft does not currently recommend, and does not support,
Automation of Microsoft Office applications from any unattended,
non-interactive client application or component (including ASP,
ASP.NET, DCOM, and NT Services), because Office may exhibit unstable
behavior and/or deadlock when Office is run in this environment.
Still, many people do this/try to do this, and run into similar problems as you did. Generally this appears to be caused by permission issues (security context and the DCOM security configuration). For which different potential solutions have been described, such as
How to make IIS7 play nice with Office Interop With a 2 different solutions, one of which is mentioned several times elsewhere:
Open Windows Explorer
Depending on whether you installed a 32bit or
64bit version of office you will need to do one (or both) of the
following:
32bit Office installation: Navigate to
C:\Windows\System32\config\systemprofile
64bit Office installation:
Navigate to C:\Windows\SysWOW64\config\systemprofile
Verify the folder
"Desktop" exists (create it if it's not there)
Right click > Properties
On the security tab: Add the account under which the site
is running (eg: Network Service) with default permissions (Read &
execute; List folder contents; Read)
RPC failure opening an excel document. Listing the following solution:
Type Dcomcnfg.exe in Run which opens the dcomconfig utility.
In the dcomconfig utility,
go to Component Services --> Computers --> My Computer --> DCom Config
--> Microsoft Excel Application (and Powerpoint)
Right click it and go to properties. Go to security tab. Under
Security
1) Launch & Activation Permissions --> Choose customise and click
Edit. Add User Network Service and check everything under Allow for
it.
2) Do the same for Access Permissions and Configuration Permissions.
Then click Apply and close everything.
Another one using Windows Server 2003, with a different solution
It turns out that there was some kind of permission that the COM
Object needed. Setting the AppPool (for the site) on the Win2003
server to "SYSTEM" fixed the problem. For some reasion (by Default)
the ASPNET account has permission to whatever the COM object was
trying to access.
Perhaps one of these solutions will work for you.
The reason it sometimes works for you and not other times, may be related to the contents of the specific excel file, e.g. whether it contains any VBA scripts or references any (specific) modules. So that is something you should look into.
Related
I have an Asp.net application that handles the function of creating a directory and then viewing that directory (on the network).
Dim di As DirectoryInfo = New DirectoryInfo (Me.lblPath.Text)
di.Create()
Process.Start(Me.lblPath.Text)
Both creating and viewing the directory work perfectly from Visual Studio... but when I run the compiled asp.net application it shows me "access denied" in both cases.
[Win32Exception (0x80004005): Access denied]
The folder where the subdirectories are created is on the network and is shared for everyone.
Please help!
Actually, if you check, the folder probably was created. It really depends on the user you using to run the application pool.
However, then 2nd part?
Process.Start(Me.lblPath.Text)
That is not allowed anymore. Server running process (such as IIS) are in general not allowed to shell launch system apps.
So, you can get your code to create the folders. But, IIS is a service, and such running services as a general rule can't start (shell) execute things like windows explorer in this case.
You might try giving the application pool user rights to do this, but from what I can tell, by default, running IIS services, that service can't start such programs.
You can CERTAINLY do this on your development computer, since you running VS, and it runs + launches IIS express as a context as you the super user and owner of that computer.
but, on a real server, running IIS? Nope, in general this is not allowed. Quite sure this hole was plugged around 2008. In think in server 2012, you COULD set security to make this work (I believe some kind of rights to a console_0 user.
but, after 2012, even that option was removed.
So, such code? Yes, it will work during deployment on your development computer. but a server system, running IIS is locked down, and to my knowledge, you can't execute or run such processes.
Put in a try/catch, and send the error out to a extra text box on that page - you see the web does generate a error.
Message reads: System.Runtime.InteropServices.COMException: Exception from HRESULT: 0x800A9D9F
Environment: Access 2016, Windows 10, IIS 10.0; ASP.NET 4.7, URL http://127.0.0.1/openAccess3.aspx. The code is in an ASP.NET file on an ISS web server. No internet involvement. Browser and ISS are both on my desktop. Here is the code in question:
Dim oAccessApp
oAccessApp = createObject("Access.Application")
oAccessApp.OpenCurrentDatabase "C:\inetpub\wwwroot\WPE_Dev\WPE_Support.accdb")
oAccessApp.Run("ReadJSON")
oAccessApp.Quit
If I comment out oAccessApp.Run("ReadJSON"). Access opens and closes just as you would expect.
In the Access Trust Center I set Macro Settings to “Enable all macros (not recommended; potentially dangerous code can run)" That didn't help.
In IIS I set the Process Model Identity to an admin account. The code now runs. It is possible that another tweak i made also helped, but this change is what got it to run.
I solved this issue (not from ASP but from a NET executable) by allowing Trusted Locations on my network.
On Access:
File->Options->Trust Center->Trust Center Settings->Trusted Locations
Activate Allow Trusted Locations on my network or perhaps add a new location (didn't tried)
Add, remove, or change a trusted location
Don't do this, it's not officially supported (highlighting by me):
Microsoft does not currently recommend, and does not support, Automation of Microsoft Office applications from any unattended, non-interactive client application or component (including ASP, ASP.NET, DCOM, and NT Services), because Office may exhibit unstable behavior and/or deadlock when Office is run in this environment.
Source: MS KB 257757.
Thus, the "correct" solution would be to migrate your ReadJSON code to classic ASP (VBScript) or, better, ASP.NET (C# or VB.NET) and run it outside an MS Access container.
(I am aware that this is a potentially costly solution and that workarounds, even if officially unsupported, might be worth the risk. You just need to be aware that what you are doing is officially unsupported and might stop working at any time.)
I have an old application that uses Microsoft Word automation in asp.net and I need to install it on a Windows Server 2012 R2 x64 with Office 2013 Standard x86. I know that Office automation in server technologies like IIS should be avoided but I don't have the green light to rewrite the application at the moment, so I have to take it as-is.
Initially I started the application and it gave this error:
Retrieving the COM class factory for component with CLSID {000209FF-0000-0000-C000-000000000046} failed due to the following error: 80070005 Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED)).
I found some information online that {000209FF-0000-0000-C000-000000000046} is the identifier of generic Word, no specific version.
I went to Component Services -> My Computer -> DCOM Config -> Microsoft Word 97 - 2003 Document (note that there is no node for Microsoft Word or MS Word or Word while there is one for Microsoft Excel) and changed the security to allow the IIS AppPool user "Local Launch", "Local Activation" and "Local Access". This makes the application take some time to respond (more than a minute) and fail with the following error:
Retrieving the COM class factory for component with CLSID {000209FF-0000-0000-C000-000000000046} failed due to the following error: 80080005 Server execution failed (Exception from HRESULT: 0x80080005 (CO_E_SERVER_EXEC_FAILURE)).
At the same time the event viewer System log shows:
The server {000209FF-0000-0000-C000-000000000046} did not register with DCOM within the required timeout.
I searched online and found some information that access rights might not be OK, including system drive paths and registry. I ran Process Monitor and checked what the process is trying to open. I gave the IIS AppPool user full access to the following:
C:\Windows\SysWOW64\config\systemprofile
C:\Windows\Temp
HKU.DEFAULT\Software\Microsoft\Office
HKLM\Software\Wow6432Node\Microsoft\Office
HKLM\Software\Wow6432Node\Microsoft\Shared Tools
When I ran the application again it only showed a few access problems in Process Monitor which seem to be just attempts to read different configurations. The application itself did not show any kind of error any more, it just freezed. I don't have Visual Studio installed on that machine, but I don't see any errors in the application logs, so no exceptions were thrown.
I tried also setting a specific user (local administrator) in the DCOM Identity but there was no change.
Now I restored all permissions and I am back to the 0x80080005 error because it at least gives me some information to try to go with.
I succeeded to reproduce the error in a simple application with this code:
try
{
l1.Text = System.Security.Principal.WindowsIdentity.GetCurrent().Name;
var application = new Microsoft.Office.Interop.Word.Application();
l2.Text = "OK";
}
catch (Exception ex)
{
this.Label2.Text = ex.ToString().Replace("\r\n", "<br/>");
}
It fails also on Windows 8 x64 with Office 2013 Pro x64, with exactly the same error.
If I impersonate the current user to be an administrator, then it works. However even adding IIS APPPOOL\DefaultAppPool to the administrators group, it still fails.
Any ideas on the next steps?
So this is what worked at the end:
Create an admin user and set Word to run with it in the DCOM settings
In the settings give activation, launch and access permissions to the AppPool user as well as IIS_IURS and IUSR. Note that if you don't give the rights for the others, only to the AppPool user, Windows will still report that the AppPool user does not have sufficient privileges which is totally misleading
I also figured out what the problem with the freezing Word was: creating the new file was causing Word to open in the special mode where it tells you that the file might be dangerous. Of course using COM you don't see the problem but it would then not be able to continue until you allow it. This is a new behavior in Word 2013 and that's why I didn't have it before.
I had the exact same error with legacy code using Office Interop on Windows Server 2016 with Office 2013 and it drove me mad. So first I want to join those who already mentioned that the best practice would be to not use it and rewrite your code to DocX or similar if you have any chance. It just has too many traps that eat up time.
I followed all hints of Vladimirs post but still got the error. After all it was the doc file templates of the project Office failed to open in Interop mode (but which opened without any problem in the RD session on the server). They were created in an older Office Version. I opened/saved the templates in Word once and everything worked fine.
The Background (skip to the bottom if you want the question)
Recently I upgraded an SVN repository (hosted on assembla) to SVN 1.7. After doing so, we started to intermittently encounter lots of File Access Denied errors on the ASP.NET site pages that sit in the local working copy of the repository.
Some folders also started to get weird file permissions (they became marked read-only) and user sharing got removed from them. These problems would only start occurring after an update/commit cycle, via AnkhSVN's Visual Studio plugin, but not all the time; it seemed highly temperamental.
The only temp-fix we've found so far is to commit any outstanding changes, delete the local copy and re-checkout a full working copy (with TortoiseSVN). However, that is not a viable fix, and it is seriously impacting on productivity.
This site is an Azure based ASP.NET WebWorkerRole. It has never given problems before the upgrade to SVN 1.7. I tried fiddling with the internal IIS permissions to get around the problem, however, no dice.
My Environment
Visual Studio 2010 Ultimate 10.0.40219.1 SP1
AnkhSVN 2.3.10509 (latest version, supports SVN 1.7.1)
TortoiseSVN 1.7.1, Build 22161 - 64 Bit
Running in Debug Mode via the Azure emulator environment
The Question
Is it possible for SVN 1.7 or any of the tools in my environment to break file permissions so that the files become unusable in an ASP.NET site? and more importantly, how do I fix this?
The exact file permission error dumped out is this:
Access to the path '//file//' is denied.
Description: An unhandled exception occurred during the execution of
the current web request. Please review the stack trace for more
information about the error and where it originated in the code.
Exception Details: System.UnauthorizedAccessException: Access to the
path '//file//' is denied.
ASP.NET is not authorized to access the requested resource. Consider
granting access rights to the resource to the ASP.NET request
identity. ASP.NET has a base process identity (typically
{MACHINE}\ASPNET on IIS 5 or Network Service on IIS 6 and IIS 7, and
the configured application pool identity on IIS 7.5) that is used if
the application is not impersonating. If the application is
impersonating via , the identity will be
the anonymous user (typically IUSR_MACHINENAME) or the authenticated
request user.
To grant ASP.NET access to a file, right-click the file in Explorer,
choose "Properties" and select the Security tab. Click "Add" to add
the appropriate user or group. Highlight the ASP.NET account, and
check the boxes for the desired access.
But a clean working copy will not generate this error. Comparing the permissions of the two, it seems the working copies that are not bugged are shared (with IUSR and the local account), whereas the broken ones have zero sharing, yet the sharing is never changed by the user.
When subversion updates a file it first creates a temporary version in .svn/tmp/. It then moves the file into the right location. (This to avoid corruptions)
In 1.6 it did this for every directory by itself, but in 1.7 there is just a .svn in the top level directory of your working copy.
If somehow the filesystem permissions of this .svn directory are restricted, it is possible that the restrictions are copied with the file when it is moved in place.
(Subversion doesn't change the permissions itself on Windows)
I solved this by accessing the security settings for the website folder and and clicking Advanced and then Change Permissions for the IIS_IUSRS user. I checked the "Replace all child object permissions with inheritable permissions from this object" and clicked apply.
Before that, I had given the IIS user full permissions to the hidden tmp folder in the root of the checkout, but I don't know if this helps with anything.
I'm not sure if this is a permanent fix, but in case it is not, you can at least use it to reapply permissions for all the files in a single operation.
Much information is located in .svn folders inside directory where project was checked out. So in my opinion better use SVN separately from advanced integration tools. Also this deals with solving problem like this.
I found this exact same issue happened when I did a 'Revert' using:
Tortoise Svn 1.6.16
AnkhSVN 2.3.11269.1348.
Visual Studio 2010 Professional
Windows 7 - 64 bit.
I was completely puzzled the first time I encountered the permissions error and started off by thinking it was my code. After a while of fiddling about I ended up deleting the whole project and re-downloading from Subversion which fixed the issue.
When this problem happened again I looked more closely at the reverted file, and I found the permissions on the reverted files do not match the permissions of the other files. Specifically 'Users' permissions, for the machine that Visual Studio is running on, is missing altogether.
So I just added it in by:
Right clicking on the problem file. This caused the file properties window to appear.
Then clicked on 'Edit...'. The permission window appears.
Then clicked on Add and the 'Select Users, Computers, Service Accounts, or Groups window appears.
Click on the Object Types button and check all the boxes.
Click on the Locations button and make sure your machine name is selected.
Type in 'users' then click the 'check names' button.
Click OK on all the windows to close them.
Your website should now run without the permissions error.
This may be a simple question but I will throw it out anyway.
My company's standard is to encrypt the contents of specific folders on our laptops, so in the case our laptops are stolen, the thieves would have a more difficult time at getting to "sensitive" information.
We are now being asked to encrypt our code that we work on (ASP.NET, winforms, WPF, etc.) for the same reason. Prior to this, our code lives in an unencrypted folder and everything works fine when we try to debug.
I tried to encrypt the folder for one of my projects, built it and started debugging. Note that this is a ASP.NET Web App running on Windows 7. I get the following error:
Server Error in '/' Application.
Access is denied.
Description: An error occurred while accessing the resources required to serve this request. You might not have permission to view the requested resources.
Error message 401.3: You do not have permission to view this directory or page using the credentials you supplied (access denied due to Access Control Lists). Ask the Web server's administrator to give you access to 'c:\dev\rdsims\development\Web\HomePage.aspx'.
Version Information: Microsoft .NET Framework Version:2.0.50727.4952; ASP.NET Version:2.0.50727.4955
Has anyone else encountered this? Do you need more information?
I think I found the answer... By default, it should work. Debugging a vanilla asp.net application on my laptop should be fine because it is running in the context of me, and I have the keys to the kingdom when it comes to encryption/decryption. HOWEVER, the application I am trying to debug runs impersonated as a different user (and thus does not have the proper access). So, the solution is going to be to debug on my laptop not impersonating the user, and then when it migrates out to QA and production, make sure the code is in place to impersonate, etc