How to install client packages from different Uniprint environments on the same workstation

Overview

The printers from one package are overwritten or removed by the other package because there is a conflict in the SpoolQueueId collected from the Windows Registry.

Technical

The same "SpoolQueueId" in the "LocalPrinters" key under the "Popup Client" registry.  Notice the value of "SpoolQueueId" was set with the [module_id] for the printer module in a package.  The [module_id] is unique within an environment, but it's incremental.  So, it's possible for the [module_id] to overlap between independent Uniprint environments.  This value must be randomized so that the packages can coexist. The [module_id] of a queue is stored in the [modules] table.  It's created by a trigger after the queue is added to the database.  The column is an 'identity' data type.  The 'Identity seed' of the queue must be changed so that the seed depends upon a unique value in each environment, such as the Site Code.

Resolution

In this example, use the Site Code as the unique value in each environment.  The Site Code includes 2 digits at the end.  The SQL script below collects the last 2 digits from the Site Code, which is derived from the License Key stored in the database.  This is represented as @licensekey in the SQL script.  Then, @seed is generated randomly using @licensekey as a salt.

-- Script Start --
use pharos

declare @seed int
declare @licensekey nvarchar(255)

select @licensekey=license_quick_key from system
select @licensekey=right(@licensekey,2)
select @seed = 0

begin try
  select @seed = 2000 * convert(int, @licensekey)
end try
begin catch
end catch

select @seed = 1000+@seed
DBCC CHECKIDENT (modules, RESEED, @seed)
go
-- Script End --

Run the SQL script (above) on the Pharos database in each of the independent Uniprint environments.  The SQL script creates a new random next incremental value for [module_id] on each of the Pharos databases.  New queues and packages will now receive a unique [module_id] and "SpoolQueueId".  However, this will not affect existing ones.

It's often easier to rebuild the queues and packages for one of the independent Uniprint environments.  If this is not a feasible option, then there are several options for how to handle existing queues and packages that have already been deployed.

The "SpoolQueueId" is based upon [module_id], as described above.  The client packages only use the "SpoolQueueId" when installing or upgrading itself in order to decide whethere to delete an existing printer (queue).

Option 1:

1. Install package A

2. Run a customized REG file that changes the Windows Registry key named "SpoolQueueId" for each print queue installed under HKLM\SOFTWARE\Pharos\Popup Client\LocalPrinters. This is accomplished using a custom action incorporated with the package

3. Install package B

Option 2:

1. Run the database update script on one of the Pharos databases

2. Build new queues on one of the Pharos databases

3. Build a new package C that includes the new queues

4. Install package A

5. Install package C instead of B

Disadvantage: More setup and additional queues on one of the Pharos databases.

Option 3:

1. Run the database update script on one of the Pharos databases

2. Update the existing queues' [module_id] on one of the Pharos databases, which includes 3 tables: [modules], [module_os], and [package_modules]

3. Rebuild the existing package from the updated database (above)

4. Install package A

5. Install package B

Disadvantage: Could cause duplicate printers for those who have the package with the original unmodified [module_id].