New Microsoft Cloud online course available

I have just released a new online training course over at the CIAOPS Academy:

Microsoft Cloud Workshop for IT Professionals and Resellers

This course is especially for those looking to understand and sell Microsoft Cloud Services like Microsoft 365 and Azure, especially in the Small Business (SMB) space. The course takes you through overviews of services plus deep dives into things like security. It also shows you how to craft unique go to market offerings that you can build easily.

All the information you need is here including:

Over 18 hours of video instructions
Downloadable content, including slides, white papers, etc
Links to additional training material

If you are looking at coming to grips with everything that the Microsoft Cloud can provider your customers and users, then this is course for you!

As a special offer to kick things along I’m offering a 50% discount for a limited time. Use the promo code:

LAUNCH0520

at check out

or the direct link:

https://www.ciaopsacademy.com/p/mscloudworkshop/?product_id=1942989&coupon_code=LAUNCH0520

I’ll continue to add content to this course, so there is never a better time to take advantage of the launch of this course! You may also want to consider the full course catalogue at the CIAOPS Academy which will include this new course as well.

Creating a WVD host pool in the Azure console

Before you launch into creating host pools in Windows Virtual Desktop (WVD), you’ll need to do some preparations. I’ve detailed those previously here:

What you need for Windows Virtual Desktop (WVD)

Once you have all that in place, navigate to Windows Virtual Desktop in your portal and you should see the following screen.

A host pool is the container in which the virtual machines hosting your desktops and apps will live in. You’ll need at least one of these before you configure anything else

Select Host pools from the menu on the left.

If you have no host pools as yet you can select the Create host pool button at the bottom of the page as shown or you can select the Add button at the top of the page.

Step one will be to nominate a Resource group for your pool, as well as a Name for your host pool. You’ll then need to select a Location for the pool metadata to live. Note, at this time, these locations are in the US but will expand in the future.

You have a number of options to select from when it comes to Host pool type. Typically, you are going to select the type as Pooled, rather than Personal. This will allow multiple users to share multiple hosts that you create.

You then need to determine Max session limit, which is the maximum number of users your hosts can have. The number you place here will depend on the size of your configuration. The suggestion is to keep it low initially as adding additional hosts is easy when required.

A few suggestions here. I’d suggest you keep all of your WVD infrastructure in the same Azure Resource group and in the same region. To be able to deploy hosts onto the VNet you have already created prior to this, things will need to be in the same region. The location of the metadata configured in this screen is not that important, but where you put your pool and hosts does matter. So, keep it all together in the same Resource group and region I suggest.

Press the Next: Virtual machines button at the bottom of the page to continue.

Here, you can add hosts (VMs) to you pool at the time you create your pool if you wish. You can always add hosts later, so to reduce complexity here, leave this set as No and select the Next: Workspaces button at the bottom of the page to continue.

You can also create a Workspace at the same time you create your pool. Think of a Workspace as a way to group virtual hosts and apps together. You can always add Workspaces later, so to reduce complexity, leave this set as No and select Next: Tags button at the bottom of the page to continue.

Azure tags are a great way to easily categorise Azure resources to help with things like billing and management. Here you can use pre-existing tags or create new tags.

When complete, select the Next: Review + create button at the bottom of the page to continue.

Your selections will then undergo validation as shown above.

If the validation passes, you should see the Create button at the bottom of the page. if you get an error here it maybe because the total number of cores exceeds the quota for the tenant as I detailed here:

Watch the core limit in your Azure tenant

Press the Create to complete the process.

You should then see a deployment screen as shown above and short time later you will see that the process has completed successfully.

If you return to your WVD console and look in Host pools you should now see the pool you just created as shown above.

If you select the Host pool name you should see the details of that pool as shown above.

If you look in the Application groups option from the menu on the left, you’ll see that a default Desktop application group (<Pool name?-DAG) has been created but has no users assigned as yet. You’ll see no RemoteApp application groups have been created as yet.

If you look in Session hosts, you see that nothing in here as yet either. We’ll be added hosts to this pool in the next step in a following article.

Remember, this host pool creation process is part of the Spring 2020 update to WVD. You can also create host pools with PowerShell, which I’ll cover in an upcoming article. However, you now have a container in which you can start adding virtual hosts.

Watch the core limit in your Azure tenant

So when spinning up a new host inside the new WVD experience I received the error as shown above:

