BCL easyConverter SDK Word
easyConverter SDK Usermanual
PDF-to-Word Programming API  |  Download Free Trial  |  Contact Us to Purchase

Using easyConverter on the Server Side

Servers and system services do not behave the same way as desktop applications. Services are running under special limited user accounts, and do not have access to the desktop. For example, they cannot open a dialog box, or launch Microsoft Word.

In order to work around these limitations, easyConverter offers two alternative solutions. One is called the Loader Service, and the other one is called Impersonation.

When to Use Loader

PDF2Word only uses Word automation in a select few cases:

Only in these very rare cases is it necessary to use the Loader Server or the Impersonation technique. Most customers should never have to worry about any of this.

On the other hand, when Microsoft Office automation is used on the server side, such as from Microsoft Internet Information Services (IIS), it is absolutely necessary to use Loader.

Beginning with easyConverter SDK 5, users have a choice between the Loader Service and Impersonation.

The Loader Service

The easyConverter SDK Loader Service has been a part of the product for a very long time. It is based on the idea of running a system service under a desktop user account. All easyConverter function calls are tunneled through this service, therefore impersonating a desktop user.

The disadvantage of this method is that this service must always be running under a highly privileged user account, which is a potential security vulnerability. Also Windows has to store this username and password somewhere in the registry (in encrypted format). The uninstallation of easyConverter causes the password to be forgotten, which must be manually reset every time easyConverter is reinstalled.

Another huge disadvantage is that the service is a single point of failure. Should easyConverter crash, it might crash the service with it. Should the service fail in any way, a real person must log in to the server and restart it manually. The service cannot easily be killed or restarted during normal operation. If the service is busy, that can cause issues with uninstallation or upgrade.


The alternative solution is to simply impersonate a desktop user when necessary. This brand new technique was introduced in easyConverter SDK 5, and is available for .NET, Java, PHP and Python programmers only. Users of the classic COM API have no choice but to use the Loader Service.

The basic idea of Impersonation is to launch an external process under a specific user account. Instead of having a central Loader Service that is always running, each SDK object is isolated into a separate worker process. Each worker process quits as soon as they are not used anymore.

A huge advantage of Impersonation over the Loader Service is that multiple different users can be impersonated. For example, you may have a separate user for each web request.

The difficulty of this solution is that the username and password must be supplied as parameters by the user of the SDK. It is the developer's burden to hide this information in a secure location. Those who are uneasy about storing cleartext passwords in the source code are required to encrypt it. Fortunately, .NET has a built-in solution.

Note that the implementation offered by the classic Loader Service is not any better, either. The only difference with Loader Service is that the password is managed (and encrypted) by Windows, which is not incredibly secure, either. It uses an encrypted registry key, which solution is strongly discouraged and deprecated, yet still used by Microsoft to store user passwords for services.

Security via Isolation

On a modern Windows system, it is a physical impossibility to run Microsoft Office on the server side without supplying a username and password.

When security is a concern, customers should separate the web server from the application servers via a firewall. Make sure easyConverter is only installed on the application servers, which are on a local area network, completely inaccessible from the internet. Only the web server should be online, which distributes individual conversion jobs to a load-balanced array of application servers.