How to manage Remote Desktop Services with Windows PowerShell

Microsoft provides a graphical user interface and a command-line interface to help with virtual desktop deployment. Now that you have installed Remote Desktop Services on Windows 2008 R2, see how to manage it with Windows PowerShell.

The management interface installed with the Remote Desktop Services (RDS) PowerShell module is made up of two parts:

1. Providers present a logical view of a data structure (similar to a file system) with a tree structure (like that of the graphical user interface) for dealing with RDS. Providers also make use of common cmdlets like get-item, get-childitem,  get-acl, set-acl andnew-item>. Microsoft provides more information about providers on its website.
2. Cmdlets in relation to RDS, provide management that may be out of the scope of the provider.

Step 1: Install Remote Desktop Services Management
The first step is simple — in fact, you don’t need to do anything at all.

The provider and cmdlets are installed by default with the RDS components.

Step 2: Run the PowerShell RDS module
There are two options for starting the PowerShell RDS Module:

1. Go to Start Menu — All Programs — Administrative Tools — Remote Desktop Services – – Remote Desktop Services PowerShell.
2. Add the module to an existing PowerShell module
   1. by the Import-Module cmdlet built-in to PowerShell (see Figure 1).

      Import-module RemoteDesktopServices — verbose.

   Note: Unless User Account Control is disabled, you will want to “Run as Administrator.”

   Step 3: Take a look at what you have
   The biggest obstacle when starting is figuring out what you have. There are several ways to do this, including get-command and default provider cmdlets.

   Get-command
   Get-command is a built-in cmdlet that notes what commands are available. One of the most useful parameters for get-command is –module, gets the commands available in the module.

   Note: For more information on get-command see get-help get-command — full or the Microsoft help page on get-command.

   Default Provider cmdlets
   There are many built-in provider cmdlets designed to work consistently with all the providers (such as registry, file system and RDS).

   • Get-Childitem (dir:) Gets all the child items in the current location.
     Example: PS> get-childitem RDS:ConnectionBroker
   • Get-Item (gi:) Gets a specific item in the provider.
     Example: PS> get-item RDS:ConnectionBrokerDisplayName
   • Get-Member (gm:) Lists the properties for a given item.
     Example: PS> get-item RDS:ConnectionBrokerDisplayName | get-member
   • Set-item: Used to set a property on a given item.
     Example: PS> get-item RDS:ConnectionBrokerDisplayName | set-item -value “RDS CB”

   Overall, PowerShell is a powerful tool for managing Remote Desktop Services. For more information on virtual desktop deployment, check out Microsoft’s Remote Desktop Services Team Blog.

   
   

Terminal Services grows up with Windows Server 2008 R2

First up in this feature-by-feature rundown of what’s new and exciting in Windows Server 2008 R2 is Terminal Services, er, Remote Desktop Services (RDS). Sporting a brand new name along with major new functionalities, RDS elevates Microsoft’s venerable Terminal Services to a platform additionally capable of hosting your Virtual Desktop Infrastructure (VDI). Other hoped-for features are also available with the release of R2, but let’s start with the most exciting first.

Remote Desktop Virtualization

The new Remote Desktop Virtualization (RDV) feature for RDS arrives first as an augmentation to the old Terminal Services Session Broker (TSSB) role service. In its original version, TSSB was responsible for load balancing users across multiple servers in a terminal server farm. This new version is now additionally responsible for brokering connections between users and hosted desktops running atop one or more Hyper-V servers.

This architecture, commonly called VDI or “hosted desktops,” adds a second mechanism for connecting users to remote applications. With Remote Desktop Virtualization, users can be manually tagged to a specific personal desktop, or groups of available and similarly-configured desktops can be aggregated into “pools” for distribution as connections are made.

This concept of hosted desktops is not new technology. Vendors VMware, Citrix and others have been doing it for a while using their software and virtualization infrastructures. The difference here is a matter of cost versus functionality, as Microsoft’s solution requires no additional costs outside of your Windows Server licenses to get started. At the same time, what you can do with Microsoft’s administrative functionality may be comparatively limited.

Here’s how the process works. An administrator first creates a set of hosted desktops within Microsoft Hyper-V. These desktops are either specifically tagged to a user or they become part of a pool for use by any connecting user. The use of clones in this case reduces the on-disk overhead of creating lots of virtual machines.

