Contents

• Windows Virtual Desktop – Group based assignment
• The Setup
• Prerequisites
• Why a Runbook?
• The Implementation Guide
• Setup on hybrid worker machine
• Azure
• Schedule
• Runbook Schedule
• Logic App Schedule
• Using the script for 2 application groups (or more)
• Testing if Everyting Works
• Contact Information and script

Windows Virtual Desktop – Group based assignment

Windows Virtual Desktop WVD is a great new solution from Microsoft that helps partners and customers to easy manage and deploy virtual desktops and apps to end users. WVD is at an early state but in constant development, but currently not supporting group-based assignment of users. Users needs to be assigned induvidial to Virtual Desktops or AppGroups.

The mainpart of our costumers runs hybrids setup where users and computer accounts are based on identity from a traditional Active Directory AD. In the following guide I will descripe how to dynamicly assign users to WVD from the membership of a Security Group In AD in a safe way.

Supporters can then assign users from the “Active Directory Users and Computers” Console, without usage of powershell or other 3 party tools even if multiple AppGroups exists, this is possible because we use a runbook in azure that checks the security group every 30 minutes or more frequently if necessary, then it adds them or removes them based on their membership of the security group.

The Setup

• Hybrid Cloud
• Azure AD Connect Service
• Two application groups
• Connection to DC

In our setup we are running vm’s in azure and Azure AD Connect to sync users between AD and AAD, the reason for doing this is that, our customer still have applications that can’t support cloud only, so we move all vm’s to azure and move all the features we can to a cloud only solution.

Prerequisites

Now, before we begin with the setup we will need to complete a few prerequisites first.

• Azure Automation Account
  You will need to create an Azure Automation Account. This is the service that handles all the automation tasks that we are going to perform.

• Hybrid worker
  If you don’t have a hybrid worker installed in your environment, then there is no connection between Azure and your envoirment, that means the runbook will not be able to execute in your environment, and the script will therefore not work. https://docs.microsoft.com/en-us/Azure/automation/automation-hybrid-runbook-worker

• Active Directory Service Account
  You will need to create a service account that has Read and Write permissions on the security group that your adding and removing users to.
  You will also need to give it “log on as a service” permissions on the server that you installed the hybrid worker on, this can also be done with a group policy https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/log-on-as-a-service

Now, before we begin with the setup we will need to complete a few prerequisites first.

Why a Runbook?

• Security
  Runbooks are more secure then for example a scheduled task on a normal server, if somebody hacks into your server then they are in, they can shut down the task or delete it.
  But in azure there is a lot of Security, frist of all there is Condetional access that’s a tool that maks it possible to deny access or grant access based on a condetion you set up, that could be location or suspensios behavior.
  Then there is MFA so you need to authenticate youself with a seperate device or mail.
  Then at last there is PIM (Privileged Identity Management) that makes it possible for you to request access to resources or roles and you can set it up so that you request needs to be approved by sombody else before your granted access.
  So all in all if you want to break into stop this runbook, if all these security mesures are set up you would need to steal a laptop and a phone belonging to the same person, use his credentials and a coworker to break in, on top of that you would need to be at an approved location and that’s a tough task if you ask me.

• Fail over
  If you want to you can install multiple hybrid workers on diffrent servers across your envoirment, so that if one server fails then you runbook will just execute on another server.

• Logs and output
  All your output from your script are saved in azure after every run, so you can just pick the date and select the job and check all the output, no need to export it to seperate csv files.

• All your automation in one place
  Instead of having a scheduled task in one server and another one on a second server, and each of them outputting log files to different shares, then you have azure automation accounts one place to have all your automation.

• Other benefits
  There are lots of benefits, of using azure runbooks, they include intergrations to other systems, deployment of scripts from azure devops and many more, if your interested you can read more here https://docs.microsoft.com/en-us/azure/automation/

The Implementation Guide

First of all we will need to gather some information for the script to work.

