blog.powershell.no

On Windows PowerShell and other admin-related topics

Manage RDS RemoteApp with Windows PowerShell

In Windows Server 2008 R2, Remote Desktop Services (formerly Terminal Services) includes a provider for managing RDS using Windows PowerShell. You may find more information along with some examples in this article on Microsoft TechNet.

One of the many things you can manage this way is the new RemoteApp-feature introduced with Windows Server 2008. In Windows Server 2008 R2, this feature got enhanced by the addition of User Assignment and Web Single Sign-On capabilities. These new features makes it possible for more and more customers to consider RDS without additional products like Citrix. One benefit using Citrix are more flexible application-management, since an published application may be available from a new farm member without adding each application manually.

Let`s look at a given example: You got a farm with 16 RDS-servers, and you`re leveraging the RemoteApp-feature. For each server in the farm, you must manually set up all applications in RemoteApp-manager after they`re installed. Although there is an export/import-feature in the GUI, many customers require no manual interaction in the server provisioning process. By the addition of the new PowerShell-provider for RDS, this is now possible in RemoteApp using scripting as part of either server provisioning or Group Policy.

For the average Windows sysadmin, I imagine that managing RemoteApp using the RDS PowerShell provider might be a bit tedious. To make this a little easier I`ve created a Windows PowerShell module for working with RDS RemoteApp, available from here.

This module contains the following functions:

  • Get-RDSRemoteApp
  • Export-RDSRemoteApps
  • Import-RDSRemoteApps
  • New-RDSRemoteApp
  • Remove-RDSRemoteApp

The functions let you administer the same application attributes as the graphical RemoteApp Manager:

  • Displayname
  • Alias
  • Command-line arguments
  • RD Web Access availability
  • User Assignment

 

Installing the RDSRemoteApp module

Download and unzip RDSRemoteApp.zip in the following location: %userprofile%\Documents\WindowsPowerShell\Modules\RDSRemoteApp

Alternatively you may save the module in any of the folders in the $Env:PSMODULEPATH variable.

Using the RDSRemoteApp module

First we`ll have a look at the RemoteApp Manager application-list in the lab-environment:

image

Start Windows PowerShell on the RDS-server and import the module (you will need to run PowerShell with Administrative privileges):

image

Since I`ve leveraged the built-in help capabilities in Windows PowerShell v2 Advanced Functions, I`ll show the usage of the functions with a few screenshots from the help:

Get-RDSRemoteApp

image

New-RDSRemoteApp

image

Remove-RDSRemoteApp

  image

Export-RDSRemoteApps

image

Import-RDSRemoteApps

image 

Sample usage for export/import:

image

Be aware that there are several other RDS settings that may be managed using the PowerShell provider, this module only leverages the RemoteApp functionality. If someone want to create a module for managing other aspects of RDS, feel free to include my RDSRemoteApp module. And as always, suggestions for improvements and new functionality are more than welcome.

Advertisements

June 30, 2010 Posted by | Deployment, Remote Desktop Services, Scripting, Terminal Services, Windows PowerShell, Windows Server 2008 R2 | | 3 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

Automate Group Policy Preferences printer-management using Windows PowerShell

I`ve written a couple of blog posts earlier on Group Policy Preferences and printer deployment using Group Policy.

Using Group Policy Preferences is a very flexible way to deploy printer connections. This is also very manageable in smaller environments. What if you got hundreds, or even thousands of printer connections you need to deploy? Do you want to sit down and make several thousands of mouse clicks to accomplish the task? There are better alternatives!

Based on SDM Software`s Group Policy Automation Engine, I`ve created a script module to handle this. The script module are available from this link.

Save the script module as a psm1-file in the following directory: %userprofile%\Documents\WindowsPowerShell\Modules\GPPreferencesPrinters
You need to manually create the 3 subfolders under %userprofile%\Documents if they doesn`t exist.

When done, start Windows PowerShell and type the following command:

image

You should now see the GPPreferencesPrinters module.
Import the module with the Import-Module cmdlet:

image

As you can see there are two functions in addition to SDM Software`s cmdlet: Add-GPPreferencesPrinter and Get-GPPreferencesPrinter.

Example 1:

image

Example 2:

If you got the printers listed in an Excel spreadsheet, save the document in csv-format:

image