Once they are created, users can connect to available hosted desktops through any of the usual mechanisms first introduced in Windows Server 2008 RTM — RDP file, local installation, Remote Desktop Web Access website and so on. As users connect, that connection first goes to the Remote Desktop Session Broker service to identify which hosted desktop should be provided. Once this information is known, the client’s connection is redirected to the correct Hyper-V server to access the user’s virtual machine. Just like with traditional Terminal Services applications, the network protocol, connecting user to machine remains RDP.

This new capability is a major play for organizations that still support problem applications, such as 16-bit apps or those that refuse to work with Terminal Services. Those who want to provide a fully-remote desktop for their users will also appreciate the integration. Users will see their hosted desktop alongside their traditional hosted applications either on their desktop or through Remote Desktop Web Access. The result is designed to look seamless to the user.

Fair share CPU scheduling

RDV is only one of the much-needed updates Windows Server 2008 R2 brings to the Terminal Services table. Another particularly impressive new feature is fair share CPU scheduling. Anyone who has seen the actions of one user spike the CPU resources on their terminal server — and who hasn’t? — will appreciate how this feature works.

With fair share CPU scheduling, each user on a terminal server is given a percentage of CPU power equal to every other user on that server. For example, a server with 10 users will see each user getting approximately 10% of the overall power. This happens until the 11th user connects, when the balance is shifted again. If one user begins watching a video or running a developer build, or any other resource-intensive action, his or her individual session will show full utilization while the total server will only show utilization equal to the user’s percentage. The result is a stunning reduction in resource overuse by your few problematic users.

RemoteApp and Desktop Connection

Another client piece that aligns Remote Desktop Services with what Citrix admins have used for years is RemoteApp and Desktop Connection. This feature is visually similar to the Citrix XenApp plugin, or what used to be called the Citrix Program Neighborhood Agent. With RemoteApp and Desktop Connection, Windows clients across your environment can be configured to look to a specific location on the network for the identification of available RemoteApp programs.

Once discovered, RemoteApp programs are then made available automatically in the Start Menu or desktop of the client.

This operation is quite different from what was introduced in the RTM version of Windows Server 2008. There, to make RemoteApp programs available in this way, an MSI would first need to be created and subsequently installed to each client. The result was an added administrative overhead for “installed” RemoteApp programs requiring a software delivery mechanism like Configuration Manager or Group Policy for their deployment.

With RemoteApp and Desktop Connection, administrators need only to ensure that desktop clients are pointed to the correct discovery location. Clients will automatically check the location every few hours and update their list of applications.

Although it’s a great new client add-on, the beta version does not support updating the local client’s file extension associations when a new RemoteApp program is provisioned. Lacking this feature, users who try to access apps as RemoteApp programs won’t be able to through the usual document invocation (i.e., double-click) method. Let’s hope Microsoft adds this in the final version.

What else is new?

There are quite a few other RDS bonuses with Windows Server 2008 R2, although the remainder are minor compared to the above three. Here’s a list of some of the more interesting ones:

• Remote Desktop IP Virtualization. Some applications require that specific IP addresses are used on the server hosting the application. This is often the case because of licensing restrictions. Windows Server 2008 R2 adds the ability to virtualize — or “spoof” — IP addresses to enable these applications to function on Remote Desktop Services.
• Windows Installer becomes RDS aware. A major problem with traditional Terminal Services has long been related to the limitations of Windows Installer. In previous versions, Windows Installer wasn’t fully aware of Terminal Services’ multi-sessioning architecture, meaning it would not always correctly disseminate per-user customizations to new users. In Windows Server 2008 R2, Windows Installer is now RDS-aware, which means that the installation of most MSI applications should function with little post-installation hacking.
• Roaming profile cache management. If you allow roaming profiles to remain on your terminal servers, then you know how they can quickly fill up the available space. A new but small feature adds a bit of extra logic that removes the oldest profiles first when space gets tight.
• Ridiculously-powerful PowerShell integration. With the advent of Windows Server 2008 R2 comes the complete capability to manage RDS servers through Windows PowerShell. This includes the ability to view and modify configurations through the command line.

As before, many if not all of these features will require additional functionality at the client layer as well. With the release of Windows Server 2008 R2, you can also see the Remote Desktop Client updated to version 7. An install of this new version will be required to make use of most of the features discussed in this article.

Implementing VDI using Windows Server 2008 R2 Remote Desktop Services and Hyper-V

RDS VDI Functionality

