Marc Lognoul's IT Infrastructure Blog

Cloudy with a Chance of On-Prem


Leave a comment

SharePoint: MS15-022 (Critical) Vulnerabilities in Microsoft Office Could Allow Remote Code Execution (3038999)

Once again, SharePoint Server 2007, 2010 and 2013 are affected by a vulnerability categorized as Critical by MS that can allow remote code execution. The matching Office suite version are affected as well.

More information:

Important: SharePoint Server 2013 updated with March PU or Service Pack 1 can receive this security update through Windows Update.

Advertisements


Leave a comment

SharePoint 2013: February 2015 Cumulative Update released

The February 2015 CU for SharePoint 2013 (aka build number 15.0.4693.1001 ) has just been released. Download Links:

KB Articles:

Besides SharePoint, Office OneDrive Client get updated as well with fixes for long paths and large lists:

All Office-related February updates: Office Updates Blog [MSFT]: February 2015 Office Update Release


Leave a comment

SharePoint 2013: December 2014 Cumulative Update released

The December 2014 CU for SharePoint 2013 (aka build number 15.0.4675.1000) has just been released.

Download Links:

KB Articles:


Leave a comment

SharePoint: MS14-081 Vulnerabilities in Microsoft Word and Microsoft Office Web Apps Could Allow Remote Code Execution (3017301)

Both SharePoint 2010 and 2013 versions are affected by a vulnerability categorized as Critical by MS that can allow remote code execution.

More information:


Leave a comment

SharePoint 2013: October 2014 Cumulative Update released

The October 2014 Cumulative Update for SharePoint 2013 (including Project Server and Office Web Apps) has just been made available.

I recommend to carefully read Stefan Goßner [MSFT]‘s blog for matching KB’s, Download links and necessary clarifications about prerequisites, patching sequence and packages: October 2014 CU for SharePoint 2013 has been released.

Carefu


Leave a comment

.Net: Vulnerabilities in .NET Framework Could Allow Remote Code Execution (MS14-057) – Critical

.Net Framework versions from 2 to 4.5.2 are affected by a vulnerability categorized as Critical by MS that can allow remote code execution.

More information:


Leave a comment

SharePoint 2010-2013: August 2014 CU’s Released with a Gotchas!

While the monthly CU for both SharePoint 2010 and 2013 have been released, make sure you carefully read Stefan Goßner’s [MSFT] posts regarding the “non-cumulative” nature of those so-called “cumulative” updates, particularly for SharePoint 2013:


Leave a comment

SharePoint 2013: MS14-050 Vulnerability in Microsoft SharePoint Server Could Allow Elevation of Privilege

This vulnerability applies to SharePoint Foundation 2013 and SharePoint Server 2013 with and without SP1. More information:

 


UAG2010: Configuration Lost after Installing Service Pack 4

ForeFront UAG

Introduction

In this post I will modestly relay a problem experienced by a customer that was hopefully resolved by MS product Support.

After Installing the Service Pack 4 of UAG 2010, the complete configuration was missing. It was impossible to restore a backup taken prior installing the Service Pack because the schema of the database storing the configuration evolved. We were in a rather uncomfortable position…

Solution

Hopefully, the solution to this problem is rather simple:

  1. From the Control Panel, uninstall the Service Pack 4 and reboot once prompted
  2. After rebooting, open the UAG console and verify the current build version of the product. Due to the prerequisites for SP4 installation, it should be 4.0.3206.10100, which means Service Pack 3 + Update Rollup 1. You can refer to this page if you need MS product build versions, it covers UAG2010 as well
  3. “Normally”, the configuration should be back as well. If not, restore it from a previous backup. Since build versions are identical, it should work fine
  4. Activate the configuration then reboot the server again. The situation should be stable from this point. For safety, take a new backup before going any further
  5. From now you can attempt to install the Service Pack 4 again
  6. After successful installation, activate the configuration again and take a backup

Proactive Action

In order to prevent this problem from occurring on other Service Pack 4 deployments, proceed as follows:

  1. Make sure Service Pack 3 and Update Roll-up 1 are installed
  2. Activate the configuration with the current build level
  3. Reboot the server
  4. Take a backup
  5. Deploy Service Pack 4


SharePoint 2013: How to Estimate the Time Necessary to Deploy a SharePoint Update and Optimize it

SharePoint 2013

Introduction

When planning the roll-out of a SharePoint Update (hot fix, cumulative update or service pack) on a production farm, it may be useful to estimate the effective time necessary to perform such an action. While the complete duration depends on many factors, I will attempt to give some guidance here. The most important thing being: benchmarking on your test environment is the key.

Note: While this article covers mostly SharePoint 2013, the same logic may apply to previous versions.

The Rollout Sequence

