Monday, June 18, 2007

MOSS 2007 cannot login into SSP

I have been involved with installing MOSS 2007 (with the right service accounts) with our Sharepoint administrator in our test environment. One problem we uncovered when creating the SSP application is that the SSP timer service account would take over the app pool credentials and not allow us to login. This is explained below.

When we created the Web application where the SSP will be hosted, we created a new app pool and added the service account we created (svcMOSSSSPAP) as the app pool identity account in the 'Create web application' page in central admin. Things were great thus far. However, when we went in to create a SSP under that Web application, we would run into a problem where the SSP timer service account that we entered in the SSP creation form (svcMOSSSSP) would end up taking over the app pool identity for the Web application. This would block all access to the SSP. Also, it would not allow us to change the identity in the app pool in IIS (it would reset to the same account everytime we tried to change it). We finally figured out what it was doing and had to create a new app pool in IIS that would use svcMOSSSSPAP as its identity and configured the SSP web application to use that new app pool. We were then able to access the SSP.

17 comments:

scott said...

Thankyou, thankyou, thankyou.

Every other idiot just talked about assigning the correct permissions.

Every SSP I created I instantly got access denied.

This fixed it!

Scott said...

I now know why.

DO NOT call you SSP the same name as the AppPool you use for the SSP Admin Site.

The SSP actually uses its name to create an AppPool for use under the Office Search site.

If your SSP Admin AppPool is the same name then MOSS sets it to use the timer svc account.

If your hosting then call the SSP Admin AppPool 'Company - SSPAdmin' and the actual SSP 'Company - SSP'. This will stop MOSS clobbering the accounts.

Anonymous said...

Brilliant, create a new app pool and use the locked one as a template - then change the user and reassign the IIS to use this new pool.

Nothing to do with names of the services.

Thanks

Anonymous said...

Great post, I was able to resolve the access issue just as you said. Thank you.

Anonymous said...

Also, what Scott said is exactly right, that's what is going on. Thank you Scott

SEO Expert said...

Great Work.
Thanks a lot.

Anonymous said...

Absolutely GREAT Post. This is really an issue down the line. I tried for HOURS to solve this issue. AND: It is true, if the SSP has the same name as the app pool of the SSP this issue comes up. Thanks a LOT

Tahir said...

Faraz! You are the man.
This is exactly what I was looking for. THANKS :o)

Paul said...

I followed the advice here and still have the same problem. Any advice?

Mark said...

w00t thanks for that.

That'll shut the boss up. Permissions my arse.

meka9233 said...

I think you complicate the development of sharepoint by this way. After you create the new SSP[sharepointservices1(Default)] you should run the Sharepoint products and technologies configuration wizard one time, it fixes the accounts and rights related to application pools in its right way and nothing more is needed.

Anonymous said...

Opulently I acquiesce in but I contemplate the post should secure more info then it has.

Anonymous said...

Your blog keeps getting better and better! Your older articles are not as good as newer ones you have a lot more creativity and originality now keep it up!

Anonymous said...

I just discovered the website who discuss about
many
home business opportunity

If you want to know more here it is
home business ideas

Anonymous said...

foucaults cvisual never directory complain recent discrepancy ksxkkyk involve poor literally
servimundos melifermuly

Anonymous said...

verbs factor occupation candidates instytut fong surat perspectives knobel egrkk shop
servimundos melifermuly

vivek said...

@Scott
your god... you saved me hell lot of time... thank you very much...