blog.powershell.no

On Windows PowerShell and other admin-related topics

Adding printer drivers from a print server using Windows PowerShell

Managing printer drivers in a Remote Desktop Services (formerly Terminal Services) environment can be a challenge for administrators. There are many ways to ease this challenge, including third party solutions such as ThinPrint and UniPrint. When “thick” drivers are used on the RDS servers, all printer drivers must be installed locally on every server. Citrix XenApp has a printer driver replication feature which makes it possible to distribute printer drivers from a source server to one or more destination servers in a farm.

There might be situations where none of the mentioned solutions can be used for various reason, i.e. financial costs. A common way to solve this problem is to map all printer connections from a specified print server using administrative credentials during the initial setup of each RDS server. This solves the problem, but it can be time consuming as all printers that uses the same driver is being installed. Even though the driver is already installed on the local computer, it takes some time to process each printer connection.

I recently faced this challenge, as the installation of all printer connections from a few specified print servers took 30-40 minutes using a legacy script. I then wrote an advanced function in PowerShell to make the procedure more effective. This was accomplished by installing a printer connection only for unique printer drivers.
An example: A print server has 500 shared printer objects, while there is only 10 unique printer drivers. It would make more sense to add a printer connection (in order to install the driver) to 10 printer objects rather than 500, given the time consumed by installing a printer connection.

The function is available for download from here.

Sample usage and output:

image

 

image

There is a switch option added to the function called Clean. If this parameter is specified the function will also remove all mapped printer connections for the current user.

The function doesn’t`t provide any log options. However, it produces PowerShell objects, so it would be easy to pipe the output to a file.
An example on how to export the output objects to a csv-file:

image

But what about printer drivers added to the print servers after the function is run on an RDS server? One way to solve this could be adding the PowerShell function to a script-file which is set up as a scheduled task to run i.e. once a day on every RDS server.  If the scheduled task is set up using Group Policy Preferences, it will be automatically created on every new RDS server that is added later on. Beside scheduling the task to run at specified intervals, the print server administrator may also invoke the scheduled task remotely on every RDS server whenever a new print driver is added to a print server. The details on how to do this is previously described in this blog-post.

Since the function might be run several times on the same computer, it also checks if the driver to be installed is already in place on the local computer. This means that after the first run, only printer drivers added to the print server after the first run is actually installed. This makes the script more effective, and depending on the number of shared printer objects on the specified print server, it shouldn’t`t run for many seconds.

Coming back to the before mentioned example (~600 printer objects, ~50 unique drivers) where it took 30-40 minutes to install printer drivers from a print server, when using the Add-PrinterDriver PowerShell function the execution ran for 4 minutes. After the first run, subsequent executions ran for  20 seconds.

Advertisements

July 3, 2011 Posted by | Print management, Remote Desktop Services, Scripting, Terminal Services, Windows PowerShell, Windows Server 2008, Windows Server 2008 R2 | , , , , | 5 Comments

DFS-R Health Report for SYSVOL

Distributed File System Replication (DFS-R) was introduced as a replacement for File Replication Service (FRS) in Windows Server 2008, and was further enhanced in Windows Server 2008 R2. When your domain functional level are set to Windows Server 2008, you have the option to migrate SYSVOL-replication from the deprecated FRS to the new and more reliable DFS-R service. A major advantage of using DFS-R over FRS is that FRS copies the whole file when a change are made, while DFS-R only copies the changed bits. This and further details are discussed here. I`ve also included some links in the resource section below on how to perform an FRS to DFS-R migration.

Included in the Windows Server 2008 and Windows Server 2008 R2 are the DFS Management-console as well as several command-line tools for administering DFS. A great built-in feature in these tools is the diagnostic reports.

This is available in the DFS Management-console:

image

As well as from the DfsrAdmin.exe command-line tool:

image

Using this feature we can generate an HTML-report containing a great overview of the replication health for the SYSVOL replication group:

image

Any errors and warnings will be shown with detailed explanations. In addition we can view general information and statistics i.e. regarding free diskspace on the domain controllers, bandwith savings and so on (click on the thumbnail to view):

image

Since the reporting feature are available from the DfsrAdmin.exe command-line tool, it makes it easy to set up a script as a scheduled task that also sends the generated report via e-mail i.e. every morning. I`ve published a simple PowerShell-script to accomplish this which is available here.

Resources

SYSVOL Replication Migration Guide: FRS to DFS Replication (Word-version available here)

Verifying File Replication during the Windows Server 2008 DFSR SYSVOL Migration

DFSR SYSVOL Migration FAQ

