SharePoint 2013 isn't supported on Windows Server 2012 R2. Be that as it may, it works just fine. (There are articles out there on how to do some manual installation hacks to get this unsupported configuration working, but that is outside the scope of this post.) Microsoft's answer to those of us SharePoint 2013 developers nutty enough to run Windows Server 2012 R2 natively in lieu of using VMs was simply: wait for Service Pack 1.
Well the wait is over and SP1 is out. Yay. Since my local SharePoint environment is a development / everyday work machine, I have Windows Update configured with the "don't bother me" setting, which downloads and installs updates at will. Well the last few times updates tried to install, one of them would always hang. The last time, after watching the spinnie for almost a half hour, I became impatient, swallowed hard and held down my laptop's power button for four seconds.
When it came back, I noticed that after playing around in Central Administration for only a minute or two, I'd start getting 500's in my browser. It turns out that all my SharePoint administrative IIS app pools were stopping! I fired them back up, and could work for another minute or so until they stopped - and now stayed stopped - this second time. So I flung open Windows Update, and there it was, staring back at me: SharePoint 2013 Service Pack 1.
Cool. I kicked off the installation manually and after less than an hour, it was completed. Thinking I was well on my way to being productive again, I kicked off PSConfig. That hung trying to get a lock on the farm. So I rebooted and tried again. This time, it got about half way home (step 5) before complaining about a timeout error. The logs informed me that it was trying to start a Windows Service, but offered no further insight. Here's the whole mess:
03/27/2014 11:06:47 14 ERR Exception: System.ServiceProcess.TimeoutException: Time out has expired and the operation has not been completed.
at System.ServiceProcess.ServiceController.WaitForStatus(ServiceControllerStatus desiredStatus, TimeSpan timeout)
at Microsoft.SharePoint.Win32.SPAdvApi32.StartService(String strServiceName)
at Microsoft.SharePoint.Administration.SPWindowsServiceInstance.Provision(Boolean start)
at Microsoft.SharePoint.PostSetupConfiguration.ServicesTask.InstallServiceInstanceInConfigDB(Boolean provisionTheServiceInstanceToo, String serviceInstanceRegistryKeyName, Object sharepointServiceObject)
at Microsoft.SharePoint.PostSetupConfiguration.ServicesTask.InstallServiceInstances(Boolean provisionTheServiceInstancesToo, String serviceRegistryKeyName, Object sharepointServiceObject)
at Microsoft.SharePoint.PostSetupConfiguration.ServicesTask.InstallServices(Boolean provisionTheServicesToo)
I tried rebooting and rerunning the Products and Technologies wizard a couple times, but I kept getting the same results. So I decided to bite the SPBullet, uninstall SharePoint, acquire the 2013 + SP1 bits from MSDN, and install the whole thing clean. The uninstallation was a bit dramatic: the progress bar didn't move for several minutes, but eventually began to slowly turn green like a rotting bagel. Next, after downloading the SP1 ISO, rebooting, mounting, and running it, I was informed that:
I indulged it and rebooted again, but not without a bad feeling, which was quickly validated; the uninstallation wasn't as clean as I had thought. It turns out that it's just a registry key or two that control this error state. Read this for information on how to convince the SharePoint setup program that its ancestor installation is no longer a threat. (When you load the previously-linked page, scroll down a bit to the "ISSUE #3" section.)
Afterwards, the installer ran fine, and as usual, asked me kick off PSConfig. Since my previous installation still had a few ghosts floating around from my hacked-up "Stand Alone" configuration, there was more work to do to get this wizard to finish. Since my uninstall removed my instance of SQL Express, I decided to install SQL Server 2012 SP 1 full, and point my new SharePoint farm at that. Well no can do, since PSConfig is overly worried that:
Well I got around that annoyance by reading this old article and enlisting PowerShell to help. As long as you don't use "localhost" for the "DatabaseServer" parameter to New-SPConfigurationDatabase, it should create the farm just fine. Finally, point PSConfig to this and your installation of SharePoint 2013 Service Pack 1 on Windows Server 2012 R2 should finally be complete!