Thursday, 28 November 2019

Test driving Windows Virtual Desktop

This week I've been working with Windows Virtual Desktop (WVD) for the first time. Microsoft announced General Availability in September and I'm just getting to it now. I think it's great. What's not to like? We can now deploy a Remote Desktop solution in Azure without having to worry about the underlying infrastructure (RD Gateway, an RD Connection Broker, and RD Web Access).

I've captured my experience in this blog post. It's pretty long so I've divided it into the following sections to make it easier to read.
  • What is Microsoft Windows Virtual Desktop?
  • Is it the same as Microsoft Managed Desktop?
  • Windows Virtual Desktop prerequisites
  • Setting up Windows Virtual Desktop
  • Working with Windows Virtual Desktop
  • Advanced configuration (with RemoteApp, FSLogix containers and MSIX App Attach)

What is Windows Virtual Desktop?

WVD allows you to deploy and scale virtualized Windows desktops and apps on Azure. It can be deployed in minutes and offers simplified management, multi-session Windows 10 and optimizations for Office 365 ProPlus. We can deploy VMs with Windows 10 or Windows Server 2016. We can also use our own custom Windows 7 images. As an added bonus this includes free extended support for Windows 7 (extended security updates for three years). That's a no-brainer.

Is this the same as Microsoft Managed Desktop?

No, Microsoft Managed Desktops is something different. This is also a cloud service but Microsoft will manage Windows 10 and Office 365 ProPlus on your hardware. Obviously Microsoft will only support this on a specific list of devices.

