MVP - Most Valuable Professional

Just can't get enough of IT

This blog is about mostly anything in IT. But the primary focuses are Microsoft technologies like Exchange Server, Microsoft 365, Microsoft Teams, and Cloud Security.
Thomas Stensitzki | MVP
Thomas Stensitzki | MVP

MVP LogoThomas Stensitzki is a leading technology consultant focusing on the Microsoft messaging and collaboration technologies and the owner of Granikos GmbH & Co. KG.

He is an MVP for Office Apps & Services since 2018.

Thomas is an MCT Regional Lead for Germany and delivers Microsoft Learning training courses for Office 365, Microsoft Teams, and Exchange Server.

He holds Master certifications as Microsoft Certified Solutions Master Messaging and as Microsoft Certified Master for Exchange Server 2010. These certifications make him a subject matter expert for any messaging topic related to Microsoft Exchange, Exchange Online, Microsoft 365, and hybrid configurations.

Follow Thomas: LinkedIn, Twitter

His sessions:

MVP Blog:
Personal blog:
Personal website:
Thomas' Tech Talk:

Contact Thomas at


On November 15, 2016
0 Comment
Updated: 2016-12-20

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.



  • 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 or visit our website


Read More »

Image showing three analogue cassette tapesPublic folders are one solution to provide a team collaboration tool for companies. Legacy public folders utilized a proprietary multi-master replication mechanism which was not planned to handle today's data volumes. Therefore, Exchange 2013 introduced modern public folders which utilize the robust DAG replication functionality. Due to the technology change between legacy public folders and modern public folders a migration is required.

You can migrate legacy public folders hosted on Exchange 2007 or Exchange 2010 to modern public folders hosted on Exchange 2013. Or you can migrate legacy public folders hosted on Exchange 2010 to modern public folders hosted on Exchange 2016. If a cloud migration is a viable option for your company, you are able to migrate legacy public folders hosted on Exchange 2007 or Exchange 2010 to modern public folders hosted in Exchange Online.

The requirements for legacy Exchange Servers are:

  • Exchange Server 2007 SP3 with Update Rollup 15 or later
  • Exchange Server 2010 SP3 with Update Rollup 8 or later
  • Windows Server hosting Exchange Server 2007 must be upgraded to Windows PowerShell 2.0 and WinRM 2.0 for Windows Server 2008 x64

Since Exchange Server 2013 RTM the public folder migration scripts and the migration guidance have quite often been updated. The information provided at TechNet is very detailed for each migration option and there is no need to repeat each step in this blog post. Please see the link section for all hyperlinks.


Preparing a legacy public folder migration is pretty straight forward. The main issue companies are facing is the required downtime for finalizing the public folder migration batch. The required downtime cannot be determined exactly (not as exactly as requested by upper management). This means that you have to plan for scheduled maintenance during off-hours. In the past, a single migration request has been used to migrate legacy public folders. The new batch approach migrates public folder content using multiple requests within a single batch.

Estimated Number Of Concurrent Users

The Create-PublicFolderMailboxesForMigration.ps1 script uses the parameter EstimatedNumberOfConcurrentUsers to determine the overall number of public folder mailboxes serving the hierarchy. The TechNet articles explain this parameter as follows:

The estimated number of simultaneous user connections browsing a public folder hierarchy is usually less than the total number of users in an organization.

Exchange Server 2013 and Exchange Server 2016 currently support 2.000 concurrent connections to a single mailbox. This limit (2.000) is used by the Create-PublicFolderMailboxesForMigration.ps1 in conjunction with EstimatedNumberOfConcurrentUsers to determine the number of public folder mailboxes required to serve the public folder hierarchy. The current version of the script uses a coded limit of max 100 public folder mailboxes. This means that you can only serve 100 x 2.000 = 200.000 concurrent users accessing the public folder hierarchy.

Legacy Public Folder Store

Finalizing the migration request and setting the PublicFolderMigrationComplete attribute requires the legacy public folder information store to be restarted. Otherwise, the configuration change will not be picked up in the information store in a timely fashion. Remember to restart the information store service on all legacy public folder servers.

Interim Migration

If your current public folder infrastructure is based on Exchange 2007 and you want to get rid of that Exchange version, you might think of replicating all content to Exchange 2010. This is not the best approach. Due to known content conversion issues, you might encounter data loss when replicating public folder content between Exchange 2007 and Exchange 2010.

The recommended approach is to migrate Exchange 2007 legacy public folders to Exchange 2013 modern public folders directly.

Recommended Reading

A recommended reading on legacy public folder migration from Exchange 2010 to Exchange 2016 is Butch Waller’s blog post “Migration to Modern Public Folders – Notes from the Field

The PowerShell script referenced in that blog post does not work with Exchange 2007. You can use my PowerShell script which utilizes UTF8 encoding and runs with Exchange 2007 and Exchange 2010:

All limits mentioned in this post reflect the information available at the time of writing.




Do 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 or visit our website



