Open Text Document Pipeline Base and services

Within the Technet-forums there was an issue posted regarding a problem with sequencing Open Text Document Pipeline Base and it referred to several error messages that were generated while attempting to run the installer in monitoring mode when using the App-V 4.6 SP1 / SP2 beta sequencer

The main culprit seems to be that as part of the installation – a service is started, or as happens while sequencing; it tries to start the service that was installed. This actually assumes the fact that you would install the service to run within the local-system context – and not as a service account as that is not supported within App-V 4.x. Since the service can not be started – if you cancel, the installation rollbacks and renders your capture useless.

This service is called Archive Spawner – or spawner for short. If opening services.msc and choosing manually to initiate the startup – you get a message that tells you the service started and then stopped again. If attempting to check the properties of the service you would receive another error message with saying this;  “The parameter is incorrect”.

Obviously – we don’t care about any parameters as the service started – and then stopped. The question here is – why it stopped? Lets attempt to start the process that would normally run in the context of the local-system account or a service-account for this piece of software;

C:\Program Files\Common Files\Open Text\Spawner\bin>spawner.exe
spawner: cannot open file \00SPAWNER.conf

Well – thats odd. A file that attempts to be opened using the path of \00SPAWNER.conf. Verifying the activity with Process Monitor you can see that the service (spawner.exe) attempts to read the file c:\00SPAWNER.conf – which isn’t there. (yes – you can run Process Monitor while in monitoring mode – you just need to ensure that its properly started and loaded its device driver before you start any monitoring.). Poking around the package tells you that the file is placed here; C:\ProgramData\Open Text\CONF_DIRS.
As an installation while not beeing in monitoring mode doesn’t generate this error – what could be different while in monitoring mode?

Poking around the system we can see that the following system environment variables are created;

If checking via a command prompt – the following happens;

As you can see – no EMC variables are seen from within the Command-Prompt. This seems odd. As the Technet-forum post above stated – this seems to be succesfully sequenced within App-V 5 – so there has obviously been improvements to that area. Comparing the Command-Prompt output of “SET” while installing this application natively – does show our EMC environment variables and also shows them in the GUI.  What can we do to resolve this problem? Creating the variables via the GUI does not seem to make any difference (they are already there), setting them via the SETX -command doesn’t do anything while we are in monitoring mode (not more visible after we run the command) – however, we could attempt to reset everything and set them as a prerequisite.

Run the following commands on the sequencer before you start the sequencer;

setx ECM_CONF_DIRS "C:\ProgramData\Open Text\CONF_DIRS" /M
setx ECM_DOCUMENT_PIPELINE_BASE "C:\Program Files\Open Text\BASE Document Pipeline 9.7.1" /M
setx ECM_DOCUMENT_PIPELINE_CONF "C:\ProgramData\Open Text\BASE Document Pipeline" /M
setx ECM_LOG_DIR "C:\ProgramData\Open Text\var\LogDir" /M
setx ECM_VAR_DIR "C:\ProgramData\Open Text\var" /M

Once you are in monitoring mode – the installation will now pass on without issues. Since there isn’t any entry point (aka virtual extension) for this application – there will not be an OSD-file generated. OSD-files usually contain the environment variable configuration – so you will need create a dummy file (shortcut to whatever you like) inorder to verify if the environment variables are captured within your package (most likely not) and actually show up within the OSD-file. You could attempt to run the setx-commands while in monitoring mode, that will unlikely ensure that they end up in the package as they already exist within the sequencer. Worst case – simply choose to open this in Edit Mode and then add the environment variables under the OSD-tab in the sequencer.

Open Text Windows Viewer–virtual vs native install

If you have a native install of Open Text Windows Viewer (any version) and want to contaiimagen and co-operate a virtualized Open Text Windows Viewer you might run into a problem if the application uses certain COM-objects. As opposed to star the virtualized instance – the native application gets called every time. Try removing the following value while in monitoring mode;

HKCR\CLSID\ {30446849-11E3-11D0-9D4E-0020AFC0E4C0}\InprocHandler32

If you review the activity using Process Monitor – you will notice that SVCHOST.exe is the process that attempts to start alviewer.exe. The reason is explained by Sasha in one of the previously posted interviews.