Interesting issue I just had with a Shared Service Provider setup that I thought I’d share. After creating the Shared Service Provider, I tried accessing it, but I got the SharePoint “Access Denied” message. I made sure that the account that I was using was a Site Collection Administrator. I also tried giving the account full control via a Web Application Policy. Setting up another account as a site collection admin didn’t work either. No errors or warnings in the Windows Event Logs.
When I created the Web Application for the SSP, I provided an AD account to use for the Application Pool. When I set up the SSP, I specified a different account for the Shared Services Timer Jobs. This is a “best practice” – having different accounts for different jobs.
Looking at IIS, I noticed that the App Pool for my SSP web app was using the SSP Timer Service account. Odd.
I went back and modified the SSP configuration (Central Admin – Application Management – Manage this farm’s Shared Services – Edit Properties) and changed the SSP Service Credentials to the account that I originally specified for the SSP App Pool. I flicked back over to the IIS Management screen to confirm that the Application Pool was now using the account I expected.
I was then able to browse to the SSP admin site. I can’t say I understand why this issue has occurred, but there you have it. I did see a comment about not using the same name for the App Pool and the SSP name which might be the reason for my problem. I’m too lazy to retest right now.
Other related info – my environment is running on Windows 2008 SP2 x64, MOSS 2007 Enterprise with SP 2, using separate servers for AD, SQL and MOSS.
