Blog - Mathieu Chateau

Symptômes:

En voulant supprimer un ancien serveur SQL sur SharePoint depuis l’administration centrale:

An object in the SharePoint administrative framework, "SPDatabaseServiceInstance Name= could not be deleted because other objects depend on it. Update all of these dependants to point to null or different objects and retry this operation. The dependant objects are as follows: SPWebService Name=WSS_Administration

Correction:

Vous avez déplacé la base (à priori ;)) mais il SharePoint en a gardé une référence. Vous pouvez alors utilisé une application Web qui pointe sur le bon serveur pour mettre à jour celui de l’administration centrale:

$centralAdmin=Get-SPWebApplication -IncludeCentralAdministration | ? {$_.DisplayName -match ‘SharePoint Central Administration’}
$goodExample=Get-SPWebApplication -identity ‘http://mygoodwebapp’
$centralAdmin.Parent.DefaultDatabaseInstance=$goodExample.Parent.DefaultDatabaseInstance
$centralAdmin.Parent.Update()
$centralAdmin.Update()

Utilisez les alias SQL pour la prochaine fois 🙂

Vous avez peut-être déjà rencontré ce message d’avertissement SharePoint:

Object Cache: The super user account utilized by the cache is not configured. This can increase the number of cache misses, which causes the page requests to consume unneccesary system resources.
 To configure the account use the following command 'stsadm -o setproperty -propertyname portalsuperuseraccount -propertyvalue account -url webappurl'. The account should be any account that has Full Control access to the SharePoint databases but is not an application pool account.

Généralement, j’utilise le script powershell suivant (toutes mes Application Web sont en claim):

foreach ($a in (Get-SPWebApplication))
{
   $a;
   $a.Properties[« portalsuperuseraccount« ];
   $a.Properties[« portalsuperreaderaccount« ];
   $a.Properties[« portalsuperuseraccount« ] =« i:0#.w|mydomainSharePointAdminAccount« ;
   $a.Properties[« portalsuperreaderaccount« ] =« i:0#.w|mydomainSharePointDedicatedReadAccount« ;
   $a.Update();
}

Cependant, aucun site n’avait les 2 propriétés incorrectes. Pour trouver facilement, il faut basculer dans l’onglet Details de l’event:

Il s’y trouve le PID (Process ID) ayant généré l’erreur:

Il suffit ensuite d’utiliser par exemple Process Explorer de sysinternals pour identifier le site qui pose problème:

Dans le cas présent il s’agit de la centrale Admin, qui ne doit pas être en mode claim par ailleurs