These past weeks I have been battling our webservers and application to get DCOM calls from IIS to Microsoft Office 2007 working. After several high hopes and nervous breakdowns I have found solutions to all the catches I have found.
I'll first describe our environment a bit.
We have Windows server 2008 R2 servers (that means it's running x64mode) with Office 2007 (that's 32 bit) installed on it. The Webserver needs to be able to make a snapshot of a certain page in an uploaded Office document and show it on the website.
To be able to open Office from IIS you need to change DCOM security for the Office applications.
So the first problem that can happen is that after installing Office you don't find the objects in the Component Services MMC, normally they should be under "Component Services"/"Computers"/"My Computer"/"DCOM Config".
If you can't find them, open the Component Services MMC in 32 bit mode by opening a run box (
Now the office applications should be visible under "Component Services"/"Computers"/"My Computer"/"DCOM Config".
(this solution is described on many blogs over the Internet, I just repeat it here to have a more complete solution in one place)
The next problem is that IIS 7.5 by default runs under the Account "IIS AppPool\DefaultAppPool", people often change this to "network Service" or even "local System" (YUCK!!!! Really people.... Never run IIS under "local system"!!! this means that if a hacker can exploit IIS he will be GOD on your system)
This is a security feature from Microsoft that I don't want to turn off lightly... So I don't!!!
I just give the user "IIS AppPool\DefaultAppPool" the rights on the locations it needs.. (including DCOM activation)
However this user cannot run Office by himself, so we will have to create a proxy user which I'll call sa_DCOM for now (sa meaning Service Account) This user needs to be in the users group and have write rights to the location where office will need to write the files)
So open the Component services MMC.
A lot of sites tell you to change the default security on "Component Services"/"Computers"/"My Computer"/"DCOM Config" itself. But this is not best practice as that way you'll open up all the DCOM applications on your server to be exploited by hackers.
so navigate to the path "Component Services"/"Computers"/"My Computer"/"DCOM Config" and then open up the properties to "Microsoft (Office) Word 97 - 2003 Document" (the Office depends on the version of office you have. In 2010 it's no longer there)
now do the following settings:
Security/ Launch and Activation Permissions Customize -> Selected,
Edit
Add: IIS AppPool\DefaultAppPool with local launch and activation rights
Security/ Access Permissions Customize -> Selected
Edit
Add: IIS AppPool\DefaultAppPool with local Access rights
Security/ Configuration Permissions Customize -> Selected
Edit
Add: IIS AppPool\DefaultAppPool with read rights
Identity -> This user-> Selected, User =
This way Office and IIS will allways run with the lowest permission needed.
Now we would think that we're there...
Alas not!
Microsoft Office Word needs the user that runs the application to have it's registry keys loaded.
The problem is that, as soon as the user sa_DCOM is logged off, its hive unloaded. So we'll have to find a way to keep the profile loaded. My solution for this is that I have created a dummy service which does absolutely nothing and let that service run as sa_DCOM. As soon as the service starts the profile is loaded and Word will run without problems. (so set the service to start automatically).
The settings for Word that I have done above can be done for Powerpoint and Excel also. And other programs also I would think, however I have only tested these three...
I hope that some of you guys will be spared (any more) hear tearing and crying by reading this post.
Here are some of the DCOM Errors I have solved with the above solution:
Error Exception from HRESULT: 0x800A03EC
Exception from HRESULT: 0x800AC472
and of course the access denied error 0x80004005
Posts
