Deploying printers using Group Policy

November 8, 2009

Traditionally printer connections have been deployed to users with scripting, like batch (net use) and Kixtart (AddPrinterConnection).

I would now like to show how printer connections can be deployed using Group Policy. Today we have 2 possible solutions for natively deploy printers using Group Policy without the need for any scripting:

1) Group Policy Preferences – available in Windows Server 2008 and later

2) Print Management – available in Windows Server 2003 R2 and later

Using Group Policy Preferences to deploy printers are described in an earlier blog post, available here. Therefore, I won`t explain any further details regarding this.

I will focus on the Print Management which has a powerful “Deploy with Group Policy” feature.

Configure printer deployment on

print servers

To use the “Deploy with Group Policy” feature, you need to install the “Print Management Component” feature from “Add/Remove Windows Components” in Windows Server 2003 R2. In Windows Server 2008/2008 R2 you need to install the “Print Server”-role from the “Add Roles Wizard”.

When installed, you`ll find “Print Management” under “Administrative tools” on the Start menu:

image

The following screenshots are taken from Windows Server 2008 R2.

When you open the Print Management Console you will see an overview of Custom Filters, Print Server and Deployed Printers:

image

You may add additional filters and print servers to the console, which you can read more about in the links in the bottom of this post. For now, we`ll focus on the printer deployment part.

Right-click the printer you want to deploy, and select “Deploy with Group Policy”:

image

Select “Browse” to choose a Group Policy Object where the printer connection will be deployed. Select “per user” and/or “per machine” and press “Add”. Then click “OK”:

image

You should now receive a message stating that the deployment operation was successful. Click “OK”:

image 

The printer will now be deployed to client computers.

 

Behind the scenes

To understand how the print deployment feature works, we`ll activate the “Advanced Features” option on the “View”-menu in “Active Directory Users and Computers”:

image

Open the “Group Policy Management Console”, go to the Group Policy Object you deployed the printer to, and select “Details”:

image

Note the “Unique ID” (GUID).

Back in ADUC, expand “System” and then “Policies”:

image

This is where the actual Group Policy Objects in Active Directory are stored, in addition to \\domain.local\sysvol\policies.

Find and expand the Group Policy Object you deployed the printer to. You will now see “PushedPrinterConnections” under the “Machine” and “User” nodes:

image

When looking at “PushedPrinterConnections” under the “User” node, we see an entry of type “msPrint-ConnectionPolicy”:

image

When we go into “Properties” on the “msPrint-ConnectionPolicy” and go to “Attribute Editor”, we can see that this represents the printer connection we added:

image

Deployment to client computers

Client computers running Windows Vista and later have native support for the new printer connection policies, and will work “out-of-the-box” when printer connections are added to a Group Policy.

Client computers running Windows 2000 and Windows XP doesn`t support the the new printer connection policies natively. To resolve this, there are a utility called “pushprinterconnections.exe” which must be added to a logonscript in Group Policy. This utility will check the computer and user Group Policy Objects and add any printer connections defined.

This utility have 1 parameter: –log. This is useful when troubleshooting problems, and I would recommend you to use this parameter. As you can see, the utility should not be run manually from the command line:

image

Here is an example of the utility added to a logon-script in a Group Policy Object:

image

The log-files are named “ppcUser.log” and “ppcComputer.log”. These are located in the %temp% directory:

image

Here is an example output of the logfile:

image

In Windows 2000 and Windows XP, no other feedback than these log-files are provided.

In Windows Vista/Windows Server 2008 and later, the following feedback are shown during logon:

image

In addition, any failures are logged to the “Application”-log with Source “SpoolerSpoolss”.

Special considerations

Windows 2000 supports only “per machine” deployments when using the pushprinterconnections.exe utility.

The pushprinterconnections.exe utility won`t catch “per user” connection policies when using “User Group Policy loopback processing”. You must link the GPO containing the “per user” connection policies to an Organizational Unit where the users reside.

