Windows Virtual Desktop - AD join account requirements

It took me a while to figure out why my customer deployment of a WVD host pool would not work. Everything looked normal to me. The problem was that the VMs could be created but could not be joined to the domain (remember all Windows Virtual Desktops must be domain joined). Eventually I tracked down the problem to the domain-join account. This made me look more closely at the requirements for this account, so here we go.

What is the WVD domain-join account? 

This account has to be entered during the provisioning of a WVD host pool.

One of the required items is the AD domain join UPN. This is the account that will be used to join the VMs to your on-premises Active Directory. If you look at the tooltip you will see the following text:

"UPN of an Active Directory user that has permissions and will be used to join the virtual machines to your domain. For example, vmjoiner@contoso.com. A local user account with this name will be created on each virtual machine. Do not enter a user who has MFA enabled. See https://aka.ms/vmUsernameReq for invalid usernames".

There are a few takeways here.

• the account must have permissions to join AD (this is obvious)
• a local account is actually created on each VM
• the account cannot be MFA enabled
• take note of the URL for invalid usernames (see next section)

Requirement #1: MFA cannot be enabled on the WVD AD join account. 

(tip: you should create a service account for this).

Invalid usernames

The official WVD docs don't tell us much about the requirements for this account.

"Enter the user principal name and password. This account must be the domain account that will join the virtual machines to the Active Directory domain. This same username and password will be created on the virtual machines as a local account. You can reset these local accounts later".

However there are some specific requirements around invalid usernames, which are actually enforced by Azure (this was my problem). You can find them in the Azure VMs FAQ docs 

These are the blacklisted usernames. There are a number of popular contenders in there.

Requirement #2: the username cannot be one of the blacklisted usernames.

Password

You will find the password requirements in the same doc

Requirement #3: in general the password must be complex with a minimum of 12 characters.

I hope this helps you when implementing WVD. Until next time.....

Configuration Manager co-management considerations

Co-management allows you to cloud-attach your Configuration Manager infrastructure. Essentially it enables you to manage Windows 10 devices with the ConfigMgr agent and Intune MDM at the same time. Implementing co-management gives you instant access to invaluable features like conditional access.

I just want to share some information on co-management that I find useful.

Co-management scenarios

My previous understanding was that, without co-management, it was not possible to manage a Windows 10 device with ConfigMgr and Intune at the same time. However, as I recently discovered on a customer site, that is only partially true. It depends on the order.

On a recent customer engagement, I had configured co-management with a pilot collection.

I was very surprised to see co-managed devices in the Azure portal that were not members of the pilot collection. I now understand that it depends on the scenario.

If the ConfigMgr agent is running on a device and the device becomes Azure AD joined, no attempt is made to enrol in Intune, even if automatic Intune enrolment is configured. When co-management is configured, then automatic Intune enrolment kicks in and enrols the device in Intune.

However, what happens if the device is MDM enrolled first? In this case you can install the ConfigMgr agent. The device will be co-managed but will not receive any workloads if it hasn’t been added to a co-managed collection.

In this case you will see a co-management capability of 1, which is what I saw on my customer site. This means that the device is co-managed but hasn’t received any policy. The “real” co-managed devices had a capability of 45. 

Intune automatic enrolment

What happens if my devices are already Azure AD joined but I haven’t configured automatic Intune enrolment? 

I was concerned that automatic enrolment was a one-time thing i.e. when the device is joined to Azure AD it is automatically enrolled in Intune (if that is configured). I was concerned that if automatic enrolment is not configured first then the Intune enrolment doesn’t try again as the device will already be joined to Azure AD.

MDM URLs must be populated on the client before it can be successfully enrolled. These URLs are populated by the automatic Intune enrolment user scopes. When co-management is configured, the ConfigMgr agent periodically checks for these URLs and keeps retrying until they are populated. At that point, the device is enrolled in Intune. It is not a one-time thing.

ConfigMgr client settings

Hybrid Azure AD join, and automatic Intune enrolment are among the prerequisites for co-management. What happens if you configure hybrid AADJ using Azure AD Connect? Do you still need to configure this in ConfigMgr client settings (Automatically register new Windows 10 domain joined devices with Azure Active Directory to = Yes)?

The answer is no. You do not need it. This is a throwback to when you needed a GPO to tell devices to perform a hybrid AADJ. Current supported versions of Windows 10 will automatically join Azure AD if they find a Service Connection Point in Active Directory.

However, this is the default setting and you should leave it alone. If you turn it off, you may block devices from competing the AAD join.

GPO

As stated above you no longer need to configure a GPO to force a hybrid AAD join. For current supported Windows 10 devices, this should happen automatically.

Co-management display changes (April 2020)

There are some changes in the 2004 service release. On the All devices page, the entries for the Managed by column have changed:

• Intune is now displayed instead of MDM
• Co-managed is now displayed instead of MDM/ConfigMgr Agent

Learn more about co-management in the official Microsoft docs

I hope this helps you to understand and configure co-management. Until next time…..

LAPS not working after computer rebuilds

Many of my customers use the Microsoft Local Administrator Password Solution (LAPS) to manage local account passwords of domain joined computers. Recently I created a Windows 10 v1909 task sequence solution with ConfigMgr for one of these customers. Everything looked good in testing but after a few days I got a report to say that LAPS wasn't working. Admins couldn't sign into the devices uing the local administrator password.

I figured that was unusual so I reinstalled W10 v1909 on a test laptop and LAPS worked perfectly. That was a bit odd. What was the difference between my test and the customers test?

