Just can't get enough of IT

Description

This script removes orphaned mobile device partnerships from Exchange Server 2013+ user mailboxes. Run the script as a scheduled task to maintain your Exchange Server environment properly.

This script utilizes a settings.xml file to configure

• SMTP settings for email reports
• Threshold values for mobile devices
  • Default number of allowed devices per user: 5
  • Defaul number of aged devices to be removed: 1
  • Default threshold for unsynchronized devices: 150 days

Settings.xml (default)

<?xml version="1.0"?>
<Settings>
  <EmailSettings>	
    <SMTPServer>smtp.mcsmemail.de</SMTPServer>
    <SMTPPort>25</SMTPPort>
    <MailFrom>postmaster@mcsmemail.de</MailFrom>
    <MailTo>postmaster@mcsmemail.de</MailTo>
  </EmailSettings>
  <OtherSettings>
	<!-- MobileDeviceLimit defines the overall threshold of mobile devices for a single user to synchronize. Default is 5. -->
	<MobileDeviceLimit>5</MobileDeviceLimit>

	<!-- AgedDeviceLimit defines the threshold of allowed aged devices for a single user to be removed. Default is 1. -->
	<AgedDeviceLimit>1</AgedDeviceLimit>

	<!-- Time threshold in days to identify old mobile devices, Be default devices not synchronized for 150 days will be removed -->
    <LastSyncDays>150</LastSyncDays>
  </OtherSettings>
</Settings>

Steps being executed by the script:

1. Fetch all user mailboxes hosted on Exchange Server 2013 or later
2. Iterate through each user mailbox and determine the number of mobile devices and the number of devices which have not synchronized since 150 days
3. Remove mobile device registration, if a user has more than the allowed number of devices in total and a minimum of 1 device that has not synced within 150 days and the -ReportOnly switch has not been used
4. Optionally, write a CSV export of identified mobile devices to disk | Use -ReportOnly switch
5. Optionally, send an email report | Use -SendMail switch

Examples

# EXAMPLE 1
# Remove old mobile device partnerships without sending a report email

 .\Remove-MobileDevicePartnership.ps1 

# EXAMPLE
# Remove old mobile device partnerships and send a report email

# .\Remove-MobileDevicePartnership.ps1 -SendMail

Version History

• 1.0, Initial community release
• 1.1, ReportOnly switch added

Links

• Download and follow at Github: https://github.com/Apoc70/Remove-MobileDevicePartnership
• Download and like at TechNet Gallery: https://gallery.technet.microsoft.com/Cleanup-Mobile-Device-1205d2db

Follow

• Twitter @stensitzki
• LinkedIn
• Xing

Problem

It might happen that a mobile device running an Android operating system is not being redirected properly by the on-premises AutoDiscover service, when the mailbox has been migrated to Office 365.

If your device is not redirected, the device prefix is not recognized by Exchange Server and therefore not being redirected properly. The new device redirect feature for Android devices was introduced in Exchange Server 2010 SP3 RU9, Exchange Server 2013 CU8, and Exchange Server 2016.

The following device prefixes are known to Exchange by default:

• Acer, ADR9, Ally, Amazon, Android, ASUS, EasClient, FUJITSU, HTC, HUAWEI, LG, LS, Moto, Mozilla, NEC, Nokia, Palm, PANASONIC, PANTECH, Remoba, Samsung, SEMC, SHARP, SONY-, TOSHIBA, Vortex, VS, ZTE

Solution

If the device prefix of your device is not part of the default list, you can add the prefix to the AutoDiscover web.config file. 

Add the device prefix to the MobileSyncRedirectBypassClientPrefixes key in the appSettings node.

  <appSettings>
    <add key="LiveIdBasicAuthModule.AllowLiveIDOnlyAuth" value="true" />
    <add key="LiveIdBasicAuthModule.ApplicationName" value="Microsoft.Exchange.Autodiscover" />
    <add key="LiveIdBasicAuthModule.RecoverableErrorStatus" value="456" />
    <add key="LiveIdBasicAuthModule.PasswordExpiredErrorStatus" value="457" />
    <add key="ActiveManagerCacheExpirationIntervalSecs" value="5" />
    <add key="ProxyRequestTimeOutInMilliSeconds" value="30000" />
    <add key="LiveIdNegotiateAuxiliaryModule.AllowLiveIDOnlyAuth" value="true" />
    <add key="TrustedClientsForInstanceBasedPerfCounters" value="bes" />
    <add key="InstanceBasedPerfCounterTimeWindowInterval" value="900000" />
    <add key="MobileSyncRedirectBypassEnabled" value="true" />
    <add key="MobileSyncRedirectBypassClientPrefixes" value="Acer,ADR9,Ally,Amazon,Android,ASUS,EasClient,FUJITSU,HTC,HUAWEI,LG,LS,Moto,Mozilla,NEC,Nokia,Palm,PANASONIC,PANTECH,Remoba,Samsung,SEMC,SHARP,SONY-,TOSHIBA,Vortex,VS,ZTE" />
  </appSettings>

File location

%ExchangeInstallPath%\ClientAccess\Autodiscover\web.config

Notes

• Modify the web.config on each Exchange 2010/2013 Client Access Server and each Exchange 2016 server.
• After installing an Exchange 2013/2016 CU, the web.config must be modified again.

As always: Be careful when modifying application settings. Test such changes in a test environment first, if possible.

Links

• Some Android devices do not redirect to Exchange Online
• Exchange ActiveSync on-boarding to Office 365
• Exchange HTTP ActiveSync Protocol: HTTP Error 451

You need assistance with your Exchange Server setup? You have questions about your Exchange Server infrastructure and going hybrid? You are interested in what Exchange Server 2016 has to offer for your environment?

Contact me at thomas@mcsmemail.de
Follow at https://twitter.com/stensitzki

You might have the requirement to authenticate mobile devices and authorize user access to on-premises Exchange Server mailboxes using a multi-vendor strategy. This blog post focuses on the configuration of a Kemp LoadMaster located in an internal network segment. The Kemp LoadMaster ESP functionality is used to allow ActiveSync connections for members of a dedicated security group only.

This results in the following authentication and authorization endpoints:

• MobileIron access policies
• Kemp LoadMaster ESP security group membership validation
• Exchange Server ActiveSync client access allowance 
• Exchange Server mobile device policy

Overview

The following diagram shows a simplified overview for mobile devices connecting to an on-premises Exchange Server. The perimeter and internal network segments are omitted for simplification reasons.

1. A MobileIron managed device connects to MobileIron Sentry which validates access with MobileIron policies
2. If a MobileIron policy allows access the device connects to Kemp LoadMaster ESP
3. Kemp LoadMaster ESP configuration validates the security group membership of the authenticating user
4. If the user is a member of the security group, the device connects to Exchange Server
5. Exchange Server authenticates the user and checks, if the ActiveSync protocol is enabled and the device complies with Exchange Server MDM configuration

Kemp LoadMaster Virtual Service

The following screenshots illustrate a working setup for a virtual service load balancing mobile device connections from MobileIron Sentry to Exchange Server. It's assumed that you've already configured the following:

• SSO Domain settings for connecting to a domain controller to authenticate users

SSL Properties

The SSL Traffic is offloaded and re-encrypted as we need to authenticate the user with ESP. Ensure to select a Cipher Set that does not provide any weak or unsecure cipher suites. In this example I've selected the predefined set BestPractices.

ESP Options

Enable ESP to activate the ESP configuration section. The settings are as follows:

• Client Authentication Mode: Basic Authentication
  Be aware that this setting requires that MobileIron users are provisioned using DOMAIN\SamAccountName notation and not the UPN Name
