Project 2013: Upgrade-SPProjectWebInstance – ActivatePWAWebThemesFeature failed

En voulant mettre à jour une instance Project 2010 en 2013:

Upgrade-SPProjectWebInstance https://url/pwa

Il s’en ait suivi cette erreur:

Upgrade-SPProjectWebInstance : Post provision setup failed.
ActivatePWAWebThemesFeature failed.
At line:1 char:1
+ Upgrade-SPProjectWebInstance https://url/pwa
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 + CategoryInfo : InvalidData: (Microsoft.Offic...radePwaInstance:
 PSCmdletUpgradePwaInstance) [Upgrade-SPProjectWebInstance], ProvisionException
 + FullyQualifiedErrorId : Microsoft.Office.Project.Server.Cmdlet.PSCmdletUpgradePwaInstance

 

Solution:

Il faut d’abord mettre à jour le site SharePoint en 2013 pour que la fonctionnalité soit présente:

Upgrade-SPSite -Identity https://url/pwa -versionupgrade

puis relancer la commande du départ:

Upgrade-SPProjectWebInstance https://url/pwa

SharePoint 2010 – erreur – suppression d’un serveur SQL référence – wss_administration

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 🙂

SharePoint 2013 – Ajouter un compte géré – Access denied

Symptômes:

Lorsque vous ajoutez un compte géré:

Résolution:

Le compte déclaré pendant la création de la ferme exécute le service SharePoint Timer Service. Ce compte a besoin d’être administrateur local.

Malgré l’erreur, le compte a été ajouté. Cependant si vous allez dans les comptes gérés depuis l’administration centrale, cela ne fonctionne plus (Object reference not set to an instance of an object):

Il faut alors:

  • Supprimer le compte ajouté en PowerShell : Remove-spManagedAccount -identity mondomainenouveauCompte
  • Rendre le compte du timer administrateur local
  • Redémarrer le service SharePoint Timer pour qu’il prenne en compte le privilège
  • iisreset
  • Ajouter de nouveau le compte géré.

SharePoint 2010 – The super user account utilized by the cache is not configured

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

SharePoint 2010: CAPI2 failed extract root list the data is invalid

Un des serveurs SharePoint 2010 a soudainement généré le message d’erreur suivant « en masse » (toutes les 20 secondes):

Failed extract of third-party root list from auto update cab at....With error: the data is invalid

CAPI2 Failed extract thirdt party data is invalid

L’impact le plus notable est une très grosse lenteur soudaine et persistante, alors que SQL et le cpu ne pas solicité.

Il est connu que les assembly .Net sont signés, et que par défaut Windows cherche à valider leur signature. Cela peut poser des lenteurs supplémentaires au 1er appel des application pools. J’avais d’ailleurs déjà écrit un billet à ce sujet pour SharePoint 2007.

Mais là c’est bien après le 1er appel, et le serveur a accès à Internet directement.

Une trace wireshark montre tout de suite des essais répétés pour télécharger des certificats:

Pour tracer le coupable, il suffit d’aller dans la vue détaillée de l’eventlog, et de récupérer le PID du processus qui a généré l’erreur (344):

Lancez ensuite Process Monitor de Sysinternals, en filtrant sur le PID 344:

On voit des essais répétés sur un fichier temporaire de type Cab.tmp, qu’il essaye de copier dans cryptneturlCache.

Je suis tombé sur cet article d’un autre MVP, et j’ai appliqué la KB indiquée même si l’erreur de correspondait pas exactement.

  • L’erreur dans l’eventlog disparait immédiatement,
  • Mais les lenteurs persistent.

J’ai constaté qu’il essayait toujours de télécharger le fichier (en prenant un 304 not modified à chaque fois).

J’ai fais une variante de l’article ci-dessus, j’ai supprimé le dossier CryptNetUrlCache mais dans le profile du compte AD SharePoint.

Et voilà ^^

SharePoint 2010: Unable to index into an object of type Microsoft.SharePoint.SPListItem

En voulant peupler une liste SharePoint via PowerShell, j’ai le message d’erreur suivant:

Unable to index into an object of type Microsoft.SharePoint.SPListItem.
 + $newItem[ <<<< "column_name"] = $SPFieldUserValue
 + CategoryInfo : InvalidOperation: (column_name:String) [], RuntimeException
 + FullyQualifiedErrorId : CannotIndex

Le nom des colonne est sensible à la casse, j’avais oublié une majuscule!

SharePoint 2010 – Accès refusé en boucle

Symptômes

  • Lorsque vous essayez d’accéder aux sites SharePoint, vous bouclez sur un accès refusé quelque soit le compte
  • Dans les logs : 
    SPWindowsTokenCacheServiceApplication.CacheHandle() call to OpenProcess() failed for '0#.w|mondomainemonlogin': PID=2956, ErrorCode=5, Exception=System.ComponentModel.Win32Exception: Access is denied
    The Secure Store Service application Secure Store Service is not accessible. The full exception text is: Cannot open database "Secure_Store_Service_DB_guid" requested by the login. The login failed.  Login failed for user 'mondomaineaccount'

Résolution

Security Token Service Application doit tourner avec le compte admin de la ferme

Cannot start queue. SSP: SiteUID: Url: Queue: ProjectQ

 

Log Name: Application
Source: Microsoft-SharePoint Products-Project Server
Event ID: 7626
Task Category: Queue
Level: Critical
Description:
Cannot start queue. SSP: <GUID Project server application> SiteUID: <GUID Site> Url: Queue: ProjectQ

Vous avez également son frère jumeau, identique mais avec Url:  Queue: TimesheetQ

On va corriger, ça, mais pour les prochaines fois, il faut d’abord supprimer l’instance PWA et seulement après l’Application Web.

#Récupérer l’application project

$a= get-spserviceapplication | ? {$_.Typename -like "*Project*"
#Vérifier qu'on a bien le pwa fantôme (mettre le guid siteUID)
$bad=$a.SiteCollection | ?{$_.SiteID -eq "a2c27d0d-1e66-43af-94d2-83b1b268658f"
$bad| select id,name,siteid,webappid |fl 

Id : 4d4389d1-e32b43a380439105a83fceb8
Name : PWA fantome a supprimer:
SiteId : a2c27d0d
1e6643af94d283b1b268658f
WebAppId : 9a618b96
6b00472c93f74c5f53822050 

#Si c'est ok, on supprime! 
$bad.Delete() 
#On relance les commandes pour valider qu'il a disparu
$bad=$a.SiteCollection | ?{$_.SiteID -eq "a2c27d0d-1e66-43af-94d2-83b1b268658f"
$bad| select id,name,siteid,webappid |fl

 

Project Server 2010 – could not be deleted because other objects depend on it

Problème:

Suite à la suppression partielle d’un site PWA, la recréation du même site échoue avec le message suivant:

An object in the SharePoint administrative framework, "ProjectDatabase Name=ProjectServer_Archive", 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:ProjectSite Name=c1a6cdf0-cf4b-452f-8fea-ef339e8be2cc

Solution:

La solution que j’ai appliqué est de supprimer le site pseudo fantôme:

$a=(Get-SPServiceApplication | ?{$_.Name -match "project"}).SiteCollection | ?{$_.SiteID -match "c1a6cdf0-cf4b-452f-8fea-ef339e8be2cc"}
$a
$a.delete()

et voilà!