Use ACL`s  on the printer objects on the print servers to publish the printers based on group membership. By using this approach, all printer connections may be defined in the same Group Policy Object.

My recommendations

As I said in the introduction to this post, printer connections have traditionally been deployed to users with scripting. Since there are native ways to accomplish this using Group Policy, this would be my recommendation.

Considerations for using the “Deploy with Group Policy” feature in the print server role:

-the print administrator would have an overview over all printers which are deployed with the Print Management Group Policy feature in the Print Management console
-printers can be administered in an individual GPO like GP Preferences with the Print Management console. To do so, open Group Policy Editor, expand Computer Configuration/User Configuration->Policies->Windows Settings->Deployed Printers
-it requires that pushprinterconnections.exe are run on Windows XP and Windows Server 2003 clients
-it is available with Windows XP/Windows Server 2003 R2 and later (backwards compatible to Windows 2000 Professional/2000 Server)
-it requires Windows Server 2003 Client Access Licenses (CALs)

Considerations for using Group Policy Preferences:

-it can handle more different printer types (local, TCP/IP, and shared instead of only “shared”)
-it has several additional options (deleting all existing connections, setting default printer, etc.)
-it can save a lot of GPOs because you can have many printer objects in one GPO and use “Item Level Targeting” to address each printer individually (e.g. clients in a specific IP-range, per group or even per user)
-it is easy to automate the process of adding printer objects to a GPO using Windows PowerShell, since the GP Preferences settings are store in XML-files
-it requires that Group Policy Client Side Extenstions are deployed on Windows XP and Windows Server 2003 clients
-it is available with Windows Vista/Windows Server 2008 and later (backwards compatible to Windows XP/2003 Server)
-it requires Windows Server 2008 Client Access Licenses (CALs)

 

Resource links

Step-by-Step Guide for Print Management
(Applies To: Windows Server 2003 R2)

Print Management Step-by-Step Guide
Applies To: Windows Server 2008

Print Management
(Applies To: Windows 7, Windows Server 2008 R2, Windows Vista)

Deploy the PushPrinterConnections.exe Utility


Bulk-create printer objects on print servers using Windows PowerShell

November 7, 2009

When installing a new print-server with several hundreds or thousands of printer objects there arent`t too much fun doing this manually.

Here are 3 steps to automate this process:

1) Install all the necessary printer drivers on the printserver

2) Create a csv-file with a listing of all printer objects and their properties

3) Bulk-import the printer objects using a script

For the 3rd step I`ve created a basic Windows PowerShell script, available on PoshCode.org from this link.

The script contains one function for creating a TCP/IP printer port and one function for creating a printer object. These functions are used in a foreach-loop cycling through the csv-file containing all the printer objects. The script are pretty basic, and should be further expanded with error handling and further details for printer properties.

The script are created and tested on a Windows Server 2008 server against a remote Windows Server 2003 server.
Running the script from Windows Server 2003 returns an access denied error, possibly due to the impersonation-model in Windows Server 2003. However, it should work from Windows Vista, Windows 7, Windows Server 2008 and Windows Server 2008 R2 against remote print-servers (2000/2003/2008/2008 R2).

Especially the ability to set NTFS permissions on the printer objects would be a useful addition in the script.

Please feel free to leave suggestions for improvements in the comments section below.

Update 09.11.2009:
I`ve got some feedback regarding the ability to set NTFS permissions on the printer objects in the script.
A utility called SubInACL from Microsoft could be used for this.

Example usage:
subinacl.exe /printer “\\print-server\printer” /revoke=”Power Users”
subinacl.exe /printer “\\print-server\printer” /grant=”DOMAIN\Domain Users”

The tool can be downloaded from here.


How to install an Excel Add-in with PowerShell

November 1, 2009

Recently I had the need to automate the process of installing Excel Add-ins in a terminalserver (or more correctly Remote Desktop Services environment since this was Windows Server 2008 R2) environment.

Since Excel Add-ins are per-user based, this was in the first place a manual setting. Of course we wanted to automate this process, so I researched a bit on the internet and found mostly VBScripts. I`ve used this KB-article as a template.

Although this worked very well, I`m trying to leverage the use of PowerShell as much as possible. Many would say that VBScripts load much faster, and are more effecient as logonscripts.
Even though PowerShell v1 was a bit slow due to the lack of assemblies not being ngen`ed, as described on the PowerShell Team`s Blog, this bug is fixed in v2 and I`m quite happy with the loading time now.

I basicly re-wrote the sample VBScript in the KB-article, the result are uploaded to PoshCode.org and available from here.

I used an if-statement to check if the Add-in are already installed, to avoid installing it on every logon.

When tested and ready for production, the script may be distributed as a traditional logonscript, or alternatively with Group Policy:

image


Active Directory group membership modifications report

October 11, 2009

Based on customer needs I`ve created a Windows PowerShell script to report Active Directory group membership modifications. The script are uploaded to PoshCode and available from here.

