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
Nice post. Will be really handy in x86-x64 migration scenarios.
Thanks for sharing
Hi, I have found that instead of using
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>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup 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.
Would you be willing to share your modified script Rob and the basic steps in your MDT TS that you used to achieve this?
Hi Damon, I have set it up basically as a four step process.
Step 1 is to create a deployment task sequence. I based mine on the Client.xml template, and right down the bottom, I added a "Run Command Line" task that runs:
Step 2 is to create the ZTI_Custom_Copy_Printer_Remap_Script.wsf script in the %SCRIPTROOT% folder that contains this code:
Step 3 is to create the ZTI_Custom_Remap_Printers_To_Print_Queues.vbs script in the %SCRIPTROOT% folder that contains the below code. This is the script that is copied to each StartUp folder within each profile on the new computer:
Finally in step 4, create your new printer queues on the new server, then create a text file called ZTI_Custom_Remap_Printers_To_Print_Queues_Reconnection_Map.txt in the %SCRIPTROOT% folder, that has contents like the following, with the old and new printers being separated by a semi-colon:
So, what happens when the task sequence runs, the VBS is copied to the StartUp folder for each user (C:\Users\%username%\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup) and the TXT is copied to the Temp folder for each user (C:\Users\%username%\AppData\Local\Temp). When the user logs in, the VBS runs and deletes itself, and you will find a log of its actions in the %TEMP% folder per user as well.
Thanks Rob, appreciate your response. Your post is exactly what I was after.
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.