locked
Shared Services is broken after failed attempt to create a secondary ssp. It is now associated with a database that doesn’t exist, thus login to db fails by server farm account. RRS feed

  • Question

  • I am new SharePoint administrator.  In my development SharePoint environment, for practice,  I was planning to create a secondary ssp then set it as default ssp then delete the original ssp.

     

    During the creation of secondary ssp via Central Administration UI, the browser (IE 7 on Win XP) crashed and the creation did not complete.  A new ssp name was added to the CA quick launch bar with no active link to it.  The secondary ssp database I named for the creation was not actually created in SQL, yet it is referenced as database being accessed when I attempt to open the old ssp – which fails.

     

    This error results: “An unhandled exception occurred in the user interface.Exception Information: The given key was not present in the dictionary. “

     

    I made more attempts to created ssp’s via stsadm command line because cannot open Central Admin managessp.aspx page. I created a new web app first which I believe I didn’t do the first time (I used existing web app).  Similar scenario results, ssp names appear in quick launch with no active link to them, databases are created in SQL this time.  Original ssp is still the only linked ssp, and it won’t open due to being pointed to a non-existent database. 

     

    Windows Event log on SharePoint server error indicates the attempts are failing because of login failure to a database that doesn’t exist: Event ID 5554 (user profiles)

    “Failure during sweep synch.  Exception was Cannot open database "SharedServices1_DB" requested by the login. The login failed. Login failed for user 'xxx\serverfarmaccount'..”

     

    Windows Event log on SQL box: Login failed for user 'xxx\serverfarmaccount'. Reason: Failed to open the explicitly specified database. [CLIENT: xx.xxx.xx.xxx]

     

    Environment: Stand alone MOSS 2007 version 12.0.0.6421 on Server 2008 on one box, SQL Server 2008 stores SharePoint databases on another box.

     

    I seem to have no way to create a new Shared Service provider. Can anyone help ?


    dms
    Tuesday, January 17, 2012 6:36 PM

All replies

  • Can you try providing SysAdmin rights on the SQL server to your account?

    Wednesday, January 18, 2012 9:42 AM
  • Thank you PraveenKumar for the suggestion.  Most of the app pool accounts (but not all) which access the databases have sysadmin rights -- the account that is accessing this (according to event logs) has sysadmin rights: 'xxx\serverfarmaccount'. 

    I cannot open Shared Services Administration (http:/SERVERNAME:#####/managessp.aspx)  link from Quick Launch bar in Central Admin, however can access   http:/SERVERNAME:##### /ssp/admin/default.aspx. 

    Things I've tried:

    1)With an snapshot in place on SharePoint server and SQL server, I removed all ssp's and their databases via stsadm command (deletessp) but when I tried to delete the last ssp which was the original ssp, it would not delete due to references which I suspect are because it is set as the default ssp. 

    I reverted the snapshot back to a time before I removed ssp's, then tried this:

    2)Run a psconfig successfully.

    3)Repaired SharePoint 2007 via control panel, then restarted the server, and run psconfig successfully again,

    but the problem persists.


    dms

    • Edited by dms.WebDev Thursday, January 26, 2012 4:16 PM
    Friday, January 20, 2012 7:41 PM
  • My solution came via assistance from MicroSoft paid support professional.   I will update this post with step-by-step later but basically we deleted all ssp's, ran a few stsadm commands, then cleared the ProgramData cache files.  After this, was finally able to create a new default ssp via Central Administration again.  Once new ssp was in place I encountered tons of windows event log transport level errors connecting to SQL server (which did not prevent SharePoint site from working). After clearing the cache again, most of them went away.

    Lesson learned: wash, rinse, repeat.


    dms




    • Edited by dms.WebDev Wednesday, February 8, 2012 6:39 PM
    Wednesday, February 8, 2012 6:37 PM
  • Your lesson should have been to run, not walk away from sharepoint.   Basic things like creating a manage service app, deleting it fail until you try it 10 times.  I have a completely clean environment, and it failed in a manner you describe here.  This is after a week of tracking down other undocumented features that require stsadm commands, reboots, and server farm removals to fix.  Sharepoint is horrible. 
    Wednesday, October 24, 2012 2:11 PM
  • Daniel - -Thanks for your post, it's been awhile since I visited that problem.  Just curious if you're also working with SharePoint 2007?  I wonder if it gets easier with 2010--which we plan to migrate too soon, or 2013 which I understand is in Beta right now?

    I have found that with the 2 most used Microsoft products I use; SharePoint, InfoPath, clearing a cache somewhere often clears up the problem.  I had a problem where InfoPath form template wouldn't publish to SharePoint once, and the solution was clearing the cache.  The SSP solution I posted about was to clear the cache too.

    In reference to the problem I posted, one problem persists, which is that a custom SharePoint workflow wouldn't fire automatically when a new item (InfoPath form) was created.  But if I terminate the workflow and manually start it, it does start.  I JUST discovered this week the problem with the workflow is either the OS or IE version (or combination thereof) because it fires automatically on XP and IE7 machine, yet fails on Win 7 and IE9.  So is Windows or IE the culprit?  The problem is the delay at workflow startup is handled differently so it fails, so the workflow code has to be modified.  Really? Shucks.


    dms


    • Edited by dms.WebDev Wednesday, October 24, 2012 3:19 PM
    Wednesday, October 24, 2012 3:17 PM