Merge pull request MicrosoftDocs#312 from andikrueger/patch-1

Update sharepoint-server-2016-zero-downtime-patching-steps.md

SharePoint/SharePointServer/upgrade-and-update/sharepoint-server-2016-zero-downtime-patching-steps.md

@@ -23,18 +23,18 @@ Zero downtime patching is a method of patching and upgrade developed in SharePoi
 
 A couple of things to note as we discuss ZDP (we'll talk about these elements later in the article).
 
-- Your ZDP experience could be enhanced by using MinRole in SharePoint Server 2016, but MinRole is  *not*  a requirement. 
-    
+- Your ZDP experience could be enhanced by using MinRole in SharePoint Server 2016, but MinRole is  *not*  a requirement.
+
     [Why could MinRole help?](sharepoint-server-2016-zero-downtime-patching-steps.md#BKMK_Min)
-    
-- Your farm must leverage high availability (HA) to reap the benefits of ZDP. A highly available SharePoint Server 2016 farm  *is*  a requirement for ZDP. 
-    
+
+- Your farm must leverage high availability (HA) to reap the benefits of ZDP. A highly available SharePoint Server 2016 farm  *is*  a requirement for ZDP.
+
     [Why is High Availability required?](sharepoint-server-2016-zero-downtime-patching-steps.md#BKMK_HA)
-    
+
 It's important to remember that the goal of ZDP is uptime for your users, so, in this article, all the decisions involved in patching and rebooting your farm will be made with that bias in mind.
 
 > [!IMPORTANT]
-> Even if all the servers in your SharePoint Server 2016 farm were configured to use the 'Custom' role, you can still manually configure a highly available farm. There are [documents on TechNet](https://technet.microsoft.com/en-us/library/cc748824.aspx) that will help you construct highly available farms, and the principals of fault tolerance (having redundant hardware) and high availability (having systems and software in place to support failover and continuation of uptime) are the same. Be aware that in more complex Highly Available or Custom farms, you should take special care to patch the Search servers in a way that supports HA, for example, patch one index replica at a time and never patch or upgrade index replicas from the same partition at the same time. 
+> Even if all the servers in your SharePoint Server 2016 farm were configured to use the 'Custom' role, you can still manually configure a highly available farm. There are [documents on TechNet](https://technet.microsoft.com/en-us/library/cc748824.aspx) that will help you construct highly available farms, and the principals of fault tolerance (having redundant hardware) and high availability (having systems and software in place to support failover and continuation of uptime) are the same. Be aware that in more complex Highly Available or Custom farms, you should take special care to patch the Search servers in a way that supports HA, for example, patch one index replica at a time and never patch or upgrade index replicas from the same partition at the same time.
   
 ## The ZDP Process
 
@@ -49,100 +49,108 @@ Ideologically, you can draw a line through the middle of the farm in this diagra
 For the most part, everything you do on one side of the line (to the 01 servers) you'll exactly repeat for 02. Of all the steps involved in the relatively simple, two phase ZDP process, those taken with the WFEs (SPWeb01 and 02) are the most complex. We'll start there.
 
 > [!NOTE]
-> General information on Software Updates for SharePoint Server 2016 can be found [here](https://technet.microsoft.com/en-us/library/ff806329%28v=office.16%29.aspx). Notice that the article links out to documentation on [permissions settings](https://technet.microsoft.com/en-us/library/cc678863%28v=office.16%29.aspx) for SharePoint Server 2016. Review these articles as needed, and remember that part of patching involves database updates. If you've changed SQL Server permissions for SharePoint accounts post-installation, for example, you'll need to review these articles. 
+> General information on Software Updates for SharePoint Server 2016 can be found [here](https://technet.microsoft.com/en-us/library/ff806329%28v=office.16%29.aspx). Notice that the article links out to documentation on [permissions settings](https://technet.microsoft.com/en-us/library/cc678863%28v=office.16%29.aspx) for SharePoint Server 2016. Review these articles as needed, and remember that part of patching involves database updates. If you've changed SQL Server permissions for SharePoint accounts post-installation, for example, you'll need to review these articles.
   
 Make sure you've rebooted and tested your WFEs before you take either out of the load balancer to avoid situations where the WFE to be patched first is taken out of rotation, and other WFEs don't handle the resulting load. All servers in the farm should be fresh from a reboot and healthy before you patch. Also, consider stopping Search crawls and Profile Imports during the upgrade or patch window.
 
 > [!IMPORTANT]
-> You should enable the side-by-side file copy process before you Upgrade. Running in side-by-side ensures that all the web front ends in the farm serve the same static content during the upgrade, even if static files on a given WFE are being upgraded or replaced. Side-by-side is built in to PSCONFIG but must be enabled. This feature makes sure users have the same experience of the sites when browsing SharePoint and working on their files, even while file-system files are being changed and updated. > To enable side-by-side upgrade capabilities, you will need to open SharePoint 2016 Management Shell and run the following commands on all your SharePoint servers: >  `$webapp = Get-SPWebApplication <webappURL>`>  `$webapp.WebService.EnableSideBySide = $true`>  `$webapp.WebService.update()`> Please note that administrators can opt out of side-by-side by setting the 'enableSideBySide' value to $false. Be aware that this could impact what users see when browsing. They may see upgraded UI in one browse, and not, in another, or may experience issues if, for example, javascript files are being changed or upgraded at the time of their browse. 
+> You should enable the side-by-side file copy process before you Upgrade. Running in side-by-side ensures that all the web front ends in the farm serve the same static content during the upgrade, even if static files on a given WFE are being upgraded or replaced. Side-by-side is built in to PSCONFIG but must be enabled. This feature makes sure users have the same experience of the sites when browsing SharePoint and working on their files, even while file-system files are being changed and updated.  
+> To enable side-by-side upgrade capabilities, you will need to open SharePoint 2016 Management Shell and run the following commands on all your SharePoint servers:  
+> `$webapp = Get-SPWebApplication <webappURL>`  
+> `$webapp.WebService.EnableSideBySide = $true`  
+> `$webapp.WebService.update()`  
+> Please note that administrators can opt out of side-by-side by setting the 'enableSideBySide' value to $false. Be aware that this could impact what users see when browsing. They may see upgraded UI in one browse, and not, in another, or may experience issues if, for example, javascript files are being changed or upgraded at the time of their browse.
   
 ### Phase 1 - Patch install
 
 The first phase is getting the patch binaries on the servers and installing them there.
 
-1. 
-     ![Step 1 in the ZDP process is show in a graphic.](../media/83fe53e5-ace6-4a00-a66f-014982adbc5a.png)
+1. ![Step 1 in the ZDP process is show in a graphic.](../media/83fe53e5-ace6-4a00-a66f-014982adbc5a.png)
 
-    Take the first WFE (SPWeb01) out of the load balancer and patch it with the 'STS' and 'WSS' packages. \> Reboot the server when patching is done. \> Return the server to rotation in the load balancer.
-
-2. 
-     ![Step 2 in ZDP process.](../media/98f51947-6ad2-4909-ad37-5bd0a47ac78e.png)
+    Take the first WFE (SPWeb01) out of the load balancer and patch it with the 'STS' and 'WSS' packages.  
+    Reboot the server when patching is done.  
+    Return the server to rotation in the load balancer.
+
+2. ![Step 2 in ZDP process.](../media/98f51947-6ad2-4909-ad37-5bd0a47ac78e.png)
 
-    Take the second WFE (SPWeb02) out of the load balancer and patch it with the 'STS' and 'WSS' packages. \> Reboot the server when patching is done. \> Leave this server out of the load balancer until the entire upgrade is complete.
-
+    Take the second WFE (SPWeb02) out of the load balancer and patch it with the 'STS' and 'WSS' packages.  
+    Reboot the server when patching is done.  
+    Leave this server out of the load balancer until the entire upgrade is complete.
+
     > [!NOTE]
-    > If you aren't running the upgrade in a maintenance window and the farm has a lot of load, you can return this WFE to the network load balancer until you're ready to run PSCONFIG. 
+    > If you aren't running the upgrade in a maintenance window and the farm has a lot of load, you can return this WFE to the network load balancer until you're ready to run PSCONFIG.
   
-3. 
-     ![Step 3 in the ZDP process is shown in a graphic.](../media/829a85db-08c1-404c-887b-4dc83ca73639.png)
+3. ![Step 3 in the ZDP process is shown in a graphic.](../media/829a85db-08c1-404c-887b-4dc83ca73639.png)
 
-    For each of SPApp, SPDCH, and SPSRCH in column 1, patch with 'STS' and 'WSS' packages. \> Reboot them when they're done. (The work sent by SPWeb01 will fall on servers in column 2).
-
-4. 
-     ![Step 4 in the ZDP process is shown in this graphic.](../media/d25214fa-c5e7-40ce-9a3d-bc9ea00687a3.png)
+    For each of SPApp, SPDCH, and SPSRCH in column 1, patch with 'STS' and 'WSS' packages.  
+    Reboot them when they're done. (The work sent by SPWeb01 will fall on servers in column 2).
+
+4. ![Step 4 in the ZDP process is shown in this graphic.](../media/d25214fa-c5e7-40ce-9a3d-bc9ea00687a3.png)
 
-    Now you repeat the 'patch and reboot' for column 2. For each of SPApp02, SPDCH02, and SPSRCH02 in column 2, patch with 'STS' and 'WSS' packages. \> Reboot them when they're done. (As you can see, work sent by SPWeb01 will now fall on servers in column 1.)
-
+    Now you repeat the 'patch and reboot' for column 2. For each of SPApp02, SPDCH02, and SPSRCH02 in column 2, patch with 'STS' and 'WSS' packages.  
+    Reboot them when they're done. (As you can see, work sent by SPWeb01 will now fall on servers in column 1.)
+
 ### Phase 2 - PSCONFIG upgrade
 
 Every node in the SharePoint Server 2016 farm has the patches installed, and all have been rebooted. It's time to do the build-to-build upgrade.
 
 > [!NOTE]
-> During the ZDP process, you can run [Upgrade-SPContentdatabase](https://technet.microsoft.com/en-us/library/ff607813.aspx) to reduce the overall time it will take to finish running PSCONFIG. Consider this if you have a large number of databases, or select large databases. 
+> During the ZDP process, you can run [Upgrade-SPContentdatabase](https://technet.microsoft.com/en-us/library/ff607813.aspx) to reduce the overall time it will take to finish running PSCONFIG. Consider this if you have a large number of databases, or select large databases.
   
-1. 
-     ![Step 5 in the ZDP process s shown in a graphic.](../media/4c2c5d4d-f81c-40d8-b645-ba5bf8e9e1bc.png)
+1. ![Step 5 in the ZDP process s shown in a graphic.](../media/4c2c5d4d-f81c-40d8-b645-ba5bf8e9e1bc.png)
 
     Return to the WFE that is out of load-balanced rotation (SPWeb02), open the SharePoint 2016 Management Shell, and run this PSCONFIG command:
-    
-  ```
-  PSCONFIG.exe -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures -cmd secureresources -cmd services -install
-  ```
+
+    ```powershell
+    PSCONFIG.exe -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures -cmd secureresources -cmd services -install
+    ```
 
     After the command completes, return this WFE (SPWeb02) to the load balancer. This server is fully patched and upgraded.
-    
+
     > [!TIP]
-    > The last step in the PSCONFIG process ensures that updates to the User Interface (UI) are copied from the /layouts folder to a version-specific folder. This is part of the side-by-side UI update that lets users browsing your farm have one experience of the UI until the upgrade is completed, and you're ready to switch over to the new interface. > To be sure the side-by-side copy was successful, check the associated logfile. By default, this is located under  *C:\program files\common files\Microsoft shared\web server extensions\16\logs.*  (Your root drive letter may vary!) > If, for some reason, PSCONFIG didn't successfully copy UI files, please run this command to manually copy them [Copy-SidebySideFiles](https://technet.microsoft.com/en-us/library/mt604696%28v=office.16%29.aspx)! 
+    > The last step in the PSCONFIG process ensures that updates to the User Interface (UI) are copied from the /layouts folder to a version-specific folder. This is part of the side-by-side UI update that lets users browsing your farm have one experience of the UI until the upgrade is completed, and you're ready to switch over to the new interface.  
+    > To be sure the side-by-side copy was successful, check the associated logfile. By default, this is located under:  
+    *C:\program files\common files\Microsoft shared\web server extensions\16\logs.*  (Your root drive letter may vary!)  
+    > If, for some reason, PSCONFIG didn't successfully copy UI files, please run this command to manually copy them [Copy-SidebySideFiles](https://technet.microsoft.com/en-us/library/mt604696%28v=office.16%29.aspx)!
   
-2. 
-     ![Step 6 in the ZDP process is shown in this graphic.](../media/0d89cbbf-e92c-4bda-b32c-c019ee6cbb29.png)
+2. ![Step 6 in the ZDP process is shown in this graphic.](../media/0d89cbbf-e92c-4bda-b32c-c019ee6cbb29.png)
   
-    Remove SPWeb01 from the load-balancer. \> Open theSharePoint 2016 Management Shell and run the same PSCONFIG command:
-    
-  ```
-  PSCONFIG.exe -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures -cmd secureresources -cmd services -install
-  ```
+    Remove SPWeb01 from the load-balancer. \> Open theSharePoint 2016 Management Shell and run the same PSCONFIG command:  
+
+    ```powershell
+    PSCONFIG.exe -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures -cmd secureresources -cmd services -install  
+    ```
 
     Return this WEF (SPWeb01) to the load balancer. It's also fully patched and upgraded now.
-    
+
     Both WFEs are patched and upgraded. Move on to the remainder of the farm, but be sure that the required Microsoft PowerShell commands are run one server at a time and not in parallel. That means, for all of column 1, you'll run the commands one server at a time. Then you'll run them, one server at a time, for servers in column 2 with no overlapping. The end-goal is preserving uptime. Running the PSCONFIG commands serially is the safest and most predictable means of completing the ZDP process, so that's what we'll do.
-
-3. 
-     ![Step 7 in the ZDP process is shown in this graphic.](../media/599700e4-3338-40a9-8f08-51c08ed2821a.png)
+
+3. ![Step 7 in the ZDP process is shown in this graphic.](../media/599700e4-3338-40a9-8f08-51c08ed2821a.png)
   
     For all remaining servers in column 1 (SPApp01, SPDCH01, SPSRCH01), run the same PSCONFIG command in the SharePoint 2016 Management Shell. Do this on each server, one at a time, until all servers in column 1 are upgraded.
-    
+
     > [!IMPORTANT]
-    > Remember to gracefully [remove the Distributed Cache](https://technet.microsoft.com/en-us/library/jj730452.aspx?f=255&amp;MSPPError=-2147217396) before running PSCONFIG and [add the Distributed Cache to the server](https://technet.microsoft.com/en-us/library/jj730445.aspx) again after completion. 
-  
-  ```
-  PSCONFIG.exe -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures -cmd secureresources -cmd services -install
-  ```
+    > Remember to gracefully [remove the Distributed Cache](https://technet.microsoft.com/en-us/library/jj730452.aspx?f=255&amp;MSPPError=-2147217396) before running PSCONFIG and [add the Distributed Cache to the server](https://technet.microsoft.com/en-us/library/jj730445.aspx) again after completion.
 
-4. 
-     ![Step 8 in the ZDP process is shown in this graphic.](../media/28cd6fdc-950b-4ca5-a77f-a0cdc60e7ef8.png)
+    ```powershell
+    PSCONFIG.exe -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures -cmd secureresources -cmd services -install
+    ```
+  
+4. ![Step 8 in the ZDP process is shown in this graphic.](../media/28cd6fdc-950b-4ca5-a77f-a0cdc60e7ef8.png)
   
     For all remaining servers in column 2 (SPApp02, SPDCH02, SPSRCH02), run the same PSCONFIG command in the SharePoint 2016 Management Shell. Do this on each server, one at a time, until all servers in column 2 are upgraded.
-    
+
     > [!IMPORTANT]
-    > Remember to gracefully [remove the Distributed Cache](https://technet.microsoft.com/en-us/library/jj730452.aspx?f=255&amp;MSPPError=-2147217396) before running PSCONFIG and [add the Distributed Cache to the server](https://technet.microsoft.com/en-us/library/jj730445.aspx) again after completion. 
-  
-  ```
-  PSCONFIG.exe -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures -cmd secureresources -cmd services -install
-  ```
+    > Remember to gracefully [remove the Distributed Cache](https://technet.microsoft.com/en-us/library/jj730452.aspx?f=255&amp;MSPPError=-2147217396) before running PSCONFIG and [add the Distributed Cache to the server](https://technet.microsoft.com/en-us/library/jj730445.aspx) again after completion.
+
+    ```powershell
+    PSCONFIG.exe -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures -cmd secureresources -cmd services -install
+    ```
 
     > [!IMPORTANT]
-    > After all servers have been through PSCONFIG successfully, remember to run the SharePoint 2016 Management Shell command below to switch to the new user interface files and complete the side-by-side process: >  `$webapp.WebService.SideBySideToken = <current build number in quotes, ex: "16.0.4338.1000">`>  `$webapp.WebService.update()`
+    > After all servers have been through PSCONFIG successfully, remember to run the SharePoint 2016 Management Shell command below to switch to the new user interface files and complete the side-by-side process:  
+    > `$webapp.WebService.SideBySideToken = <current build number in quotes, ex: "16.0.4338.1000">`  
+    > `$webapp.WebService.update()`
   
 Now you're done, and the farm has been fully upgraded while in use and without downtime.
   
@@ -163,8 +171,5 @@ The goals here are high availability and fault tolerance. That means top priorit
 In examples used here, I draw out physical servers to make concepts easier to grapple with. When it comes time to plan for ZDP, you should draw out your own environment, wherever it lives (complete with rack names/numbers, and sever names where each SharePoint Server role can be found). This is one of the quickest ways to isolate any violations of the goals of role redundancy and fault tolerance that might have snuck into your setup, no matter the size your setup may be.
   
 ## Related Topics
-<a name="BKMK_HA"> </a>
 
 [Video demo of Zero Downtime Patching in SharePoint Server 2016](video-demo-of-zero-downtime-patching-in-sharepoint-server-2016.md)
-
-