SharePoint 2007 - When Shared Services Provider creation causes you grief

I just did a deployment of Office SharePoint Server 2007.  As mentioned in a previous post, we are building a customer extranet for our current client.  I have encountered some very strange behavior (which in the end turned out not to be so strange).  Essentially, everything installed fine, up until the point that I created my Shared Services Provider (SSP).  Central Administration works as expected, the system allows me to create an SSP and even tells me its been successfully created, but when I go to access it, I get an access denied screen.

I felt that I had exhausted all options and that it was time to delete the SSP and build it again, along with it's supporting databases.  This shouldn't be a big deal, since this is a new install and no one is using it yet.  Well, thru the admin UI, you are not able to delete the SSP if it is the only one there.  I searched for a while and discovered that this is possible using the stsadm command line tool.  Here is the command: 

stsadm -o deletessp -title "SharedServices1" -deletedatabases

All you do is pass it the name of the SSP and a flag indicating that you want to delete the databases that go along with it.  I did not go thru the trouble of creating another SSP but if I would have, I would venture to guess that the option to delete becomes enabled in the UI (did I mention that it was there, just not clickable), since there is an SSP to fall back on.  I would also imagine that you can change the default SSP if there is more than one and that you would then be able to delete the other thru the UI if you wanted to.

After deleting and recreating my SSP I was still getting an access denied screen.

I mulled over this for quite some time.  A coworker of mine asked me if I had the site in my Trusted sites security zone or in my Local intranet security zone.  DOH!

I had found it odd that I could access the SSP administration site remotely, but could not locally on the server.  At any rate, I felt kind of silly, it was working all along.  So the lesson learned is to add the SSP administration site as well as Central Administration to your trusted sites on the server as soon as you create them.  This won't be happening to me again.