Cascade Skyline - with Microsoft Logo and Project Support header - author Brian Smith

My SSP stopped working when I restored to another domain! Unable to Edit a Project Server or SharePoint Shared Services Provider.

My SSP stopped working when I restored to another domain! Unable to Edit a Project Server or SharePoint Shared Services Provider.

  • Comments 7

I’m guessing this problem may be more of an issue for us Project Server 2007 support guys at Microsoft than for most customers – but I can certainly see scenario’s where this one would bite you too, so worth an explanation.  I’ll throw in all the text from the logs etc. at the end as it makes better reading for the search indexers than for normal people and just concentrate first on what breaks and how to work around the issue.

When you are restoring a farm backup you get the option to update the accounts used for most things – then some of the other accounts you can set once you have things up and running.  However, if you have added any accounts into the “Process Account with Access to this SSP” section of the Edit Properties part of the SSP the accounts just get carried through to the new configuration database.  Unfortunately this can break some stuff – and even more unfortunate is that the first thing it breaks is the page where you would go to remove them!  Basically the page tries to validate the data it has and gives the following error:-

An unhandled exception occurred in the user interface.Exception Information: The specified account name is invalid.
Parameter name: account

The same problem occurs if an account added in Process Accounts is removed from AD – and this may well be the most common customer scenario if restoring across domains is not involved.  Verbose logging for Office Server General will also show the actual DOMAIN\User that is causing the problem.

You can also see the same error if you try to run stsadm –o enumssp.  And other SSP related jobs may post a very similar error in the Application Event Log as they fail to work.  Our workaround until now has been the usual; create a new SSP and change associations, and only today did I get to the bottom of this particular failure.  The only supportable workaround is to take a fresh backup after removing any accounts from the Process Accounts section.  The stsadm –o editssp also does not seem to give a way to remove an account that is not valid – giving an error:

A failure occurred during the processing of this command. Check diagnostic logs
for more information.

and logs the same kind of thing in the ULS logs as detailed below. 

So here is the less interesting stuff that Live and any other search engines I have forgotten can lap up…

ULS Log

=======

Verbose

Office Server

Office Server General

792o

Verbose

NTAccount 'DOMAIN\User could not be translated to a SID. Exception: System.Security.Principal.IdentityNotMappedException: Some or all identity references could not be translated. at System.Security.Principal.NTAccount.Translate(IdentityReferenceCollection sourceAccounts, Type targetType, Boolean forceSuccess) at System.Security.Principal.NTAccount.Translate(Type targetType) at Microsoft.Office.Server.Utilities.WindowsSecurity.ValidateAccount(NTAccount account, Boolean throwIfInvalid)

Exception

Office Server

Office Server General

837w

Exception

Unhandled page level exception. Path: /_admin/sspdetails.aspx, Error: The specified account name is invalid. Parameter name: account, Details: System.ArgumentException: The specified account name is invalid. Parameter name: account ---> System.Security.Principal.IdentityNotMappedException: Some or all identity references could not be translated. at System.Security.Principal.NTAccount.Translate(IdentityReferenceCollection sourceAccounts, Type targetType, Boolean forceSuccess) at System.Security.Principal.NTAccount.Translate(Type targetType) at Microsoft.Office.Server.Utilities.WindowsSecurity.ValidateAccount(NTAccount account, Boolean throwIfInvalid) --- End of inner exception stack trace --- at Microsoft.Office.Server.Utilities.WindowsSecurity.ValidateAccount(NTAccoun... Continues...

Application Event Log

==================

No specific error relating to the failed Edit Properties page - but due to the same root cause there would likely be errors like the one below, possibly every minute.

Event Type: Warning

Event Source: Office SharePoint Server

Event Category: Office Server Shared Services

Event ID: 5783

Date: 6/12/2008

Time: 10:01:52 AM

User: N/A

Computer: W2K3

Description: Synchronization for Shared Services Provider 'SSP1' has failed. The operation will be retried.

Reason: The specified account name is invalid.

Parameter name: account

Technical Support Details:

System.ArgumentException: The specified account name is invalid.

Parameter name: account ---> System.Security.Principal.IdentityNotMappedException: Some or all identity references could not be translated. at System.Security.Principal.NTAccount.Translate(IdentityReferenceCollection sourceAccounts, Type targetType, Boolean forceSuccess) at System.Security.Principal.NTAccount.Translate(Type targetType) at Microsoft.Office.Server.Utilities.WindowsSecurity.ValidateAccount(NTAccount account, Boolean throwIfInvalid)

--- End of inner exception stack trace ---

at Microsoft.Office.Server.Utilities.WindowsSecurity.ValidateAccount(NTAccount account, Boolean throwIfInvalid) at Microsoft.Office.Server.Administration.SharedAccessRule.Validate() at Microsoft.Office.Server.Administration.SharedComponentSecurity.SetAccessRule(SharedAccessRule accessRule) at Microsoft.Office.Server.Administration.SharedComponentSecurityFormatter.DeserializeFromXml(XmlReader xmlReader, SharedComponentSecurity& security) at Microsoft.Office.Server.Administration.SharedComponentSecurityFormatter.FromXmlString(String xml) at Microsoft.Office.Server.Administration.SharedResourceProvider.InternalGetAccessControl() at Microsoft.Office.Server.Administration.SharedResourceProvider.GetApplicationSecurity() at Microsoft.Office.Server.Administration.SharedResourceProvider.Microsoft.Office.Server.Administration.ISharedComponent.Synchronize() at Microsoft.Office.Server.Administration.SharedResourceProviderJob.Execute(Guid targetInstanceId)

Leave a Comment
  • Please add 3 and 4 and type the answer here:
  • Post
  • Is there any way to fix the issue without having to re-create the SSP?

    In our current situation, a user has been deleted from Active Directory and since then we see hundreds of such errors in the event logs. It looks as if It's trying to do something with the deleted account every minute.

    I turned on verbose logging and that is how I found out the deleted user name is causing the issues.

    Thanks.

  • Hi Vili,

    I am not aware of a way - but will check with the SharePoint guys to see if there are plans to fix the stsadm so that this tool could remove invalid (or non-existent) accounts.

    Best regards,

    Brian.

  • I will be going deeper in this posting, particularly on the scenario of moving just the databases and

  • Is there any solution to this isseu yet?

    We added users to acces the ssp and are unable to acces the ssp with these accounts.

    Authentication is even not possible after creating a new ssp and so we re-created an account.

  • Hi Dimitri,

    Checking our bug database the stsadm appears to have been fixed as part of the work in SP2 for SharePoint and hopefully this will be out in the next month or so.

    Best regards,

    Brian.

  • We had the same problem and it turned out that restoring a Sharepoint farm to another domain often doesn't reassign the correct permissions for the service accounts in the SQLServer databases.

    A quick verification of this is to add the user Builtin\administrators to the Security Users group of every Sharepoint related SQLServer database with the db_owner role.  Then populate the Builtin\administrators with all the Sharepoint service accounts.  Ugly, but it will show you if its just a problem of SQL permissions.

  • Thanks for this tip Lars!

Page 1 of 1 (7 items)