Slow PowerShell Response to Get-Mailbox Debugging Protocol

Gentle reader of calendar migration intent,

Ms. Calendar received the following (edited slightly for clarity):

When setting up an impersonation account in our active environment the first few steps (editor's note: see The Cookbook Version of Exchange Migration Rights) go fine and then when I run this:

Get-Mailbox -resultsize unlimited | add-mailboxpermission -user OurDomainUser -accessrights:  fullaccess -InheritanceType: All

It just sits there and never spits out any output.  Yesterday I left it running for hours and eventually Exchange Management Shell closed itself but I still get the you don't have access to this email when trying to log in to any email accounts with the service account.

An  interesting case which does occur! 

There is not a lot of love across the community for Get-Mailbox performance and even less for practical actions to take.  See: Performance issues with Get-Mailbox -Database PowerShell cmdlet and Count Mailboxes Per Database Faster.

Hats off and thanks to Russ and his team for this migration-centric debugging protocol:

It is probably a problem with "get-mailbox"

To test:

1) First try without any qualifiers: 

get-mailbox  

or limit it to 100

get-mailbox  -resultsize 100

2) Second add the resultsize qualifier

Get-Mailbox -resultsize unlimited

Once they set a static limit instead of unlimited they were able to set impersonation on all accounts.

We have seen in instances where the performance is deplorable it's usually a problem getting the "join"s to work through AD.  Keep in mind we're linking two separate AD actions here, Get-Mailbox and Add-MailboxPermission.

Where is the AD server located? 

on the same subnet? 

Are there access issues there?   

To test if it's a connectivity issue, use PortQry to check for connectivity issues. You can download it from Microsoft. Test ports 389 (LDAP) and 3268 (Global Catalog).  There are other possible ports, but these are the main ones used.

On the related issue when you have trouble with Exchange performance itself, see Troubleshooting performance issues with Exchange when RPC request spike high.

MDaemon Mail to Exchange via imapsync

Gentle reader of migration mindedness,

Today we will use imapsync for migrating email from MDaemon to Exchange.

Why?  Obviously because we're going to get to moving calendars for this legacy product, but you only get to calendars if you're also doing email and we get asked about email, so we're documenting it here.

Using imapsync will cost you all of 50 Euros.

Goodness, gracious it is worth it!  

This application has significant advantages over other products:  

1. It is really simple to install and use.
2. The "sync" in the title is serious.  You can upload all the data from a user set during working hours and then cut over the incremental changes starting on a Friday after closing time.
3. You can also use imapsync on a Linux environment as well as a Windows environment.
4. It is all in your control as opposed to run through someone else's data center or through a major integrator looking to run up hours.
5. It is very reasonably priced with the most liberal license I have seen.

We use the Windows version in our testing.

imapsync runs exclusively in the Command Prompt.

First off, please make sure you have enabled IMAP on your Exchange 2013 server.

Migrating from MDaemon to Office 365 looks something like this (if you use individual passwords for users).

imapsync.exe 
--host1 147.1.41.1 --user1 zyg@sumatra.local --password1  "XXXX" 
--host2 outlook.office365.com --user2 zyg@sumatra.onmicrosoft.com --password2 "XXXXX"  
--ssl2

If you set up a service account with FullAccess, you can accomplish a migration with a command like this:


imapsync.exe 
--host1 147.1.41.1  
--user1 jimi.hendrix@sumatra.local --password1  "XXXX" 
--host2 outlook.office365.com --port2 993 --sep2 / 
--user2 jimi.hendrix@sumatra.onmicrosoft.com  
--authuser2 riuliano@sumatra.onmicrosoft.com 
--password2 "XXXXX"  --ssl2

Note in  the above, for an Office 365 target system we need to use the "--sep2 /" command. 

Executing will give you some excellent statistics and feedback.

Other things to be aware of

Exchange Configuration Requirements:

Before you can run imapsync, you will have configure Exchange for IMAP.  This requires two steps.

Step 1: Start two IMAP4 services (and configure those services to automatically start if you wish.)

By default, in Exchange 2013 the IMAP4 service(s) are stopped:

To start those services: On the computer running the Client Access server role:

1. Set the IMAP4 service to automatically start:

     Set-service msExchangeIMAP4 -startuptype automatic

2. Start the Microsoft Exchange IMAP4 service.

     Start-service msExchangeIMAP4

On the computer running the Mailbox server role:

1. Set the Microsoft Exchange IMAP4 Backend service to start automatically.

     Set-service msExchangeIMAP4BE -startuptype automatic

