Friday, January 29, 2016

Error on Open document from Office 365 in local Office 2010 client

We are preparing for a transition to Office 365. Current we’re conducting analysis steps to identify steps and potential issues. We use a trial Office 365 tenant subscription. Today I encountered an issue that when trying to open in native Office 2010 client (current still the Office standard in our company, installed on all client machines) a document administrated in SharePoint Online, the Office application structural aborts. E.g. in Word 2010:
In EventViewer, the following information is logged
Google (your friend, certainly that of myself...) referred to me a potential related information source: Set up Office 2010 desktop programs to work with Office 365 for business. However, the installation of that Office 365 Desktop setup itself fails on my laptop. So for now I'm stuck with this. Checked with some colleagues, they also experience the issue. Will contact Microsoft to inquire whether this is a known-issue / problem.

Tuesday, January 19, 2016

Approach for inability to rollback an AddIn update

Our SharePoint governance prescribes to include in the runbook of any change to our SharePoint environment, the steps to roll back the change in case of unexpected issues. However, as we experienced, technical rollback to previous state is not possible for AddIn (former: SharePoint Apps) update. The AddIn framework does not support to remove/downgrade the AddIn update, and return to the previous version of installed AddIn as active version. The only option is to re-deploy the version previous to the update; but for this to succeed that previous version must be changed to receive a version number later than that of the failed AddIn update. This approach is only possible for company-build AddIns, but not feasible for purchased AddIns. And from purist perspective it is undesired, as it is not a removal but a compensating rollback to return to previous state of working AddIn. While technical still a change is executed in the environment: the updated AddIn remains deployed, and the previous AddIn version is installed twice, last time with increased version number to force the AddIn update to be executed.

Mitigation approach

To cope with the unavailability of a pure rollback for AddIn update, we instead apply a procedural approach to minimize the likelihood of failed AddIn update. In an isolated subsite, that is non-accessible for regular end-users, we prepare the same installation status of the AddIn we intend to upgrade. In the change runbook, we start with upgrading the AddIn in the isolated subsite, and validate the functionality there for the production environment. Only in case the validation succeeds, we continue with deployment of the AddIn upgrade in the production hostweb(s) to which end-users have access. And in the undesired situation that the validation fails, we stop the deployment, and only need to cleanup by removal of the isolated validation subsite.