Patching a Production SharePoint Servers


Psconfig upgrade command – v2v versus b2b

Upgrading product version(Major e.g. MOSS 2007 to SP2010 or SP2013 upgrades):

psconfig.exe -cmd upgrade -inplace v2v -wait

Applying a patch(minor e.g. CU or Service Pack):

psconfig.exe -cmd upgrade -inplace b2b -wait

If specified, the SharePoint Products Configuration Wizard will perform an in-place upgrade.

If v2v is specified, an in-place version to version upgrade is performed.

If b2b is specified, an in-place build to build upgrade is performed.

  • v2v upgrade is used for upgrading from one product version to another (e.g. MOSS 2007 to SharePoint Server 2010).
  • b2b upgrade is used for upgrading from one build to another within the same product version (e.g. SP2010 RTM to SP2010 SP1).

Plan (learn), backup (prepare), test, implement and verify (validate) is the basic testing plan suggested by Microsoft.

Deploying updates in a SharePoint Server 2010 environment consists of: downloading the binaries, installing (also referred to as updating) and upgrading by running the configuration wizard (not always). Ensure all servers in the farm (excluding the database servers) have been patched/updated before upgrading (running the configuration wizard (psconfig)).

Validate the CU upgrade:
PS>(get-spfarm).buildversion
Check if psconfig needs to be run:
PS> (get-spserver $env:computername).NeedsUpgrade
if True then
psconfig.exe -cmd upgrade -inplace b2b -force

Ensure the version is the version you are expecting after the patch.
Example of SP2010 SP1 with August 2012 CU:
Major  Minor  Build  Revision
—–  —–  —–  ——–
14     0      6126   5000

CA > Upgrade and Migration > Check upgrade status

or

SharePoint Cumulative Updates “Error: Some farm products and patches were not detected

  1. Get-SpProduct – -Local
  2. (Get-SpServer $env:ComputerName).NeedsUpgrade
  3. Confirm “True” is returned
  4. Continue with running the SharePoint Products Configuration Wizard

If false , then no need , 

Check this link : https://www.concurrency.com/blog/w/sharepoint-cumulative-updates-error-some-farm-prod

___________________________________________________________________________________-

Q. Best approach to update and apply CUs for SharePoint farm?, should i manually install CU or i should use windows update?

A.Keep in mind,

  • First, you have to make sure you need CU to Fix a problem in your Farm? if yes, then go ahead.
  • Dont apply those CU /Fixes from Windows Update.Always Turn off Automatic Update on Server
  • Dowload the CU from Micro soft site and apply.
  • You need to plan it, test it, schedule a down time.
  • SharePoint fixes for server products will continue to be available via Microsoft Update.
  • Install CU if it will fix issue on farm,
  • Never install CU on production till apply it on test.

Q. Security update through windows update and CU through download center, right?

A. Correct

Q. Sharepoint 2010/2013 allow to run after installing CU/Security patches?

A. Yes ,SharePoint 2010 and 2013 allow to continue execution without PSCONFIG after installing fixes.so you can schedule running configuration wizard after securing patch installation is finished.

Ref :https://technet.microsoft.com/en-us/library/cc263093.aspx

http://blog.sharepointsite.co.uk/2012/02/patching-production-sharepoint-farm.html

 

************************************************************************************

SharePoint Cumulative Updates Best Practices

This guidance pertains to production SharePoint environments and is applicable to SharePoint 2007, 2010, 2013, and likely future versions.

Maintaining a healthy SharePoint environment requires a practical approach to applying cumulative updates. SharePoint Cumulative Updates are patches released by Microsoft that fix known issues. As their name suggest, they are cumulative in content so they include previously released patches. However, a plan that simply applies the latest updates is likely not in your best interest and can actually put your environment at risk.

General rule

Install updates and patches when you encounter an issue that is addressed by the update. The only exception is you should maintain a reasonably current level of updates. It is not ideal to let your environment lapse two years behind in SharePoint updates.

Maintain a 6+ month lag

