Part of PF migration challenge is that Exchange 2013 CU7 hierarchy mailboxes cannot exceed 100 GB as prescribed by Microsoft (https://technet.microsoft.com/en-us/library/dn594582(v=exchg.150).aspx) This is the absolute maximum, recommended size is actually half of that value: 50 GB. Here you need to learn how to perform PF Move Requests, PF Branch moves or PF Mailbox split.
Whether you go with mailbox split ps1 script or PF branch move ps1 script – it’s all in a sense a bunch of PF Move requests under the hood, just the move job is more robust and has higher tendency to fail. The scripts are provided in the Exchange 2013 Scripts folder on each Exchange server. Here are some considerations of when each one can be used:
– My favorite – I call it “easy touch move” … kidding 🙂 when your PF mailbox with synced data is approaching 50 GB, just look in the Target Ex 2013 under the root folder where the job is currently sitting and perform few folder moves “Root”,”Root\Folder1″,”Root\Folder1\Sub-Folder1″ via issuing single PF Move Request. What this does is folder created next by PFTA will adhere to the new PF mailbox where its parent folder now resides. So you “sort of” switch PF Sync stream from one PF hierarchy mailbox into the other.
-Move PF Branch script. You give it root folder and it moves the entire PF branch with all subfolders underneath it. This comes handy when you go skiing on the weekend and find one of your PF hierarchy mailboxes to be 100 GB in size on Monday morning 🙂 Well, to tell you the truth I actually had to watch things even during my busy weekends, but indeed ran into a 100 GB mailbox one day so had to work on decreasing its size.
-And finally PF Split script. I must tell you I didn’t like much this one. It worked ok few times but never was able to actually split mailbox at the ratio I expected. It was just taking 3 – 5% of its size, so hoping you’ll get better experience with it. More often it was just failing on me with the error below and increasing value inside XML was not helping, at which point I just decided to stick with the other two methods.
“Error details: The formatter threw an exception while trying to deserialize the message: Error in deserializing body of request message for operation ‘ValidateAndPopulateRequestJob’. The maximum string content length quota (262144) has been exceeded while reading XML data. This quota may be increased by changing the MaxStringContentLength property on the XmlDictionaryReaderQuotas object used when creating the XML reader.”
NOW THE MOST IMPORTANT PART. DON’T EXPECT PF MOVES TO JUST WORK.
BEFORE STARTING THE MOVE, SOURCE AND DESTINATION MAILBOXES NEED TO BE IN SYNC WITH PRIMARY HIERARCHY MAILBOX, OTHERWISE THE MOVE FAILS. WHILE IT CAN STILL SUCCEED, MOST OFTEN YOU WILL NEED TO STOP ALL PF SYNC JOBS WHILE MOVING PFS as hierarchy is out of sync and move will fail. It’s advisable to run Update-PublicFolderMailbox with InvokeSynchronizer or sometimes with -FullSync switch to kick in the hierarchy sync process:
Public Folder Mailbox Source:
Update-PublicFolderMailbox –Identity “pfmailboxname” -InvokeSynchronizer | ft –autosize –wrap
Public Folder Mailbox Destination:
Update-PublicFolderMailbox –Identity “pfmailboxname” –InvokeSynchronizer | ft –autosize –wrap
OR To Trigger Sync on All PF Hierarchy Mailboxes (it will throw error on the Primary – just ignore):
Get-Mailbox -PublicFolder | Update-PublicFolderMailbox -InvokeSynchronizer
To Track the progress:
Get-PublicFolder -Mailbox “PRIMARY_HIERARCHY_MBX” -Recurse -ResultSize Unlimited > C:Primary.txt
Get-PublicFolder -Mailbox “SOURCE_HIERARCHY_MBX” -Recurse -ResultSize Unlimited > C:Source.txt
Get-PublicFolder -Mailbox “DESTINATION_HIERARCHY_MBX” -Recurse -ResultSize Unlimited > C:Destination.txt
Folder Count should be equal for the moves to work: PRIMARY_HIERARCHY_MBX = SOURCE_HIERARCHY_MBX = DESTINATION_HIERARCHY_MBX
Here is also nice script for troubleshooting (it will take some time!): “https://gist.github.com/bill-long/f97df51f2151afe5340f”
Example – one of my mailboxes was ~ 17,000 vs 90,000 folders and was climbing at the rate of about ~ 10,000 folders per hour, so it does take time to complete! Pre-create your PF mailboxes ahead of time so that they seat in the environment for a while and get in-sync with the Primary Hierarchy Mailbox.
PF MOVES
Per Folder:
New-PublicFolderMoveRequest -DomainController dc12 -AllowLargeItems -TargetMailbox PF101MB06 -Folders “Root1″,”Root1Folder1″,”Root1Folder1Subfolder1”
Per Branch (Script):
.Move-PublicFolderBranch.ps1 -FolderRoot “Root1” -TargetPublicFolderMailbox PF100MB06
Split Mailbox:
.Split-PublicFolderMailbox.ps1 -SourcePublicFolderMailbox PF400MB03 -TargetPublicFolderMailbox PF100MB03 -MinimumPercentageToSplit 30 -AllowLargeItems
Here is how success looks:
IMPORTANT: After the move, Source mailbox will not immediately drop in size. It will take at least 24 hours or longer plus require some steps.
Run Get-OrganizationConfig | fl Default*
Set-OrganizationConfig -DefaultPublicFolderMovedItemRetention 1:00:00:00
Unfortunately it will not let you set it to anything less than 1 day.
Here is how you can monitor PF Moves. If you see TransientFailure even though it shows in progress – it will 90% fail. Just suspend, remove PF move request and give your environment more time for PF hierarchy to get in sync.
Get-PublicFolderMoveRequestStatistics -identity publicfoldermove | select status,statusdetail
Status StatusDetail
—— ————
InProgress LoadingMessages
CopyingMessages
Completion
Finalization
Cleanup
(NOT TransientFailure)
Or Also:
Get-PublicFolderMoveRequestStatistics -IncludeReport | export-csv C:report1.csv
Then approximately one day after the move mbx size should decrease automatically, if not – then run Mailbox Assistant:
Start-ManagedFolderAssistant on Source PF mailbox to initiate free space release after the move
