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 (12)

  1. RobSampson says:

    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:

    cscript.exe "%SCRIPTROOT%ZTI_Custom_Copy_Printer_Remap_Script.wsf"

    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%AppDataRoamingMicrosoftWindowsStart MenuProgramsStartup) and the TXT is copied to the Temp folder for each user (C:Users%username%AppDataLocalTemp).
     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.


  2. RobSampson says:

    Hi, I have found that instead of using


                        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.

  3. Anonymous says:

    Thanks Rob, appreciate your response. Your post is exactly what I was after.



  4. RobSampson says:

    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.

  5. Anonymous says:

    Would you be willing to share your modified script Rob and the basic steps in your MDT TS that you used to achieve this?

  6. Mohammed Imran says:

    Nice post. Will be really handy in x86-x64 migration scenarios.

  7. Anonymous says:

    Pingback from Printer Remapping in Windows 7 Deployments | What have I learnt today?

  8. Charles Waters says:

    Hello @RobSampson…

    I changed the suggested lines that you listed above with changing:

    objReg.DeleteKey HKEY_CURRENT_USER,StrKeyFullPath


    objNetwork.RemovePrinterConnection Replace(strSubKey, ",", ""), True, True


    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!

  9. RobSampson says:

    @NPares, sorry for this super late reply!
    If you are removing DomainB printers, and replacing them with DomainA servers, your syntax would be:
    \PrintServer1.DomainB.comPrinter1 ; \PrintServer001.DomainA.COMPrinter1

    but this may depend on the format you should see in
    You will need to match that DomainB printer name for your first part before the semi-colon, and just to be sure, connect a DomainA printer, then see what that naming is like as well, for the second part after the semi-colon

    @Charles Waters
    You will have a line just a few lines above that one you changed, that reads
    For Each strSubKey In arrSubKeys

    so you need to make sure strSubKey on that line matches your new line variable.

    But you may also have Option Explicit at the top of the code, in which case you will need to add
    Dim strSubKey
    before you use that variable as well.


  10. Urist says:

    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.

  11. RobSampson says:

    Hi, I'm not sure what happened here, I posted a reply a few months ago, but it never got published….

    I'll try again.


    You would be best to manually connect to a printer in each domain, then have a look at HKCUPrintersConnections, and see what the domain paths are. The script should match up those when it is reading the currently connected printers, and replace them accordingly.

    For undefined variables…did you put Option Explicit at the top of the script? You may need to add
    Dim strSubKey

    above that line that provides the error (and any more "undefined" errors you get as well.