Skip navigation
All Places > Knowledge Base & Downloads > Blog > 2014 > June

Pharos SignUp Client logging on a Windows 7 SignUp Client it fails to log.


"Knowlege Base article #626,  Pharos Logsetter Utility says I can't use the log setter to turn on logging for the SignUp Client so I need to know how to get a SignUp Client Log."

Uniprint 8.1

There is currently an issue with logging the signup client as it does not produce a Signup Client log but will produce 2 other logs those being the UILog and the CPLog


The issue seems to be with the logsetter tool and how logging is done on Vista and Windows 7 machines.


Included is a tool that can be used called "remotetracer" (see attachment)


1. What you need to do is get this exe on a machine somewhere.  The server is probably a good choice, since it will need to run uninterrupted for a while.  On the server, run it from the command prompt.  It may tell you it needs additional configuration to work properly (i.e. adding a pipe name to the registry).  Update the registry if needed and exit the program, and run it again like this:


remotetracer > clientlog.txt


2. Now on the SignUp client to be logged, browse to HKLM\Software\Pharos\SignUp Client\Log and add a new REG_SZ value called "PipeName".  Set this value to "\\server\pipe\remotetracerpipe".  The other values should be as you would typically set for file logging (level 5, options 31, types 15, etc... if in doubt, use the logsetter and make sure all checkboxes are enabled, then add the PipeName afterward).  After this, reboot the client and when it restarts you should see clientlog.txt on the server begin to increase in size.


While this is going on, make sure we are still writing the CP, UI, and SUServer logs.


There are two additional keys for client logging on Vista/W7, for logging different components.These are for the Credential Provider (CP Log) and Client UI (UI Log) components. Instead of a 'Log' subkey (HKLM\Software\Pharos\SignUp Client\Log), you create one called CP Log (HKLM\Software\Pharos\SignUp Client\CP Log) and one called UI Log (HKLM\Software\Pharos\SignUp Client\UI Log).


The UI component is basically just the clock icon and popup messages, so logging that is not too interesting. If you do decide to log the UI component, that process runs as the user and so requires a log location the user can write to. The other one (CP Log) logs little more than function traces, but logs with system privileges.


The two new subkeys use the same format as the original Log key, so the easiest thing to do is set logs using the logsetter, then export that subkey (HKLM\Software\Pharos\SignUp Client\CP Log) and modify it to create the same values under the new names.


This should get you logs of the SignUp Client.

Uniprint 8.2 and later

There are 3 specific registry keys used to enable detailed logging on a Uniprint Signup client.  The attached zip file (SignUp Client Logging Registry will create 3 files.

1. The Signup Client log
This log contains information on the client and its communications to the server.

2. The Signup CP Log
This log contains information on some of the underlying components of the client provider mechanism.

3. The Signup UI log
This log contains information on the User Interface of the client.

These 3 log files will be created in the directory "c:\windows\temp\pharoslogs".

This directory must be manualy created on the client machine.  If you are using a PC State software such as Deepfreeze or Clean Slate then the registry keys may need to be modified to point to a folder in the "Safe Space" of the client system so they do not get deleted when the client machine reboots and the PC is reverted back to a "clean state".

The 3 log file names will be:
1. signupclient-log.txt
2. signupCP-log.txt
3. signupUI-log.txt

After applying the registry keys you will need to restart the client PC.

To delete all the logs files created and start with a new set you will need to stop the "Pharos SignUp Client" Windows service, delete the files and then restart the service.

There are two folders in the zip file, one for 32-bit clients, and another for 64-bit clients.

There are 2 independent Uniprint environments, i.e. 2 different principal servers and databases.  Most users are confined to either one, but there is a subset of users who want to interact with both environments.  However, the printers from one package are overwritten or removed by the other package.  Is this scenario possible?



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.



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.



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)

-- 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].