Patch My PC Feature and Application Request

A community where customers and the community can provide feedback to make a better product for everyone! For more details on how we prioritize request, please see:

83 Vote

Add Office 365 Apps

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!

  • Guest
  • Feb 12 2021
  • SUBMITTED
  • Attach files
  • Claudio Mendes commented
    29 May 12:34pm

    we are now also testing the intune integration… we need this now ^^

  • Justin Blocksom commented
    12 May 08:52pm

    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

  • Nick Wiley commented
    15 Apr 01:29pm

    Yes please! Standard 365 Apps in Intune is flaky, to say the least.

  • Claudio Mendes commented
    5 Apr 06:50am

    maybe also add a sample base pmpc xml? i'm available for testing purposes ^^

    <Configuration>
    
    <Add SourcePath="\\patchmypc\Applications\Microsoft\Office 2019\x64" OfficeClientEdition="64" Channel="PerpetualVL2019" AllowCdnFallback="TRUE" ForceUpgrade="TRUE">
    <Product ID="ProPlus2019Volume">
    <Language ID="en-us" />
    <Language ID="fr-fr" />
    <Language ID="de-de" />
    <Language ID="lb-lu" />
    </Product>
    <Product ID="VisioStd2019Volume">
    <Language ID="en-us" />
    <Language ID="fr-fr" />
    <Language ID="de-de" />
    <Language ID="lb-lu" />
    </Product>
    <Product ID="ProjectStd2019Volume">
    <Language ID="en-us" />
    <Language ID="fr-fr" />
    <Language ID="de-de" />
    <Language ID="lb-lu" />
    </Product>
    <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" />
    </Product>
    </Add>
    <Property Name="PinIconsToTaskbar" Value="FALSE" />
    <Updates Enabled="TRUE" />
    <RemoveMSI />
    <AppSettings>
    <Setup Name="Company" Value="Patch My PC" />
    </AppSettings>
    <Display Level="None" AcceptEULA="TRUE" />
    <Logging Level="Standard" Path="%temp%" />
    <Property Name="FORCEAPPSHUTDOWN" Value="True" />
    <Property Name="AUTOACTIVATE" Value="1" />
    </Configuration>
  • Claudio Mendes commented
    1 Apr 09:16pm

    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.

  • Admin
    Adam Cook commented
    1 Apr 08:04am

    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!

  • Claudio Mendes commented
    31 Mar 07:43am

    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" />

  • Claudio Mendes commented
    31 Mar 07:24am

    please start with current channel/latest version

  • Claudio Mendes commented
    18 Mar 12:50pm

    any news? :D

  • Guest commented
    23 Feb 08:49pm

    This would be amazing!

  • Chris Kibble commented
    1 Feb 05:53pm

    @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.

  • Claudio Mendes commented
    2 Nov, 2021 09:59am

    +999

  • Mikkel Elgaard commented
    20 Sep, 2021 06:09am

    @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

  • Juan Pablo Vanegas commented
    17 Sep, 2021 02:56pm

    @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.

  • Admin
    Adam Cook commented
    17 Sep, 2021 02:17pm

    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

  • Jan Ketil Skanke commented
    7 Sep, 2021 01:19pm

    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.

  • Mikkel Elgaard commented
    7 Sep, 2021 12:20pm

    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.

  • Joe Alonge commented
    7 Sep, 2021 11:40am

    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.

  • Admin
    Adam Cook commented
    7 Sep, 2021 10:55am

    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?

  • Guest commented
    21 Jul, 2021 07:36pm

    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.

  • +35