The csv-file may be used like this to import the printer connections:

image

image

Additional functions and parameters will later be added to the script module, i.e. Remove-GPPreferencesPrinter and Item-Level Targeting. Note that example usage for Item-Level Targeting are provided in the Group Policy Automation Engine User Manual.

January 18, 2010 Posted by | Active Directory management, Deployment, Group Policy, Print management, Scripting, Windows PowerShell | 6 Comments

Mapping printers based on Active Directory group membership using Windows PowerShell

While researching for a logon script setup for mapping network printers using Windows PowerShell, I thought of using the Windows native tool printui.dll for the actual printer mappings.
However, I was`nt quite sure how to check for a users` group membership in Active Directory. This sure can be accomplished with a tool like Quest`s PowerShell Commands for Active Directory. However, installing this on every domain computer wasn`t an option.
Then I found Andy Grogan`s PowerShell function for determining AD group membership.

Based on this function, and the printui.dll the task was easy to accomplish. I`ve published a sample script to PoshCode.org, available from here.

You may also want to check out “PrintUI.DLL User’s Guide and Reference“.

Tested with Windows PowerShell v 1.0/2.0 and Windows XP/Vista/7.

As an alternative, you may also want to check out this blog post on mapping printers using Group Policy.

November 28, 2009 Posted by | Deployment, Print management, Scripting, Windows PowerShell | Leave a comment

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

How to upgrade from MDT 2008 Update 1 to MDT 2010

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

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

 

The upgrade procedure

1) Uninstall earlier versions of Windows Automated Installation Kit

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

3) Download and install Microsoft Deployment Toolkit 2010

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

image

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

Specify the path to your Deployment Share.

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

image

Press “Next”:

image

Review any warnings and press Finish:

image

Your Deployment Share are now available in the Deployment Workbench:

image

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

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

image

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

image

 

image

image

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

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

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

image

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

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

September 25, 2009 Posted by | Deployment, MDT 2010 | | Leave a comment

New features in Microsoft Deployment Toolkit 2010

MDT 2010 was released September 9th 2009.

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

New Feature #1: Logging directly to the network

New Feature #2: Gathering virtualization details

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

New Feature #4: Folders everywhere

New Feature #5: Support for multiple deployment shares

New Feature #6: Drag and drop

New Feature #7: Boot image creation optimized

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

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

New Feature #10: Detection of signed drivers

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

New Feature #12: USMT 4.0 hardlink support

New Feature #13: New task sequence templates

New Feature #14: Database improvements

New Feature #15: Finish actions

New Feature #16: PowerShell support

New Feature #17: Customizable boot image process

New Feature #18: Selection Profiles

New Feature #19: Improved Driver Management

Other interesting posts on Michael`s blog:

Running PowerShell scripts as part of a task sequence

Automatically update MDT 2010 boot images in WDS

 

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

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

The Deployment Guys` blog are also an excellent resource.

September 24, 2009 Posted by | Deployment, MDT 2010 | | 2 Comments

Integration between MDT 2008 and SCCM 2007

I`m scheduled for exam 70-635 (Microsoft Deployment Toolkit 2008, Desktop Deployment) next Friday, and I`ve been looking around for some study materials.
Microsoft`s exam information can be found here. Beside the preparation materials submitted by Microsoft there really aren`t much info about this exam to find. Although I`ve found Garth Jones` excellent wiki for this exam.

During the last months I`ve been working quite much with MDT 2008. I`ve not worked that much with System Center Configuration Manager 2007, so I didn`t really understand the value of MDT on top of SCCM until I saw this excellent video by Richard Smith (Microsoft UK) posted on Technet Edge. If you are working with MDT or SCCM I would really recommend this video.

Beside this I`ve read through the documentation provided in the MDT 2008 Workbench:

image