Configuring DFSR to a Static Port

FRS to DFSR Migration Tool (not for SYSVOL migration)

December 30, 2010 Posted by | Active Directory management, DFS-R, Scripting, Windows PowerShell, Windows Server 2008, Windows Server 2008 R2 | | 2 Comments

Enable and configure Windows PowerShell Remoting using Group Policy

As you may know, Windows PowerShell 2.0 introduced a new remoting feature, allowing for remote management of computers.

While this feature can be enabled manually (or scripted) with the PowerShell 2.0 cmdlet Enable-PSRemoting, I would recommend using Group Policy whenever possible. This guide will show you how this can be accomplished for Windows Vista, Windows Server 2008 and above. For Windows XP and Windows Server 2003, running Enable-PSRemoting in a PowerShell startup script would be the best approach.

Windows PowerShell 2.0 and WinRM 2.0 shipped with Windows 7 and Windows Server 2008 R2. To take advantage of Windows PowerShell Remoting, both of these are required on the downlevel operating systems Windows XP, Windows Server 2003, Windows Vista and Windows Server 2008. Both Windows PowerShell 2.0 and WinRM 2.0 are available for download here, as part of the Windows Management Framework (Windows PowerShell 2.0, WinRM 2.0, and BITS 4.0). To deploy this update to downlevel operating systems I would recommend to use WSUS, which are described in detail in this blog post by Kurt Roggen.

Group Policy Configuration

Open the Group Policy Management Console from a domain-joined Windows 7 or Windows Server 2008 R2 computer.

Create or use an existing Group Policy Object, open it, and navigate to Computer Configuration->Policies->Administrative templates->Windows Components

Here you will find the available Group Policy settings for Windows PowerShell, WinRM and Windows Remote Shell:

image

To enable PowerShell Remoting, the only setting we need to configure are found under “WinRM Service”, named “Allow automatic configuration of listeners”:

image

Enable this policy, and configure the IPv4 and IPv6 addresses to listen on. To configure WinRM to listen on all addresses, simply use *.

In addition, the WinRM service are by default not started on Windows client operating systems. To configure the WinRM service to start automatically, navigate to Computer Configuration\Policies\Windows Settings\Security Settings\System Services\Windows Remote Management, doubleclick on Windows Remote Management and configure the service startup mode to “Automatic”:



No other settings need to be configured, however, I`ve provided screenshots of the other settings so you can see what`s available:

image

image

image

image

There is one more thing to configure though; the Windows Firewall.

You need to create a new Inbound Rule under Computer Configuration->Policies->Windows Settings->Windows Firewall with Advanced Security->Windows Firewall with Advanced Security->Inbound Rules:

image

The WinRM port numbers are predefined as “Windows Remote Management”:

image

With WinRM 2.0, the default http listener port changed from TCP 80 to TCP 5985. The old port number are a part of the predefined scope for compatibility reasons, and may be excluded if you don`t have any legacy WinRM 1.1 listeners.

image

image

When the rule are created, you may choose to make further restrictions, i.e. to only allow the IP addresses of your management subnet, or perhaps some specific user groups:

image

Now that the firewall rule are configured, we are done with the minimal configuration to enable PowerShell Remoting using Group Policy.

image

On a computer affected by the newly configured Group Policy Object, run gpupdate and see if the settings were applied:

image

As you can see, the listener indicates “Source*”GPO”, meaning it was configured from a Group Policy Object.

When the GPO have been applied to all the affected computers you are ready to test the configuration.

Here is a sample usage of PowerShell Remoting combined with the Active Directory-module for Windows PowerShell:

image

The example are saving all computer objects in the Domain Controller Organization Unit in a variable. Then, a foreach-loop are invoking a scriptblock, returning the status of the Netlogon-service on all of the Domain Controllers.

Summary

We`ve now had a look on how to enable and configure PowerShell Remoting using Group Policy.
There are an incredible number of opportunities opening up with the new Remoting feature in Windows PowerShell 2.0. For a complete walkthrough on how you can use this new feature, I would like to recommend the excellent Administrator’s Guide to Windows PowerShell Remoting written by Dr. Tobias Weltner, Aleksandar Nikolic and Richard Giles.

March 4, 2010 Posted by | Active Directory management, Deployment, Group Policy, Scripting, Windows 7, Windows PowerShell, Windows Server 2003 R2, Windows Server 2008, Windows Server 2008 R2, Windows Vista, Windows XP | , , | 19 Comments

Hyper-V R2 and storage location for snapshot differencing disks

