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
Preparing for Exchange on-premise

Preparing for Exchange online

SolarWinds strongly recommends using Modern Authentication.

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 thumbprint, which you then use as user name and password during the configuration 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.

You can install the certificate by double-clicking the pfx file. You are prompted to install it for the user or computer and in which store. To install the certificate in root and under personal, perform the operation twice.

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.

Microsoft announced the discontinuation of the "Basic" authentication method and the EWS for Exchange Online.

TLS 1.2 is required to access Exchange Online. For more information, see the Microsoft article Enable support for TLS 1.2 in your environment for Azure AD TLS 1.1 and 1.0 deprecation (© 2022 Microsoft Corporation, obtained on December 13, 2022).

Alternatively, you can still use the username/password combination for Exchange Online.

This procedure is not recommended.

Create a user with an email address as a service account or select an existing (service) account with email address.
Add the account to the View-Only Organization Management group for read-only access or to Organization Management for modify access.
If this a new account, you must log in to the Office365 environment once with this account before you can use it.

For use as a service account for ARM, it is not necessary to assign a license to the account.

Preparing for Exchange on-premise

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:

Prepare the PowerShell website.
Set up the required permissions.
Set up Exchange Web Services - Impersonation.
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 "Default Web Site" (2010) or "Exchange Back End" (2013 and higher), it includes the sub-site "PowerShell". This must be configured to allow Access Rights Manager access to Exchange.

On the CAS, start the IIS Manager.

(Screenshot property of © 2020 Microsoft Corporation)
Navigate to PowerShell.

In Exchange 2010, PowerShell is located under Default Web Site.

In Exchange 2013, PowerShell is located under Exchange Back End.
Double-click Application Settings.

(Screenshot property of © 2020 Microsoft Corporation)
In the Application Settings window, perform the following steps:

(Screenshot property of © 2020 Microsoft Corporation)
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 2010: Configuring Exchange Impersonation in Exchange 2010 (© 2020 Microsoft, https://docs.microsoft.com/en-us/previous-versions/office/developer/exchange-server-2010/bb204095(v=exchg.140), obtained on January 29, 2020).
Exchange 2013 or higher, 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.

Select Admin roles.
Click Add role group.
Update the Admin roles section.

(Screenshot property of © 2020 Microsoft Corporation)
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.
Enable the permission.

(Screenshot property of © 2020 Microsoft Corporation)
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:

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

(CTRL+SHIFT+right-click on the PowerShell-Icon -> "Run as different user")
Create a credential object.
```
$cred = get-credential
```

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

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

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

Enter the session. You can execute cmdlets (which ones, depends on their rights).
```
Import-PSSession $session
```