Maintain your production environment at a 6 to 12 month update lag. In other words, don’t install any updates that are less than 6 months old, unless it is necessary. I recommend not extending much beyond a 12 month lag behind the latest updates. This keeps your SharePoint environment relatively current while minimizing your risk as new updates are applied. Should you encounter an issue after applying an update, the likelihood of a fix already existing in a subsequent update is much greater than if you had applied the newest update available. Microsoft does a good job of testing their releases, but the number of possible configurations, feature combinations, and server patch levels are almost infinite so you are wise to stay away from the bleeding edge.

Test your updates first

Every update should be applied to a test environment and thoroughly tested before applying said update to production. The idea of having to completely regression test SharePoint is not practical nor should it be expected. But you should have a test environment for every production environment, and that test environment should be used to test updates.

Urgent updates (updates that address an urgent problem in production), will require more focused and targeted testing. This is less than ideal, but necessary when a critical issue is identified. However, general operational maintenance updates can be applied to the test environment and remain there for several months before applying that same update to production. This allows for more exhaustive user and operational testing activity to expose any possible problems.

Synergy with developers

If you have SharePoint developers on staff or contract, they can provide a tremendous benefit regarding updates. You should coordinate your update plans with them to ensure they are developing with at least the current production version, or even better, the next cumulative update identified and targeted for production. I suggest developers keep their environments to a relatively recent update level. This is usually not an issue for them and can be very easy if they develop using virtual machines.

Ensuring a successful update

Below are a few points that will help you make the update process as smooth as possible:

  • Something to consider: Minimize server downtime. Placing the content databases in a read-only mode while installing the binaries right before applying the patches can reduce server downtime. This allows your users access the SharePoint servers during the initial upgrade process and only experience downtime during the later portion of the update process. Again, not necessarily a recommendation, but something to consider.
  • If you are using virtualization, take snapshots or backups of your Web Front End and Application servers(s). I am a big proponent of virtualized SharePoint servers.
  • After installing the binaries of the Service Pack, run the Psconfig command on every server:
  • psconfig –cmd upgrade –inplace b2b –wait

Ref: https://blog.crsw.com/2014/02/05/sharepoint-cumulative-updates-best-practices/

 

**************************************************************************

Microsoft Clarifies SharePoint 2013 Patch Process and New ‘Uber Packages’

Microsoft offered clarification about its patch process for SharePoint Server 2013 this week.

The occasion for confusion, prompting Microsoft’s clarification, was the release of the August Cumulative Update (CU) for SharePoint 2013. The August CU came with a caveat about having to install the July CU first. That led SharePoint experts, such Microsoft MVP Todd Klindt, to say that the August CU really wasn’t a cumulative update after all.

“This [August] CU is NOT Cumulative,” Klindt wrote in a blog post. “It does NOT include the patches from the July 2014 CU. To get all fixes install [SharePoint Server 2013] SP1, the July 2014 CU, and then the August 2014 CU.”

(Microsoft had originally released Service Pack 1 for SharePoint Server 2013 in late February or early March, but a software flaw caused problems for some users, who couldn’t get subsequent cumulative updates. Microsoft rereleased SP1 in late April.)

Klindt’s claim that the August CU was not cumulative made quite a lot of sense at the time. How could a cumulative update in August not include updates from the previous months? Apparently the confusion was widespread, prompting a “SharePoint patching demystified” post on Tuesday by Stefan Gossner, a Microsoft senior escalation engineer for SharePoint. In that post, Gossner reaffirmed that the August CU is a cumulative update.

“After release of August 2014 CU I read several statements that August CU is not cumulative – but that is not correct! SharePoint fixes are always cumulative!” Gossner wrote.

Microsoft’s Explanation
Gossner’s explanation for why the August CU is cumulative has two facets. The first idea is that SharePoint gets released in parts or “independent components” for aspects such as “Search, Excel Services, Web Content Management, Document Lifecycle,” and other components needed to make SharePoint work. But not all of those components get fixed each month (Microsoft now releases its SharePoint Server cumulative updates on a monthly basis, instead of on a bimonthly basis, as Microsoft explained last month).

