Prepare Exchange resources

Access Rights Manager reads information from Exchange using a remote PowerShell connection.

See the following sections for more information:

Preparing for Exchange online

Exchange Online requires certificate-based (app-only) authentication. ARM connects to Exchange Online using the application ID, the certificate thumbprint, and the organization of a registered app. User name and password (Basic) authentication is no longer supported for Exchange Online, and the retired MSOnline PowerShell module is no longer used.

When you upgrade to ARM 2026.4, existing Exchange Online configurations are switched to certificate-based authentication. If an existing configuration uses a username and password, register an app and update the credentials as described below to avoid connection failure.

To set up Modern Authentication, follow the steps in App-only authentication for unattended scripts (© 2022 Microsoft Corporation, obtained on October 12, 2022). The setup includes an application ID and certificate thumbprint, which you then enter together with your organization when you configure the Exchange Online resource in ARM.

In the instructions, you create a certificate and store it in the personal store location (-CertStoreLocation "cert:\CurrentUser\My"). Using this configuration, the certificate cannot be used in the context of another user.

In the following example script, the certificate is stored in personal (cert:\LocalMachine\My) and in root (cert:\LocalMachine\Root). In the first command, the DNS name must be adjusted. The domain of the collector where the scan is executed should be entered here. Alternatively, you can also enter a list of computer names (FQDN).

# Scripts are not supported under any SolarWinds support program or service.
# Scripts are provided AS IS without warranty of any kind. SolarWinds further
# disclaims all warranties including, without limitation, any implied warranties
# of merchantability or of fitness for a particular purpose. The risk arising
# out of the use or performance of the scripts and documentation stays with you.
# In no event shall SolarWinds or anyone else involved in the creation,
# production, or delivery of the scripts be liable for any damages whatsoever
# (including, without limitation, damages for loss of business profits, business
# interruption, loss of business information, or other pecuniary loss) arising
# out of the use of or inability to use the scripts or documentation.
#
# create certificate under personal
$mycert = New-SelfSignedCertificate -DnsName "domain1.local", "domain2.local" -CertStoreLocation "cert:\LocalMachine\My" -NotAfter (Get-Date).AddYears(100) -KeySpec KeyExchange
# export certificate to .cer file to upload to azure
$mycert | Export-Certificate -FilePath c:\temp\ExoCert.cer
# Export certificate to .pfx file to install the certificate on other machines
$mycert | Export-PfxCertificate -FilePath c:\temp\ExoCert.pfx -Password (Get-Credential).password
# install certificate for root
Import-Certificate -FilePath c:\temp\ExoCert.cer -CertStoreLocation cert:\LocalMachine\Root
		

The script creates two files under C:\Temp. ExoCert.cer that is necessary for uploading to Azure. You can use ExoCert.pfx to install the certificate on additional computers as well.

ARM access to Exchange Online through Modern Authentication/App Registration allows you to enable multi-factor authentication for Azure accounts. If required, Modern Authentication should also be set up for ARM access to SharePoint Online to avoid any restrictions on access to SharePoint Online.

The registered application is granted full access to Exchange Online. You cannot set up read-only access with Modern Authentication.

Preparing for Exchange on-premise

ARM supports Exchange Server 2016, Exchange Server 2019, and Exchange Server Subscription Edition (SE) on-premise for scans, permission changes, and the Exchange Logga.

Any collector can perform an Exchange scan. The connection is established using a client access server (CAS) or a database availability group (DAG).

To prepare for Exchange on-premise, perform the following procedures:

1. Prepare the PowerShell website.

2. Set up the required permissions.

3. Set up Exchange Web Services - Impersonation.

4. Test the connection to Exchange PowerShell.

Prepare the PowerShell website

The Exchange Client Access Server (CAS) hosts a site within Internet Information Services (IIS) that allows users to access the Exchange Server. Known as "Exchange Back End" in Exchange 2016, 2019, and Subscription Edition (SE), it includes the sub-site "PowerShell". This must be configured to allow Access Rights Manager access to Exchange.

1. On the CAS, start the IIS Manager.

   (Screenshot property of © 2020 Microsoft Corporation)

2. Navigate to PowerShell.

   In Exchange 2016, 2019, and Subscription Edition (SE), PowerShell is located under Exchange Back End.

3. Double-click Application Settings.

4. In the Application Settings window, perform the following steps:

   1. Select PS LanguageMode.

      The PSLanguageMode FullLanguage is no longer needed.

   2. Click Edit.

   3. In the Value field, enter the following and then click OK:

      FullLanguage

      Cumulative Exchange updates may reset this setting.

   4. Activate the desired authentication method.

Later, you must select the same authentication method in the Exchange configuration that you activate here.

Alternatively you can activate the authentication with PowerShell.

For example, Activate Windows-authentication (Kerberos).

Get-PowerShellVirtualDirectory | Set-PowerShellVirtualDirectory -WindowsAuthentication $true

You must restart the IIS to apply all changes.

For example in the command prompt or PowerShell:

iisreset

Set up the required permissions

The service account that is used to scan Exchange requires the following access rights:

• Administrator privileges on the collector server

• Membership in the following Exchange security group:

  View-Only Organization Management

• Impersonation rights to scan deputy rules.

  See Exchange Web Service - impersonation for more information.

• Its own mailbox to scan public folders.

The service account used to modify Exchange requires the following additional different rights:

Membership in the Exchange security group "Organization Management"

Denying rights applied to mailbox content may hinder successful scans.

Multi-factor authentication (MFA) is not supported for scanning or modifying Exchange on-premise.

Set up Exchange Web Services - Impersonation

PowerShell allows you to load administrative information from Exchange, such as the structure and permissions of objects—for example, mailboxes and public folders. Substitution rules can only be read through the Exchange Web Service.

Access to the Exchange Web Service always occurs in context with the mailbox user. This requires that the scan account (service account) has the right to impersonate.

Impersonation only works with active Active Directory accounts.

Examples for the configuration of impersonations using PowerShell can be found here:

• Exchange 2016, 2019, Subscription Edition (SE), online, and Office 365: How to: Configure impersonation (© 2020 Microsoft, https://docs.microsoft.com/en-us/exchange/client-developer/exchange-web-services/how-to-configure-impersonation, obtained on January 29, 2020).

As an alternative to using the Microsoft process, you can use the Exchange Admin Center GUI.

1. Log in to the Exchange admin center.

2. Select Admin roles.

3. Click Add role group.

4. Update the Admin roles section.

   1. Select the new role and give an appropriate name and description.

   2. Click Assigned.

   3. Assign the account used for Exchange scanning to the role.

5. Enable the permission.

   1. Click Permissions.

   2. Enable the following permission to the new role:

      ApplicationImpersonation

Test the connection to Exchange PowerShell

Perform the following steps to test the connection to PowerShell:

1. Start a PowerShell console with the credentials used for the remote session.

   (CTRL+SHIFT+right-click on the PowerShell-Icon -> "Run as different user")

2. Create a credential object.

   $cred = get-credential
   

3. Create a SessionOption object (turn off all checks for the test).

   $so = New-PSSessionOption -SkipCACheck -SkipCNCheck -SkipRevocationCheck
   

4. Create a session. Adjust the URI, Authentication (authentication mechanism) and encryption http(s).

   $session = New-PSSession -configurationname Microsoft.Exchange -connectionURI https://srv-ex01/PowerShell/ -Credential $cred -SessionOption $so -Authentication Default

5. Enter the session. You can execute cmdlets (which ones, depends on their rights).

   Import-PSSession $session