Monday, May 23, 2016

Fix Office365 performance issues with FSLogix Office 365 Containers for Citrix!

I’ve written about FSLogix in the past. About a year ago I wrote an article on masking specific applications & plugins for specific users and running various java versions on the same OS. Check it out here: Managing your Azure RemoteApp application landscape using FSLogix Apps.

FSLogix is a set of tools with an extremely small footprint and has an amazing set of features that fix really specific problems, applicable in almost any VDI or RDSH environment!

“…FSLogix Apps is a software agent that enables virtual desktop administrators to massively reduce the number of Windows Gold images, easily manage per-user applications, optimize license costs while assuring compliance, and eliminate some of their biggest problems in VDI and RDSH…”
More info: https://FSLogix.com Today, FSLogix introduces great new functionality again, fixing very common issues in any VDI or RDSH environment!

FSLogix Office 365 Container for Citrix

Consider the following scenario, you have Office 365 and want to publish the full outlook client experience to your end users supporting cross platform and available anywhere / anytime. A common scenario is RDSH of VDI either RemoteApp or Full Desktop. For the best user experience in Outlook for Office 365, outlook cache is enabled. When running Outlook on a local device, that’s no issue, the generated .OST will remain inside the user’s profile on the local device. In any RDSH of VDI scenario however, you preferably roam that .OST file. Otherwise the .OST will be regenerated on each RDSH or pooled VDI you log on to (obviously personal VDI could be an exception). If you do roam the .OST, where do you store it? How do you roam it without having to copy it to the local cached profile? Obviously many vendors offer profile options as part of their overall management suites. For example, Microsoft offers User Profile Disk (UPD). If you are not familiar with UPD, in essence is you store the entire user’s profile in a single .VHDX file on a central file server. When you log on, the .VHDX file is mounted under C:\users\<username> without having to copy any (delta) profile and making it fully transparent for users and applications. FSLogix already offers a similar solution called Profile Containers. This solution is based on the same idea as UPD, but does not have some of the downsides that Microsoft UPD has. For example, Profile Containers is not bound to a single Session Collection where Microsoft UPD is and Profile Containers can be enabled for a specific group of people, for example to exclude administrators. Essentially, FSLogix Office 365 Container for Citrix does the same thing as Profile Containers or UPD, this time however specifically for the just .OST file! Why is this interesting? This makes their solution (similar to all their products) platform & OS independent! Although the name of the product implies that it’s for Citrix only, it’s not. You can run this on top of any RDSH or VDI solution, whether its Microsoft, Citrix VMWare and independent of any existing profile management solution like RES, Appsense (now part of Landesk) you may already have. Azure RemoteApp or AWS would also make for a good use case.

How does it work?
As with any FSLogix product or solution, part of their strength is keeping things simply. There is no complex backend infrastructure needed, and the installation is extremely easy.

1. Import the ADM(X) template provided by FSLogix and create a new GPO (or leverage an existing one that is linked to the OU where your RDSH / VDI machines are located.)

2. Open the GPO and browse to Computer Configuration, Administrative Template, FSLogix. You should see the structure as shown below.clip_image002
3. First, enable Office 365 container
clip_image004 4. Next, provide a location on your (existing) fileserver (CIFS, SMB)clip_image006 5. optionally, advance settings for the VHDX can also be changed. For example, for this lab test I set the maximum Size to 1Gb and Virtual Disk Type VHDX.clip_image007 Alternatively, the settings above can also be configured directly in the registry, the root location if HKLM\Software\Policies\FSLogix
clip_image009 Install FSLogix on the RDSH Servers by using setup.exe, or deploy it using your favorite deployment tools. The setup is extremely easy, setup.exe without any configuration.clip_image011clip_image013

You can configure the environment to only apply FSLogix Office 365 Container for specific users, by modifying the group membership of the group FSLogix ODFC Include List on the RDSH / VDI machine. For this lab I did this manually, but preferably you perform this using GPO or configure it as part of your image management process.clip_image015