In Windows 2000 Server and Windows Server 2003, the following security event IDs were valid for group membership changes:

Scope Member added Member removed
Local 636 637
Global 632 633
Universal 660 661

In Windows Server 2008 and Windows Server 2008 R2 the security event IDs changed:

Scope Member added Member removed
Local 4732 4733
Global 4728 4729
Universal 4756 4757

Source for 2000/2003 event IDs.
Source for 2008/2008 R2 event IDs.

Group membership auditing are enabled by default from Windows 2000 Server to Windows Server 2008 R2, so there are no need change any auditing settings to accomplish this.
I`ve added event ID`s for both 2000/2003 and 2008/2008 R2 to the script to cover all event ID`s currently available.
Group membership changes are logged to the Security eventlog on the domain controller the modification was run against. Because of this the script are set up to get all domain controllers in the current domain and loop through the security eventlog on each of them, searching for the relevant event ID`s described in the table above.

The script are based on Alan Renouf`s Daily Report script for PowerCLI.

The “isWithin”-function are taken from Jeffrey Snover`s blog-post regarding DateTime Utility Functions.

Preview of the HTML-report the script will generate:

image

A tip would be to run the script as a scheduled task e.g. once a day, and store the file in a central location.

For those of you interested in Active Directory auditing I would recommend you to have a look at the AD DS Auditing Step-by-Step Guide on Microsoft TechNet.
Personally I think the new "directory service changes" category are very useful, which allows us to see both the old and new values on modified Active Directory user objects.


Generate random passwords for Active Directory users v2

September 29, 2009

A litte while ago I posted a script to generate random passwords for each user in a specified OU in an Active Directory environment.

Now I`ve just posted another version of this script on PoshCode.

This script are intended for another scenario:
Power users with delegated permissions to reset password for specified Organizational Units. The power users get this script available as a published application in Remote Desktop Services.


How to upgrade from MDT 2008 Update 1 to MDT 2010

September 25, 2009

Now that Microsoft Deployment Toolkit 2010 are available, MDT 2008 installations should be upgraded to support Windows 7 and Windows Server 2008 R2 deployment.

Also, many new features are available, which I wrote about in this blog-post.

 

The upgrade procedure

1) Uninstall earlier versions of Windows Automated Installation Kit

2) Download and install Windows Automated Installation Kit for Windows 7

3) Download and install Microsoft Deployment Toolkit 2010

4) Open Deployment Workbench. You should now find your Deployment Share.

image

Right-click the Deployment Share and choose “Open Deployment Share”.

Specify the path to your Deployment Share.

Check the checkbox “Upgrade the content of the deployment share” and press Next:

image

Press “Next”:

image

Review any warnings and press Finish:

image

Your Deployment Share are now available in the Deployment Workbench:

image

5) Upgrade the Windows PE boot images with new versions of Windows PE and the MDT-scripts.

To do so, right click the Deployment Share and choose “Update Deployment Share”:

image

Choose “Completely regenerate the boot images” and press Next:

image

 

image

image

6) If WDS are used to distribute the boot images, they must be updated.

To do so, open “Windows Deployment Services” from the Start-menu->Administrative tools.

Go to “Boot Images”, right click the boot image to update and choose “Replace”:

image

You`ll find the updated wim-files in the Boot-folder in the Deployment Share.

Microsoft Deployment Toolkit are now upgraded to version 2010, and supports Windows 7 and Windows Server 2008 R2 deployment.


New features in Microsoft Deployment Toolkit 2010

September 24, 2009

MDT 2010 was released September 9th 2009.

Michael Niehaus from Microsoft`s Deployment Team has posted an excellent series of blog posts describing the new features:

New Feature #1: Logging directly to the network

New Feature #2: Gathering virtualization details

New Feature #3: Suspend and resume a Lite Touch task sequence

New Feature #4: Folders everywhere

New Feature #5: Support for multiple deployment shares

New Feature #6: Drag and drop

New Feature #7: Boot image creation optimized

New Feature #8: No more visible command windows when booting Lite Touch Windows PE

New Feature #9: Copy and paste support in the Deployment Workbench task sequence editor

New Feature #10: Detection of signed drivers

New Feature #11: Windows 7 and Windows Server 2008 R2 support

New Feature #12: USMT 4.0 hardlink support

New Feature #13: New task sequence templates

New Feature #14: Database improvements

New Feature #15: Finish actions

New Feature #16: PowerShell support

New Feature #17: Customizable boot image process

New Feature #18: Selection Profiles

New Feature #19: Improved Driver Management

Other interesting posts on Michael`s blog:

Running PowerShell scripts as part of a task sequence

Automatically update MDT 2010 boot images in WDS

 

For those who are working with MDT I would also recommend to follow the Microsoft Deployment Toolkit Team`s blog.

Be aware of the following bug described on their blog:Fix for ‘Multiple connections to a server or shared resource by the same user, using more than one user name, are not allowed” problem with MDT 2010

The Deployment Guys` blog are also an excellent resource.


Replmon.exe not included in Windows Server 2008/2008 R2

September 18, 2009

A lot of administrators are used to check their Active Directory replication status using replmon.exe which is a part of the Windows Server 2003 Support tools.
Today I stumbled across the need to use replmon.exe on a domain controller running Windows Server 2008, and was unable to find it.

It turns out that that this utility is not included in Windows Server 2008/2008 R2.

According to a comment from a team member from the Microsoft Directory Services Team, this is the explanation:

“Unfortunately, replmon did not survive the transition to Win2008. It was actually developed by MS support, not the product group (along with many other support tools/resource kit tools), and without an actual owner to service the tool years later, it was a casualty. I don’t see why it wouldn’t work on 2008 though…”

I wouldn`t recommend using unsupported tools on Windows Server 2008/2008 R2, so the advice would be to either use repadmin.exe on 2008/2008 R2, or to use replmon.exe from a Windows Server 2003 server.

You can find the command reference for repadmin.exe in Windows Server 2008/2008 R2 here.

A few examples:

repadmin.exe /showrepl shows the replication-status for the domain controller the tool are being run from.

repadmin.exe /showrepl servername shows the replication-status for the domain controller with the provided servername,

repadmin.exe /queue shows the replication-queue for the domain controller the tool are being run from.

repadmin.exe /queue servername shows the replication-queue for the domain controller with the provided servername,

repadmin.exe /replsummary shows a brief summary of the replication status.

I also checked if there are any PowerShell cmdlets for checking replication status in Windows Server 2008 R2, but it`s not. Hopefully this will be implemented some time in the future.

PS: I did test installing the Windows Server 2003 Support tools on a Windows Server 2008 domain controller in a lab environment, and it does work.


How to use the new Active Directory Recycle Bin feature

September 13, 2009

 

In Windows Server 2008 R2 there is a new feature called Active Directory Recycle Bin. This feature makes it possible to restore deleted objects in Active Directory without restore from backup.
Opposite to restoring tomb stoned objects, all object parameters are remained (group membership, sn, dn, and so on).

Active Directory Recycle Bin are disabled by default, even in new Windows Server 2008 R2 domains. As a prerequisite, the forest mode must be set to Windows Server 2008 R2.
When all domain controllers are running Windows Server 2008 R2, this can be accomplished by using the Active Directory module in PowerShell:
Set-ADForestMode –Identity domain.local -ForestMode Windows2008R2Forest

You may also use ldp.exe or the GUI tool “Active Directory Domains and Trusts”.

You can use the Get-ADOptionalFeature to check if the Recycle Bin Feature are enabled.

Before enabling the feature:

image

After enabling the feature:

image

 

When the prerequisites are met, the Active Directory Recycle Bin-feature can be enabled.
Either using the Active Directory module in PowerShell:

image

Or by using ldp.exe.

When the feature are enabled it`s a good idea to perform some testing. By default all deleted objects are placed in the Deleted Objects container.

In my test I first created a user named “Test User”, and then deleted the user object:

image

This will retrieve all deleted user objects:

image

This will restore all deleted user objects:

image

This will restore a specific user object:

image

For those of you that are more comfortable using a GUI rather than the PowerShell command-line, a GUI tool for using this new feature are already available. Check out Kirk Munro`s PowerGUI PowerPack for Active Directory Recycle Bin.

This blogpost are based on the official Microsoft documentation on Technet, provided in the Active Directory Recycle Bin Step-by-Step Guide.


Generate random passwords for Active Directory users

August 22, 2009

Lately I had the need to create a random password for each user in a specified OU in an Active Directory environment.
I accomplished this by using Windows PowerShell and the system.random .Net-class combined with Quest`s ActiveRoles Management Shell for Active Directory.

The script are uploaded to PoshCode, and available from here.

What I would like to add, is the encryption of the $password variable. If you have some good ideas on how to accomplish this, suggestions are welcome in the Comments-section below.