An RDS-based VDI provides an environment that enables central storage, execution, and management of Windows desktops in a datacenter. An RDS VDI solution supports the creation and management of virtual desktop pools, and personal virtual desktops.

A virtual desktop pool is a collection of identical virtual desktops that are available for connection by multiple users. This type of virtual desktop does not maintain user state; instead it reverts back to its original state when a user logs off. A virtual desktop pool is applicable to users with the following characteristics:

• Do not need a personalized desktop
• Do not need offline access to virtual desktop
• Do not need to save state between sessions
• Need access to the virtual desktop from a collection of client devices

Examples of users that may require access to a virtual desktop pool are call-center workers, POS workers, and administrative office workers.

In contrast, a personal virtual desktop is configured for connection by a single user and maintains user state information when the user logs off. A personal virtual desktop pool is applicable to users with the following characteristics:

• Need a personalized desktop
• Need to save desktop state between sessions
• Need administrative access to virtual desktop

Examples of users that may require access to a personal virtual desktop are offshore software developers and testers.

Core RDS VDI Components

Whether deploying a virtual desktop pool or personal virtual desktops using RDS-based VDI, specific core components are needed and additional components may be necessary depending on the complexity of the solution requirements. The core components required for any RDS-based VDI solution include the following:

• RD Connection Broker
• RD Session Host
• RD Virtualization Host
• RD Licensing Server

The RD Connection Broker builds on the functionality of the Windows Server 2008 TS Session Broker to manage not only session-based remote desktops, but also virtual desktops. The RD Virtualization Host (RDVH) is a new role added in Windows Server 2008 R2. The RD Virtualization Host role runs on Hyper-V hosts and serves to manage the state of virtual machines and connect users to virtual machines.

RD Connection Broker

The RD Connection Broker manages user requests for connection to session-based and virtual machine-based desktops. It tracks the user name for each connection as well as the connection identifier, connection state, and connection host for each connection to an RD Session Host or RD Virtualization Host server. The RD Connection Broker also provides the ability to load balance connections within RD Session Host and RD Virtualization Host server farms, by evenly distributing connections between RD Session Host and RD Virtualization Host servers using a relative server weight value. In addition, the RD Connection Broker enables disconnected users to reconnect to an existing session-based or virtual machine-based desktop.

RD Session Host

In a VDI environment, RD Session Host servers are configured to run in redirection mode, which disallows interactive user sessions. Instead, when a client requests a connection to a virtual desktop, the RD Session Host server role contacts the RD Connection Broker for the IP address of the virtual machine to which the user should connect and returns it to the client. The client then initiates an RDP connection to the virtual machine.

RD Virtualization Host

The RD Virtualization Host is installed on Hyper-V hosts to manage virtual machines in preparation for an RDP connection based on a request from the RD Connection Broker. In addition, the RD Virtualization Host monitors and reports on virtual machine guest sessions to the RD Connection Broker.

RD Licensing Server

If you have worked in a Microsoft Terminal Services environment, you are already familiar with Client Access Licenses (CALs). In Windows Server 2008 R2, an RDS CAL is required for each device or user that connects to RD Session Host or RD Virtualization Host servers. When a user or device attempts a connection through an RD Session Host server, it requires an RDS CAL. The RD Session Host server makes a request to an RD Licensing Server on behalf of the client. If an RDS CAL is available, it is issued to the client, which is then able to connect to the RD Session Host or RD Virtualization Host server.

Microsoft provides a grace period that begins when an RD Session Host server accepts the first client connection. However, after the grace period, each user or device must be issued an RDS CAL before it can connect to an RD Session Host or RD Virtualization Host server. In Windows Server 2008 R2, the grace period lasts 120 days.

If you already have Windows Server 2008 deployed and have Windows Server 2008 TS CALs, you do not need to purchase new CALs as both Windows Server 2008 TS CALs and Windows Server 2008 R2 RDS CALs allow a user or device the right to connect to Windows Server 2008 R2.

Other RDS VDI Components

There are several additional RDS components that may be needed to provide a complete VDI solution. These additional components include the following:

• RD Web Access
• RD Gateway
• RemoteApp

RD Web Access

RD Web Access provides a web portal from which users can access session-based remote desktops, session-based remote applications, or virtual machine-based desktops. User requests for connection to session-based and virtual machine-based desktops made through RD Web Access are managed through the RD Connection Broker.