This notion that some SharePoint Server components get fixes in a cumulative update while others do not seems to turn the meaning of “cumulative update” on its head. According to Gossner’s explanation, though, components fixed in a particular cumulative update contain the past fixes for that component throughout the year. However, if a component wasn’t fixed in a particular cumulative update release, then you don’t get the past fixes for that component for the year — or something like that.

The second facet to this explanation is an exception to this rule, namely the so-called “uber package,” which apparently is a new term from Microsoft. An uber package usually gets distributed with SharePoint Server cumulative updates but it didn’t get shipped with the August CU because of the faster cumulative update release cycle that Microsoft initiated last month.

The Missing Uber Package
What is an uber package? It seems to be a cumulative update on its face, but it’s actually more like a “mini-service pack,” according to Gossner.

“The ‘Uber’ packages which are usually released with each CU not only include patches for the components updated in the current CU but also all patches released for other components of the product,” he wrote. “So they are very similar to a mini service pack.”

It’s not clear when Microsoft started using the term, “uber package,” but despite the “uber” name, “service packs” are more encompassing (see chart). Service packs are especially relevant for IT pros because they set a new “service baseline” for the server installation, and they are required to get subsequent updates for the product. Gossner explained that service packs are required even though cumulative updates may contain all of the fixes in a particular service pack. Cumulative updates are a special case, though, because they support two patch baselines. Cumulative updates support “the previous service pack for 12 more month[s] after releasing a service pack,” according to Gossner.

Hierarchy of Microsoft’s updates. Service packs contain it all, but uber packages are described as being like a miniature service packs.

Microsoft’s “standard terminology” page for its updates defines a service pack as “a tested, cumulative set of all hotfixes, security updates, critical updates, and updates.” The page doesn’t describe an uber package at all. In addition, the definition of a cumulative update is missing from that list. A cumulative update appears to a collection of previous “update rollups” for the year. An update rollup, in turn, is a collection of fixes that are released each month, which can contain security fixes or not — at least that’s what Microsoft seemed to have meant when it described its update rollups last year. Microsoft’s actual description of an update rollup in its standard terminology page adds to the confusion because it throws in the word, “cumulative.”

“Definition [of an update rollup]: A tested, cumulative set of hotfixes, security updates, critical updates, and updates that are packaged together for easy deployment,” Microsoft’s standard terminology page states.

Public Updates
Gossner also provided the definition for a “public update.” It’s a subset of a cumulative update that Microsoft intends for all users.

“Public Updates are also cumulative updates — but [they] only include those packages which include updates which should be distributed to all customers,” he wrote.

Public updates get released monthly, but they may not include past updates for all of SharePoint’s components, Gossner warned. In addition, because public updates and cumulative updates use different Knowledge Base article numbers, Windows Update may not recognize that fixes in a public update were applied in a cumulative update, he explained.

Gossner also talked about potential patch-numbering disparities. He explained that a patch number described in a particular Knowledge Base article may differ from the patch number seen in the SharePoint administrative console. The reason for the disparity is that the console only shows the SharePoint Foundation component, he explained.

In a nutshell, it appears that IT pros who patch SharePoint Server 2013 will have to learn to recognize when Microsoft does and does not release an uber package. If they don’t see an uber package mentioned, then they had better have service packs and cumulative updates installed to date. Otherwise, they risk not getting future updates, in all of their various forms.

Ref: https://redmondmag.com/articles/2014/08/19/sharepoint-patch-process.aspx

Failed to upgrade SharePoint Products

Running PSConfig after installing updates is a stressful experience(atleast for me). Every time is comes up with a different challenge. But unlike some unfriendly errors, psconfig gives us much more details about the failures in the upgrade logs. Okay then, I was updating SharePoint 2010 with May 2015 CU. Everything goes well until – The upgrade command is invalid or a failure has been encountered.

Well, that’s not too bad. No complaints about the missing features or unable to update content database errors. This time it says the upgrade command is invalid of-course or a failure is encountered.

Here is the complete message:

Upgrading SharePoint Products…

10.00%Failed to upgrade SharePoint Products.

An exception of type Microsoft.SharePoint.PostSetupConfiguration.PostSetupConfig
urationTaskException was thrown. Additional exception information: The upgrade
command is invalid or a failure has been encountered.
Failed to upgrade SharePoint Products.

The upgrade command is invalid or a failure has been encountered

After running the PSConfig.exe -cmd upgrade -inplace b2b -force -cmd applicationcontent -install -cmd installfeaturescommand, error occurred in 5th step while performing – Upgrading SharePoint Products.

Spent about 30 minutes Binging the error which did not help me this time. We decided to clear configuration cache which usually is my first step in troubleshooting. Here is how to do it.

PSconfig completed successfully without errors. Clearing cache did the trick.

Resolution: Clearing SharePoint Configuration Cache.

 

Step-by-step Cumulative Update SharePoint 2013

The first time is always the hardest (and most stressful). I remember the first time I patched a multiple server SharePoint environment for a user base of over 500 users with the SharePoint Cumulative Update – I was petrified. I researched long and hard but could only find bits and pieces and reached a good level of confidence but a level of nervousness remained.

This post is for the guy who has been asked to update a farm environment for the first time (and probably during a late night session … alone). The following details step-by-step the process of installing the SharePoint Server Cumulative Update (September 2014) including the pre-requisite SharePoint Server 2013 Service Pack 1.

The following is a check list of things to get ready beforehand:

  1. Complete enterprise Change Request requirements including ensuring Server Administrator resources are available during the change window to restore server backups
  2. Schedule server backups prior to the change request

