we have couple of sharepoint 2013/2016 farms, and they all shared these architecture :-

  1. one sharepoint application server which have sharepoint server installed.
  2. one database server which have the sharepoint databases installed.

Now as part of our backup policy, we do the following:-

  1. we perform a backup on the sharepoint databases.
  2. our database backups will be beneficial to us, in-case the database server got sever damage and we were not able to recover it back.
  3. but what about the case if our sharepoint application server crashed. then our database server and our database backups will not be beneficial to us.

now someone might say that i can build a new sharepoint application server, and configure it to run on existing database. but the problem in sharepoint , that the sharepoint application server need to have the same patch level as in the crashed server. by patch level, i mean all the sharepoint patches that are installed as part of windows updates (those updates can be found inside the control panel).

so my question is how we can backup those sharepoint patches?, in a way that can allow us to automatically install them in any new sharepoint server? till i find a way to do so, i am currently taking a screenshot of our control panel, which includes the sharepoint updates we have, something as follow, this can allow us to know what are the updates that we need to install in-case we faced a situation that our current SharePoint server got sever damage and we want to build a new sharepoint server (of course i update this list after any patching we do on the server). enter image description here

  • why i got down votes? any explanation will be useful.. – test test Jan 15 '19 at 16:17
  • I'm guessing it's because it's for a business and is considered off-topic for this site. – HazardousGlitch Jan 17 '19 at 14:01
  • @HazardousGlitch i am asking a question about how we can document/backup the sharepoint patches info that we have. so we can apply the same sharepoint patches if/when need inside a new server. – test test Jan 17 '19 at 14:34
  • 1
    You mentioned a SharePoint server farm which probably means it's for a corporation which is beyond the scope of this site. Even if it isn't a corporation, I believe it's still beyond the scope. You're better off asking on ServerFault as it's better designed to handle these types of questions. That is probably why you were down voted. – HazardousGlitch Jan 17 '19 at 14:50
  • 2
    This should have been migrated to SharePoint... – Sven Jan 17 '19 at 19:57

Have a look at the documentation (which you should do anyway, because updating SharePoint is definitely not as straightforward as other products).

For SharePoint 2013, updates have been cumulative since Service Pack 1, thus you only need to keep track of the last update you install. If/when you need to build a replacement server, just apply SP1, then the same update as the originale server; you don't need to apply all the ones before.

The situation is quite more complex for SharePoint 2016, as there have been several non-cumulative updates; only after KB4011127 updates have started replacing previous ones. So you need to at least get there before installing the same update that was installed on the original server.

  • thanks for the reply. now in sharepoint on-premises 2013, sometimes our admin install security updates (for sharepoint & windows) and some of the sharepoint security updates will raise the sharepoint farm build number. so in sharepoint on-premises 2013 not all the updates are been done as part of a full CU, as we can install separate sharepoint security updates without having to install a full CU... – test test Jan 17 '19 at 18:06
  • Does your admin install everything that pops up on Windows Update? Is he/she aware that it's required to actually run the SharePoint Product Configuration Wizard after each and every SharePoint update? – Massimo Jan 17 '19 at 18:11
  • yes after patching the sharepoint server we run the product configuration wizard,, we are already aware of this.. – test test Jan 17 '19 at 18:12
  • 1
    Ok, good. But SP2013 CUs are released monthly, you probably don't need so fast a patch cycle. Anyway, the approach is the same: just keep track of the last installed CU and of any update installed after that; everything before the last CU is not needed, because it's included in the CU. – Massimo Jan 17 '19 at 18:14
  • 2
    @Massimo: Just FYI: Unfortunately, we can't migrate to a 3rd site after it has been migrated here. I could only close it, which would send it back to SU... – Sven Jan 17 '19 at 19:59

Another answer for a different approach to the problem: why don't you just backup the whole server?

If it's a virtual machine (most servers are, nowadays) it should be really easy to take a backup, or even to make a clone, after applying an update. But even if it's a physical server, there are solutions for that.

Restoring a backup is much quicker than building a replacement server.

  • yes the sharepoint server and the dataabse server are VMs... but the problem is that snapshots are not supported in sharepoint... or you mean i can reference the snapshot to get what are the patches that we need to install inside any new VM? – test test Jan 17 '19 at 18:11
  • I'm not talking about snapshots, I'm talking about backups (they are not the same). But if you are concerned about taking an image of a running system, just turn off the server and make a full copy of its virtual disk(s). You need to reboot it anyway if you have installed updates; a couple minutes of additional downtime shouldn't matter and will make a restore a lot quicker and easier than building another server. – Massimo Jan 17 '19 at 18:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.