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
Comments
Anonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
Hi, I have found that instead of using StrKeyFullPath=strKeyPath&""&Subkey objReg.DeleteKey HKEY_CURRENT_USER,StrKeyFullPath it is better to use objNetwork.RemovePrinterConnection Replace(strSubKey, ",", ""), True, True since this removes the printer connection properly. Otherwise, the connection still appears under Devices and Printers. I have now combined a modified version of this script into a post LoadState task in my MDT Task Sequence, which places itself in the C:Users<username>AppDataRoamingMicrosoftWindowsStart MenuProgramsStartup folder by enumerating the Users folder, and creating the Startup folder. This way, it runs when the user logs in, and reconnects their printers, and remove the old ones.Anonymous
January 01, 2003
Thanks Rob, appreciate your response. Your post is exactly what I was after. Cheers DamonAnonymous
January 01, 2003
Thanks for sharingAnonymous
January 01, 2003
No problem. I also found the same approach to be helpful in situations where you need to apply other "current user" settings as well. I have the step 2 script copy some other scripts to the StartUp folder that apply 64 bit user specific settings (for when HLKM doesn't cut it) for specific applications. Glad it helped.Anonymous
January 01, 2003
Would you be willing to share your modified script Rob and the basic steps in your MDT TS that you used to achieve this?Anonymous
February 12, 2013
Nice post. Will be really handy in x86-x64 migration scenarios.Anonymous
May 13, 2014
Pingback from Printer Remapping in Windows 7 Deployments | What have I learnt today?Anonymous
September 24, 2015
Hello @RobSampson...
I changed the suggested lines that you listed above with changing:
StrKeyFullPath=strKeyPath&""&Subkey
objReg.DeleteKey HKEY_CURRENT_USER,StrKeyFullPath
TO
objNetwork.RemovePrinterConnection Replace(strSubKey, ",", ""), True, True
AND
I get the following error: "Variable is undefined: 'strSubKey' - Code: 800A01F4
Is there something I overlooked!? Otherwise, the script works GREAT! The ability to remove the old printers would be phenomenal!Anonymous
February 15, 2016
The comment has been removedAnonymous
February 26, 2016
Charles Waters:
The variable should should be SubKey, not strSubKey, i.e.
objNetwork.RemovePrinterConnection Replace(SubKey, ",", ""), True, True
I also replaced all uses of ucase() with lcase() to make printer names look prettier.Anonymous
March 01, 2016
The comment has been removed