Manufacturing, Healthcare and Retail Voice with Teams Phone

In today's business environment, seamless communication is more important than ever, especially in sectors like manufacturing and retail, where quick, clear coordination can significantly impact operations. While DECT technology continues to evolve as a valuable communications platform, many organizations are looking for modern solutions that offer more flexibility and integration. Microsoft Teams Voice has become a comprehensive platform that provides everything you need, including dial-by-name functionality for simplified communication.

However, extension-based dialing remains crucial for certain use cases, especially in fast-paced environments where speed and simplicity are key. Whether it's contacting a production manager in manufacturing or reaching a sales team member on the retail floor, or a trauma nurse in the ICU, the ability to quickly dial an extension can save time and reduce confusion.

Enter Teams Shared Calling—a game-changing integration that not only simplifies IT management but also reduces costs by streamlining how organizations connect to PSTN services. By combining these three elements—DECT (through Teams SIP Gateway), Teams extension dialing, and a recent Microsoft product update enabling extension dialing through Shared Calling —businesses can build a communication system that meets both traditional and modern needs.

In this post,  my peers Pratik, Matt and I will help explore how to leverage all three technologies to create a streamlined communication platform, with a focus on practical use cases in manufacturing, healthcare and retail.

I need to thank our partner ecosystem for making this example implementation possible.

• Jacob Lauritsen, Pumi Powar, and Craig Barrass - Spectralink DECT and Teams Phone solutions
• Rick Garcia, Mark Vale, and Jeffery Head - Momentum Teams solutions for Operator Connect integration supporting Fax and SMS solutions in Teams
• Gary Wood, and Diana Florea, Andrew Steinke - PureIP for seamless integration of Operator Connect and hosted direct routing for global PSTN services.

Extension dialing is not a new concept in Teams calling, yet is still controversial. In Teams, and other UCaaS solutions, users and numbers are tied to identities for security and license capabilities and the concept of dial-by-name is widely encouraged. Where there is ongoing development and extension dialing may still be useful is shared device scenarios, specifically where SIP endpoints are used, and directory search isn't always available. 

Here we will review setup and options.

          
PBX to Shared Calling SIP device       Teams SIP to SIP Device

Components used in our recipe

• Teams users - enabled with Phone System and Operator Connect
• Teams features - dial plan normalization rules, shared calling policies (and PLAR/Ringdown when faster access is needed)
• Spectralink DECT solutions - IP-DECT Server 400, IP DECT Base Station, S33 and S37 DECT handset
• Shared Calling DID's from Operator Connect carrier partners
• Teams Native Phones - Poly/HP CCX500 for PLAR/ringdown

Scenarios

• Scenario - Nursing station needs to reach any nurse working in wing
• Scenario - Plant production manager needs to reach any worker in production group 2 
• Scenario - Retail manager needs to reach anyone working in cashier role

Connectivity Configuration

• Enable shared calling following this guidance - https://learn.microsoft.com/en-us/microsoftteams/shared-calling-setup
• In this scenario we will use 2 groups of users - 2 shared calling policies
• Configure 2 resource accounts with Operator Connect numbers, one for each shared calling group.
• In a practical application each group may be defined by emergency location or floor of a building.

We will also want to create a caller ID policy for the users to leverage the DID from each shared calling group (policy) - note the setting below - Replace the caller ID with Resource account.

Users and Shared Devices

• Assign licenses to users (Teams Phone System) and shared devices (Shared Device License)
• Assign policies
• Assign user phone numbers extensions using direct routing type - here is where recent feature and documentation updates come into play - https://learn.microsoft.com/en-us/microsoftteams/shared-calling-setup#step-10-configure-extension-dialing-support-for-shared-calling-enabled-users-optional
• Map extension ranges to shared calling policies (main resource account DID and emergency location)
• In this example setup shared calling user group 1
• Operator Connect DID - Assigned in shared calling policy to resource account 1
• User assigned same phone number as shared calling resource account 1 (type is direct routing)
• Extension Range - 4000 assigned to users with policy 1
• Shared calling user group 2
• Operator Connect DID - Assigned in shared calling policy
• User assigned same phone number as shared calling resource account 2 (type is direct routing)
• Extension Range - 5000 assigned to users with policy 2

Note - we use number type direct routing on the user assignment (allowing for the DID from the shared calling resource account and extension assignment).

At this point we have to set up some additional policies for dial plan and normalization rules and then we can assign all the needed policies for each user.

Extension Dialing

In this example setup - we are not using the last 4 digits of each DID since our users don't have a DID in shared calling. Increasingly sequential DID blocks are becoming harder to obtain and maintain - and often you may find yourself with overlapping (or duplicate) extension numbers based on last 4 digits of DID - so in this case we mapped extension range 4000 to shared calling group 1 and extension range 5000 to shared calling group 2.

• Create a Dial Plan and Normalization Rules

• Here we apply the shared calling resource account DID number to the translation (in the "Then do this" section), with the ext=$1
• Assign dial plan policies to users

Scalability - optional on-prem integration - the same extension dial plans can be applied in the SBC or on-prem PBX as needed. 

Outcome

• All users and shared devices can place outbound calls
• Inbound calls from PSTN can be routed to users through auto attendant and dial by name or dial by extension
• Users can quickly call each other - between devices with extension dialing or dial-by-name in the Teams client, web, mobile app or native phones.

Spectralink Tools

Spectralink provides unique features adding additional value to Teams Phone.

• Ringtone choices, loud ringing and visual alerts
• Messaging
• Admin Profiles/Speed Dial phonebook management
• Range Extension
• Personal Safety Alerts and lighting assistance

Additional Value - Shared calling users receive inbound calls through the optional auto attendant configures and assigned to the Resource Account. PLAR/Ringdown phones can be configured to automatically dial the Auto Attendant for the shared calling users - allowing gloved worker to speak the name or the extension of the shared device users or speed dials can also be used for quick access to users and devices.

Keep your eye on M365 Roadmap and Message Center - admin managed speed dial contacts, and remote contact management.

Thanks for reading and hope this insight was helpful.

Cheers.

Getting Started with Teams Queues App: Features, Voice Application Policy Settings, and Roles

Welcome to the world of Microsoft Teams Queues App! This powerful tool is designed to streamline your team's communication and enhance productivity. In this post, we'll explore the key features of the Teams Queues App, including its intuitive interface and robust functionality. We'll also dive into the Voice Application policy settings and controls, which allow you to manage call routing and user permissions effectively. Additionally, we'll highlight the differences between a Teams Admin Role and the authorized user setting, ensuring you have a clear understanding of the distinct responsibilities and capabilities each role entails. Whether you're an admin or an authorized user, this guide will help you get familiar with the Teams Queues App and get started on the right foot.

Key features provided with Queues App 

Collaborative Calling: Teams working together to service customers can benefit from a shared call queue in a Teams Channel. This feature allows team members to manage calls collectively, ensuring that no customer call goes unanswered

Enhanced user interface: The Teams Queues App offers an intuitive and streamlined user interface, allowing team members to manage customer calls efficiently and enabling team leads to configure call queues and auto attendants directly from the Teams client, enhancing overall productivity and user experience

Real-Time Metrics and Historical Reporting: The app offers real-time metrics such as the number of waiting calls, average wait time, and longest call waiting time. Additionally, it provides historical metrics for call queues and auto attendants, helping teams analyze performance and make data-driven decisions

Enhanced Customer Engagement: By integrating with other Microsoft Teams features, the Queues App allows agents to quickly access subject matter experts within the organization. This immediate access to resources enables agents to resolve customer inquiries more efficiently, leading to improved customer experiences.

Seamless Integration: The app integrates seamlessly with Microsoft Teams, eliminating the need for agents to switch between multiple applications. This integration fosters real-time communication via chat, calls, and video meetings, enhancing collaboration and productivity

These features collectively help teams manage customer engagements more efficiently, streamline workflows, and ultimately enhance overall productivity.

Getting started with the Teams Queues App, there are several prerequisites you need to meet:

