Following on from customer related issues in Office 365, there are a number of technology issues that give me concern. I will caveat this that this is based on my last project, and by the time I write this the Office 365 SharePoint platform could have changed to address some of these problems.

Technology Issues

No options for dealing with Query Throttle Exceptions. Consider this – you’ve been using a list for a while, and have lots of useful data in it. Suddenly, some of your views start to return Query Throttle exceptions. You’ve just tipped over the magic 5000 items limit in a large list. What do you do? Well, in normal SharePoint you’ve a number of options, the main one being to create an index or indices on the list so that your queries can be more efficient, and thus avoiding throttling. However, that action is itself throttled – so you’d have to either a) get a Farm Admin to do it, or b) have to define a “happy hour” window late at night when throttling was turned off, and add the index during that window.

The problem is that neither of these options are available in Office 365. You don’t have a Farm Admin, and you don’t have a happy hour. One might expect that you could raise a ticket with Microsoft and that their support would be able to add an index for you – but we (or rather, our customer) tried this, and Microsoft said that they couldn’t. Essentially, if you’ve not got your design exactly right and you want to make changes to a list that contains 5000 items or more, you’re fucked.

As this includes changes like ‘Adding a new column’, which isn’t that rare an activity, this is a show-stopper for me. Hopefully Microsoft will introduce some approach for dealing with this.

Search Latency in SharePoint Online can be very long. I blogged about this previously, and I still don’t think that your typical business user would expect to wait 8 hours for new content to get indexed. I mean, in an on-prem SharePoint system the Continuous Crawl kicks in every 5 minutes – that’s more like the timescale we need. Worse, this compounds the problems with large list queries described above, as it makes it difficult to use the Search Service (which is probably better suited to that kind of query) instead.

Browser Support. Office 365 will no longer supports Internet Explorer 8. This is unfortunately, because although IE8 is junk, it is still used by a lot of our customers. In short, they’ll lose the ability to not upgrade their browsers for years on end. (I might rejoice, but from their point of view it’s an expense with little benefit).

Logging and Fault Diagnosis. Essentially, Office 365 doesn’t have any. Take a moment, and read that again – Office 365 doesn’t have any logging for fault diagnosis. There is a PowerShell API for retrieving log information from SharePoint Online’s logging service – but the only thing that writes to the log is Business Connectivity Services.

It’s possible that Microsoft have more access to logs than we do – I did wonder if the issue is that all customers sharing a tenant machine would be able to read each other’s ULS log entries – but the point remains that we have very limited logging information to go on. Mostly, it’ll just be the standard error message “An exception has occurred”. Great.

Reliability. Which developing with SharePoint online I found I was getting more errors than I’d expect to see. For example, when migrating documents using the client side object model, I would occasionally receive errors like “The server did not respond” which I don’t expect to see normally. Browsing around was similar – you’d occasionally get “Server did not respond” errors. And sometimes I’d see weird transient errors that I couldn’t repeat, such as problems changing the appearance of a site. Now, these problems might not be due to the platform itself – I sometimes question our Internet connection – but still, reliability was worse than having our own server on the same network.

No easy way to do ‘Timed Jobs’. You know how it is, sometimes you just want to be able to perform a timed job for something. For example, it might be ‘Archive completed tasks and the end of the month’. There’s no easy way to do this, though. I’ve had a play with using Azure Scheduler to perform such actions, and it kind of works – but it was hard to get working, and password expiry breaks it. I really miss timer jobs.

Unconvinced about Apps. To be honest, that could be a post of it’s own, so that’s what I’ll do.

Conclusion

I suppose my conclusion is simply that there are a number of issues with running SharePoint Online projects, and I might not rush to do too many projects in it. In particular, the lack of ways of handling the Query Throttle, and the surprisingly long search latency are, to my mind, major issues. SharePoint online might still be a good way of doing your project – but caveat emptor.