Featured Post

Download the Sumatra Double-Booking cmdlet

You can download the Sumatra Double-Booking cmdlet for Exchange / Office 365 in a .ZIP file from here .  The ZIP file also includes the docu...

Tuesday, February 09, 2016

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.

No comments: