Session-Based Desktop Deployment on

Windows Server 2012, experiences so far

(Part 1)
In this article series, the author shares some of his experiences of Session-Based Desktop
Deployment based on Windows Server 2012.
If you would like to read the next part in this article series please go to Session-Based Desktop
Deployment on Windows Server 2012, experiences so far (Part 2).

Introduction
Now that Windows Server 2012 has been generally available for some time, its high time to
take a look back at the past few months to see what Windows Server 2012, and particularly
Session-Based Desktop Deployment, Powered by RDS has brought us. In this article Ill share
some of my experiences while putting Session-Based Desktop Deployment in production based
on Windows Server 2012. Well discuss how the overall installation process and the new way of
managing your Session-Based Desktop Deployment environment performs and works out. This
is part 1 of a series of (at least) 2 parts.

Before we start
Before we start, lets get a naming convention straightened out here. With Windows Server 2012
the overall name is Virtual Desktop Infrastructure, Powered by Remote Desktop Services. VDI
now consists of two flavors; there is Session-Based Desktop Deployment, what we would
previously refer to as Terminal Services and there is Virtual Machine-based Desktop
Deployment, what we would previously refer to as Virtual Desktop Infrastructure. This naming
convention will probably take some time in getting used to. For a long time many will probably
still talk about RDS when theyre actually referring to Session-Based Desktop
Deployment(Powered by RDS) just as since the name transition in Windows Server 2008 R2
many still refer to Terminal Services when they mean Remote Desktop Services. With Windows
Server 2012 the two flavors of RDS have been brought together. They share many of the same
RDS Roles and Components and are manageable from a single Server Manager Interface (the
RDMS) which, I believe, justifies name change.

Deployment
With Windows Server 2012 the new way of initially deploying the various roles that make up
Remote Desktop Services is called Scenario Based Deployment. Although, the actual name
Server Manager wizard uses is Remote Desktop Services Installation. Before the Beta Release
when this release was still called Windows Server 8, the wizard would refer to this installation
type as Scenario Based Installation, but this name changed in the GA release. So if you see me

mentioning Scenario Based, Im referring to the Remote Desktop Services Installation. So this
new way of deployment changed compared to previous releases like for example, in Windows
Server 2008 R2 where you would still do Role Based Deployment.
Ive done several deployments of Session-Based Desktop Deployment over the last months. The
new way of deployment definitely saves time as the three basic roles that are, RD Connection
Broker, RD Web Access and RD Session Host can be installed remotely using a single wizard. If
youve done RDS implementations on Windows Server 2008 (R2) youre probably remember
having to populate groups like TS Web Access Computers, Session Broker Computers etc. and
configure various MMC snap-ins.
In all production deployments I have done, I have been using the Standard Deployment. As you
might know, using the Standard Deployment you are able to select different servers for the
various RDS roles, which is usually what you would do in production environments. Also, the
Quick Deployment, in contrast to the Standard Deployment, creates and configures a basic
Session Collection. Thats ideal for demo and lab environments, but in production environments
you will most likely undo this basic configuration as it for instance, allows All Domain Users to
access the environment, and it publishes Calculator, Paint and WordPad.
With Windows Server 2012 we now also have much broader support to deploy and configure
RDS using PowerShell. For more information on that see my previous articles at Using
PowerShell to control RDS in Windows Server 2012 (Part 1) and Using PowerShell to control
RDS in Windows Server 2012 (Part 2).

