Enabling search for Microsoft Teams chat with on-premise Exchange Server mailboxes

I recently had a client who a hybrid environment with mailboxes hosted on an on-premise Exchange 2019 server follow the Microsoft documentation:

Content Search
https://docs.microsoft.com/en-us/microsoft-365/compliance/content-search?view=o365-worldwide

… in an attempt to search content in a Teams Chat data but noticed that launching the Admin center then Security:

… then Search > Content Search:

… and attempting to search did not yield any results.

Administrators who have come across this issue in the past, may know that this is because Teams chat data for users are stored in their primary cloud-based mailbox, while users with on-premise mailboxes are not able to store Teams chat data in their non-cloud-based mailbox. The workaround solution for this issue is outlined in the following article where a request needs to be filled out and submitted to Microsoft Support to enable this:

Search for Teams chat data for on-premises users
https://docs.microsoft.com/en-us/microsoft-365/compliance/search-cloud-based-mailboxes-for-on-premises-users?view=o365-worldwide

The process typically takes a few weeks before the changes are active while Microsoft creates a cloud-based storage area so that it can be used with eDiscovery tools to search for and export Teams chat data for on-premises users.

Having gone through this process before, I proceeded to create a ticket, had the support engineer escalate the case, then eventually received a call back a week later from the escalation engineer and was told that Microsoft had turned this feature on globally as of January 13, 2021, most likely because there have been so many requests. I was told that it may take a couple of weeks before the changes propagate through all the tenants but my guess is that by the time anyone finds this blog post, it would have been activated for them.

If you’re attempting to search Teams Chat data for a user with an on-premise Exchange mailbox, ensure that you have granted your account the following roles:

Security > Permissions

Grant the administrator account the following permissions:

• Organization Management
• Compliance Administrator
• eDiscovery Manager < if export is required (https://docs.microsoft.com/en-us/microsoft-365/compliance/assign-ediscovery-permissions?view=o365-worldwide)

Content search should return results once the above permissions are granted.

The following is an article outlining the keyword queries and search conditions that can be used for the search:

Keyword queries and search conditions for Content Search and eDiscovery
https://docs.microsoft.com/en-us/microsoft-365/compliance/keyword-queries-and-search-conditions?view=o365-worldwide

The following is the documentation for Content Search:

Content Search
https://docs.microsoft.com/en-us/microsoft-365/compliance/content-search?view=o365-worldwide

Quick Overview of a Simple Deployment of WVD (Windows Virtual Desktop) on Microsoft Azure

This post is long overdue as I took the screenshots last summer in 2020 but never got around writing this post. As I just had to complete another WVD deployment this weekend, I took the time to validate that these notes are still valid so this post serves to demonstrate how to quickly deploy a simple WVD (Windows Virtual Desktop) pool for access:

Step #1 – Registering and Preparing Azure AD Tenant for WVD

If your tenant does not have WVD deployed, navigating to the Enterprise applications will not have any Windows Virtual Desktop applications registered:

Begin by obtaining the Tenant ID unique identifier by navigating to Azure Active Directory > Properties and copying the string under Tenant ID:

Then copy the subscription ID by navigating into Subscriptions and copying the Subscription ID:

Navigate to the URL https://rdweb.wvd.microsoft.com/, select Server App for Consent Option, paste in the tenant ID copied from the Azure portal and then click on Submit:

Log in with a Global Admin account for the tenant:

You will be asked to grant permissions to the organization:

You should receive a AAD Application has been successfully registered message:

Note that Windows Virtual Desktop AME is now present in the Enterprise applications:

Repeat the same procedure at https://rdweb.wvd.microsoft.com/ but select Client App for Consent Option, paste in the tenant ID copied from the Azure portal and then click on Submit:

Another prompt to grant permissions to the organization will be displayed:

You should receive a AAD Application has been successfully registered message:

An additional Windows Virtual Desktop Client will now be displayed in addition to Windows Virtual Desktop AME:

Confirm that the Microsoft.DesktopVirtualization provider is now listed as being Registered in Subscriptions > YourSubscription > Resource Providers:

Step #2 – Creating a new WVD Tenant

Proceed to create a new WVD tenant by launching PowerShell installation the following 2 modules:

1. Az
2. Microsoft.RDInfra.RDPowerShell

Then run the cmdlets providing the tenant ID and subscription ID copied earlier:

Import-Module -Name Az

Import-Module -Name Microsoft.RDInfra.RDPowerShell

$brokerurl = "https://rdbroker.wvd.microsoft.com"

$aadTenantId = "the tenant ID used in the previous steps"

$azureSubscriptionId = "the subscription for this deployment"

With the modules imported and variables defined, use the Add-RdsAccount cmdlet to add an authenticated account to use for Windows Virtual Desktop cmdlet requests. Upon completion, the context is automatically set to use the Default Tenant Group as the tenant group name. Execute the cmdlet with the variable:

Add-RdsAccount -DeploymentUrl $brokerurl

Then sign in with the account that will be used for the RDS Account:

The following output will be displayed upon completion:

The cmdlet above should place the authenticated account in Azure Active Directory > Enterprise applications > All applications > Windows Virtual Desktop Client > Users and groups but the Role assigned is Default Access:

Proceed to add the account to the grant the account permissions to the Windows Virtual Desktop AME Enterprise applications by navigating to Azure Active Directory > Enterprise applications > Windows Virtual Desktop AME:

Navigate to Users and Groups and then Add user/group:

Select the account and click on Assign:

The account should now be listed as a Tenant Creator:

Execute the following cmdlet to create a new WVD tenant:

New-RdsTenant -Name "WVDTenantNameOfYourChoice" -AadTenantId $aadTenantId -AzureSubscriptionId $azureSubscriptionId

**Note that it could take a bit of time before the permissions configured in the previous steps to take effect so if the cmdlet errors out then wait 5 to 10 minutes before trying again.

Proceed to add the Azure AD Global Admin and on-premise Active Directory Domain Admin accounts to the WVD RDS Owners Group with the following cmdlets:

New-RdsRoleAssignment -SignInName "username@AADdomain.onmicrosoft.com" -RoleDefinitionName "RDS Contributor" -TenantName "TenantNameFromAbove" -AadTenantId $aadTenantId

New-RdsRoleAssignment -SignInName "domainAdmin@domain.com" -RoleDefinitionName "RDS Contributor" -TenantName "TenantNameFromAbove" -AadTenantId $aadTenantId

For the purpose of this example, I will add my on-premise Active Directory account which is both a Global Admin and Domain Admin and a cloud account that is a Global Admin:

Step #3 – Create Windows Virtual Desktop and Remote Application Host Group

With the Azure AD Tenant configured, we can now proceed to create the host groups, which will host our virtual desktops and applications. This can be accomplished either via Azure portal (ensure that you are logged in with the account you used to create the tenant when the cmdlet Add-RdsAccount -DeploymentUrl $brokerurl was executed) or PowerShell. To create it in the Azure portal, simply navigate to Windows Virtual Desktop > Host pools > New to create a virtual desktop pool:

Or use the PowerShell cmdlet New-RdsHostPool (https://docs.microsoft.com/en-us/powershell/module/windowsvirtualdesktop/new-rdshostpool) to create the pool.

New-RdsHostPool -TenantName "Contoso WVD" -name "WVD-CONTOSO-VDI"

New-RdsHostPool -TenantName "Contoso WVD" -name "WVD-CONTOSO-VDI-APP"

As there are numerous parameters that need to be configured, I would suggest using the GUI if this is your first time creating a WVD deployment:

**Note that I will be creating a pool of desktops that are not statically assigned to a user

Fill in the required configuration changes for the environment:

We’ll register the desktop app group later:

Proceed with the deployment of the host pool:

When the deployment is complete. Clicking into the host pool will display the 2 virtual desktops created:

An Application Group will also be automatically created:

To grant users permissions to the WVD virtual desktops, navigate to Users, search for the user and either use the Individual assignments or Group assignments to grant permissions:

Proceed to create a Workspace by navigating to Workspaces > New:

Provide the configuration for the Workspace and then proceed to Application groups:

Add the Application Group containing the Host pool that was created:

With the above steps completed, you should now be able to access the published virtual desktop either via:

1. The Windows Virtual Desktop with the web client: https://rdweb.wvd.microsoft.com/arm/webclient (short URL: https://aka.ms/wvdarmweb)
2. The Windows Desktop client: https://docs.microsoft.com/en-us/azure/virtual-desktop/connect-windows-7-10#install-the-windows-desktop-client

Note that depending on the date documentation you find for the Windows Virtual Desktop with the web client, you may find the following non-arm URL that will not present the resource configured above: http://aka.ms/wvdweb (https://rdweb.wvd.microsoft.com/webclient/index.html)

The following is a screenshot of how the web client looks like:

The following is a screenshot of the Windows client:

The following is a screenshot of multiple sessions established on a Windows 10 desktop:

I will write another blog post demonstrating how to create a custom virtual desktop image with LOB (Line of Business) apps and other OS customizations in the future.

Attempting to access Windows Virtual Desktop (WVD) displays the message: “It looks like your system administrator hasn’t set up any resources username@contoso.com yet. Please choose a different account or try again. If you believe you have received this message in error, please contact your system administrator.”

One of the most common problems I find many of my clients and colleagues experience during there first deployment of WVD is that upon completing the configuration of the host pool, application group, and assignment of users, they receive the following message from the both the web client and the Windows desktop client:

It looks like your system administrator hasn’t set up any resources for username@contoso.com yet. Please choose a different account or try again. If you believe you have received this message in error, please contact your system administrator.

Many of the forum posts tend to point the user to ensure they are not using the older non-arm URL for arm deployments:

• https://rdweb.wvd.microsoft.com/arm/webclient (short URL: https://aka.ms/wvdarmweb)
• https://rdweb.wvd.microsoft.com/webclient/index.html (short URL: http://aka.ms/wvdweb)

However, what I’ve found to be the frequent cause is if the administrator either has not created a Workspace or added the Application Group into the Workspace:

Hope this helps anyone who might have missed this step.