I checked application pool identity; added Search account to user policy of mysite web app; updated Permissions for User Profile Service Application by adding the following to both Authenticated Users and All Authenticated users: "Use Personal Features", "Create Personal Site", "Use Social Features"... all to no avail. Of course this pattern looked familiar to me, I had seen it years ago...
It turns out that since I use AutoSPInstaller for all of my SharePoint Deployments, I had completely forgotten some of the must mundane, known SharePoint issues, as this script automatically tends to easily fixed, known configuration changes necessary for a smooth deployment. Therefore, I completely over-looked the good old 'LoopBack Check' issue.
Microsoft first introduced the LoopBack Check in Windows Server 2003 SP1 and is utilized in Server 2008/20012 as well. This feature prevents access to a web application using a fully qualified domain name (FQDN) if an attempt to access it takes place from a machine that hosts that application. The end result is a 401.1 Access Denied from the web server and a logon failure in the event log.
While this can be a PIA when accessing SharePoint from the local server itself, this is a security feature and should be left alone in production scenarios, however, in lower environments, this feature can, and in 99.9% of my builds, is turned off.
The fix is simply to create a DWORD registry key in the registry called DisableLoopbackCheck and set its value to 1. This can be done manually, but in the world of PowerShell, who wants to jack with the registry by hand?
New-ItemProperty HKLM:\System\CurrentControlSet\Control\Lsa -Name "DisableLoopbackCheck" -value "1" -PropertyType dword
Now, your web app/site will auto-magically work as expected!
Post a Comment