Configuration
As I mentioned before, with Windows Server 2012 all management can be performed centrally
from the Server Manager Console. For Remote Desktop Services this is referred to as the
Remote Desktop Management Services (RDMS). From my experience, its definitely easy to add
additional roles to servers using RDMS. However, there are two roles that still require opening
the traditional MMC snap-in. These are RD gateway and RD Licensing. These two roles can be
installed remotely using the RDMS, however, for the configuration you still have to switch to the
other consoles. Hopefully, this will be improved in the future. During the implementations of
production environments, I ran into some options that feel to be missing from the RDMS. For
example, being able to configure the farm name users connect to. As you might know, with
Windows Server 2012 the RD Connection Broker now also serves as the initial connection (think
of this as dedicated redirector mode). So by default, published applications and desktops will
connect to the hostname of the RD Connection Broker. That name cannot be changed using the
RDMS. To be able to change the name of the initial connection, you would have to prepare the
RD Connection Broker for High Availability. During this preparation you can specify the RD
Connection Broker DNS name. On the other hand, in all the production deployments I have done
so far Ive used RD Connection Broker HA (or at least prepared for HA) to create High
Availability. The steps to create this RD Connection Broker High Availability have improved
immensely compared to Windows Server 2008 R2, and the High Availability setup is now also
Active-Active, which is great. As the RD Connection Broker plays a much more important role
on Windows Server 2012 (basically you hardly cannot do without), I would advise to always

configure RD Connection Broker HA if possible. Take into account though that it requires an
instance of SQL Server of at least version 2008 R2.
If youre used to managing your RDS environment on Windows Server 2008 R2 and moved to
Windows Server 2012 for the first time, first thing youll notice on the configuration side will be
the fact that most of the Remote Desktop MMC snap-ins are gone. Where we used to work with
for example, Remote Desktop Session Host Configuration, Remote Desktop Connection
Manager and RemoteApp Manager we can now perform most of these actions within the RDMS.
What from my experience works great is the fact that you can now centrally publish your
Remote Apps. Previously, you had to publish these on all your RD Session Host servers either
manually or using an import/export function. What Im also really happy with is the fact that you
can now publish a Full Desktop as a Remote App that points to your farm. Previously, using the
RemoteApp Manager, you had an option called Show a Remote Desktop Connection to the RD
Session Host server in RD Web Access. The downside here was that, as the name suggests, it
pointed to a single RD Session Host instead of the farm. With Windows Server 2012 you can
now publish a full desktop on RD Web Access that points to your farm (and is fully Single Sign
On) by creating a Session Collection of the type Remote Desktop. The downside that I have
experienced here is that since you have to put the Session Collection in type Remote Desktop,
you cannot publish both Full Desktop and Remote Apps inside the same Session Collection. In
order to achieve this you would have to create an additional Session Collection, including an
additional (set of) RD Session Host servers.
One function of RDS on Windows Server 2008 R2 that has also changed on Windows Server
2012 is the way to distribute Remote Apps or Desktops. Previously, you could use the
RemoteApp Manager, and create .RDP and .MSI files to distribute the Remote Apps or Desktops
you wanted to publish. The function to create these files does not exist in RDS on Windows
Server 2012. The best way to publish Remote Apps and Desktops now is to use the Web Feed
URL which can be configured using the corporate e-mail address. Personally, I did not create
.RDP or .MSI files on many occasions, so I dont really miss this functionality. But if you have
been using it a lot in the past, beware that this functionality no longer exists. There are relatively
easy ways to retrieve the .RDP files of course. For more information on that see Distribution of
Remote Apps and desktops in Windows Server 2012 . In my experience the Web Feed URL
functionality works very fluently in both the traditional Remote Desktop Client (mstsc) as well
as the Modern UI Remote Desktop Client.

Conclusion
This concludes part I of this series. Feel free to share your experiences by adding a comment to
this article or by sending me an e-mail. In the part 2, Im going to discuss some more of my
experiences on Session-Based Desktop Deployment on Windows Server 2012. Some of the
topics Ill be discussing in part 2 are User Profile Disks, the new Modern UI Start Screen, the
Modern UI Remote Desktop Client and Remote Control.
If you would like to read the next part in this article series please go to Session-Based Desktop
Deployment on Windows Server 2012, experiences so far (Part 2).

See Also

Disaster recovery options for the RD Connection Broker 2012 (HA)