You have to delve a little deeper into how LAPS works to be able to answer that question. This Microsoft blog post explains what happens to LAPS during machine reinstalls.

“LAPS uses the attribute ms-MCS-AdmPwdExpirationTime on the computer object to remember the expiration time of local administrator password. It works pretty well during lifetime of computer. But what happens when computer is reinstalled? LAPS design expects that in this case, computer account is deleted and created again. But what if you decide to reuse computer account?

In this case, when you install the computer and then install LAPS CSE on it, during first GPO refresh after install, CSE looks to computer account and sees that it is not time to reset password yet: ms-MCS-AdmPwdExpirationTime attribute still has value populated by previous computer that used this computer account. This means that the password that is on local administrator account after setup may be there until the password expiration time set by previous computer expires: up to 30 days by default”.

That explained to me why my test computer worked and none of the others did. I ALWAYS delete the computer object from ConfigMgr and Active Directory before I re-image. The customer verified that they didn't do this for any of their tests.

The customer wondered why this not happen before. I explained that it did occur but they didn't notice as they didn’t test LAPS immediately. The solution corrects itself after the password expiration date.

It's easy to verify that this is happening:

I generated the password on 10th Feb but it was set to expire on 12th Feb. That was my first clue. The password should have been valid for 30 days.

I hope this helps you to explain the anomaly if you encounter it. It's expected behaviour. 

Until next time....

Note: several people have pointed out to me that it's better to automatically expire the existing password during the rebuild by including this script in the task sequence.

FSLogix profile compacting

I've done a lot of work with Windows Virtual Desktop recently and I've incorporated profile management with FSLogix technology. It all works really well and users can log in to the desktop really quickly, even with large profiles. Remember roaming profiles. I hated those. You can read about my experience configuring FSLogix containers here

FSlogix containers use VHD or VHDX files. This has one drawback in that these files do not shrink on their own and the file sizes can be bigger than they need to be. This could be a problem in your infrastructure as you have to pay for the storage.

Let's have a look at the file sizes in my test lab.

This is the FSLogix VHD associated with my profile. It's pretty big at almost 12GB. 

But is the profile really that big? You can mount the VHD to look inside.

You'll get an error that the file could not be mounted. No problem, we just have to give it a drive letter.

Open Disk Management and you'll see a new disk for the profile. 

Right click the disk and choose Change Drive Letter and Paths.

Choose a drive letter and select Add.

The disk is now ready......

…..and you'll see that the drive is now mounted.

You can now see the real profile size. See my profile is 1.6GB. That's a lot smaller than the VHD of 11.8GB.

Don't forget to eject the drive. We don't want to leave it mounted when not in use.

This is the overall size of the VHDs in my test lab. It's 56GB which is a lot bigger than it needs to be. 

Luckily there are community scripts available that can help with this problem.

You'll find a good one here. The FSLogix Profile Compacting tool was written by David Ott (@citrixirc). These are David's instructions:

1. The program will remember the last directory selected (via an .ini file – if it exists), or you can click the “…” button at the top left to browse to the root directory of your profile share.
2. Once a directory is selected it will list all .vhd and .vhdx files along with their current size and their current locked status in descending order by size.
3. Select the profile(s) you wish to compact (you can select multiple using ctrl and shift+click)
4. Click the compact button, and the program will process each profile selected one at a time
   1. Checks one more time to make sure the file is not locked
      1. If it is, it will skip on to the next one
   2. Gets the current size again before processing
   3. Attaches the vhd(x) in R/W mode
   4. Finds the first available drive letter it can assign (between D and Z)
   5. Waits 3 seconds before assigning the drive letter (there can be a timing issue if you don’t wait a couple of seconds between mount and drive letter assignment)
   6. Defrags the mounted volume
   7. Detaches and re-attaches as read only
   8. Uses diskpart to compact the vhd(x)
   9. Gets the size of the file post processing
   10. Updates the results pane
5. After it has run through all the selected profiles it will display the total reduction in MB at the bottom.

So let's see the tool in action.

I've download the tool to the server containing the FSLogix profiles. It's an executable file. Launch the tool.

Browse to the folder containing the VHDs. They will be listed showing the name, size and status (locked or not). Containers that are locked are in use and cannot be compacted.

Select the profiles and choose Compact.

In Disk Management you will see each VHD being mounted in turn (if you care to).

You can track progress in the tool.

The process has finished and the VHDs have been compacted. See some have not been touched as they were in use.

Let's see what it did to my profile. There has been a massive compaction. It is now 1.7GB (remember it was 11.8GB).

My overall profile size has been reduced from 58.6GB to 44.1GB in 10 minutes. That is certainly worth doing. It would be a good idea to implement this a regular scheduled task. Remember though that you'll never get the same reduction again as you did the first time.

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

Error while adding users to WVD host pool - apostrophe problem

I was creating a Windows Virtual Desktop environment for a customer today and had some difficulty when I was creating the host pool. WVD is not yet fully integrated with the Azure portal so doesn't support dynamic groups. You have to add a comma separated list of users when you are creating the host pool (or you can do it afterwards). Anyway I was getting this error when I entered a pre-prepared list of approximately 200 users.

The list may only contain UPNs (in the form of valid email addresses) separated by commas. Leading whitespace, trailing whitespace, or additional spaces before or after commas is not allowed.

I looked through my list in Notepad trying to find a space before or after a comma but no joy. Eventually I found the problem. One of the users had an apostrophe in their UPN and this was messing with my formatting. Removing this UPN from the list allowed me to continue.

It's the little things that cost you the most time sometimes. I hope this helps if you see a similar problem.

Until next time.....