How to create a blank ("No Email") Outlook 365 profile by GPO

Question

This question also came up here (archived, so can't reply) which describes the issue precisely, but the export/import registry answer doesn't work in some situations (RDS and Office 365 shared licensing activation, it appears): https://social.technet.microsoft.com/Forums/en-US/0b294025-3619-4148-8797-9db7097f04d4/configuring-outlook-for-no-email-support-by-gpo
and here: https://learn.microsoft.com/en-us/answers/questions/765131/want-to-create-a-default-outlook-account-in-window.html
And is documented (but doesn't describe how to semi-automate it past the "Welcome to Outlook 2016" prompt) here: https://www.msoutlook.info/question/using-outlook-without-an-email-account

Having procmon'd and trial-and-error'd the heck out of this, I thought I would document my findings for others trying to accomplish the same.

Here's what I've found:

• The /PIM switch is what you want, but when it creates the profile, it generates a bunch of registry keys under HKCU\Software\Microsoft\Office\16.0\Outlook\Profiles specific to the user account.
• However, Outlook seems to have a hard-coded bias towards creating a profile called Outlook. If you try to automate things by running "[path]\Outlook.exe /PIM NoMail" to create a NoMail profile, Outlook inevitably creates a profile called Outlook anyway.
• You might try to work around this by instead accommodating Outlook's bias by running "[path]\Outlook.exe /PIM Outlook", but Outlook will tell you that the profile already exists--even though this is a brand-new login on a fresh user profile and the Profiles reg key doesn't even exist yet (the Outlook profile seems hard-coded, no?).
• One of the sites above says you'll need to copy the empty PST first, but you might find that it creates a new PST with the same name anyway (appended with a number), so this doesn't work in all scenarios.
• Worse, the registry keys are in binary format, and some have user-specific paths. In particular, there's a 01020fff value that contains the absolute path to the PST in binary format with nulls ("00") between each character in the path. I tried editing this with %userprofile% and c:\users\%username% etc. without success--Outlook doesn't seem to accept environment variables in the path (or perhaps there's an escape character for % symbols... I couldn't find any documentation on this).
• Strangely, even though Outlook won't launch properly without the 01020fff value, it doesn't seem to care if the parent key is renamed.
• But worse still, the registry keys seem to have randomly-generated GUID-y key names, which makes it scripting against it a bit of a moving target.
• One key that has an impact whether the "Welcome to Outlook 2016" prompt appears does seem to have the same key name each time (0a0d020000000000c000000000000046, at least in the testing environment), so this might be scriptable. This key contains two values (1102039b and 11020434, which appear to be non-random) that contain the path to the PST, but Outlook doesn't seem to care if you rename these values. One value that did seem important regarding whether the Welcome prompt appears is the 001f0433 value, which has an absolute path to a [profile_name, e.g. NoMail].sharing.xml.obi file--which didn't even exist in my testing--under the user's %localappdata%\Microsoft\Outlook path. This was inconsistent, though--renaming the value would sometimes result in getting the Welcome prompt again, sometimes it didn't.

The best semi-automated solution I've found thus far is this (I'm using the Outlook profile name NoMail below):

• Create a group policy preference under User Configuration that sets Value name=DefaultProfile under Key Path=Software\Microsoft\Office\16.0\OutlookDefaultProfile with a Value data (REG_SZ)=NoMail
• Run a login script that launches Outlook.exe /PIM NoMail
• Later in the login script, include the line GPUpdate /Target:User

This is because Outlook seems to create an Outlook profile no matter what in this scenario, and as mentioned, it throws an error if you run /PIM Outlook. It also then sets the DefaultProfile reg key to Outlook, so you need to override that--but you have to do it after the Outlook launch. The group policy preference will have applied it prior to Outlook launch and will get overwritten, thus the GPUpdate command after the Outlook launch in the script. The GPUpdate line in the script won't run until the empty Outlook window is closed by the user after they sign into O365 (the sign in is required even though Outlook won't be connecting to their Exchange account). You could also run a reg add command rather than GPUpdate, but if you have the Prevent access to registry editing tools GPO setting enabled, the reg add command will fail. To prevent the login script from running at every login, start the script with an IF EXIST statement, such as IF EXIST "%userprofile%\Documents\Outlook Files" EXIT.

Hopefully this info proves useful to someone else!