The other day I was taking a look at Vlad Catrinescu’s blog on quickly creating a SharePoint 2013 dev farm. It’s a great blog and provides some good information on creating a dev environment much faster than you could ever do it manually. I like to develop in an environment as similar to the production environment as possible and I also have the hardware to do it. With this in mind I wanted to come up with a way to quickly build a multi-server SharePoint 2013 developer environment. The problem is that for a single server install you could be looking at hours to install and configure, a multi-server environment could take even longer. I set out to build scripts that would not only deploy the SharePoint environments but would also create the VMs, deploy Active Directory and SQL Server, and configure the network. In addition, I wanted to be able to do this more than once (as different environments are sometimes needed at different times).
So recently at my client site we had a report that was running incredibly long. This was a while ago, so unfortunately I can’t remember the run time, but I believe it was greater than 12 hours. The report was pretty basic, just a determination of which documents were created within the month and an output that displayed things like location, file name, created date and creator.
When reviewing the code I noticed the original solution had been coded to loop through each site in the web and then grab all the documents within a particular date range. The line in particular that scanned the documents was as follows:
var listAddedItems = listItems.Where(x => ((DateTime)x["Created"] >= reportManager.ReportStartDate && (DateTime)x["Created"] <= reportManager.ReportEndDate) || ((DateTime)x["Modified"] >= reportManager.ReportStartDate && (DateTime)x["Modified"] <= reportManager.ReportEndDate));
Pretty straight forward, but what it’s actually doing is going through and gathering all the data and throwing out what you don’t need. Not a big deal unless you are working with a lot of data. Right now we are sitting at around 1 million items in our SP farm. I think I found the culprit.
I have seen over time that new users have asked about reporting in SharePoint. Usually it is in a forum post which isn’t always the best place to provide an answer as the answer can be quite detailed, so I decided to do a write-up and if someone asks, I can direct them here instead of re-writing in a medium that isn’t quite as nice for the requirements of the answer. Not only that, I have seen blog posts with posts that are only about one report and not about any of the others. I would like to discuss all the OOTB reports in one place so anyone looking can find them all. This isn’t going to be anything new or cutting edge for the experienced SharePoint user. It’s intended for the person that is new to SharePoint or looking for basic info on SharePoint.
To put it bluntly, SharePoint doesn’t have a lot of OOTB reporting. You aren’t going to find a lot of user reports or detailed usage logs within SharePoint. Microsoft provides methods to build reports, but doesn’t provide a lot within SharePoint itself. Companies like AvePoint, Share-Gate and Metalogix have provided user teams with much needed reporting, but we are here to talk about what SharePoint gives you OOTB.
This month I traveled to Saskatoon, Edmonton and Calgary to present on the Leading Practices of Planning and Implementing a SharePoint Environment. This was not meant as a technical discussion, but instead a discussion on implementing a SharePoint environment. There is a bit of technical topics within it, but the focus is how to plan out your entire project to get the best SharePoint implementation you can. I had a lot of great discussions and questions from everyone that attended and really enjoyed myself. I promised everyone I would post my slide deck so they could reference it and use it should they choose to.
I would really like to thank the Saskatchewan SharePoint User Group, Edmonton Microsoft User Group, and the Calgary SharePoint User Group for hosting me for these presentations. I really enjoyed myself and hope to return soon with another presentation. I would also like to thank Solvera Solutions for making this all possible as well.
As promised… the slide deck.
So your SharePoint list or perhaps lists are very slow to response or a custom solution that accesses your lists takes a long to complete its processes. What could be the problem? Old, dilapidated hardware? Poor database configuration? Slow network? How about the fact that many SharePoint solutions are designed as if they are a relational database.
After a long hiatus, I would like to start things off with something I brought forward to one of my clients the other day. Even though SharePoint looks like a fantastic place to build easy database solutions (like a replacement for MS Access) it simply is not built to do that. To the user SharePoint lists look completely separate from each other. So why can’t we simply create DB table like lists and have them reference each other, like having columns that are basically foreign keys to other lists just like a DB table?