Part 1: SharePoint 2013 Service Pack 1 Installation Process

  1. Log in as the SharePoint Farm service account
  2. Download SharePoint Server 2013 Service Pack 1 binary via http://support.microsoft.com/kb/2880552
    • officeserversp2013-kb2880552-fullfile-x64-en-us.exe
  3. Run the powershell script detailed at the end of this post (as per MSDN blog:http://blogs.msdn.com/b/russmax/archive/2013/04/01/why-sharepoint-2013-cumulative-update-takes-5-hours-to-install.aspx)
    • Ensure patch.ps1 and above binaries are in the same directory
  4. Ensure search content crawls are disabled (Idle)Step-by-step Cumulative Update SharePoint 2013_1
  5. Execute patch.ps1 script on all SharePoint application and web front end servers (as this is a binary update, the updates on the servers can be done concurrently)Step-by-step Cumulative Update SharePoint 2013_2This may take a few minutes…Step-by-step Cumulative Update SharePoint 2013_3This may take a while…(up to 20 minutes)Step-by-step Cumulative Update SharePoint 2013_4Complete…Step-by-step Cumulative Update SharePoint 2013_5
  6. Repeat until installation of binaries above complete on all servers
  7. Run the SharePoint 2013 Products Configuration Wizard (in the following order)
    • Application Server
    • Web Front EndStep-by-step Cumulative Update SharePoint 2013_7
    • Click Next
    • Step-by-step Cumulative Update SharePoint 2013_8
    • Click Yes>Step-by-step Cumulative Update SharePoint 2013_9Click Next>Step-by-step Cumulative Update SharePoint 2013_10This may take a while…(up to 50 minutes per server)Step-by-step Cumulative Update SharePoint 2013_11Complete…
  8. Verify Build Number in Upgrade and Migration under Check product and patch installation status in Central AdministrationStep-by-step Cumulative Update SharePoint 2013_12
  9. Verify Upgrade Status in Upgrade and Migration under Check upgrade status in Central AdministrationStep-by-step Cumulative Update SharePoint 2013_13

Part 2: SharePoint Server 2013 Cumulative Update September 2014 Installation Process

  1. Log in as the SharePoint Farm service account
  2. Download SharePoint Server 2013 Cumulative Update September 2014 binary via http://support2.microsoft.com/kb/2883068
    • 478311_intl_x64_zip.exe, 478312_intl_x64_zip.exe
    • 478313_intl_x64_zip.exe
  3. Run the powershell script detailed at the end of this post (as per MSDN blog: http://blogs.msdn.com/b/russmax/archive/2013/04/01/why-sharepoint-2013-cumulative-update-takes-5-hours-to-install.aspx)
    • Ensure patch.ps1 and above binaries are in the same directory
  4. Ensure search content crawls are disabled (Idle)Step-by-step Cumulative Update SharePoint 2013_14
  5. Execute patch.ps1 script on all SharePoint application and web front end servers (as this is a binary update, the updates on the servers can be done concurrently)Step-by-step Cumulative Update SharePoint 2013_15This may take a few minutes…Step-by-step Cumulative Update SharePoint 2013_16Step-by-step Cumulative Update SharePoint 2013_17Step-by-step Cumulative Update SharePoint 2013_18This may take a while…(up to 25 minutes) Step-by-step Cumulative Update SharePoint 2013_19
    Complete…Step-by-step Cumulative Update SharePoint 2013_20
  6. Repeat until installation of binaries above complete on all servers
  7. Run the SharePoint 2013 Products Configuration Wizard (in the following order)
    • Application Servers
    • Web Frond End ServersStep-by-step Cumulative Update SharePoint 2013_21Click Next>
    • Step-by-step Cumulative Update SharePoint 2013_22
      Click Yes>Step-by-step Cumulative Update SharePoint 2013_23
      Click Next>Step-by-step Cumulative Update SharePoint 2013_24
      This may take a while…(up to 50 minutes per server)Step-by-step Cumulative Update SharePoint 2013_25
  8. Verify Build Number in Upgrade and Migration under Check product and patch installation status in Central AdministrationStep-by-step Cumulative Update SharePoint 2013_26
  9. Verify Upgrade Status in Upgrade and Migration under Check upgrade status in Central AdministrationStep-by-step Cumulative Update SharePoint 2013_27

Resources:

Below is the patch.ps1 file as referenced from http://blogs.msdn.com/b/russmax/archive/2013/04/01/why-sharepoint-2013-cumulative-update-takes-5-hours-to-install.aspx

<#============================================================

  // 

  // Microsoft provides programming examples for illustration only, 

  // without warranty either expressed or implied, including, but not 

  // limited to, the implied warranties of merchantability and/or 

  // fitness for a particular purpose. 

  // 

  // This sample assumes that you are familiar with the programming 

  // language being demonstrated and the tools used to create and debug 

  // procedures. Microsoft support professionals can help explain the 

  // functionality of a particular procedure, but they will not modify 

  // these examples to provide added functionality or construct 

  // procedures to meet your specific needs. If you have limited 

  // programming experience, you may want to contact a Microsoft 

  // Certified Partner or the Microsoft fee-based consulting line at 

  //  (800) 936-5200 . 

  // 

  // For more information about Microsoft Certified Partners, please 

  // visit the following Microsoft Web site: 

  // https://partner.microsoft.com/global/30000104 

  // 

  // Author: Russ Maxwell (russmax@microsoft.com) 

  // 

  // ———————————————————- #>

  

########################### 

##Ensure Patch is Present## 

########################### 

$patchfile = Get-ChildItem | where{$_.Extension -eq “.exe”} 

if($patchfile -eq $null) 

  Write-Host “Unable to retrieve the file.  Exiting Script” -ForegroundColor Red 

  Return 

######################## 

##Stop Search Services## 

######################## 

##Checking Search services## 

$srchctr = 1 

$srch4srvctr = 1 

$srch5srvctr = 1

$srv4 = get-service “OSearch15” 

$srv5 = get-service “SPSearchHostController”

If(($srv4.status -eq “Running”) -or ($srv5.status-eq “Running”)) 

  

    Write-Host “Choose 1 to Pause Search Service Application” -ForegroundColor Cyan 

    Write-Host “Choose 2 to leave Search Service Application running” -ForegroundColor Cyan 

    $searchappresult = Read-Host “Press 1 or 2 and hit enter” 

    Write-Host 

    

   if($searchappresult -eq 1) 

    

        $srchctr = 2 

        Write-Host “Pausing the Search Service Application” -foregroundcolor yellow 

        Write-Host “This could take a few minutes” -ForegroundColor Yellow 

        $ssa = get-spenterprisesearchserviceapplication 

        $ssa.pause() 

    

    

    elseif($searchappresult -eq 2) 

    

        Write-Host “Continuing without pausing the Search Service Application” 

    

    else 

    

        Write-Host “Run the script again and choose option 1 or 2” -ForegroundColor Red 

        Write-Host “Exiting Script” -ForegroundColor Red 

        Return 

    

  }

Write-Host “Stopping Search Services if they are running” -foregroundcolor yellow 

if($srv4.status -eq “Running”) 

  

    $srch4srvctr = 2 

    set-service -Name “OSearch15” -startuptype Disabled 

    $srv4.stop() 

  }

