[Index]

Model: relation/MicrosoftTenant

Microsoft UC Application Setup

Full HTML Help

MICROSOFT

Overview

To allow VOSS Automate to manage and provision Microsoft applications, VOSS Automate must be able to authenticate with Microsoft Entra, PowerShell proxy servers (one or more) Microsoft Teams, and Microsoft Exchange Online.

This task sets up the authentication between MS 365, MS Teams, and VOSS Automate, and sets up the PowerShell proxy server.

Note

Microsoft changed the name of Azure Active Directory to Microsoft Entra ID in August 2023.

To access the flowcharts, view the topic via the release documentation at: https://documentation.voss-solutions.com/automate.html

Note

For details around the URLs, ports, and protocols that VOSS Automate uses to connect to the PowerShell proxy and the Microsoft 365 tenant, and which the PowerShell proxy uses to connect to the tenant, see:

"Network Communications External to the Cluster" in the VOSS Automate Installation Guide or Platform Guide.

Devices for Microsoft UC Application Setup

The table describes the devices configured for Microsoft UC application setup (authentication, authorization, and PowerShell proxy):

Device Description
Microsoft Graph API

Used for managing cloud-based apps. VOSS Automate uses Microsoft Graph API to interact with Microsoft Entra.

Registering VOSS Automate as an application object in Microsoft Entra provides authentication and authorization for VOSS Automate.

PowerShell Proxy Servers

VOSS Automate accesses and provisions Microsoft Teams using PowerShell.

Authentication and authorization are enforced on the PowerShell proxy and in the Microsoft 365 tenant.

Microsoft Teams

VOSS Automate uses the PowerShell proxy server and the Microsoft Teams PowerShell module to manage MS Teams settings.

PowerShell scrips authenticate to Microsoft Teams using Basic Authentication, and credentials associated with a service account in the tenant.

Exchange Online

VOSS Automates uses the PowerShell proxy server and Microsoft Exchange Online PowerShell module to manage MS Exchange Online components.

VOSS Automate authenticates using app-only authentication, which requires a certificate and private key installed on the PowerShell proxy.

Microsoft Graph API

VOSS Automate uses the Microsoft Graph API (if available) to manage cloud-based applications, such as Microsoft Entra.

Note

When available, the Microsoft Graph API is the preferred choice, for the following reasons:

As the Microsoft Graph API matures, VOSS Automate can easily be updated to leverage new Graph functionality; new templates can be added, and existing ones can be updated. Template updates can be deployed with no downtime or service impact.

Windows PowerShell and PowerShell Proxy Servers

If the Microsoft Graph API is not available, and for on-premise applications, VOSS Automate uses Windows PowerShell, along with PowerShell management modules provided by Microsoft. In this case, VOSS Automate requires access to at least one Windows computer to use as the PowerShell proxy server.

VOSS Automate manages Microsoft Teams and Microsoft Exchange Online using the PowerShell proxy servers running Windows PowerShell. The PowerShell proxy servers execute remote PowerShell cmdlets.

The table describes how PowerShell Proxies may be used to manage on-premise or cloud-based applications:

On-premise apps Join the PowerShell proxy server to the domain under management. If using VOSS Automate to manage multiple on-premises customer domains, add at least one domain-joined PowerShell proxy for each domain.
Cloud-based apps Use a PowerShell proxy server to manage multiple Microsoft 365 tenants. A PowerShell proxy that manages only cloud-based applications can optionally be configured as a workgroup server.

Authentication and authorization may be enforced in two places:

When using Windows PowerShell for Microsoft apps management, VOSS Automate creates separate PowerShell sessions via the PowerShell proxy servers for each Microsoft application being managed for a specific customer tenant or domain.

All PowerShell sessions for a particular customer may be hosted by the same PowerShell proxy server, or you can configure a separate PowerShell proxy server for each PowerShell session. Optionally, the PowerShell proxy servers hosting the PowerShell sessions may be dedicated for this purpose exclusively.

Related Topics

WinRM and WSMan

Windows Server includes the "Windows Remote Management" (WinRM) service, which implements the "Web Services-Management" protocol (WSMan):

Once connected, VOSS Automate pushes PowerShell scripts (which it generates "on the fly") to the PowerShell proxy, and instructs WinRM to execute the scripts and return the results. The Microsoft Teams and Exchange Online Management PowerShell modules (provided by Microsoft) then connect to the Microsoft 365 tenant.

