SharePoint Musings

Synopsis I'll go out on a limb here and say that updates and patching is no ones favorite thing to do.  But nonetheless it is a crucial piece of the puzzle in keeping applications/platforms/systems at an optimal level and more importantly - supported! The scary reality of applying Windows Updates (not CUs or SPs) to servers hosting our SharePoint environment is that you are at the mercy of the changes that are about to be applied.  They frequently go without a hitch, and sometimes they DO NOT.  When that happens you typically spend countless hours scouring the event logs and ULS because those end-user error messages are just sooo helpful, like this one: "We're sorry. We ran into a problem completing your request. Please try that again in a few minutes" The Problem A client of mine was performing some routine scheduled maintenance on their SharePoint 2013 farm, and by routine maintenance I mean installing queued up Windows Updates.  Smooth sailing, right?

Synopsis Before we start talking about the problem let's understand the setup here.  We have a SharePoint 2013 intranet site that is also configured for access outside of the corporate network.  Employees use the same URL to visit the site both internally and externally via standard ports (80 and 443). Internal URL: http://sharepoint.domain.com Public URL: https://sharepoint.domain.com The site URL has been added to the Local Intranet zone in Internet Explorer for passing domain credentials. Alternate Access Mappings have been configured in such a way that if a user requests the site over HTTP they are automatically re-directed to HTTPS. Internal URL Zone Public URL for Zone https://sharepoint.domain.com Default https://sharepoint.domain.com http://sharepoint.domain.com Default https://sharepoint.domain.com Web application has been configured to use Kerberos protocol for authenticating incoming c