ABCpdf .NET 10.0

It is not uncommon to come across permissions issues when running OpenOffice.org from ASP.NET.

We offer a three step guide to help you through these. Follow the instructions precisely and you should have no problem.

Step 1. Validate your existing solution

Download and install OpenOffice.org. Open some documents to check that it's working correctly. You may wish to disable the OpenOffice.org Quickstarter to ensure that the OpenOffice.org processes are shut down after use rather than kept alive in the background. This may be important if you are going to be changing the user at a later stage.

Build and run the doc2pdf project. If it fails then this would imply a generic configuration issue. Check your OpenOffice installation. Let us know if you cannot see a cause.

If it succeeds (as invariably it will) it will imply a permissions issue under ASP.NET.

So assuming it succeeds we need to eliminate the permissions issue. The easiest way to do this is to bypass it using .NET Enterprise Services.

There is an example project ready for you included with your ABCpdf installation. You can find the PDFEnterpriseServices project in the Projects folder under the ABCpdf menu item. All you need to do is build and run it.

Let's assume you are logged on locally as Administrator. All you should need to do is open the solution. Then set right click on the web site project and select it as the startup project. Then run - just press F5.

Note for Vista users with User Access Protection (UAP) enabled. UAP means that Vista switches between user and administrator mode as requested. Visual Studio may not always make appropriate requests during the build process and this can lead to access failures or generic errors. We have found it significantly easier to disable UAP temporarily rather than work through these errors.

Step 2. Deploy to your destination server

Once you've got the .NET Enterprise Services project working on your local machine you may want to deploy it to a remote server.

You should note the following points before deployment:

1. For server versions of Windows (e.g. Windows 2003 Server) it is important that the latest updates from Microsoft are installed.
2. It is important that ABCpdf .NET has been installed by running the installer on your server. This is necessary to ensure that ABCpdf is available via the GAC.
3. It is important that the version of ABCpdf .NET you compile your project against is exactly the same as the version you install on your remote server. If the versions are different, .NET will refuse to load the assembly.

Once you've built the .NET Enterprise Services DLL on your local machine you can copy the project to the remote machine and register the DLL from the command line while logged on locally as Administrator. Simply make the following call from the command line,

regsvcs.exe PdfEnterpriseServices.dll

After you've registered the DLL you should set up a new virtual directory and point it to the web site. Then browse to the site.

If you later need to update the package you must first delete it using the Component Services Administration tool and then re-register the DLL otherwise your changes will not be picked up.

The Identity of the Component Package should be left as the Interactive User. Indeed you should be logged on locally as the Interactive User. By all means change the user later - but please do not be tempted to do this before you have got the package working.

So why do we say this? The problem with changing the user is that each user has to - on first run - accept the OpenOffice.org EULA. Running as the interactive user you can see this and accept it yourself. If you change to someone who may not have access to the desktop you may never see it and you'll end up with a timeout. It's important to start with a simple scenario so that you know what you are dealing with.

Step 3. Change the Component Package user

The Interactive User is fine as long as you are logged on locally. However this may not always be the case for web servers. So you will most likely want to assign a user to the package.

When you change the user it should be to one that has accepted the OpenOffice.org EULA. If the user has not accepted the EULA then ABCpdf will time out. In this case you will probably want to copy over the EULA acceptance documentation to the relevant user.

Let's assume you entered appropriate values for the EULA and auto-update settings when you originally ran OpenOffice.org. These are stored in your personal settings on the computer. For example:

C:\Documents and Settings\Michael\Application Data\OpenOffice.org

Or:

C:\Users\Michael\AppData\Roaming\OpenOffice.org

So all you need to do is copy these settings to the Component Package user. On Windows 2003 you will probably need to copy the OpenOffice.org folder to:

C:\Documents and Settings\Default User\Application Data\

On Windows 2008 or Vista 64-bit you will probably need to copy it to:

C:\Windows\SysWOW64\config\systemprofile\AppData\Roaming

On Windows 2008 or Vista 32-bit you will probably need to copy it to:

C:\Windows\System32\config\systemprofile\AppData\Roaming

On Windows XP the setup may be slightly different and depending on whether you've set up the Component Package as a Service or not you may find the user settings at one of the following locations:

C:\WINDOWS\system32\config\systemprofile\Application Data\
C:\Documents and Settings\NetworkService\Application Data\

If you are unsure about the location assigned to a particular user you can use Process Monitor from Microsoft / SysInternals (mentioned on the main support page) to find out.

Note that there is a lock file at the top level of the OpenOffice.org folder which you may need to delete after copying the settings.

Further note that for OpenOffice versions 2.x the folder is called OpenOffice.org2. Since OpenOffice 3.0 it has been renamed to OpenOffice.org and it contains a sub-folder called 3.

Alternatives to .NET Enterprise Services

You can probably do without Enterprise Services provided you give NetworkService (or your equivalent app pool identity) DCOM launch, activation and access permissions. To do so:

1. Launch component services (dcomcnfg.exe)
2. Go to Computers->My Computer->DCOM Config.
3. Scroll down and look for an application called "Open Office Text Document 1.0" or "OpenOffice.org 1.1 Text Document" or "OpenOffice.org Service Manager".
4. Right click on the application, select Properties and go to the Security tab.
5. Set the Launch and Activation Permissions to Customize and then click on Edit.
6. Add NetworkService or your ASP.NET user (or in fact the entire IIS_IUSRS group) and give it full permissions.
7. Repeat for Access Permissions
8. If there is more than one Open Office application repeat the process for all of them.
9. You can also give it permissions for all DCOM applications, not just Open Office, by selecting Computers->My Computer, launching the properties dialog and using "Edit Default" in the COM Security tab.

Note that there are both x86 and x64 versions of DCOMCNFG for separate x86 and x64 settings. By default on x64 versions of Windows the x64 version is launched. To launch the x86 version you will need to perform the following command line operation:

C:\WINDOWS\SysWOW64> mmc comexp.msc /32

Common Problems

The most frustrating cause of problems with OpenOffice.org are a generic failure to do anything. Typically your process will hang for a minute or two and then finally come back with an error message such as the following.

Retrieving the COM class factory for component with CLSID {82154420-0FBF-11D4-8313-005004526AB4} failed due to the following error: 80080005 Server execution failed (Exception from HRESULT: 0x80080005 (CO_E_SERVER_EXEC_FAILURE)).

Fortunately these types of errors are almost always caused by a simple misplacement of configuration files.

OpenOffice.org looks in the AppData folder for the current configuration. If it looks in the wrong folder because the environment is set up incorrectly then it will most likely hang. Most likely it will drop a ".lock" file in this location which will need to be delete to free the process.

For example you might have your OpenOffice.org configuration files here.

C:\Users\Edward\AppData\Roaming\OpenOffice.org\3\user

But you might find that OpenOffice.org is looking here.

C:\Windows\SysWOW64\config\systemprofile\AppData\Roaming\OpenOffice.org\3\user

The solution is to identify the issue using Process Monitor (filter on AppData or similar). Then you can either fix the environment or you can copy the correct settings over from your AppData folder.