SharePoint, Office 365, Azure, and Front end JS geek. – Chicago IL
SharePoint, Office 365, Azure, and Front end JS geek. – Chicago IL

SharePoint 2010

SPPatchify – CU patch entire farm from one script

Patching can be tedious and time consuming.   Why not automate that?  Who wants to be awake all night clicking “Next” and watching SP config wizard?  So  I coded a single PowerShell script to manage the full end-to-end patching process.

 

The script will …

  • Enable PowerShell client remoting.  Connects to farm peer machines.
  • Autodetect current user password from IIS pools
  • Download Microsoft Cumulative Update (CU) media (EXE +CAB) and copy to all servers.   Optionally, you can download to the \media\ sub folder manually.
  • Stop Distributed Cache (DC)
  • Stop SharePoint services
  • Run EXE binary in paralle
  • Wait for EXE to complete and reboot
  • Dismount-SPContentDatabase
  • Start SharePoint services
  • Run SharePoint Config Wizard serially
  • Mount-SPContentDatabase
  • Remove Microsoft Cumulative Update (CU) media from peer servers
  • Ensure IIS started
  • Launch Central Admin with IE
  • Reboot current PC

 

Duration from start to end is incredibly fast.    I tested a 4 server SharePoint 2013 farm and ran the entire process in just 45 minutes.   Stopping services and dismounting content databases speeds up patching significantly.    Automating serial (one-at-time) Configuration Wizard ensures minimal “think time” between steps.   Removing manual human process gives higher consistency while mitigating risk of error.

The script uses Get-SPServer to auto detect farm members.   That enables CU media copy sideways to peers and the stop/start of SharePoint services.   Get-SPContentDatabase is exported to a local CSV file to “snapshot” before patching and later Mount-SPContentDatabase step to present databases again.   The big goal isn’t zero downtime, but rather minimal downtime.  

The entire farm patching process can be managed from one PowerShell window.  Enjoy! 

shades_smile

 

Please leave a comment if you found this helpful.

 

Get Started

  1. https://github.com/spjeff/sppatchify
  2. Extract to “C:\SPPatchify” on any server in the farm
  3. RDP with farm account and run “C:\SPPatchify\SPPatchify.ps1”

 

Flow Diagram

6

 

Screenshots

image
5
image
image
image
image

References

NEW CodePlex project – SPUpgradeHelper

Today I am happy to announce https://spupgradehelper.codeplex.com/ is available for download.   This project aims to smooth the “double hop” upgrade from MOSS 2007 to SP2010 to SP 2013 by reading a CSV of database targets and automating the Cmdlets needed for a consistent, repeatable, high quality, and fast process.   Please leave a comment here or on CodePlex if you found this helpful.  Cheers! 

shades_smile

 

Project Description

Migrating MOSS 2007 to SP 2013? This script takes a CSV of databases and runs upgrade Cmdlets in bulk (DB version/Mount/Dismount/Upgrade-SPSite/Claims auth)

Upgrading MOSS to SP2013 is a tedious process with many Cmdlets, especially if you have many databases. This script aims to help automate that process.

Given a CSV with SQL instance and content database names, this script offers Cmdlets to run upgrade steps across many databases all at once. No more TXT or XLS copy and paste madness. Simply populate the CSV, get familiar with UH* Cmdlets and upgrade with ease.

