This post assumes a single SharePoint server but if you have multiple SharePoint servers, you must follow these steps on all SharePoint servers in your farm.

Introduction

The SharePoint world is rapidly moving into the Cloud with SharePoint Online and Office 365, but some organizations are still not ready to move completely to Office 365 and SharePoint Online.

Upgrading to SharePoint 2019 that has support for a hybrid scenario can be a valid solution to allow a gradual move to the cloud.

Installing a SharePoint 2019 farm can be done in an automated way using PowerShell and AutoSPInstaller. One additional advantage of this installation process ensures that the SharePoint farm is installed with the latest updates, leaving the SharePoint farm updated and working properly (if you want to learn how to install a SharePoint 2019 farm in an automated way, click here and here).

To ensure that after the installation, the SharePoint server is kept always updated, we must ensure that both the Windows Updates and specially the SharePoint Cumulative Updates are properly installed.

Installing SharePoint Updates

To install the latest SharePoint Cumulative Updates in your farm, follow the following steps:

• Download the SharePoint Cumulative Updates
• Backup SharePoint Farm and Configurations
• Install the Cumulative Updates in the SharePoint Farm (using PowerShell)
• Run SharePoint Products and Configuration Wizard
• Post-Installation Steps

Download the SharePoint Cumulative Updates

All starts by downloading the latest SharePoint Cumulative Updates. To do that, you must download:

• SharePoint 2016 and SharePoint 2019:
  • The latest language independent SharePoint updates
  • The latest language dependent SharePoint updates (even if you just have the English language pack installed in your farm)
• SharePoint 2013:
  • The latest SharePoint 2013 Server updates (if you have SharePoint 2013 Server installed)
  • The latest SharePoint Foundation 2013 updates (if you have only SharePoint Foundation 2013 installed). This update is not necessary if you have SharePoint 2013 Server since SharePoint Foundation 2013 is included in SharePoint 2013 Server

To stay up to date and download the latest updates, click here for SharePoint 2019, here for SharePoint 2016 and here for SharePoint 2013.

Backup SharePoint Farm and Configurations

Before applying the updates, you should perform the following backups:

• Backup the SharePoint farm by running the following command:
  Backup-SPFarm -Directory <BackupFolder> -BackupMethod Full -Verbose

The backup folder should be a shared folder on the network, accessible by both SharePoint and database servers.

Ensure the SharePoint Server VSS Writer service is started on the SharePoint server (not started automatically).

Ensure the SQL Server VSS Writer service is started on the database server.

For more details about SharePoint farm backup, click here, here and here

• Backup all SharePoint databases in the database server that supports the SharePoint farm using SQL Server Enterprise tools
• Backup the web.config files for all web applications
• If you have custom developed solutions using server-side code, backup the solutions. To make this easier, you can download a PowerShell script from my GitHub repository

Install the Cumulative Updates in the SharePoint Farm (using PowerShell)

After downloading the latest updates and taking the necessary precautions, you are ready to install them in your SharePoint farm.

If you want to use the traditional method to update your farm, click here. If you want to learn the PowerShell way and speed up the installation of the Cumulative Updates in your SharePoint farm, read on!

To download the SharePoint Patch PowerShell script, click here. This script, written by Trevor Seward, is an improved version of a PowerShell script originally created by Russ Maxwell for SharePoint 2013.

The way this PowerShell script ensures that the SharePoint patch process time is reduced from 4 to 5 hours to less than one hour is by doing the following:

• If you choose to (use the -Pause switch parameter), suspends the Search Service Application. This is very important since if a search crawl was triggered during the installation of the Cumulative Update, the Search Application could get corrupted and you could be forced to rebuild the entire Search Service Application, recreate any custom managed properties and perform a Full Crawl again to ensure you have search results and all search based solutions work properly
• For SharePoint 2013 (not necessary for SharePoint 2016 and SharePoint 2019), the following services will be disabled and then stopped:
  • Search services are disabled
  • Search services are stopped
  • IISAdmin and SPTimerV4 services are disabled
  • IISAdmin and SPTimerV4 services are stopped
• If you choose to, the Cumulative Updates are installed in passive mode (without any necessary user interaction) but you can still see the installation process in the UI
• When the installation of the Cumulative Updates is complete:
  • For SharePoint 2013 (not necessary for SharePoint 2016 and SharePoint 2019), the following services will be set to automatic:
    • Search services
    • IISAdmin and SPTimerV4 services
  • If you choose to use the -Pause switch parameter, the Search Service Application will be resumed

To start the installation process, open the SharePoint PowerShell window (run as administrator) and execute the following commands:

• Import-Module .\SharePointPatchScript.psm1
• Install-SPPatch -Path -Pause
  • Example: Install-SPPatch -Path D:\SharePoint\Updates -Pause

For SharePoint 2016 and 2019, a monthly Cumulative Update typically contains both the language independent (“sts” file) and the language dependent (“wssloc” file) packages. Sometimes, a Cumulative Update only includes the language independent package. If that is the case, and you already have the latest language dependent package installed, you can run the PowerShell command with the -OnlySTS switch parameter:

• Import-Module .\SharePointPatchScript.psm1
• Install-SPPatch -OnlySTS -Path -Pause
  • Example: Install-SPPatch -OnlySTS -Path D:\SharePoint\Updates -Pause

This will start the SharePoint farm update process (examples for SharePoint 2013 and SharePoint 2019).

For SharePoint 2013, SharePoint Server or SharePoint Foundation packages will be detected automatically and installed. The example below is for SharePoint 2013 Server.

For SharePoint 2016 and SharePoint 2019, both language independent and language dependent packages will be detected automatically and installed.

Instead of taking hours to perform, the updates should be installed in less than one hour.

A reboot to the server may be necessary.

Run SharePoint Products and Configuration Wizard

To finish the farm update process, you must ensure that after the updates are properly installed, you execute the SharePoint Products and Configuration Wizard that will ensure the following:

• The database schema for all SharePoint databases is updated to the latest version
• Copies the required binaries from the install location into the _app_bin directories of all web applications
  
• Fixes security settings on the file system to match SharePoint’s needs
• Updates features registrations with SharePoint

To start, run the SharePoint Products and Configuration Wizard and select Yes when prompted to reset IIS, SharePoint Administration and SharePoint Timer services.

Depending on your environment, the process will take some minutes to execute the 10 steps of the process.

After a few minutes, the SharePoint Products Configuration Wizard will finish executing, hopefully with success.

After clicking on Finish, the Central Administration will automatically be launched.

Post-Installation Steps

To ensure that the farm was successfully updated, it is important to check that the Databases Upgrade Status page.

If the page shows any database still needing upgrade (showing the “Database is in compatibility range and upgrade is recommended” status), some additional steps must be followed.

These steps must also be followed if you encounter the error below while running SharePoint Products and Configuration Wizard, saying that there is a mismatch between SharePoint installed version (after updating the farm) and the database schema version.

To ensure all databases are properly upgraded, follow the following steps:

• Upgrade the content databases by executing the following PowerShell command (executed with “run as administrator”):

Get-SPContentDatabase | Upgrade-SPContentDatabase

• Upgrade the remaining content databases, executing the following command (in command prompt with “run as administrator”):

Psconfig.exe -cmd upgrade -inplace b2b -wait -force

• Run the SharePoint Products and Configuration Wizard (PSCONFIGUI.EXE) again. After running SharePoint Products and Configuration Wizard again, it should run without errors.

