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.
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 stuffed.
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. While 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.
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.
5 thoughts on “Observations on Office 365 – Part 2”
Has there been any changes in being able to deal with list view thresholds recently in O365? I’m trying to figure out a way of allowing users to download items from a library >5,000 items in bulk. However Explorer View is now broken and Workspace/One Drive are not equipped to deal with large lists. Annoyingly the library field I’m trying to filter by isn’t indexed so using CSOM has proved wasteful. IS there a way of using the ContentIterator class in O365?
Gah! No, there’s not one that I can see. Office 365’s inability to deal with large lists is, in my opinion, a major issue.
All I can say is complain to Microsoft until they give us a mechanism for setting this. It’s driving me bonkers too.
Oh, and the ContentIterator is good – but server-side and there’s no server side code in SharePoint Online.
I’ve had numerous calls with MS support over this and in most cases they know their product less than us, it takes me at least 2 to 3 people before I get someone that can explain to me what we already know. There’s no point asking them about code solutions either. Clearly the support call centres don’t include devs. AvePoint have a tool for SharePoint Online that allows us to get around making list changes (permissions, indexed columns etc.) by restoring content to new libraries which you can set up properly from the outset. However I still need to be able to filter these large libraries by a Managed Meta-Data column which isn’t indexable so I’m still screwed, unless we look at redesigning the library to use Lookup columns instead, effectively losing us the Managed Meta-Data Navigation tree….. I can’t win!
Oh by the way, a heads up on Key Filters and Grouped results sets. This still doesn’t work in O365 yet, I’ve submitted it as a bug but MS support reckon it’ll be 8 months until the fix is done and incorporated in to customers sites!
Hmm. What is needed from those views? Is there a way Search could be leveraged to show that content instead? I mean, search is much more scalable – albeit with the latency issue too, and you’d have to develop it yourself – but if the right properties are available in search, that might be an approach.