In Windows Server 2008 R2, RD Web Access allows the view of available remote desktops, remote applications, and virtual desktops to be customized based on user access. This means that a user will only be able to view and access those elements to which an administrator has specifically provided rights and permissions.

The RD Web Access portal also supports both private and public computer modes to control storage of sensitive information. For example, in private mode, RD Web Access cookies storing a user name expire in 4 hours. In public mode, they expire in 20 minutes.

RD Gateway

The RD Gateway is deployed at the edge of a corporate network and allows remote users to connect to resources deployed within a corporate intranet through a secure, encrypted connection. RD Gateway uses RDP over HTTPS to establish the secure connection between the remote user device and internal corporate resources.

RemoteApp

RemoteApp enables applications hosted on an RD Session Host server and virtual desktops hosted on an RD Virtualization Host server to be remotely accessed and integrated with a client desktop. For examples, using RemoteApp, it is possible to launch a remotely hosted application from an icon on the client desktop. When the application launches, an RDP session initiates to the application host and the application is presented on the local desktop in its own resizable window. If a user runs multiple RemoteApp applications, the applications can also share a single RDP session.

Remote Client Connection Sequence in Windows Server 2008 R2 RDS VDI

So how do RDS components work together to provide a remote client access to a virtual desktop within an Active Directory domain? Here is a brief explanation of the process assuming that RD Gateway and RD Web Access are deployed behind an external firewall and used to connect to a virtual desktop:

1. A remote user opens a web browser and connects to the RD Web Access portal.
2. RD Web Access requests the list of virtual desktop information to display from the RD Connection Broker.
3. The RD Connection Broker checks virtual desktop permissions in Active Directory, and then provides the information back to the RD Web Access site.
4. The users’ browser displays the virtual desktop information from the RD Web Access site.
5. After the user selects a virtual desktop, the Remote Desktop Client (RDC) opens a connection to the RD Gateway.
6. The RD Gateway forwards the connection to the RD Session Host server running in redirection mode.
7. The RD Session Host server requests that the RD Connection Broker prepare the virtual desktop and return its IP address.
8. The RD Connection Broker queries AD to verify user credentials and personal virtual desktop information associated with the user, if necessary.
9. The RD Connection Broker requests that the RD Virtualization Host server start the virtual desktop if it is not running, and then returns the virtual desktop IP address to the RD Session Host server.
10. The RD Session Host server returns the virtual desktop IP address to the Remote Desktop Client running on the users’ computer.
11. The Remote Desktop Client connects to the virtual desktop through the RD Gateway.

Since there are many different network configurations in which the RD Gateway and other RDS VDI components can be deployed, the connection sequence may slightly vary. For additional information on RD Gateway deployment configurations, you can check out the Microsoft RDS Team blog entry here.

Conclusion

In Windows Server 2008 R2, the RD Connection Broker has been extended to manage not only session-based remote desktops, but also virtual machine-based desktops running on Hyper-V. With this new feature and the addition of the RD Virtualization Host component, it is now possible to build a VDI for small or medium environments using only Windows Server 2008 R2 RDS components. For large deployments, a Microsoft RDS-based VDI solution can still be integrated with Citrix XenDesktop to provide an enterprise scale infrastructure.

Implementing VDI using Windows Server 2008 R2 Remote Desktop Services and Hyper-V

RDS VDI Functionality

An RDS-based VDI provides an environment that enables central storage, execution, and management of Windows desktops in a datacenter. An RDS VDI solution supports the creation and management of virtual desktop pools, and personal virtual desktops.

A virtual desktop pool is a collection of identical virtual desktops that are available for connection by multiple users. This type of virtual desktop does not maintain user state; instead it reverts back to its original state when a user logs off. A virtual desktop pool is applicable to users with the following characteristics:

• Do not need a personalized desktop
• Do not need offline access to virtual desktop
• Do not need to save state between sessions
• Need access to the virtual desktop from a collection of client devices

Examples of users that may require access to a virtual desktop pool are call-center workers, POS workers, and administrative office workers.

In contrast, a personal virtual desktop is configured for connection by a single user and maintains user state information when the user logs off. A personal virtual desktop pool is applicable to users with the following characteristics:

• Need a personalized desktop
• Need to save desktop state between sessions
• Need administrative access to virtual desktop

Examples of users that may require access to a personal virtual desktop are offshore software developers and testers.

Core RDS VDI Components

