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.
If you got any further ideas or comments, please let me know in the comments section below.
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:
To enable PowerShell Remoting, the only setting we need to configure are found under “WinRM Service”, named “Allow automatic configuration of listeners”:
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:
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:
The WinRM port numbers are predefined as “Windows Remote Management”:
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.
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:
Now that the firewall rule are configured, we are done with the minimal configuration to enable PowerShell Remoting using Group Policy.
On a computer affected by the newly configured Group Policy Object, run gpupdate and see if the settings were applied:
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:
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.
Pin and unpin applications from the taskbar and Start-menu using Windows PowerShell
I`ve created a PowerShell module for working with pinned applications in Windows 7 and Windows Server 2008 R2. The module are created based on a script created by Ragnar Harper and Kristian Svantorp.
The module are available here, on the TechNet Script Center Gallery.
Installation and usage
Modules in Windows PowerShell can be “installed” in two ways:
1) Save the module as a psm1-file, and store it in a folder with the same name as the psm1-file. Copy this folder, using i.e. xcopy or Copy-Item, to a desired PowerShell module-folder (see available module paths using $env:PSModulePath)
2) Import the module by calling the psm1-file directly.
The first option are preferred for production use.
Next, import the module using Import-Module:
(Option 1)
(Option 2)
The module consist of one function as shown here:
The help text are available with Get-Help:
For example usage, add –Examples to the Get-Help cmdlet:
Basic error checking for valid parameters are included:
The Set-PinnedApplication function supports the en-us and nb-no locales as-is, but you can easily add support for more locales.
Feel free to let me know in the comment section below if you got any feedback.
Update, 06.08.2010: A new version of the module are now published at the original link on the TechNet Script Center Gallery. In the new version, there are full MUI support, after an update by Johan Akerstrom.
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
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)”:
Best practice would be to configure this in a common GPO for all Remote Desktop Services servers in the domain:
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:
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:
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:
Sample signing:
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:
Also the RDP-file may be deployed in the same way:
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.
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:
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:
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”:
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”:
You should now receive a message stating that the deployment operation was successful. Click “OK”:
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”:
Open the “Group Policy Management Console”, go to the Group Policy Object you deployed the printer to, and select “Details”:
Note the “Unique ID” (GUID).
Back in ADUC, expand “System” and then “Policies”:
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:
When looking at “PushedPrinterConnections” under the “User” node, we see an entry of type “msPrint-ConnectionPolicy”:
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:
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:
Here is an example of the utility added to a logon-script in a Group Policy Object:
The log-files are named “ppcUser.log” and “ppcComputer.log”. These are located in the %temp% directory:
Here is an example output of the logfile:
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:
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)
How to install an Excel Add-in with PowerShell
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:
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.
How to use the new Active Directory Recycle Bin feature
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:
After enabling the feature:
When the prerequisites are met, the Active Directory Recycle Bin-feature can be enabled.
Either using the Active Directory module in PowerShell:
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:
This will retrieve all deleted user objects:
This will restore all deleted user objects:
This will restore a specific user object:
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.
Windows Server 2008 R2 Migration Tools
The Windows Server 2008 R2 Migration Tools are a set of tools available to simplify migration of various roles, features and other server data to a new server running Windows Server 2008 R2.
As described on the Migration Tools TechNet documentation, the following can be migrated using these tools:
Roles
Active Directory Domain Services and DNS
DHCP Server
File Services
Print Services
Features
BranchCache
Settings and Data
Data and Shares
IP Configuration
Local Users and Groups
Installation
Start by installing the Windows Server Migration Tools feature from the Add feature wizard in Server Manager on the destination server running Windows Server 2008 R2:
You can find the new feature on the Start-menu in Administrative tools:
After the “Windows Server Migration Tools” PowerShell prompt are opened, go to C:\Windows\System32\ServerMigrationTools.
Type SmigDeploy.exe /? to list the description and usage of this command.
Example usage
In this example we`ll migrate a DHCP Server running on a Windows Server 2003 machine. To create a deployment package for Windows Server 2003 32-bit, execute the following command:
When the package folder are successfully create, copy the folder to the source DHCP Server:
The only requirement on the source Windows Server 2003 server are Windows PowerShell (and thereby .NET Framework 2.0).
Start SmigDeploy.exe from the SMT_ws03_x86 folder to fire up Windows PowerShell with the Windows Server Migration Tools snapin.
Available cmdlets for this snapin:
Execute the cmdlet Get-SmigServerFeature to get the set of all Windows features that can be migrated from the local server:
The cmdlet returns the DHCP Server as a feature available for migration:
Here we got the DHCP Leases on the source DHCP Server, which are to be migrated to the Windows Server 2008 R2 server:
To export the DHCP Server configuration and database, run the Export-SmigServerSetting cmdlet with the following parameters (you will be prompted for a password to protect the exported file):
The export was successful, and we can see the exported *.mig-file:
Copy the *.mig file to the target DHCP Server.
To import the DHCP Server configuration and database, run the Import-SmigServerSetting cmdlet with the following parameters (you will be prompted for the password for the exported file):
The DHCP Server feature was not installed on the Windows Server 2008 R2 server, but the Import-SmigServerSetting takes care of this automatically:
The import was successful:
After starting the DHCP Server service we can open the DHCP Server management console and verify that the migration was successful:
This concludes this post regarding the new Migration Tools, and I must say I really like this new feature, especially the fact that it`s leveraging Windows PowerShell. I would recommend you to play around with this in a lab environment to get to know it`s usage.
Update 25.08.2009: As stated in the documentation on Technet, the DHCP-service on the source server must be stopped (Stop-Service DHCPserver) prior to the export. Thanks to Max for pointing this out.
Update 15.01.2011: Note that the destination DHCP-server must be authorized. Thanks to Blazej for pointing this out.
About
Jan Egil Ring works as a Senior Consultant on the Infrastructure Team at Crayon, Norway.
He mainly works with Microsoft server-products, and has a strong passion for Windows PowerShell. In addition to being a consultant, he is a Microsoft Certified Trainer.
He has obtained several certifications such as MCITP: Enterprise Administrator and MCITP: Enterprise Messaging Administrator. For more details see his MCP Virtual Business Card.
In January 2011, he was awarded the Microsoft Most Valuable Professional Award for his contributions in the Windows PowerShell technical community.
His engagements as a speaker includes TechDays in Norway, as well as a Microsoft Office 365 bootcamp for Microsoft partners in Norway.
He is a co-founder of the Norwegian Microsoft Technology User Group (MTUG), which is an assosication of local MTUG user groups in Norway.
His intentions with this blog is to share experiences based on various projects and troubleshooting, as well as sharing different resource links to technologies he works with.
Google Reader – My Shared Items- Kill cmd.exe Bartek Bielawski
- SCVMM 2012 Quick Tip: Finding which storage arrays a Hyper-V host can see hector.linares
- On Becoming a Senior Technical Individual Contributor jsnover
- Fix for "You must close all dialog boxes before you can close Exchange Management Console" in Exchange 2010 Jeff
- The Windows 8 Task Manager Steven Sinofsky