If you know more resources for either MDT or SCCM (which I`m also planning to learn more extensively), please post a comment to this blog post.

March 15, 2009 Posted by | Deployment | 1 Comment

Looking at MDT 2010 beta

 

While testing the betas of Windows 7 and Windows Server 2008 R2 these days like many others I`ve also had a look at the beta of the next version of Microsoft Deployment Toolkit.
I installed it on the Windows Server 2008 R2 server and deployed Windows 7 on a virtual machine. Haven`t noticed any bugs so far.
It doesn`t seem to be that many noticeable changes from the current 2008-version of the MDT. The GUI looks exactly the same, but there are some new features of course.

The list below is copied from the “What`s New In MDT 2010 Guide” on the Microsoft Connect website for MDT 2010 beta.

 

The MDT 2010 Beta 1 release includes the following new features:

· Support for Windows 7 Beta. Deploy Windows 7 Beta by using MDT 2010 Beta 1.

· Support for Windows Server 2008 R2 Beta. Deploy Windows Server 2008 R2 Beta by using MDT 2010 Beta 1.

· Support for Windows Automated Installation Kit (Windows AIK) version 2.0. Deployment of Windows 7 Beta and Windows Server 2008 R2 Beta by using MDT 2010 Beta 1 requires the use of Windows AIK version 2.0.

· Support for Windows User State Migration Toolkit (USMT) version 4.0. USMT 4.0 is required to support Windows 7 Beta deployments. Specifically, the following new features of USMT 4.0 are supported in LTI-based deployments:

· Support for USMT 4.0 hardlink migration. USMT 4.0 includes a new method of saving user state called hardlink migration. Hardlink migration creates a snapshot of current user data files before reinstallation, which keeps data in the same location on the disk while upgrading the system and rebuilds the links after Windows 7 Beta is installed. Hardlink migration dramatically reduces the time required to migrate user state, because the data is never moved, which is faster than copying the user data to another disk.

· Support for USMT 4.0 shadow copy. USMT 4.0 supports the ability to archive files that are in use by using the shadow copy feature in Windows 7 Beta and Windows Server 2008 R2 Beta.

· Support for the Deployment Image Servicing and Management (DISM) tool. The new DISM tool (Dism.exe) allows for servicing offline images, mounting and unmounting Windows Imaging format (WIM) files, and customizing Windows Preinstallation Environment (Windows PE) boot images. The DISM tool replaces many of the tools in previous versions of the Windows AIK, including Package Manager (Pkgmgr.exe), the International Settings Configuration Tool (Intlcfg.exe), and the Windows PE command-line tool (PEimg.exe).

· Support for Windows PE version 3.0. Windows PE 3.0 is included as a part of the Windows AIK version 2.0 and is required to deploy Windows 7 Beta and Windows Server 2008 R2 Beta by using MDT 2010 Beta 1.

· Support for the Boot Configuration Data (BCD) management tool. MDT 2010 Beta 1 uses the new BCDEdit command-line tool to manage BCD files. MDT 2008 Update 1 used the BitLocker™ Drive Preparation Tool (BdeHdCfg.exe) to manage boot configuration.

· Support for Windows 7 Beta default disk partition configuration. In MDT 2010 Beta 1, the disk partition configuration for Windows 7 Beta will be similar to the Windows BitLocker Drive Encryption disk configuration, where the operating system is installed on Disk 0, Partition 2, and the system partition is on Disk 0, Partition 1.

 

 

The new DISM tool which replaces ImageX and Peimg from the previous versions of Windows AIK seems to be really powerful. There isn`t any official documentation yet, but I found this forum post which got some useful information.

It doesn`t seem like MDT 2010 will contain any PowerShell features (snapins, modules or cmdlets) for administration or operations, so I guess this will come in the next version.

Upgrading from MDT 2008 to MDT 2010 is pretty straightforward, so if your using MDT today you will be well prepared for Windows 7 when MDT 2010 is released.

January 16, 2009 Posted by | Deployment | Leave a comment

Microsoft Deployment Toolkit 2008

Today I`ve walked through the TechNet Virtual Lab: Introduction to Microsoft Deployment Toolkit 2008, which was a good introduction to the MDT.

I would recommend all of you who are working with client (and server) deployment to have a look at MDT 2008 as it`s a very good tool to deploy clients (and upgrade existing ones).

More labcasts regarding deployment can be found here.
The MDT 2008 homepage can be found here, and the download page for the newest version here.

MDT combine existing Microsoft-products such as Windows Deployment Services for imaging and User State Migration Tool for migrating user profiles when reinstalling or upgrading a client.

I would also recommend you to check out the MS Deployment Toolkit Blog as well as The Deployment Guys` Blog.

December 20, 2008 Posted by | Deployment | Leave a comment