That’s it!

After logging on with my test user, a new VHDX file on the central location has been created.clip_image017

And inside user session profile of the active user session you can see the junction point, confirming that we are now using an OST file inside a mounted .VHDX file!clip_image019

And here is the disk in Disk Management.
image

FSLogix Office 365 Containers allows you to fix a very common issue when dealing with Office365 and RDSH / VDI. The setup is extremely easy, there’s no management backend needed. The fact that it works independent of the virtualization solution or infrastructure is awesome!

I’ll write a follow up with some performance testing!
More info: https://fslogix.com/





Tuesday, May 17, 2016

Ten reasons you’ll love Windows Server 2016 #4: Remote Desktop Services

A video was posted on Microsoft Technet where Clark NIcholson talks about Remote Desktop Services in Windows Server 2016.

“…This is post #4 in the “Ten Reasons You’ll Love Windows Server 2016” video series by Matt McSpirit, Technical Evangelist at Microsoft.

In today’s edition, Matt introduces you to Clark Nicholson, Principal Program Manager on the Remote Desktop Services (RDS) team. Clark talks about the powerful new areas of innovation his team is working on for Windows Server 2016 – graphics improvements, scale enhancements, and optimizations for the cloud. Together, these enhancements strengthen our trusted platform for partners to build secure, customized solutions for our customers…”image Source: https://blogs.technet.microsoft.com/windowsserver/2016/04/12/ten-reasons-youll-love-windows-server-2016-4-remote-desktop-services/

Monday, May 9, 2016

Using Azure File Services to store application configuration files for Azure RemoteApp

Consider the following scenario;
You are a small organization and most of your line of business applications are SaaS or web based. You want to embrace BYOD to help employees to be productive on the devices they love and have access to company applications at any time from any location. With all your applications being SaaS and web based this is relatively easy. However, what if still need to support 2 or 3 Windows Applications that you want to manage centrally. Azure RemoteApp seems to be ideal for that use case! With Azure RemoteApp there is no need to setup and maintain a complex RDS infrastructure backend and Windows Applications can be delivered to any device at any time. Some of the Windows Applications however still need access to a classic file share / drive mapping to access centrally stored application configuration files and data. What you can do is stand up file server in Azure IaaS, create a file share and publish that on the RD Session Host servers as part of you Azure RemoteApp Collection. However, that is yet another server to manage, monitor and maintain where your organization may want to move forward to a full “as a service” environment.

Why not use Azure File Services to store application configuration files for Azure RemoteApp application?

Here’s how in 4 easy steps:

1.  You create a new Azure Storage account (or use an existing one)
image

2. You create a new File service within that storage account
image

3. You create a new File Share within that File Service
image

4. You map a network drive directly to the File Share.

To be able to map a network drive, first get the Access Key by clicking the Key icon on the storage account.
image

Then open the example Net Use command by opening Connect icon on the File Share.
image
Simply copy that command and add in the Access Key you copied before. The results in a Net Use command you can use.

In scenario’s where you deployed a Hybrid (domain joined) Azure RemoteApp collection, you can use Group Policy Objects to create a logon script and create a drive mapping in every user session.
image

As a results, the end users’ applications will have a drive mapping available to store and share application configurations settings.
image

In scenario’s where you deployed a Cloud (non-domain joined) Azure RemoteApp collection, you can place the same logon script inside the Azure RemoteApp template image. For more information on how to perform this see: https://blogs.msdn.microsoft.com/cloud_solution_architect/2016/04/08/configuring-startup-logon-scripts-for-azure-remoteapp/

Of
course, you can also create the Azure File Service inside the Azure V1 (classic) portal. The screen shots below outline the necessary steps

1. Create a Storage account (or use an existing one) 
image

2.Open the Storage account and get the Access Key by clicking Manage Access keys
image

