How it works...

The .NET Framework's System.Printing namespace contains some useful printing-related classes and enums, some of which you use in this recipe. PowerShell does not load this namespace by default. You load it in step 1, using the Add-Type cmdlet, which produces no output.

In step 2, you create a variable, $Permissions, that holds the print permissions you need-namely the ability to administer the print server. In step 3, you instantiate a PrintServer object with the permission to administer the print server. These permissions are separate from normal administrative privileges. Even running the commands in an elevated PowerShell console requires you to create permissions, as you can see here.

In step 4, you change the Spool folder to the in-memory PrintServer object, and then in step 5, you commit the update. In step 6, you restart the Spooler, and then, in step 7, observe the results from changing the Spooler folder. The output from step 6 and step 7 looks like this:

The second and simpler method involves just updating the registry value entry that holds the spool folder name (and restarting the Spooler). To do this, in step 8, you stop the Spooler, and in step 9, you update the registry value that the Spooler system uses for its spool folder. Note that you do not have to do steps 1-7 to use the second method!

In step 10, you restart the Spooler service, which now uses the new Spool folder. Finally, in step 11, you view the results of changing the Spool folder, which looks like this:

Note that the two methods you use in this recipe use different folder names for illustration. The folder name may not be appropriate for your installation. In production, you should also consider moving the Spool folder to a separate volume to avoid running out of space on the system volume.

This recipe makes use of the underlying .NET System.Printing namespace instead of just commands from the PrintManagement modules. This approach has value in many other places inside Windows. In general, the advice is to use cmdlets where/when you can and only then dip down into either the .NET Framework or the CIM/WMI namespaces and classes.