Microsoft Project – livrable – fichiers srchui.dll et jscript.dll

Depuis Microsoft Project 2010 et 2013, en utilisant le menu de gestion des livrables, vous obtenez:

23-03-2014 12-09-39Ce message qui semble venir d’outre tombe de la version 2003 apparaît au lieu du panneau latéral.

Inutile de les chercher sur votre machine, vous ne les avez certainement pas.

C’est en fait un problème avec la zone « Internet » de internet explorer, même si votre serveur Project est dans la zone « intranet ».

La zone internet ne doit pas être avec le curseur au maximum en haut, sinon les livrables Project ne fonctionnent plus.

26-03-2014 07-43-13

Le tout même sur Windows Server 2012 R2 + Project 2013 SP1 + IE 11 complètement à jour…

 

 

SharePoint/Project 2013 SP1 – Configuration wizard

Après avoir déployé le Service Pack 1 de SharePoint/Project 2013, il faut passer le configuration wizard. Dans le cas présent, il échouait sur tous les noeuds avec la même erreur dans le log:

SyncUpgradeTimerJob: sleeping for 10 seconds
SyncUpgradeTimerJob: sleeping for 10 seconds
SyncUpgradeTimerJob: Upgrade timer job failed. Return -1.
The exclusive inplace upgrader timer job failed.

 

Etape 1 – autre log

Un autre log est beaucoup plus utile, au même endroit, il porte le nom upgrade-date-blahblah-error.log:

Exception: The operation cannot be performed on database "WSS_UsageApplication" because it is involved in a database mirroring session or an availability group. Some operations are not allowed on a database that is participating in a database mirroring session or in an availability group.  ALTER DATABASE statement failed

Ou alors en utilisant la commande upgrade-spfarm:

29-03-2014 12-55-19

 

Solution

Supprimer le miroir ou always-on le temps de l’upgrade sur cette base.

 

 

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: 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à ^^

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