The template deployment ‘AddVMsToHostPool-7b00d9c7-8690-455f-90fa-d69d2661601f-deployment’ is not valid according to the validation procedure. The tracking id is ‘867f4f35-b3dc-42c7-879d-b588517f15d0’. See inner errors for details

I wasted plenty of time looking in other location rather than looking in the “inner error: as recommended. To get there, press the copy button at the top right as shown and then paste the information. When I did do this and actually read what it said I saw:

Operation could not be completed as it results in exceeding approved Total Regional Cores quota. Additional details – Deployment Model: Resource Manager, Location: australiaeast, Current Limit: 10, Current Usage: 10, Additional Required: 2, (Minimum) New Limit Required: 12. Submit a request for Quota increase at

Damm! I gotta read those errors more fully I reminded myself, instead of ‘assuming’ and rushing off elsewhere for solution.

The end result was that I simply needed to lift the core quota for the tenant to allow for the additional VMs. Hopefully, this help someone else wasting time looking for a solution when it is really there in your face.

Uploading Graph credentials to Azure key Vault

If you have been following along with the recent articles I have been posting, you’ll know that I have been detailing how to use saved credentials from an Azure AD application to access multiple tenants using the Microsoft Graph. This post showed you how to create an Azure AD application inside multiple tenants and generate those credentials:

Using the Microsoft Graph with multiple tenants

Part of that process involved saving the Azure AD application credentials into locally encrypted XML files. I detailed how the encryption process for these configuration files locks those files to a single user on a single Windows 10 machine. Thus, if those files were copied to another location they couldn’t be used as you see below.

The potential challenge is, what if you want to use those credentials on multiple machines? And, what happens if the original machine on which those credential resides fails or is inaccessible? What is needed is a process to backup these files to somewhere secure in the cloud. Luckily, I know just the solution – Azure Key Vault.

To make things easy, I have created a free program to upload these credentials into an Azure Key Vault of your choosing. You’ll find the program at:

https://github.com/directorcia/Office365/blob/master/az-keyvault-saveto.exe

Simply download it and put into the same directory that the XML credential files for the domains live, as shown above.

When you run the program you’ll need to nominate an admin account for the Azure Key Vault destination as well as login into that Azure tenant into which you wish to save the credentials to. That tenant will need to have an Azure paid subscription.

Once you have logged into the destination tenant, you’ll be asked to select the subscription you wish to use for the Azure Key Vault. Remember, you need to have a paid Azure subscription to achieve all this.

When you enter the name of the destination Azure Resource Group for the destination Azure Key Vault, you’ll be warned if it already exists and if you are happy to use it. If no matching Azure Resource Group is found a new one will be created. Azure Resources Groups are just management containers for things like Azure Key Vaults.

You are then asked for the name of destination Azure Key Vault in that Resource Group. Again, the program will check to see if an Azure Key Vault of that name already exists and ask you whether you wish to use it. A single Azure Key Vault can hold many credentials, so using just one is fine if you choose to.

If the Azure Key Vault doesn’t already exist in that Azure Resource Group, a new one will be created with the name entered.

The destination Azure Key Vault will then be checked to determine whether a similar set of credentials already existing in there with the same name. If so, you’ll be given the option to use these existing entries or abort.

In most cases, with an Azure Key Vault with those credentials will not already exist so they can be written into the Azure Key Vault as shown above. At the end of the process, you’ll be given the option to delete the local XML configuration files if you want.

This process will continue through all the local XML configuration files for all the domains as shown above.

When the program has completed if you go and look in the destination Azure Key Vault, under the Secrets option on the left menu, you should find an entry for each configuration file uploaded as shown.

Effectively, you have now ‘backed up’ the Azure AD application credentials for all the tenants you have configured to a central secure location in Azure Key Vault.

I’ve also created a program here:

https://github.com/directorcia/Office365/blob/master/az-keyvault-saveto.exe

That will copy the credentials from Azure Key Vault and save them as local XML credential files. The good thing with this is now you can ‘restore’ these credentials securely to any Windows 10 machine.

Start by downloading the following file:

https://github.com/directorcia/Office365/blob/master/az-keyvault-saveto.exe

and placing it in a location where you want the Azure AD application credentials to be restored to.

When you run the program you’ll be asked to login to the Azure tenant with the Azure Key Vault containing the credentials you wish to restore as shown above.

You’ll then be prompted to select the subscription inside that tenant in which the Azure Key Vault is located as shown above.

Next, you’ll be prompted for the Azure Resource Group in which the Azure Key Vault lives as shown above.