Related Topics

PowerShell Proxy Deployment Topologies

PowerShell Proxy Server Domain Membership

PowerShell proxy servers may be joined to a Microsoft Entra domain.

Domain membership is required if you're using VOSS Automate to manage or extract data from any on-premises component, such as Skype for Business Server, on-premises Microsoft Entra, or on-premises Exchange Server.

Domain membership is optional in all other scenarios.

Redundancy

Deploying two or more PowerShell proxy servers provides redundancy. PowerShell proxy servers can be scaled and made highly available by interposing a load balancer between VOSS Automate and the PowerShell proxy servers.

Load balancer requirements:

When deploying VOSS Automate as a multi-node cluster and the load balancer is configured in "IP Affinity" mode, each Unified Node will have all its requests routed to the same PowerShell proxy.

A properly configured load balancer will distribute the overall load from all the Unified Nodes across the deployed PowerShell proxy servers. When a PowerShell proxy goes out of service the load balancer will route incoming traffic to the surviving servers, bypassing the failed one.

Related Topics

Outbound Internet Proxy

Some organizations require all traffic outbound to the public Internet (including traffic to Microsoft 365 tenants) to traverse an outbound Internet proxy server for audit logging and, optionally, authentication.

Related Topics

Microsoft Entra

VOSS Automate uses the Microsoft Graph API at https://graph.microsoft.com over TCP port 443 to interact with Microsoft Entra.

Microsoft's application registration process provides authentication and authorization services for VOSS Automate. For details, see Create Application Registration in Tenant Portal

You can configure the permissions granted to the VOSS Automate application based on the management use cases for which VOSS Automate has been designated. For example, you can grant permission to VOSS Automate to manage end user license assignments, or you can withhold that permission (in which case VOSS Automate will only be able to view existing license assignments, limiting the VOSS Automate workflows available to you).

For details around the permissions that VOSS Automate requires, see Step 3: Add Microsoft Graph API Permissions

Microsoft Teams

VOSS Automate uses the PowerShell proxy and the Microsoft Teams PowerShell module to manage Microsoft Teams end user, service, device policies, and telephony settings.

The PowerShell scripts authenticate to the Microsoft Teams tenant using Basic Authentication.

Note

The Microsoft Teams PowerShell module currently only supports Basic Authentication.

The PowerShell scripts authenticate using the credentials associated with a service account in the tenant. The tenant service account must be granted sufficient privileges to perform Microsoft Teams end user, service, and device management, and it must not have multi-factor authentication enabled.

Note

To enhance the security of the connection between the PowerShell proxy server(s) and your Microsoft Teams tenant, you may wish to consider using Conditional Access to restrict management access by the service account to specific static IP addresses associated uniquely with your PowerShell proxy server(s).

For more information around Conditional Access, see What is Conditional Access? | Microsoft Docs.

You must assign at minimum the following role to the service account used for managing Microsoft Teams:

Role Description
Teams Administrator

Provides full access to all MS Teams, manages service requests, and monitors service health.

Use cases:

  • List MS Teams users
  • Retrieve Teams user identity, attributes, and assigned policies
  • Update MS Teams user attributes and assigned policies
  • Enable / disable Enterprise Voice for MS Teams users
  • Create, read, update and delete MS Teams policies
  • Create, read, update, and delete MS Teams Enterprise Voice configuration, including Voice Routing Policies, PSTN Usages, Voice Routes, PSTN Gateways, and Tenant Dialplans
  • Create, read, update, and delete MS Teams Call Queues and Teams Auto Attendants
  • Create, read, update, and delete MS Teams endpoints, including Teams Phones, Common Area Phones, Collaboration Bars, and Teams Rooms

Microsoft Exchange Online

VOSS Automate uses the PowerShell proxy server, along with Microsoft's Exchange Online PowerShell module, to manage MS Exchange Online user mailboxes, shared mailboxes, room mailboxes, and distribution groups.

VOSS Automate uses app-only authentication for Microsoft Exchange Online.

Note

For more information about app-only authentication, see App-only authentication | Microsoft Docs.

For app-only authentication, you will need to create an X.509 certificate with a private key. The certificate and private key must be installed on the PowerShell proxy server.

When registering the VOSS Automate Application Object with Microsoft Entra, you will upload the certificate (with only the public key) and assign Exchange Online API permissions and an appropriate RBAC role to the application.