Enable debug logging for RDS deployments (RDMS) in Windows Server 2012
Solve the pending reboot error in RDS deployments (RDMS) in Windows Server 2012
Troubleshooting RDS in Windows Server 2012
Remote Desktops Service in Windows Server 8
Video: Windows Server 2012 RDS Improvements
Session-Based Desktop Deployment on Windows Server 2012, experiences so far (Part
2)
Working with User Profile Disks on Session-Based Desktop Deployments
The flexibility of VDI in Windows Server 2012
Windows Server 2012 R2 is coming what does this add to RDS VDI

The Author Freek Berson

Freek Berson is a Microsoft MVP on RDS and works as an Infrastructure Specialist
at Wortell. His main focus is Session Virtualization (RDS and TS) and Desktop
virtualization (VDI).

Latest Contributions

Further enhanchements for RemoteFX adaptive encoding in RDP 8.1 12 Feb. 2014
Session-Based Desktop Virtualization in Azure 5 Feb. 2014
Availability of RDS Diagnostic Tool for RDS 2012 (2) 29 Jan. 2014
Microsoft RDP client for non-Windows devices, now available! 22 Jan. 2014
Microsoft's non-Windows based RDP clients 28 Nov. 2013

Session-Based Desktop Deployment on

Windows Server 2012, experiences so far
(Part 2)
In part 2 of Session-Based Desktop Deployment on Windows Server 2012, the author focuses on
further configuration of Session Collections, Maintenance and User Experience.
If you would like to be notified of when Freek Berson releases the next part in this article series
please sign up to our VirtualizationAdmin.com Real-Time Article Update newsletter..

Introduction
This is part 2 of a series of articles about my experiences with Session-Based Desktop
Deployment on Windows Server 2012 in production environments since the General Availability
(GA) of Windows Server 2012. In part 1, I focused on the deployment itself including the
different deployment scenarios, and part of the configuration. In this part 2 well be focusing on
further configuration of Session Collections, Maintenance and User Experience.

User Profile Disks

Youve probably already heard about User Profile Disks (UPD) as one of the new features being
available on Windows Server 2012. If not, I recently wrote an article on this subject called
Working with User Profile Disks on Session-Based Desktop Deployments. As with all new
techniques and features, time will tell how well they will work in production environments larger
than your average lab environment. Ive set up UPD in a few production environments over the
past few months. From what Ive experienced, the way to set up UPD is relatively easy. What I
also like about UPD is that all settings are stored in the local local.low folders as legacy
applications often still write settings and configuration files to these locations. There is one
downside that could potentially cause issues for administrators and that is that UPD is enabled
for all users that connect to a RD Session Host that is a member of a Session Collection where
UPD is configured. This also includes Administrators logging in on a RD Session Host. UPD
mounts a .vhdx file on a central network share and it can obviously only do this once. For your
regular user this would not be an issue because you usually dont allow multiple sessions by the
same user at the same time. However, as an administrator there can be scenarios where you
logon to multiple RD Session Host servers at the same time. Be aware that this leads into a
temporarily profile for the second logon. It would seem useful if the /admin switch of mstsc
would block UPD, but this is not the case.

Modern Start Screen

Im sure by now youre aware of the fact that with Windows 8 we no longer have a classic start
menu. Its being replaced by a Modern UI Start Screen which is optimized for touch but can also