3. Based on the access key run the following 2 PowerShell commands
image
image

4. Now create the drive mapping the same way as described above.

That’s it! An easy way to share configuration data & file for Windows Applications hosted on Azure RemoteApp.

Q Can I use Azure File Services for all File Server needs?
A Technically yes, however do note that Azure File Services does not support NTFS

Thursday, April 28, 2016

Run your Remote Desktop Server Connection Broker database in Azure SQL (Win Server 2016 TP5)

Windows Server 2016 Technical Preview 5 is out! For Remote Desktop Services, this brings a great new feature to the table! Remote Desktop Services in TP5 allows you to store the RD Connection Broker database in Azure SQL! This is a very interesting scenarios for RDS on Azure IaaS but can also be used for an on premises or hosted scenario.

How to configure this? The process of setting up RDS Deployment (Quick or Standard) via Server Manager or PowerShell in Technical Preview 5 is similar to setting this in up Windows Server 2012(R2).

Now we need to setup an Azure Database. Select New from the Azure Portal and choose SQL Database.image

In the New Server window provide a server name, logon and location.
image

Next, provide a database name, subscription and new (or existing resource group) and select a blank database. For testing purposes in my lab I selected the Basic tier but in future production environments the Tier should be chosen based on the performance needed.
image

That is basically it! The database will now be created in Azure.
image

Once it’s finished, the screen below is what you will end up with. Click “Show database connection strings” and copy the ODBC connection string and save it, you’ll need this later on.
image

From the RDMS console in Server Manager you can select the option “Configure High Availability”, still similar to Windows Server 2012 R2. In this case however, you will be presented with the option to choose a Dedicated database server or a Shared database server. For Azure Databases the option obviously is Shared database server. Note for this to work, similar to HA in Windows Server 2012 R2, you still need the SQL Server Native client to be installed on all RD Connection Broker servers.
image
image

Provide the DNS name for the RD Connection Broker, similar to setting up High Availability in Windows Server 2012. Copy the ODBC connection string you saved earlier and enter the password in the string, this is the password you provided while setting up the Azure database.
image
Double check the information and click next.
image

The Windows Internal Database is now migrated to the Azure Database
image
The Server Manager console now reflect the changes and shows “High Availability Mode”.
image

Obviously other factors now also come into play like performance, what Azure SQL Tier do I need, what connectivity is required etc. These require more in depth testing, and we still have time since this is only Technical preview, but for now it’s a great new feature that adds more options and flexible deployment scenarios of RDS on Azure IaaS or on premises! image

Tuesday, April 12, 2016

Remote Desktop Preview App now supports Azure RemoteApp! (Insiders ring)

The latest update to the Azure RemoteApp Preview App (version 856) in the Microsoft App Store (currently only in the insiders rings) now contains support for Azure RemoteApp! This means you can now start using this client to launch applications hosted in Azure RemoteApp.

What is the experience like?
First download and install the latest Remote Desktop Preview App from the Appstore (note that you currently have to be in the insiders rings to see the update, other rings will follow soon)
https://www.microsoft.com/en-us/store/apps/microsoft-remote-desktop-preview/9nblggh30h88

After launching the App we now have a new option called “Azure RemoteApp, Sign in to a source feed to get apps”.

Simply enter the account you want to use that is assigned to an Azure RemoteApp collection and click Sign In.
image

The App will start to retrieve the applications that are assigned, which in my case took a few seconds.
image

And here are the applications that are assigned to my user.
image

By single clicking, a user session is logged on and the application is launched. Similar to the ClickOnce client, or any RemoteApp environment, the launch of 1st application takes a little longer because at this stage the session is being logged on. Any 2nd or 3rd application we launch leverages the same session and is faster in launch time.
image

Here I have several applications open. By clicking the three dots in the upper center of the App you can easily switch between active application i.e. if you have minimized an application and want to bring it back up.
image

