How to remove an Office 365 component RRS feed

  • Question

  • With office 2010 and office 2013 you can pass a configuration file to the setup.exe to instruct the installer not to install certain office components. for example to remove the Access component you would specify a line like this in the config file

    <OptionState Id="ACCESSFiles" State="absent" Children="force" />

    it seems like there is no way to do this with Office 365 click to run products, we don't want all of our users to gain access to all of the components within office because we have big problems with users incorrectly creating Access databases and Publisher files and InfoPath files, these types of files we consider as being for more advanced users who know what they are doing with those products.

    how can we block access to using Access, Publisher and InfoPath from the click to run products - most preferably without having to deploy applocker policies, or is this the only way to do it?



    • Edited by Milkientia Monday, February 25, 2013 2:27 PM
    Monday, February 25, 2013 1:18 PM

All replies

  • Hi,

    According to the following article, it seems there isn't a Product ID for installing individual Office features of Click-to-Run version:


    If the edition doesn't meet your requirment, ask Office 365 team to see if we can switch to MSI-based edition:


    Best regards, 

    Rex Zhang
    TechNet Community Support

    Tuesday, February 26, 2013 3:44 AM
  • unfortunately I am unable to ask the question of "if I subscribe to an Office 365 plan can I use an MSI based installer to deploy Office" in the office 365 community link you posted as I have not yet subscribed to Office 365, my question was based on very very early testing of the click to run product, I haven't even signed up for a trial yet to office 365. I have a feeling I already know the answer though, I suspect you have to be a volume licensing customer to use the MSI based installer, and that office 365 will always use a click to run installer.

    Tuesday, February 26, 2013 9:50 AM
  • Just in case anyone might find this useful, during my testing phase I implemented the following which seemed to work for me to disallow access to certain O365 components.

    Create a GPO which uses User GPP and Computer start up scripts. The GPP will remove the shortcuts and the start up scripts will install an ACT  Database with AppHelp messages. These AppHelp messages will disallow the application to run passing it off as a "compatibility" issue, and that's assuming the user can get to the exe file after the shortcut has gone.

    Create a GPP Folder Options – File Type which re-associates the extensions for the blocked app with another application or removes the extension.




    any or all of those steps could form a solution as far as I can tell. I know this appears a pretty botch job but its the best I can think of, app locker policies could be used but personally I have never been a fan of implementing such restrictions. Although this method doesn't actually remove the components it could block access to it, and if you're really clever you could turn this into a "user" focused scenario rather than a device based one, adding the shortcuts back and uninstalling the app help messages depending on what user logs into the machine (for a hot desking environment for example) this gives a better solution than an MSI deployment where the component is completely removed from the machine which of course would increase network traffic and time to reconfigure the product to add it back based on the user who logs in.

    Talking of blocking access ... maybe a script that adds the user to the deny ACL for the exe.... bit crazy and too far? probably is.


    • Edited by Milkientia Thursday, March 21, 2013 4:36 PM
    Thursday, March 21, 2013 4:34 PM