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).
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 we’ll be focusing on further configuration of Session Collections, Maintenance and User Experience.
User Profile Disks
You’ve 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. I’ve set up UPD in a few production environments over the past few months. From what I’ve 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 don’t 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
I’m sure by now you’re aware of the fact that with Windows 8 we no longer have a classic start menu. It’s 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. It’s 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 that’s 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. I’ve tested a few and found that if you really want the classic Start Menu back, it’s 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 you’ll 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).
