Office 365 deployment – notes for some painful bits

O365 or M365 Apps for enterprise or Microsoft defender for spreadsheets – or whatever its called next week – can be… unpleasant…. at the best of times to deploy and configure…. here’s a couple of things that can help.


Use the web-based to create your xml, not SCCM

The main reason here, is that when you go to “Office 365 client management” in SCCM, and select “Office 365 installer” and follow the wizard, you will get a bunch of nicely presented options, but for some reason the language option of Language ID=”MatchOS” is not an option that is available in the drop down.

If you head over to, Language ID=”MatchOS”  is the first option. This makes deployment much easier where you would like your proofing language to be English (Australian) for example, or where you want to use proofing languages that match the the region where you are deploying to multiple regions.


Teams is a per-user install – so if you have performed basic security lockdowns such as disabling the run key – it wont install

This is just all types of absolute shit. When teams (optionally) installs as part of office, it actually installs the “Teams Machine-Wide Installer”, and then as each user logs on, it installs in the users profile utilising the run key.

One work around for this is to create a shortcut in all-users startup with the command C:\Program Files (x86)\Teams Installer\Teams.exe” –checkInstall –source=default as helpfully documented here –

There is also other possible modifications such as


Now that i have installed teams, how do i pre-configure some of the settings for my users ?

Here comes the fun part – setting defaults as part of an install or using group policy or registry settings in HKLM… well, no… those traditional methods im sure are termed “legacy” somewhere within MS…

Configuring Startup Settings in Microsoft Teams with Windows PowerShell


Thanks to links above, we have example powershell which we can use to modify the json file that keeps the user preferences… and in order to save them, we just need to terminate the teams process – and roll this out across the userbase. Cool, normal and totally not user intrusive at all.


Updating Outlook to use Celsius

Its understandable that Farenheit is the default, given the 4.21% of the worlds population use that unit of measurement.

For the other 95% of the planet – updating outlook to use Celsius is almost as fun…. its another per-user setting stored in a semi-randomly named dat file – as nicely documented in this technet forum post.

Again, the outlook process needs to be terminated for this to occur – completely reasonable. Given that Technet forums will disappear at some stage – the bare-bones of the script is below.

$LocalPath = "$env:USERPROFILE\AppData\Local\Microsoft\Outlook\RoamCache\*"
$LocalFileName = (Get-Item -Path $LocalPath -Filter "Stream_Weather*.dat").FullName
$Content = Get-Content -path $LocalFileName
Stop-Process -Name outlook -Force -ErrorAction SilentlyContinue
Set-Content $LocalFileName $content.Replace("DegreeType"" v=""9-1""", "DegreeType"" v=""9-0""")


The other option is to simply disable it via GPO – given its weather is far from accurate (at least for Aus) anyway.

User Config | Admin templates | Outlook 2016 | Outlook options | preferences | calendar options | Disable weather bar > Enabled


What about OneDrive ?

A OneDrive is installer is copied with office as well, and exists in the same folder as teams ready for deployment on a per user basis… however, thankfully the OneDrive team seems to be a bit more aware of management and has made some options available for us to install the “sync app” on a per-machine basis – as documented (very well) here –

i use a seperate application installation with Onedrivesetup.exe /allusers /silent /configure_business:<tenantID> combined with some group policy settings for silent logon



So… how can we address this complete and utter shit-show and make it into something semi-usable, manageable and not user-intrusive ?

  • We can re-enable the processing of the run key…. this allows teams to install per-user with the installer-provided method… but goes against pretty much every reputable Windows hardening guide… and it runs every time – which is just inefficient.
  • We could use a self-deleting scheduled task as recommended here.… but what happens when another user comes along to the same machine?
  • We could use ActiveSetup… its a bit better, as it runs pre-user shell (and is therefore less intrusive) and is only run once per user. Unfortunately this is only effective for the teams install…. and not the modification of the json for teams or the .dat for outlook – as they need to be run once in the user context before the config files are created
  • We could use a logon script – but that runs every time – and is really no better than a scheduled task or using the run key or startup folder
  • Use a funky per-user detection rule as per and and adapt it for teams


None of the options are great… and i’ve found that i end up using something different at each client – because they have different requirements.



Leave a Reply