Thursday, April 28, 2011
Active Directory: Improving and Automating Identity and Access
Active Directory: Improving and Automating Identity and Access
1. Using Windows PowerShell with Active Directory 66
2. Selecting Functional Levels in Windows Server 2008 R2 78
3. Active Directory Recycle Bin: Recovering Deleted Objects 82
4. Offline Domain Join: Securing and Facilitating Deployment 86
5. Service Accounts 87
6. Best Practices Analyzer 88
For the Windows Server 2008 release, Microsoft consolidated and renamed its various
identity and access services to create the following five roles:
1. Active Directory Certificate Services (AD CS)
2. Active Directory Domain Services (AD DS)
3. Active Directory Federation Services (AD FS)
4. Active Directory Lightweight Directory Services (AD LDS)
5. Active Directory Rights Management Services (AD RMS)
For Windows Server 2008 R2, these five roles remain in place and the visible Active
Directory infrastructure is functionally the same. You can still install the roles the same
way, by using Server Manager or Windows Optional Component Setup (Ocsetup.exe)
from the command line, although the Add Roles Wizard now requires you to install the
Microsoft .NET Framework 3.5.1 feature with Active Directory Domain Services, Active
Directory Lightweight Directory Services, and Active Directory Rights Management
Services roles. This requirement is to support the new Active Directory Web Services
module.
Note For more information on Active Directory Web Services, see the section “Introducing
Active Directory Web Services,” later in this chapter.
Once you have installed the Active Directory roles you need, you will find that all of the
familiar Active Directory objects and attributes are still the same, and all of your familiar
tools are still there. However, although the Active Directory roles in Windows Server 2008 R2
appear to be the same as those in Windows Server 2008, there are some substantial innovations
beneath the surface, particularly in the area of Active Directory administration.
The R2 release includes a new set of tools for managing Active Directory from Windows
PowerShell, a new graphical management utility that is based on those same Windows
PowerShell
cmdlets, and a long-requested mechanism for restoring Active Directory objects
that administrators have inadvertently deleted. There is also a new facility for joining workstations
to an AD DS domain when they do not have access to a domain controller, and an
Active Directory implementation of the Best Practices Analyzer (BPA) technology that should
be familiar to administrators of Microsoft Exchange Server.
These are all improvements that administrators can avoid entirely, if they so desire. You can
skip right over this chapter if you want to and continue to work with Active Directory the way
you always have on your new Windows Server 2008 R2 servers, and everything will function
just as it always has. However, if you choose to persevere and examine these new features,
you might find yourself approaching your Active Directory management tasks in a completely
new and better way. You might even learn to love the command prompt.
Using Windows PowerShell with Active Directory:
As in many other areas of its operating system, Windows Server 2008 R2 leverages Windows
PowerShell as a major new management tool for Active Directory. Windows Server 2008
R2 includes no fewer than 85 new cmdlets for AD DS and AD LDS, which are designed to
replace the existing (non–Windows PowerShell) command prompt tools, such as Dsget.exe, Dsmod.
exe, and Dsadd.exe. For administrators not comfortable working from the command
prompt, Windows Server 2008 R2 also includes Active Directory Administrative Center
(ADAC), a new management console that provides a graphical interface to the functionality of
the Windows PowerShell cmdlets.
Using Active Directory Module for Windows PowerShell:
You have already read about the enhanced capabilities of Windows PowerShell 2.0 in Chapter
1, “What’s New in Windows Server 2008 R2,” and you have seen some of what Windows
PowerShell can do with Hyper-V and Remote Desktop Services in Chapter 3, “Hyper-V: Scaling
and Migrating Virtual Machines,” and Chapter 4, “Remote Desktop Services and VDI: Centralizing
Desktop and Application Management.” Another major innovation in Windows Server
2008 R2 is the ability to use Windows PowerShell cmdlets to manage the AD DS and AD LDS
roles.
Using Windows PowerShell with Active Directory
Windows Server 2008 R2 implements the cmdlets for Active Directory management as a
Windows PowerShell module called ActiveDirectory. A Windows PowerShell 2.0 module is a
self-contained unit consisting of cmdlets, scripts, or other code that you must import into a
Windows PowerShell session before you can access its features.
Importing the Active Directory Module:
When you add the AD DS or AD LDS role on a computer running Windows Server 2008 R2,
the system installs the Active Directory Module for Windows PowerShell and creates a shortcut
with the same name in the Administrative Tools program group. This shortcut launches
the Windows PowerShell environment and uses the Import-Module cmdlet to load the Active
Directory module. You can also import the module manually from a standard Windows
PowerShell
prompt by using the following command:
Import-Module ActiveDirectory
Once you have imported the module, the Active Directory cmdlets it contains become
available, but only within that Windows PowerShell session. If you open up another Windows
PowerShell window (without importing the module), the Active Directory cmdlets are not
available in that session.
Using the Active Directory Module Cmdlets:
Active Directory Module for Windows PowerShell contains 90 cmdlets not found in a standard
Windows PowerShell session. Most (but not all) of the cmdlets in the module include the
initials AD as part of their names, so you can list them using the following command:
Get-Command *-AD*
The Active Directory cmdlets, which you can use individually or combine using the standard
PowerShell piping techniques, provide almost universal administrative access to AD DS
and AD LDS resources. For example, to create new AD DS objects, you can use any of the
following cmdlets:
1. New-ADUser
2. New-ADComputer
3. New-ADGroup
4. New-ADOrganizationalUnit
5. New-ADObject
Each of these cmdlets supports parameters representing the possible attributes of the new
object. For example, the New-ADUser cmdlet has 60 possible parameters, as shown in Figure
5-1, generated by the Get-Help New-ADUser command.
Figure 5-1 Command-line parameters for the New-ADUser cmdlet.
These parameters not only enable you to create a new object, but you can also specify
values for many of the object’s attributes using a single command, such as in the following
example:
New-ADUser –Name “Mark Lee” -SamAccountName “MarkLee” -GivenName “Mark”
-Surname “Lee” -DisplayName “Mark Lee” -Path ‘CN=Users,DC=example,DC=local’
-OfficePhone “717-555-1212” -Title “Account Manager”
-EmailAddress “mlee@example.com” -ChangePasswordAtLogon $true
Consider how many different processes you would have to perform and how many screens
you would have to access to create the user object for Mark Lee and set all the attributes
defined in this example using the Active Directory Users and Computers console. For custom
attributes, and those not specifically covered by a cmdlet’s parameters, you can use the
–OtherAttributes parameter, and to create objects not explicitly supported by a cmdlet, you
can use New-ADObject, and specify the type of object you want to create.
Of course, for any serious Windows PowerShell user, command-line parameters are only
one way to specify attribute values when creating a new object with the New-ADUser cmdlet.
Another possible method is to use an existing object as a template. When you specify the
name of the object you want to use as a template on the New-ADUser command line, using
the –instance parameter, the system copies all of the attribute values from the template to
the new object, except for those overridden by other parameters on the command line.
Yet another method, suitable for creating multiple Active Directory objects using a single
command, is to create a comma-separated value (CSV) file containing a list of the objects you
want to create and their attribute values. You can then use the Import-CSV cmdlet to pipe the
contents of the CSV file to the New-ADObject cmdlet, and the system will create each object
listed in the file in turn.
In addition to cmdlets for creating Active Directory objects, there are also cmdlets for
manipulating them, such as the following examples:
1. Set-ADObject Modifies the properties of an Active Directory object
2. Get-ADObject Gets or performs a search to retrieve one or more Active Directory
objects
3. Move-ADObject Moves an Active Directory object or container from one container
to another or from one domain to another
4. Restore-ADObject Restores a deleted Active Directory object
5. Rename-ADObject Renames an Active Directory object
6. Remove-ADObject Removes an Active Directory object
A comprehensive treatise on managing Active Directory using the capabilities provided by
the Active Directory Module for Windows PowerShell could easily fill this book. The preceding
are some extremely basic examples of how, with a little study and a little practice, you
can learn to enhance and streamline the processes by which you perform your regular Active
Directory management tasks, using the tools provided in Windows Server 2008 R2.
1. Using Windows PowerShell with Active Directory 66
2. Selecting Functional Levels in Windows Server 2008 R2 78
3. Active Directory Recycle Bin: Recovering Deleted Objects 82
4. Offline Domain Join: Securing and Facilitating Deployment 86
5. Service Accounts 87
6. Best Practices Analyzer 88
For the Windows Server 2008 release, Microsoft consolidated and renamed its various
identity and access services to create the following five roles:
1. Active Directory Certificate Services (AD CS)
2. Active Directory Domain Services (AD DS)
3. Active Directory Federation Services (AD FS)
4. Active Directory Lightweight Directory Services (AD LDS)
5. Active Directory Rights Management Services (AD RMS)
For Windows Server 2008 R2, these five roles remain in place and the visible Active
Directory infrastructure is functionally the same. You can still install the roles the same
way, by using Server Manager or Windows Optional Component Setup (Ocsetup.exe)
from the command line, although the Add Roles Wizard now requires you to install the
Microsoft .NET Framework 3.5.1 feature with Active Directory Domain Services, Active
Directory Lightweight Directory Services, and Active Directory Rights Management
Services roles. This requirement is to support the new Active Directory Web Services
module.
Note For more information on Active Directory Web Services, see the section “Introducing
Active Directory Web Services,” later in this chapter.
Once you have installed the Active Directory roles you need, you will find that all of the
familiar Active Directory objects and attributes are still the same, and all of your familiar
tools are still there. However, although the Active Directory roles in Windows Server 2008 R2
appear to be the same as those in Windows Server 2008, there are some substantial innovations
beneath the surface, particularly in the area of Active Directory administration.
The R2 release includes a new set of tools for managing Active Directory from Windows
PowerShell, a new graphical management utility that is based on those same Windows
PowerShell
cmdlets, and a long-requested mechanism for restoring Active Directory objects
that administrators have inadvertently deleted. There is also a new facility for joining workstations
to an AD DS domain when they do not have access to a domain controller, and an
Active Directory implementation of the Best Practices Analyzer (BPA) technology that should
be familiar to administrators of Microsoft Exchange Server.
These are all improvements that administrators can avoid entirely, if they so desire. You can
skip right over this chapter if you want to and continue to work with Active Directory the way
you always have on your new Windows Server 2008 R2 servers, and everything will function
just as it always has. However, if you choose to persevere and examine these new features,
you might find yourself approaching your Active Directory management tasks in a completely
new and better way. You might even learn to love the command prompt.
Using Windows PowerShell with Active Directory:
As in many other areas of its operating system, Windows Server 2008 R2 leverages Windows
PowerShell as a major new management tool for Active Directory. Windows Server 2008
R2 includes no fewer than 85 new cmdlets for AD DS and AD LDS, which are designed to
replace the existing (non–Windows PowerShell) command prompt tools, such as Dsget.exe, Dsmod.
exe, and Dsadd.exe. For administrators not comfortable working from the command
prompt, Windows Server 2008 R2 also includes Active Directory Administrative Center
(ADAC), a new management console that provides a graphical interface to the functionality of
the Windows PowerShell cmdlets.
Using Active Directory Module for Windows PowerShell:
You have already read about the enhanced capabilities of Windows PowerShell 2.0 in Chapter
1, “What’s New in Windows Server 2008 R2,” and you have seen some of what Windows
PowerShell can do with Hyper-V and Remote Desktop Services in Chapter 3, “Hyper-V: Scaling
and Migrating Virtual Machines,” and Chapter 4, “Remote Desktop Services and VDI: Centralizing
Desktop and Application Management.” Another major innovation in Windows Server
2008 R2 is the ability to use Windows PowerShell cmdlets to manage the AD DS and AD LDS
roles.
Using Windows PowerShell with Active Directory
Windows Server 2008 R2 implements the cmdlets for Active Directory management as a
Windows PowerShell module called ActiveDirectory. A Windows PowerShell 2.0 module is a
self-contained unit consisting of cmdlets, scripts, or other code that you must import into a
Windows PowerShell session before you can access its features.
Importing the Active Directory Module:
When you add the AD DS or AD LDS role on a computer running Windows Server 2008 R2,
the system installs the Active Directory Module for Windows PowerShell and creates a shortcut
with the same name in the Administrative Tools program group. This shortcut launches
the Windows PowerShell environment and uses the Import-Module cmdlet to load the Active
Directory module. You can also import the module manually from a standard Windows
PowerShell
prompt by using the following command:
Import-Module ActiveDirectory
Once you have imported the module, the Active Directory cmdlets it contains become
available, but only within that Windows PowerShell session. If you open up another Windows
PowerShell window (without importing the module), the Active Directory cmdlets are not
available in that session.
Using the Active Directory Module Cmdlets:
Active Directory Module for Windows PowerShell contains 90 cmdlets not found in a standard
Windows PowerShell session. Most (but not all) of the cmdlets in the module include the
initials AD as part of their names, so you can list them using the following command:
Get-Command *-AD*
The Active Directory cmdlets, which you can use individually or combine using the standard
PowerShell piping techniques, provide almost universal administrative access to AD DS
and AD LDS resources. For example, to create new AD DS objects, you can use any of the
following cmdlets:
1. New-ADUser
2. New-ADComputer
3. New-ADGroup
4. New-ADOrganizationalUnit
5. New-ADObject
Each of these cmdlets supports parameters representing the possible attributes of the new
object. For example, the New-ADUser cmdlet has 60 possible parameters, as shown in Figure
5-1, generated by the Get-Help New-ADUser command.
Figure 5-1 Command-line parameters for the New-ADUser cmdlet.
These parameters not only enable you to create a new object, but you can also specify
values for many of the object’s attributes using a single command, such as in the following
example:
New-ADUser –Name “Mark Lee” -SamAccountName “MarkLee” -GivenName “Mark”
-Surname “Lee” -DisplayName “Mark Lee” -Path ‘CN=Users,DC=example,DC=local’
-OfficePhone “717-555-1212” -Title “Account Manager”
-EmailAddress “mlee@example.com” -ChangePasswordAtLogon $true
Consider how many different processes you would have to perform and how many screens
you would have to access to create the user object for Mark Lee and set all the attributes
defined in this example using the Active Directory Users and Computers console. For custom
attributes, and those not specifically covered by a cmdlet’s parameters, you can use the
–OtherAttributes parameter, and to create objects not explicitly supported by a cmdlet, you
can use New-ADObject, and specify the type of object you want to create.
Of course, for any serious Windows PowerShell user, command-line parameters are only
one way to specify attribute values when creating a new object with the New-ADUser cmdlet.
Another possible method is to use an existing object as a template. When you specify the
name of the object you want to use as a template on the New-ADUser command line, using
the –instance parameter, the system copies all of the attribute values from the template to
the new object, except for those overridden by other parameters on the command line.
Yet another method, suitable for creating multiple Active Directory objects using a single
command, is to create a comma-separated value (CSV) file containing a list of the objects you
want to create and their attribute values. You can then use the Import-CSV cmdlet to pipe the
contents of the CSV file to the New-ADObject cmdlet, and the system will create each object
listed in the file in turn.
In addition to cmdlets for creating Active Directory objects, there are also cmdlets for
manipulating them, such as the following examples:
1. Set-ADObject Modifies the properties of an Active Directory object
2. Get-ADObject Gets or performs a search to retrieve one or more Active Directory
objects
3. Move-ADObject Moves an Active Directory object or container from one container
to another or from one domain to another
4. Restore-ADObject Restores a deleted Active Directory object
5. Rename-ADObject Renames an Active Directory object
6. Remove-ADObject Removes an Active Directory object
A comprehensive treatise on managing Active Directory using the capabilities provided by
the Active Directory Module for Windows PowerShell could easily fill this book. The preceding
are some extremely basic examples of how, with a little study and a little practice, you
can learn to enhance and streamline the processes by which you perform your regular Active
Directory management tasks, using the tools provided in Windows Server 2008 R2.
Monday, April 25, 2011
License Server Assignment and Activation
Licensing:
The Remote Desktop Services role and its role services are included as part of the standard
Windows Server license and do not require any additional licenses. The RD Session Host
license is also covered by the Windows Server license with the same considerations as any
other Hyper-V host.
Each user or device that directly or indirectly accesses a computer running Windows
Server to interact with a remote graphical user interface (using the Windows Server 2008 R2
RDS functionality or other technology) must have a Windows Server 2008 RDS Client Access
License (CAL) in addition to the Windows Server CAL. RDS functionality is considered those
features or services that are enabled with the RDS role and/or role service(s) in Windows
Server 2008 R2. This includes, but is not limited to, RD Gateway, RemoteApp, RD Web Access,
and RD Connection Broker.
RDS CALs are available as Per User or Per Device CALs. RD Session Host servers are configured
for Per Device or Per User mode, and require an appropriate RDS CAL for access.
Licensing
Each Per Device RDS CAL allows one device to connect to the RDS resources, regardless
of how many users use the device. Conversely, a Per User RDS CAL allows a single user access
to the RDS resources from as many devices as he or she happens to have. Companies should
carefully consider their users and the type of devices and access they need to RDS resources
before purchasing CALs and deciding what mode RD Session Host servers will use.
Windows Server 2008 R2 RDS CALs and Windows Server 2008 TS CALs are equivalent and
can be used interchangeably. However, RDS CALs can only be managed from Windows Server
2008 SP2 Terminal Server License servers or Windows Server 2008 R2 RD License servers. The
RD Licensing Manager, shown in Figure 4-13, adds important new capabilities, including the
ability to automatically migrate licenses and dynamically activate or deactivate license servers.
Figure 4-13 The RD Licensing Manager
License Server Assignment and Activation
Windows Server 2008 R2 changes how RDS Session Hosts locate and connect to license servers.
In Windows Server 2008, Terminal Servers used a discovery mechanism to find and connect
to a license server. This created problems if the license server was unavailable, or if the
discovery process encountered problems, and it became the source of a significant number of
support calls. In Windows Server 2008 R2, this is changed so that RD Session Hosts explicitly
specify the RD License servers they will connect to, as shown in Figure 4-14, and when a specific
license server is unavailable, licenses are automatically migrated.
and VDI: Centralizing Desktop
and Application Management
Figure 4-14 The RD Licensing Server is specified in the RD Session Host Configuration console.
When an RD Session Host is initially installed, it has a 120-day grace period before a
license server needs to be specified. If no license server is specified and available at the end
of that grace period, the RD Session Host will stop accepting connections. This grace period
cannot be reset and is not an “evaluation” or “temporary” license.
Virtual Desktop Licensing:
Complete and correct licensing of a Microsoft VDI environment requires licensing of both the
Windows client operating system running in a centralized location and the infrastructure and
management components that enable an end-to-end VDI environment.
Virtual Enterprise Centralized Desktop (VECD) is the license for Windows as a guest operating
system in the data center. VECD is available for client devices that are covered by Software
Assurance (VECD for SA), and those that are not, including devices such as thin clients. VECD
or VECD for SA is required for any VDI environment running Windows as the guest operating
system.
Most VDI environments also include management components such as System Center
Virtual Machine Manager (SCVMM) or System Center Operations Manager to manage the
environment. For licensing the infrastructure and management components of a Microsoft
VDI environment, there are essentially two options: You can license the infrastructure components
(RD Session Host, RD Virtualization Host, RD Connection Broker, etc.) with RDS CALs
and license the management components separately; or, if you’re a Volume License customer,
you have a pair of new options—the Microsoft Virtual Desktop Infrastructure Standard Suite
and the Microsoft Virtual Desktop Infrastructure Premium Suite. These two suites combine
the products for an optimum VDI experience in a value package.
1. Microsoft Virtual Desktop Infrastructure Standard Suite (VDI Standard
Suite) Includes the core products and CALs required to enable and manage VDI,
including:
• Remote Desktop Services (RDS) The RDS component of the VDI Suite is
licensed solely for use in a VDI context; it does not provide a license to use sessionbased
RDS resources.
• Microsoft Desktop Optimization Pack (MDOP) This is a collection of technologies
that enable desktop virtualization and management, including App-V.
• System Center Virtual Machine Manager (SCVMM) Client Management
License This provides centralized management of the Microsoft® Hyper-V™-
based virtualization components of the VDI host.
• System Center Configuration Manager Standard Server Management
License This provides centralized configuration management of the (physical) VDI
hosts of the VDI Suite.
• System Center Operations Manager Standard Server Management
License This provides centralized monitoring and performance management of
the physical VDI host of the VDI Suite.
n Microsoft Virtual Desktop Infrastructure Premium Suite (VDI Premium
Suite) Includes all the components of the VDI Standard Suite, plus the following:
• App-V for RDS This provides application-level virtualization for RDS sessions.
• RDS The RDS license is not use restricted to the VDI scenario only, but can also be
used for session-based desktop and applications scenarios.
Note T he System Center components of the VDI Suites are only licensed for use in a VDI
scenario, and can’t be used for general management of virtualization hosts with mixed
workloads.
The Remote Desktop Services role and its role services are included as part of the standard
Windows Server license and do not require any additional licenses. The RD Session Host
license is also covered by the Windows Server license with the same considerations as any
other Hyper-V host.
Each user or device that directly or indirectly accesses a computer running Windows
Server to interact with a remote graphical user interface (using the Windows Server 2008 R2
RDS functionality or other technology) must have a Windows Server 2008 RDS Client Access
License (CAL) in addition to the Windows Server CAL. RDS functionality is considered those
features or services that are enabled with the RDS role and/or role service(s) in Windows
Server 2008 R2. This includes, but is not limited to, RD Gateway, RemoteApp, RD Web Access,
and RD Connection Broker.
RDS CALs are available as Per User or Per Device CALs. RD Session Host servers are configured
for Per Device or Per User mode, and require an appropriate RDS CAL for access.
Licensing
Each Per Device RDS CAL allows one device to connect to the RDS resources, regardless
of how many users use the device. Conversely, a Per User RDS CAL allows a single user access
to the RDS resources from as many devices as he or she happens to have. Companies should
carefully consider their users and the type of devices and access they need to RDS resources
before purchasing CALs and deciding what mode RD Session Host servers will use.
Windows Server 2008 R2 RDS CALs and Windows Server 2008 TS CALs are equivalent and
can be used interchangeably. However, RDS CALs can only be managed from Windows Server
2008 SP2 Terminal Server License servers or Windows Server 2008 R2 RD License servers. The
RD Licensing Manager, shown in Figure 4-13, adds important new capabilities, including the
ability to automatically migrate licenses and dynamically activate or deactivate license servers.
Figure 4-13 The RD Licensing Manager
License Server Assignment and Activation
Windows Server 2008 R2 changes how RDS Session Hosts locate and connect to license servers.
In Windows Server 2008, Terminal Servers used a discovery mechanism to find and connect
to a license server. This created problems if the license server was unavailable, or if the
discovery process encountered problems, and it became the source of a significant number of
support calls. In Windows Server 2008 R2, this is changed so that RD Session Hosts explicitly
specify the RD License servers they will connect to, as shown in Figure 4-14, and when a specific
license server is unavailable, licenses are automatically migrated.
and VDI: Centralizing Desktop
and Application Management
Figure 4-14 The RD Licensing Server is specified in the RD Session Host Configuration console.
When an RD Session Host is initially installed, it has a 120-day grace period before a
license server needs to be specified. If no license server is specified and available at the end
of that grace period, the RD Session Host will stop accepting connections. This grace period
cannot be reset and is not an “evaluation” or “temporary” license.
Virtual Desktop Licensing:
Complete and correct licensing of a Microsoft VDI environment requires licensing of both the
Windows client operating system running in a centralized location and the infrastructure and
management components that enable an end-to-end VDI environment.
Virtual Enterprise Centralized Desktop (VECD) is the license for Windows as a guest operating
system in the data center. VECD is available for client devices that are covered by Software
Assurance (VECD for SA), and those that are not, including devices such as thin clients. VECD
or VECD for SA is required for any VDI environment running Windows as the guest operating
system.
Most VDI environments also include management components such as System Center
Virtual Machine Manager (SCVMM) or System Center Operations Manager to manage the
environment. For licensing the infrastructure and management components of a Microsoft
VDI environment, there are essentially two options: You can license the infrastructure components
(RD Session Host, RD Virtualization Host, RD Connection Broker, etc.) with RDS CALs
and license the management components separately; or, if you’re a Volume License customer,
you have a pair of new options—the Microsoft Virtual Desktop Infrastructure Standard Suite
and the Microsoft Virtual Desktop Infrastructure Premium Suite. These two suites combine
the products for an optimum VDI experience in a value package.
1. Microsoft Virtual Desktop Infrastructure Standard Suite (VDI Standard
Suite) Includes the core products and CALs required to enable and manage VDI,
including:
• Remote Desktop Services (RDS) The RDS component of the VDI Suite is
licensed solely for use in a VDI context; it does not provide a license to use sessionbased
RDS resources.
• Microsoft Desktop Optimization Pack (MDOP) This is a collection of technologies
that enable desktop virtualization and management, including App-V.
• System Center Virtual Machine Manager (SCVMM) Client Management
License This provides centralized management of the Microsoft® Hyper-V™-
based virtualization components of the VDI host.
• System Center Configuration Manager Standard Server Management
License This provides centralized configuration management of the (physical) VDI
hosts of the VDI Suite.
• System Center Operations Manager Standard Server Management
License This provides centralized monitoring and performance management of
the physical VDI host of the VDI Suite.
n Microsoft Virtual Desktop Infrastructure Premium Suite (VDI Premium
Suite) Includes all the components of the VDI Standard Suite, plus the following:
• App-V for RDS This provides application-level virtualization for RDS sessions.
• RDS The RDS license is not use restricted to the VDI scenario only, but can also be
used for session-based desktop and applications scenarios.
Note T he System Center components of the VDI Suites are only licensed for use in a VDI
scenario, and can’t be used for general management of virtualization hosts with mixed
workloads.
Saturday, April 23, 2011
Remote Desktop Administration and Management
Remote Desktop Administration and Management:
The RemoteApp and Desktop Connection Web application gives IT administrators a single
place to manage and assign resources for their users. Changes made here are directly
reflected in the RemoteApp and Desktop Connection Control Panel for Windows 7 users,
and in the applications and virtual desktops that users connecting from earlier versions of
Windows
see when they log in to the RD Web Access server, as shown in Figure 4-2
.
50 CHAPTER 4 Remote Desktop Services
and VDI: Centralizing Desktop
and Application Management
Figure 4-2 The RemoteApp and Desktop Connection page from a Windows XP SP3 computer.
The Windows 7 computer of the same user directly integrates these same links into the
user’s Start menu, as shown in Figure 4-3.
Figure 4-3 RemoteApp and Desktop Connections are directly integrated into the Windows 7 Start menu.
Whenever an administrator makes changes to the available programs or virtual desktops,
both the RD Web Access page and the user’s Start menu are dynamically updated without
further intervention.
(Re)introducing Remote Desktop Services and VDI CHAPTER 4 51
Windows PowerShell Module:
Windows Server 2008 R2 includes a new Windows PowerShell module, the RemoteDesktopServices
module, that includes both cmdlets and a full RDS Provider, as shown in Figure 4-4.
Figure 4-4 The RemoteDesktopServices module for Windows PowerShell includes both cmdlets and a
provider.
For those new to Windows PowerShell, a brief explanation of providers is in order. In
Windows PowerShell, providers are a way to view and navigate information in a hierarchical
way as if the providers were drives on the computer. In fact, the FileSystem is implemented as
a provider. This means that when you type dir c:\ at the Windows PowerShell prompt, what
you’re actually doing is asking Windows PowerShell to give you the children of the C drive
of the FileSystem provider. (The dir command is an alias for Get-ChildItem.) Windows PowerShell
implements the Windows Registry as a provider as well, so you issue the command
dir HKLM:\System\CurrentControlSet to see what the HKeyLocalMachine registry
hive has in the System\CurrentControlSet container.
With the RemoteDesktopServices provider, the “drive” is RDS:. Beneath that top level we
have RDSConfiguration, GatewayServer, LicenseServer, RDSFarms, ConnectionBroker, and
RemoteApp containers. With the RDS Windows PowerShell module, you can configure and
manage all RDS role services and components using Windows PowerShell. For example, you
can do the following:
52 CHAPTER 4 Remote Desktop Services
and VDI: Centralizing Desktop
and Application Management
1. View and edit configuration settings of Remote Desktop Server
2. Publish RemoteApp applications
3. Configure License Server
4. Create and configure a Remote Desktop server farm
5. Configure and assign virtual Internet Protocol (IP) addresses to either sessions or applications
6. Create and manage RDV (VDI) pools
7. Create and manage Gateway Resource Access and Client Access policies
For example, with Windows PowerShell, you can quickly get a list of the personal virtual
desktop assigned to a particular user:
PSH> import-module RemoteDesktopServices
PSH> $cred = Get-Credential
PSH> Get-VirtualDesktop –user example\charlie –credential $cred
Name AssignedTo Host
---- ---------- ----
xmpl-vdi-92.example.local EXAMPLE\Charlie HOST-9.example.local
Because the RDS team implemented their Windows PowerShell support primarily as a provider,
it’s easy to navigate and investigate the functionality available, and also easy to get help
on how to do tasks. So, for example, if you want to know what the parameters are for creating
a new RemoteApp using Windows PowerShell, you just ask Windows PowerShell to tell you,
as shown in Figure 4-5.
You can also use Windows PowerShell to quickly get or set the value of various RDS settings,
as shown in Figure 4-6.
(Re)introducing Remote Desktop Services and VDI CHAPTER 4 53
Figure 4-5 Using the Get-Help command with the –path parameter to get specific help on creating
RemoteApps.
Figure 4-6 Getting the ConnectionBrokerSettings.
To change the session settings to disable new connections, the command would be as
follows:
RDS:\RDSConfiguration> Set-Item –path .\SessionSettings\AllowConnections 0
54 CHAPTER 4 Remote Desktop Services
and VDI: Centralizing Desktop
and Application Management
Windows 7 and RDS (Better Together)
Users running Windows 7 will have an enhanced user experience when using Remote Desktop.
Not only will they have more direct access to applications and desktops through the
RemoteApp and Desktop Connection (RAD) link in the Control Panel, but the overall experience
is more natural and integrated. RemoteApps are directly integrated into the Start menu,
Taskbar, and system tray, so that many users will be unable to tell whether a program is running
locally or remotely.
Improved User Experience
The improved user experience with Remote Desktop Services and Windows 7 clients includes
the following features:
1. Multimedia redirection This feature provides high-quality multimedia by redirecting
multimedia files and streams so that audio and video content is sent in its original
format from the server to the client and rendered using the client’s local media playback
capabilities.
2. True multimonitor support Remote Desktop Services enables support for up
to 10 monitors in almost any size, resolution, or layout with RemoteApp and remote
desktops. Applications will behave just like they do when running locally in multimonitor
configurations.
3. Audio input and recording VDI supports any microphone connected to a user’s
local machine and enables audio recording support for RemoteApp and Remote Desktop.
This is useful for Voice over Internet Protocol (VoIP) scenarios and also enables
speech recognition.
4. Windows Aero support VDI provides users with the ability to use the Windows
Aero user interface for client desktops, ensuring that remote desktop sessions look and
feel like local desktop sessions.
5. DirectX redirection Improvements in DirectX 9, 10, and 11 application rendering,
and support for the new DirectX 10.1 application programming interfaces (APIs)
that allow DirectX (2D& 3D) graphics to be redirected to the local client to harness the
power of the graphical processing unit (GPU) on the user’s local device, remove the
need for a GPU on the server.
6. Improved audio/video synchronization Remote Desktop Protocol (RDP)
improvements in Windows Server 2008 R2 are designed to provide closer synchronization
of audio and video in most scenarios.
7. Language bar redirection Users can control the language setting of RemoteApp
programs using the local language bar.
8. Task Scheduler Improvements keep scheduled applications from interacting with
users running RemoteApps, avoiding confusion.
Enabling VDI CHAPTER 4 55
RA D Control Panel
The RAD Control Panel applet, part of Windows 7, provides a simple way to configure
RemoteApp and VDI directly into the user’s Start menu. Plus, once the initial connection is
made, applications and desktops are automatically updated as the administrator configures
the available applications and desktops, simplifying management and deployment.
Configuring RemoteApp and Desktop Connection
To change the settings for RAD, use the Remote Desktop Connection Manager console, as
shown in Figure 4-7.
Figure 4-7 The Remote Desktop Connection Manager console.
The Remote Desktop Connection Manager connects to an RD Connection Broker, and
allows you to configure the RD Virtualization Host servers and the personal and pooled
virtual desktops they provide, along with designating the RemoteApp sources that will be
available to the RD Connection Broker.
Enabling VDI
Windows Server 2008 R2 adds support for both personal and pooled virtual desktops.
Enabling that VDI support requires setting up and configuring an RD Virtualization Host, an
RD Session Host, an RD Connection Broker, and an RD Web Access server, although these
and VDI: Centralizing Desktop
and Application Management
different roles can be combined as appropriate for your environment. The basic steps to
enabling VDI are as follows:
1. Enable the RD Virtualization Host role service of the Remote Desktop Services role.
This will also enable the Hyper-V role.
Note E nabling the Hyper-V role requires hardware that supports hardware virtualization.
This might require an updated BIOS. The BIOS must be configured to support both
hardware virtualization and hardware Data Execution Protection.
2. Enable an RD Session Host. This is required both for VDI and to provide RemoteApp
programs.
3. Enable an RD Connection Broker and an RD Web Access server.
4. Export the Secure Sockets Layer (SSL) certificate for the RD Web Access computer. This
will be imported onto the virtual machines (VMs).
5. Create the VMs that will be used, configuring them as appropriate. These will be used
either as part of a VDI pool or as personal VMs.
• Add the SSL machine certificate from the RD Web Access computer to them.
• Enable Remote Access.
• Allow Remote RPC for RDS in the registry.
• Enable Remote Service Management in Windows Firewall.
• Add RDP protocol permissions to the VMs.
• Configure the VMs for rollback if they’re part of a VDI pool.
6. Add the RD Web Access computer to the TS Web Access Computers local group on the
RD Connection Broker.
7. Add the RD Connection Broker computer as a source for the RD Web Access computer,
as shown in Figure 4-8.
Enabling
Figure 4-8 Configure RD Web Access to use an RD Connection Broker as a source.
8. Configure the VDI Pool and assign any Personal Virtual Desktops on the RD Connection
Broker as shown in Figure 4-9.
Figure 4-9 Adding virtual machines to a Virtual Desktop Pool.
58 CHAPTER 4 Remote Desktop Services
and VDI: Centralizing Desktop
and Application Management
9. Add applications to the RemoteApp server and make them available as RemoteApps.
10. Log on to the client computer as an administrator and import the machine SSL certificate
from the RD Web Access server.
11. Log on to the client computer and set up the RemoteApp and Desktop Connection.
Yes, this is fairly complicated, but most of these steps are performed one time only, or can
be easily automated.
Integrating Remote and Local Applications with
RemoteApp
RemoteApp for Windows Server 2008 R2 gives you the ability to provide your users with an
integrated and transparent mixture of local and remote applications. For applications that
behave best when run locally, or that are used when not connected to the network, you can
install the applications locally, while providing access to other applications using RemoteApp
where appropriate. Applications running remotely can even control the file extensions on the
client computer, providing a transparent experience for the user.
To configure remote applications to take over the local file extensions, you need to create
a Windows Installer (.msi) package for them and install the package locally (or use Group
Policy to deploy the resulting .msi package), following these steps:
1. Open RemoteApp Manager and connect to the RD Session Host that hosts the application
you want to deploy.
2. Click Add RemoteApp Program to open the RemoteApp Wizard. Click Next and select
the program or programs you want to add, as shown in Figure 4-10.
Figure 4-10 Adding a program with the RemoteApp Wizard.
Working Over the Web: Web Access CHAPTER 4 59
3. Click Next and then click Finish to return to the RemoteApp Manager.
4. Select the program in the list of RemoteApp programs and click Create Windows
Installer Package in the Actions pane.
5. Click Next to open the Specify Package Settings page. Make any changes here that are
appropriate for your environment.
6. Click Next to open the Configure Distribution Package page shown in Figure 4-11.
Figure 4-11 The Configure Distribution Package page of the RemoteApp Wizard.
7. Select the Associate Client Extensions For This Program With The RemoteApp Program
check box. Also select the Desktop check box if you want the user to have a shortcut to
this application on his or her desktop.
8. Click Next and then click Finish to create the .msi package, which can be installed on
users’ computers.
Working Over the Web: Web Access
Windows Server 2008 R2 provides access to RemoteApp programs and desktops using the RD
Web Access role for all versions of Windows that support at least RDP version 6.0 or later. This
includes Windows Vista SP1 and Windows XP SP3.
Users can connect to the resources of your RDS environment, including virtual desktops,
from supported clients using direct RemoteApp and Desktop Connection, or over the Web
using the Remote Desktop Gateway. This enables users to have consistent access to corporate
resources without having to use a virtual private network (VPN) connection. Figure 4-12
shows the typical RD Web Access connection through an RD Gateway.
and VDI: Centralizing Desktop
and Application Management
Figure 4-12 The RD Web Access connection through an RD Gateway.
RD Web Access can be configured to provide virtual desktops as well as RemoteApps, and
also provides a gateway to allow users to connect to their own workstation if corporate policy
allows it.
The RemoteApp and Desktop Connection Web application gives IT administrators a single
place to manage and assign resources for their users. Changes made here are directly
reflected in the RemoteApp and Desktop Connection Control Panel for Windows 7 users,
and in the applications and virtual desktops that users connecting from earlier versions of
Windows
see when they log in to the RD Web Access server, as shown in Figure 4-2
.50 CHAPTER 4 Remote Desktop Services
and VDI: Centralizing Desktop
and Application Management
Figure 4-2 The RemoteApp and Desktop Connection page from a Windows XP SP3 computer.
The Windows 7 computer of the same user directly integrates these same links into the
user’s Start menu, as shown in Figure 4-3.
Figure 4-3 RemoteApp and Desktop Connections are directly integrated into the Windows 7 Start menu.
Whenever an administrator makes changes to the available programs or virtual desktops,
both the RD Web Access page and the user’s Start menu are dynamically updated without
further intervention.
(Re)introducing Remote Desktop Services and VDI CHAPTER 4 51
Windows PowerShell Module:
Windows Server 2008 R2 includes a new Windows PowerShell module, the RemoteDesktopServices
module, that includes both cmdlets and a full RDS Provider, as shown in Figure 4-4.
Figure 4-4 The RemoteDesktopServices module for Windows PowerShell includes both cmdlets and a
provider.
For those new to Windows PowerShell, a brief explanation of providers is in order. In
Windows PowerShell, providers are a way to view and navigate information in a hierarchical
way as if the providers were drives on the computer. In fact, the FileSystem is implemented as
a provider. This means that when you type dir c:\ at the Windows PowerShell prompt, what
you’re actually doing is asking Windows PowerShell to give you the children of the C drive
of the FileSystem provider. (The dir command is an alias for Get-ChildItem.) Windows PowerShell
implements the Windows Registry as a provider as well, so you issue the command
dir HKLM:\System\CurrentControlSet to see what the HKeyLocalMachine registry
hive has in the System\CurrentControlSet container.
With the RemoteDesktopServices provider, the “drive” is RDS:. Beneath that top level we
have RDSConfiguration, GatewayServer, LicenseServer, RDSFarms, ConnectionBroker, and
RemoteApp containers. With the RDS Windows PowerShell module, you can configure and
manage all RDS role services and components using Windows PowerShell. For example, you
can do the following:
52 CHAPTER 4 Remote Desktop Services
and VDI: Centralizing Desktop
and Application Management
1. View and edit configuration settings of Remote Desktop Server
2. Publish RemoteApp applications
3. Configure License Server
4. Create and configure a Remote Desktop server farm
5. Configure and assign virtual Internet Protocol (IP) addresses to either sessions or applications
6. Create and manage RDV (VDI) pools
7. Create and manage Gateway Resource Access and Client Access policies
For example, with Windows PowerShell, you can quickly get a list of the personal virtual
desktop assigned to a particular user:
PSH> import-module RemoteDesktopServices
PSH> $cred = Get-Credential
PSH> Get-VirtualDesktop –user example\charlie –credential $cred
Name AssignedTo Host
---- ---------- ----
xmpl-vdi-92.example.local EXAMPLE\Charlie HOST-9.example.local
Because the RDS team implemented their Windows PowerShell support primarily as a provider,
it’s easy to navigate and investigate the functionality available, and also easy to get help
on how to do tasks. So, for example, if you want to know what the parameters are for creating
a new RemoteApp using Windows PowerShell, you just ask Windows PowerShell to tell you,
as shown in Figure 4-5.
You can also use Windows PowerShell to quickly get or set the value of various RDS settings,
as shown in Figure 4-6.
(Re)introducing Remote Desktop Services and VDI CHAPTER 4 53
Figure 4-5 Using the Get-Help command with the –path parameter to get specific help on creating
RemoteApps.
Figure 4-6 Getting the ConnectionBrokerSettings.
To change the session settings to disable new connections, the command would be as
follows:
RDS:\RDSConfiguration> Set-Item –path .\SessionSettings\AllowConnections 0
54 CHAPTER 4 Remote Desktop Services
and VDI: Centralizing Desktop
and Application Management
Windows 7 and RDS (Better Together)
Users running Windows 7 will have an enhanced user experience when using Remote Desktop.
Not only will they have more direct access to applications and desktops through the
RemoteApp and Desktop Connection (RAD) link in the Control Panel, but the overall experience
is more natural and integrated. RemoteApps are directly integrated into the Start menu,
Taskbar, and system tray, so that many users will be unable to tell whether a program is running
locally or remotely.
Improved User Experience
The improved user experience with Remote Desktop Services and Windows 7 clients includes
the following features:
1. Multimedia redirection This feature provides high-quality multimedia by redirecting
multimedia files and streams so that audio and video content is sent in its original
format from the server to the client and rendered using the client’s local media playback
capabilities.
2. True multimonitor support Remote Desktop Services enables support for up
to 10 monitors in almost any size, resolution, or layout with RemoteApp and remote
desktops. Applications will behave just like they do when running locally in multimonitor
configurations.
3. Audio input and recording VDI supports any microphone connected to a user’s
local machine and enables audio recording support for RemoteApp and Remote Desktop.
This is useful for Voice over Internet Protocol (VoIP) scenarios and also enables
speech recognition.
4. Windows Aero support VDI provides users with the ability to use the Windows
Aero user interface for client desktops, ensuring that remote desktop sessions look and
feel like local desktop sessions.
5. DirectX redirection Improvements in DirectX 9, 10, and 11 application rendering,
and support for the new DirectX 10.1 application programming interfaces (APIs)
that allow DirectX (2D& 3D) graphics to be redirected to the local client to harness the
power of the graphical processing unit (GPU) on the user’s local device, remove the
need for a GPU on the server.
6. Improved audio/video synchronization Remote Desktop Protocol (RDP)
improvements in Windows Server 2008 R2 are designed to provide closer synchronization
of audio and video in most scenarios.
7. Language bar redirection Users can control the language setting of RemoteApp
programs using the local language bar.
8. Task Scheduler Improvements keep scheduled applications from interacting with
users running RemoteApps, avoiding confusion.
Enabling VDI CHAPTER 4 55
RA D Control Panel
The RAD Control Panel applet, part of Windows 7, provides a simple way to configure
RemoteApp and VDI directly into the user’s Start menu. Plus, once the initial connection is
made, applications and desktops are automatically updated as the administrator configures
the available applications and desktops, simplifying management and deployment.
Configuring RemoteApp and Desktop Connection
To change the settings for RAD, use the Remote Desktop Connection Manager console, as
shown in Figure 4-7.
Figure 4-7 The Remote Desktop Connection Manager console.
The Remote Desktop Connection Manager connects to an RD Connection Broker, and
allows you to configure the RD Virtualization Host servers and the personal and pooled
virtual desktops they provide, along with designating the RemoteApp sources that will be
available to the RD Connection Broker.
Enabling VDI
Windows Server 2008 R2 adds support for both personal and pooled virtual desktops.
Enabling that VDI support requires setting up and configuring an RD Virtualization Host, an
RD Session Host, an RD Connection Broker, and an RD Web Access server, although these
and VDI: Centralizing Desktop
and Application Management
different roles can be combined as appropriate for your environment. The basic steps to
enabling VDI are as follows:
1. Enable the RD Virtualization Host role service of the Remote Desktop Services role.
This will also enable the Hyper-V role.
Note E nabling the Hyper-V role requires hardware that supports hardware virtualization.
This might require an updated BIOS. The BIOS must be configured to support both
hardware virtualization and hardware Data Execution Protection.
2. Enable an RD Session Host. This is required both for VDI and to provide RemoteApp
programs.
3. Enable an RD Connection Broker and an RD Web Access server.
4. Export the Secure Sockets Layer (SSL) certificate for the RD Web Access computer. This
will be imported onto the virtual machines (VMs).
5. Create the VMs that will be used, configuring them as appropriate. These will be used
either as part of a VDI pool or as personal VMs.
• Add the SSL machine certificate from the RD Web Access computer to them.
• Enable Remote Access.
• Allow Remote RPC for RDS in the registry.
• Enable Remote Service Management in Windows Firewall.
• Add RDP protocol permissions to the VMs.
• Configure the VMs for rollback if they’re part of a VDI pool.
6. Add the RD Web Access computer to the TS Web Access Computers local group on the
RD Connection Broker.
7. Add the RD Connection Broker computer as a source for the RD Web Access computer,
as shown in Figure 4-8.
Enabling
Figure 4-8 Configure RD Web Access to use an RD Connection Broker as a source.
8. Configure the VDI Pool and assign any Personal Virtual Desktops on the RD Connection
Broker as shown in Figure 4-9.
Figure 4-9 Adding virtual machines to a Virtual Desktop Pool.
58 CHAPTER 4 Remote Desktop Services
and VDI: Centralizing Desktop
and Application Management
9. Add applications to the RemoteApp server and make them available as RemoteApps.
10. Log on to the client computer as an administrator and import the machine SSL certificate
from the RD Web Access server.
11. Log on to the client computer and set up the RemoteApp and Desktop Connection.
Yes, this is fairly complicated, but most of these steps are performed one time only, or can
be easily automated.
Integrating Remote and Local Applications with
RemoteApp
RemoteApp for Windows Server 2008 R2 gives you the ability to provide your users with an
integrated and transparent mixture of local and remote applications. For applications that
behave best when run locally, or that are used when not connected to the network, you can
install the applications locally, while providing access to other applications using RemoteApp
where appropriate. Applications running remotely can even control the file extensions on the
client computer, providing a transparent experience for the user.
To configure remote applications to take over the local file extensions, you need to create
a Windows Installer (.msi) package for them and install the package locally (or use Group
Policy to deploy the resulting .msi package), following these steps:
1. Open RemoteApp Manager and connect to the RD Session Host that hosts the application
you want to deploy.
2. Click Add RemoteApp Program to open the RemoteApp Wizard. Click Next and select
the program or programs you want to add, as shown in Figure 4-10.
Figure 4-10 Adding a program with the RemoteApp Wizard.
Working Over the Web: Web Access CHAPTER 4 59
3. Click Next and then click Finish to return to the RemoteApp Manager.
4. Select the program in the list of RemoteApp programs and click Create Windows
Installer Package in the Actions pane.
5. Click Next to open the Specify Package Settings page. Make any changes here that are
appropriate for your environment.
6. Click Next to open the Configure Distribution Package page shown in Figure 4-11.
Figure 4-11 The Configure Distribution Package page of the RemoteApp Wizard.
7. Select the Associate Client Extensions For This Program With The RemoteApp Program
check box. Also select the Desktop check box if you want the user to have a shortcut to
this application on his or her desktop.
8. Click Next and then click Finish to create the .msi package, which can be installed on
users’ computers.
Working Over the Web: Web Access
Windows Server 2008 R2 provides access to RemoteApp programs and desktops using the RD
Web Access role for all versions of Windows that support at least RDP version 6.0 or later. This
includes Windows Vista SP1 and Windows XP SP3.
Users can connect to the resources of your RDS environment, including virtual desktops,
from supported clients using direct RemoteApp and Desktop Connection, or over the Web
using the Remote Desktop Gateway. This enables users to have consistent access to corporate
resources without having to use a virtual private network (VPN) connection. Figure 4-12
shows the typical RD Web Access connection through an RD Gateway.
and VDI: Centralizing Desktop
and Application Management
Figure 4-12 The RD Web Access connection through an RD Gateway.
RD Web Access can be configured to provide virtual desktops as well as RemoteApps, and
also provides a gateway to allow users to connect to their own workstation if corporate policy
allows it.
Subscribe to:
Posts (Atom)