18 Things for a new SharePoint Administrator

Are you a new SharePoint administrator?

Are you a developer who’s also responsible for your SharePoint farm?

Are you an IT person who’s been put in charge of the server side of SharePoint?

You’re in the right place.

My Name is Jack Fruh, and I’ve been a SharePoint administrator at a Fortune 500 company for the past few years. My company didn’t own any tools for managing SharePoint, doing migrations, really anything. In my time there I’ve written or collected different scripts, open source tools and knowledge about how to manage a bunch of SharePoint Farms.

This article is here to help you if you are new to administering SharePoint – it won’t cover all the scripts on this site, instead it focuses, in order, on a few key things you can do to in your first days as a SharePoint Administrator. It should be noted that this is intended for people who have access to the SharePoint server – you should be able to log into the server remotely, and you should know the user ID and Password for the “farm account”.

Scripts 1-8 Do these TODAY

#1 – Print the PowerShell Cheat Sheet and put it on your desk/wall/refrigerator/etc.

This is perhaps the easiest of things you can do here today- download the PDF & print it out. It has all the basic mechanics of PowerShell, in a very short 3 page document. It also has the URL of this site so if you do nothing else today, at least you’ll be able to find your way back here later.

(Update, it’s now a 6 page document, 3 SharePoint specific pages have been added)


If you’ve never used PowerShell as it relates to SharePoint, here is a (very) quick primer…  1) You will log on to the server with remote desktop. 2) You will look for and run something called “SharePoint 2010 Management Shell” (this is just a regular PowerShell window, that preloads the SharePoint snap in) Note that it’s possible you’ll get an error that says you can’t access the farm, this means you’re ID is not setup properly for using powershell with SharePoint – find the farm account ID and password, and log in with that, If you’re super security conscious, you can use that account to grant yourself the needed rights, but doing that is not in the scope of this article


#2 – Confirm you have Database backups of all the SQL DB’s that power SharePoint.

SharePoint stores all it’s content in “Content Databases” – It is critical to get these backed up, daily. Sure there are other databases that are important too, but if you do nothing else, make sure the content databases are being backed up. Most companies have a DBA that manages/guards the SQL Server, so you may want to run GET-SPCONTENTDATABASE and give the output to your DBA for confirmation.  Also note that it’s possible to kick off some backup jobs from Central admin but you have to be careful – If you’re environment is using 3rd party tools like K2, Nintex, Newsgator, etc.. it’s very likely that the central admin backup will Not backup those.  Anyhow in your second or third week on the job you can dig more into backups and such, but for now,  at least make sure the content databases are backed up (if more is being backed up, that’s great too)

#3 – Export all the WSP’s from your farm.

If you ever need to rebuild the farm from scratch, you’ll want a copy of all the sharepoint solutions that were installed -these are stored in WSP files and getting a copy of them is so easy, that it just makes sense to do that now. As a side note, this might also save you a ton of headache if you ever deploy newer WSP’s and things don’t go so well – you’ll wish you had a copy of what was on there and working.


