Good Morning Brad,
Whether you manually created and enabled "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Pharos\LPD Server\Submit new jobs via Secure Release", then the shared print queues are going to be the entry point for new jobs. Regardless of how they make it to the SecureRelease service, the jobs are held there until they are released or purged whether they be processed immediately in the case of a direct Print Group, or they are held until they expire or are released by a person for a held Print Group. Since version 8.3, the SRS will deliver the jobs directly to the printers instead of using the Windows Print Spooler. This means that the client machines themselves really have no idea where the physical printer is or how it is being delivered to paper.
This is good news because it means that you can pretty much just change the IP address of the device in the Pharos Administrator and issue a change control. Version 8.3 will exclusively print via LPR (unless you are using a pass-through queue which would require that you update the port/network properties there instead of in the Pharos Admin as I am describing), whereas RAW printing support is in 8.4 after hotfixes and 9.0 natively (default port = 9100) along with LPR printing (port 515). As long as you have that port routed and open in your firewall, you should at least be able to print ("that port" = the TCP Port value under the Network Information section - see below). I still would recommend that you ensure that port 161 - or whatever port you use for SNMP - is also opened so that Pharos can detect the status of the device. If you do not wish to open 161 or enable SNMP, be sure to turn off the Online State Check in the Pharos Administrator at each Device entry for which you want to skip the SNMP check.
- Set the new IP address on the printer
- Set the printer's new IP address in Pharos Admin > Output Management > Devices --> (lower center pane) --> Network Information > Network Address
- Disable the Online State Check or modify the SNMP info if/as needed
- Run Online State Check (Actions pane) to see if the device is responding to SNMP
- Send Test Page (Actions pane) to see if the test print job comes out successfully
- Issue a Change Control to inform the Pharos services of the device's new location
- If jobs won't come out, verify your ability to ping the printer and telnet to it by IP address on the TCP Port listed two rows below the Network Address described above
As Steven said, the client is really irrelevant in this case, because it points to the server, and the server points to the printer. So, you change the IP in the device properties on the server and you're done. This also means the printer could be entirely replaced with a new make and model and as long as the driver on the client end was somewhat compatible, it would still work as well, even if some features did not. If you included the updater (on Windows packages anyway) the client would update from the new package with the new driver on the server automatically so again it's pretty much no touch.
One thing to be aware of with the updater is that it is only triggered when a print job is sent. This means that the user that is logged in at that moment must have sufficient permissions to update printer properties, and any security software (e.g. Deep Freeze, Clean Slate, SmartShield) must not be enabled or it all the changes/updates will be wiped out when the machine is rebooted.
Continuing, if one has security software installed, the updater would potentially end up annoying the end users unless you were to go to the lengths necessary to script a job submission to trigger the updater during a maintenance window. That would need to be coordinated with the frequency interval that the updater checks in (set in the Administrator), or you potentially wind up with first job after a reboot always triggering the updater since the date stored in the registry would likewise be locked down. The effort spent in scripting a trigger would likely be better directed in just having the ability to push the print package down to the client for a silent/quiet install on an as needed basis.
A few other notes about the auto updater... The updater is not designed to update the Pharos software from one version to the next. It is simply designed to compare the checksum in the registry for packages that are installed to the checksum that Uniprint generated/updated when the package was built. It will then update the necessary modules to get the locally installed packages in sync with the server. The updater functions globally at the workstation level meaning that if any package installs the updater, all installed packages will get updated.
I have found the simplest way to "disable" the updater if, for example, you find that security software is being added after the initial deployment, the uniupdater.exe file can simply be renamed or removed from the Pharos\Bin folder. I have not checked recently, but the reasoning behind renaming instead of removing it is to prevent confusion if someone sees in the registry that the updater is supposed to be installed and the file is missing (i.e. if the updater is not firing, but you see the file renamed to "uniupdater.exe.disabled", it eliminates any mystery as to why the updater has not been firing).