Printer Remapping in Windows 7 Deployments
One of the challenges that I frequently come across is the shift from 32-bit operating system environments to 64-bit operating system environment during deployment projects. Windows 7 ships as both 32-bit as well as 64-Bit, with the 64-bit version becoming more popular due to its ability to handle large amounts of RAM and the wider availability of OEM 64-bit drivers.
With this in mind, most customer we see are moving from Windows XP 32-bit to Windows 7 64-bit and as part of the effort of migrating we often see a need to migrate their printing infrastructure into a 64-bit compatible printing infrastructure.
This introduces challenges around the migration of existing printers configured on the windows XP 32-bit environment. The User State Migration tool (USMT) is the great tool for migrating the user’s data and settings and it also helps migrating the network printers, but USMT does not takes care of the new print queues.
To begin - lets examine how USMT handles network printers.
During the USMT scan state phase USMT scans the HKCU\Printer\Connection registry keys and values and during the restore phase it restore the HKCU\Printer\Connection registry keys and values. Once the Print Spooler services get started it validates the network printer connection and then it makes the network printer visible under Devices and Printers within the operating system.
In order to migrate network printers to a new queue, a scripted solution can be used which takes care of remapping the network printers. The challenging part in the solution is around using System Center Configuration Manager 2007 or System Center 2012 Configuration Manager. Because printers are populated per user, and the task sequence runs under the system context, any scripted solution that runs from the task sequence will not be able to find printers for any specific users. Moreover when the tasks sequence is running in the system context, it would not have access to HKCU.
Because of these challenges, a scripted solution need to be run with the user’s rights – which allows for two options
1. Run the scripted solution via Group Policy Object(s) (GPO
2. Inserting a run once registry values (If there is only one primary user associated with the machine) to run the scripted solution at user logon.
Each of these deployment methods has its own pros and cons. Typically, a customer environment has PCs which in most part are used by a single user – the preference would be to add the run once registry value as part of the deployment task sequence as the last step or finish action in the task sequence.
The script solution provided below is a solution that was developed to be deployed via the run once registry value. The script solution provides the ability to map old to new printer queues in a text file (PrintRemap.txt) which is then consumed by the PrintRemapRegistry script to make the changes.
The PrintRemapRegistry script creates a log file under %Temp%\PrinterRemap_<ComputerName>.log which logs all the events. This log will also let you know if there is no mapping found. This script will not touch existing print queues unless they are listed in the printRemap.txt
This post was contributed by Kaushal Pandey (Guest Blogger), an Associate Consultant with Microsoft Global Delivery
Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use