Get-SpSolution | forEach-Object {

Note: this only exports “normal” WSP’s – Sandboxed WSP’s are not covered by this.

#4 – Make a backup of your inetpub directory

Specifically your web.config files from all your SharePoint sites – I don’t have a fancy script for this, I just went in and grabbed a copy and put it somewhere else – don’t make the backup in the same directory! Why? In SharePoint, in Central admin, under System Settings->Services On Server, if you happen to Stop the service called “Microsoft SharePoint Foundation Web Application” It will de-provision every SharePoint site from IIS, which deletes not just the web.config, but also all the files in that folder, taking with it your precious backup. And if you were to just “start” that service back up? It puts in a default web.config that’s very likely to be missing key pieces you need to make the site run. There are likely other times you’ll want to have this backed up so go do this now, I’ll wait…

#5 Enable versioning on every list and document library on your farm.

I’ll assume you are using SharePoint 2010 SP1 or greater, if so, you have some awesome self service recovery options built right in – the Recycle bin is great for restoring deleted documents, and versioning is great for recovering a document that hasn’t been deleted, but has been overwritten. The script to do this is pretty long so I’m not going to copy it all here, but follow the link and put a scheduled task on your SharePoint server to run this on a regular basis (You will need to run it as the SharePoint farm account, or an account with access to the farm. If you have more than one server, you’ll only need to run it on one of them. If you have more than one FARM, you’ll need to find one server on each farm to run it on.)

(Note, that the script in the article above has the lines that actually turn on versioning commented out – you’ll want to run it a few times first and understand it before enabling those. (But don’t worry, it’s easy))

#6 – Capture basic user permissions so you have a record in case some one messes up.

The most common problem here, is that a user with enough rights hits the “inherit permissions” button, which resets the permissions on their website and often leaves them unable to do anything. When this happens, it’s nice to have a way to verify that they were the site owner before this happened, and icing on the cake is if you have a full record of what the permissions were before.

There are expensive tools on the market that do this, and they probably do a great job, but for my needs, grabbing a basic list of who had rights was all I needed – note that the script below doesn’t actually write out permissions – it just writes out who has access and what groups they belonged to – since most SP groups have names like Marketing Owners, Marketing Visitors”, etc… it’s pretty straightforward to set the permissions. If you need to capture item level permissions, then this script isn’t for you (But it is better than nothing and will take under 30 minutes to test and get scheduled)


#7 – Record the IIS bindings and backup SSL certificates from your web front ends.

A lot of what happens in IIS is automatically setup by SharePoint, but a few things are not – mainly IP Address bindings and SSL certificate associations. It’s good to have this documented, and to have an exported copy of your SSL certificates in case you ever need to rebuild things.

I’ve not written an article on this yet, but don’t let that stop you, log on to IIS on each server in your farm and have a look at the Bindings (ie what IP address each site is answering), and jot it down somewhere. While you’re at it, it might be a great time to run IPConfig /all and confirm that each IP on the machine is actually being used.

Article needed

#8 – Install a monitor to let you know when SSL certificates are going to expire.

SSL certificates that expire are always embarrassing so wouldn’t it be great to have a way to get notified when they are about to expire? (You’ll want to schedule this to run once a week on one of your web front ends)


Make your life easier:

These tips will make your life easier as a SharePoint admin.

#9 – Use Microsoft’s free “Remote Desktop Connection Manager”

While you can certainly use the built in remote desktop client to connect to servers one by one, Using Remote Desktop Connection manager makes sense for a lot of reasons – you can put all your connections in one place, group them by environment, add descriptions and even save credentials so that remoting into a server is just a few clicks away.  It’s especially handy if your servers have hard to remember names. (note, version 2.2, from way back in 2010 is still the latest version, and it’s still 100% awesome)


#10 – Use Password Safe

An Enterprise SharePoint farm might have 5-10 different accounts associated with it. If you have Dev, QA, Stage and Production, you could have 20-40 different user ID’s and passwords to keep track of. Password Safe is secure, free and allows you to store passwords, grouped any way you want – so for example you can put all the Dev accounts in one group, QA in another, etc…  Another great thing about password safe is that you can copy a password to the clipboard, without ever actually seeing the password – this is great if you need to log into a machine and have a user sitting over your shoulder watching.

Password safe for Windows is free and open source: http://passwordsafe.sourceforge.net/

There are also variants of Password safe for Mac, Linux, your iPhone, Android Phone or Windows Mobile Phone, etc…

#11 – Use a SharePoint warmup script

SharePoint, which uses .net on top of IIS, suffers from a “Slow first launch” problem – the first time you access a site – .net does a bunch of “just in time” mumbo jumbo, that slows your site to a crawl. If you’ve ever logged into central admin and had to wait 60 seconds or more for it to come up, you’ve experienced this.  The easy solution to this, is to have a script access the site every 15-30 minutes this way the site is always loaded in memory and ready to go.

I used this script from codeplex, but there are others.

I hate to admit this, but I ignored doing this for over a year. Every time I went into Central admin, it felt like I had to wait. Worst yet, the first user of the day had to wait. Who was the first user of the day? Well,  it was our CIO – not a person you want waiting around for the system you manage…

#12 – Inject yourself as a site collection admin into every site collection in your farm (Including all your mysites)

Nothing worse than getting a call from someone wanting help with SharePoint, and you don’t have access to their site. Sure you can go into central admin and put your name in there, but it only holds two names, so if you have a team of 3 people, that’s not good enough. The script below lets you add as many people as you want to the Site collection administrator group of each site collection.


Note that you can basically do the same thing by altering the web policy on the web application from central admin, by giving yourself full control.  I can’t think of any pros/cons of one approach over the other, unless you wanted to somehow grant someone site collection admin to every site, minus a few – in that case, doing it in central admin would be a no-no, and you could use the above script, with some additional logic to ignore specific sites.

#13 – Connect to all your servers as your admin account at one time with PowerShell

It’s a good practice to have two windows ID’s – one for yourself and one for the admin work you do, that way you’re less likely to make accidental mistakes.

In my enviornment, my admin ID has access to over 40 different servers. But when I log in each day at my desk, I log in with my non-admin account.

When it comes time to patching or copying files to a bunch of different servers, typing in my admin account and password gets old pretty fast.

This script will log in your admin account to as many servers as you’d like – once conected, you can go right to them without entering any credentials. A big time saver.

For those  of you who remember your Command line commands, it basically does a net use \\server /user:domain\user in a loop for each server you put in a list.


#14 – Use scripts for WSP deployments

If you EVER have to deploy WSP’s that your developers provide, you will save yourself HOURS of time if you have them provide you a deployment script along with the WSP.

There are a few ways to go about this.

Nik Patel wrote a mother of all deployment scripts script, which is available here.

Nik’s script is awesome and we use it at work, but it took me a while to wrap my head around, so I created a ‘simple’ script to redeploy a WSP- it’s not as sophisticated as Nik’s but it’s much simpler.  I’ve even got a 7 min video that explains it and shows it in action.

My “Simple” script and video can be found here:  http://sharepointjack.com/2013/a-simple-powershell-script-for-redeploying-a-sharepoint-wsp-solution-file/


#15 – Watch Todd Klindt’s weekly netcast

Todd is a well known author and speaker in the SharePoint community. He runs a weekly netcast – you can watch it live or download it from itunes. More info at his website

#16 – Follow Wendy Neal on twitter.

Wendy retweets a ton of SharePoint related stuff – if you’re only going to follow one person, Wendy’s a great one to follow, as you’ll get coverage of all the important SharePoint related news.  https://twitter.com/SharePointWendy

#17 – Print this list of virtual file paths in SharePoint


This is a list of some common “Virtual” file paths – these are files that you can access anywhere.

IE, links for changing the master page, viewing all site content, etc. Many of these have links, but there are times when the links don’t work – for example if someone hoses the home page of a site collection, you can still use /_layouts/viewlists.aspx to get to the pages library and set a new home page.

#18 Tip: How to flush the SharePoint timer service cache.

The SharePoint Timer service is that windows service that runs on each machine in the farm – it’s job is to query the DB looking for work – this could be WSP deployment jobs, or it could be  “timer jobs” or whatever.  The timer service uses a cache and sometimes it gets confused, and clearing the cache will help the issue.

Note: I’ve personally seen this fix issues on more than one occasion, I’ve not (yet) seen it cause any harm if done properly.

The article below shows the steps for manually clearing the cache, and also has a link to a script that will automate it across all machines in a farm.


#19 Tools to make the ULS logs easier to work with

David Hendry noted in the comments the omission of the ULS Log Viewer – Thanks David!

There’s a great tool called the ULS Log Viewer, which makes reading ULS logs MUCH easier!
You can get it from http://www.toddklindt.com/ulsviewer

For more info and other ULS tricks see this post:


That’s All (for now?)

Did I miss anything? Do you have a tip you think should be added to this list? Drop me a note in the comments below and let me know!



6 thoughts on “18 Things for a new SharePoint Administrator

    1. Thanks David!
      I’ve added a 19th item (while keeping the title the same so as not to confuse anyone)
      I’ve also added a blogpost about the ULS logs with a few other tips – thanks again for the suggestion!

  1. Great post! Only thing I would change is telling them to use ULS log viewer for Correlation id’s, and change it to using the powershell for it. get-splogevent -starttime get-splogevent | ?{$_.Correlation -eq “”} | select Area, Category, Level, EventID, Message | Format-List > C:\correlation.log

  2. Awesomely sweet post! Thank you very much. The links to the scripts in the #1 are returning page not found errors. Do you have these located elsewhere?

Leave a Reply