in the other Thread Windows 10 Servicing and Patching are we talking about the update behavior of Windows 10. So I´d like to discuss here the behavior of Microsoft Office 365 ProPlus on premise.
I choosed the Heat DSM board, because AFAIK there is no support for Office365 in Heat PM/APM/PatchLink.
My links point to the german sites. If anyone is needing the english ones and can´t find them, I will try to help.
With the Office 2016 Deployment Tools and the reference for the click-and-go file "configuration.xml" it is possible to build an eScript, which can install the appropriate version on the clients using the command: setup.exe /configure
For this we are using a central share, where we are prooviding the x86 and the x64 files. All setup files were downloaded by using setup.exe /download and the customized configuration.xml for 32 and 64 bit.
Out of the box, Office 365 is creating tasks in the task scheduler of windows which will download the updates locally on the client. This is what were are using at the moment. So, the better way would be to download the updates on a central storage and distribute them from there.
As already mentioned, I don´t know a method using PM/APM/PatchLink for this, so the only option would be to change the updatepath in the configuration.xml to a central share (see reference).
Using this way, it is also possible to work with several test and piloting groups. There is a very good blog post at MS: Managing Updates for Office 365 ProPlus – Part 2. It explains also how to get the updates, which are nothing else than a newer build of office, into the local central shares.
There is also a way to deploy the updates with SCCM and WSUS. It would be great if there is a way to integrate it in PM/APM/PatchLink , too to see the status of the update distribution and check the compliance. Maybe HEAT is already working on it, I don´t know but I would be very happy about it.
In the meanwhile maybe we could try to get a workaround for this. What about an eScript, starting the command setup.exe /configure update.xml, looking for an update on the local share on every system start and showing the compliance state based on the errorcode receiving. Has anyone already tried this or got a better method?
The other problem is, that we got a repository in our DMZ for our external clients. So, when I use an internal share for the office365 update package, those clients are unable to reach it. The connection between the internal and external DSM Server is https only, not SMB. So the best way would be using an eScript package, but then I have to redistribute this package everytime an update is avaible. And in this scenario I can´t use test andpiloting groups.