if($srv5.status -eq “Running”) 

  

    $srch5srvctr = 2 

    Set-service “SPSearchHostController” -startuptype Disabled 

    $srv5.stop() 

  }

do 

  

    $srv6 = get-service “SPSearchHostController” 

    if($srv6.status -eq “Stopped”) 

    

        $yes = 1 

    

    Start-Sleep -seconds 10 

  

  until ($yes -eq 1)

Write-Host “Search Services are stopped” -foregroundcolor Green 

Write-Host

####################### 

##Stop Other Services## 

####################### 

Set-Service -Name “IISADMIN” -startuptype Disabled 

Set-Service -Name “SPTimerV4” -startuptype Disabled 

Write-Host “Gracefully stopping IIS W3WP Processes” -foregroundcolor yellow 

Write-Host 

iisreset -stop -noforce 

Write-Host “Stopping Services” -foregroundcolor yellow 

Write-Host

$srv2 = get-service “SPTimerV4” 

  if($srv2.status -eq “Running”) 

  {$srv2.stop()}

Write-Host “Services are Stopped” -ForegroundColor Green 

Write-Host 

Write-Host

################## 

##Start patching## 

################## 

Write-Host “Patching now keep this PowerShell window open” -ForegroundColor Magenta 

Write-Host 

$starttime = Get-Date

$filename = $patchfile.basename 

$arg = “/passive”

Start-Process $filename $arg

Start-Sleep -seconds 20 

$proc = get-process $filename 

$proc.WaitForExit()

$finishtime = get-date 

Write-Host 

Write-Host “Patch installation complete” -foregroundcolor green 

Write-Host

################## 

##Start Services## 

################## 

Write-Host “Starting Services Backup” -foregroundcolor yellow 

Set-Service -Name “SPTimerV4” -startuptype Automatic 

Set-Service -Name “IISADMIN” -startuptype Automatic

##Grabbing local server and starting services## 

$servername = hostname 

$server = get-spserver $servername

$srv2 = get-service “SPTimerV4” 

$srv2.start() 

$srv3 = get-service “IISADMIN” 

$srv3.start() 

$srv4 = get-service “OSearch15” 

$srv5 = get-service “SPSearchHostController”

###Ensuring Search Services were stopped by script before Starting### 

if($srch4srvctr -eq 2) 

    set-service -Name “OSearch15” -startuptype Automatic 

    $srv4.start() 

if($srch5srvctr -eq 2) 

    Set-service “SPSearchHostController” -startuptype Automatic 

    $srv5.start() 

}

###Resuming Search Service Application if paused### 

if($srchctr -eq 2) 

    Write-Host “Resuming the Search Service Application” -foregroundcolor yellow 

    $ssa = get-spenterprisesearchserviceapplication 

    $ssa.resume() 

}

Write-Host “Services are Started” -foregroundcolor green 

Write-Host 

Write-Host 

Write-Host “Script Duration” -foregroundcolor yellow 

Write-Host “Started: ” $starttime -foregroundcolor yellow 

Write-Host “Finished: ” $finishtime -foregroundcolor yellow 

Write-Host “Script Complete”

Ref:https://sharepointfundamental.wordpress.com/2015/08/07/step-by-step-cumulative-update-sharepoint-2013/

Advertisements
This entry was posted in SHAREPOINT ADMIN. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s