To confirm the databases upgrade was successful, go back to the Databases Upgrade Status page. After the previous steps, all SharePoint databases were successfully upgraded.

To ensure the upgrade process was successfully finished, go to the Patch Status page and the Upgrade Status page.

Important Notes

Some important notes on using SharePoint Products and Configuration Wizard (PSCONFIGUI.EXE) and PSCONFIG.EXE (command line version):

• You should not run PSCONFIG.EXE as a replacement of SharePoint Products and Configuration Wizard (PSCONFIGUI.EXE)
  • PSCONFIGUI.EXE is the UI based configuration wizard which performs several tasks one after the other after installing fixes. It is the preferred option to ensure that the SharePoint farm update is completed after installing updates in your SharePoint farm
  • PSCONFIG.EXE is the command line tool which gives users granular control over all tasks that are executed and which is therefore often quicker than PSCONFIGUI.EXE but if misused will not make all the necessary tasks required after installing updates in your SharePoint farm
  • If you want to run PSCONFIG.EXE, ensure you run it with the correct parameters: “PSConfig.exe -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures -cmd secureresources -cmd services -install”
    • Above, I used “Psconfig.exe -cmd upgrade -inplace b2b -wait -force” since I already had used
      SharePoint Products and Configuration Wizard (PSCONFIGUI.EXE) and the only thing I wanted to ensure was that SharePoint databases schema were upgraded
• PSCONFIGUI.EXE should always be executed even when installing SharePoint security updates

For more details, check Stefan Goßner’s articles here and here.

Troubleshooting

During an update there are a few errors that can occur while the patch is being validated against your SharePoint environment before is starts being installed. The most common errors are the following:

• “The expected version of the product was not found on the system” – this article by Stefan Goßner explains the error in detail and what can cause it. Basically, SharePoint is typically composed of the following components:
  • SharePoint Server or SharePoint Foundation*
  • SharePoint Server or SharePoint Foundation English Language Pack*
  • Any additional SharePoint Server or SharePoint Foundation Language Packs*
    
    * – SharePoint Foundation existed from SharePoint 2007 to SharePoint 2013 and in SharePoint 2016 and 2019, only SharePoint Server is available
    
    To solve this error, you must ensure that all components have the same patch level. If any of the installed components has a lower patch level or doesn’t meet the Cumulative Update Prerequisites, the error above will be shown and you won’t be able to install the Cumulative Update in your SharePoint farm.
    
    Example: Install the May 2019 Cumulative Update in a SharePoint 2013 farm that has Service Pack 1 (15.0.4571.1502 patch level). The installed components have the following patch levels:
    • SharePoint Server 2013 – 15.0.4571.1502 (Service Pack 1)
    • SharePoint Server 2013 English Language Pack – 15.0.4571.1502 (Service Pack 1)
    • SharePoint Server 2013 Portuguese Language Pack – 15.0.4420.1017 (RTM)
      
      The “The expected version of the product was not found on the system” error will be shown since of one of the components (the Portuguese Language Pack) has a lower patch level. To solve this, you must install the SharePoint Server 2013 Portuguese Language Pack Service Pack 1 (you can get the download link here)
      
      To help you to identify the problem, you can use Roiscan which generates a detailed report of all installed Office components, including SharePoint, and verify the patch level of each components.
      
      You can also take a look at this article that can help you ensure that the information about all installed patches is correctly updated in the SharePoint configuration database.
      
• “No product installed for contained patch” – this can occur if you are installing a Cumulative Update for the wrong version of SharePoint. The most common case is when you are trying to install the SharePoint Foundation 2013 Cumulative Update in a SharePoint Server 2013 farm. In this case, you only need to install the SharePoint 2013 Server Cumulative Update

Other errors can occur while trying to run SharePoint Products and Configuration Wizard after installing the patch:

• “Feature is referenced in database but isn’t installed on the current farm” – this is more common in an farm upgrade scenario (ex: upgrade from SharePoint 2013 to SharePoint 2019) but can also occur while installing a SharePoint Service Pack or Cumulative Update. To learn more details about this error and how to solve it, click here.
• “An update conflict has occurred, and you must re-try this action.” when you run the following command “Psconfig.exe -cmd upgrade -inplace b2b -wait -force”. If you take a look at the ULS Logs, you may find messages like “PSCONFIG.EXE (0x1A8C) UpdatedConcurrencyException: The object SPUpgradeSession Name=Upgrade-20190531-122515-42 was updated by another user. Determine if these changes will conflict, resolve any differences, and reapply the second change. This error may also indicate a programming error caused by obtaining two copies of the same object in a single thread.”. To solve this problem, execute the following command:
  
  PSConfig.exe -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures -cmd secureresources
  
  NOTE: After solving these issues, to finish the process, run SharePoint Products and Configuration Wizard again.

Related Articles

To learn why your business should migrate to SharePoint Online and Office 365, click here and here.

If you want to convert your tenant’s root classic site into a modern SharePoint site, click here.

If you are a SharePoint administrator or a SharePoint developer who wants to learn more about how to install a SharePoint 2019 farm in an automated way using PowerShell, I invite you to click here and here.

If you prefer to use the traditional method to update your farm and want to learn all the steps and precautions necessary to successfully keep your SharePoint farm updated, click here.

If you want to learn how to upgrade a SharePoint 2013 farm to SharePoint 2019, click here and here.

If SharePoint 2019 is still not an option, you can learn more about how to install a SharePoint 2016 farm in an automated way using PowerShell, click here and here.

If you want to learn how to upgrade a SharePoint 2010 farm to SharePoint 2016, click here and here.

If you are new to SharePoint and Office 365 and want to learn all about it, take a look at these learning resources.

If you are work in a large organization who is using Office 365 or thinking to move to Office 365 and is considering between a single or multiple Office 365 tenants, I invite you to read this article.

If you want to know all about the latest SharePoint and Office 365 announcements from SharePoint Conference 2019, click here and here.

If your organization is still not ready to go all in to SharePoint Online and Office 365, a hybrid scenario may be the best choice. SharePoint 2019 RTM was recently announced and if you to learn all about SharePoint 2019 and all its features, click here.

Happy SharePointing!

The post How to install SharePoint Cumulative Updates In Less Than An Hour in a SharePoint Farm Step by Step appeared first on Blog IT.

This post assumes a single SharePoint server but if you have multiple SharePoint servers, you must follow these steps on all SharePoint servers in your farm.

UPDATE 02/05/2019:

The farm update process can take several hours. If you want to learn how to update your SharePoint farm in less than an hour, using PowerShell click here.

Introduction

The SharePoint world is rapidly moving into the Cloud with SharePoint Online and Office 365, but some organizations are still not ready to move completely to Office 365 and SharePoint Online.

Upgrading to SharePoint 2019 that has support for a hybrid scenario can be a valid solution to allow a gradual move to the cloud.

Installing a SharePoint 2019 farm can be done in an automated way using PowerShell and AutoSPInstaller. One additional advantage of this installation process ensures that the SharePoint farm is installed with the latest updates, leaving the SharePoint farm updated and working properly (if you want to learn how to install a SharePoint 2019 farm in an automated way, click here and here).

To ensure that after the installation, the SharePoint server is kept always updated, we must ensure that both the Windows Updates and specially the SharePoint Cumulative Updates are properly installed.

Installing SharePoint Updates

