Back in May I started doing marketing work for SysKit, the folks that bring you fine products like SPDocKit. One of the things they asked me to do was to write a review of SPDocKit from the view of someone that uses it. They know I’ve been a big fan of SPDocKit for years, so I was happy to do it. This blog post is my review of SPDocKit, or at least the first part of it. I had so many things to say SysKit had to finally cut me off and tell me to publish the thing. I may follow this up with some more thoughts later.

Here it is, my review of SPDocKit.

I've been a SharePoint Administrator for a lot of years, the majority of my professional career. Over that time I've seen a lot of SharePoint utilities come and go. A few have grabbed me as being must haves, and SPDocKit is one of them. Since the first time I used it I knew how much value it provided the SharePoint admin, and with each update it's gotten even better. Today I want to walk you through a quick review of a few of my favorite pieces of SPDocKit and how you can put it to use for you.

One of SharePoint's biggest strengths, and why I think it has been so popular is how easy it makes things for the users. IT is no longer the bottleneck to adding functionality or getting things done. If a user wants to add someone to their site, they can. If a user wants to create a new list, library, or even subsite, they can. No waiting on hold with the helpdesk. No filling out a web form that they didn’t know existed. No bribing IT with a bag of candy. All without IT lifting a finger. A win for IT, a win for the user, and ultimately a win for the business. But it does have a cost…

SharePoint's greatest strength, putting power in the hands of the people, is also one of its greatest problems. Users don't care about governance, security, storage resources, any of that. They just worry about getting their job done. Unfortunately, sometimes that runs afoul of IT, and without IT knowing about it. Over the years IT departments have either been blindsided by this, when data leaked out, or drives filled up, or they’ve cobbled together solutions to keep an eye on it. I learned a long time ago what my favorite solution to the problem was, frequent doses of SPDocKit applied liberally to my SharePoint farms.

SPDocKit is a tool, conceived and inspired by SharePoint experts, that documents your SharePoint farm in stunning detail. That sounds pretty boring on its surface, no one likes documentation. But the folks at SysKit have taken SharePoint documentation to a whole new level. They’ve made documentation fun, and very powerful. Not only does it do an impressively thorough of documenting a SharePoint farm, it produces completely customizable professional looking reports that are useful to admins, and their bosses. Personally, I don’t think any SharePoint farm is complete without SPDocKit. It gives the SharePoint Admin a fighting chance of keeping up with the growth and proliferation of their farms.

The SPDocKit installation is a breeze. Don’t take my word for it, download a trial for free and walk through the install yourself. It’s right up my alley as a SharePoint admin that enjoys clicking “next” and “finish” a lot. You have the option to have SPDocKit store its results in SQL, and I recommend that. Since you’re documenting SharePoint you have a SQL instance at your disposal. Letting SPDocKit use SQL allows it to take advantage of SQL’s database engine to run queries and give you better information faster.

Another nice touch is that while SPDocKit caters to SharePoint admins, it also has an install mode for SharePoint consultants, such as myself. This allows me to run it on a customer’s farm without leaving it there afterwards. Features like this showcase how in tune the SPDocKit developers are with the people that use their tools.

Once you get SPDocKit installed you’re greeted with a very friendly page that shows you what tools are at your disposal.

There are a ton of great tools in SPDocKit, but the ones I use the most are in the top heading, Documentation and Configuration. This is where SPDocKit got its start and where it really shines, in my opinion.

My trips into SPDocKit on a new farm usually start with “Take Snapshot.” If SPDocKit had a weakness (and I’m not sure it does) it would be that it does too good of a job collecting data. It finds useful information in many dark corners of SharePoint, and in that can be overwhelming depending on how big your farm is, or what information you’re looking for. To help combat the potential information overload, SPDocKit has a couple of options for what is collected during a snapshot. The “Default” mode is a good place to start. That report runs pretty quickly and gives you a good overview of what snapshots collect.