You will then provision the certificate's thumbprint in VOSS Automate so that VOSS Automate can pass the thumbprint to the PowerShell proxy. The PowerShell proxy uses the certificate identified by the thumbprint to authenticate with Exchange Online.

Microsoft Entra permission for managing Exchange Online

VOSS Automate requires the following Microsoft Entra permission to manage Exchange Online:

Microsoft Entra Description
Exchange.ManageAsApp Allows a registered application to access Exchange Online resources

RBAC role for managing Exchange Online

VOSS Automate requires the following RBAC role for managing Exchange Online:

RBAC Role Description
Exchange Administrator Users with this role have global permissions within Microsoft Exchange Online. Also can create and manage all Microsoft 365 groups, manage support tickets, and monitor service health.

Note

For custom administrator user roles, ensure the associated Access Profile allows for all operations on all MS Exchange models; that is: Access Profile type: device/msexchangeonline/*

For details, see Access Profile Permissions and Operations.

PowerShell Proxy Setup

Introduction

This procedure configures the PowerShell proxy servers and installs the Microsoft Teams PowerShell module.

Note

You will need to perform the following tasks:

  1. Create Server-local Service Account
  2. Configure Local Hosts File
  3. Configure the Outbound Internet Proxy
  4. Configure WinRM
  5. Install Software Management Components on a PowerShell Proxy
  6. Test Tenant Connection

Step 1: Create Server-local Service Account

VOSS Automate must use a server-local service account for accessing the PowerShell Proxy server. It must not be a domain account (should the server be domain-joined).

This task is mandatory.

  1. Create a local service account with the following properties:

    Account Type Local Computer Account (not a domain account)
    Local Group Membership
    • Administrators
    • Remote Management Users
  2. Sign out of the server, then sign back in using the credentials for the service account you just created. Perform the remainder of the tasks in this section using this account.

Step 2: Configure PowerShell Proxy for Redundancy

Important

This task is only required if you're deploying multiple PowerShell Proxy servers behind a load balancer. If you do not have any concerns around redundancy, you can skip this task.

This procedure adds a Fully Qualified Domain Name (FQDN) to the local hosts file on each PowerShell Proxy server you're deploying. Each PowerShell Proxy server must be able to address itself with the FQDN corresponding to the load balancer's virtual IP address.

Perform these steps:

  1. On each of the PowerShell Proxy servers, open an elevated PowerShell window, and issue the following command:
PS C:\WINDOWS\system32> notepad C:\Windows\System32\drivers\etc\hosts
  1. In the Notepad window uncomment the 127.0.0.1 line (delete the hash) and append the FQDN of the load balancer virtual IP:
# Copyright (c) 1993-2009 Microsoft Corp.
#
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
#
# This file contains the mappings of IP addresses to host names. Each
# entry should be kept on an individual line. The IP address should
# be placed in the first column followed by the corresponding host name.
# The IP address and the host name should be separated by at least one
# space.
#
# Additionally, comments (such as these) may be inserted on individual
# lines or following the machine name denoted by a '#' symbol.
#
# For example:
#
# 102.54.94.97 rhino.acme.com # source server
# 38.25.63.10 x.acme.com # x client host
# localhost name resolution is handled within DNS itself.
127.0.0.1 localhost psproxy.domain.com
# ::1 localhost

Step 3: Configure the Outbound Internet Proxy

This procedure configures a PowerShell Proxy server to use an outbound Internet proxy.

Important

This step is only required if your deployment is using an outbound Internet proxy to access the public Internet (including Microsoft tenants).

Prerequisites:

Perform these steps:

  1. Sign into the PowerShell Proxy server using the local service account that VOSS Automate will use to connect to the proxy.

  2. Open Windows Settings and go to Network & Internet > Proxy.

  3. Under Manual proxy setup enable Use a proxy server.

  4. In the Address field, fill out the IP address or FQDN of the outbound Internet proxy server.

  5. In the Port field, fill out the port number required by the proxy.

    Note

    The port is typically 3128, but your organization may require a different port.

  6. Select Don't use the proxy server for local (intranet) addresses.

  7. Click Save.

    Note

    This is a per-user configuration, so ensure you sign in using the VOSS Automate service account.

  8. To make this configuration the default setting for all HTTP clients, open an elevated PowerShell session, and issue the following command:

    netsh winhttp import proxy source=ie
    

Step 4: Configure WinRM

This procedure configures the Windows Remote Management (WinRM) service with the appropriate settings for VOSS Automate.

VOSS Automate uses the Web Services-Management protocol (WSMan) to create the PowerShell sessions that manage Microsoft UC applications.

On Windows computers, the Windows Remote Management (WinRM) service implements WSMan.

You will need to configure WinRM on a PowerShell Proxy running on Windows Server 2019.

Note

Any firewalls between VOSS Automate and the PowerShell Proxy, including Windows Firewall on the proxy, must permit the connections listed in the following table, which describes WinRM Firewall Settings.

These firewall exceptions are enabled by default in Windows Server 2019.

Service Protocol Port
WinRM 2.0 (HTTP) TCP 5985
WinRM 2.0 (HTTPS) TCP 5986

Perform these steps:

  1. Open an elevated PowerShell session.
  2. Issue the following commands:
Enable-WSManCredSSP -Role Server -Force
Enable-WSManCredSSP -Role Client -DelegateComputer \* -Force
Set-Item WSMan:\localhost\Service\AllowUnencrypted $true
Set-Item WSMan:\localhost\Service\Auth\Basic $true
Set-Item WSMan:\localhost\Client\AllowUnencrypted $true
Set-Item WSMan:\localhost\Client\Auth\Basic $true
Set-Item WSMan:\localhost\Client\TrustedHosts '{server identity}'

Note

When setting the TrustedHosts value, you'll need to provide the identity of the server on which you're executing these commands:

For example, assume the server's FQDN is psproxy01.domain.com and its IP address is 10.1.1.10. If the server is not behind a load balancer, the value for TrustedHosts (including the quotes) will be:

'10.1.1.10,psproxy01.domain.com'

If the server is behind a load balancer, and the FQDN of the load balancer's virtual interface is psproxy.domain.com, then provide the following value for TrustedHosts, including the quotes:

'10.1.1.10,psproxy01.domain.com,psproxy.domain.com'

Step 5: Install Software Management Components

This procedure installs the following software components on a new PowerShell Proxy server:

Before you start

The Install-Module command used in Step 2: Install Microsoft Teams PowerShell Module and Step 3: Install Microsoft ExchangeOnlineManagement Module downloads the specified PowerShell module from the PowerShell Gallery (an online repository).

Since the PowerShell Gallery has deprecated the use of TLS versions earlier than TLS 1.2, you will need to force Windows PowerShell to use TLS 1.2, which will allow the Install-Module command to work correctly. TLS 1.2 is the default in Windows Server 2019 and later. If you're using an earlier release of Windows Server, use the following command to force PowerShell to use TLS 1.2:

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

The command is relevant only for the current PowerShell session (its effect persists only until you close the PowerShell window and end the session). Errors such as the following when using the Install-Module command are likely the result of a TLS version mismatch: "Unable to resolve package source", "No match was found…"

Step 5.1: Install .NET Framework 4.8

  1. Browse to https://dotnet.microsoft.com.

  2. Navigate to the download for .NET Framework 4.8 Runtime, or do an Internet search for ".NET Framework 4.8 download".

    Note

    Ensure you only download from a URL ending in "microsoft.com". The authenticity of software downloaded from third-party websites cannot be guaranteed.

  3. Download and run the .NET Framework 4.8 Runtime installer.

    Note

    Once the installation completes, you may need to reboot the server.

Step 5.2: Install Microsoft Teams PowerShell Module

To upgrade any PowerShell proxies that have already been deployed, perform these steps:

Starting with VOSS Automate version 21.3-PB1, the required MS Teams PowerShell module v4.3.0. If you're upgrading existing PowerShell proxy servers, perform the following steps (on each PowerShell proxy server) to use the supported version of the MS Teams module (v4.3.0).

  1. Exit any existing PowerShell and PowerShell ISE windows.

  2. From an elevated (run as Administrator) PowerShell window:

    Stop-Service WinRM
    Uninstall-Module MicrosoftTeams
    Install-Module MicrosoftTeams -RequiredVersion 4.3.0 -AllowClobber
    Start-Service WinRM
    
  3. Verify

    Get-Module -ListAvailable -Name MicrosoftTeams
    

    The output should show version 4.3.0

    $cred = Get-Credential
    

    Enter MS Teams tenant admin credentials in the pop-up.

    Connect-MicrosoftTeams -Credential $cred
    Get-CsOnlineUser -ResultSize 1
    

    The output should display the details for one random user.

To install MS Teams PowerShell module on a new PowerShell proxy, perform this step:

  1. From an elevated PowerShell session issue the following command:

    Install-Module MicrosoftTeams -RequiredVersion 4.3.0
    

Step 5.3: Install Microsoft ExchangeOnlineManagement Module

  1. From an elevated PowerShell session issue the following command:

    Install-Module -Name ExchangeOnlineManagement -RequiredVersion 2.0.5
    

    Note

    Check with VOSS in case a newer version of the ExchangeOnlineManagement module is recommended.

Step 6: Test the Tenant Connection

This procedure tests the connection to Microsoft Teams from a non-privileged PowerShell session.

Perform these steps:

  1. From a PowerShell session, configure a test session for an outbound Internet proxy (if your PowerShell Proxy server is behind an outbound Internet proxy that requires authentication):

    $w = New-Object System.Net.WebClient
    
    $w.Proxy.Credentials = (Get-Credential) (when prompted, enter your
    outbound proxy credentials)
    

    Note

    The credentials you enter above persist only for the duration of this PowerShell session, and are deleted when you exit the PowerShell session.

    See the caveat regarding proxy authentication, at: Deployment Topology Options

  2. Issue the following command to test the connection to Microsoft Teams and to perform a test query:

    Connect-MicrosoftTeams -Credential (Get-Credential)
    Get-CsOnlineUser -ResultSize 1 | Select DisplayName
    

    When prompted, enter your Teams service account credentials.

    Note

    Perform step 1 first if your PowerShell Proxy is behind an outbound Internet proxy that requires authentication.

  3. Verify that you have successfully connected to the tenant and retrieved one random user.

Configure Microsoft Tenant Connection Parameters

Full HTML Help

Note

References in this section to "PowerShell Proxy" refer to the MS Windows host running PowerShell commands. References to just "Proxy" refer to the HTTP proxy server that the the Windows PowerShell host uses to access the tenant in the cloud.

This procedure configures the following connections:

Prerequisites:

You will need:

To add and configure the Microsoft Tenant

  1. Log in to the Automate Admin Portal as a Provider Administrator.

    Note

    By default, the Provider administrator role is the only role that has the ability to create Tenant connections.

  2. Add the Microsoft tenant:

    1. Go to (default menus) Apps Management > Microsoft Tenant.
    2. Click Add.
    3. Choose the hierarchy level where you wish to add the tenant. Typically, this is at Customer level.
    4. Enter a name and a description for the tenant.
  3. Add the PowerShell Proxy connection parameters:

    1. Locate the Microsoft Teams Powershell section.

    2. In the Host field, enter the FQDN or IP address of a single-node PowerShell Proxy, or the FQDN corresponding to your load balancer's virtual IP address.

      Note

      For details around the local hosts file and the TrustedHosts WinRM configuration, see PowerShell Proxy Setup.

    3. In the Username field and Password field, enter the credentials for the local service account you created on the PowerShell Proxy.

  4. Configure the outbound internet Proxy:

    1. Locate the Microsoft Teams HTTP Proxy fields.

    2. If you have an outbound Internet Proxy deployed between the PowerShell Proxy and the public Internet, select the Use HTTP Proxy checkbox.

      Note

      • If there is no outbound Internet Proxy deployed between the PowerShell and the public internet, leave both checkboxes unchecked, and leave the Username and Password fields blank. Continue to the next step.
      • Authenticated proxy is supported.
    3. If the outbound Internet proxy requires authentication, select the Use HTTP Proxy Authentication checkbox, and enter the Proxy authentication credentials in the Username / Password fields.

      Note

      You will have already provisioned the outbound Internet Proxy's IP address (or FQDN) and port number when you set up the PowerShell Proxy. See PowerShell Proxy Setup, and note the caveat regarding proxy authentication in Deployment Topology Options.

  5. Add the Microsoft Teams Tenant service account credentials:

    1. Locate the Microsoft Teams fields.

    2. In the Admin Username and Admin Password fields, enter the credentials for the Microsoft Teams tenant service account.

      Note

      You created this account earlier. See Create Microsoft Teams Service Account on Azure.

  6. Add Microsoft 365 details to the Microsoft tenant:

    1. Locate the Microsoft 365 fields.

    2. Enter the Client ID and Tenant ID values recorded earlier during the application registration setup.

    3. If you're using client secret authentication, copy the secret value into the Secret field.

    4. If you're using certificate authentication:

      • Paste the certificate thumbprint obtained from Azure into the Certificate Thumbprint field.

        Note

        From release 21.4 onwards, this field is no longer a password, but plain text, since it is generated from the public portion of the certificate.

      • From the Certificate drop-down, choose the certificate previously created in the Admin Portal.

        Note

        • You uploaded the public key for this locally stored certificate to Azure. The thumbprint added in the Microsoft 365 tenant parameter is generated in Azure when the public key file is uploaded to Azure.
        • Certificate authentication only if a client secret is not provided.
    5. MS 365 proxy / MS 365 secure proxy: These fields allow for setting an outbound internet proxy server if required for traffic outbound to the public Internet. This proxy setup is used to define the route for the MS Graph API communications which the system uses for communication with the MS 365 cloud tenant.

      • If the Internet Proxy is not authenticated, then use the MS 365 proxy field and the format is:

        https://host:port/

      • If the Internet proxy requires authentication, then use the MS 365 secure proxy and the format is:

        https://proxyuser:proxypassword@host:port/

      In both cases the host can be a FQDN if resolvable via DNS or the IP address of the Internet proxy.

    6. Max page size for MSOLUser / Max page size for Groups: These fields control the paging size for the number of records pulled at a time from the corresponding API.

      • The MSOLUser setting controls the device/msgraph/MSOLUser related API.
      • The Group setting defines the number of records retrieved at one time from the device/msgraph/Group related APIs.

      When left blank, the default page size is 999, a high number that allows for best performance. It is recommended that you leave this blank and utilize the default value unless you encounter errors on your Microsoft 365 syncs (for example, "Template output exceeded memory limit"). In that case, you can enter a specific value less than 999 in order to try a smaller number of records until the sync no longer has an error.

      Note that reducing the value may impact sync performance so it is best to use the largest paging size that does not result in an error.

      From release 21.4-PB4 onwards, the memory limit handling of requests has been increased, so that any previous explicit specification of max page size values less than 999 may not be required anymore, or can be increased substantially.

  7. If you're using Automate to manage Microsoft Exchange online, provision the Exchange Online application certificate thumbprint.

    Note

    The certificate authentication thumbprint is generated on the Azure portal for Microsoft Exchange. You would have installed this certificate on the PowerShell proxy server and configured it in the application registration.

    The certificate thumbprint is the encrypted password required for an authenticated connection to the Microsoft Cloud Exchange portal. Connecting to Microsoft Exchange is required to sync in the Microsoft Exchange objects (mailboxes, shared mailboxes, rooms, and distribution lists).

    1. Locate the Microsoft Exchange fields.

    2. Select Enable Microsoft Exchange.

    3. In the Certificate Thumbprint field, paste the certificate thumbprint you obtained earlier.

      Note

      You obtained the certificate thumbprint when logged into the PowerShell proxy to register the Automate application with Microsoft Entra ID. See Create Application Registration in Tenant Portal.

      The certificate thumbprint was created on the proxy and uploaded to the Azure portal. When generating PowerShell scripts to manage Microsoft Exchange Online, Automate includes this thumbprint so that the PowerShell proxy can use the corresponding certificate to authenticate with Microsoft Exchange Online.

  8. Click Save.

  9. Test your Microsoft tenant connection. You will be prompted to confirm the test.

    Note

    In this step you will verify that Automate can connect to the Microsoft Teams tenant using PowerShell, and to Microsoft Entra ID using the Microsoft Graph API.

    1. On the Microsoft Tenant page, choose the relevant tenant.
    2. Click Test Connection.

Modifying Microsoft Tenant

Modifying a Microsoft tenant will only overwrite those driver parameters in the underlying connections (MSTeamsOnline, MSExchangeOnline, MSGraph) which are managed by the tenant workflows. Other driver parameters will be left as is.

Next Steps

Important

For release 21.5-PB5, Multivendor environments using the data/MultivendorUsernameMappingMacros model at a hierarchy below sys level require an additional update. High level administrators with access to this model should ensure instances include:

"username_macro_ms_365": [
   "{{ input.UserPrincipalName }}",
   "(( fn.is_none_or_empty input.username == fn.true ))<NOT_FOUND>(( data.User.username | username:input.username != '' ))<{{ data.User.username | username:input.username }}><NOT_FOUND>",
   "(( fn.is_none_or_empty input.username == fn.true ))<NOT_FOUND>(( data.User.username | username_ms_365:input.username != '' ))<{{ data.User.username | username_ms_365:input.username }}><NOT_FOUND>",
   "(( fn.is_none_or_empty input.UserPrincipalName == fn.true ))<NOT_FOUND>(( data.User.username | email:input.UserPrincipalName != '' ))<{{ data.User.username | email:input.UserPrincipalName}}><NOT_FOUND>",
   "(( fn.is_none_or_empty input.UserPrincipalName == fn.true ))<NOT_FOUND>(( data.User.username | username_ms_365:input.UserPrincipalName != '' ))<{{ data.User.username | username_ms_365:input.UserPrincipalName }}><NOT_FOUND>",
   "(( fn.is_none_or_empty previous.UserPrincipalName == fn.true ))<NOT_FOUND>(( data.User.username | username_ms_365:previous.UserPrincipalName != '' ))<{{ data.User.username | username_ms_365:previous.UserPrincipalName }}><NOT_FOUND>",
   "(( fn.is_none_or_empty input.UserPrincipalName == fn.true ))<NOT_FOUND>(( data.User.username | username_ms_teams:input.UserPrincipalName != '' ))<{{ data.User.username | username_ms_teams:input.UserPrincipalName }}><NOT_FOUND>",
   "(( fn.is_none_or_empty previous.UserPrincipalName == fn.true ))<NOT_FOUND>(( data.User.username | username_ms_teams:previous.UserPrincipalName != '' ))<{{ data.User.username | username_ms_teams:previous.UserPrincipalName }}><NOT_FOUND>",
   "(( fn.is_none_or_empty input.UserPrincipalName == fn.true ))<NOT_FOUND>(( device.cucm.User.userid | userIdentity:input.UserPrincipalName != '' ))<{{ device.cucm.User.userid | userIdentity:input.UserPrincipalName }}><NOT_FOUND>",
   "(( fn.is_none_or_empty input.UserPrincipalName == fn.true ))<NOT_FOUND>(( device.cucm.User.userid | mailid:input.UserPrincipalName != '' ))<{{ device.cucm.User.userid | mailid:input.UserPrincipalName }}><NOT_FOUND>"
    ],

Related Topics

Microsoft Overview in the Core Feature Guide

Microsoft Sync Overview in the Best Practices Guide

This relation implements the workflows to manage Microsoft Tenant connection parameters and enabled services.

Model Details: relation/MicrosoftTenant

Title Description Details
Tenant Group Assigned by FDP
  • Field Name: Tenant
  • Type: Object
Name * Microsoft Tenant user defined name can have a max length of 255 charactors within the following regex pattern - ^[a-zA-Z0-9-_ ]+$
  • Field Name: Tenant.name
  • Type: String
  • MaxLength: 255
  • Pattern: ^[a-zA-Z0-9-_. ]+$
Description Microsoft Tenant user defined description can have a max length of 255 charactors.
  • Field Name: Tenant.description
  • Type: String
  • MaxLength: 255
Microsoft Application Authentication Group Assigned by FDP
  • Field Name: Microsoft Application Authentication
  • Type: Object
Client ID * The Client ID or Application ID located in the Azure AD app registration portal.
  • Field Name: Microsoft Application Authentication.client_id
  • Type: String
Tenant ID * The Tenant ID or Directory ID located in the Azure AD app registration portal.
  • Field Name: Microsoft Application Authentication.tenant_id
  • Type: String
Certificate A locally stored certificate the public portion of which has been previously uploaded in the Azure AD app registration portal.
  • Field Name: Microsoft Application Authentication.certificate_pkid
  • Type: String
Certificate Thumbprint Certificate Thumbprint for a certificate which has been previously uploaded in the Azure AD app registration portal. Required for Exchange.
  • Field Name: Microsoft Application Authentication.certificate_thumbprint
  • Type: String
Secret A Client secret previously created in the Azure AD app registration portal. Not used for Exchange.
  • Field Name: Microsoft Application Authentication.client_secret
  • Type: String
  • Is Password: True
  • Store Encrypted: True
Powershell Server Authentication Group Assigned by FDP
  • Field Name: Powershell Server Authentication
  • Type: Object
Host * Windows powershell host, serves as an intermediary between VOSS and Microsoft Teams, can be an IP address or a host name up to 255 charactors.
  • Field Name: Powershell Server Authentication.hostName
  • Type: String
  • MaxLength: 255
Username * Windows powershell host service account.
  • Field Name: Powershell Server Authentication.proxyUsername
  • Type: String
  • MaxLength: 255
Password * Windows powershell host password of the above service account.
  • Field Name: Powershell Server Authentication.proxyPassword
  • Type: String
  • Is Password: True
  • Store Encrypted: True
  • MaxLength: 255
Microsoft Teams Admin Account Group Assigned by FDP
  • Field Name: Microsoft Teams Admin Account
  • Type: Object
Admin Username Username of an admin account used by VOSS to access Microsoft Teams. Required to use device models which do not support application authentication.
  • Field Name: Microsoft Teams Admin Account.tenantUsername
  • Type: String
  • MaxLength: 255
Admin Password Admin password of the above account. Required to use device models which do not support application authentication.
  • Field Name: Microsoft Teams Admin Account.tenantPassword
  • Type: String
  • Is Password: True
  • Store Encrypted: True
  • MaxLength: 255
Resource Account Basic Authentication Enable basic authentication for resource accounts
  • Field Name: Microsoft Teams Admin Account.resourceAccountBasicAuthEnabled
  • Type: Boolean
Powershell Server HTTP Proxy Group Assigned by FDP
  • Field Name: Powershell Server HTTP Proxy
  • Type: Object
Use HTTP Proxy Use Proxy is for when there is an internet proxy set up between the powershell server and the internet. Setting it to true will make the powershell script make use of it properly so that it can get to the MS cloud. There is another setting use_proxy_auth which comes into play only if use_proxy is true which will do additional configuration when the internet proxy requires auth Default: false
  • Field Name: Powershell Server HTTP Proxy.use_proxy
  • Type: Boolean
  • Default: false
Use HTTP Proxy Authentication The proxy server through which the powershell server connects to the cloud requires credentials. Default: false
  • Field Name: Powershell Server HTTP Proxy.use_http_proxy_auth
  • Type: Boolean
  • Default: false
Username Username for the proxy server through which the powershell host connects to the cloud.
  • Field Name: Powershell Server HTTP Proxy.http_proxy_username
  • Type: String
  • MaxLength: 255
Password Password for the proxy server through which the powershell host connects to the cloud.
  • Field Name: Powershell Server HTTP Proxy.http_proxy_password
  • Type: String
  • Is Password: True
  • Store Encrypted: True
  • MaxLength: 255
Microsoft 365 Group Assigned by FDP
  • Field Name: Microsoft 365
  • Type: Object
MS 365 proxy Define the HTTP Proxy String as follows: https://user:password@server/ E.g. https://myuser:[email protected]:3128/ NOTE: Special characters in either the user or password sections must be URL Encoded
  • Field Name: Microsoft 365.http_proxy
  • Type: String
  • Store Encrypted: True
MS 365 secure proxy Define the HTTP Proxy String as follows: https://user:password@server/ E.g. https://myuser:[email protected]:3128/ NOTE: Special characters in either the user or password sections must be URL Encoded
  • Field Name: Microsoft 365.https_proxy
  • Type: String
  • Store Encrypted: True
Max page size for MsolUser Controls the number of records retrieved at a time from the device/msgraph/MSOLUser related API. Leaving it blank uses a default of 999 for optimal performance. Only modify this value if you encounter sync errors (e.g., 'Template output exceeded memory limit'), where you can specify a smaller value to resolve the issue. Note that reducing the value may affect sync performance, so use the largest value that doesn't cause errors.
  • Field Name: Microsoft 365.msol_user_api_page_size
  • Type: String
Max page size for Groups Governs the number of records fetched at once from the device/msgraph/Group related APIs. When left empty, it defaults to 999 for efficient performance. Adjust this value only if you encounter synchronization errors, like ('Template output exceeded memory limit.'). You can specify a smaller value to resolve errors, but be aware that reducing the value may impact sync performance, so use the largest suitable page size.
  • Field Name: Microsoft 365.groups_api_page_size
  • Type: String
Microsoft Exchange Group Assigned by FDP
  • Field Name: Microsoft Exchange
  • Type: Object
Enable Microsoft Exchange Enable Microsoft Exchange.
  • Field Name: Microsoft Exchange.enable_exchange
  • Type: Boolean
Admin Domain Microsoft Exchange admin domain used to authenticate.
  • Field Name: Microsoft Exchange.exchange_admin_domain
  • Type: String