By
Published
Apr 04 2019 05:46 PM
2,909
Views
First published on TechNet on May 24, 2011
Hi there folks, Ned here again. I've touched on USMT and printers before but it was a quick answer to a specific question in a Friday Mail Sack . Today I explain in detail how USMT migrates network-mapped printers and why it migrates nothing else. If you didn't understand this before, don’t worry… it's confusing as $&^%. :-)
We describe what USMT migrates here but we use some loose wording in this case: "Network printer mappings". Let's take the case of XP and what this means in practical USMT terms. There are only two USMT manifests for XP that mention printing:
When you examine these files you find that "PRINTING-SPOOLER-CORE-DL.MAN" migrates a few general settings about your client's spooler, which has nothing to do with individual printers. However, the "PRINTING-SPOOLER-NETWORKCLIENT-DL.MAN" file is much more interesting:
If you look at a computer where you have a connected network printer, this will line up nicely:
Oh yes, it's just that easy - whatever registry settings are here get copied. When your new Windows 7 computer connects to that print server, the driver will automatically download and you are back in business. The registry data for mapped network printers are just that - some pointers to a server who will do all the heavy lifting for you. Barely more than shortcuts, really.
But what about those other printers - the ones connected via LPT, local Plug-and-Play, COM , TCP, and LPR ports?
So you perform a test migration, restart the destination Windows 7 computer, and… eh. Only that network printer is migrated to the Devices and Printers applet.
Ah… but those were not the printer themselves - those DevModes2 entries are for printer preferences . That's why even the network printer is there: I had decided to print back to front, like a weirdo:
The actual printers for the Printers and Faxes applet are all stored - along with their driver, spooler, port, and other info - in a completely different registry key structure within:
And as you know now from examining that downlevel MAN file, USMT does not migrate those keys. And our practical repro reinforces this.
What about Windows 7 though? Now armed with the other registry keys, we can search through our manifests for those entries and see what we find:
Nothing there. How about the OS-included manifests?
Ah, sweet data (slightly snipped up for readability - all we care about is the latest version of each file).
The next step is to verify that these returned files care about USMT by looking for the string "USMT" that shows:
It turns out the first one (* microsoft-windows-remoteregistry-service *.manifest) doesn't contain this so it’s irrelevant. The next one (* microsoft-windows-printing-spooler-core *) does, but it's only concerned about:
Neither of those gets us all those other printers. Of the remaining ones, only these are for USMT:
The first one is for cluster printers (oh brother, how helpful that this is included for USMT), and the two others just reference what we've already seen so that Windows 7 can migrate those same network connected printers.
This is all by design – the printer developers who wrote these manifests for USMT don’t automatically migrate all these varieties of local printers intentionally , because they can’t guarantee drivers and architecture will be the same between computers. The same way we don’t migrate video card drivers or other hardware. Connections to Windows Print servers are safe as the client is updated with a driver when connecting to the printer queue; even if the driver doesn’t exist now on the client, it soon will.
As for other options: I'm not a printer guru, but we do have them. Our friends at the AskPerf blog spend much of their lives working on printer installation and migration issues . They tend to think that even network-mapped printers are a legacy of the past and that you should be doing things like Location Aware Printing , Active Directory Printing , and printer deployment using printui . If you talk to the Perf folks here through a support case, they will also bring up Group Policy based printer deployment or prnmgr.vbs . Between all these options, you can deploy network or local printers in automated fashions, regardless of USMT capabilities.
If you've already learned how to reverse engineer USMT behaviors no matter the component , you didn’t have to read this. You have transcended ordinary IT operations and now are a hot pepper-eating fire demon of awesomeness.
Until next time.
Ned "Please think of the paper mill employees and certified tree farmers, and print this blog" Pyle
Hi there folks, Ned here again. I've touched on USMT and printers before but it was a quick answer to a specific question in a Friday Mail Sack . Today I explain in detail how USMT migrates network-mapped printers and why it migrates nothing else. If you didn't understand this before, don’t worry… it's confusing as $&^%. :-)
The way it all works
We describe what USMT migrates here but we use some loose wording in this case: "Network printer mappings". Let's take the case of XP and what this means in practical USMT terms. There are only two USMT manifests for XP that mention printing:
C:\usmt\X86\DLMANIFESTS>findstr /i /m "printer" *.man
PRINTING-SPOOLER-CORE-DL.MAN
PRINTING-SPOOLER-NETWORKCLIENT-DL.MAN
When you examine these files you find that "PRINTING-SPOOLER-CORE-DL.MAN" migrates a few general settings about your client's spooler, which has nothing to do with individual printers. However, the "PRINTING-SPOOLER-NETWORKCLIENT-DL.MAN" file is much more interesting:
<rules context="User">
<include>
<objectSet>
<!--
DevModes2ListType.
-->
<pattern type="Registry">HKCU\ Printers \DevModes2 [\\*]</pattern>
<!--
ListOfPrinterConnection.
-->
<pattern type="Registry">HKCU\ Printers \Connections\* [*]</pattern>
</objectSet>
</include>
</rules>
If you look at a computer where you have a connected network printer, this will line up nicely:
Oh yes, it's just that easy - whatever registry settings are here get copied. When your new Windows 7 computer connects to that print server, the driver will automatically download and you are back in business. The registry data for mapped network printers are just that - some pointers to a server who will do all the heavy lifting for you. Barely more than shortcuts, really.
But what about those other printers - the ones connected via LPT, local Plug-and-Play, COM , TCP, and LPR ports?
So you perform a test migration, restart the destination Windows 7 computer, and… eh. Only that network printer is migrated to the Devices and Printers applet.
Ah… but those were not the printer themselves - those DevModes2 entries are for printer preferences . That's why even the network printer is there: I had decided to print back to front, like a weirdo:
The actual printers for the Printers and Faxes applet are all stored - along with their driver, spooler, port, and other info - in a completely different registry key structure within:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Print
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Print\Printers
HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Devices
And as you know now from examining that downlevel MAN file, USMT does not migrate those keys. And our practical repro reinforces this.
What about Windows 7 though? Now armed with the other registry keys, we can search through our manifests for those entries and see what we find:
C:\usmt\AMD64\ REPLACEMENTMANIFESTS >findstr /m /i "SYSTEM\CurrentControlSet\Printers" *.man
C:\usmt\AMD64\ REPLACEMENTMANIFESTS >findstr /m /i "Control\Print\Printers" *.man
C:\usmt\AMD64\ REPLACEMENTMANIFESTS >findstr /m /i "NT\CurrentVersion\Devices" *.man
Nothing there. How about the OS-included manifests?
C:\Windows\winsxs\ Manifests >findstr /m /i "Control\Print\Printers" *.manifest
amd64_microsoft-windows-remoteregistry-service_31bf3856ad364e35_6.1.7600.16385_none_e55af7609d2857a8.manifest
C:\Windows\winsxs\ Manifests >findstr /m /i "NT\CurrentVersion\Devices" *.manifest
amd64_microsoft-windows-printing-spooler-core_31bf3856ad364e35_6.1.7601.17514_none_3471a890d8284f57.manifest
C:\Windows\winsxs\ Manifests >findstr /m /i "CurrentVersion\Print" *.manifest
amd64_microsoft-windows-fax-common_31bf3856ad364e35_6.1.7601.17514_none_6a2ab458674011dc.manifest
amd64_microsoft-windows-p..-localprinting-home_31bf3856ad364e35_6.1.7600.16385_none_93a1ff364af0f5eb.manifest
amd64_microsoft-windows-p..g-xpsdocumentwriter_31bf3856ad364e35_6.1.7601.17514_none_80fea45979a5d3f2.manifest
amd64_microsoft-windows-p..ooler-core-localspl_31bf3856ad364e35_6.1.7601.17514_none_8e41636aa94da31c.manifest
amd64_microsoft-windows-p..ooler-networkclient_31bf3856ad364e35_6.1.7601.17514_none_9799402887898e33.manifest
amd64_microsoft-windows-printing-spooler-core_31bf3856ad364e35_6.1.7601.17514_none_3471a890d8284f57.manifest
amd64_microsoft-windows-remoteregistry-service_31bf3856ad364e35_6.1.7600.16385_none_e55af7609d2857a8.manifest
Ah, sweet data (slightly snipped up for readability - all we care about is the latest version of each file).
The next step is to verify that these returned files care about USMT by looking for the string "USMT" that shows:
<migration scope="Upgrade,MigWiz,USMT"
It turns out the first one (* microsoft-windows-remoteregistry-service *.manifest) doesn't contain this so it’s irrelevant. The next one (* microsoft-windows-printing-spooler-core *) does, but it's only concerned about:
<merge script="MigXmlHelper.SourcePriority()">
<objectSet>
<pattern type="Registry">HKLM\SYSTEM\CurrentControlSet\Control\Print\Providers [*]</pattern>
<pattern type="Registry">HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Printers [DefaultSpoolDirectory]</pattern>
</objectSet>
</merge>
Neither of those gets us all those other printers. Of the remaining ones, only these are for USMT:
*microsoft-windows-p..ooler-core-localspl*
*microsoft-windows-p..ooler-networkclient*
*microsoft-windows-printing-spooler-core*
The first one is for cluster printers (oh brother, how helpful that this is included for USMT), and the two others just reference what we've already seen so that Windows 7 can migrate those same network connected printers.
Why? And now what do I do?
This is all by design – the printer developers who wrote these manifests for USMT don’t automatically migrate all these varieties of local printers intentionally , because they can’t guarantee drivers and architecture will be the same between computers. The same way we don’t migrate video card drivers or other hardware. Connections to Windows Print servers are safe as the client is updated with a driver when connecting to the printer queue; even if the driver doesn’t exist now on the client, it soon will.
As for other options: I'm not a printer guru, but we do have them. Our friends at the AskPerf blog spend much of their lives working on printer installation and migration issues . They tend to think that even network-mapped printers are a legacy of the past and that you should be doing things like Location Aware Printing , Active Directory Printing , and printer deployment using printui . If you talk to the Perf folks here through a support case, they will also bring up Group Policy based printer deployment or prnmgr.vbs . Between all these options, you can deploy network or local printers in automated fashions, regardless of USMT capabilities.
A final note
If you've already learned how to reverse engineer USMT behaviors no matter the component , you didn’t have to read this. You have transcended ordinary IT operations and now are a hot pepper-eating fire demon of awesomeness.
Until next time.
Ned "Please think of the paper mill employees and certified tree farmers, and print this blog" Pyle