Read Windows Server 2008 R2 Unleashed Online
Authors: Noel Morimoto
trickle replicated back to a share at the main office for backup and recovery.
If the main office has data that it wants to push out to all remote offices, whether that is
template files, company policy documents, standard company materials, or even shared
data that a workgroup of users needs to access and collaborate on, DFSR provides the ability
to push out data to other servers on the network. Users with access rights to the data no
longer have to go across a WAN connection to access common data. The information is
pushed out to a server that is more local to the user, and the user accesses the local copy of
the information. If any changes are made to remote or centralized copies of data, those
changes are automatically redistributed back to all volumes storing a copy of the data.
One of the enhancements made in Windows Server 2008 R2 specific to DFS-R is the ability
for an administrator to set a DFS replica to be read-only. In the past, DFS replicas were all
read/write replicas so that a user in a remote location could accidentally overwrite files
that then replicate to all replicas in the environment. Administrators have compensated
for this potential issue by setting file-level permissions across files and folders; however,
for many remote branch offices, if the administrator could simply make the entire replica
read-only, it would simplify the security task dramatically. Thus, read-only replicas can
now be set so that an entire server or branch of a DFS tree can be set to replicate to a
remote server on a read-only basis.
Distributed File System Replication is covered in detail in Chapter 28.
Improvements for Thin Client Remote Desktop Services
33
Improvements in Distributed Administration
Finally, for remote or branch offices that do have IT personnel in the remote locations,
1
administration and management tasks have been challenging to distribute proper security
rights. Either remote IT personnel were given full domain administrator rights when they
should only be limited to rights specific to their site, or administrators were not given any
administrative rights because it was too difficult to apply a more limiting role.
Windows Server 2008 R2 Active Directory has now defined a set of rights specific to
branch office and remote site administrators. Very similar to site administrators back in
the old Exchange Server 5.5 days—where an administrator was able to add users, contacts,
and administer local Exchange servers—now network administrators in Active Directory
can be delegated rights based on a branch or remote site role. This provides those adminis-
trators with the ability to make changes specific to their branch location. This, along with
all the other tools in Windows Server 2008 R2 specific to branch office and remote office
locations, now provides better IT services to organizations with multiple offices in the
enterprise.
Improvements for Thin Client Remote Desktop
ptg
Windows Server 2008 R2 has seen significant improvements in the Terminal Services (now
called Remote Desktop Services [RDS]) capabilities for thin client access for remote users
and managed users in the enterprise. What used to require third-party add-ons to make
the basic Windows 2000 or 2003 Terminal Services functional, Microsoft included those
technologies into Windows Server 2008 and further enhanced them in Windows Server
2008 R2. These technologies include things such as the ability to access Remote Desktop
Services using a standard Port 443 SSL port rather than the proprietary Port 3389, or the
ability to publish just specific programs instead of the entire desktop, and improvements
in allowing a client to have a larger remote access screen, multiple screens, or to more
easily print to remote print devices.
These improvements in Windows Server 2008 R2 Remote Desktop Services have made RDS
one of the easiest components to add to an existing Windows 2003 Active Directory to
test out the new Windows Server 2008 R2 capabilities, especially because the installation
of a Windows Server 2008 R2 Remote Desktop Services system is just the addition of a
member server to the domain and can easily be removed at any time.
All of these new improvements in Windows Server 2008 R2 Remote Desktop Services are
covered in Chapter 25.
Improvements in RDP v6.x for Better Client Capabilities
The first area of significant improvement in Windows Server 2008 Terminal Services was
addressed in the update to the Remote Desktop Protocol (RDP) v6.x client, shown in
Figure 1.10.
34
CHAPTER 1
Windows Server 2008 R2 Technology Primer
FIGURE 1.10
Remote Desktop Protocol client for Remote Desktop Services.
ptg
The RDP client with Windows Server 2008 provided the following:
.
Video support up to 4,096 x 2,048—
Users can now use very large monitors across
an RDP connection to view data off a Windows Server 2008 Terminal Services
system. With Windows Server 2008 R2 Remote Desktop Services, the latest support
has been extended to support DirectX 9, 10, and 11 redirection.
.
Multimonitor support—
Users can also have multiple (up to 10) monitors
supported off a single RDP connection. For applications like computer-aided design
(CAD), graphical arts, or publishing, users can view graphical information on one
screen and text information on another screen at the same time.
.
Secured connections—
The new RDP client now provides for a highly encrypted
remote connection to a Remote Desktop Services system through the use of
Windows Server 2008 R2 security. Organizations that need to ensure their data is
protected and employee privacy is ensured can implement a highly secured encrypt-
ed connection between a Windows Server 2008 R2 Remote Desktop Services system
and the remote client.
Remote Desktop Services Web Access
Also new to Windows Server 2008 and extended in Windows Server 2008 R2 Remote
Desktop Services is a new role called Remote Desktop Services Web Access. Remote
Desktop Services Web Access allows a remote client to access a Remote Desktop Services
session without having to launch the RDP 6.x client, but instead connect to a web
page that then allows the user to log on and access their session off the web page.
Improvements for Thin Client Remote Desktop Services
35
This simplifies the access method for users where they can just set a browser favorite to
link them to a web URL that provides them with Terminal Services access.
1
NOTE
Remote Desktop Services Web Access still requires the client system to be a Windows
XP, Windows Vista, Windows 7, Windows 2003, Windows Server 2008, or Windows
Server 2008 R2 server system to connect to a Remote Desktop Services session. A
browser user cannot be running from an Apple Macintosh or Linux system and access
Remote Desktop Services Web Access. For non-Windows-based web clients, third-party
vendors like Citrix Systems provide connector support for these types of devices.
Remote Desktop Services Gateway
Remote Desktop Services Gateway is an update to Windows Server 2008 R2 Remote
Desktop Services and provides the connectivity to a Remote Desktop Services session over
a standard Port 443 SSL connection. In the past, users could only connect to Windows
Remote Desktop Services using a proprietary Port 3389 connection. Unfortunately, most
organizations block nonstandard port connections for security purposes, and, thus, if a
user was connected to an Internet connection at a hotel, airport, coffee shop, or other
ptg
location that blocked nonstandard ports, the user could not access Terminal Services.
Now with Remote Desktop Services Gateway, the remote user to the Remote Desktop
Services Gateway connection goes over Port 443 just like surfing a secured web page.
Because of the use of SSL in web page access (anytime someone accesses a web page with
https://), effectively now a user can access Windows Server 2008 R2 Remote Desktop
Services from any location.
Remote Desktop Services RemoteApps
Another new server role added to Windows Server 2008 and updated in Windows Server
2008 R2 is called Remote Desktop Services RemoteApps. Remote Desktop Services
RemoteApps allows administrators to “publish” certain applications for users to access.
These applications could be things like Microsoft Outlook, Microsoft Word, the company’s
time sheet tracking software, or a customer relationship management (CRM) program.
Instead of giving users full access to a full desktop session complete with a Start button
and access to all applications on the session, an organization can just publish a handful of
applications that it allows for access.
Leveraging group policies and Network Policy Server, along with Remote Desktop Services
RemoteApps, the administrators of a network can publish different groups of applications
for different users. So, some users might get just Outlook and Word, whereas other users
would get Outlook, Word, and the CRM application. Add in to the policy component the
ability to leverage network location awareness (new to Windows Server 2008 R2 covered
in the earlier section “Improvements in the Group Policy Management”), the administra-
tors of the network can allow different applications to be available to users depending on
whether the user is logging on to the network on the LAN or from a remote location.
36
CHAPTER 1
Windows Server 2008 R2 Technology Primer
Beyond just limiting users to only the programs they should have access to by policy,
Remote Desktop Services RemoteApps minimizes the overhead for each user connection
because the user no longer has a full desktop running, but only a handful of applications
deemed necessary for the remote user’s access.
Remote Desktop Services Connection Broker
Formerly called the Session Broker in Windows Terminal Services, the Remote Desktop
Services Connection Broker is a system that manages Remote Desktop sessions to ensure
that if users are disconnected from a Remote Desktop server, the users can reestablish a
connection to their session without loss of the session state. Without a Connection
Broker, users who attempt to reconnect to Remote Desktop Services after a session discon-
nect might end up logging on to a completely different Remote Desktop server and have
to go back to where they last saved data to pick up where they left off.
Other than the name change from Session Broker to Connection Broker, new to Windows
Server 2008 R2 Connection Broker is the ability to cluster this role. In the past, this role
was a single server instance. In the event that this server session was down, the connec-
tion states would not be preserved and the Session Broker would not do its job. By cluster-
ing the Connection Broker role, an organization can now add redundancy to a critical role
ptg
for an organization that has several Remote Desktop servers and wants to provide users
with the ability to reconnect back to their session after a temporary disconnect.
Virtual Desktop Infrastructure (VDI)
Lastly, a completely new role added to Windows Server 2008 R2 is the Virtual Desktop
Infrastructure, or VDI role. Instead of Remote Desktop Services that provides a one-to-
many experience, where effectively a single server instance is shared across multiple users,
VDI provides a one-to-one virtual guest session relationship between the server and
remote client. When a VDI client user logs on to a guest session, a dedicated guest session
is made available to the user with a separate client boot-up shell, separate memory pool
allocated, and complete isolation of the guest session from other guest sessions on the
host server.
Windows Server 2008 R2 VDI provides two different VDI modes. One mode is a personal-
ized desktop and the other is a pooled desktop. The personalized desktop is a dedicated
guest session that users have access to each and every time they log on to the VDI server.
It is basically a dedicated guest session where the image the guest uses is the same every
time. A pooled desktop is a guest session where the user settings (favorites, background,
and application configuration settings) are saved and reloaded on logon to a standard