The complete roll-out sequence used to update a SharePoint Farm (The servers and the configuration and content they share) is made of the following core steps:

  1. Installing the Update Package on each Server in the Farm
  2. (Optionally) Rebooting the Server(s) (Depending upon the files being updated and their state (in use or not), a reboot may be necessary
  3. Applying the Update on a first server, usually the one hosting the Central Administration web application
  4. Applying the Update on remaining servers. Note: This should not be done simultaneously (see why in next section)

SharePoint Update Process

Installing the Update Package

This action consists in installing the update binaries and other dependencies thanks to the Windows Installer technology. In other words, this means it will apply a “patch” on an existing MSI package that is the original package you installed SharePoint with. At that time, it will not touch SharePoint configuration or content. Because it may have to update files that are currently in-use, a reboot might be necessary after this process. If you plan to install multiple updates as part of the same rollout, there is a probability of reboot after each installation (A server in a pending-reboot state will refuse to install).

To reduce the execution time you can apply the guidance hereunder. Apply them carefully and according to you organization’s SLA and other policies:

  • Before installing the package, check that each server is not already pending reboot, this will prevent installing the update until a preliminary reboot is performed
  • Stop/Pause the Windows Anti-virus Software running on Windows Server if any. Refer to you security policies for guidance.
  • Stop as many server processes as you can (IIS, SharePoint services, other services such as Search, SharePoint AV is any…). This will reduce the load on the server and increase the number of threads available to the MSI engine to perform its job. Obviously, this will make SharePoint unusable on the server where it takes place. Refer to your SharePoint SLA for guidance. The service stop/start order maters, therefore you can rely on these posts for detailed guidance and automation: SharePoint Brew [MSFT] Why SharePoint 2013 Cumulative Update takes 5 hours to install? and SharePoint IT Pro Blog [MSFT]How to install update packages on a SharePoint farm where search component and high availability search topologies are enabled
  • While this step can be executed simultaneously on multiple SharePoint servers in the farm, rebooting the servers might be required. Therefore you should always bear in mind your SLA
  • Pre-extracting the package will also help since otherwise, each server will unpack the archive before starting the installation. This TechNet Article explains how to extract fiels from an Update Package: Prepare to deploy software updates for SharePoint 2013
  • Once extracted, there is no dramatic performance difference between installing from locally stored sources or from a remotely hosted shared folder. However and because MSI also maintains its local source cache, it might be wiser to keep sources centralized to avoid local clutter and confusion
  • Like most of installation packages provided by Microsoft, SharePoint Update Packages are digitally signed with a Microsoft Certification Authority. Before executing the package content, Windows will attempt to validate the certificate by checking its status against the Microsoft Certificate Revocation List (CRL). If the SharePoint servers have no internet connection, it is therefore advisable to Disable the Certificate Verification. This will prevent useless spinning until a timeout is reached
  • Once the package is installed on every server, you can measure the time it took by looking at the MSI Events from the Windows Application Log. They cover the start, end and sometimes intermediate events. This MSDN Article give the list of related Event ID and meaning: Windows Installer Logging – Event Logging
  • Installation log files can be found under the %TEMP% folder of the user who performed it

Applying the Update (aka PSConfig B2B Upgrade)

This step consists in applying the at various SharePoint levels:

  • Sharepoint Server’s file system modifications, assemblies, GAC,  files Under the 15 folder…
  • IIS Configuration and files (web.config…)
  • SharePoint databases (schema and content)

The details of each modification, its result as well as useful timestamp information can be found in the upgrade.log file. This log file will provide good indication of the time it took to update each elements of SharePoint. This MS KB article, while a little outdated, will give a good explanation of the log file and the sequences it contains: MS KB Description of the sequences and actions that occur when you upgrade SharePoint Products and Technologies.

In a nutshell, the elements hereunder will influence the duration:

  • The Number of SharePoint servers in a farm
  • The Number of Web Applications and Extensions
  • The Number of databases, content databases in particular
  • Potentially, the number of objects in the SharePoint content. Some updates may have to create new content through, for example a new document library in each site or so

Executin the PSConfig on the remaining servers in the farm will take less time than on the first one (50% to 25% less). Anyway, it should never be performed simultaneously on multiple servers otherwise conflicts may occur when objects are getting updated in the Configuration database.

Below some guidance over this step:

  • Stopping/Pausing the Windows Anti-Virus software remains a good idea due to the number of files being accessed and modified
  • Unlike during the package installation, services such as IIS and SharePoint service should not be stopped because they are at some point, necessary in the upgrade process. The upgrade.log file will contain entries related to service start/stop/restart.
  • Keep the total number of servers, web application, IIS sites and content databases as low as possible
  • To speed up the content database upgrade by deferring it, you can remove all content databases and add them back gradually. Obviously, this will impact the content availability. Note: Temporarily removing CDB’s can also help recovering faster in case of disaster during the deployment if you have many and/or large databases

Additional Administrative Steps

While the steps stated above are the main technical ones, some orgnizations may also have to take administrative as well as extra technical steps into account such as:

  • Informing the users about the maintenance (if a downtime occurs)
  • Putting the servers/Farm in maintenance mode
  • Changing Load Balancer configuration
  • Performing a health check to make sure the farm is in overall good shape
  • Taking the appropriate back up
  • Getting approval from a security officer to stop the A-V software
  • Performing technical and functional testing after applying the update on the first server
  • Performing technical and functional testing after the update is applied on the whole farm
  • Update other components such as Workflow Manager and/or WAC
  • Setting-off the Maintenance Mode
  • Communicating to the end users

Obviously these may severly impact time necessary to deploy as well…

Conclusion

  • To accurarely estimate the total deployment time, you’ll need a test environment whose configuration and ideally content is close or identical to your production environment
  • Event Logs and log files contain all key events to benchmark a deployment
  • While updating a SharePoint farm may sometimes last for hours, ther are a couple of tips to make it shorter
  • While the SharePoint core steps are important, the additional administrative and technical steps around might also heavily influence the planning

Additional Information