Finally, you’ll be asked to select the Azure Key Vault inside that Azure Resource Group in which the credentials are stored. Remember, an Azure Resource Group can have many different resources, including multiple Azure Key Vaults if you choose.

The four credentials for each domain will be extracted one at a time and you will be prompted to hit CTRL+V (Paste) to save these in an encrypted format in the local directory. Thus, you’ll need to repeat this CTRL+V (Paste) process four times for each domain. I detailed this process previously if you need to understand it.

When the program is complete, if you look in the current directory, you should now see the familiar XML configuration files, four for each domain, as shown above. A copy of these credentials still remains in Azure Key Vault. You can now run any of the other Graph reporting programs on this machine as now the credential files are local o that machine.

These two programs now allow you to save the Azure AD application credential list into Azure Key Vault and restore them from there onto as many other Windows 10 workstations as you wish. Credentials are still stored securely locally and in Azure Key Vault.

Summary report on multiple tenants with the Microsoft Graph

In recent articles I’ve covered off how to add an Azure AD application to multiple tenants, then set the permissions and finally run a report all quickly and easily using automation. You’ll find all that here:

Reporting on multiple tenants with the Microsoft Graph

With those same Azure AD applications and permissions in place I have now developed a program that will provide you a summary report of emails, Teams, OneDrive for Business and SharePoint usage across multiple tenants, all WITHOUT the need to login to any of them!

You’ll find this program available at my GitHub repo here:

https://github.com/directorcia/Office365/blob/master/graph-summary-get.exe

For it to execute you’ll have needed to completed the process I detailed earlier of creating an Azure AD application in every tenant and adding suitable permissions. When that is complete you can simply run the above program. The program will need to be downloaded into the same directory that the tenant configuration files are located and run from there.

When it runs, it will get the configuration files in the current directory and access each tenant in order. It will collect information via the Microsoft Graph and then report on emails (above),

Teams (above),

OneDrive for Business (above),

and SharePoint (above). It will do this for each user in each tenant, again without the need to login to the tenant.

Thus, you could use this report to run on a regular schedule and provide details on each of the tenants. because no login is required to the tenants you can do this whole process unattended!

There is lots more that can be done in this manner via the Microsoft Graph, so look out for more stuff I’ll be making available in the future.

Microsoft Graph tenant management summary

I’ve covered a lot in recent articles around using the Microsoft Graph to manage a tenant. You can find those previous articles here:

Reporting on multiple tenants with the Microsoft Graph

Making PowerShell automation easier with the Microsoft Graph

To bring this all together I have created a summary video which you’ll find here:

https://www.youtube.com/watch?v=P3xhE2ESgE8

In it, you see how to use the code that I created to install Azure AD applications in tenants, provide permissions to these Azure AD applications and then finally run a report routine to extract the desired information.

Hopefully, this summary provides a nice easy way to see this concept in action end to end.

Reporting on multiple tenants with the Microsoft Graph

The aim of this project has been to show you how to manage multiple Microsoft 365 tenants quickly, easily and securely using the Microsoft Graph. this article builds on a previous article so go and take a look at:

Using the Microsoft Graph with multiple tenants

The complete steps in this whole process are:

1. Embed a ‘static’ Azure AD application in all the tenants you wish to access.

2. Give those ‘static’ Azure AD applications, in all those tenants, the appropriate permissions to access the tenant values.

3. Run a Graph request against these Azure AD applications in each tenant and extract the desired results.

This article will show you how to complete Steps 2 and 3. Step 1 was covered in the previous article.

Step 2 requires granting appropriate permissions to the Azure AD application already in place inside each tenant. The manual process of how to achieve this is covered in my article:

Using interactive PowerShell to access the Microsoft Graph

However, why do it manually if you can automate it I say? With that in mind, I have created a self executing PowerShell script to add the appropriate permissions to multiple tenants and allow the reading of OneDrive for Business usage information for all users. You’ll find the program to do this in my GitHub repo here:

https://github.com/directorcia/Office365/blob/master/graph-adapp-per-add.exe

You’ll need to download the file into the location where all the XML configuration files are that were created in Step 1. These will be needed again as the program cycles through all those tenants adding the appropriate permissions.

When you run the program, it will read the XML configuration files it finds in the directory and then ask you to login to each tenant again. You need to do this as you are granting/consenting to permissions and that requires administrator access.

You’ll need to complete the process of opening a browser session to each tenant and Accept the permissions as shown above. You’ll note that, in this case, they are read only permissions.