I recently worked with a Hyper-V case, where the differencing disk files (.AVHD) for snapshots didn`t appear at the expected location. As we figured this out, I would like to share the experience we had regarding this.

A virtual machine has two important directories, the VM root and the snapshot root. The VM root is where we store the virtual machine configuration file (XML) and the saved state files (.BIN and .VSV). The snapshot root is where we store the config and saved state files for each snapshot of a virtual machine.

Virtual hard disks (.VHDs) are stored where ever the user specifies when creating the virtual machine (or when creating a new virtual hard disk).

What has changed in Hyper-V between Windows Server 2008 and Windows Server 2008 R2 is the placement of .AVHD files (these are the differencing disks created for each snapshot). In Windows Server 2008 the .AVHD is always created in the snapshot root location, which by default are located at C:\ProgramData\Microsoft\Windows\Hyper-V\Snapshots. This caused a lot of people problems – as they would run out of space on the partition where the snapshot root folder was. In Windows Server 2008 R2 the .AVHD file is always created in the same location as its parent virtual hard disk.

This means that with R2 .AVHD files will always appear beside their respective .VHD files. The one exception to this is if you bring across a Windows Server 2008 virtual machine with .AVHDs already in the snapshot root. In this case new .AVHDs will be created beside their parent .AVHDs (in the snapshot root).

 

Microsoft TechNet Resources

Hyper-V in Windows Server 2008
Hyper-V R2 in Windows Server 2008 R2

February 23, 2010 Posted by | Hyper-V, Hyper-V R2, Windows Server 2008, Windows Server 2008 R2 | | 1 Comment

Single Sign-On to Remote Desktop Services

 

Single sign-on is an authentication method that allows users with a domain account to log on once to a client computer by using a password, and then gain access to remote servers without being asked for their credentials again. See more details here for Windows Server 2008 and here for Windows Server 2008 R2.

On the client-side SSO are currently available for Windows XP with SP3, Windows Vista and Windows 7.

 

Configure SSO on the server-side

To configure SSO on the server-side (Windows Server 2008 Terminal Services or Windows Server 2008 R2 Remote Desktop Services), set the option “Security layer” to either “Negotiate” or “SSL (TLS 1.0)”:

image

Best practice would be to configure this in a common GPO for all Remote Desktop Services servers in the domain:

image

This setting resides under Computer Configuration->Policies->Administrative templates->Windows Components->Terminal Services->Terminal Server->Security.

 

Configure SSO on the client-side

Using a common GPO would also be the best practice to deploy the client settings needed for SSO to work.
The “Allow Delegating Default Credentials” resides under Computer Configuration->Policies->System->Credentials Delegation:

image

image

Enable “Allow Delegating Default Credentials”, press the “Show”-button and either specify the domain pre-fixed with * to allow delegation to all servers in the domain, or specify specific servers:

image 

Next, create a RDP-file and deploy this file to the client computers.
Before deploying the file, open it in a text editor, e.g. Notepad, and add the following line: enablecredsspsupport:i:1
This will enable SSO for the RDP-file.

I would also recommend to sign the RDP-file with a Code Signing certificate. This can be accomplished using the utility rdpsign.exe:

image

Sample signing:

image

When a RDP-file are signed, the following will be added to the bottom of the file:

signature:s:AQABAAEAAADBCgAAMIIKvQ……..

For Windows Vista and Windows 7 clients, the configuration would now be completed when the RDP-file are deployed.

 

For Windows XP clients the following would be necessary in addition to the steps above:
-Service Pack 3 needs to be installed
-At least version 6.0 of the Remote Desktop Client
-Turn on the CredSSP Security Provider

The steps to turn on the CredSSP Security Provider are described in this kb-article.

I would recommend deploying these registry settings using Group Policy Preferences:

image

Also the RDP-file may be deployed in the same way:

image

I`ve covered the usage of Group Policy Preferences in a previous post.

Also, SSO can be combined with Remote Desktop Services Web Access. The Remote Desktop Services Team has posted an excellent post describing how to set up SSO in RDS Web Access.

December 25, 2009 Posted by | Group Policy, Remote Desktop Services, Terminal Services, Windows 7, Windows Server 2008, Windows Server 2008 R2, Windows Vista, Windows XP | , , , , , | 2 Comments

Deploying printers using Group Policy

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

November 8, 2009 Posted by | Deployment, Group Policy, Print management, Windows Server 2003 R2, Windows Server 2008, Windows Server 2008 R2 | 8 Comments

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

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.

September 18, 2009 Posted by | Active Directory management, Windows Server 2008, Windows Server 2008 R2 | , | 3 Comments