be used on non-touch devices. The same is true for Windows Server 2012, no Start Menu. A
configuration that was frequently used in RDS deployments was redirecting the user Start Menu
to a central location in combination with Access Based Enumeration to only show shortcuts to
applications a user was authorized to run. With the transition of Start Menu to Start Screen this is
no longer possible. The Start Screen works differently and is technically not a folder anymore in
which shortcuts exist. Its now become a binary file and is part of the users profile. Because of
this change the above described configuration can no longer be used.
The idea about the Modern UI Start Screen is that the user can modify it to his own personal
needs. In essence thats a good idea but how would we publish applications to the end user
with which he can build his own start screen? In the RDS 2012 implementations I have
performed so far, the most convenient and user-friendly way was as follows:
I implemented the Start Menu redirection policies similar to the way in Windows Server 2008
R2. That causes the All Apps section of the Start Screen to be redirect to that location. From a
user perspective that would result in a set of shortcuts in the All Apps section of his Start Screen
that he could then use to build his own personalized Start Screen. However, this causes the Start
Screen itself to be completely empty upon first logon which is of course not very user friendly.
To overcome this, you can do some additional configuration to actually create a default Start
Screen that will be presented upon first logon that end users can then modify to their needs. I
have created an article on how to achieve this called Predefining and customizing the Modern UI
Start Screen on RDS 2012. Up until now I have found this to be the most convenient way to
present the new interface to end users. I was also surprised to see how remarkably quick end
users pick up on the new UI.
In case you or your customers still want to be able to access a classic (Windows 7 alike) Start
Menu, there are already many 3rd party tools available that are able to do this. Ive tested a few
and found that if you really want the classic Start Menu back, its relatively easy and some of
them really do a great job at making it look like a Windows 7 or even Windows XP Start Menu.
However, personally, I would prefer the Modern UI Start screen. Once you start using it youll
discover that it can work much quicker than the classic Start Menu.

Remote Control
As you might know the ability to do Remote Control (or shadowing) on Remote Desktop
(Previously Terminal Services) has been around for a long time. It can be used to view and even
interact with users sessions to assist them with issues they may encounter. I was surprised to see
that this feature no longer exists in Windows Server 2012. There are workaround for this but this
would require to use additional (3rd party) products or services. If you or your customers heavily
depend on Remote Control on RDS be sure to test possible workarounds that would suite your
environment best.

Web Access
The RD Web Access has also improved in various ways. What I like is the ability to create
subfolders in the Remote Apps Web Access page to consolidate applications in subfolders which
looks a lot better than a single Remote App page fully packed with all Remote Apps. Also, new
is the ability to allow password reset for end users to change (expired) passwords. Although it
recently seemed that by installing a KB article this has also been possible with Windows Server
2008 R2. I think the best new feature is the full Single Sign On we now have for Full Desktop
Sessions to the farm. With Windows Server 2008 R2 we were able to publish a Remote App to
a full desktop, however this was configured on the Remote App manager and this would point to
a specific (single) RD Session Host, not the farm. We can now have such a Full Desktop
Remote App that points to the RD Session Host farm.

Conclusion
This concludes part 2 of these series of experiences. Feel free to share your experiences by
adding a comment to this article or by sending me an e-mail. I might do a part 3 in the future
describing some more experiences with Session-Based Desktop Deployment on Windows Server
2012.
If you would like to be notified of when Freek Berson releases the next part in this article series
please sign up to our VirtualizationAdmin.com Real-Time Article Update newsletter.
If you would like to read the first part in this article series please go to Session-Based Desktop
Deployment on Windows Server 2012, experiences so far (Part 1).

See Also

Working with User Profile Disks on Session-Based Desktop Deployments

UPD (User Profile Disks) are also enabled for administrators
Modern UI Remote Desktop Client, experiences so far
Session-Based Desktop Deployment on Windows Server 2012, experiences so far (Part
1)
The UPD file naming convention, and a workarround
Surviving Printing on Citrix
Remote Apps and Full Desktops using the Modern UI Remote Desktop Client
What's new in Remote Desktop for Windows 8?
Terminal Services Server Drain Mode
Microsoft's non-Windows based RDP clients

The Author Freek Berson

Freek Berson is a Microsoft MVP on RDS and works as an Infrastructure Specialist
at Wortell. His main focus is Session Virtualization (RDS and TS) and Desktop
virtualization (VDI).

Latest Contributions

Further enhanchements for RemoteFX adaptive encoding in RDP 8.1 12 Feb. 2014
Session-Based Desktop Virtualization in Azure 5 Feb. 2014
Availability of RDS Diagnostic Tool for RDS 2012 (2) 29 Jan. 2014
Microsoft RDP client for non-Windows devices, now available! 22 Jan. 2014
Microsoft's non-Windows based RDP clients 28 Nov. 2013