• TenantName

• ApplicationGroupName

• HostPoolName

• SecurityGroup

• AADTenantID

Fill out the variables with data that fits your environment, and save the script somewhere on your computer, so you can use it for later.

Setup on hybrid worker machine

You will need to install two PowerShell modules on the same server, where your hybrid worker is installed.

Set-PSRepository -Name "PSGallery" -SourceLocation
"https://www.powershellgallery.com/api/v2" -InstallationPolicy Trusted

Find-Module "Microsoft.RDInfra.RDPowershell" | Install-Module
Add-WindowsFeature RSAT-AD-PowerShell

Set-PSRepository -Name "PSGallery" -SourceLocation
"https://www.powershellgallery.com/api/v2" -InstallationPolicy Untrusted

When you have run these three commands, you will then have installed the two modules. You don’t need to configure anything else for your on-premises environment. The Add-WindowsFeature command is used to get the Active Directory module installed. The reason for doing it this way, is because the Active Directory module is actually a feature for the Windows servers.

Azure

Go to the Automation Account you created, by searching for Automation Acount in the search field in Azure and select the Automation Account you created.

Go to the credentials tab and add your WVD credentials and your AD Service Account, beaware that you might have to use the pre 2000 windows logon name on the service account for it to work.

Go create the runbook where your script will run. Press the Runbook tab and then press the “Create a Runbook” button.

Give it a name and select PowerShell as runbook type and then press Create.

Testing If Everyting Works

To make sure everything works, you can do a few different things to test it out.

First of all, add someone to your group in Active Directory. Then execute the runbook in the Automation Account. Press the start button, or, if you are using a Logic App, click “Run trigger”.

Then go to the Automation Account and select the jobs tab and click the most recent one.

Paste the entire script and replace the automation credential name with the variable name of the credentials we just added.

Press Publish and the script is ready for use.

Schedule

There are two ways we can make a schedule. We can make a normal runbook schedule, which works perfectly but it can only run once per hour, so if you need it to run more frequently, then you need to make a logic app to run it for you. We made the runbook execute every 30 minutes. I will provide guidelines on how to create the logic app as well.

Runbook Schedule

Making a normal runbook schedule is pretty straight forward. You just go into your runbook and select Schedules, and then press the “Add a schedule” button.

Logic App Schedule

With a logic app, it will be possible to run the runbook every minute, but first you will need to create a service account that can run the logic app for us. It doesn’t matter which type of account it is, as long as MFA is disabled for the account, otherwise it will not be able to run the runbook.

When the account has been created, we will need to give it some rights to our automation account, we do that by going to our automation account and selecting the access control tab and pressing the add button on the right.

Select Automation Operator, select the service account, select save. Now your service account has been delegated rights.

Then you press “New step” and select “Create job (Azure automation)”

Using the script for 2 application groups (or more)

If you want to use it for more then one application then its really easy to setup, first of all you will need to give your AD service account read and write permessions on the new Security Group that you created, or you can make a new service account for this specific security group, if you want to make it even more secure. then you will need to copy this part of the script.

Then you can just keep copying and pasting until you have the amount you need.

If you would like to see an example of this, you can go to this link to check it out:
https://github.com/dani9335/wvdaddgroupmember/blob/master/add-multiplememberstoappgroups.ps1

Testing If Everyting Works

To make sure everything works, you can do a few different things to test it out.

First of all, add someone to your group in Active Directory. Then execute the runbook in the Automation Account. Press the start button, or, if you are using a Logic App, click “Run trigger”.

Then go to the Automation Account and select the jobs tab and click the most recent one.

Always remember if passwords to any of your service accounts expire then your script will not work.

Contact Information and script

If you run into any problem or have questions, you can reach me at dpg@automize.dk and I will reply as soon as possible.

You will find the script below:
https://github.com/dani9335/wvdaddgroupmember/blob/master/add-appgroupmember.ps1