Hello,

I am looking at deploying Office 365 via SCCM, but it looks like we will loose the ability to patch via WU/MU and instead need to update via pointing 365 to a static update source in configuration.xml \\server\path\. 

Has anyone found a way to deploy the click to run 365  Office version and still effectively manage and updates and patches using SCCM distribution points?  We do not want to run the MSI version. 

Can anyone from MS here comment on the future of SCCM and 365 click to run integration ?

TIA

Lance

Hi,

are you deploying O365 via ConfigMgr?
Are you customising the deployment?
This article offers a few interesting thoughts, and you might be able to configure for your goal:
http://support.microsoft.com/kb/2772509/en-us

e.g. if your DPs could host the O365 package (either via SMB or http), you could use DNS or DFS, I guess, to provide the target for your O365 client updates/distributions.

I've always considered that CTR is an alternative to traditional distribution/patching, and one that's quite attractive, if you don't have to (or can't afford to) worry about sociability/integration/compatibility testing.
Automatic updating falls into the same category for me. If I can use it (where I don't have sociability/integration/compatibility testing to deal with), then I'll use automatic updating for everything, and never have to deal with testing, approvals, etc.

Hi Don, 

Thanks for the reply. 

We are looking to deploy with config manager and also pre-load in our image folk bulk deployment. We are creating small customization such as disabling products and adding languages.  App-V would work, but we are not licensed for MDOP, so I don't think we can use it to deploy the CTR version.  DNS and DFS would be a little tricky as we have number of sites and local dp's but I will research a bit more. 

Those are some of the same reasons we really want to use the CTR version over the traditional MSI and I'm surprised it does not have more native ability to make it easier for enterprises to take advantage of it. 

Had a ton of problems trying to specify relative paths with Click to Run for use with SCCM. This is the current xml we're using.

----snip----

<Configuration>
 <Add SourcePath="" Version="15.0.4569.1508" OfficeClientEdition="32" >
  <Product ID="O365ProPlusRetail">
   <Language ID="en-us" />
  </Product>
 </Add>
 
 <Updates Enabled="FALSE" />
 <Display Level="None" AcceptEULA="TRUE" />
 <Logging Name="Office365Setup.log" Path="%temp%" />
 <!-- <Property Name="AUTOACTIVATE" Value="1" /> -->
 <Property Name="FORCEAPPSHUTDOWN" Value="TRUE" />

</Configuration>

----snip----

We call the setup.exe /configure install.xml from SCCM and use a detection method (SCCM 2012) of one of the exe I.e winword.exe file version.

Because we don't specify a source path the path is taken from the content cache directory on the SCCM client computer. When I've tried directly from a DP I have some odd behaviour (maybe something to do with the UNC path???)

This has been working for us - hope this helps

Hi Danny

Thats fine for the installation, but how do you install the updates?

I was hoping you'd ask ;)

We created a second app in SCCM with some different settings for deployment because we expected people would be using Office while we were trying to update. . We used the same deployment method as the original app and the only real difference in the XML is the version number of the bits we are updating and the display level. We changed the display level so that if people were logged in an using Office when the installation deadline was reached they would get a nice popup that indicated if they wished to continue with the Office update then they would need to close Office. If they declined then SCCM marked the application as failed and on next software eval cycle would prompt again until success.

Our XML for the update is below - hope this helps.

<Configuration>
 <Add SourcePath="" Version="15.0.4623.1003" OfficeClientEdition="32" >
  <Product ID="O365ProPlusRetail">
   <Language ID="en-us" />
  </Product>
 </Add>
 
 <Updates Enabled="FALSE" />
 <Display Level="Full" AcceptEULA="TRUE" />
 <Logging Name="Office365Setup.log" Path="%temp%" />
  <Property Name="FORCEAPPSHUTDOWN" Value="TRUE" />

</Configuration>

• Proposed as answer by Garth JonesMVP, Moderator Tuesday, December 23, 2014 4:04 PM
• Marked as answer by Garth JonesMVP, Moderator Saturday, January 03, 2015 3:43 PM

Hi, Thanks for sharing....

If we use this method,

a) Is it going to download the whole update package to local CCMCACHE folder for update?

b) Are you running the update deployment from DP?

If you configure the installation source as a package and not an application and run from distribution point then the content should be streamed from the DP not downloaded to local cache.

However in recent deployments since code 15.0.46xx.xxxx on Windows 8.1 deployments I've found the 'SourcePath="" ' option is failing. I'm not sure why yet and I've had to fall back to using an absolute path. I've found no other solution to this as yet.

Thank you for your posts first of all!

I also ran into the issue with the SourcePath and the SCCM DPs. Instead of reaching out for the content on the DP, it was going to the CDN. I was able to work around the issue by just deleting the SourcePath from the XML file and that appeared to have worked out!

Has anyone thought of trying to use a baseline to deploy a powershell script to the client to have it query the MP based on a clients current IP and update the registry path that the updatePath specifies?

Then you'd at least be able to have clients pull the updates from your DPs, even if the content was not in the content library itself? You'd have to manually keep the content on your DPs, but it would greatly reduce the content transfers across the WAN...