Office 365 Apps for Business and Enterprise are one of the most common failures for Windows Autopilot deployment failures that are reported. Differences in the CDN’s have shown that packaging the app as a Win32 app provides a more consistent experience, but that requires maintenance.
So it would be great if PMPC could take care of the maintenance side of things!
we are now also testing the intune integration… we need this now ^^
We would love to have a way to "get inbetween" O365 trying to go to the internet for these updates (which is traffic we don't want in our facilities internet pipes) and a way we can also better control approval. This would be AWESOME to do this in a more controlled manner via this channel
Yes please! Standard 365 Apps in Intune is flaky, to say the least.
maybe also add a sample base pmpc xml? i'm available for testing purposes ^^
Thats exactly how i supposed it to be implemented. Provide the odt binaries and we use our own custom xml configuration file with it. For starting i would already appreciate to have the possibility to only publish the base m365 apps configuration but yes the possibility to have multiple “configuration” available would be also neat but for now i think we can workaround it as you said with scripting. Yes i also dont see a need to check for specific versions for now.
The more I think about this, the more I foresee needing to let customers define their own XML for the ODT (to configure their own preferences for things like channel, language, products to be installed, etc) and we'll simply include the ODT as the binary in the catalogue.
Customers would add their XML via the Add additional file(s) (in Add custom pre/post scripts), and then change Modify command line to specify the name of the XML file.
This would create drawbacks where some customers have indicated they wanted multiple configurations of the Office app in their environment/tenant; one with base M365 apps, another with base apps + Project, another with base apps + Visio, another with base apps + Project + Visio.
At this time, this is not natively possible via the Publisher's UI until this idea is implemented: https://ideas.patchmypc.com/ideas/PATCHMYPC-I-631 - however if you executed a script client side (bundled as pre script via the right click option Add pre/post custom scripts) to determine the conditions as to whether the client should install with an alternate configuration XML, you can rename the XML on the fly to the file name specified Modify command line
As for detection, it could be non-version dependent - just detect whether or not M365 apps are on system, regardless of specific versions.
I plan to hopefully at least test this idea soon. I would appreciate all your feedback on the idea above!
and also please add
<Product ID="LanguagePack">
<Language ID="en-us" />
<Language ID="fr-fr" />
<Language ID="de-de" />
<Language ID="lb-lu" />
</Product>
<Product ID="ProofingTools">
<Language ID="en-us" />
<Language ID="fr-fr" />
<Language ID="de-de" />
<Language ID="lb-lu" />
please start with current channel/latest version
any news? :D
This would be amazing!
@Adam - If there were entries for each channel and the latest version, couldn't the detection script just look at the registry for the channel and the VersionToReport key for the applicable version? This probably still requires you to have multi-file application support though, which I think I saw in another thread isn't yet supported.
I would definitely use this if it became a thing in PMPC.
+999
@Adam
I am thinking "different" applications for each support channel. I am interested in the "bare" install (autopilot) and would prefer it to be the latest version.
It would be nice with language customazion or if install language matches OS language.
/Mikkel
@Adam Cook - Would it be viable to have separate entries in PatchMyPC for each release channel of Office365?
Since all the support channels get monthly patches and change versions on a monthly basis, that would allow customers to choose the support channel they need while still allowing you to check for specific minimum version to enforce.
I've been thinking more about this and my next train of thought is about detection.
Since we can't detect standalone binaries which do not register themselves as installed products in Windows, we wouldn't be looking for detection of the ODT itself, therefore we'll be considering detecting Office.
Given the version of Office can be wildly different depending on which support channel the customer specifies in the config.xml, what's the ideal solution? Should we detect any M365/Office app with consideration for minimum version - just bare existence? This could be sufficient for initial deployments of Office i.e. during Autopilot, but could be problematic for customers expecting a exact or minimum version to be guaranteed/detected upon install.
Would the expectation be for us to maintain version numbers across all support channels of M365/Office in the catalogue? https://docs.microsoft.com/en-us/officeupdates/update-history-microsoft365-apps-by-date#supported-versions
I am currently using the same method for many customers via PowerShell. I deploy basically a config.xml and a install script to automatically get the latest ODT from MS and use that to install from CDN. Works very good. So if I could simplify this even more with having PMPC maintaining ODT and allowing me just to add a config.xml in Publisher for my configurations, I would most definitely use that.
I think it will be more relaible with the Office Deplyoment Tool (ODT). I have tested it by myself and it often works better than installing MS365 through Company Portal / Intune.
I hope you will support this.
PatchMyPC is better at the logging and the controls. We often have to re-deploy Office 365 especially when a user gets a visio or project license and the installs fail for various different reasons and they are hard to track. The CDN part does not bother me at all.
One of the struggles we will have with this is that we will only be able to use the Office Deployment Tool in our catalogue, and you will not be able to include the content by downloading the bits first. This is largely because today we only support single-file products/installers.
At that point, your devices will still be pulling content down from the CDN. With that in mind, is there still any value in having just the Office Deployment Tool in our catalogue, even though your devices will be downloading the content from CDN at the time of install?
Microsoft's way to deploy is very barebones and having some of the robust features that PatchMyPC has (conflicting processes, robust logging, post-install scripts, etc) would make the process much easier.