• Licensing: Users must have both a Teams Phone and a Teams Premium license. Once a user is licensed for Teams Premium, it can take up to 48 hours for the Queues App to be available in the Teams client. Queue agents can be a member of the queue without the Teams Premium license, but will not have access to the Queues App experience in Teams.
• Teams Preview Policy - at the time of this post, the Queues App is in Public Preview - review your tenant and user preview settings - Public preview in Microsoft Teams - Microsoft Teams | Microsoft Learn
• Resource Accounts: You need a Resource Account for each Call queue and Auto attendant. These accounts must have a Microsoft Teams Phone Resource Account license
• Admin Permissions: During deployment, a Teams Administrator account  is required to set up Voice Application policies, and authorized users of designated auto attendants and call queues.
• Teams Client: The Queues App is currently supported on Teams desktop and Mac clients, but not on web, mobile, or Virtualized Desktop Infrastructure (VDI) clients
• PowerShell Modules: As with many features and administrative controls, the queues app can be managed in Teams Admin Center or the updates Teams PowerShell module can be used.

Let's break down the differences between the Teams Admin Role and the Authorized User Policy settings for the Queues App and Voice Application Policies.

Teams Admin Role

Teams Admins have comprehensive control over the Teams environment, including the Queues App and Voice Application Policies. Their responsibilities include:

• Creating and Managing Policies: Admins can create, edit, and assign custom Voice Application Policies. These policies control what configuration changes authorized users can make to auto attendants and call queues.
• Full Access to Settings: Admins have full access to all settings related to call queues and auto attendants, including hours of operation, call routing, queue membership, and pre-recorded greetings.
• Delegation of Permissions: Admins can delegate certain permissions to authorized users, allowing them to manage specific aspects of call queues and auto attendants without needing full admin rights.
• Global Policy Management: Admins manage the global, org-wide default policy, which disables all configuration change capabilities for all users unless custom policies are created and assigned.

Authorized User Policy Settings

Authorized Users are designated by Teams Admins to manage specific aspects of call queues and auto attendants. Their capabilities include:

• Limited Configuration Changes: Authorized users can make configuration changes to the auto attendants and call queues they are authorized for. This includes managing business hours, call routing, and viewing real-time and historical metrics.
• No Admin Center Access: Authorized users do not need access to the Teams Admin Center portal nor do they need to be assigned any administrative roles.
• Access Through Teams Client: Authorized users can access and manage their assigned call queues and auto attendants directly through the Teams desktop client or the Queues App.
• Policy Assignment: Authorized users must be assigned a custom Voice Application Policy created by an admin. This policy provides the minimum levels of permissions needed for their role.

Key Differences

• Scope of Control: Teams Admins have full control over all settings and policies, while Authorized Users have limited control based on the permissions assigned to them.
• Access Level: Teams Admins access and manage settings through the Teams Admin Center, whereas Authorized Users manage their assigned settings through the Teams client or Queues App.
• Policy Creation and Assignment: Only Teams Admins can create and assign custom Voice Application Policies. Authorized Users can only operate within the confines of the policies assigned to them.

These distinctions ensure that while Teams Admins maintain overall control and security, Authorized Users can efficiently manage specific aspects of call queues and auto attendants, enhancing productivity and delegation within the organization.

Implementation Planning

We've covered the features and value within the Queues App. In getting started, there are a few recommended planning steps. 

• Assignment of the Teams Premium license - Teams Premium is required to access the queues application, while all queue agents may not require the Queues App interface, assign the Teams Premium add-on (not included in E5).
• App Setup Policy - define which users will see the Queues App and the pinned position of the Queues App (or user pinning allowed)
• Voice Application Policy - define the controls needed for each role or persona
• Authorized users - define non-administrative users who can interact, control and report within each auto attendant or call queue

Premium License Assignment

Teams App Setup Policy

Voice Application Policy

This section offers flexibility and should be planned accordingly. You may consider getting started with 3 policy settings based on persona's. 

• Manager/Supervisor
• Agent
• Reporting Only (no control or interaction with the call flow, visibility of statistics and reporting)

You may also consider additional policies here, and options to separate Auto Attendant functions from Call Queue functions. Often Call Queues are preceded in the call flow by Auto Attendants (nesting) therefor control of both functions may be needed.

Take note - the historical reporting options allow for control over ALL Queues in the tenant or only when authorized users are defined.

