The implications of Office 365

Microsoft have released Office 2016 via the 365 ‘service-based’ offering and touted this to enterprises as the ‘quick and easy way to consume the new features’.

Having worked with the product, we were surprised to find a few things not quite obvious:

  • Its VERY different to deploying Office 2016 or select media – this is a new model/paradigm, not JUST a licensing wrapper on the product.
  • Office 365 subscription is either 2013 or 2016 (people keep talking about 365, but they rarely clarify…)
  • The other crucial item, is Office 365 is essentially a client-less App-V.
    It’s not an App-V you can mount and publish, but it sure doesn’t install into Program Files (x86)\Microsoft Office\Office16 either… – That’s Office 2016…
    As such, it isn’t quite as ‘integrate-able’ as one would expect – sure the common FTA’s, ProgIDs and other usual entry points are exposed to the client as you’d expect.  This means there’s no issue with code calling Word.Application, .doc, or the other basic examples.
    BUT: if your bespoke business application relies on other bits of ‘the common Office guts’, (but not necessarily ‘Office’ such as MSComCTL.OCX, for example), you’re in for some investigation if you weren’t aware of this dependency…

While there are multiple plans for SharePoint and Exchange add-ons, there didn’t appear to be anything less than Proplus – You don’t get to granularly control features (*during deployment*) like you could with earlier editions, assuming you wanted to apply an MSP to control feature states.  Its just waaay easier to deploy the lot – turning on Access and Publisher after the fact isn’t trivial…