I work on a small but mighty team of 2. We support 3 production SharePoint on-prem farms and numerous other non-production farms to support them. It wasn’t always like this – in fact we started out with 1 farm, but our simple environment soon morphed into more due to project work, migration projects, and timing of corporate initiatives.
My role is to install/configure/maintain the SharePoint infrastructure, do some development work, help design/build solutions for our end-users and tier 3 support. My team member’s role is to design/build solutions for our end-users, assist staff with training needs, and tier 2 support. In addition to this we both do a million other miscellaneous tasks that come when you have a SharePoint environment. If you work on a small team with SharePoint you know exactly what I’m talking about.
This post is to cover what I think are the minimum tasks you need to do in order to maintain your SharePoint infrastructure when this is only 1 part of what your job responsibilities are. It’s easy to quickly become overwhelmed with this role and to feel like you aren’t doing enough to support the environment. When I think about best-case/recommended tasks I read in Microsoft material and hear in session presentations I sometimes feel there isn’t enough time in the day to do it right.
I suspect I’m not the only person who finds themselves in this scenario – you’re the “go-to” guy or gal for all things SharePoint and somehow need to find a way to keep the plates spinning.
With that, here are the top 5 activities I do at a minimum to maintain stable SharePoint on-prem environments:
Have a non-production SharePoint environment for EACH one of your production environments.
This is a bare minimum. This environment should be used to test out patches, fixes, new solutions, settings, etc. before doing it in your production environment. This environment should reflect the same architecture as your production farm. For example, if you have 2 app servers and 2 web servers in your production farm, have this same topology in your test farm. This matters for some things like the Distributed Cache cluster where more than 1 server is involved and you need to know how to work with this type of configuration rather than a simple 1 server configuration. You should go to school in your non-production environment ALWAYS.
Ideally, you should have more than one non-production environment for each production one – for example, if you do custom development you should have a development farm, test farm, and even a QA farm if your environment will support it.
Have good backups (and test them!)
If you do nothing else, do this. You don’t want to be caught flat-footed if/when you need to restore from a backup and realize you don’t have a good one to do it with. This can be SQL backups, SharePoint backups (actually initiates a SQL backup), or third-party vendor backups. Remember there may be some things not backed up depending on how you’re backing up your environment (IIS settings, NLB settings, SSL certs, etc.) Have a plan for how you’re going to restore those things as well. In tandem with this is having your farm(s) documented, both the logical components and physical layout. A great tool (reasonably-priced) for generating farm documentation is SPDocKit.
Once you’ve got backups, how do you know they’re good? Well, you don’t – you need to test them. Periodically you need to verify your backups are good and your process sound – how you do this can vary from a simple restore into a test environment content database to a full DR scenario involving the entire SharePoint farm and then document the steps you took to do it. Do what’s appropriate for your environment – no more, no less.
Patching (OS and SharePoint)
Whether you’re the one responsible for OS patching in addition to SharePoint patching or not, they still need to be done. The level of OS patches applied is usually dictated by the IT security department, but should be done on a regular basis to reduce risk.
SharePoint patching – my strategy is taken from other smart people in the industry (Todd Klindt I’m looking at you) whereby I take this approach:
- Only apply an update if it fixes a regression in an existing production environment.
- Install a Service Pack as soon as it can reasonably be installed. These are typically well-tested and usually introduce new functionality, stability, and/or performance improvements that make them worthwhile.
- Test out these patches as best you can (remember the non-production environment from above? This is one of the reasons why you need it.) What I’ve found in our test environments is it’s IMPOSSIBLE to sufficiently test out a patch. This is why I sit back and wait for others in the community to install the patch and test it out first – and that’s ok. I absolutely take advantage of the larger SharePoint community to highlight any issues they’ve discovered with a patch prior to trying it out in our own non-production environments. Only then do we start testing it in our own environment. It just makes sense to do it this way.
Here are some great references I use for SharePoint patching:
- SharePoint Updates (Trevor Seward) – includes PS cmdlets to manage SP Patches
- Todd Klindt’s 2013 Build Numbers
- What’s in that Patch? (Jeff Jones)
Health Analyzer Rules
These pesky rules, although annoying at times, do point out some important issues in your farm. Pay attention to them, fix the ones you can, document the ones you’re ignoring (yes, there are some you can safely ignore, even Microsoft TechNet articles say so!), and periodically review to ensure no new errors/warnings have surfaced since the last time you checked.
Monitor Content Database Sizes
Although there are many software boundaries and limits you need to be aware of, I feel the content database one is key. Depending on the type of content you have, the limit varies. Regardless, you need to be aware of the size of your content databases for your environments and scale-out when required. Microsoft has supportability constraints for certain scenarios and you need to ensure you’re falling within those:
SharePoint 2013 Content Database Limits
That is my top 5 list. I realize this is a gross over-simplification of the role and there are definitely other important things you should be doing in addition to these, but if you’re crunched for time and you need to get the job done this is a great place to start.
Do you have something different you’d include in your top 5? If so, let me know.
Thanks for reading.