For more details on this process if you haven’t seen it, take a look at the article I wrote about doing the same thing for a single tenant:

Making PowerShell automation easier with the Microsoft Graph

Remember, that you don’t necessarily have to open the default browser all the time as the consent URL is always copied to the clipboard, so you could just past it into existing active sessions for that tenant if you wished.

The program will work through all the domains available.

If you want to see what’s happened visit the Azure portal for each tenant. Navigate to Azure Active Directory, then App Registrations, All Applications. Select the name of the Azure AD application you are using, then API permissions as shown above. You should see that the only permission it has is Read All usage reports. You should not that consent has also been granted.

That now completes Step 2 of the process.

We now have an Azure AD application in all the desired tenants and that Azure AD application has the appropriate permissions to do things. We can now start extracting information by continuing to Step 3.

In this example, we’ll run a program that will retrieve usage information about OneDrive for Business for each user in each tenant, without prompting for a login!

You’ll need to download the program I’ve written to do this (graph-odfb-get.exe), which you’ll find here:

https://github.com/directorcia/Office365/blob/master/graph-odfb-get.exe

Again, you need to place it the same directory where all the tenant configuration files are, as shown above, so it can access all the tenants configured in previous steps.

When you run the program, you’ll see the program loop through all the domains and all the users in those domains, without asking for a login.

At the end of each domain you’ll see a summary of OneDrive for Business for that domain as shown above.

At the end of the process you’ll see an aggregate summary for all your domains, as shown above.

This may seem like a lot of work but remember, you only need to do Steps 1 and 2 ONCE! Once the Azure AD application is configured for each tenant and the Graph has the appropriate permissions you can run Step 3 as MANY TIMES as you wish, securely, WITHOUT be prompted for a login to each tenant! How easy is that to automate?

This example has used just one aspect of the Graph being OneDrive for Business. You can use the Graph to do just about anything in Microsoft 365 you need to, including actually changing and update parameters!. In fact that is what I’m off to do right now.

Using the Microsoft Graph with multiple tenants

In a recent article:

Making PowerShell automation easier with the Microsoft Graph

I showed how to use the Microsoft Graph to embed an Azure AD application in a single tenant and then use that to make Graph queries against. What happens when you want to that across multiple tenants?

To achieve this you’ll need to basically do three things:

1. Embed a ‘static’ Azure AD application in all the tenants you wish to access.

2. Give those ‘static’ Azure AD applications, in all those tenants, the appropriate permissions to access the tenant values.

3. Run a Graph request against these Azure AD applications in each tenant and extract the results you want.

This article is going to look at Step 1 of this process.

So, the task at hand is to create a ‘static’ Azure AD application in all the tenants we want to access. I have detailed how to achieve this manually before here:

Using interactive PowerShell to access the Microsoft Graph

That may prove time consuming if you wish to do this across many tenants, so I have automated it via a freely available program here:

https://github.com/directorcia/Office365/blob/master/graph-adapp-add.exe

You can download the file into any directory on your machine. Best best is to use a Windows 10 machine that already has the AzureAD PowerShell module installed. This program will also generate a number of configuration files in the current directory for each domain you connect to.

Running the program will launch the PowerShell script as shown. You’ll then be prompted for the name of your Azure AD application. This is the display name that will appear inside your Azure AD. This name will be the same across all tenants you connect to. Here I’ve chosen to call my Azure AD application ciaops.

You’ll then be prompted for the email address of a tenant administrator with the rights to create an Azure AD application.

You’ll then be take through the normal sign in process for that tenant with that user as shown above. This will include any MFA if required.

The tenant will be check to see if an existing Azure AD application of the same name already exists and if it does you’ll see a warning like shown above. The program will then skip adding an Azure AD Application to this tenant and move on to the next tenant.

Assuming no Azure AD application of the same name exists in that tenant you’ll see that a new Azure AD application of that name is created. When a token is created in a tenant there are fours pieces of information that will need to be saved:

1. Application ID

2. Object ID

3. Application secret

4. Tenant ID

Each of these will be written to a secure configuration XML file I’ll explain in detail below. For now, just appreciate that these values need to be written securely to files so they can be used later. To achieve that, the program uses the get-credential PowerShell command to capture these securely to be written.

To complete this process all you need to do is use the Paste command (i.e. CTRL+V) when prompted at the password field as shown.

So here, simply hit CTRL+V and then ENTER. The actual value you are pasting is a few lines up in the display as you can see above if you need it.

