This section covers the migration prerequisites for all the migration scenarios supported by iPrint.
OES 2018 SP3 server with iPrint installed, and with Print Manager and the Driver Store configured. For more information, see Installing and Setting Up iPrint on Your Server
, Creating a Print Manager
, and Creating a Driver Store
in the OES 2018 SP3: iPrint Administration Guide.
IMPORTANT:If your target server is in a non-replica eDirectory tree, both the target Driver Store and Print Manager must be active for migration to be successful. Configure SLP to make them active. For details on SLP configuration, see Configuration Parameters
in the NetIQ eDirectory Administration Guide.
Before starting the migration, ensure that the source and target Print Managers are running. If you are using command line tools for migration, ensure that the source Print Managers are running.
When you upgrade to OES, ensure that you migrate NDPS to iPrint. NDPS is not supported on OES Linux.
Ensure that the file containing the printers to be migrated does not contains extra spaces or characters. For troubleshooting extra spaces, see Printers are not migrating with the -f option.
Ensure that the driver paths are correct and accessible. For troubleshooting a bad driver assignment, see Invalid driver path assignments.
Ensure that you retain the Print Agent redirection on the source servers.
For Linux source servers, follow the instructions in Creating a Print Manager
in the OES 2018 SP3: iPrint Administration Guide.
Ensure that the user has the following rights and permissions assigned explicitly on the source server so that the user can access and execute the psminfo.nlm, even if there is a mismatch of source server and container admin credentials for the user:
Read permission to sys:ndps folder on the migration source server.
Add the user as a trustee with supervisor rights to the source server NCP server object.
Back up the Print Manager database files on the source server prior to migration. For Linux, see Understanding the Print Manager Database
.
The servers involved should be accessible via SSH. If the SSH ports are not open in the firewall, ensure that they are open before trying to access the servers.