Remote Desktop app for WVD doesn’t work with WIP

*** Solution – ensure the WVD feed URL (e.g. http://rdweb.wvd.microsoft.com/webclient) is part of the appropriate definitions in your WIP network isolation configuration

When I tried to update the feeds on my Remote Desktop client on Windows 10 for use with the Spring release of WVD I was greeted with the above issue with Windows Information Protection. (WIP). I tried setting the Remote Desktop app (msrdcw.exe) to be a protected app in WIP and still had the same issue. Also tried setting to be an exempt app, but that also didn’t help-. Only disabling WIP seemed to allow me to refresh the feeds. Once you do this you can turn WIP back on if you need to.

Hopefully Microsoft will address this issue in upcoming releases of he Remote Desktop app for Windows 10. Until then, there doesn’t seem to be much option but disabling WIP.

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.

CIAOPS Need to Know Microsoft 365 Webinar–May

laptop-eyes-technology-computer

With all this work from home going on it is a good time to focus on security in Microsoft 365. Attend to learn how you can make your environment more secure and minimise your risks. I’ll have the the latest Microsoft Cloud updates plus open Q and A as well.

You can register for the regular monthly webinar here:

May Webinar Registrations

The details are:

CIAOPS Need to Know Webinar – May 2020
Friday 29th of May 2020
10.30am – 11.30am Sydney Time

All sessions are recorded and posted to the CIAOPS Academy.

The CIAOPS Need to Know Webinars are free to attend but if you want to receive the recording of the session you need to sign up as a CIAOPS patron which you can do here:

http://www.ciaopspatron.com

or purchase them individually at:

http://www.ciaopsacademy.com/

Also feel free at any stage to email me directly via director@ciaops.com with your webinar topic suggestions.

I’d also appreciate you sharing information about this webinar with anyone you feel may benefit from the session and I look forward to seeing you there.

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.

Adding Microsoft To Do as a recommended app with Windows Information Protection

I’m a big fan of Microsoft To-Do but recently noticed that I was having trouble syncing data from my Windows 10 desktop to my other devices. Everything looked fine on my desktop but the next troubleshooting step I took revealed my problem as you can see below.

A Windows Information Protection (WIP) policy is preventing the use of Microsoft To Do on this device.

Ah ha, I had indeed recently changed my Windows Information Protection (WIP) policy for the desktop. This change had inadvertently stopped Microsoft To Do syncing as well as preventing me from logging in.

To solve the problem you need to add the Microsoft To Do app to the list of Protected apps in the Intune App Protection policy for the device, which by default, isn’t there.

Navigate to the Intune App Protection policy in question and view the properties as shown above. On the right hand side, select the Edit link next to Targeted apps as shown.

You should then see the Targeted apps as shown above.

Scroll to the bottom of the list of Protected Apps and select the +Add link at the bottom as shown.

This process is similar to one I documented a while back for Adobe Acrobat:

Adding Acrobat as an allowed app

The difference this time is that Microsoft To Do is a store app.

To identify the app you need to search for the store app on the Microsoft Store as shown above. When you locate the app and view the URL you will see a unique identifier as shown. In this case, for Microsoft To Do, it is 9NBLGGH5R558.

You’ll then need to visit this URL:

https://bspmts.mp.microsoft.com/v1/public/catalog/Retail/Products/9NBLGGH5R558/applockerdata

Doing so will spit out the information you need to add the app as a protected app to your policy. To view the result for other store apps just insert the appropriate identifier into the URL instead of the one for Microsoft To Do shown here.

Thus, for Microsoft To Do you’ll need:

“packageIdentityName”: “Microsoft.Todos”

“publisherCertificateName”: “CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US”

Back on the Add apps page opened earlier, change the pull down at the top of the page to be Store apps. Then enter the information for Name, Publisher and product name as:

Name = Microsoft To Do

Publisher = CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US

Product name = Microsoft.Todos

Select OK at the bottom of the dialog to save the changes. Then select Review+Save to update the policy.

You can either wait for the policy to be pushed down or force a sync from the device sync settings in the user account information for the Windows device. Once the policy has been updated to the machine you’ll be able to open and use Microsoft To Do or any store app you have configured. Doing so fixed my Microsoft To Do issue by allowing me to login to the app again on the desktop and sync information.

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.