• SSO Domain: An existing SSO Domain configuration for user authentication
• Allowed Virtual Hosts: The FQDN matching the Load Master virtual service IP address accessed by MobileIron Sentry to connect to Exchange Server
• Allowed Virtual Directories: Can be limited to /Microsoft-Server-ActiveSync otherwise leave the default /*
• Permitted Groups: The name of the Active Directory security group containing the allowed users
• Server Authentication Mode: Basic Authentication

Real Servers

In the Real Servers section you add all member servers of your Exchange Server DAG. Ensure to use the HTTPS protocol the health checks and ensure to query the /Microsoft-Server-ActiveSync/healthcheck.htm document.

Using this configuration you've added your Kemp LoadMaster as an additional authentication endpoint to secure mobile device access to Exchange Server mailboxes.

Enjoy!

Migrating legacy public folders (Exchange Server 2010 or older) to modern public folders (Exchange 2013 or newer / Office 365) requires a cleanup of public folders.

There are quite a lot of blog posts and tutorials available describing the general process of migrating legacy public folders to modern public folders.

First you have to identify all public folders having a backslash "\" as part of the public folder name.

Get-PublicFolderDatabase | ForEach {Get-PublicFolderStatistics -Server $_.Server | Where {$_.Name -like "*\*"}}

Just rename those public folders to a name without a backslash.

Another issue might prevent a successful public folder migration: Access Controll Lists (ACL)

This will be the case in public folder hierarchies that go back to the early days of Exchange and have never cleaned up properly during past Exchange migrations.

The cleanup any orphaned Active Directory accounts, run the following PowerShell script.

Get-PublicFolder "\" -Recurse -ResultSize Unlimited | Get-PublicFolderClientPermission | ?{$_.User -like "NT User:S-1-*"} | %{Remove-PublicFolderClientPermission -Identity $_.Identity -User $_.User -Access $_.AccessRights -Confirm:$false}

To cleanup just a single public folder, run the following PowerShell script.

Get-PublicFolder "\My Folder" -Recurse -ResultSize Unlimited | Get-PublicFolderClientPermission | ?{$_.User -like "NT User:S-1-*"} | %{Remove-PublicFolderClientPermission -Identity $_.Identity -User $_.User -Access $_.AccessRights -Confirm:$false}

It should be noted that most of the tutorials have been written using an Exchange Server lab environment with just a few legacy public folders. Therefore, some readers tend to beleive that you only need one modern public folder mailbox. That is not true. In a large legacy public folder infrastructure you will end up with a multiple public folder mailboxes. And the number of mailboxes required to serve the public folder hierarchy.

A larger public folder migration batch using 66 public folder mailboxes looks like this:

Get-MigrationUser -BatchID PFMigration | Get-MigrationUserStatistics | ft -AutoSize

Identity    Batch       Status Items Synced Items Skipped
--------    -----       ------ ------------ -------------
PFMailbox1  PFMigration Synced 91993        16
PFMailbox2  PFMigration Synced 103239       0
PFMailbox46 PFMigration Synced 35034        0
PFMailbox56 PFMigration Synced 22554        0
PFMailbox57 PFMigration Synced 20740        0
PFMailbox58 PFMigration Synced 20122        0
PFMailbox59 PFMigration Synced 7209         0
PFMailbox60 PFMigration Synced 104727       0
PFMailbox61 PFMigration Synced 23278        0
PFMailbox62 PFMigration Synced 9760         0
PFMailbox63 PFMigration Synced 9277         0
PFMailbox65 PFMigration Synced 5870         0
PFMailbox64 PFMigration Synced 5639         0
PFMailbox66 PFMigration Synced 21261        0
PFMailbox50 PFMigration Synced 27889        0
PFMailbox52 PFMigration Synced 14063        0
PFMailbox47 PFMigration Synced 29476        0
PFMailbox54 PFMigration Synced 24283        0
PFMailbox55 PFMigration Synced 4646         0
PFMailbox51 PFMigration Synced 59943        0
PFMailbox53 PFMigration Synced 30052        0
PFMailbox49 PFMigration Synced 22746        0
PFMailbox48 PFMigration Synced 16941        0
PFMailbox18 PFMigration Synced 34307        0
PFMailbox19 PFMigration Synced 4523         0
PFMailbox11 PFMigration Synced 100409       0
PFMailbox6  PFMigration Synced 116655       0
PFMailbox4  PFMigration Synced 55240        5
PFMailbox12 PFMigration Synced 37790        0
PFMailbox3  PFMigration Synced 113842       2
PFMailbox22 PFMigration Synced 46416        0
PFMailbox23 PFMigration Synced 37387        0
PFMailbox13 PFMigration Synced 231845       1
PFMailbox7  PFMigration Synced 82859        0
PFMailbox20 PFMigration Synced 65818        0
PFMailbox21 PFMigration Synced 32270        0
PFMailbox9  PFMigration Synced 46609        0
PFMailbox14 PFMigration Synced 30637        0
PFMailbox38 PFMigration Synced 246428       1
PFMailbox43 PFMigration Synced 101837       0
PFMailbox45 PFMigration Synced 157571       0
PFMailbox44 PFMigration Synced 61763        0
PFMailbox40 PFMigration Synced 70637        1
PFMailbox41 PFMigration Synced 143042       0
PFMailbox42 PFMigration Synced 81254        0
PFMailbox39 PFMigration Synced 68876        2
PFMailbox15 PFMigration Synced 58221        0
PFMailbox27 PFMigration Synced 28065        0
PFMailbox24 PFMigration Synced 31869        1
PFMailbox5  PFMigration Synced 64125        0
PFMailbox30 PFMigration Synced 72938        1
PFMailbox33 PFMigration Synced 32545        1
PFMailbox31 PFMigration Synced 93782        0
PFMailbox32 PFMigration Synced 28743        0
PFMailbox25 PFMigration Synced 100794       0
PFMailbox26 PFMigration Synced 35412        0
PFMailbox28 PFMigration Synced 27003        0
PFMailbox29 PFMigration Synced 80510        0
PFMailbox17 PFMigration Synced 97952        1
PFMailbox8  PFMigration Synced 18601        0
PFMailbox34 PFMigration Synced 87150        0
PFMailbox35 PFMigration Synced 31531        0
PFMailbox36 PFMigration Synced 37979        0
PFMailbox37 PFMigration Synced 95770        0
PFMailbox10 PFMigration Synced 14193        0
PFMailbox16 PFMigration Synced 64323        1

Enjoy (modern) public folders.

Links

• Exchange Server 2010 to 2013 Migration – Moving Public Folders
• Use batch migration to migrate public folders to Exchange 2016 from previous versions
• Use batch migration to migrate legacy public folders to Office 365 and Exchange Online

Updates

• 2016-12-20: Public folder migration batch example added

You need assistance with your Exchange Server setup? You have questions about your Exchange Server infrastructure and going hybrid with Office 365? Contact us at office365@granikos.eu or visit our website https://www.granikos.eu.

There are three different ways to configure new Exchange user mailboxes after these have been created.

• The classic manual administrator approach (keeps your job safe, but is it fun?)
• The workflow based approach using some kind of IDM workflow solution (keeps the IDM consultant's job safe)
• The scripting agent approach by extending the Exchange cmdlets (keeps your job safe, is fun, keeps you in control and get's you more free time)

The Exchange cmdlet extension is controlled by a scripting agent configuration file and a organizational setting to enable/disable the scripting agent.

Preparation

A scripting agent configuration file sample (ScriptingAgentConfig.xml.sample) is located in

• $exinstall\Bin\CmdletExtensionAgents

The sample needs to be renamed to ScriptingAgentConfig.xml, to be picked up the PowerShell engine.

As always, a slight reminder: Test any modification in a test environment first, before you use the extension in a production environment.

After succesfull testing and deployment, you need to enable the scripting agent using

Enable-CmdletExtensionAgent "Scripting Agent"

Example

Even thought that you can extend mostly any Exchange cmdlet, this example covers the extension of the New-Mailbox and Enable-Mailbox cmdlets in a multi domain and multi AD site environment.

This extension disables the following CAS mailbox settings, after a new mailbox has been created:

• ActiveSync
• IMAP4
• POP3
• MAPI over HTTP

What does the example do?

• Extension is named MailboxProvisioning and handles the cmdlets New-Mailbox and Enable-Mailbox
• Is called on trigger OnComplete
  • The extension code is called after the original cmdlet has finished
• Code is executed, if the original cmdlet was successfully finished
• Code is executed, if the mailbox created is not an archive
• A slight delay of 10 seconds ensures that domain controller activities have been finished
  • Can be adjusted or even removed, depending on your environment
• Try to fetch at least on of three user parameters to identify the user mailbox
  • Checking for Identity, Name, Alias
• Fetch a list of all domain controllers in the current AD site where the Exchange server is located
• Iterate through the list of domain controllers and try to fetch the new CAS mailbox
  • If fetched, remember the domain controller's FQDN
• Change the CAS mailbox settings as needed and use the remembered domain controller as DC to write to

<?xml version="1.0" encoding="utf-8" ?>
  <Configuration version="1.0">
	<Feature Name="MailboxProvisioning" Cmdlets="New-Mailbox,Enable-Mailbox">
		<ApiCall Name="OnComplete">
			If ($succeeded) {
				if (!($provisioningHandler.UserSpecifiedParameters.Archive -eq $true)) {
					# delay execution for 10 seconds, adjust as needed
					Start-Sleep -s 10
					
					# validate parameters to use a not null parameter
					if ($provisioningHandler.UserSpecifiedParameters["Identity"] -ne $null) {
						$user = $provisioningHandler.UserSpecifiedParameters["Identity"].ToString()
					}
					elseif ($provisioningHandler.UserSpecifiedParameters["Name"] -ne $null) {
						$user = $provisioningHandler.UserSpecifiedParameters["Name"].ToString()
					}
					else {
						$user = $provisioningHandler.UserSpecifiedParameters["Alias"].ToString()
					}
						
					# view entire forest in a multi domain environment
					Set-AdServerSettings -ViewEntireForest:$true
					
					# fetch domain controllers in AD site}
					$server = Get-ExchangeServer $env:computername
					$DCs = Get-DomainController | ?{$_.adsite -eq $server.site}
					
					$CasMailbox = $null
					foreach($d in $DCs) {
						while($CasMailbox -eq $null) {
							# find a valid domain controller having the updated user object
							$CasMailbox = Get-CASMailbox $user -DomainController $d.dnshostname -ErrorAction SilentlyContinue
							# fetch DCs FQDN
							$WriteDC = $d.DnsHostName
							break
						}
					}
					
					try {
						# set CAS features as needed
						Set-CasMailbox $user -ActiveSyncEnabled:$false -ImapEnabled:$false -PopEnabled:$false -MapiHttpEnabled:$false -DomainController $WriteDC -ErrorAction SilentlyContinue
					}
					catch {}
				}
			}
		</ApiCall>
	</Feature>
</Configuration>

Notes

After adding the PowerShell code to the ScriptingAgentConfig.xml file, the file needs to be distributed across all Exchange servers. For distribution of the scripting agent configuration file I personally recommend Paul Cunningham's PowerShell script.

Be aware of the fact, that the scripting agent Xml is being validated using a strict schema validation. The scripting agent Xml is case sensitive, as noted here.

Links

• PowerShell Script to Distribute Scripting Agent Configuration File to Exchange Servers
• Cmdlet Extension Agents & XML Case Sensitivity
• Exchange Scripting Agent – The Power Of Script

Exchange Server 2019 is the most recent release of the successful email messaging solution, introduced by Microsoft in 1996. Since the early days of the product supported a single primary email address only. The primary email address is used as the sender address when a user composes a new email message and sends the message. A mailbox can have multiple email addresses to receive messages for, but only one so-called reply-address. 

But the limitation is not valid anymore.

A recent build of the Exchange Server 2019 Cumulative Update 1 released to VLSC contains a new feature called Multi-Reply Addresses. 

This new feature is very helpful in scenarios where a single user sends email messages for multiple companies. Think of a business owner who is responsible for two or more companies. In the past, it was required to configure a mailbox account per primary email address used as a reply address. Such a configuration resulted not only on multiple inboxes but in multiple calendars and contact folders as well. 

The new Multi-Reply Addresses feature of Exchange Server 2019 provides a much better solution. Moreover, it is a CEO-safe solution.

How it works

After enabling the multi-reply feature in your Exchange Organization the new functionality is available in Exchange Admin Center and Exchange Management Shell.

When you edit the email address properties using the Edit User Mailbox dialogue of an existing mailbox you can add additional reply addresses. 

• Click Add reply address button to add an additional textbox to add a new reply address
• Select the checkbox to ensure that all addresses are used as available reply addresses
• Click OK to save the changes

The following screenshot illustrates the steps.

When you close the Edit User Mailbox dialogue the additonal reply addresses and the status are displayed in the recipient list view and the detail pane.

The following screenhot shows how the reply addresses are displayed in the list view and how the status is displyed in the detail pane. 

You can verify the updated proxyAddresses Active Directory attibute using ADSIEdit or the Attribute Viewer of the ADUC MMC. 

When you compose a new email message using Outlook on the Web, the From selector is displayed automatically. You can select one of the configured reply email addresses as the sender address. 

You can configure separate email signatures for each available reply address.

A user can select Options - Mail - Email signature to open the Email signature form. The form provides a new option to set a different email siganture for each reply address. 

This is a really exciting new feature.

How to enable the Multi-Reply feature

You can enable the new multi-reply function using the following new Exchange Cmdlet:

# Enable Multi-Reply functionality in Exchange Server 2019
Enable-SmtpMultiReply 

# Disable Multi-Reply functionality in Exchange Server 2019
Disable-SmtpMultiReply -CleanupPrimarySmtp -Force 

When disabling the Multi-Reply feature a all but one primary SMTP address is converted to a legacy proxy smtp address.

You need to be assigned permissions before you can run this cmdlet. It is required to be assigned to the Elevated Exchange Organization Management role.

Things to come

• The multi-reply or multi-primary email address engine does not support email address policies. You must activate and manage additional address manually using the Exchange Admin Center or Exchange Management Shell.
• Another interesting feature on the roadmap is the feature to include the management of multi-reply address to the users' mailbox policy. This option will allow end users to edit configured reply-addresses on their own.
• Outlook 2019 support for this feature. It's currently availabke in on-premises Outlook on the Web only.

I do not know if the new feature had been exposed accidentally, but the on-premises version of the Exchange Server 2019 benefits from this new feature. This is a true differentiator to the cloud-based service of Exchange Online.

Links

• Download Exchange Server 2019 from VLSC
• Exchange Server 2019 - Multi-Reply Documentation

Enjoy Exchange Server 2019!