To install the latest SharePoint Cumulative Updates in your farm, follow the following steps:

• Download the SharePoint Cumulative Updates
• Backup SharePoint Farm and Configurations
• Pre-Installation Steps
• Install the Cumulative Updates in the SharePoint Farm
• Run SharePoint Products and Configuration Wizard
• Post-Installation Steps

Download the SharePoint Cumulative Updates

All starts by downloading the latest SharePoint Cumulative Updates. To do that, you must download:

• SharePoint 2016 and SharePoint 2019:
  • The latest language independent SharePoint updates
  • The latest language dependent SharePoint updates (even if you just have the English language pack installed in your farm)
• SharePoint 2013:
  • The latest SharePoint 2013 Server updates (if you have SharePoint 2013 Server installed)
  • The latest SharePoint Foundation 2013 updates (if you have only SharePoint Foundation 2013 installed). This update is not necessary if you have SharePoint 2013 Server since SharePoint Foundation 2013 is included in SharePoint 2013 Server

To stay up to date and download the latest updates, click here for SharePoint 2019, here for SharePoint 2016 and here for SharePoint 2013.

Backup SharePoint Farm and Configurations

Before applying the updates, you should perform the following backups:

• Backup the SharePoint farm by running the following command:
  Backup-SPFarm -Directory <BackupFolder> -BackupMethod Full -Verbose

The backup folder should be a shared folder on the network, accessible by both SharePoint and database servers.

Ensure the SharePoint Server VSS Writer service is started on the SharePoint server (not started automatically).

Ensure the SQL Server VSS Writer service is started on the database server.

For more details about SharePoint farm backup, click here, here and here

• Backup all SharePoint databases in the database server that supports the SharePoint farm using SQL Server Enterprise tools
• Backup the web.config files for all web applications
• If you have custom developed solutions using server-side code, backup the solutions. To make this easier, you can download a PowerShell script from my GitHub repository

Pre-Installation Steps

To ensure that no crawls are started or running during the Cumulative Update installation, it is very import to suspend the Search Service. If a search crawl was triggered during the installation, the Search Application could get corrupted and you could be forced to rebuild the entire Search Service Application, recreate any custom managed properties and perform a Full Crawl again to ensure you have search results and all search based solutions work properly.

To avoid these problems and ensure there are no search crawls running during the installation, execute the following PowerShell command:

Suspend-SPEnterpriseSearchServiceApplication –Identity “<Search Service Application Name>”

Install the Cumulative Updates in the SharePoint Farm

After downloading the latest updates and taking the necessary precautions, you are ready to install them in your SharePoint farm.

First, install the language independent update:

The update will take a few minutes, depending on your server capabilities.

After a few minutes, the update finishes the installation and a reboot to the server is necessary.

If you have a language dependent update, install it after installing the language independent update:

The update will take a few minutes, depending on your server capabilities. In my case, I installed the Portuguese (Portugal) Language Pack Cumulative Update.

After a few minutes, the update finishes the installation.

Run SharePoint Products and Configuration Wizard

To finish the farm update process, you must ensure that after the updates are properly installed, you execute the SharePoint Products and Configuration Wizard that will ensure the following:

• The database schema for all SharePoint databases is updated to the latest version
• Copies the required binaries from the install location into the _app_bin directories of all web applications
  
• Fixes security settings on the file system to match SharePoint’s needs
• Updates features registrations with SharePoint

To start, run the SharePoint Products and Configuration Wizard and select Yes when prompted to reset IIS, SharePoint Administration and SharePoint Timer services.

Depending on your environment, the process will take some minutes to execute the 10 steps of the process.

After a few minutes, the SharePoint Products Configuration Wizard will finish executing, hopefully with success.

After clicking on Finish, the Central Administration will automatically be launched.

Post-Installation Steps

To ensure that the farm was successfully updated, it is important to check that the Databases Upgrade Status page.

If the page shows any database still needing upgrade (showing the “Database is in compatibility range and upgrade is recommended” status), some additional steps must be followed.

These steps must also be followed if you encounter the error below while running SharePoint Products and Configuration Wizard, saying that there is a mismatch between SharePoint installed version (after updating the farm) and the database schema version.

To ensure all databases are properly upgraded, follow the following steps:

• Upgrade the content databases by executing the following PowerShell command (executed with “run as administrator”):

Get-SPContentDatabase | Upgrade-SPContentDatabase

• Upgrade the remaining content databases, executing the following command (in command prompt with “run as administrator”):

Psconfig.exe -cmd upgrade -inplace b2b -wait -force

• Run the SharePoint Products and Configuration Wizard (PSCONFIGUI.EXE) again. After running SharePoint Products and Configuration Wizard again, it should run without errors.

To confirm the databases upgrade was successful, go back to the Databases Upgrade Status page. After the previous steps, all SharePoint databases were successfully upgraded.

To ensure the upgrade process was successfully finished, go to the Patch Status page and the Upgrade Status page.

Finally, after the farm is updated, you can resume the Search Service Application, running the following PowerShell command:

Resume-SPEnterpriseSearchServiceApplication –Identity “<Search Service Application Name>”

Important Notes

Some important notes on using SharePoint Products and Configuration Wizard (PSCONFIGUI.EXE) and PSCONFIG.EXE (command line version):

• You should not run PSCONFIG.EXE as a replacement of SharePoint Products and Configuration Wizard (PSCONFIGUI.EXE)
  • PSCONFIGUI.EXE is the UI based configuration wizard which performs several tasks one after the other after installing fixes. It is the preferred option to ensure that the SharePoint farm update is completed after installing updates in your SharePoint farm
  • PSCONFIG.EXE is the command line tool which gives users granular control over all tasks that are executed and which is therefore often quicker than PSCONFIGUI.EXE but if misused will not make all the necessary tasks required after installing updates in your SharePoint farm
  • If you want to run PSCONFIG.EXE, ensure you run it with the correct parameters: “PSConfig.exe -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures -cmd secureresources -cmd services -install”
    • Above, I used “Psconfig.exe -cmd upgrade -inplace b2b -wait -force” since I already had used
      SharePoint Products and Configuration Wizard (PSCONFIGUI.EXE) and the only thing I wanted to ensure was that SharePoint databases schema were upgraded
• PSCONFIGUI.EXE should always be executed even when installing SharePoint security updates

For more details, check Stefan Goßner’s articles here and here.

Troubleshooting

During an update there are a few errors that can occur while the patch is being validated against your SharePoint environment before is starts being installed. The most common errors are the following:

• “The expected version of the product was not found on the system” – this article by Stefan Goßner explains the error in detail and what can cause it. Basically, SharePoint is typically composed of the following components:
  • SharePoint Server or SharePoint Foundation*
  • SharePoint Server or SharePoint Foundation English Language Pack*
  • Any additional SharePoint Server or SharePoint Foundation Language Packs*
    
    * – SharePoint Foundation existed from SharePoint 2007 to SharePoint 2013 and in SharePoint 2016 and 2019, only SharePoint Server is available
    
    To solve this error, you must ensure that all components have the same patch level. If any of the installed components has a lower patch level or doesn’t meet the Cumulative Update Prerequisites, the error above will be shown and you won’t be able to install the Cumulative Update in your SharePoint farm.
    
    Example: Install the May 2019 Cumulative Update in a SharePoint 2013 farm that has Service Pack 1 (15.0.4571.1502 patch level). The installed components have the following patch levels:SharePoint Server 2013 – 15.0.4571.1502 (Service Pack 1)
    SharePoint Server 2013 English Language Pack – 15.0.4571.1502 (Service Pack 1)
    SharePoint Server 2013 Portuguese Language Pack – 15.0.4420.1017 (RTM)
    
    The “The expected version of the product was not found on the system” error will be shown since of one of the components (the Portuguese Language Pack) has a lower patch level. To solve this, you must install the SharePoint Server 2013 Portuguese Language Pack Service Pack 1 (you can get the download link here)
    
    To help you to identify the problem, you can use Roiscan which generates a detailed report of all installed Office components, including SharePoint, and verify the patch level of each components.
    
    You can also take a look at this article that can help you ensure that the information about all installed patches is correctly updated in the SharePoint configuration database.