As you get more familiar with SPDocKit you can fine tune what does and does not get included in the Snapshot. Choosing the “Custom” mode lights up the “Options” step, which gives you more fine tuning on what is and isn’t included in the Snapshot.

You can run Snapshots as often as you’d like. SPDocKit keeps track of them all. At any point you can look at any previous Snapshot. You can create a report from the Snapshot, or even more.

The obvious power of snapshots is to give you an easily consumable look at your farm at that moment. See how things are going, so you can address something if it needs it, or be proactive and get ahead of any problems coming down the road. SPDocKit does that with ease, but it takes it one step further. It allows you to compare snapshots over time, so you can also see trends in your farm.

The Compare Wizard can also compare two different farms, for instance, if you want to compare your Test farm with Production.

If you choose to compare two snapshots from the same farm you get a dialog box that lets you choose which two Snapshots to compare.

Once you choose the Snapshots, SPDocKit gets to work comparing them. After that’s finished, you got a dialog like the one below.

There are several results possible for each compared node. In the screenshot above, SPDocKit pointed out that the build number was different between the two Snapshots. The Snapshot taken before was running the April 2018 patch, 16.0.4678.1001. Some time after that, the farm was patched to the June 2018 patch, 16.0.4705.1000. If we drill down farther, we can also see there are differences in the site collections and content databases in the farm.

Reports

The place where SPDocKit really shines is with its reporting. As a nerd, it’s often tough for me communicate correctly with non-nerdy audiences. I get all excited about the technical aspects of something, and completely forget that not everyone else does. Sometimes I need help presenting in a way that can be easily consumed by my audience. SPDocKit lets me do this. It lets me see all the deep technical details of my farm, all the bytes of this, the users in that, but also lets me take that information, and distill it down to something that any CIO or other higher level person can look at and makes heads or tails of, without being overwhelmed by all the technical minutia. Not only does SPDocKit create easy to read, professional looking reports, it allows you nearly infinite customization options. This can be what information is reported, how deeply that information is reported, and even the style and colors used to report it. If your company has a particular color palette it uses, SPDocKit can make your reports match that. Want to put your corporate logo on the reports, too? Easy enough. And once you get the formatting exactly how you want it, you just save the template and SPDocKit lets you use that any time you create a report.

I fill pages with all the customization options you have, but I won’t do that. I’ll show you a couple and let you take SPDocKit for a trial run and explore on your own.

When you want to create a report, choose the Snapshot you want to report on and open it up. In the ribbon at the top you’ll see “Generate” in the Documentation area.

Notice “Customization” right next to that.

Choose the format you want your documentation in. I usually choose PDF, as that is easy to forward on to whoever I am reporting to. After you choose the documentation type I’m presented with a dialog box asking which Template I want to use. These templates let you pick what information is included in the report.

Like the default Snapshot, choosing the “Simple Documentation” template is a good place to start. If you change any of the objects reported, SPDocKit will ask you at the end if you want to save it. That’s how I created the cleverly named “Temp 1” template at the end of that list.

Once you’re satisfied that the information you want is in there, and the information you don’t want isn’t, click “Generate.” You’ll get the familiar Save dialog box where you can specify the name and location of your report.

SPDocKit will open the report for you after it’s been saved. It will probably be a lot of pages, so don’t be surprised if you don’t have to run the Report Generation wizard a few times to get exactly the right information. Here are a couple of screenshots of the report I ran on one of my test servers:

Here’s the Microsoft Word version of the same report, with a little color splashed on for good measure.

As you can see, for good or bad, you have a lot of flexibility.

I’ve run out of time for this blog post and I’ve only scratched the surface of what SPDocKit can do. There’s so much more to talk about. In an upcoming blog post I’ll gush over the other features that make SPDocKit such a great and indispensable tool.

tk

ShortURL: https://www.toddklindt.com/SPDocKitReview