Windows Virtual Desktop – First Thoughts – Part 2

A few weeks ago, I published the first part of this post, get to it here.

In the first part, I wrote about the initial setup and config experience for creating and accessing Windows Virtual Desktop (WVD). Overall, I found the experience to be good, but at times, slightly basic. This is to be expected with a brand new service that is in preview, but for the second part of this post, I wanted to explore the more advanced options of configuration that are currently available.

So in this post, I am going to discuss the following:

  • fslogix profiles
  • Load balancing
  • Depolying using a custom image
  • Availabiltiy/configuration of SSO

Starting with fslogix, I think it’s kinda cool that you are given a free license as part of WVD to use the service. The actual install was quick and easy, download the client, run it, set up two reg keys, done. However, I wasn’t overly familiar with fslogix and as such thought it wasn’t working and I have a solid background in desktop virtualisation, so I understand profile redirection explicitly. I found the Microsoft docs for this are light currently, but clicking through to the fslogix docs I spotted the issue, the local profile cannot exist first or fslogix will ignore it. A quick tidy up and my profiles were redirecting, loading quickly and generally behaving as expected. So far so good, I’d like to see how it scales with a tonne of users, but the expectation is similar performance to Citrix UPM. One thing that is perhaps a bit annoying out of the box is, when you choose signout from the web client, it simply disconnects the user from an app group, this can be fixed with some Group Policy, but I would expect sign out to mean sign out.

A little tip, check out the reg key “FlipFlopProfileDirectoryName” for a quick way to make finding your user profiles within your file share a bit easier. There are also more advanced options like “SIDDirNamePattern”, more here.

Next up is load balancing the session hosts. This obviously only applies to non-persistent session hosts, as the persitent relationship is 1:1. You also need to understand two concepts:

  • Breadth-first
    • This distributes sessions evenly across all session hosts, a max session limit is optional.
  • Depth-first
    • This fills up a session host first before distributing sessions, a max session limit is required.

Both options are simple to setup via powershell and behave exactly as outlined. Instructions here.

Third, I created a new host pool. To do this I first needed a custom image. So I deployed a VM to Azure to convert later. I skipped a bit here by using the new W10 image with 365 proplus preinstalled for you, very handy. However, I then realised this wasn’t the multi-user version and even though all is good with image creation, it fails when trying to register with WVD (30 mins later…) So to save you some time, just use the W10 multi-user image instead! I installed my apps, then I made the following changes:

  • fslogix installed and enabled
  • configured session timeout policies
  • Additional language pack and region settings

Once I had this done, to get your custom image, follow the usual docs here.

Then, you can simply specify it as part of the same steps you followed previously to deploy as a host pool

Once your new host pool is deployed, you need to assign users, don’t forget you currently can’t assign a user to more than one App Group at any one time. So I removed one of my test users from it’s previous group and added it to the new one.

Once logged in, everything is as expected. Profiles, custom settings and my newly added apps. For my own terrible fun I added a special app, yes, I’, sorry, that is Windows 95 running in the HTML5 client on WVD!

Windows95 running via HTML5 client on Windows Virtual Desktop

One tip that could save you some time is relevant to SSO. You may notice that when signing in and launching and app/desktop you are prompted for credentials twice. This is the current expected experience. In the comments on docs, I spotted the following response from the program group:

So we’ll just have to wait and see how good/bad SSO functionality will be once released!

If you have any questions or would like to see a third part to this series, let me know!

Azure – Protect My App

If you’ve taken a path to adopt public cloud and part of that adoption is a public facing application, you need to review how you are protecting it within Azure. When your application was on-premises, there was most likely only a single well managed solution to granting external access. In Azure, there are several various solutions available and each carries its own set of functionality and risk.

Rather than try define that entire list, let us look at how best to protect your application, regardless of how you have deployed it. With Azure, these are my three preferred options:

  1. Azure AD Application Proxy
  2. Azure Application Gateway
  3. 3rd Party Network Virtual Appliance

