Dans le cadre de la gestion quotidienne des environnements SharePoint, une des taches obligatoires est le contrôle régulier des logs :
- Log Windows (Event Viewer)
- Log SharePoint (ULS)
Dans le sujet qui nous importe, lors du debbuging, on peut être ammené à définir un niveau de logging supérieur pour certains types de contrôle.
Ceci se fait depuis la Centrale Administration :
- Rubrique “Operations”
- Lien “Diagnotic Logging”
Ainsi dans la partie centrale de la fenêtre, on a le choix du type d’activité à contrôler et le niveau de logging à appliquer :
Ainsi, dans ce cas, j’ai spécifié la mise en place du logging avec le mode Verbeux pour toutes les actions du Timer pour les Job.
A partir de ce moment, on peut voir apparaître l’erreur Event ID 3351 :
Event Type: Error
Event Source: Windows SharePoint Services 3
Event Category: Database
Event ID: 3351
Date: 31.05.2010
Time: 14:10:50
User: N/A
Computer: CHWS008
Description:
SQL database login failed. Additional error information from SQL Server is included below.Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'.
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Une recherche sur google donne différentes raisons, mais toutes semblent liées à la non utilisation du compte de service pour différentes actions :
- Sauvegarde de collection via STSADM
- Service SPTimer
- Outil de Backup dédié
- …
Mais il existe une autre situation qui est liée au changement de niveau de log défini juste avant :
- Les permissions du compte de service “Windows SharePoint Services Tracing” (ou SPTracing)
Ce service gère toute la création et le renseignement des fichier de log ULS. Dans le cas où ses droits ne sont pas assez élevés, on se retrouve avec des fichier de log aillant comme seule information :
05/30/2010 20:01:32.31 wsstracing.exe (0x09DC) 0x05E0 ULS Logging Unified Logging Service uls1 Monitorable Tracing Service lost trace events. Current value 12.
Dont une petite aide est disponible :
Dans notre contexte, il ne suffit pas de redémarrer les services, mais surtout lui changer le compte de service et redémarrer le serveur pour rafraichir toute la configuration.
Le dernier service à contrôler les le compte de service SPWriter :
- Les permissions du compte de service “Windows SharePoint Services VSS Writer” (ou SPWriter)
En effet, de base, ce service est configuré pour fonctionner avec le “Local System Account”, qui n’a donc pas accès aux bases de données SharePoint.
Il vous suffit donc de modifier le compte de ce service et de relancer celui-ci ainsi que le service SPTimerV3 pour ne plus trouver ce message dans les erreurs Windows.
Romelard Fabrice [MVP]
Commentaires
Enregistrer un commentaire