You’ll need to complete that process four times for each variable as shown above.

You are then prompted for the next domain you wish to add an Azure AD application to. You repeat the same entry process for each new domain you wish to use.

When you have no more domains to configure, simply press Enter at the admin domain prompt. At that point, the program will disconnect from any Azure AD and use the captured credentials to check whether it can access all these tenants. To do this, it reads from the saved configuration files and makes a basic read request to the Microsoft Graph using the Azure AD application details for each tenant to verify success. It merely tests that it can get the Graph API for that tenant.

At this point you now have an Azure AD application of the same name, inside each tenant you configured, with no permissions to anything with the Graph.

If you now return to the directory where you ran the program from you’ll see a number of additional files as shown above.

The graph-adapp-set.txt is a log of the whole process so you can see what has happened.

You’ll also see four XML files per tenant. These contain the important variables for the tenant mentioned previously. They are in format of:

<domain>-tenid.xml – holds encrypted Tenant ID

<domain>-appsec.xml – holds the encrypted application secret of the Azure AD application for the tenant

<domain>.objid.xml – holds the encrypted Object ID of the Azure AD application for the tenant

<domain>.appid.xml – holds the encrypted Application ID of the Azure AD application for the tenant

Storing these details on a workstation is not the most secure option I agree, but it’s a starting point for what I’ll show you down track (read Azure Key Vault). However, because some people want the flexibility and simplicity of local files that’s where this starts.

If you examine one of these XML configuration files more closely, as shown above, you’ll see that the variable name (here AppSec) is stored in the Username field and the Password field has a long string of characters. You’ll notice that these characters actually don’t in anyway match the actual Appsec value that was captured earlier. That value was:

This means that the actual tenant variables save in the files are encrypted, so they can’t be easily recovered.

To get the unencrypted values back you’ll need to use the PowerShell import-clixml as shown above.

Well, you maybe thinking that it is easy enough to copy these configuration files to another PC and decrypt them there. Not so fast my sneaky friend, because the way these details are encrypted is that they are locked to just THAT machine and just THAT logged in user! As you can see from the above, if you try and decrypt these files with another user on that same PC or on another machine, you can’t.

All of this comes about because of the use of the export-climxl command to save the variables, which says:

The Export-Clixml cmdlet encrypts credential objects by using the Windows Data Protection API. The encryption ensures that only your user account on only that computer can decrypt the contents of the credential object. The exported CLIXML file can’t be used on a different computer or by a different user.

That’s why you needed to do that CTL+V paste command for each variable previously so that the variable could be saved as a credential object and take advantage of this encryption process.

This has now achieved STEP 1 in the process I spoke about initially to allow secure access to multiple tenant using the Microsoft Graph.

So what does the program actually do to each tenant behind the scenes? It is easy to see. Simply visit the Azure AD Directory location in the Azure portal for that tenant. If you then select the App registration from the menu on the left, and ensure you are viewing All Applications, you should see the application with the name you entered displayed on the right as shown above. Here, ciaops.

If you select the application name to get more details you’ll many of the variables saved to XML files as shown above.

If you then select API permissions on the left you will see that, as yet, no permissions have been given to this Azure AD Application (although they will be in an upcoming article).

However, we are not quite done yet as I have also created a program that will remove all of these Azure AD applications created quickly and easily. To do that download the program:

https://github.com/directorcia/Office365/blob/master/graph-adapp-del.exe

You need to place it into the directory where all the tenant configuration file are located as shown. Double click the program to run.

To remove that Azure AD application you’ll need to log back into every tenant interactively as shown above. You’ll see the same of the tenant that it wants credentials for in the program flow.

Once you have provided access to the tenant, the Azure AD application will be deleted along with the configuration files. You’ll then be take to the next tenant and asked to repeat the process.

Once there are no more configuration files found the program will end.

Remember, this program will delete every matching tenant it finds configuration files for in the current directory. If you only want to delete a subset of the total tenants you have configured, move the other configuration files out of the current directory until this process is complete.

In summary then, the programs that I have created and made available for free will create a ‘static’ Azure AD application in all the tenants you select. The idea in upcoming articles will be to show you how this ‘static’ embedded Azure AD application can now be used to report and potentially change the configuration of multiple tenants quickly and easily. I also provided a program to also remove all these Azure AD applications from tenants.

Next step will be to give the Azure AD applications appropriate permissions and then get some information from the tenants WITHOUT the need of manually logging into each.