Whether deploying a virtual desktop pool or personal virtual desktops using RDS-based VDI, specific core components are needed and additional components may be necessary depending on the complexity of the solution requirements. The core components required for any RDS-based VDI solution include the following:

• RD Connection Broker
• RD Session Host
• RD Virtualization Host
• RD Licensing Server

The RD Connection Broker builds on the functionality of the Windows Server 2008 TS Session Broker to manage not only session-based remote desktops, but also virtual desktops. The RD Virtualization Host (RDVH) is a new role added in Windows Server 2008 R2. The RD Virtualization Host role runs on Hyper-V hosts and serves to manage the state of virtual machines and connect users to virtual machines.

RD Connection Broker

The RD Connection Broker manages user requests for connection to session-based and virtual machine-based desktops. It tracks the user name for each connection as well as the connection identifier, connection state, and connection host for each connection to an RD Session Host or RD Virtualization Host server. The RD Connection Broker also provides the ability to load balance connections within RD Session Host and RD Virtualization Host server farms, by evenly distributing connections between RD Session Host and RD Virtualization Host servers using a relative server weight value. In addition, the RD Connection Broker enables disconnected users to reconnect to an existing session-based or virtual machine-based desktop.

RD Session Host

In a VDI environment, RD Session Host servers are configured to run in redirection mode, which disallows interactive user sessions. Instead, when a client requests a connection to a virtual desktop, the RD Session Host server role contacts the RD Connection Broker for the IP address of the virtual machine to which the user should connect and returns it to the client. The client then initiates an RDP connection to the virtual machine.

RD Virtualization Host

The RD Virtualization Host is installed on Hyper-V hosts to manage virtual machines in preparation for an RDP connection based on a request from the RD Connection Broker. In addition, the RD Virtualization Host monitors and reports on virtual machine guest sessions to the RD Connection Broker.

RD Licensing Server

If you have worked in a Microsoft Terminal Services environment, you are already familiar with Client Access Licenses (CALs). In Windows Server 2008 R2, an RDS CAL is required for each device or user that connects to RD Session Host or RD Virtualization Host servers. When a user or device attempts a connection through an RD Session Host server, it requires an RDS CAL. The RD Session Host server makes a request to an RD Licensing Server on behalf of the client. If an RDS CAL is available, it is issued to the client, which is then able to connect to the RD Session Host or RD Virtualization Host server.

Microsoft provides a grace period that begins when an RD Session Host server accepts the first client connection. However, after the grace period, each user or device must be issued an RDS CAL before it can connect to an RD Session Host or RD Virtualization Host server. In Windows Server 2008 R2, the grace period lasts 120 days.

If you already have Windows Server 2008 deployed and have Windows Server 2008 TS CALs, you do not need to purchase new CALs as both Windows Server 2008 TS CALs and Windows Server 2008 R2 RDS CALs allow a user or device the right to connect to Windows Server 2008 R2.

Other RDS VDI Components

There are several additional RDS components that may be needed to provide a complete VDI solution. These additional components include the following:

• RD Web Access
• RD Gateway
• RemoteApp

RD Web Access

RD Web Access provides a web portal from which users can access session-based remote desktops, session-based remote applications, or virtual machine-based desktops. User requests for connection to session-based and virtual machine-based desktops made through RD Web Access are managed through the RD Connection Broker.

In Windows Server 2008 R2, RD Web Access allows the view of available remote desktops, remote applications, and virtual desktops to be customized based on user access. This means that a user will only be able to view and access those elements to which an administrator has specifically provided rights and permissions.

The RD Web Access portal also supports both private and public computer modes to control storage of sensitive information. For example, in private mode, RD Web Access cookies storing a user name expire in 4 hours. In public mode, they expire in 20 minutes.

RD Gateway

The RD Gateway is deployed at the edge of a corporate network and allows remote users to connect to resources deployed within a corporate intranet through a secure, encrypted connection. RD Gateway uses RDP over HTTPS to establish the secure connection between the remote user device and internal corporate resources.

RemoteApp

RemoteApp enables applications hosted on an RD Session Host server and virtual desktops hosted on an RD Virtualization Host server to be remotely accessed and integrated with a client desktop. For examples, using RemoteApp, it is possible to launch a remotely hosted application from an icon on the client desktop. When the application launches, an RDP session initiates to the application host and the application is presented on the local desktop in its own resizable window. If a user runs multiple RemoteApp applications, the applications can also share a single RDP session.