Auto attendant and Call queue historical reports - Microsoft Teams | Microsoft Learn

The Queues App interface provides access to real-time and historical reporting, keep in mind these settings also control access to historical reporting in Power BI

I covered this earlier this year in a blog post - Auto Attendant and Call Queue Historical Reporting in Power BI

Assign the policies to users

and

Define Authorized Users

Within each Auto Attendant and Call Queue - define the authorized users who do not have a Teams Administrative role.

As with any cloud solution - it may take time for licenses and policies to propagate down to users so please be patient.

Queues App in Action

Once settings and policies have synchronized the Queues App will be visible (if pinned) on the side bar. Take note of the Auto Attendants and Call Queues across the top and the historical reports available in the upper right corner through Analytics.

Important - Understanding the Queues App and Auto Attendant / Call Queue Settings

While the Queues App provides an enhanced interface for calling, follow-up, agent presence, and call statistics - control over greeting messages, agent selection, and call routing is accessed through the Teams Client settings (for authorized users)

Navigate to Settings -> Calls for administrative controls over each attendant and queue

Note - the small purple icon will identify an Auto Attendant or Call Queue.

Update - the Queues App is now Generally Available as of October 2024.

This guide provides a solid foundation for getting started with the Queues App in Teams. While there are numerous comprehensive contact center integrations available for organizations requiring full-featured experiences or CRM integration, the Queues App combined with Teams Premium offers a valuable solution that bridges the gap between basic queue needs and a fully-featured contact center.

Stay tuned - in the next chapter we will cover specific personas and real-world use of the Queues App.

Teams Admin Units for device management

As organizations grow, managing roles and devices efficiently becomes critical. Microsoft Entra ID’s administrative units allow for precise role assignment and scope, ensuring admins access only the necessary resources. The recent enhancement in Microsoft Teams enables device management within administrative units, allowing admins to control devices in specific regions or departments. For instance, an IT admin can now manage devices only in their assigned locations, without viewing or affecting others globally. This powerful combination strengthens security with principle of  least privilege (PoLP) and simplifies device management with improved organizational efficiency. This is the first addition with ongoing development of administrative units in Teams Administration.

In the first quarter of 2024, Microsoft launched a new administrative role to assist managing Telecom features in Teams. 

Earlier this month, the next step in administrative support followed with the announcement of administrative units for device admins.

Reference Links:

Use Microsoft Teams administrator roles to manage Teams - Microsoft Teams | Microsoft Learn

Assign or list Microsoft Entra roles with administrative unit scope - Microsoft Entra ID | Microsoft Learn

Manage devices with administrative units - Microsoft Teams | Microsoft Learn

Microsoft Teams: Administrative Units for Teams Administration

We are excited to announce the availability of administrative units (AUs) for Teams administration. AUs are a way to delegate admin roles and delegate administration to a subset of users in your organization, based on attributes such as department, location, or business unit. With AUs, you can create more granular and flexible management scenarios for your Teams environment. You can assign the following roles, allowing them to manage only the users, groups & devices within their AU: Teams Administrator Teams Device Administrator Teams Communication Administrator Teams Communication Support Engineer Teams Communication Support Specialist Teams Telephony Administrator

• Feature ID: 402186
• Added to roadmap: 6/26/2024
• Last modified: 8/6/2024
• Product(s): Microsoft Teams
• Cloud instance(s): Worldwide (Standard Multi-Tenant)
• Platform(s): Desktop, iOS, Android, Mac
• Release phase(s): General Availability

Lets take a closer look:

Global admins can create administrative units to segregate Teams Device management across the enterprise. Following the documentation links above, starting in EntraID, to create an admin unit.

With no user devices assigned to the scope of the Admin Unit - while Lee (our device admin) can access the Teams Admin Center, and view the device menus, yet no devices are visible. This is where I needed to do some investigation ... do we add the user account who access the device or just the EntraID device itself. The documentation wasn't explicitly clear here so I hope this post helps.

Manage users or devices for an administrative unit with rules for dynamic membership groups (Preview) - Microsoft Entra ID | Microsoft Learn

