This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Avoiding Outlook OST regeneration

Hello all-

We are performing an intra-forest domain consolidation (child into parent). Customer is currently on Office 365 which resides on the target. Pre-migration, users would log into their respective child domains and then into the parent for email. 

Our process is to merge their source account into the target. Process is fine and works as advertised.

Some of this customer's remote sites have very slow WAN links (some 1.5-3mb/s) servicing sometime 30-40 people. When the computer is migrated to the parent and Outlook is fired up, the OST is regenerated which clogs the pipe to the point where the business cannot operate.

Research shows this:  https://technet.microsoft.com/en-us/library/cc179067.aspx  Essentially using GPOs to throttle how much traffic will come down.

I think I know the answer to this but is there anyway way to preserve the whole OST post-move? QMMEX is not in play and I don't think a Remote User Collection would be relevant here anyway.

As always, thanks for the assistance.

Eric

  • I don't understand why the OST is being recreated in the first place. Assuming you are processing the workstations and the users are using the same user profile, same MAPI profile, the OST should NOT rebuild.
  • We are processing the workstations and the same MAPI profile is being used. OST is definitely being re-generated as you can see the messages being downloaded again.
  • That's odd for sure. Outlook is already connected to the target mailbox so the .OST file shouldn't get recreated. I'm wondering if this has anything to do with the permission behavior of Outlook from your other thread.
  • It may. To circumvent the OL and Registry issue, we are pre-processing everything EXCEPT the Registry. Then, when its time to move, process all, move, process Reg again. Now, if I could just get some traction on my Win10 migration issues.....
  • I agree with this. On our last migration, and our current that we are still in testing, the OST must be completely rebuilt. This is evident when you open Outlook to a blank slate and all folders must be updated.
    We are using CPUU to update the addresses for nicks and contacts, as well.
    -Derek
  • Derek, this is normal for an Exchange migration. It is common for an AD only migration, intra-forest in this case.
  • You're on the right path in throttling the .OST regeneration.

    Both Outlook 2013 and 2016 have the ability to limit the mail that is kept offline, minimizing the .OST hit after your migration.  2016 being more flexible (down to 3 days, 1 week and 2 weeks). 2013 can go as low as 1 month. By default - both are set at 12 months of mail data to be downloaded into the .OST.

    If the .OST regeneration is unavoidable - I'd recommend creating a GPO to adjust this setting to a lower value, even if temporarily to avoid saturating the customer's slow WAN links. You can then adjust the setting back up to the default of 12 months over a period of time after the remote site's migrations are completed. I've used this technique in some larger cutover migrations where bandwidth concerns existed and .OST regeneration was impossible to avoid. 

    Refer to the following MS KB Article for adjusting this in Outlook 2016: https://support.microsoft.com/en-us/help/3115009/update-lets-administrators-set-additional-default-sync-slider-windows