5 Replies Latest reply on Mar 17, 2016 8:37 AM by Klaus Salger

    Microsoft Office 365 ProPlus on Premise Deployment and Update

    MTheis Specialist

      Hi ,


      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.


      Update behavior:


      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.


      Thx, Michael

        • 1. Re: Microsoft Office 365 ProPlus on Premise Deployment and Update



          we are currently in the same process and we also have the challenge to update internal as well as external clients.

          Our solution for that is to only use internal repositories for the initial installation (actually hosted on DFS) and then use the Microsoft CDN for updates. That way all of the clients can get newer versions. We did some tests and the average size a client has to download is around 100MB (obviously that can be higher or lower). Everything else would be very tricky and ask for problems when trying to fiddle around with scripts to check if a machine is internally or externally and then to modify the registry to configure the download source.


          hope this helps


          • 2. Re: Microsoft Office 365 ProPlus on Premise Deployment and Update
            MTheis Specialist

            Hi ThorstenS70

            there is a discussion regarding machine location here: Does anyone have experience with MS Direct Access?

            Maybe there is a useful approach.



            • 3. Re: Microsoft Office 365 ProPlus on Premise Deployment and Update

              Hi Michael,


              MS Direct Access won't happen at our company Our network team and the security group are strictly against that. Which I can understand as it is good practise to have a different vendor protecting the network than is running on the clients. But obviously it would solve exactly that problem. However, Microsoft could just allow to specify two update locations.



              • 4. Re: Microsoft Office 365 ProPlus on Premise Deployment and Update
                MTheis Specialist

                It has not to be Direct Access. But the method to detect site location could be helpful. Anyway. So different updatelocations from MS would be nice, but then I still miss to see the compliance state of my clients.

                • 5. Re: Microsoft Office 365 ProPlus on Premise Deployment and Update
                  Klaus Salger Expert

                  I haven't yet implemented Office 365 ProPlus in DSM so the following thoughts are somewhat theoretical.


                  If we want to profit from DSM distribution, DSM control of what when where to install and DSM status info we need a DSM integrated solution.

                  I would go for 1 Office 365 ProPlus package that is beeing used for installation and updates. Install a certain version and update to a new revision with a new updated version thereafter. All with the same package.


                  This solution might look like this:

                  • watch the Update-Link and download the update as soon as they are available.
                    That may be done using a scheduled task with automatic download and sending a mail to the admin.
                  • create a DSM package revision using a template or snippets, include the new content, distribute and relase (maybe after the testing).
                    This needs to be done manually but should be complete in minutes. Once the template etc is ready it's always the same.
                  • create / update policies on test, pilot, production groups as needed
                    In most cases this will be a manual process anyway.


                  The package might run from the depot without staging to prevent >1GB to be downloaded to the client each month. The automatic updates would be disabled - update is done by reinstalling the package. As far as I know that's a perfectly supported solution. While handling of running office programs, informing the user etc. is done by the automatic update, it would need to be done by the DSM package when using the reinstall scenario.


                  Distribution would need to copy >1GB monthly. Storage might be reduced by deduplication - the DSM revisioning mechanism works on file basis so it won't reduce the storage requirements for new update versions.


                  This solution requires the admin to revision the office package on a monthly basis.

                  That's an extra step but doesn't require too much effort and if your process for test, pilot, production is not fully automated you need to care about the updates anyway.


                  The fully automated MS out-of-the-box alternative will work, too. But that comes without distribution, control and transparency.


                  What do you think?