Once I added the devices user account to membership - the scoped admin unit rules took place and we are able to see the devices just for that admin unit - as shown below for Lee.

and an MTR just to be thorough.

For reference - Adele is a Device Admin with non-scoped permanent role assignment and able to see the entire estate of devices.

Hope this post helps get you started with Admin Units for Teams device administration.

Call Records Insights Update 2 - Export UPN from Entra ID and update Call Records

In the previous chapter of CRI, I discussed an option for inserting user UPNs into the 'Call Record Insights' query results. To further simplify the work of administrators, this post will explore how to automate the integration of user and UPN data from Entra ID. We'll cover how to automate the replacement of this table on a scheduled basis using Azure Automation (Runbooks) or PowerShell.

Recap

The previous posts on Teams Call Record Insights covered getting started and query updates to include additional data. Below are links to those chapters.

• Introduction to CRI - Getting Started
• Update CRI with user UPN
• Rotate and update user UPN table (this post)

In the last session we reviewed how to create and populate user UPN's in the CRI database, and then use Kusto Query join to return the UPN in the call records query.

The real takeaway from the last chapter—and this post—isn't just about adding UPNs to call records; it's about empowering your organization with complete ownership, management, and flexibility of your records database. Once implemented, this data is yours to control, allowing you to retain, modify, and adapt it as your needs evolve.

Previously, we created the user_UPN table through the ADX web interface, setting up a new table and importing users, GUIDs, and UPNs using the data import tool in ADX.

But what if you need to ensure this user UPN table stays up-to-date daily, reflecting changes as users are added or removed from your tenant

Automation of table data

Given my familiarity with PowerShell and runbooks, and the added support from GitHub Copilot, this demonstration will focus on automating the process using PowerShell and Azure Automation (Runbooks). While this could also be achieved with C# or Python (I initially experimented with Python but ultimately chose PowerShell for the final solution), PowerShell’s robust capabilities made it the ideal choice for this task.

The Process

First, we'll connect to Entra ID and export the upn, display name, and GUID into a CSV file. Then, we'll rename the existing user_UPN table to keep a backup without including it in future queries. After that, we'll create a new, blank user_UPN table and import the CSV data from Entra ID to populate it with updated user information. From the previos session, I chose to export and populate upn, GUID, and display name but only upn and one of the other fields are required to match and join from the CRI table. Additionally, I've incorporated some error checking and output presentation for validation, which is helpful during setup but not necessary for the final runbook

Step 1 - connect and export user data

# Define the CSV path with a date stamp

$dateStamp = Get-Date -Format "yyyyMMdd"

$csvPath = "[your directory path]\userExport_$dateStamp.csv"

# Ensure you're connected to Azure

Connect-AzAccount -Tenant "[your tenant ID]"

# Fetch user information

$users = Get-AzADUser | Select-Object DisplayName, Id, UserPrincipalName

# Export to CSV

$userCount = $users.Count

Write-Host -ForegroundColor Blue "Number of users: $userCount"

$users | Export-Csv -Path $csvPath -NoTypeInformation

# Display in a table if needed

$users | Format-Table -AutoSize

# Prompt the user to proceed to update the Kusto database

$proceed = Read-Host "CSV file generated at $csvPath. Do you want to proceed with updates to CRI Kusto Database (yes/no)"

if ($proceed -ne "yes") {

    Write-Host "Operation aborted by the user."

    exit

}

Note - with runbook the Write-Host and Prompt to proceed should be omitted.

Step 2 - Import modules, libraries and set variables (Kusto libraries can be downloaded and locally referenced)

Reference THIS LINK for details on Kusto in PowerShell.

# Define the tenant ID, client ID, and client secret of the service principal

$tenantId = "[your tenant ID]"

$clientId = "[your client ID"

$clientSecret = "[your client secret]"

$authority = "[your tenant domain name]" 

# Define the path to the Kusto client libraries

$kustoLibPath = "[your library path]\net6.0\"

# Load the Kusto client libraries in the correct order

Add-Type -Path "$kustoLibPath\Microsoft.Identity.Client.dll"

Add-Type -Path "$kustoLibPath\Kusto.Data.dll"