This service includes the management of:
  • hardware (once it's on the approved list and registered)
  • software updates
  • Office 365 ProPlus and LOB apps as appropriate
  • end user device deployment
  • security monitoring and response
OK, so back to WVD.

Windows Virtual Desktop Prerequisites

There are some requirements before you can get started.
  • Licenses - you should consult the official docs  but I have Microsoft 365 E3 for testing.
  • Obviously we need an Azure subscription - this will cost you money (but not too much).
  • User accounts - you'll need to nominate a WVD Tenant Creator and some test host pool users.
  • You need to decide what directory services you will use to support your infrastructure. You can use Azure AD, DC hosted in Azure or a DC hosted on premises with a VPN to Azure. The Azure VMs that you create can be AD-joined or hybrid AD-joined (not Azure AD-joined.
  • Azure network - you need to have a virtual network in Azure. Remember you don't configure DHCP in Azure virtual networks. IP addressing is dynamic based on the assigned subnet. 

  • I'm using a DC hosted in Azure so I configured a static DNS record for the DC in the properties of the virtual network. This way my VMs will be able to join the domain.
  • Download and install the Windows Virtual Desktop PowerShell module. Launch PowerShell as administrator and run:
         Install-Module -Name Microsoft.RDInfra.RDPowerShell
  •  Then import the module:
          Import-Module -Name Microsoft.RDInfra.RDPowerShell

Setting up Windows Virtual Desktop

Now let's get started setting up the environment. The first thing we need to do is to allow Windows Virtual Desktop services to access the Azure AD tenant. For this we'll need the tenant ID (also referred to as Directory ID).

We can get the Directory ID in the properties of Azure Active Directory. Copy it be clicking on the blue box to the right. You'll need this a couple of times during this process.

Now navigate to (this is Windows Virtual Desktop services). Add your tenant ID and click Submit for the Server App.

Accept that you are granting permissions to WVD.

This was successful.

Repeat the process for the client app.

Accept the permissions.

Enjoy the success. Now that we've granted access to Azure AD we need to grant permissions to a user to create a Windows Virtual Desktop tenant. Essentially we'll assign the "TenantCreator" role to a user account.

We do this in the Azure Portal.

Navigate to Azure Active Directory and select Enterprise Applications.

Select Windows Virtual Desktop and choose Users and Groups.

Select Add User and add the lucky user who will create the WVD tenant. I've chosen Fred. See that he is now a TenantCreator.

Now we'll create the WVD tenant. Remember we copied the tenant ID earlier (aka Directory ID). We're going to need it again. We'll also need the Azure Subscription ID.

It's easy to find. Navigate to your Subscriptions using the search.

You'll find the subscription ID. Now's let's create the WVD tenant. We do that using PoSH. Sign in to Windows Virtual Desktop by using the TenantCreator user account with this cmdlet:

Add-RdsAccount -DeploymentUrl ""

Create a new Windows Virtual Desktop tenant associated with the Azure Active Directory tenant (you'll choose a tenant name and replace the bracketed values with your tenant ID and subscription ID):

New-RdsTenant -Name <TenantName> -AadTenantId <DirectoryID> -AzureSubscriptionId <SubscriptionID>

The WVD tenant has been created. Now we'll deploy a host pool of virtual desktops. Sign into the Azure Portal and select Create a Resource.

Search for Windows Virtual Desktop and select Windows Virtual Desktop - Provision a host pool.

Choose to Create a host pool. There are four pages of details to configure.

The first page has some basics.
  • Choose the subscription that you want to use (there will be a cost).
  • Select a Resource Group. It needs to be empty so you'll probably create a new one here.
  • Select your region.
  • Enter a name for the host pool.
  • Choose the desktop type. Personal is where every user has a dedicated VM. I've chosen pooled.
  • Configure the users that will log into these VMs (comma-separated list). Note that you'll also need to enter the TenantCreator here if he will need access. It is not automatic.

The next page is for our expected usage. This determines how many VMs will be deployed. Click Change Size if you want to change any VM details. I'm conscious of cost in my lab so I've done that. Also enter a prefix for the names of the VMs

The third page allows you to configure the VMs. Choose the following:
  • Image Operating System - I've chosen Windows 10 Enterprise multi-session with Office 365 ProPlus.
  • Disk type - I've chosen Premium SSDs for performance.
  • Domain join account and password - the account must already be configured on the domain. This requires password complexity so be careful here.
  • Domain and domain OU - remember the VMs must be able to find the DC
  • Virtual network and subnet - make sure your DNS configuration is in place.

The final page asks for the WVD tenant details. Enter the tenant name and the owner account details. That's Fred, who created the tenant.

Finally you're asked to review your configuration and then Create the host pool.

The deployment is underway. You can see the detailed steps.

The deployment has completed.

The VMs have been created......

…..and joined to the domain.

Working with Windows Virtual Desktop

There are two ways to access the WVD pool from a desktop.
  • Remote Desktop client
  • Browser (HTML5 client)
I'm going with the full client option. You can download from here

It's an MSI installer so just run and install as normal.

On the first launch you have to Subscribe to WVD.

Sign in as a permitted user.

Looks like we're in business.

I can see my WVD host pool......

….and I've signed into one of my VMs.

I can now work normally. I can browse to fileshares on one of my servers hosted in Azure.

Advanced WVD configuration

So what's next? We can get lot more advanced with WVD and I will when I have more time.


We can create a RemoteApp app group and publish individual Start menu apps.

FSLogix profile containers

The WVD service offers FSLogix profile containers as the recommended user profile solution. 

MSIX App Attach

MSIX app attach is where the application (stored in MSIX format on a central location) is attached to the operating system. After attaching, applications look and feel as locally installed to the user as well as the operating system.

That's it for now. I've enjoyed test driving Windows Virtual desktop. You can get more information in the official docs

Until next time.......

Wednesday, 16 October 2019

SCCM Current Branch - Updates and Servicing issue

I've been working with a customer this week upgrading ConfigMgr Current Branch to 1906. However I encountered a problem even before I got started.

In the ConfigMgr console. I could see that 1906 was available to download.

However all options were greyed out.

I've had similar problems in the past and the trusty CMUpdateReset tool usually got me out of trouble. However not this time. I ran the tool but the problem persisted. 1906 disappeared from the console but when it reappeared the options were still greyed out. 

There were some fairly catastrophic messages in the dmpdownloader.log file.

WARNING: Failed to find a certificate matching the following thumbprint: .

ERROR: DmpDownloader:GetMessages: Failed to get messages.. Exception: System.AggregateException: One or more errors occurred. ---> Microsoft.Management.Services.Common.NotSupportedException: {~~  "_version": 3,~~  "Message": "An error has occurred - Operation ID (for customer support): 926c3692-bde5-4c8d-a6fa-7297f93d226a - Activity ID: fb69f026-d17f-4bed-8c57-4a7ded103f37 - Url:$filter=Mode eq 1&$top=500"

I don't know if there was an easier or less dramatic way to solve this but I fixed it by removing and re-adding the Service Connection Point (this is a perfectly harmless operation).

Normal service was resumed and I could upgrade the site.

I hope this helps. Until next time.....

Monday, 30 September 2019

My experience with iOS user enrollment using Intune

Those of us who manage iOS devices have some new terminology to learn with iOS 13. Automated Device enrollment is new 😀 and what is iOS user enrollment all about?

Automated Device enrollment is the new name for the corporate Device enrollment program (DEP). iOS user enrollment (supported in iOS 13.1) was announced by Apple in June and is designed specifically for the BYOD scenario to address the privacy concerns of users and businesses. The enrolling user can choose between user and device enrollment when they are enrolling the device. iOS user enrollment has been compared to Android Enterprise with Work Profile where the work area of the device is completely separate from the personal area (strange to see Google before Apple with an enterprise solution). In this case the device is not fully managed.

Personally I don't like the terms user and device enrollment. My customers are used to the process being referred to as user-driven enrollment so this could be confusing. I'd much prefer the terms personal and corporate enrollment.

So what do we need for the solution?


We need iOS 13.1 or later devices. I prepared an iPhone and an iPad for my testing (a little more on this later).

Apple ID

We have to configure the Apple MDM Push certificate in the Intune portal as normal to facilitate the enrollment of Apple devices. However there is an additional requirement for iOS user enrollment. Each user must have a Managed Apple ID. I wasn't familiar with this so I had to do some research. You create Managed Apple Ids using the Apple Business Manager. This is a free tool (a slick new model of the Device Enrollment Program) but you need to be registered to take advantage of it. I don't have access so I won't be abe to create the required IDs. However I still want to see the user experience so I'll take it as far as I can. 

See here for more information on Manged Apple IDs

  • This ID will control access to the corporate area of the device. 
  • It should not be the same as the Apple ID associated with the device itself. That ID controls the personal area of the phone.
  • You must sign in to Intune to start the enrollment using the Managed Apple ID.
  • You will need a Volume Purchase Program token to deploy corporate apps to these devices.
So let's see the solution in action. How do we configure it?

In the Intune portal, navigate to Device enrollment > Apple enrollment. See the new section for Enrollment targeting. Click on Enrollment types, which is a preview feature.

 Click to create a profile.

We are presented with a single choice - iOS. 

Aside: I don't quite understand this. I've read somewhere that this is because iOS 13 differentiates between iOS and iPadOS devices and iPads are not supported for user enrollment. This does make sense but it's not the case in my experience, although I could be wrong. I was able to initiate user enrolment on both my test devices.

Enter a profile name and description.

I want users to have to choose the enrollment type so I'll select Required.

When you choose Required the default enrollment type choices are no longer available. See the note about needing the Azure Authenticator app in order for conditional access to work on devices targeted with user enrollment.

Assign the profile to a group - I've chosen All Users for my test.

Review your choices before you Create and assign the profile.

User experience

Now let's have a look at the user experience when enrolling a device. As usual it starts with the Intune Company Portal. Download from the App Store and Install.

Another corporate account was found on my test device so I chose to Sign in with another account.

I clicked on + to add an account.

This is where you should enter your Managed Apple ID. I don't have one so I'll wing it and see how far I can get.

Enter your password.

We're shown the list of steps that will be followed to complete the enrollment.

Ok, now this is different. I'm going to choose "I own this device".

When I do I am offered the options to secure the entire device or work related content only, cool. 

I chose "Secure work-related apps and data only".

We can see some progress.

We can see the Device management and privacy details - what your organization can't see on the device.....

….and what they can see. I don't quite understand why these dialog screens are exactly the same as those we see for device enrollment. Surely they should be different?

We see further progress.

We have to Allow the company portal website to download a configuration profile.

The management profile has downloaded and we're told to go the Settings to continue. We're familiar with this two-step enrollment with later iOS devices.

We see that we now should "Enrol in "your directory"".

Click "Enrol my iPhone" to continue.

Aside: I was also able to get this far with my test iPad so I'm not sure that it's true to say iPads are not yet supported".

Back to the iPhone - entered the existing passcode to install  the management profile.

Now I have to enter my Managed Apple ID. The ID is prepopulated based on the credentials I previously entered and it can't be changed or removed.

The process will finish and the device will be enrolled as a personal device.

Some thoughts on iOS user enrollment

iOS user enrollment is a really good idea and kudos to Microsoft for quickly integrating it with Intune. However I'm not sure Apple have got this right. Not all organizations will be able to use it. The requirement for DEP/Apple Business Manager and VPP programs can be a little too much for some organizations (not to mention testing in labs for IT Pros like me). Also the programs are not avilable in all countries.

It's certainly not as straightforward as testing Android Enterprise with Work Profile. Ironically it's easier to manage the entire device using device enrollment.

I hope you find this useful. Until next time...….