Updated: July 18, 2012
Applies To: Windows Server 2012
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.
The next section provides tasks that should be completed after you have successfully migrated the source printer server.
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.
Rename source and destination servers as directed in Verifying the Migration.
Follow your enterprise’s normal policy for server decommissioning and retirement until retirement of the source server is complete.
If the destination server has already been published in Active Directory Domain Services (AD DS), then the source server must be unpublished.
The next section provides tasks that should be completed if your migration of the source printer server did not succeede.
Restoring the source server lets you deploy the settings to a new system or use the source server while determining the cause of the failure.
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.
Rename the source server to its original, pre-migration name. You might have to rename the destination server to a temporary name first.
Rename the destination server, either to its original name, or to another name that is not the same as the original name of the source server.
The following sections can help you troubleshoot any migration issues.
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.
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.
Double-click Execute print drivers in isolated processes.
Click Enabled, and then click OK.
Double-click Override print driver execution compatibility setting reported by print driver.
Click Enabled, and then click OK.
At a command prompt, type gpupdate /force to reapply Group Policy settings.
Windows PowerShell Blog (http://go.microsoft.com/fwlink/?LinkId=128557)