How to Dig Deeper Into Your SharePoint Farm

close up macro sand 99576

Last week I talked about things you could do to spend your nervous energy while you wait for those tasty SharePoint 2019 bits. This week I thought I’d expound a bit on one of my suggestions.

Today I’ll cover my first suggestion, “Get The Lay Of The Land” in a little more depth.

Free SharePoint Discovery

No one sets out to be a bad SharePoint admin, or to have a bad SharePoint farm. It’s one of those things that happens gradually when you’re not looking because you’re busy with the 1,000 other fires going on in your organization. The printer won’t print. The phones are down. Someone can’t watch the newest virile funny panda video. These are the kinds of things that pop up when you really wish you could be learning more about SharePoint. Between that, and SharePoint and the guidance around it changing as time goes by, things can really get out of whack.

While you should also be vigilant about these things, planning for and executing a migration or upgrade is a good inflection point. These events help move the “SharePoint care and feeding” part of your job from the Important column, to the Urgent column.

So how do get your arms around this seemingly Herculean task? It’s like the old saying goes, “How do you eat an elephant? One bite at a time.”

When I do SharePoint discovery tasks, I first break them down into two general areas; farm architecture and information architecture. The first, farm architecture, deals mainly with the nuts and bolts IT Pro aspect. Servers, service apps, patch levels, databases. All that ooey-gooey behind the scenes stuff. It’s important to know where this is as you plan out your upcoming SharePoint 2019 farm. Knowing you have 2 web front ends now and they’re running at 80% CPU all the time lets you know that SharePoint 2019 will probably need more. But if those same 2 WFEs are puttering along at 20% maybe the same resources would handle SharePoint 2019 just fine.

This is also a good time to look at other parts of your farm architecture, like your content database layout. Content never grows the way you want it to and after a couple of years, database balancing has gotten out of whack. You may have 20 1 GB content databases and a monster 350 GB content database. And if you have multiple chefs in the kitchen, you may have content databases you don’t know about.

So how do you get all of this information? I have a couple of different methods that I use for customers. The first, and the least polished approach, is PowerShell. Raw, unadulterated PowerShell. I use PowerShell cmdlets to get information from the various nooks and crannies of SharePoint that I think are important to the farm I’m working on.

Unfortunately, that can be a problem because of the things Donald Rumsfeld so eloquently referred to as the “unknown unknowns.” The purpose of this is to find out where things are, so you should look under every rock, seek out those unknown unknowns. Since they’re unknown, it’s tough to know where to look. One tool I have used in the past is a PowerShell script Microsoft published for this very purpose, Document farm configuration settings in SharePoint Server. This article has one of the biggest, and ugliest, PowerShell scripts I’ve ever seen. If I didn’t know better (and I don’t, to be honest) I swear someone just created this script by running Get-Command Get-SP*.

This script essentially runs all of the SharePoint cmdlets that start with “Get” and splats the output into a gaggle of XML files. The good news about this approach is that even if you didn’t know you were using Visio Services, this script will look and give you your configuration. The unknown unknowns are now known. The bad news is the output is about as tough to read as my handwriting.

Normally when I run this, I run the parts I’m most interested in and skip the rest. But this is a good thing to run, first in a test environment, to see what it can give you.

This script is a good starting point, but it leaves a bit to be desired and I’ve had to augment it with bits of my own PowerShell. For instance, it doesn’t give site collection size, which is important. You can get with this PowerShell snippet:
Get-SpSite | Foreach-Object{$c=0}{ $c += $;$_.url + ” – ” + ($}{Write-Host “Total storage =” ($c/1MB)}

Another useful piece of data to know is how large your various databases are. The Microsoft Script doesn’t retrieve that either. Here is a bit of PowerShell to get you started with that:
Get-SPDatabase | Sort-Object name | Format-Table Name, @{Label =”Size in MB”; Expression = {($_.disksizerequired/1MB)}}

Another downside of the Microsoft script is that it doesn’t use the “-Limit all” parameter on the cmdlets that need it, so make sure you go through the output and make sure everything is there. It also only gets the default properties for each object. You may need to put some extra properties in with Select statements.

Pretty SharePoint Discovery

As a guy that has worked with Microsoft products my whole career I have often heard and repeated the phrase, “Linux is only free if you don’t value your time.” Meaning that while you can download and install Linux for free (as in beer) it takes a lot more fiddling than Windows does. If you have more time than money, Linux is probably a good fit. If not, it might not be. I look at this PowerShell script the same way. It’s free, but only if you don’t value your time. It’s very clunky to use, and it’s even tougher to get a report out of it that you can show to anyone else. If time is tight, or if you have management that eats up these kinds of reports, then I recommend springing for a professional SharePoint documentation tool. These tools do all of the heavy lifting and give you a pretty report at the end. They’re both workhorse and show pony all in one.

There are a lot of players in this field and I haven’t used them all, so I can’t speak to each of them. If you’re already using some tools by a vender and they have a discovery or inventory tool, you should start there. Their tool will likely integrate best with your current environment and it will hopefully cost you less because your vendor will offer some sort of bundling price break.

If don’t currently have an affinity towards a specific tool, I can recommend two of my favorites, ShareGate and SPDocKit. In the spirit of full transparency, both companies have given me products and swag over the years, and I currently work for SPDocKit in a marketing capacity. Both tools were written by companies that love SharePoint, and do a great job getting valuable SharePoint farm information in a way that is useful and easily consumable. If you’re serious about your SharePoint farm, these tools are a good investment.

While this week’s column mostly dealt with farm architecture, both of these tools hit the information architecture too. They will report the site collections and webs you have, as well as who uses them. To drill down into some of that extra information in the free Microsoft Script you’ll need to uncomment out the last two lines of the script. In later columns, we’ll cover the information architecture part of your farm and how to see how SharePoint is being used. They dig pretty deep, so run them on a test farm first.

Whether you are currently planning to do a SharePoint upgrade or migration, or whether you’re holding back to see how SharePoint 2019 shakes out, knowing what’s in your farm is valuable information. Using either the free PowerShell script above or one of the pay tools you can keep an eye on your farm and correct problems as they show up.