Hello,
many people asked on newsgroup how to migrate from a printer server to another, without manual intervention off course.
1/Migrate drivers and declared printer with print migrator from Microsoft:
2/
Use the following simple vbscript. Jut replace MYNEWPRINTERSERVER with the new print server name.
You may call it with cscript to not send popup, or remove wscript.echo to not warn user.
The best way is during logon script
The new print server must be already online and ready, as it removes the current printer and map again on the new print server
You can download here:
http://gollum123.free.fr/printermigrator.vbs
here is the code source:
----------------------------------------------
On Error Resume Next
Function GetDefaultPrinter()
sRegVal = "HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows\Device"
sDefault = ""
On Error Resume Next
sDefault = objShell.RegRead(sRegVal)
sDefault = Left(sDefault ,InStr(sDefault, ",") - 1)
On Error Goto 0
GetDefaultPrinter = sDefault
End Function
Set objNetwork = CreateObject ("Wscript.Network")
Set objShell = CreateObject ("WScript.Shell")
Set objFSO = CreateObject ("Scripting.FileSystemObject")
LogonServer = objShell.ExpandEnvironmentStrings("%logonserver%")
UserName = objShell.ExpandEnvironmentStrings("%username%")
strComputer = "."
PrintServer = "MYNEWPRINTERSERVER"
PrintServer = LCase (PrintServer)
Err.Clear
Set objWMIService = GetObject("winmgmts:" & _
"{impersonationLevel=Impersonate}!\\" & strComputer & "\root\cimv2")
If Err.Number Then
wscript.echo ("Error : " & Err.Number & ": " & Err.Description & VbCrLf)
Err.Clear
Else
ImpDefault = GetDefaultPrinter
Set colInstalledPrinters = objWMIService.ExecQuery _
("SELECT * FROM Win32_Printer")
For Each objPrinter in colInstalledPrinters
PrinterArray = Split (objPrinter.Name , "\")
If (LCase(objPrinter.ServerName) <> "") and (LCase(objPrinter.ServerName) <> "\\" & PrintServer) then
objNetwork.AddWindowsPrinterConnection "\\" & PrintServer & "\" & PrinterArray(3)
If Err.Number Then
wscript.echo ("Error : " & Err.Number & ": " & Err.Description & VbCrLf)
Err.Clear
End If
If ImpDefault = objPrinter.Name then
objNetwork.SetDefaultPrinter ("\\" & PrintServer & "\" & PrinterArray(3))
End If
objNetwork.RemovePrinterConnection objPrinter.Name
End If
Next
End If
-------------------
8 comments:
Sure thing, Print Migrator 3.1 despite the fact that it looks a bit outdated being issued back 4 years ago it still remains a good tool to move the print configuration data form one server to another. I, however, would note that it requires a clear understanding of what you want to do with it and I highly recommend you consider a thorough printer migration process planning before you do anything with it. It's a nice tool but requires doing all things with a maximum accuracy. Pay attention to what drivers you will be migrating, what drivers you have already deployed to the destination server and which of them may cause conflicts. While printer migration is a relatively simple process in theory, in practice it appears that when abused it may result in serious issues with all the print operations getting stuck across your company. First off, revise all the printer naming checking whether you would face with port and printer share collisions. On the paper it sounds pretty easy but for the large organization with multiple groups and OUs in Active Directory and several buildings or even branches like with our company it eventually may become a really complicated task. For example it is known that several port monitors may share the same port names. The ports are sorted in alphabetically what means that the process works in the FIFO mode. Thus, if you have ports sharing the same name but using different port monitors, all those ports that are linked to the port monitor with highest queue numbers (remember the number is directly connected with the sorting which is performed alphabetically) will be dropped from the connection. But the most confusing thing is the printer share names collision. Should this happen to you, neither of the printers will be shared. Having only the poor log-which by the way is located in the %systemroot%\system32\spool\pm\ folder-resolving the migration problem or misconfiguration conflicts may become a delving task. By the way, there's how it is possible to migrate print servers using the command line Think twice before setting up third-party drivers when using PMT to migrate printers.
By the way, since you are talking about scripting this procedure, here's the trick how you can get all the data from the print queues. You need to use the Win32_Printer WMI provider class: Set PrintCollection = objWMIService.ExecQuery("Select * from Win32_Printer Where Network ='False'")
To delve a little more into this topic, I'll recommend reading to the nice 'Print Server Migration' article by Michael Strong published something about this time when the PMT 3.1 was issued on MS site.
For myself, I have chosen the way to operate with all the procedures connected with configuring printers on my domain computers. I am using desktop management tool from Scriptlogic. Their Desktop Authority is a great helper in such situations. It allows you to manage and propagate printer settings on all machines within the domain from the central console. Since it's fully integrated with the KIX scripting environment it allows making accurate post- or predeployment configuration changes. But the most interesting thing there is it's ability to configure printers geographically or better to say address-wise. For example, we have several units in our company where the groups of people are working on different floors. Some of them, though are working in different offices which are located cross-town. This all creates a situation when I cannot manage user printer configuration manually and I cannot rely on non-guaranteed delivery of printing functionality to the users. Actually I would have been impossible for me to quickly move between the buildings even though we have personnel in that remote office. I found out that it's usually far more effective to configure setting centrally from one location rather then delegate rights for the guys in the other office. With Desktop Authority I can define from one console which printers will be deployed to which user. I even can configure the settings in that manner that each user will get the closest printer connected to his workstation. That all serves for standardizing and easy controlling printing throughout the company. What's more, I really like its reporting features which can log what's happened with handling configuration settings on the client computer and fix it in the real-time mode using the remote management functionality.
Is there a way to do this with file shares?
Basically I want to feed the script an "old server" name, and a "new server" name, and have the script update any mapped network drives with those server names.
I have a client with a lot of manual drive mappings... and I don't want to have to manually update them all :)
Hi Mathieu,
Can you please, post the printermigrator vbscript that you made last? The one which includes a folder where a log per username is created.
Thank you very much in advance,
Al
Thanks for the script, saved me today.
Can you please be more specific about what you need to change in this script and how those txt files should look like? I'm new with scripts so...
Thank you.
Hi Mathieu,
Not sure if i'm using the right way to execute the script.
I placed this script on a desktop to try, in cmd, i typed 'cscript printmigrator.vbs'
Nothing seems to happen, no error, no log files, but cscript process took up 100% of usgae and slowed down the entire system.
Did i miss some steps in between ?
Thanks a lot Mathieu! This saved a lot of time for me.
I tried the Technet link before and it didn't work for me.
Your script is pointing the printers to the new server however the default printer is not getting changed.
Any ideas?
Is there any way to add to this script that if the printer no longer exists to delete it?
Thanks in advance.
Post a Comment