2. Start the Microsoft Exchange IMAP4 Backend service.

             Start-service msExchangeIMAP4BE

In our case, the CAS and Mailbox server roles are on the same box:

Step 2: Configure Exchange IMAP4 External Connection so users can see (and thus use) the IMAP server settings

Use the powershell SET-IMAPSettings cmdlet, e.g.:

     Set-ImapSettings -ExternalConnectionSetting {:993:SSL}.

This requires you restart IIS.

This is true even if you are working within the firewall  Thus in our case, the External Connection is the same as the InternalConnection.

Finally,  Verify things are working, using OWA’s Options select Account, then pick the “Settings for POP or IMAP access” link.

For more information see: http://technet.microsoft.com/en-us/library/bb124489(v=exchg.150).aspx

These sample scripts for major migrations / multiple users will help you out a lot.

http://imapsync.lamiral.info/examples/sync_loop_windows.bat

http://imapsync.lamiral.info/examples/file.txt

I really like the way this user lays out a basic sequencing for migrations including how and when to change your MX records.

http://hadjigeorgiou.com/blog/mdaemon-to-microsoft-exchange-migration/

And on the more than crucial need for advance planning and testing, please read this thread.

Throttling in Exchange 2013

The way you control throttling changed in Exchange 2013.  If you recall, we set a different set of throttling attributes in Exchange 2010 when impersonating users.  Those attributes differ from user throttling attributes (this is a good thing for migrations!!) In Exchange 2010 there were seven throttling attributes.  In Exchange 2013, there are only TWO (again, we're focused on EWS impersonation access):

• EWSMaxConcurrency
• EWSMaxSubscriptions

To define a policy "SuThrottlingPolicy", and set it to your service account, "exsu", use the following:

 New-ThrottlingPolicy SuThrottlingPolicy -EWSMaxConcurrency $null -EWSMaxSubscriptions $null
 Set-ThrottlingPolicyAssociation -Identity exsu -ThrottlingPolicy SuThrottlingPolicy



For the inquiring minds, the following are set in Exchange 2010, but NOT used in Exchange 2013:

• EWSFastSearchTimeoutInSeconds
• EWSFindCountLimit
• EWSPercentTimeInAD
• EWSPercentTimeInCAS
• EWSPercentTimeInMailboxRPC

Here are the errors will you see in our log files if you hit the throttling limit (taken from MSDN:)

Error	Throttling policy parameter	Description
ErrorExceededConnectionCount	EWSMaxConcurrency	Indicates that there are more concurrent requests against the server than are allowed by a user's policy.
ErrorExceededSubscriptionCount	EWSMaxSubscriptions	Indicates that a user's throttling policy maximum subscription count has been exceeded.
ErrorExceededFindCountLimit	EWSFindCountLimit	Indicates that a search operation call has exceeded the total number of items that can be returned.
ErrorServerBusy	EWSPercentTimeInMailboxRPC EWSPercentTimeInCAS EWSPercentTimeInAD	Occurs when the server is busy. The BackOffMilliseconds value returned with ErrorServerBusy errors indicates to the client the amount of time it should wait until it should resubmit the request that caused the response that returned this error code.

Or, the HTTP status codes that are returned by throttling errors:

HTTP status code	Description
HTTP 503	Indicates that EWS requests are queuing with IIS. The client should delay sending additional requests until a later time.
HTTP 500	Indicates an internal server error with the ErrorServerBusy error code. This indicates that the client should delay sending additional requests until a later time. The response may contain a back off hint called BackOffMilliseconds. If present, the value of BackOffMilliseconds should be used as the duration until the client resubmits a request.
HTTP 200	Contains an EWS schema-based error response with an ErrorInternalServerError error code. An inner ErrorServerBusy error code may be present. This indicates that the client should delay sending additional requests until a later time.

Exchange 2010 Permissions Debugging Protocol updated

It being a new year and we having found a few new ways that Permissions could be problematic in Exchange, we've modified the Debugging Protocol.

The latest is available at this link: Exchange_2010_Permissions_Debugging_Protocol.pdf and supersedes all earlier versions.

Changes mainly affect the holiday cmdlet.

Exchange 2010 Permissions for Migration

Impersonation has nothing to do with Frank Gorshin or Rich Little.
It's the permission you need to give your service account to execute a full-state calendar migration.

Create a managementRoleAssignment:

new-ManagementRoleAssignment

-Name:_suImp8

-Role:ApplicationImpersonation

-User:'mysvcaccount@mydomain.com'

If you have to ask where you're doing this, please go to your Exchange Administrator.