Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

For reasons unknown, a great many of the (Windows XP SP3) computers I manage have recently started creating a new pseudoprinter object, called Microsoft XPS Document Writer, seemingly out of nowhere.

This is a problem, because for some users (created through Dynamic Local User via ZENworks) the XPS document writer is being set as the default printer!

When I made the image for these machines, I made sure to delete this pseudoprinter object from the Printers and Faxes area. I would first like to know what is causing it to be recreated recently, over a year later.

I found a tool for removing the pseudoprinter object, its driver, and some other associated things. The trouble is, it's a GUI-only application, and requires user interaction.

I would love a utility like this that just deletes the pseudoprinter object, driver, etc., without user interaction, so it can be run from the login script.

Failing that, I need to know exactly how to manually perform each of the steps that the XPS Removal Tool performs, and then script them. Ugh!

Any help would be greatly appreciated!

share|improve this question

6 Answers 6

up vote 6 down vote accepted
+75

For reasons unknown, a great many of the (Windows XP SP3) computers I manage have recently started creating a new pseudoprinter object, called Microsoft XPS Document Writer, seemingly out of nowhere.

If I read things correctly the original version of XPS Document Writer and related components for Windows XP shipped as part of .NET Framework 3.0, see for example Viewing and creating XPS documents. Consequently I suppose the reason why these components do appear on those systems to be an explicit or implicit installation of .NET Framework 3.0, e.g. triggered by another software which depends on it.

I would love a utility like this that just deletes the pseudoprinter object, driver, etc., without user interaction, so it can be run from the login script.

Presumably this installation is based on Windows Installer under the hood, which features proper uninstall functionality for system administrators by design, even in the absence of an explicit Add/Remove Program entry for end users, see Standard Installer Command-Line Options (also shown if executing msiexec /? on a command line), for example:

msiexec /uninstall /quiet YourInstallationPackage.msi
msiexec /uninstall /quiet {12345678-1234-1234-1234-123456789012}

Consequently there are some constraints though:

  • The functionality to be uninstalled must have been provided as a Windows Installer package (.msi) in the first place of course, even if this package has in turn been bundled/packed within another entity, e.g. the .NET Framework installer; this may not necessarily be the case, even though I'd be surprised if not.
  • As shown you'll either need access to the original installation package (.msi), which is usually getting cached on the system for purposes like this, or you'll need the so called ProductCode of the package as recorded in the system wide Windows Installer database.

This is where things get tricky (and potentially dangerous) regarding your example, because you'll need to find either one of these on your system:
The Windows Installer cache is usually located in C:\Windows\Installer, the Windows Installer product codes are registered under HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall. Obviously you'll first need some term to look for (e.g. 'XPS') and for every find you should definitely verify whether it actually denotes the package you are looking for, else you might end up accidentally removing important stuff.


Alternative approach:

Apparently the Microsoft XML Paper Specification Essentials Pack is an update to those bits delivered via .NET Framework 3.0 (see this article). Given this is an official Windows installer package, the uninstallation as outlined above should definitely work. I peaked into the package via Orca, and not surprisingly it seems to include custom actions for uninstalling older components if present. Consequently you may be able to install this package first, implying removal of the bits installed via the .NET Framework, and immediately uninstall it again thereafter to get rid of XPS functionality entirely:

msiexec /install /quiet 'XPSEP XP and Server 2003 32 bit.msi'
msiexec /uninstall /quiet 'XPSEP XP and Server 2003 32 bit.msi'

It definitely seems odd to install more stuff first, and it might or might not work, but in the end it may be simpler and hence worth a try.

share|improve this answer
    
Thanks! The alternative approach you listed appears to be the most straightforward. I will give it a try over the next couple of days and let you know whether or not it works out. –  eleven81 Sep 2 '09 at 19:49

Run this as a startup script

Cscript %WINDIR%\System32\prnmngr.vbs -d -p "Microsoft XPS Document Writer"
share|improve this answer
    
Thanks! This is definitely a start. However, I really would like to duplicate all of the things that the XPS Removal Tool does, not just delete the printer object every time a user logs in. –  eleven81 Aug 27 '09 at 21:35

Here's an idea for you. If you use Symantec Ghost, you could always create an AI install for it. If you're not familiar with the process, it takes an image of the computer, you run the install or script, it takes another image, then creates an executable that does all the changes. The only time it gets weird is if there's a reboot required in the middle, otherwise it works great.

share|improve this answer
    
Thanks! We use ZENworks Imaging Server for imaging, and none of the computers are in the freshly-imaged state, so an add-on image is not an option. –  eleven81 Aug 31 '09 at 20:15

if you email the guys that made the tool they have a command line tool too

share|improve this answer
    
Thanks! I've done this, but they want 50 bucks for the tool and 100 bucks for the source code. Two problems persist: first, they are not an "approved vendor" and we cannot purchase from them; second, our budget for this fiscal year is zero dollars. It can't be that difficult. –  eleven81 Sep 4 '09 at 13:24

Here's an article that discusses how to remove the XPS Document Writer by adding a few lines to the user login script.

Essentially you just at -

c:

cd \windows\system32\

cscript prnmngr.vbs -d -p "Microsoft XPS Document Writer"

Once you confirm that all users have logged in and executed the above commands you can remove the lines from the login script.

Here is a link to the complete article -

For SysAds: Removing "XPS Document Writer" by Greg Martin

share|improve this answer
    
Thanks! But, the idea "Once you confirm that all users have logged in and executed the above commands" is unworkable as new users are created through Dynamic Local User via ZENworks. –  eleven81 Sep 9 '09 at 12:39

I don't see the problem now. You have the command to delete the XPS printer in the loginscript. If the object is there, the script will delete it, if not it will exit. Job done, surely?

Bizarely I am fighting to install this critter cleanly, but that's another story.

Mike

share|improve this answer
    
To clarify, I wanted something to run once on every machine to be sure the printer object doesn't get installed again after another errant Windows Update or for any other reason. I don't want to run something every time any DLU user logs in, for the rest of all time, just to fix Microsoft's shortsightedness. It it all clear now, or clear as mud? –  eleven81 Sep 25 '09 at 13:27

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.