Office 16.42 and "New Outlook" prompt

@jtrant I have not found a process to do this...

You can use "com.microsoft.Outlook"
Key: EnableNewOutlook
Data Type: Integer

However, the only possible values are:
0 = Switch hidden (default)
1 = Switch displayed, default off
2 = Switch displayed, default on
3 = New Outlook enabled with switch hidden

We are looking for the same option (that doesn't exist):
4 = New Outlook disabled with switch hidden

We'll be submitting a DCR to Microsoft.

I agree, for now we have set it to 0 which is better than nothing, in the hopes that not many users actually flipped the switch.

@markdmatthews Maybe I'm just missing something obvious, but wouldn't -int 0 take care of that scenario? The button to switch is hidden from the Outlook interface. I guess what I'm saying is, is there another way perhaps that it can be switched to the new Outlook, or is once it's hidden it's not possible to switch? If it's the latter, it seems you wouldn't need a "New Outlook disabled with switch hidden" since having it hidden would take care of that.

Edit: Actually never mind. I think I get what you're after now. You want a way to switch back to the old Outlook AND disable the switch button using one setting. If that's the case, then yeah, that would be something for Microsoft to add.

So, I can use the defaults command to play with this setting but how does one make a configuration profile so that it applies to anyone on a machine?

@jhuls Maybe this will help.
Write out the setting to a local (new) plist file. Avoid directing it to an existing in use Office plist. So something like this

defaults write ~/Desktop/com.microsoft.Outlook.plist EnableNewOutlook -int 0

Then convert the plist to xml format so Jamf can read it

plutil -convert xml1 ~/Desktop/com.microsoft.Outlook.plist

Now back in Jamf Pro, create a new Configuration Profile and enable the Application & Custom Settings payload. Once there, you'll see an option to upload a plist file. Choose that and select the plist you just created and it will import the setting. Then you can scope it to a few machines and test it out. I would definitely test it before just deploying it out. I can't say I've tested this exact setting myself via a profile, so I don't know for sure how it will operate.

Another option is to use the same Application & Custom Settings payload, but instead of uploading a pre-configured plist, create a JSON setting that would give you that same option and allow you to toggle it on or off. Uploading a plist doesn't give you the option of changing the setting right in the UI. You just have to upload a new plist each time you want to adjust it.

Thanks @mm2270. This is what I was hoping to learn I wasn't aware that it could be written to a different path like that.

After posting this question here I had remembered that it might be in profileCreator so I gave that a try. The option was there so I created one and now I'm dealing with Jamf support. I signed it, uploaded it, and scoped it to one machine to test. It worked like it should. The problem is that now it won't remove. It's been one of those weeks. Hoping they can figure out how to remove it because I really don't want to rebuild this particular system.

I'll try your solution on another machine and see how it goes. Thanks.

@jhuls Hmm, when you say it won't remove, are you referring to the profile itself, or the setting in the Outlook UI? I guess what I'm asking is if you go into System Preferences > Profiles on that test Mac, do you see the profile listed there even after removing the machine from the scope of the profile? If so, was it deployed as a System or User level profile?

If the profile isn't there, but the setting won't go away, have you made sure there isn't an existing outlook plist file that already had the setting added to it via Terminal?

Hope you get it resolved, whatever it is. I see no reason why that setting would not remove itself if being done properly.

The profile won't remove and was deployed as a user profile. It still shows up in the Profiles system preference and the switch is still hidden. In Jamf I see there is a failed management command of "Profile with identifier '8E8356F9-824A-42E4-BA7D-5DBC5BBF9BCF' not found. <MDMClientError:89>"

@mm2270 -int 0 will prohibit the ability for any user that has already toggled to the "New Look" from switching back. SO, IF you are ahead of the rollout this would work and prevent users from enabling the "New Look". We have taken the approach of using MAU to update MSFT apps. I am working on an Extension Attribute to identify those who have enabled the "New Look". This would allow us to use -int 0 and target the others to remediate manually (using a Static Computer Group to Exclude during a support session).

A case I have been working on with MSFT Engineering has been accepted. Expect a that will result in the following behavior... EnableNewOutlook preference is set to 0: Outlook will revert to Classic mode with the toggle hidden.

This was my proposed behavior with value 4; the decision was made to make this the new behavior with value 0.

It was agreed that the current behavior of value 0 is that the toggle is hidden but the user will stay in New Outlook if they are already in that mode, leaving them with no interface to leave that mode.

@markdmatthews this is great news, thanks for following up!

It looks like this is resolved in 16.43, setting "EnableNewOutlook" to 0 forces the client back to the old UI and disables the toggle.

The "new" Outlook looks nice, but it disables functionality that a lot of my users use. I hate how Microsoft does this 🤬 It's fine to give users a preview, but the opt-in process should communicate what will be lost when the user switches to the new Outlook. Personally, I use Apple's built-in apps with my Microsoft 365 account. They work pretty well for me and my users who choose not to use Outlook. I'm going to try restricting this with a configuration profile.

Correct, potty - forgot to post an update. MSFT Re: that 16.43 released GA Nov 10 has the updated Outlook preference (com.microsoft.Outlook.plist):
<key>EnableNewOutlook</key>
<integer>0</integer>

Unlike the other preferences, when enabled this will require a restart of Outlook to revert the "look" and hide the toggle (others force a restart).

Thanks @markdmatthews !

@markdmatthews thanks for your posts on this. You had mentioned creating an EA to find computers that had enabled New Outlook. Did you ever end up doing that? I assume that with 16.43+ you can just create a profile to set the value to 0, but with 16.42 I assume you would need to do it manually (to make sure the profile doesn't turn off the ability to toggle the switch if it's already disabled.

So how exactly do we edit this again? I've done it before but I am rusty.

nevermind. reading helps.

The com.microsoft.Outlook Plist to all users (removes the New Look toggle all together)  + a KB with Tier 1 (ie. HelpDesk) telling users to restart Outlook (if they experienced an issue with shared mailboxes etc took care of it. 

Configuration Profiles > Application & Custom Settings

Preference Domain: com.microsoft.Outlook

Upload File > Property List (i.e. com.microsoft.Outlook.plist)

this hides the button as well as the option in the file menu

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>AllowCertsWithoutMatchingEmailAddress</key>
<true/>
<key>AutomaticallyDownloadExternalContent</key>
<integer>1</integer>
<key>CalendarFirstDayOfWeek</key>
<integer>2</integer>
<key>DisableDoNotForward</key>
<true/>
<key>DisableEncryptOnly</key>
<true/>
<key>DisableExport</key>
<true/>
<key>DisableImport</key>
<true/>
<key>EnableNewOutlook</key>
<integer>0</integer>
<key>HideCanAddOtherAccountTypesTipText</key>
<true/>
<key>HideDoNotForward</key>
<true/>
<key>HideEncryptOnly</key>
<true/>
<key>Weather_update_automatically</key>
<true/>
</dict>
</plist>

Thanks for the update Mark