SharePoint MOSS 2007: Cannot create A default SSP after Server Farm SharePoint Install
When you first run the SharePoint installer (SharePoint Products and Technologies Wizard), you are first asked if this is a stand alone installation, or a server farm. If you choose server farm, and you haven’t created a default SSP for the farm, you may run into the issue of not being able to create a new SSP from the web interface. In the new SSP form, I found myself with no web applications available to be selected as seen in the screenshot below. And you cannot create an SSP without assigning a web application to it. And so, I seemed to be stuck at this point with a broken farm install.
At this point, I did have 3 Web applications setup, one specifically for the default SSP I was creating here.
(as it says in the above screen, I took that while running the command to fix this problem and it shows an SSP when one didnt exist at this point. So just ignore that SSP in the screenshot)
Really, I didn’t even need an SSP for my web application because its going to be a public facing website. I’m only using the CMS parts of SharePoint without the search (we have a google search appliance for that). But, as you can see in the screenshots, I’m getting this big red “Server Farm Configuration Not complete!” message, which will freak out my boss if he sees it. So, after a quick search on google I found that this was because there is no default SSP, which brings us back around to our current problem.
My First Attempt at a Solution (see notes at the end of this article)
So, how can we install an SSP when the central admin wont let us pick a webapp for it? Thankfully, we can use the command line tool Stsadm to work around the Central Admin “bug”. Below is an example call to create a default SSP using an existing application for SSP services and for the default mysites application, just hack it up to suit your needs:
C:>"%COMMONPROGRAMFILES%\microsoft shared\web server extensions\12\bin\stsadm" -o createssp -title MY_DEFAULT_SSP -url http://SSPWEBAPPLICATIONURL:PORT -mysiteurl http://SSPWEBAPPLICATIONURL:PORT -ssplogin MYDOMAIN\SSPACCOUNTNT -ssppassword SSPACCOUNTNTPW -indexserver MYINDEXSERVER -indexlocation "C:\Program Files\Microsoft Office Servers\12.0\Data\Office Server\Applications" -sspdatabaseserver SERVERNAME\SSPDATADB -sspdatabasename MY_DEFAULT_SSP_DB -searchdatabaseserver SERVERNAME\SSPSEARCHDB -searchdatabasename MY_DEFAULT_SSP_SEARCH_DB -ssl no
After a long wait, your default SSP will magically appear and your huge red warning message will vanish from the Central Admin!
UPDATE
Looking back on this post, I ran into this problem when I installed SharePoint on a server using the "Web Front End" install option. Since I wanted to host shared services on this box (even without the intention to use them) I should have selected the "complete" install option. I believe this is why I couldn't add shared services properly with my initial install. I'm setting up a new farm now, using the complete option. I'll post the results of that test when its all up and working...
... still no go. Even using the "complete" install option, I cannot create the default SSP due to the fact that the form interface will not let you select a web application for the new SSP (as described in the beginning of this article) :/
YET ANOTHER UPDATE
After more testing, I found that the above createssp command did not work after all. It does skirt around the big red error message, but it leaves you with an unuseable SSP. For some reason, the admin site does not install properly using the command line tool (perhaps it only fails to install with this specific problem I'm seeing?) so you cant administer any of the shared services for your new SSP.
From here, I decided to delete my SSP and try creating my web applications from the command line too, using an example I found on google. So I deleted my current web applications, then used the command
c:>"%COMMONPROGRAMFILES%\microsoft shared\web server extensions\12\bin\stsadm" -o deletessp -title MY_DEFAULT_SSP
to delete the default SSP. That worked fine, and I even took the time to go into my SQL server and physically delete the databases there (often, sharepoint does not delete the database when you remove a webapp or an SSP). With all that done, no webapps installed and the SSP deleted, I started over. I decided at the last minute to try the standard, central admin method of creating an SSP just for kicks, and like magic it just worked. Unlike what I described above, when I now crate a web application for use in the default SSP, it now shows up in the list of available web applications and I can create the SSP.
Why this works now, I have no idea. But if anyone else is having the same issue, try deleting all your web apps and your default SSP first. Then see if you can use the Central Admin to create your default SSP again.
FINALLY, THE ANSWER!
After more testing I've found the actuall problem. Permissions. I find when I create a new Web application for use in an SSP, I need to specify an "Application Pool Security Account" of something other than "Network Service". I'm guessing that by default, the Network Service account does not have the proper permissions for ... whatever sharepoint is trying to do when assigning a web application as the administrative site for an SSP.
If you find yourself running into the same issue, try using an administrator domain account as a test. If your new application is now selectable for the admin site of the SSP, then you know you've hit this permissions issue.