Yes, you are correct on the versions so yes you will have to update the script and package for these. The problem with pure ODT though is controlling where those files come from and managing all of the GPOs as you've mentioned. Re-distributing content is a trivial task so I would never count that as a negative. For a 500 client org, then this is all overkill. For any non-trivial org though, this is all a huge headache. V.Next will include this functionality natively btw.
J From: [email protected] [mailto:[email protected]] On Behalf Of Brian McDonald Sent: Wednesday, November 18, 2015 9:28 AM To: [email protected] Subject: Re: [mssms] RE: Patching 0365 Slick... Let me ask a question. The problem is every "patch" you have, they inclement the product version, unless I am missing something. Most of the complaints are that every time you do this, it requires an update to the files, and repackage, since the version changes from 15.0.4631.1004 to 15.0.X.X. If that makes sense? I think if you use the ODT method, and create the install package so that the clients are installed and pointed to the update location internally, then all you need to do is download the updates to that folder, and the clients will check automatically at that location (on it schedule) and update accordingly automatically...no need to redeploy. Or am I missing something? Brian Sent from my iPhone On Nov 18, 2015, at 8:52 AM, Jason Sandys <[email protected]<mailto:[email protected]>> wrote: This deserves its own blog post, but here's what I do. First, here's the script that I use: @ECHO OFF IF /I NOT "%PROCESSOR_ARCHITECTURE%"=="amd64" ( IF /I NOT "%PROCESSOR_ARCHITEW6432%" == "amd64" GOTO 32BIT ) :64BIT reg add "HKLM\Software\Microsoft\Office\15.0\ClickToRun\Configuration" /v "updateurl" /t REG_SZ /d "%~dp0O365" /f /reg:64 "%PROGRAMFILES%\Microsoft Office 15\ClientX64\OfficeC2RClient.exe" /update user updatetoversion=15.0.4631.1004 GOTO END :32BIT reg add "HKLM\Software\Microsoft\Office\15.0\ClickToRun\Configuration" /v "updateurl" /t REG_SZ /d "%~dp0O365" /f "%PROGRAMW6432%\Microsoft Office 15\ClientX64\OfficeC2RClient.exe" /update user updatetoversion=15.0.4631.1004 GOTO END :END This should be placed in a source directory and the updated O365 C2R files placed in a sub-directory called O365 (or whatever you want if you change the script). Create a package for this directory and a program with this batch file as the command-line. Set the package to run from DP (since you most likely don't want this to get cached down but you certainly could do that if you wanted to). Deploy. Done. J From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Brian McDonald Sent: Wednesday, November 18, 2015 7:49 AM To: [email protected]<mailto:[email protected]> Subject: [mssms] Patching 0365 I have SCCM, and deploying Office 365. However each Office 365 client by default reaches out to the internet to update, causing a lot of traffic. I have found that Microsoft has an .admx file that will disable the automatic updating of Office 365, and the following blog post of how to use SCCM to update clients with Office 365. http://blogs.technet.com/b/ouc1too/archive/2014/09/05/patching-office-365-with-configuration-manager-2012-or-how-i-learned-to-stop-worrying-and-love-the-click2rclient.aspx . By reading the comments, this looks like it might be more hit and miss than anything. I have also seen where you can use that .admx template to have clients update from a UNC path, but that becomes a manual updating of that path, and also the configuration of multiple GPOs and shares for all their sites. None of these solutions seems good for a client with 500 machines. Has anyone implemented a patch management solution for Office 365 for clients? If so, can you share the details on how you did it? Thanks, Brian