• “No product installed for contained patch” – this can occur if you are installing a Cumulative Update for the wrong version of SharePoint. The most common case is when you are trying to install the SharePoint Foundation 2013 Cumulative Update in a SharePoint Server 2013 farm. In this case, you only need to install the SharePoint 2013 Server Cumulative Update

Other errors can occur while trying to run SharePoint Products and Configuration Wizard after installing the patch:

• “Feature is referenced in database but isn’t installed on the current farm” – this is more common in an farm upgrade scenario (ex: upgrade from SharePoint 2013 to SharePoint 2019) but can also occur while installing a SharePoint Service Pack or Cumulative Update. To learn more details about this error and how to solve it, click here.
• “An update conflict has occurred, and you must re-try this action.” when you run the following command “Psconfig.exe -cmd upgrade -inplace b2b -wait -force”. If you take a look at the ULS Logs, you may find messages like “PSCONFIG.EXE (0x1A8C) UpdatedConcurrencyException: The object SPUpgradeSession Name=Upgrade-20190531-122515-42 was updated by another user. Determine if these changes will conflict, resolve any differences, and reapply the second change. This error may also indicate a programming error caused by obtaining two copies of the same object in a single thread.”. To solve this problem, execute the following command:
  
  PSConfig.exe -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures -cmd secureresources
  
  NOTE: After solving these issues, to finish the process, run SharePoint Products and Configuration Wizard again.

Related Articles

To learn why your business should migrate to SharePoint Online and Office 365, click here and here.

If you want to convert your tenant’s root classic site into a modern SharePoint site, click here.

If you are a SharePoint administrator or a SharePoint developer who wants to learn more about how to install a SharePoint 2019 farm in an automated way using PowerShell, I invite you to click here and here.

If you learn how to greatly speed up your SharePoint farm update process to ensure your SharePoint farm keeps updated and you stay one step closer to start your move to the cloud, click here.

If you want to learn how to upgrade a SharePoint 2013 farm to SharePoint 2019, click here and here.

If SharePoint 2019 is still not an option, you can learn more about how to install a SharePoint 2016 farm in an automated way using PowerShell, click here and here.

If you want to learn how to upgrade a SharePoint 2010 farm to SharePoint 2016, click here and here.

If you are new to SharePoint and Office 365 and want to learn all about it, take a look at these learning resources.

If you are work in a large organization who is using Office 365 or thinking to move to Office 365 and is considering between a single or multiple Office 365 tenants, I invite you to read this article.

If you want to know all about the latest SharePoint and Office 365 announcements from SharePoint Conference 2019, click here and here.

If your organization is still not ready to go all in to SharePoint Online and Office 365, a hybrid scenario may be the best choice. SharePoint 2019 RTM was recently announced and if you to learn all about SharePoint 2019 and all its features, click here.

Happy SharePointing!

The post How to install SharePoint Cumulative Updates in a SharePoint Farm Step by Step appeared first on Blog IT.

To read the first part, click here.

Introduction

The SharePoint world is rapidly moving into the Cloud with SharePoint Online and Office 365, but some organizations are still not ready to move completely to Office 365 and SharePoint Online.

Upgrading to SharePoint 2019 that has support for a hybrid scenario can be a valid solution to allow a gradual move to the cloud.

This post is based on upgrading a SharePoint 2013 farm to SharePoint 2019 using the database attach approach but should also be valid if you want to upgrade to SharePoint 2019. This post assumes that the we will only migrate the content database(s) from the source SharePoint 2013 to SharePoint 2019 and all other SharePoint databases are created in the target SharePoint 2019 farm during its installation process.

If you want to learn more about how to install a SharePoint 2019 farm in an automated way using PowerShell, click here and here.

There is another valid migration approach to migrate from SharePoint 2013 to SharePoint 2019 by using a content migration. In this approach, the upgrade is not based in a database upgrade process but on content migration and typically a 3rd party solution is necessary to do the content migration. A few 3rd party solutions that can do the job are ShareGate, AvePoint and Metalogix.

Upgrading a SharePoint farm using the database attach approach can be a complex task and the upgrade process is composed by a series of steps:

• Migrating Custom Developed Solutions from SharePoint 2013 to SharePoint 2019
  (details about the migration of custom solutions are outside of the scope of this post)
• Upgrade to a temporary SharePoint 2016 farm
• Upgrade to the target SharePoint 2019 farm

IMPORTANT NOTE: In a typical upgrade process, the below steps should be performed twice if there are custom developed solutions:

• The first time, to test the migration process and allow custom developed solutions to be properly migrated and tested by the end users
• The second time, to perform the final migration, after all custom developed solutions are migrated and tested by the end users

This post will cover:

• Upgrade to the target SharePoint 2019 farm

Upgrade to the target SharePoint 2019 farm

IMPORTANT NOTE: Migrating from SharePoint 2013 directly to SharePoint 2019 is not supported. To migrate from SharePoint 2013 to SharePoint 2019 we must first migrate to a temporary SharePoint 2016 farm and then migrate to SharePoint 2019.

The migration is performed using the database attach upgrade method (the only supported method to upgrade from SharePoint 2013 to SharePoint 2019 using a database upgrade approach).

In the upgrade process, for both the temporary SharePoint 2016 and the target SharePoint 2019 farms, you should create an empty web application so that a valid SharePoint content database is created. To learn more on how to install a SharePoint 2019 farm, click here and here.

After having all custom developed solutions migrated to SharePoint 2019 (if there are any), you should follow the following steps:

• SharePoint 2016: Go to “Manage content databases” in Central Administration, select the web application and then the option “Remove content database”. This will make the web application unattached from any web application in the temporary SharePoint 2016 farm

• SharePoint 2016 Database Server (final migration only): Place the database in read-write mode so that users will be able to change content in the target SharePoint 2019 farm. This can be achieved by the following T-SQL command: ALTER DATABASE <CONTENT_DB_NAME> SET read_write
• SharePoint 2016 Database Server: Backup of the content database(s)

• SharePoint 2016 (final migration only): Go to “Manage content databases” in Central Administration, select the web application, then the option “Add content database” and finally select the name of the content database previously removed. This will make the web application available again in the temporary SharePoint 2016 farm

• SharePoint 2019 Database Server: Copy the database backup file from the temporary SharePoint 2016 database server to the database server that supports the target SharePoint 2019 farm
• SharePoint 2019: Go to “Manage content databases” in Central Administration, select the web application where you want to migrate to and then the option “Remove content database”. This will make the database unattached from any web application.

• SharePoint 2019 Database Server: Restore the content database backup from the temporary SharePoint 2016 database server. The restore must replace the content database that was created during the SharePoint 2019 installation.

