Prepare exchange scans
ARM reads information from the Exchange server via a remote PowerShell connection.
An Exchange scan can be performed by any collector.
The connection is established using a client access server (CAS) or a database availability group (DAG).
The steps described in this section are not required for Exchange Online.
The Exchange Client Access Server (CAS) hosts a site within the IIS, that allows users to access the Exchange Server. It is called "Default Web Site" (2010) or "Exchange Back End" (2013 and higher) and includes the sub-site "PowerShell". This must be configured to allow ARM access to Exchange.
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 in order to apply any changes.
For example in the command prompt or PowerShell:
Set up required permissions
The service account that is used to scan Exchange requires the following access rights:
- Membership in the Exchange security group "View-Only Organization Management"
- Read permissions in Active Directory (During the scan distinguished names are resolved and access rights are partially read from the mailbox user)
- Impersonation rights to scan deputy rules, mailbox folders. See the section: Exchange Web Service - impersonation
- Its own mailbox to scan public folders
The service account that you want to use to modify Exchange requires additional different rights:
- Membership in the Exchange security group "Organization Management"
Deny rights applied to mailbox content may hinder successful scans.
For Exchange Online, create a user (with an email address) that is "Global Administrator" on the server and does not need to be licensed. Add the user to the group "View-Only Organization Management" for read only access, "Organization Management" for modify access.
PowerShell allows you to load administrative information from Exchange, such as the structure and permissions of objects, e.g. mailboxes and public folders. The Exchange Web Service allows you to access their content. Substitution rules can only be read via the Exchange Web Service.
Before you decide to read and view mailbox folders, you should ensure that this adheres to your company data security policy. You may be able to view sensitive information by only viewing mailbox folder structures.
Access to the Exchange Web Service always happen 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 via 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).
Alternatively to the process described by Microsoft you can use the GUI of the Exchange Admin Center:
Test the connection to Exchange PowerShell
Use the following process to test the connection to PowerShell:
- Start a power shell console with the credentials that are also 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):