The Basics of the Windows Server 2008 Distributed File System (DFS)

For those of you who are not using Distributed File System (DFS) I would really encourage you to have a close look at what it is, and consider the value it will add to the management of your company`s file system.

I`ve found this excellent blog post by Jose Barreto (Senior Program Manager with the File Server Foundation team) called “The Basics of the Windows Server 2008 Distributed File System (DFS)” (Yes, I did copy the blog post title 🙂 )

It`s a best practice to set up DFS for managing the file system, and I always encourage my clients to implement this for the following main reasons:

-Unified file structure (\\domain.local\Share-root) for file shares
-Future file server replacements will be transparent to users and applications
-Replication (WAN-scaling and redundancy)

DFS links (copied from Jose`s post):

TechNet on DFS
http://technet.microsoft.com/en-us/library/cc753479.aspx

DFS Step-by-Step Guide for Windows Server 2008
http://technet.microsoft.com/en-us/library/cc732863.aspx

DFSUTIL overview
http://technet.microsoft.com/en-us/library/cc782897.aspx

DFS Step-by-Step Guide for Windows Server 2003 R2
http://technet.microsoft.com/en-us/library/cc737358.aspx

DFS FAQ (from Windows Server 2003 R2)
http://www.microsoft.com/windowsserver2003/techinfo/overview/dfsfaq.mspx

March 27, 2009 Posted by | File system, Windows Server 2008 | Leave a comment

Troubleshooting Group Policy made easier

In Windows Vista/Server 2008 and newer operation systems from Microsoft the userenv.log file which was logging Group Policy processing information in Windows 2000/XP are replaced by a new event log named Group Policy. You can find it in the Event Viewer when you browse to Applications and Services Logs/Microsoft/Windows/GroupPolicy.

image

The event categories found in the Group Policy event log:

image

This really makes Group Policy troubleshooting much easier!

In addition to checking out the Group Policy event log on the client, I would also recommend the use of the Group Policy Modeling (simulating what is supposed to happen) and Group Policy Results (connecting to the client to see what did happen) wizards when troubleshooting Group Policy:

image

March 25, 2009 Posted by | Group Policy, Windows 7, Windows Server 2008, Windows Vista | , | Leave a comment

Group Policy Preferences

 

GP Preferences was released with Windows Vista and Windows Server 2008. It gives much more flexibility in addition to Group Policy Settings (administrative templates), and in some environments it may completely replace logon scripts.

 

Overview

GP Preferences Overview

To work with Windows XP and Windows Server 2003 there must be installed client-side extensions. The most common and practical way to deploy these would be to approve them in WSUS.

If setup and managed from Windows Vista or Windows Server 2008, GP Preferences may also be implemented in a Active Directory domain in Windows Server 2003 mode. This is described in more detail here.

Group Policy preference client-side extension can be downloaded here.

Group Policy Preferences overview whitepaper can be downloaded here.

 

Preferences vs. Settings (from the whitepaper)

Group Policy Preferences

Group Policy Settings

Enforcement

· Preferences are not enforced

· User interface is not disabled

· Can be refreshed or applied once

· Settings are enforced

· User interface is disabled

· Settings are refreshed

Flexibility

· Easily create preference items for registry settings, files, and so on

· Import individual registry settings or entire registry branches from a local or a remote computer

· Adding policy settings requires application support and creating administrative templates

· Cannot create policy settings to manage files, folders, and so on

Local Policy

· Not available in local Group Policy

· Available in local Group Policy

Awareness

· Supports non-Group Policy-aware applications

· Requires Group Policy-aware applications

Storage

· Original settings are overwritten

· Removing the preference item does not restore the original setting

· Original settings are not changed

· Stored in registry Policy branches

· Removing the policy setting restores the original settings

Targeting and Filtering

· Targeting is granular, with a user interface for each type of targeting item

· Supports targeting at the individual preference item level

· Filtering is based on Windows Management Instrumentation (WMI) and requires writing WMI queries

· Supports filtering at a GPO level

User Interface

· Provides a familiar, easy-to-use interface for configuring most settings

· Provides an alternative user interface for most policy settings

Also, see this blog post from the Group Policy team regarding GP Preferences vs GP Settings.

 

Example usage


Drive mapping

image

Printer mapping

image

Power Options

image

 

Group Policy Resources 

Group Policy Team Blog

GPOGuy – whitepapers, blog, free tools and some excellent video trainings

GPanswers – newsletters, book resources, community forum and more.

March 20, 2009 Posted by | Active Directory management, Group Policy, Windows Server 2008 | 7 Comments