• SharePoint 2019: If you have custom developed farm solutions, deploy all the migrated WSPs in the target SharePoint 2019 farm.
• SharePoint 2019: As a farm administrator, execute the first of a series of PowerShell commands to associate the restored content database to the SharePoint 2019 farm (in this example the web application URL is http://sp2019): Test-SPContentDatabase -Name <Content_DB_Name> -WebApplication http://sp2019
  
  • This PowerShell cmdlet will test the content database against the web application to verify if all customizations referenced within the content database are also installed in the farm
  • In my case, I got some missing features errors but none of them are upgrade blocking

• SharePoint 2019: As a farm administrator, execute the second of a series of PowerShell commands to associate the restored content database to the SharePoint 2019 farm: Mount-SPContentDatabase -Name “<Content_DB_Name>” -DatabaseServer “<DBAlias>” -WebApplication “http://sp2019”
  • This PowerShell cmdlet attaches an existing content database to a web application
  • In my case, no errors or warnings were shown

• SharePoint 2019: As a farm administrator, execute the third of a series of PowerShell commands to associate the restored content database to the SharePoint 2019 farm: Test-SPSite http://sp2019
  • This PowerShell cmdlet runs a series of health checks on the site collection and its contents
  • In my case, I got a warning but once again nothing that is upgrade blocking

• SharePoint 2019: As a farm administrator, execute the fourth of a series of PowerShell commands to associate the restored content database to the SharePoint 2019 farm: Repair-SPSite -identity http://sp2019
  • This PowerShell cmdlet is similar to the Test-SPSite cmdlet but fixes any issues that it finds
  • The result was identical to the Test-SPSite cmdlet: no upgrading blocking issues were found

• SharePoint 2019: As a farm administrator, execute the fifth of a series of PowerShell commands to associate the restored content database to the SharePoint 2019 farm: Upgrade-SPSite http://sp2019 -VersionUpgrade
  • This PowerShell cmdlet will upgrade the site collections associated to the web application to SharePoint 2019 mode. Before this cmdlet was executed, the site collections were still in SharePoint 2016 mode.

After the migration is complete, your SharePoint web application is successfully displayed in your brand new SharePoint 2019 environment! The site is presented using the classic site experience, but from now on, you will be able to take advantage of the new modern experiences in your SharePoint 2019 environment!

To download the SharePoint 2019 migration PowerShell files, click here.

To read the first part of this two part step by step tutorial, click here.

Related Articles

To learn why your business should migrate to SharePoint Online and Office 365, click here and here.

If you are a SharePoint administrator or a SharePoint developer who wants to learn more about how to install a SharePoint 2019 farm in an automated way using PowerShell, I invite you to click here and here.

If you want to learn all the steps and precautions necessary to successfully keep your SharePoint farm updated and be ready to start your move to the cloud, click here.

If you learn how to greatly speed up your SharePoint farm update process to ensure your SharePoint farm keeps updated and you stay one step closer to start your move to the cloud, click here.

If SharePoint 2019 is still not an option, you can learn more about how to install a SharePoint 2016 farm in an automated way using PowerShell, here and here.

If you want to learn how to upgrade a SharePoint 2010 farm to SharePoint 2016, click here and here.

If you are new to SharePoint and Office 365 and want to learn all about it, take a look at these learning resources.

If you are work in a large organization who is using Office 365 or thinking to move to Office 365 and is considering between a single or multiple Office 365 tenants, I invite you to read this article.

If you want to know all about the latest SharePoint and Office 365 announcements from SharePoint Conference 2019, click here and here.

If your organization is still not ready to go all in to SharePoint Online and Office 365, a hybrid scenario may be the best choice. SharePoint 2019 RTM was recently announced and if you to learn all about SharePoint 2019 and all its features, click here.

Happy SharePointing!

The post How to upgrade from SharePoint 2013 to SharePoint 2019 Step by Step (Part 2) appeared first on Blog IT.

To read the second part, click here.

Introduction

The SharePoint world is rapidly moving into the Cloud with SharePoint Online and Office 365, but some organizations are still not ready to move completely to Office 365 and SharePoint Online.

Upgrading to SharePoint 2019 that has support for a hybrid scenario can be a valid solution to allow a gradual move to the cloud.

This post is based on upgrading a SharePoint 2013 farm to SharePoint 2019 using the database attach approach but is also valid if you want to upgrade to SharePoint 2016 (to learn more about upgrading to SharePoint 2016, click here and here). This post assumes that the we will only migrate the content database(s) from the source SharePoint 2013 to SharePoint 2019 and all other SharePoint databases are created in the target SharePoint 2019 farm during its installation process.

If you want to learn more about how to install a SharePoint 2019 farm in an automated way using PowerShell, click here and here.

There is another valid migration approach to migrate from SharePoint 2013 to SharePoint 2019 by using a content migration. In this approach, the upgrade is not based in a database upgrade process but on content migration and typically a 3rd party solution is necessary to do the content migration. A few 3rd party solutions that can do the job are ShareGate, AvePoint and Metalogix.

Upgrading a SharePoint farm using the database attach approach can be a complex task and the upgrade process is composed by a series of steps:

• Migrating Custom Developed Solutions from SharePoint 2013 to SharePoint 2019 (outside of the scope of this post)
• Upgrade to a temporary SharePoint 2016 farm
• Upgrade to the target SharePoint 2019 farm

IMPORTANT NOTE: In a typical upgrade process, the below steps should be performed twice if there are custom developed solutions:

• The first time, to test the migration process and allow custom developed solutions to be properly migrated and tested by the end users
• The second time, to perform the final migration, after all custom developed solutions are migrated and tested by the end users

This post will cover:

• Migrating Custom Developed Solutions from SharePoint 2013 to SharePoint 2019 (details about the migration of custom solutions are outside of the scope of this post)
• Upgrade to a temporary SharePoint 2016 farm

Migrating Custom Developed Solutions from SharePoint 2013 to SharePoint 2019

This step is outside the scope of this post but a few notes are important to mention if you have custom developed solutions that you want to migrate from SharePoint 2013 to SharePoint 2019:

• First, you should analyze the source SharePoint 2013 farm and look for custom developed solutions and in particular for farm solutions and/or sandboxed solutions
• If custom developed solutions are found and if you want to take the easiest migration path, you could simply upgrade your custom developed solutions to SharePoint 2019 without changing the solution architecture. This typically involves migrating server-side code from SharePoint 2013 to SharePoint 2019, possible migration of master pages and adjustments to CSS and JS files
• Despite more difficult, if possible, you should consider migrating the existing solutions to one of the following development models:
  • SharePoint Framework: the latest and the recommended development model for modern SharePoint solutions, enabling an easier migration path to SharePoint Online and Office 365
  • SharePoint Add-Ins: this development model is still supported and can be a valid solution depending on your scenario. However, when possible. you should consider migrating solutions to the SharePoint Framework development model

Upgrade into a temporary SharePoint 2016 farm

IMPORTANT NOTES:

• Migrating from SharePoint 2013 directly to SharePoint 2019 is not supported. To migrate from SharePoint 2013 to SharePoint 2019 we must first migrate to a temporary SharePoint 2016 farm and then migrate to SharePoint 2019
• To to be able to migrate to SharePoint 2016 and then to SharePoint 2019, the SharePoint 2013 farm must at least have the March 2013 Public Update installed. For more details, click here

The migration is performed using the database attach upgrade method (the only supported method to upgrade from SharePoint 2013 to SharePoint 2019 using a database upgrade approach).

In the upgrade process, for both the temporary SharePoint 2016 and the target SharePoint 2019 farms, you should create an empty web application so that a valid SharePoint content database is created. To learn more on how to install a SharePoint 2019 farm, click here and here.

After having all custom developed solutions migrated to SharePoint 2019 (if there are any), you should follow the following steps:

• SharePoint 2013 (test migration only): Export all WSPs from the SharePoint 2013 farm to file system. To export the WSP files, you can use this PowerShell script.
  SharePoint 2013 (final migration only): Go to “Manage content databases” in Central Administration, select the web application and then the option “Remove content database”. This will temporarily make the web application unavailable in the source SharePoint 2013 farm

• SharePoint 2013 Database Server (final migration only): Place the database in read-only mode to ensure the source web application is made available again and so that users cannot change content anymore during the upgrade process. This can be achieved by the following T-SQL command: ALTER DATABASE <CONTENT_DB_NAME> SET read_only
• SharePoint 2013 Database Server: Backup of the content database(s) (in read-only mode in the final migration)

• SharePoint 2013 (final migration only): Go to “Manage content databases” in Central Administration, select the web application, then the option “Add content database” and finally select the name of the content database previously removed. This will make the web application available again in the source SharePoint 2013 farm in read-only mode, preventing users from changing any content

• SharePoint 2016 Database Server: Copy the database backup file from the source SharePoint 2013 database server to the database server that supports the temporary SharePoint 2016 farm
• SharePoint 2016: Go to “Manage content databases” in Central Administration, select the web application where you want to migrate to and then the option “Remove content database”. This will make the database unattached from any web application.

• SharePoint 2016 Database Server: Restore the content database backup from the source SharePoint 2013 database server. The restore must replace the content database that was created during the SharePoint 2016 installation.

• SharePoint 2016: If you have custom developed farm solutions, add all the exported WSPs (without deploying them) in the temporary SharePoint 2016 farm. For each WSP, run the following command:
  • Add-SPSolution -LiteralPath $location\solution.wsp where $location is the file system location of the WSP files
• SharePoint 2016: Execute the first of a series of PowerShell commands to associate the restored content database to the temporary SharePoint 2016 farm (in this example the web application URL is http://sp2016): Test-SPContentDatabase -Name <Content_DB_Name> -WebApplication http://sp2016
  
  • This PowerShell cmdlet will test the content database against the web application to verify if all customizations referenced within the content database are also installed in the farm
  • In my case, I got some warnings but none of them are upgrade blocking

• SharePoint 2016: Execute the second of a series of PowerShell commands to associate the restored content database to the temporary SharePoint 2016 farm: Mount-SPContentDatabase -Name “<Content_DB_Name>” -DatabaseServer “<DBAlias>” -WebApplication “http://sp2016”
  • This PowerShell cmdlet attaches an existing content database to a web application
  • In my case, no errors or warnings were shown

• SharePoint 2016: Execute the third of a series of PowerShell commands to associate the restored content database to the temporary SharePoint 2016 farm: Test-SPSite http://sp2016
  • This PowerShell cmdlet runs a series of health checks on the site collection and its contents
  • In my case, I got a warning but once again nothing that is upgrade blocking

• SharePoint 2016: Execute the fourth of a series of PowerShell commands to associate the restored content database to the temporary SharePoint 2016 farm: Repair-SPSite -identity http://sp2016
  • This PowerShell cmdlet is similar to the Test-SPSite cmdlet but fixes any issues that it finds
  • The result was identical to the Test-SPSite cmdlet: no upgrading blocking issues were found

• SharePoint 2016: Execute the fifth of a series of PowerShell commands to associate the restored content database to the temporary SharePoint 2016 farm: Upgrade-SPSite http://sp2016 -VersionUpgrade
  • This PowerShell cmdlet will upgrade the site collections associated to the web application to SharePoint 2016 mode. Before this cmdlet was executed, the site collections were still in SharePoint 2013 mode.

To download the SharePoint 2016 migration PowerShell files, click here.

To read the second part of this two part step by step tutorial, click here.

Related Articles

If you want to convert your tenant’s root classic site into a modern SharePoint site, click here.

To learn why your business should migrate to SharePoint Online and Office 365, click here and here.

If you are a SharePoint administrator or a SharePoint developer who wants to learn more about how to install a SharePoint 2019 farm in an automated way using PowerShell, I invite you to click here and here.

If you want to learn all the steps and precautions necessary to successfully keep your SharePoint farm updated and be ready to start your move to the cloud, click here.

If you learn how to greatly speed up your SharePoint farm update process to ensure your SharePoint farm keeps updated and you stay one step closer to start your move to the cloud, click here.

If SharePoint 2019 is still not an option, you can learn more about how to install a SharePoint 2016 farm in an automated way using PowerShell, here and here.

If you want to learn how to upgrade a SharePoint 2010 farm to SharePoint 2016, click here and here.

If you are new to SharePoint and Office 365 and want to learn all about it, take a look at these learning resources.

If you are work in a large organization who is using Office 365 or thinking to move to Office 365 and is considering between a single or multiple Office 365 tenants, I invite you to read this article.

If you want to know all about the latest SharePoint and Office 365 announcements from SharePoint Conference 2019, click here and here.

If your organization is still not ready to go all in to SharePoint Online and Office 365, a hybrid scenario may be the best choice. SharePoint 2019 RTM was recently announced and if you to learn all about SharePoint 2019 and all its features, click here.

Happy SharePointing!

The post How to upgrade from SharePoint 2013 to SharePoint 2019 Step by Step (Part 1) appeared first on Blog IT.

Recently, a customer reported problems with Search in a SharePoint 2013 farm. Instead of showing search results, the following error was being shown:

The Problem

To diagnose the problem, I opened Central Administration and the Search Service Application page indicated problems with the Index Partition component in the Search Service Application Topology.

To further diagnose the problem, I opened up a PowerShell window (used the option “Run As Administrator” to ensure proper permissions) and executed the following commands:

$ssa = Get-SPServiceApplication -Name “Search Service Application”
Get-SPEnterpriseSearchStatus -SearchApplication $ssa -Detailed -Text

After execution, the result confirmed a problem with the Index Partition, showing the Index component with the Degraded state. According to Microsoft “The reason for the degraded status is typically a transient situation related to a restart or network issues” but from my experience it is not easy to understand why this happens.

The Solution

The solution was composed by two steps:

• Reset the Search Index – this operation will clear all index content but will NOT delete any custom managed properties you may have created in the search service application
• Perform a Full Crawl on Search Content Source to crawl and reindex all your content

Reset the Search Index

To reset the Search Index, I went to the Reset Index page in the Search Service Application in Central Administration and clicked the “Reset Now” button.

To confirm the Index Reset, I clicked “OK” in the popup message.

Perform a Full Crawl on Search Content Sources

After resetting the index, the search index data was deleted and to allow search results to be shown again, we need to perform a Full Crawl on all Content Sources in the farm. To do that, we must go to the Content Sources page in the Search Service Application in Central Administration and for each available Content Sources, select “Start Full Crawl”.

NOTE: If you have more than one Content Source, let the Full Crawl on the previous Content Source finish before starting to Full Crawl the next Content Source.

After the Full Crawl on all Content Sources finished, I returned to Central Administration and the Search Service Application page to check the Search Service Application status. The page now indicates a healthy status for all Search components.

To confirm that the problem is solved, I ran the same commands previously executed in the PowerShell window.

$ssa = Get-SPServiceApplication -Name “Search Service Application”
Get-SPEnterpriseSearchStatus -SearchApplication $ssa -Detailed -Text

After execution, the result confirms that the problem with the Index Partion is solved,
showing an Activate state in the Index component.

After the above steps, SharePoint sites started returning search results again!

Related Articles

If you want to convert your tenant’s root classic site into a modern SharePoint site, click here.

This solution should be also valid for SharePoint 2016 and SharePoint 2019. If you want to know all about the new features available in the new SharePoint Server release, click here.

To find a solution to a search crawling issue I recently found in a SharePoint 2016 farm, click here.

To learn why your business should migrate to SharePoint Online and Office 365, click here and here.

SharePoint 2019 RTM was recently announced! To learn all about SharePoint 2019 and all its features, click here.

If you are a SharePoint administrator or a SharePoint developer who wants to learn more about how to install a SharePoint 2019 farm in an automated way using PowerShell, I invite you to click here and here.

If you want to learn how to upgrade a SharePoint 2013 farm to SharePoint 2019, click here and here.

If you want to learn all the steps and precautions necessary to successfully keep your SharePoint farm updated and be ready to start your move to the cloud, click here.

If you learn how to greatly speed up your SharePoint farm update process to ensure your SharePoint farm keeps updated and you stay one step closer to start your move to the cloud, click here.

If SharePoint 2019 is still not an option, you can learn more about how to install a SharePoint 2016 farm in an automated way using PowerShell, click here and here.

If you are involved in a SharePoint upgrade and want to learn more about the upgrade process, click here and here.

If you are new to SharePoint and Office 365 and want to learn all about it, take a look at these learning resources.

If you are work in a large organization who is using Office 365 or thinking to move to Office 365 and is considering between a single or multiple Office 365 tenants, I invite you to read this article.

If you want to know all about the latest SharePoint and Office 365 announcements from SharePoint Conference 2019, click here and here.

Hope this can help someone with the same problem!

Happy SharePointing!

The post How To Fix a Degraded Search Index Partition in a SharePoint 2013 farm appeared first on Blog IT.

The programme team did a great job going through over 700 session submissions and putting together a stellar lineup of great speakers while also broadening the scope of the conference to include Office 365 and Microsoft Azure along with the SharePoint-related content. Congratulations to Wim Dierickx, Göran Husman, Adis Jugo and Nicki Borell. I was on the programme team last year and I know how hard it is to select the sessions and speakers, and put together a compelling programme.

The first keynote was delivered by Seth Patton, Jeff Tepper and Bill Baer, and this fact alone demonstrates how much Microsoft is invested in connecting with the community. The keynote was mostly focused on:

• Usage and adoption statistics for Office 365
• New and improved features that recently rolled out in Office 365
• Near future roadmap for Office 365
• What’s New in SharePoint Server 2016

Regarding usage and adoption, Office 365 has some impressive statistics:

• Over 75,000 customers which account for more than 160 million users
• 200% monthly active user growth
• 7 Billion Office documents stored in OneDrive for Business, team sites and other SharePoint portals, which represents a 500% year-on-year growth in content
• Runs on 30,000 servers, with 20,000 SQL databases, on 19 datacenters around the world.

As for new features and near future roadmap for Office 365, Jeff Tepper and Bill Baer shared that:

• OneDrive for Business will now have a new rock-solid sync client (which has been in preview for a few weeks) and already has mobile apps for all devices. It recently got a revamped UI with a better browsing and sharing experience, and better tooling for IT management.
• SharePoint Online has rolled-out improvements in collaboration, co-authoring and external sharing features.
• The new Office 365 groups and their tight integration with Outlook 2016 is helping people to be more productive, adapting the technology to the users and not the other way around.
• Delve and the Office Graph are also evolving, with new APIs and the new analytics features that are now in development.

The biggest announcement was the release of a second and last beta version of SharePoint Server 2016 before the end of the month, which will be nearly feature complete. The new features of SharePoint Server 2016 were already known since Microsoft Ignite a few months back, but it was still interesting to hear about the enhanced mobile experience, robust and cloud inspired infrastructure, and the compliance and data loss prevention features.

My session was about “Content Recommendation with SharePoint Search” and I think it was well received by the 100 or so attendees in the room, but having to deliver a session on the afternoon of the last day usually means I’m not going to enjoy the conference because I’ll be too worried fine tuning the slides and demos, and practicing the presentation until almost the end. If you’re interested in the presentation contents check the slide deck on SlideShare.

Nevertheless, I still managed to attend a few sessions by really good presenters:

• Radi Atanassov (@RadiAtanassov) presented a great session on Office 365 Dev Patterns and Practices.
• Chris O’Brien (@ChrisO_Brien) gave some fantastic tips on what you should and shouldn’t do when developing for Office 365.
• Marius Constantinescu (@c_marius) showed us how to use Lightswitch to build cloud business apps in Visual Studio.
• Nuno Costa (@ndocosta) and João Oliveira (@joaopcoliveira), fellow Portuguese Microsoft guys, delivered a brilliant talk on Office 365 governance with PowerShell and CSOM.
• Rodrigo Pinto (@ScoutmanPt), fellow Portuguese MVP, got to present two great sessions: one on PowerShell Desired State Configuration and another one on techniques to migrate full trust solutions to the add-in model.
• Edin Kapic (@ekapic) made complex topics such as authentication and authorization seem simple as he showed how to build a custom claims provider for SharePoint. Pretty epic stuff.
• Knut Relbe-Moe (@sharePTkarm) dove deep into the Office 365 group and filled a room even on the last session slot of the conference.

It was a nice surprise to find Pedro Serrano and Daniel Pereira from Cave Digital showing off their Smart Governance product in the expo floor, and Alex Ferreira (@alexaem) and Tiago Duarte (@tduarte85) attending the conference. It’s always great meeting Portuguese friends when we’re far away from home.

Overall it was a great experience and the team in charge of the organization has done a tremendous job. If I had to point out three highlights of the event, those would be:

• The venue for the awards gala, which was absolutely fantastic, and the venue for the conference. It will be very hard to top that next year.
• The networking opportunities.
• The speaker and session lineup, which included top Microsoft executives.

Next year the European SharePoint Conference will take place in Vienna, Austria, on November 14-17, and I hope I can be there again.

The post the European SharePoint Conference 2015 was great! appeared first on Blog IT.

The conference will take place in Stockholm, Sweden, from November 9^th to November 12^th, and has a fantastic session lineup from some of the best speakers in the business. The programme team did a great job putting it together. I know how hard it is to select 100 breakout sessions and 8 full-day tutorials out of several hundred candidates to build a balanced and interesting session lineup.

If you have not attended in previous years, I highly recommend it. It’s well worth it.
You still have 7 days to grab the ticket at Super Early Booking Rate (ends on April 17^th) so, if you’re considering attending, don’t wait!

I’ll see you there!

The post European SharePoint Conference 2015 appeared first on Blog IT.

Here’s what I’ll be talking about:

Information security is one of the most important concerns when designing a content management solution. Learn about Information Rights Management (IRM) and what it allows you to do to protect your information and control its usage. Learn how it can be applied to SharePoint 2013 and SharePoint Online and the main differences between the way it works in each version.

In this webinar for IT Pro’s you will:

1. Learn what is Information Rights Management (IRM)
2. Learn how IRM works in SharePoint 2013 and SharePoint Online
3. Learn how to manage IRM

You can register for my webinar on Information Rights Management here. I hope you can join me!

The post Webinar: Information Rights Management in SharePoint appeared first on Blog IT.

The following example shows how you you can create a custom webpart that modifies the search query string of a content search web part that exists in the same page.

Setup: Add a visual web part to your SharePoint project and add the Newton-King Json.NET reference to your project

1. On Visual Studio, open your project solution, right click your project folder and select “Add Item “
2. In the Add New Item menu select “Office/SharePoint” ->  VisualWebPart, give a name ex: “WebPartConfigurator”
3. Add James Newton-King Json.NET .dll to your project.  This will make it extremely easy to edit the search query once you get it from the target webpart. (you can find it here: http://james.newtonking.com/json)

Code: Follow 3 steps -> Get the the LimitedWebPartManager, get the target content search  webpart, configure the  query string in the target content search webpart.

1. Add the following to your class header:

using System.Linq; //For accessing the web part
using Newtonsoft.Json.Linq; // For editing the webparts search query (Json). Don't forget to add a reference to this lib on your project.

2. Uncomment PageLoad method and add the following code:

//Get the page
SPFile membersPage = SPContext.Current.File;
SPLimitedWebPartManager limitedWebpartManager;

//Get the page's Limited Web Part Manager using (limitedWebPartManager = membersPage.GetLimitedWebPartManager(PersonalizationScope.Shared)) {                     ////Gets all the the webpart with "YOUR_WEB_PART_NAME_HERE" name if they exist                     System.Collections.Generic.List<System.Web.UI.WebControls.WebParts.WebPart> searchWebParts = limitedWebPartManager.WebParts.Cast<System.Web.UI.WebControls.WebParts.WebPart>().Where(webpart => webpart.Title == "YOUR_WEB_PART_NAME").ToList();                      ////If any web part is found runs the configuration method "ConfigureWebpart" on it                     if (membersWebParts.Count > 0)                     {                         foreach (System.Web.UI.WebControls.WebParts.WebPart webPart in membersWebParts)                         {                             ////Run the configuration method on your target webpart ConfigureWebPart(webPart); ////Save all the changes made to your target webpart!!!!!!!                             limitedWebPartManager.SaveChanges(webPart);                         }                                                  } } ////Updates all the changes made to the page elements membersPage.Update();

3. Add your ConfigureWebPart method. In this case we will change the query string using Newtons-King Json.net lib.

private void ConfigureMembersWebPart(System.Web.UI.WebControls.WebParts.WebPart webPart)
{
            ////Cast the webpart to a ContentSearchWebPart (ResultScriptWebPart in .Net)
            ResultScriptWebPart membersWebPart = (ResultScriptWebPart)webPart;
            
            ////Get the query object
            JObject query = JObject.Parse(membersWebPart.DataProviderJSON);
 
            ////Edit the query object
            query.Property("QueryTemplate").Value = "YOUR_QUERY_HERE";
 
            ////Set the webpart's query object to the newly edited object.
            membersWebPart.DataProviderJSON = query.ToString();
}

Finishing: Add the custom web part to the page of the target webpart.

The post Configure a native webpart using another webpart appeared first on Blog IT.

This is a super short guide to a successful experience with Sharepoint 2013 FBA Pack.  For a fully detailed process please refer to Chris Coulson’s life saving article.

Our goal?

Provide FBA authentication in our SahrePoint application

What we need?

The SharePoint2013FBAPack zip file with the Activate.ps1, Deploy.ps1, UnDeploy.ps1and Visigo.Sharepoint.FormsBasedAuthentication.wsp files.

Our three simple steps?

1. Create users database
2. Install the Sharepoint 2013 FBA Pack
3. Configure web application

1. Create users database

1. Go to c:\windows\Microsoft.NET\Framework64\v4.0.30319\
2. Run “aspnet_regsql.exe”
   1. Choose “Configure SQL Server for application services” -> click Next
3. Now that you have created your users database, you must make sure that the the identity running you SharePoint application pool can access it.
   1. Where can you find this identity?  In IIS ->“Application Pools”. Check the value in the Identity column of you SharePoint application pool. Take a note, you’ll need it later.
      1. Open SQL server as an Administrator -> Go to Security/Logins -> Select the user that matches the identity identified earlier -> Right click -> Select Properties -> Check the “Map” box for the database created previously and check the “db_owner” role. -Now the db is ready!

2 . Install the Sharepoint 2013 FBA Pack

1. If you haven’t download -the pack zip file do it now 🙂 and extract its content
2. Open a Powershell and navigate to the pack extraction path.
3. Run “Set-ExecutionPolicy Unrestricted” and “.\deploy [Site Collection URL]

3. Configure Web Application

Now that we have a membership database,  that our SharePoint pool identity can access it and that the FBA pack is installed, we need to configure the membership provider in the config files.

From the approaches described in Chris Coulson’s life saving article. I would recommend to avoid the approach that involves machine.config editing, because unless  you’re doing something very special you don’t really want to disseminate your apps specifics beyond its scope.

With this in mind, also make sure you always backup  your .config files before editing any “tiniest” change to avoid spending hours trying to resolve a character typo our encoding mistakes.

We are going to add the same changes to three different config files. You can find each of these by navigate through IIS -> right click the application -> Explore -> Double click the “web.config” file :

• SharePoint Central Administration
• SecurityTokenServiceApplication
• Your SharePoint application web application

1. In the <ConnectionString> section add the following line, make sure that [SERVER NAME] matches the fully-qualified name of your db server:

   <add connectionString="Server=[SERVER NAME];Database=aspnetdb;Integrated Security=true" name="[CONNECTION STRING NAME]" />

2. In the <membership><providers> section add the following and make sure that [CONNECTION STRING NAME]  matches the value of the previous step:

   <add name="[MEMBERSHIP PROVIDER NAME]"
    type="System.Web.Security.SqlMembershipProvider, System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
    connectionStringName="[CONNECTION STRING NAME]"
    enablePasswordRetrieval="false"
    enablePasswordReset="true"
    requiresQuestionAndAnswer="false"
    applicationName="/"
    requiresUniqueEmail="true"
    passwordFormat="Hashed"
    maxInvalidPasswordAttempts="5"
    minRequiredPasswordLength="7"
    minRequiredNonalphanumericCharacters="1"
    passwordAttemptWindow="10"
    passwordStrengthRegularExpression="" />

3. In the <roleManager><providers> section add and make sure that [MEMBERSHIP PROVIDER NAME] and [CONNECTION STRING PROVIDER NAME] match the values of the previous steps.:

   <add name="[MEMBERSHIP PROVIDER NAME]" connectionStringName="[CONNECTION STRING NAME]" applicationName="/"
    type="System.Web.Security.SqlRoleProvider, System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />

Now  you’ll be able to add the Membership Provider to your web application when enabling the Forms Based Authentication.

Ok, so… this might not be super-short, but it is short enough. Just be extra careful when editing the config files and you won’t have to worry about anything else.

The post Super short guide to a successful SharePoint 2013 FBA Pack Installation appeared first on Blog IT.