How to deploy x86 and x64 universal printer drivers en-masse

I was recently asked to come up with a solution to update our entire print server esate (around 600 boxes) with univeral PCL6 and PS drivers over x86 and x64 architectures. Specifically in this case I was asked to update with Lexmark and HP drivers although I see no reason this solution shouldn’t extend to any other manufacturers.

Since we have SCCM, my immediate idea was to create a package and push all packages out to the servers concerned but I found some shortcomings when creating the driver packages. Lexmark provide a tool to create the packages but I found I was unable to install both x86 and x64 drivers on the same machine. In fact, the executable created for the x86 drivers just threw errors. For the HP drivers, I had to throw in a few command line switches but again it simply wouldn’t install both architectures of driver. I should point out that the print server I was using for the test was Windows 2008 x64.

So another method was required. After much testing, I found the most reliable method was to use the Microsoft utility, prndrvr.vbs. This utility (along with several others) can be found under C:\Windows\System32\Printing_Admin_Scripts\en-US on the print server. I then deployed these using a task sequence in SCCM, running this utility with the drivers in question. Everything installs just fine and I don’t get any of the other rubbish which the manufacturer utilities include, such as extra printer objects, pre-configured ports etc. I have outlined what I did below for the HP drivers but remember, this should work for any print drivers.

  1. Download HP Universal Drivers package from the net. Create a folder called HPUniversalDrivers in C:\Temp on your test workstation. Create another folder inside called HPUPD. Copy xcopy.exe into this folder. Copy the 32bit and the 64bit folders out of the HP Universal Drivers package into C:\Temp\HPUniversalDrivers\HPUPD. Finally copy prndrvr.vbs into C:\Temp\HPUniversalDrivers\HPUPD. Your HPUPD folder should now contain two folders (32bit and 64bit) and the vbs script.
  2. Create a package in SCCM pointing the source to the location we have just described on your test box, eg \\testbox\C$\temp\HPUniversalDrivers, create a distribution point and update it. You don’t need a program.
  3. Create a new custom task sequenceSelect General > Run Command Line: NAME=Copy HP Drivers Locally, Command Line=xcopy “HPUPD” “C:\Temp\HPUPD\” /E /Y, select the ‘package’ checkbox and browse to your HP driver package you created earlier. OK
  4. Decide which driver version you require. You may have to dig about in the .inf files to find the one for your particular requirements but for the purposes of this blog I required v5.4 which could be found in hpcu118d.inf: 
    • Create a new custom task sequenceSelect General > Run Command Line: NAME=HP UPD PS v5.4 x86, Command Line=cscript prndrvr.vbs -a -m “HP Universal Printing PS (v5.4)” -e “Windows NT x86” -i “C:\Temp\HPUPD\32bit\PS\hpcu118d.inf” -h “C:\Temp\HPUPD\32bit\PS”, Start in:= C:\Temp\HPUPD
    • Create a new custom task sequenceSelect General > Run Command Line: NAME=HP UPD PCL6 v5.4 x86, Command Line=cscript prndrvr.vbs -a -m “HP Universal Printing PCL 6 (v5.4)” -e “Windows NT x86” -i “C:\Temp\HPUPD\32bit\PCL6\hpcu118c.inf” -h “C:\Temp\HPUPD\32bit\PCL6”, Start in:= C:\Temp\HPUPD
    • Create a new custom task sequenceSelect General > Run Command Line: NAME=HP UPD PS v5.4 x64, Command Line=cscript prndrvr.vbs -a -m “HP Universal Printing PS (v5.4)” -e “Windows x64” -i “C:\Temp\HPUPD\64bit\PS\hpcu118v.inf” -h “C:\Temp\HPUPD\64bit\PS”, Start in:= C:\Temp\HPUPD
    • Create a new custom task sequenceSelect General > Run Command Line: NAME=HP UPD PS v5.4 x64, Command Line=cscript prndrvr.vbs -a -m “HP Universal Printing PCL 6 (v5.4)” -e “Windows x64” -i “C:\Temp\HPUPD\64bit\PCL6\hpcu118u.inf” -h “C:\Temp\HPUPD\64bit\PCL6”, Start in:= C:\Temp\HPUPD
    • Create a new custom task sequenceSelect General > Run Command Line: NAME=Remove HP Directory, Command Line=cmd.exe /c RD C:\Temp\HPUPD /S /Q
  5. Your task sequence is now complete. Next, create a collection and add the print server of your choice to the collection. Advertise the task sequence to the collection and you should be good to go. This example will install both x86 and x64 drivers, PS and PCL6.

Print Drivers

Disclaimer: I am in no way responsible if you accidentally deploy something nasty to your whole estate. Please test responsibly before deployment!

Connection to Hyper-V VMs are very slow from remote Windows clients

So you have your Hyper-V box set up along with several virtual servers. Communication between Hyper-V host and VMs is fine. However when a remote Windows client tries to browse for a share on a VM there is a very long delay (sometimes minutes) before the share is displayed.

This problem had me puzzled for a fair while. Fortunately it was only in my lab environment but it was still frustrating. My network was IPv4. What I needed to do was to disable most of the advanced properties under the virtual network adapter on the Hyper-V host. Unless you have a IPv6 network you can leave the IPv6 settings as they are. After I’d disabled all these settings I was able to successfully browse shares properly.

RDP stops working for XP clients trying to remote to Windows 7 clients after applying Win7-EC-Desktop baseline policy

Sorry, not the catchiest of titles but it does what it says on the tin (unfortunately).

Essentially, following the application of the Microsoft-recommended Win7-EC-Desktop baseline hardening policy (this baseline and others can be found when you install Microsoft Security Compliance Manager solution accellerator) users on XP desktops are no longer able to reach those Windows 7 machines that are subject to this policy. Two weeks on the phone to Microsoft resulted only in various network monitor captures, procmon captures and general frustration. In the end it was simple. Instead of concentrating on the specific RDP changes made in the policy, it was to do with the new firewall settings.

Just change Allow the connection if it’s secure to Allow the connection:

UPDATE

An fix has been created by Microsoft which both myself and the original customer who raised the bug have recently beta tested and approved. A full KB article and the final approved release version will be made available from the Microsoft site around about the 13th November 2012.