RUM, Windows 7 and Outlook 2016

Hello all-

Weird thing I'm seeing with some of my workstations. I'm doing a child to root AD domain consolidation. Target Exchange is Office 365 and is outside the scope of my engagement. All child domain users also have an account in the root for O365 so I'm merging source and target objects. QMM for AD 8.14

Workstations are primarily Windows 7, Outlook 2016. On occasion and what appears to be randomly when a workstation is moved to the root domain, Outlook will break with an error of: "Cannot Open Outlook." I cannot run in safe mode nor can I create a new profile and so far the only solution is to try to run a repair on Office or uninstall and reinstall of Office. 

I think it's permissions-related but I can't see how. The RUM processes and moves systems without any issue and this only happens randomly. I say permissions as when I try to run Outlook with any switches, I can't even see the executable outlook.exe. Finally, on the few OL2013 client I've migrated, all have gone without a hitch.

Anyone else run into this? Any insights, thoughts or ideas? I've migrated 1000s of Win7 systems and never seen this. This has not happened on the handful of Win8 and Win10 clients either.

As always, thanks,

Eric

  • I can't see how it's permissions related either. RUM checks to see if the source permission is there and if it is, RUM checks against its .ini file for the target SID and then drops it in if it's present. Maybe a security policy somewhere?
  • There is a feature (PIA feature I might add) in Outlook 2013 and Higher, that impacts a migration. Outlook changes the permissions on the MAPI profile keys in the registry when it is launched and closed.

    Add this to your migration process, run a Processing Task after your Move Task , and only process the registry .
  • In reply to Jeff Shahan:

    Didn't see this reply until now. Not sure why. So re-process with just the registry post move? Can I do it before the reboot? We've found that we need about a 15 minute restart timer so the SPNs can re-generate when the system moves from child to parent domain otherwise we get a security database error. It would be ideal for us to do that before the reboot.
  • In reply to Chris.Holley:

    I just don't understand why I have not run into this before. I've done plenty of Win7/Office 2013 gigs..never seen this one before.
  • In reply to eric_bergstrom:

    You could, it just depends on if you have the end user out of the system of not. That is the key factor
  • In reply to Jeff Shahan:

    So from what I'm reading from that article, if the RUM has processed the systems in advance of migration and the user logs out and back in (we try to pre-process systems a week in advance) then the ONLY way to resolve this is to log into the target post move, RUM with Registry only, THEN try Outlook. Did I get this correct?
  • In reply to eric_bergstrom:

    You just need to process the registry again before they logon as the target account.
  • In reply to Jeff Shahan:

    Although not a scientific survey, processing the registry post move but before the reboot reduced this issue dramatically
  • In reply to Jeff Shahan:

    Jeff - What do you think of pre-processing without touching the Registry (maybe just profiles, shares and files/folders) first and right before the move, process everything including the registry? Then for good measure, process the Registry post-move?