Note - ClientID, ClientSecret and Authority are needed when not using a user login, or when running script as runbook where service principle is required. This section of the documentation explains the variables needed with User, Application or Azure CLI interaction with Kusto in PowerShell.

Step 3 - Create Kusto query with Kusto Custom String Builder and Client Request Properties

# Define Kusto connection string variables

$clusterUrl = "[your Azure Data Explorer cluster url]"

$databaseName = "CallRecordInsights"

# Create the Kusto connection string with the OAuth token if using service principal

$kcsb = [Kusto.Data.KustoConnectionStringBuilder]::new($clusterUrl, $databaseName)

$kcsb = $kcsb.WithAadApplicationKeyAuthentication($clientId, $clientSecret, $authority)

# Define client request properties

$crp = [Kusto.Data.Common.ClientRequestProperties]::new()

$crp.ClientRequestId = "UserUPNpsh.ExecuteQuery." + [Guid]::NewGuid().ToString()

$crp.SetOption([Kusto.Data.Common.ClientRequestProperties]::OptionServerTimeout, [TimeSpan]::FromSeconds(30))

Step 4a (run as user) or 4b (run as application)

Here is an example of a query to test connecting and querying the manually created  user_UPN table and displaying the output to screen. (this would not be needed or valuable in a runbook)

# Query and present the existing table to test

$queryProvider = [Kusto.Data.Net.Client.KustoClientFactory]::CreateCslQueryProvider($kcsb)

$query = "user_upn | take 10"

Write-Host "Executing query: '$query' to test access to Kusto with connection string: '$($kcsb.ToString())'"

$reader = $queryProvider.ExecuteQuery($query, $crp)

$dataTable = [Kusto.Cloud.Platform.Data.ExtendedDataReader]::ToDataSet($reader).Tables[0]

$dataView = New-Object System.Data.DataView($dataTable)

$dataView | Sort DisplayName | Format-Table -AutoSize 

Here is the steps to rename the existing table and create a new table, ingesting the previously created CSV file, and ignoring the top header row (we don't want to ingest the column headers as data in the Cosmos DB table). Also note: Write-Host and Proceed lines should be omitted in a runbook.

# Rename the existing user_upn table to user_upn_old to preserve the table

$renameQuery = ".rename table user_upn to user_upn_old"

Write-Host -ForegroundColor Blue "Executing rename query: '$renameQuery'"

# Execute the rename query

try {

    $queryProvider.ExecuteControlCommand($renameQuery, $crp)

    Write-Host "Table renamed successfully."

} catch {

    Write-Host "Error renaming table: $_"

}

# Prompt the user to proceed to update the Kusto database

$proceed = Read-Host "User_upn renamed. Do you want to proceed with updates to CRI Kusto Database (yes/no)"

if ($proceed -ne "yes") {

    Write-Host "Operation aborted by the user."

    exit

}

# Define the create table query to recreate user_upn table with new upn data

$createTableQuery = @"

.create table user_upn (

    DisplayName: string,

    Id: guid,

    UserPrincipalName: string

)

"@

Write-Host -ForegroundColor Blue "Executing create new table: '$createTableQuery'"

# Execute the create table query

try {

    $queryProvider.ExecuteControlCommand($createTableQuery, $crp)

    Write-Host "New table created successfully."

} catch {

    Write-Host "Error creating new table: $_"

}

# Ingest data into the new table

$rowCount = (Import-Csv -Path $csvPath | Measure-Object).Count

Write-Host -ForegroundColor Blue "Executing table data ingest with $rowCount records:"

# Construct the ingestion query to ingest the CSV file into the table, and remove the column headers from the table data

$csvContent = Get-Content -Path $csvPath -Raw

$csvLines = $csvContent -split "`n"

$csvLinesWithoutHeader = $csvLines | Select-Object -Skip 1

$csvContentWithoutHeader = $csvLinesWithoutHeader -join "`n"

$tableName = "user_upn"

$ingestQuery = @"

.ingest inline into table $tableName <|

$csvContentWithoutHeader

"@

# Execute the ingestion query

try {

    $queryProvider.ExecuteControlCommand($ingestQuery, $crp)

    Write-Host "CSV file ingested successfully into the table $tableName."

} catch {

    Write-Error "Failed to ingest CSV file: $_"

}

Write-host -ForegroundColor Green "User UPN data updated successfully. Please check Kusto database for the updated data."

Azure Automation

Create Automation Account

Assign Roles and Perms for Automation Account

1. Enable Managed Identity for the Azure Automation Account:

   • Navigate to your Azure Automation account in the Azure portal.
   • Under "Account Settings", select "Identity".
   • Enable the System-Assigned Managed Identity or add a User-Assigned Managed Identity.

2. Assign Azure Roles:

   • Go to the "Access control (IAM)" section of your subscription.
   • Add a role assignment for the managed identity with the Contributor role at the subscription level. This ensures it has the necessary permissions to manage resources within the subscription.
   • Additionally, assign the Reader role on the Azure AD to the managed identity. This allows it to read user information.

3. Grant Azure AD Permissions:

   • Navigate to the Azure AD section in the Azure portal.
   • Go to "App registrations" and find the managed identity.
   • Under "API permissions", add the Directory.Read.All permission.
   • Grant admin consent for the permission.

or run script to assign permissions

# Install the Microsoft Graph PowerShell module if not already installed
Install-Module Microsoft.Graph -Scope CurrentUser

# Connect to Microsoft Graph
Connect-MgGraph -Scopes "Application.ReadWrite.All", "AppRoleAssignment.ReadWrite.All", "Directory.Read.All"

# Find the managed identity
$DisplayNameOfMSI = "<Your-Managed-Identity-Name>"
$MSI = Get-MgServicePrincipal -Filter "displayName eq '$DisplayNameOfMSI'"

# Find the Microsoft Graph service principal
$GraphAppId = "00000003-0000-0000-c000-000000000000"
$GraphServicePrincipal = Get-MgServicePrincipal -Filter "appId eq '$GraphAppId'"

# Find the app role for Directory.Read.All
$PermissionName = "Directory.Read.All"
$AppRole = $GraphServicePrincipal.AppRoles | Where-Object {$_.Value -eq $PermissionName -and $_.AllowedMemberTypes -contains "Application"}

# Assign the app role to the managed identity
New-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $MSI.Id -PrincipalId $MSI.Id -ResourceId $GraphServicePrincipal.Id -AppRoleId $AppRole.Id

Lets build the automation account

Runbooks can be environment specific, we can load the Kusto Client DLLs from storage already created during the CRI deployment steps - from the NUGET file share in the CRI storage account. Optionally you could create blob storage and upload the libraries from this link - https://www.nuget.org/packages/Microsoft.Azure.Kusto.Data/

# Define the path to the Kusto client libraries

$kustoLibPath = "[your library path]\net6.0\"

# Load the Kusto client libraries in the correct order

Add-Type -Path "$kustoLibPath\Microsoft.Identity.Client.dll"

Add-Type -Path "$kustoLibPath\Kusto.Data.dll"

These libraries are required for the script to construct the Kusto client query, used in this context:

$kcsb = [Kusto.Data.KustoConnectionStringBuilder]::new($clusterUrl, $databaseName)

I also simplified the runbook, removing the dependency to write and store the user data in CSV, and just held the data in temp storage (JSON format) in the script.

# Fetch user information

$users = Get-AzADUser | Select-Object DisplayName, Id, UserPrincipalName

# Convert user data to JSON format for Cosmos DB ingestion

$usersJson = $users | ForEach-Object {

    [PSCustomObject]@{

        DisplayName       = $_.DisplayName

        Id                = $_.Id

        UserPrincipalName = $_.UserPrincipalName

    }

}

In our query we get UPN's in our call records, with an automated process to keep things up to date:

Next

I hope this post helps share the flexibility and specific ways to integrate additional data into call records with automation. You may not need this specific use case, but experiment with data integration needs for your organization.

In our next chapter we will investigate visualizing Call Record Insights in Power BI, and the value of CRI data retention in comparison to Teams Call Quality Dashboard, and QER in PowerBI - and way to leverage CRI to investigate call issues and correlate call ID's between TAC and CRI.

Thanks

JB