Windows Server 2008 R2 Unleashed (14 page)

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

Services

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