4

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

test test
  • 81
  • 8
  • 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. –  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. –  Jan 17 '19 at 14:50
  • @HazardousGlitch so your advice is to move this question to ServerFault forum? – test test Jan 17 '19 at 15:09
  • Yes. If you don't then a moderator probably will. –  Jan 17 '19 at 16:10
  • @HazardousGlitch seems i do not have any option to move this question to another forum.. – test test Jan 17 '19 at 16:16
  • 2
    This should have been migrated to [sharepoint.se]... – Sven Jan 17 '19 at 19:57
  • @Sven no i am asking a question about patching windows server and about windows updates and not specific question about sharepoint – test test Jan 17 '19 at 19:58
  • @testtest Your question boils down to "how can I build a replacement SharePoint server with the same installed updates which can run against the same database". So, yes, this really is SharePoint-specific. Even if the SharePoint updates on the production server are installed via Windows Update (which they shouldn't). – Massimo Jan 17 '19 at 20:07

2 Answers2

1

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.

Massimo
  • 68,714
  • 56
  • 196
  • 319
  • 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
  • yes each month Microsoft release a full CU.. but we do not install full CUs very frequent (unless it will solve an issue).. but each 3-6 months our admins patch the sharepoint servers for "Security updates". for example we have a farm which got the latest full CU, around 2.5 years ago, but we have been security patching it every 3 months, and we run the SP product configuration wizard.. so returning back to my answer, sharepoint updates do not have to be as part of full CU (which is released each month).. you can install single SP security update which might raise the SP build number – test test Jan 17 '19 at 18:20
  • This is exactly the wrong approach to patching SharePoint. Even if you are on a 3-6 months patch cycle, you should install the latest CU *and then* all remaining security updates (if any). Apart from being simpler, this will also save you a lot of time. – Massimo Jan 17 '19 at 18:21
  • but installing full CUs will require doing an intensive testing for the whole farm,and it is not required to install full CUs unless it will solve issues for our sharepoint.so we can not install full CUs each 3-6 months... while installing sharepoint security updates will still require testing but the effect will be minimal on the functionality.. also if we install a full sharepoint CU, then there is not need to install separate sharepoint security updates,, as full SP CU will cover security updates.. – test test Jan 17 '19 at 18:26
  • in all ways let me concentrate more on my original question... as i mentioned in our case we install full CUs when we face an issue that have a fix inside a full CU, while we have to patch the server each 3-6 months to install security updates, this will ensure that the sharepoint server will be secured. so in our way if we keep a list of all the sharepoint updates inside the "Control Panel" >> "View installed updates".. then this can be used if we faced a sever situation that require us to create a new sharepoint VM and force it to work with the current database server? – test test Jan 17 '19 at 18:37
  • You are deliberately placing yourself in a difficult-to-manage position by installing lots of smaller updates instead of CUs, which exist *exactly for the purpose of allowing you to install a single cumulative update instead of many smaller ones*. The only answer to your question is "you need to manually keep track of them", if you don't want to perform patching the proper way. – Massimo Jan 17 '19 at 18:47
  • based on Microsoft recommendations we should NOT install full CUs unless it solve an issue. and at the same time based on our customer policies and ours security policy, the servers need to be patched every 3-6 months to install the latest security update for sharepoint and windows. so that why we have separate sharepoint security updates that are installed inside our farm. but as u mentioned those security updates are "cumulative", as sometimes when we install a SP security update, it will remove older updates from the "control panel">>"view installed updates"... – test test Jan 17 '19 at 19:00
  • I think you are mistaking Microsoft guidelines, or are still clinging to old and superseded ones; here are the current guidelines: https://docs.microsoft.com/en-us/SharePoint/product-servicing-policy/product-servicing-policy. They are somewhat product-specific, but always along the lines of "you should install Public Updates (the new name for CUs) as soon as they are released". – Massimo Jan 17 '19 at 19:35
  • Anyway, if you want a more in-depth analysis, you should ask the folks at https://sharepoint.stackexchange.com. – Massimo Jan 17 '19 at 19:36
  • 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
1

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.

Massimo
  • 68,714
  • 56
  • 196
  • 319
  • 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