Remote Client Connection Sequence in Windows Server 2008 R2 RDS VDI

So how do RDS components work together to provide a remote client access to a virtual desktop within an Active Directory domain? Here is a brief explanation of the process assuming that RD Gateway and RD Web Access are deployed behind an external firewall and used to connect to a virtual desktop:

1. A remote user opens a web browser and connects to the RD Web Access portal.
2. RD Web Access requests the list of virtual desktop information to display from the RD Connection Broker.
3. The RD Connection Broker checks virtual desktop permissions in Active Directory, and then provides the information back to the RD Web Access site.
4. The users’ browser displays the virtual desktop information from the RD Web Access site.
5. After the user selects a virtual desktop, the Remote Desktop Client (RDC) opens a connection to the RD Gateway.
6. The RD Gateway forwards the connection to the RD Session Host server running in redirection mode.
7. The RD Session Host server requests that the RD Connection Broker prepare the virtual desktop and return its IP address.
8. The RD Connection Broker queries AD to verify user credentials and personal virtual desktop information associated with the user, if necessary.
9. The RD Connection Broker requests that the RD Virtualization Host server start the virtual desktop if it is not running, and then returns the virtual desktop IP address to the RD Session Host server.
10. The RD Session Host server returns the virtual desktop IP address to the Remote Desktop Client running on the users’ computer.
11. The Remote Desktop Client connects to the virtual desktop through the RD Gateway.

Since there are many different network configurations in which the RD Gateway and other RDS VDI components can be deployed, the connection sequence may slightly vary. For additional information on RD Gateway deployment configurations, you can check out the Microsoft RDS Team blog entry here.

Conclusion

In Windows Server 2008 R2, the RD Connection Broker has been extended to manage not only session-based remote desktops, but also virtual machine-based desktops running on Hyper-V. With this new feature and the addition of the RD Virtualization Host component, it is now possible to build a VDI for small or medium environments using only Windows Server 2008 R2 RDS components. For large deployments, a Microsoft RDS-based VDI solution can still be integrated with Citrix XenDesktop to provide an enterprise scale infrastructure.

<input type=”hidden” name=”IL_RELATED_TAGS” value=”1″/>

Dynamic Remote Desktop Connection Manager connection list

Microsoft recently released a free tool for managing multiple remote desktop connections called “Remote Desktop Connection Manager”.

A sample screenshot:

There are several nice features, such as “Connect group” which lets you connect to all servers in a group at once:

On the “Group Properties” you may set common settings for all connections in the group, like logon credentials:

Further, there are group properties for RDS Gateway (formerly TS Gateway), display settings, local resources and so on.

There are several applications for remote desktop connections on the market, and some of them got these settings as a per server setting. It`s nice to be able to group servers and configure common settings.

Dynamically creating the connection list

When you work in larger environments with hundreds, maybe thousands of servers, setting up each connection manually isn`t an option.

Since Remote Desktop Connection Manager stores the config-files in xml-files, it`s rather easy to create dynamic config-files for a domain using Windows PowerShell. I`ve created a script to accomplish this, called New-RDCManFile.ps1, available from here. It uses Microsoft`s PowerShell-module for Active Directory, which is available in Windows Server 2008 R2 and RSAT for Windows 7.

The script does the following:
Creates a template xml-file
Inserts the logged on user`s domain name in the file properties
Inserts the logged on user`s domain name in the group properties
Inserts the logged on user`s username in the logoncredentials section
Inserts the logged on user`s domain name in the logoncredentials section
Retrieves all computer objects from Active Directory with the word “server” in the operatingsystem property
Adds each computer object as a server object
Saves the XML-file to %userprofile%domain-name.rdg

When done you can open the rdg-file in Remote Desktop Connection Manager. I would recommend you to insert your password in the Group Properties to avoid being asked for credentials for each connection.

Feel free to customize the script to your needs, in example by editing the XML-template to edit the Group Properties. Another customization might be creating a group for each server OU for enhanced overview in larger environments.

If you would rather use Quest`s PowerShell Commands for Active Directory (which works on downlevel operatingsystems like Windows XP and Windows Server 2003), or any other way to retrieve the server names, you may customize this on line 110.

You might also want to schedule the script to run on a regular basis, saving the file to a central location. This way the IT personnel will always have access to the latest version with the most recent servers added.