Post-Migration Tasks

The final step in the migration process is determined by whether the migration was successful or unsuccessful.

No post-migration tasks are necessary beyond the standard migration process. If the server state (new settings, drivers, queues, and so on) changed, create and archive a new backup of the server state for recovery purposes.

After taking the source server offline while backing it up, users are unable to print until the migration to the destination server is complete. To minimize the impact, leave the source server in service while you complete the migration and testing of the destination server. By leaving it in service, you can also add both the source and destination servers to the Print Management snap-in to simplify verifying the restoration.

Once you have validated the installation, rename the source and destination servers and take the source server offline.

On the source server, restart the print spooler for all printers so it can finish spooling delayed print jobs. When it finishes, verify that there are no new print jobs.

Rollback can only be completed if retirement of the source server has not been started. After you start retiring a source server—that is, you delete any print queues, close any print connections, reformat any drivers, or remove any hardware from the source server—you cannot roll back migration. After you start retiring the source server, the only method of rolling back migration is to restart the Print Services migration process from the beginning.

Rolling back migration involves renaming the source server to its pre-migration name, and renaming the destination server to either its original name, or another name that is not the same as the pre-migration name of the source server. Renaming the source and destination servers can be completed in a few minutes.

Printer migration events are included in the Application log, which is located at %SystemRoot%\System32\Winevt\Logs\Application.evtx and can be viewed using Event Viewer. A custom view for Printer Migration Events is available in Event Viewer.

Note

If the Printer Migration Wizard fails, you are directed to Event Viewer to view error messages. If you cannot find an error that explains the failure in Event Viewer, restore the backup by using the Printbrm.exe command-line tool. Error reporting from Printbrm.exe can often provide more detail than what is available in the event log.

When a cross-architecture migration includes the migration of printer language monitors, an error will occur during the process of restoring the printers to the destination server using the Backup Restore Migration (Printbrm.exe) command-line tool. The reason for the error is that language monitor driver architecture must always be the same as the source server architecture. Therefore, when migrating from x86-based architecture to x64-based platforms, language monitor migration cannot be successful. An error posted to the event log will state that the source architecture is not the same as that of the destination server.

You can recover from the printer restore error on the destination server by manually installing (or reinstalling) the appropriate standard driver for the migrated printer(s) running on that architecture.

If you encounter a failure in the Print Spooler service during print server migration, you can work around the failure. Using policy settings, you can isolate print drivers in separate processes so that print driver failures will not cause the Print Spooler service to fail—which allows the restoration to continue.

To turn on print driver isolation using Group Policy

Open the Group Policy Management Console. Right-click a Group Policy Object with the necessary scope, and then click Edit.

In the console tree under Computer Configuration, expand the Administrative Templates folder, and then expand the Printers folder.