In the wise words of Todd Klindt, “SQL Aliases are powerful.” However, with great power, comes great responsibility. Whoa wait, that’s not the right one… my Spidey sense totally failed me on this one. I had to resort to some black ops and find the real identity of the problem. So here’s the run down…
Location: Alabama, United States
I have just completed building several MOSS 2007 farms (Microsoft Office SharePoint Server 2007 for you civilians who need acronym translations). I need to extend one of the web applications on one of the servers into the Extranet zone so that I can enable FBA (Forms Based Authentication) and SSL to expose it to external customers.
On one of the application servers, I try to extend the web application and receive the following error:
An object of the type Microsoft.SharePoint.Administration.SPWebApplicationProvisioningJobDefinition named "Provisioning 1aa06c49-f543-41c2-b3f6-ce7884a9b71d" already exists under the parent Microsoft.SharePoint.Administration.SPWebService named "". Rename your object or delete the existing object.
A quick and thorough search of this error leaves me with no real solution. What now? Using my excellent investigative skills I notice “SPWebApplicationProvisioningJobDefinition” as part of the error. Job… well, I know there is a way to check those out. So I look in Central Admin at the timer jobs… nothing. No trace of the problem. So I decide to go a little rogue and try something anyway.
I log into all servers on my farm and run stsadm.exe –o execadmsvcjobs. On 3 of the four servers, it returns “Executing” completes, and all is well. On the 4th server (the other application server) I see: 
Holy cow… “The farm is unavailable.” That’s not something any admin worth her salt wants to see on her servers. Where do I start? Well, as an expert in covert ops, I have learned that my farm is actually a database on a SQL server. With that knowledge, I begin to investigate. I check all of my servers to see that they have the same database server entered. All of them do, so that is good. I begin to back track the possible source of the problem and realize this farm was one of the ones whose databases were moved to a new server in preparation for server hardening recently.
Now, as skilled as I may be in administration and investigation, the company I am currently consulting with does not allow me to dig into areas of the server where they do not want me. So during this move, I had to be content with allowing the internal infrastructure administrators to update the SQL Alias on the farms. I had been assured that this had taken place, only now I wasn’t so sure.
I began to remote into each server, saving this problem server for last. I went Start>Run and typed “cliconfg.exe”. I then clicked on the Alias tab and verified that the correct server alias was entered with the correct parameters, especially the server name. The 3 that executed properly were fine, now to deal with this problem server. I performed the same actions and would you believe, the alias still pointed to the old server name?
I corrected this and then ran the previous command, it executed more jobs than I could count, and suddenly, I was able to extend my web application, change it to FBA, and set it to SSL with no issues. I celebrated by swinging from building to building slinging webs from my wrist… oh wait, wrong thing again.