Read More »
The information provided is valid for Exchange Server 2016 and Exchange Server 2019.

Microsoft Docs provides detailed documentation on Exchange Server 2016 mail flow and the transport pipeline. That article helps you to

The detailed diagram showing the Exchange Server 2016 transport pipeline in the TechNet documentation does not show the TCP ports being used by the Exchange Server 2016 components.

The following diagram is an updated version of the original diagram showing the TCP ports being used by

  • Front End Transport service
  • Transport service
  • Mailbox Transport service
  • Mailbox Transport Delivery service

Exchange Server 2016 Mail Flow with Ports

By default Exchange Server implements the following receive connectors

  • Front End Transport service
    • Default Frontend SERVER, TCP 25
    • Outbound Proxy Frontend SERVER, TCP 717
    • Client Frontend SERVER, TCP 587
  • Transport service
    • Default SERVER, TCP 2525
      Server SMTP connections connected to TCP 25 are proxied to this connector
    • Client Proxy SERVER, TCP 465
      Client submission connections connected to TCP 587 are proxied to this connector
  • Mailbox Transport service
    • SERVER\Default Mailbox Delivery SERVER, TCP 475 (hidden)

Cross-server SMTP communication occurs on either TCP 2525 or TCP 475.




Enjoy Exchange Server!



Read More »


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


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.

    <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" />

File location



  • 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.



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
Follow at

Read More »


I came across an interesting issue when setting up a new Exchange 2013 server in an Exchange organization having the cmdlet extension agent enabled.

As mentioned in my last post Exchange setup checks for the existence of the ScriptingAgentConfig.xml file when agent extenstion is enabled in the Exchange organization. It turned out that this ist not only true when you install an Exchange update using /mode:update, but as well when installing a new Exchange server using /mode:install.

The following error occurs when Exchange Management Tools are provisioned.

Configuring Microsoft Exchange Server

    Preparing Setup                                                               COMPLETED
    Stopping Services                                                             COMPLETED
    Copying Exchange Files                                                        COMPLETED
    Language Files                                                                COMPLETED
    Restoring Services                                                            COMPLETED
    Language Configuration                                                        COMPLETED
    Exchange Management Tools                                                     FAILED
     The following error was generated when "$error.Clear();
        " was run: "Microsoft.Exchange.Provisioning.ProvisioningBrokerException: Provisioning layer
initialization failed: '"Scripting Agent initialization failed: "File is not found: 'C:\Program File
s\Microsoft\Exchange Server\V15\Bin\CmdletExtensionAgents\ScriptingAgentConfig.xml'.""' ---> Microso
ft.Exchange.Provisioning.ProvisioningException: "Scripting Agent initialization failed: "File is not
 found: 'C:\Program Files\Microsoft\Exchange Server\V15\Bin\CmdletExtensionAgents\ScriptingAgentConf
ig.xml'."" ---> System.IO.FileNotFoundException: "File is not found: 'C:\Program Files\Microsoft\Exc
hange Server\V15\Bin\CmdletExtensionAgents\ScriptingAgentConfig.xml'."
   at Microsoft.Exchange.ProvisioningAgent.ScriptingAgentConfiguration.Initialize(String xmlConfigPa
   at Microsoft.Exchange.ProvisioningAgent.ScriptingAgentConfiguration..ctor(String xmlConfigPath)
   --- End of inner exception stack trace ---
   at Microsoft.Exchange.ProvisioningAgent.ScriptingAgentConfiguration..ctor(String xmlConfigPath)
   at Microsoft.Exchange.ProvisioningAgent.ScriptingAgentClassFactory.get_Configuration()
   at Microsoft.Exchange.ProvisioningAgent.ScriptingAgentClassFactory.GetSupportedCmdlets()
   at Microsoft.Exchange.Provisioning.ProvisioningBroker.BuildHandlerLookupTable(CmdletExtensionAgen
t[] enabledAgents, Exception& ex)
   --- End of inner exception stack trace ---
   at Microsoft.Exchange.Provisioning.ProvisioningLayer.GetProvisioningHandlersImpl(Task task)
   at Microsoft.Exchange.Provisioning.ProvisioningLayer.GetProvisioningHandlers(Task task)
   at Microsoft.Exchange.Configuration.Tasks.Task.<BeginProcessing>b__4()
   at Microsoft.Exchange.Configuration.Tasks.Task.InvokeNonRetryableFunc(Action func, Boolean termin

As expected a fresh Exchange install contains the sample file only. The following screenshot shows the Exchange Management Shell and the releated folder in the background.

Enabled cmdlet extension agent breaks Exchange setup



The only solution currently known to me is to disable the cmdlet extension agent until the setup of the new Exchange server has finished.

Disable-CmdletExtensionAgent "Scripting Agent"

Having the cmdlet extension agent disabled the setup finishes without any issues. Don't forget to copy the cmdlet extension Xml file to the newly built server and to enable the cmdlet extension agent again.

Enable-CmdletExtensionAgent "Scripting Agent"




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
Follow at


Read More »