These arguably run from least to most secure. An important tip is to treat each application as unique, because it is. There is not a single best solution for all of your applications and as Azure is a shared model of security it is up to you to protect your data!

Awkward stuff out of the way, let’s look at Application Proxy, we’ve already had a post on setting this up here. The key point with this service is that you do not have your site exposed externally at a network level. Of course, the application itself will be and therefore possibly your server and data, but there is not an open endpoint accepting traffic.

Next is Application Gateway. This is actually a load-balancing solution but you can enable the Web Application Firewall tier easily. This provides protection of your applications from common exploits and vulnerabilities. However, this protection is based on rules from the OWASP core rule set and while it is configurable, this only means you can disable certain rules, not add custom ones. Application Gateway can seamlessly integrate into your environment whether you are running PaaS or IaaS solutions and is economical from a cost perspective. However, that point regarding customisation can often be the deciding factor in choosing our third option instead.

Finally, a 3rd party appliance. Azure offers solutions from the majority of the major providers in this space. Easily deployable from the Azure Marketplace within minutes. Integration options are good but require some work, (See post on routing here) and cost can be a factor to meet required availability levels. But if you need maximum protection and customisation, this is your best option.

Overall, I think there is definitely a solution in Azure that will meet your requirements. Take the time to understand your application, consult with your SMEs and you won’t go wrong!

 

 

Azure AD Application Proxy

Web applications that are only accessible on your corporate LAN are common place in most companies. The lack of public access can be the result of many factors, most commonly the reason is the complexity of allowing a route through your secure perimeter. As a result, providing access to these applications has traditionally involved creating and utilising virtual private networks (VPNs) or demilitarized zones (DMZs), both requiring significant IT effort to put in place and keep secure. Adding to this, a lot of these applications can be quite difficult to lift and shift into a DMZ which would of course be best practise. Overall, both solutions have several complexities and offer different degrees of difficulty to manage.

Enter Azure AD Application Proxy (AP). This service can provide single sign-on (SSO) and secure remote access for these common web applications. It leverages your current infrastructure and ties into Azure AD for identity management so if you are already using Office 365, the authentication process for users is identical and the configuration required is minimal. Additionally, the page will be available on any web-accessible device at all times. This greatly simplifies the process as you don’t need to change your network infrastructure or allow VPN access for external users.

Again, those already using Office 365 will have their identities, or a version of them, active within Azure AD. When using AP, you can require users pre-authenticate before the internal page loads, offering an additional layer of security and auditing. If your identities are federated for example, this process ties-in seamlessly without any further configuration required. The ability to then add a method of passthrough authentication is when your end users life is made a lot easier.

To make use of AP, you need to install at least one connector in your environment. The requirements for this installation are here. The beauty of the connector is that it only requires outbound ports on your firewall and the main ports are 80 and 443, ports you would most likely already have open. Again, Microsoft are trying to make this as simple as possible! Once you have a connector installed and active, it is a good idea to install at least one more. This allows for high availability should one of the servers be inaccessible accidentally or due to maintenance.

Next, you obviously want to publish your application. This can be done in several ways, from the very simple to the completely integrated. Digging through those complexities is something that requires a lot more time than this blog post is suitable for, but believe me, with some guidance from an experienced architect, this process is very much achievable in the majority of environments. Here is some additional reading on application publishing:

Publishing Applications

SSO utilising KCD

Remember, AP isn’t just for simple internal web applications like your intranet page. It can be leveraged to provide SSO and secure remote access to your on-premise Sharepoint farm and even applications published locally via RDS.

I’ve implemented this service for several clients and they all compliment the functionality it allows them to leverage. The guidance during the configuration phase allows IT admins to then layer additional points of access to applications that would previously have been simply to cumbersome to offer externally. In my opinion, AP is one of the best features of Azure AD and it is only improving as Microsoft adds additional options for security and functionality.

This post is much more of an introduction to AP than a guide to configuration, if you want to talk about config, or have any other questions you can contact me on Twitter – @wedoAzure or via email.