Key Features

  • Read CSV of databases
  • Load helper functions into memory
  • Enable admin to more easily run Cmdlets in bulk
  • Measure time duration for each step (# minutes)
  • Provide detailed LOG file of actions, result, and duration

Quick Start Guide

  • Extract “SPUpgradeHelper.ZIP” to any SharePoint machine in your farm
  • Run “SPUpgradeHelper.ps1” to load helper functions
  • Type in full path to your CSV file (i.e. “C:\TEMP\COLLAB.CSV”)

Function Names

  • UHCIaims – execute SPWebApplication function to upgrade Classic to Claims auth
  • UHCompatibiIity – execute Get-SPSite for “set” of databases to show GUI version (14/15)
  • UHDBVersion – execute TSQL for “set” of databases to show build number (12.0, 14.0, 15.0)
  • UHDismount – execute DisMount-SPContentDatabase for “set” of databases
  • UHMount – execute Mount-SPContentDatabase for “set” of databases
  • UHReadCSV – load CSV file into memory with upgrade “set”, SQL instance, and database names
  • UHUpgrade – execute Upgrade-SPSite for “set” of databases

NOTE – Upgrade “set” is meant for running parallel workstreams. For example, two servers with SP2010 and two servers with SP2013. That way overall upgrade can be expedited by running database set “A” through the first SP2010 and SP2013 server while database set “B” runs on the second server.

Microsoft Upgrade Process

InfoPath tip – detect Security Group with List Item permissions

Yes, everyone says InfoPath is dead … but we’re all still supporting it for a while so I wanted to share one of my favorite tips.  Forms often need role based security at the field level.  Table below with example security matrix.

How can InfoPath detect that?   Don’t some people query SOAP ASMX?   Or even a custom WSP with a custom ASMX?   There is a simpler way with List Item permission.  

image
  1. Create a new Custom List named “SecurityLevel” with only the default “Title” column.  
  2. Go create the needed SharePoint Groups under Site Permissions.  
  3. Back in “SecurityLevel” add one new item for each SharePoint Group with an identical name.   Hover that item, pull down the menu, and set Item Level Permissions for that group ONLY to have “Read” on that item only.  
  4. With InfoPath Designer edit the XSN Form Template and create a new Data Connection to the list “SecurityLevel” with auto refresh.  
  5. Under Form Load create a rule … if count(SecurityLevel [“Analyst”]) > 0 then set field “SecurityLevel=Analyst”.   
  6. With that in place you are ready to apply formatting rules anywhere needed that use “SecurityLevel” to determine hide/show or read/write.

 

Voila!

Now when a user open the InfoPath form, the data connection “SecurityLevel” will only show the items they have access to (which is the same as the SharePoint Group membership!).    Works on MOSS 2007, SharePoint 2010, SharePoint 2013, and Office 365.

Hope this helps.  Please leave a comment if it did. 

shades_smile

 

DOWNLOAD  InfoPath Form – SecurityLevel.xsn >>

 

 

image
image
image
image
image

 

image
image
image

Upgrading SP2010 to 2013? Consider AAM redirection

This technique was introduced for upgrades from MOSS 2007 to SP2010 and appears to work nicely with SP2013 too.

The STSADM command still exists, creates HTTP 302 redirect output, and enables farm administrators to more easily manage content database attach upgrades for large Web Applications (i.e. multiple  terabytes).   Considering how content database attach is the only upgrade method for SP2013, the below AAM technique can be a helpful way to gradually upgrade content databases from a SP2010 “source” farm to a SP2013 “destination” farm.  Multiple weekends and longer timelines beyond one day upgrades (small Web Applications) are possible with the help of AAM redirection.

Please keep in mind AAM redirect (HTTP 302) is a temporary solution and best used for as short a time as possible.    The sooner upgrade is complete, the fewer support tickets we are likely to have.  See whitepaper below for how to configure.

 

Using Alternate Access Mapping (AAM) URL redirection as part of the upgrade process (SharePoint Server 2010) (white paper)

Special Considerations

  • Custom Code (DLL/JS)  -  Hardcoded URLs may fail on the “source” web application when it is given a new AAM and temporary URL.
  • InfoPath Forms (XSN)  -  Hardcoded URLs in data connections, hyperlinks, or code may fail.
  • Workflow (XOML)  -  Hardcoded URLs in email body HTML may fail.
  • Incoming Email  -  While AAM handles HTTP browser traffic, it does not facilitate SMTP (port 25) delivery for inbound email enabled lists and libraries.  One possible option here might be the placement of a PowerShell script in Task Scheduler on the “destination” (new SP2013) farm to move old EML files over to the \\sp2010-wfe\c$\inetpub\mailroot\drop\ folder if they are not picked up locally.   A time threshold needs to be decided (i.e. 30 minutes) to give the local SP2013 farm enough time to process while not burden users with “missing” email taking too long to appear.
  • Local HOSTS File -  It may be necessary to enable both the original URL (portal.contoso.com) and temporary URL (portalold.contoso.com) enabled on the “source” (old SP2010) system.   This means IIS binding and local HOSTS loopback so that if SharePoint 2010 attempts to open http://portal.contoso.com/ via loopback for one of the above data connections on a site which hasn’t migrated yet it could successfully do so.   Even though end user DNS will have “portal.contoso.com” pointed at SP2013, the SP2010 machines may need to loopback locally for “portal.contoso.com” to better accommodate SP2010 sites which haven’t migrated.

 

image

 

Note

  • This method is might not be officially supported by Microsoft for SP2010 upgrade to SP2013.  However, quick tests in the lab show HTTP 302 redirects can be created and user traffic successfully redirects.

© Copyright 2016
@ SPJeff

Return to Top ▲Return to Top ▲