SPProductUpdate: Add possibility to use Zero-Downtime Patching with SPDsc

@andikrueger and I have been discussing the possibility to patch SharePoint using Zero-Downtime Patching with SharePointDsc. Since this requires directing traffic to other servers in the SharePoint farm, this will require implementing a solution to make sure the server is not serving traffic.

We both see that a lot of companies don't configure their load balancing the proper way. Their appliances only ping the SharePoint WFE IP addresses. If the IIS services are stopped or not responding (intentionally or because of some sort of issue), the server doesn't serve any requests, but the load balancer still gets a ping response and considers the server as operational.

Therefore load balancer solutions should at least check for HTTP status codes or better yet, retrieve a page and check for specific content every 10 to 15 seconds.

If this is the case, there is a possibility to do ZDP with SPDsc:

1. Prepare WFE by fooling the LB by either:
   a. Create a IIS Rewrite rule, to send out 503 status codes
   b. Changing the IP of the SharePoint Web application binding - changing the HTTP listening port
   c. Setting a firewall rule, that blocks all traffic coming from the load balancer IP (which is the easiest to create)
   d. Create a new IIS Web Application that catches all the traffic to that server and does a redirect to the IP address of any other WFE (with the host-header attached)
   e. Have a PowerShell script check the local web applications and create an HTML file in an anonymous web site. If the checks are good, the file contains the text "Ok". If the checks fail, the file contains the text "Failed". The LB checks this HTML file and depending on the result, considers the server as operational or not.
   f. Any other ways to temporally disable this WFE from taking request issued by the LB.
2. Now the LB should route the traffic to the remaining WFEs.
3. Enable Side-by-side on WFE 1
4. Install the patches
5. Reboot the server
6. Disable the LB fooling solution on this WFE
7. Prepare WFE 2 by using either method mentioned in 1.
8. Proceed with the patching on this server, etc

We are curious what other think of this solution? If there are any other ideas that might be better as the ones suggested above.

No files, tests, or entry points are named. Start by reviewing the proposed traffic-draining methods and the per-WFE patching sequence, then establish which approach is supported and define its implementation scope. Done would require an agreed, validated solution for directing load-balancer traffic away from each WFE during patching.