When submitting a Secure Release (or held) job to a clustered Uniprint 8.3 Print Server, the queue goes into an "Error" status, as does the print job. When I review the SecurePort log, I see the following:

"Server was unable to process the print job. See server logs for error."

The PrintService log (referred to by the SecurePort log) shows this for the same entry:

"[JobReceiver] (-AddJob.Failed-) Job Id:f7c6500b-046d-4578-8bde-9cce986e1ee0(0) Input string was not in a correct format."

What is happening?

The reason that this (otherwise unhelpful) message appears is due to a missing registry key "HKEY_LOCAL_MACHINE\Software\Pharos\Print Server\Next Job Id". This is created as a 'DWORD' type when the Secure Release Service is started for the first time.

In a cluster server environment, a technology called Registry Checkpoint is used to sync the Windows Registry between nodes. Because of this feature, any changes to a Registry key while the service is offline is reverted to the previous checkpoint when the service starts up. In the case of the Secure Release Service, it starts up first (due to dependency) and creates the Next Job Id key correctly. However, when the Print Server starts up, that change is rolled back since it is occurred while the Print Server service was offline. This is why there was no Next Job Id key.

The resolution is to manually create the registry key "HKEY_LOCAL_MACHINE\Software\Pharos\Print Server\Next Job Id" (on a 64-bit system this will be in "HKEY_LOCAL_MACHINE\Software\Wow63432Node\Pharos\Print Server\") on the active node. Then either restart the server or Secure Release Service. Users will now be able to submit and release print Jobs from this server. Ensure that this key also exists on the other node(s) when they are the active node for the cluster.

NOTE: This will be corrected in a future service pack, and currently affects PServer.exe for the original 8.3 release and Service Pack 1.