Optionally, you can pin RemoteApps by right clicking the App and selecting “Pin To Start”
image

Currently there is no intuitive way to return to the main screen of the App to launch additional apps. To return to the main screen, first press the button with the 3 dots again, and then click the Back arrow button.
image

Also, once in the main screen, there currently is no easy way to switch back to an active session, the only method is to launch an additional app from the same source. Ideally you would like to switch concurrent active session easily especially in scenarios where users have multiple feeds from different sources or are in the middle of a migration path from on premises RemoteApp to Azure RemoteApp. Microsoft has confirmed that functionality to provide easy switching of active session is on the roadmap. As with any Azure service or App, it’s all about continuous development, so expect updates to this App regularly too.

Finally, the App collects recently launched RemoteApps and if you right click the tile in the Start Screen, you can quickly launch recently opened RemoteApp and Pin them from the Start Screen as well.
image

Monday, April 4, 2016

Estimating Azure RemoteApp network bandwidth usage

imageMicrosoft updated some articles for guidance on estimating Azure RemoteApp network bandwidth usage.

”…Azure RemoteApp uses the Remote Desktop Protocol (RDP) to communicate between applications running in the Azure cloud and your users. This article provides some basic guidelines you can use to estimate that network usage and potentially evaluate network bandwidth usage per Azure RemoteApp user.

Estimating bandwidth usage per user is very complex and requires running multiple applications simultaneously in multitasking scenarios where applications might impact each other's performance based on their demand for network bandwidth. Even the type of Remote Desktop client (such as Mac client versus HTML5 client) can lead to different bandwidth results. To help you work through these complications, we'll break the usage scenarios into several of the common categories to replicate real-world scenarios. (Where the real-world scenario is, of course, a mix of categories and differs by user.)

Before we go further - note that we assume RDP provides a good to excellent experience for most usage scenarios on networks with latency below 120 ms and bandwidth over 5 MBs - this is based on RDP's ability to dynamically adjust by using the available network bandwidth and the estimated application bandwidth needs. This article goes beyond those "most usage scenarios" to look at the edge, where scenarios begin to unwind and user experience begins to degrade.

Now check out the following articles for the details, including factors to consider, baseline recommendations, and what we did not include in our estimates…”

Source & more info:

Estimate Azure RemoteApp network bandwidth usage
How do network bandwidth and quality of experience work together?
Testing your network bandwidth usage with some common scenarios
Quick guidelines if you don't have the time or ability to test

Friday, March 11, 2016

HTML5 updates & improvements for Azure RemoteApp

On January 13, the HTML5 client for Azure RemoteApp became available in public preview. I wrote a blog post on the user experience with this initial version here: HTML5 for Azure RemoteApp available in public preview!

Yesterday, the next major update to HTML5 has been made available! The most important changes in this release are:

1. Support for Dynamic resolution
The session is no longer fixed to a specific remote resolution, the session now automatically adjusts resolution if you change your browser size

Here is the Azure RemoteApp HTML5 client at full Windows Size
 

Here is de browser resize in action, this takes about ~2 seconds


And here is the end result:


2. Audio redirection is now supported!
It's hard to demonstrate this in a blog post, but I can assure you it's working :) The audio service in your Azure RemoteApp RDSH must obviously be running for this to work



3. Mouse cursor updates
This really helps for the overall user experience. Previously, mouse cursus updates were not visible which made it really hard to e.g. resize application windows etc. See the example below. Mouse cursus updates are now coming through.


4. Support for browsers without WebGL support
Previously there were some issues with browsers without WebGL support which caused crashes of the browser and session disconnected errors. This has been resolved.


5. Support for cloud only deployments
In the first release of the HTML5 client, only Hybrid Collections (domain joined collections) were supported. With the lastest release Cloud Deployments (non-domain joined collections) are also supported!

This latest HTML5 should be deployed to all Azure regions by now!