1. Please be sure you are an Administrator on your PC before installing to avoid any issues.
2. To troubleshoot try giving local administrative rights to the C: Drive (or the install drive) to see if the software begins to work.
3. The first two items in the list below have been known to resolve the majority of the issues. Please do try them even if you don't think it's the issue.
If you are using any type of MS Office files with our tools you must make sure the input files are in a TRUSTED location. Although shown for MS Excel below, it is also applicable/similar to MS Word.
The link to a pdf below details a customers solution working on Windows Server 2016. In this case the customer was using 'Convert XLS' to OLE Automates MS Excel. Many other applications from Softinterface use OLE Automation ('Diff Doc', 'Convert Doc', 'Convert PowerPoint', 'Convert Document to Image'). The solution provided below is applicable to all Softinterface products.
NOTE: Using files on a network? Make sure you are only using UNC (Uniform Naming Convention) paths. Mapped drives will not work when using Windows Scheduler.
PROBLEM: A user was trying to launch a Softinterface program (COM or execute a batch script) as a service inside their application. The script worked fine on a Windows XP machine. However the same script when executed as a service within an application on a Windows 2008 server errors with the following message:
Microsoft Office Excel cannot access the file 'C:\MessageWay\msgstore\data\ABC.XLS'.
The same script was found to run fine from the DOS prompt within Windows Server 2008.
The file system will not be visible within a service unless the following is observed. In order to have the correct permissions passed in to the service you need to address the fundamental reason why they aren't passed in, which is apparently because a profile can't be found. In order to allow a profile to be found one creates the following 2 directories:
Windows 2008 Server x64:
Make this folder.
Windows 2008 Server x86:
Make this folder.
NOTE: When running a service you can specify the user to run the service as, however, this makes no difference, the permissions of the specified user are not passed in.
NOTE: This issue was found when using 'Convert XLS' when using the 'MS Excel' conversion method, however, it can also apply to 'Convert Doc' and 'Convert Document To Image' when using the 'MS Word' method.
NOTE: This folder may not exist by default on Windows 2008. This folder
does exist on Windows XP and Windows 2003.
Please CLICK HERE to review a word document that contains a step by step how to.
You may have to set the security permissions to enable launch and activation permissions on the Microsoft Excel/Word/PowerPoint application class within the component services section. The Component Services can be found within Administrative Tools, You then open up the Console Root, component services, computers, my computer, DCOM Config and select the Microsoft Excel Application. Then click on the security tab and enable launch and activation permissions on the component for the application / user that is using the component.
Problem: Trying to launch a Softinterface program via PHP or other script language causes the program to become hung in memory, but seems to perform well when ran manually.
Problem: When developing an ASP.Net application on Windows 2003 Server
operating with IIS v6.0 it is possible to get an 'Access Denied' error
when trying to create an instance of the clsConvertDocClass exposed via
Interpop (an instance of UnauthorisedAccess exception).
Resolution: The problem can originate because of the security permissions on the 'Network Service' account - which is the default identity for an Application Pool. To avoid the error change the identity under which the Application Pool is created to one that has sufficient privileges - such as the 'Local System Account'. This can be done on the 'Identity' tab on the Properties dialog for the application pool (found in IIS Manager).
See this handy tool found on Microsoft Technet. https://docs.microsoft.com/en-us/sysinternals/downloads/procmon Add a filter for the specific application you are working with. Give permissions to those files that our tool requires permission for.
A) Make sure that in IIS (Internet Information Server) under directory security you are not using ‘Integrated Windows Authentication’.
B) Two important things to consider:
IIS will be impersonating the client account when
accessing your ActiveX
EXE. Hence, the EXE will need configuring with dcomcnfg.exe in order to
accept connections from different accounts. By default, an ActiveX EXE runs
in the context of the "launching user". Hence, if there are several distinct
client users then you would end up with multiple instances of your ActiveX
EXE running. In the dcomcnfg properties for the EXE, I typically set
'Authentication Level=None' (in the General tab) and a specific user account
in the Identity tab.
The ActiveX EXE needs to be registered on both the web
server (where ASP
is running) and on the remote server (where you expect the ActiveX EXE to
run). Also, it must be the same version of that EXE registered in both
locations. When the ASP page comes to access the EXE, the details (either
ProgID or ClsID) are looked up first in the local registry before calling
out to the remote server machine.
C) If you are using Active Directory to authenticate users who would
enter your ‘admin’ section, that is where they can upload and run the Application
(e.g. 'Convert Doc' or 'Diff Doc'). A side effect of them logging via Active
Directory authentication was that it tried to trigger the Application as
that user, who did not have the correct privileges. We took this out and it
worked, the code on the page was,
Here it is:
' Force a username and password
If Request.ServerVariables("LOGON_USER") = "" Then
Response.Status = "401 Access Denied"
If any of your other clients are running convertdoc using command line
options and wscript, changing the authentication level to "none" on
convertdoc.clsconvertdoc via dcomcnfg.exe resolved my problem.
On Windows 2008 Server. Using COM interface from within a Windows Service:
We used a process monitor to find out where the application INI was. Instead of using the profile that the windows process runs under, it uses a system profile. The software began to work once the necessary information was added to the .INI file here:
C:\Windows\SysWOW64\config\systemprofile\AppData\Roaming\Softinterface, Inc\Convert Document To Image
99.9% of all issues (especially with servers) have to do with installing. You must install with all the necessary privileges, rights etc. Installing as an administrator usually solves problems of this nature.
When a COM component is run with a specific (not interactive) user identity, no HKEY_CURRENT_USER registry entries are loaded. Instead, values from HKEY_USERS\.DEFAULT are used. In this instance, because some entries relating to installed MS Office components were missing from the HKEY_USERS\.DEFAULT entries, this resulted in the MS Installer attempting to install the components each time the COM object was invoked. Once the missing registry keys were identified (from the application log using event viewer) it was a simple matter of adding these to HKEY_USERS\.DEFAULT.
More info on COM+ Wrappers, click HERE.
From a customer: "I finally was able to get the COM+ interface within an ASP page to work as expected. I tried all the recommendations in the FAQ Security Issues (online) without success until I completely removed the software (including uninstalling it, removing any registry keys, deleting the actual exe file after rebooting the server) and reinstalled it. I then made some changes as outlined in the documentation (click here for this documentation) and the component finally worked. I’m thinking that the previous version must be completely removed (files, registry, program) and then reinstalled.
From a customer: "Create a new application pool in IIS and have that app
pool run as the administrator account. Then put my web service application
in that app pool. After that change it started working. That means that my
Network Service account is missing permissions somewhere. "
If we log onto the server using the interactive user account before starting the COM+ application, ConvertDoc works as expected.
This is caused by the user running the server process not having
permission to run the Excel/Word COM object. The following link explains
it a bit. (Search for
In Windows 2003 Server the "DCOMCNFG" command is part of Component Services (the "DCOM Config" section.) Under "DCOM Config" there is an entry for "Microsoft Excel Application" which needs to have it's access permissions and its "launch and activation permissions" set.
Issue: On Windows 2012 Server we get no response from the Softinterface program when called from within the Oracle Database through a host shell command. The program was running fine when called from the command prompt from the server console.
Solution: Security privileges on Windows 2012 prevented the
Softinterface program from being called from within an Oracle Database
To fix the issue change the Oracle service in Windows that starts the Oracle Database to login as a User account instead of Local System account.
Below we show how to make this change:
Domain Name: ZZZ
This was an SQL Server installation on a Windows 2003 Server machine.
The problem I ran into was that when I installed SQL Server I was using
the Local (Computer) Administrator account so the SQL Server Service was
running under the ABC-DEV\Administrator Account. After I added the
server in question to the Domain, I changed the owner of the C: drive
and all subdirectories (including C:\Program Files\ and C:\Program Files
(x86)\) to be ZZZ\Administrator à The Network Administrator account.
This account was then considered the owner of the ConvertPDFtoImage (or
any other Softinterface Program) executable.
When running a command shell from within an SQL Server Stored Procedure (using xp_cmdshell) the resulting process is created using the SQL Server Agent Proxy Account which can be specified by using xp_sqlagent_proxy_account as described in Books Online. If no such proxy account has been specified, then the account which is running SQL Server on that machine (in this case the ABC-DEV\Administrator account) is used. Since ABC\Administrator did not have rights to the executable I was trying to run, the process hung. I resolved the problem by changing the account used to run SQL Server to ZZZ\Administrator. This can be done by right-clocking on the server in SQL Enterprise Manager, selecting Properties, then specifying the desired account in the Startup Service Account section on the Security tab. Naturally, whatever account is specified here will also need to have privileges to run SQL Server in order for it to work properly.
Bottom line is either the account running SQL Server needs to have privileges on the directory and executable being run in a command shell or an SQL Server Agent Proxy Account must be established that has these rights.
This was initially done using Visual Studio 2008. The user reporting this method has since upgraded to VS 2010. To use the COM interface, add a reference to the .EXE file of the Softinterface installation directory. Visual Studio then creates an Interop dll file. Then remove the .EXE reference, and move the DLL to a more permanent location in your project and add a reference to the DLL in VS. When the software is published to the server, the interop DLL is copied there and is what the program uses to access the COM object.
Try entering instead the fully qualified network path into the software. Some security attributes that may have been introduced after the software was made can hide mapped drives. A fully qualified path could look something like below for example:
Change the account under which the script is running to have the proper privilidges. For example change to an administrator as shown below: