Configuration

The steps outlined in the previous sections complete the initial deployment of ScriptX Printing server side and validate that ScriptX can be successfully used on the server. However, as configured after initial installation, there are two undesirable aspects:

1. An interactive user must be logged onto the server at all times.
2. For IIS 5/5.1, the ASP application must be marked as Application Protection Low (IIS Process); a failure in the ASP application will cause the entire server to fail.
3. For IIS 6 and later (Windows Server 2003 and later) the application pool is using the SYSTEM account, this presents a potentially severe security risk.

The changes listed in the following sections are those for a default install of Windows Server.

A typical problem during configuration is "Access denied" errors. When errors occur, always check the event log - access denied usually means what it says, the account making the request is being denied because of access restrictions. If errors make no sense, then a reboot can often solve problems as the settings made are then actually used. If you are still having problems and are doubtful that the problem is to do with DCOM settings, then add the "Everyone" account to default launch and access permissions - if this solves all the problems then it confirms that you have a DCOM security configuration problem.

IIS 5/5.1

Before making the changes discussed here, the server should be rebooted (or the IIS Process stopped and restarted) to ensure that the ScriptX Components are unloaded from the IIS Process (IIS caches used component DLLs).

Application Protection

The ASP worker process will run under either the IUSR_<machinename> account (medium protection) or IWAM_<machinename> (high protection). These accounts must have "Log on as a batch job" rights and must also have permission to launch DCOM servers and access DCOM servers (in particular the "MeadCo TriPrint Server" object - DComCnfg can be used for this).

After changing the protection level and appropriate configuration with dcomcnfg.exe it is suggested that the above tests are run again to ensure successful operation.

Note: If the tests fail with the error "Unable to create ActiveX Object" the most likely cause is that the IUSR/IWAM accounts do not have "Log on as a batch job" rights or do not have permission to launch DCOM servers.

In addition, the account used as the identity for the "MeadCo TriPrint Server" object must have DCOM access permissions, at this stage this can be achieved by adding INTERACTIVE to the Default access permissions list - however, see "Running ScriptX Printing under a specific user account" below in this section for additional configuration.

IIS 6 and later

As initially configured, the application pool is using the SYSTEM account. It is preferable to use either a default account (e.g. the default NETWORK SERVICE for IIS 6 or the ApplicationPoolIdentity (IIS APPPOOL\<Poolname>) in IIS 7) or a named account created for the purpose. After changing the identity to use (e.g.) the NETWORK SERVICE account or ApplicationPoolIdentity, it is almost certain that the tests listed in the previous sections (start with testprint1) will fail with:

"Unable to access printer object - there is a ScriptX configuration error. Error on create: Access is denied. (Error code: -2147024891)"

There will also likely be an error from DCOM in the System event log:

 "Access denied attempting to launch a DCOM server, The server is: {1663ED76-23EB-11D2-B92F-008048FDD814} ..."

The account used must have permission to launch DCOM servers and access DCOM servers. "Component Services" should be used for this. It is our experience that changes to "DefaultCOM Security" must be made, applying the changes to the "MeadCo Triprint Server" is insufficient. In otherwords, for example, add NETWORK SERVICE (or IIS APPPOOL\<Poolname>) to those accounts listed for each of Launch, Activation and Access permissions under Default COM Security.

In addition, the account used as the identity for the "MeadCo TriPrint Server" object must have DCOM access permissions. At this stage this can be achieved by adding INTERACTIVE to the Default access permissions list - however, "Running ScriptX Printing under a specific user account" below in this section for additional configuration details.

After changing the protection level and appropriate configuration with "Component Services" it is suggested that all the above tests are run again to ensure successful operation.

Running ScriptX Printing under a specific user account (IIS 5 and later)

Running ScriptX Printing under a specific user account removes the necessity for an interactive user to be logged on to the server machine. There is no necessity for the account to be used to have "Administrator" rights. However, it must:

1. Have a properly configured Internet Explorer (in other words, log on to the account and ensure that the web pages to be printed can be accessed).
2. Have a functional default printer available - ScriptX Printing must be able to read the settings of the default printer.
3. Have access rights to the printer to be used.
4. Have "Log on as a batch job" rights.
5. Have "Create global objects" rights (without this right licensing will not work).
6. Have (read) access to the the folder where the ScriptX binary files are installed.
7. Already be in use as the logon identity for a service.

IIS 5 and 6

Please note, for IIS 5 and 6 that if the account to be used is not already logged on, its registry hive will not be used - the "Default User" hive will be used instead. Although the default hive can be configured with access to the required printer(s), since ScriptX Printing requires read and write access to various parts of the hive (for example to store print header/footer settings) this is not recommended. It is recommended that a "null" service is used instead. If the account to be used for ScriptX Printing is not already in use for a service, a suitable service is available in the ScriptX Server-side printing Add-on kit. The kit is available to licensees in the downloads section of the My MeadCo Portal.

IIS 7

With IIS 7 there is an option for the Identity used for the application pool to load its registry hive when the pool is loaded. If the same Identity is used to run the MeadCo TriPrint Server, then there is no need to use an appropriate service as described above. 

To configure ScriptX Printing to use a particular account, use "Component Services" (or  DComCnfg) to configure the application "MeadCo TriPrint Server" with the required identity. Also ensure that the required identity is given access permission in default DCOM security.

After configuration, it is suggested to log off any interactive sessions on the server and access the server from another client machine and that all tests are run again to ensure successful operation.

 

::> Test and validation kit