Discussion :

[vponcet0774]

Bonjour,

Suite à une installation de SQL Server 2008 R2, l'agent SQL ne veux pas démarré et voici le message que j'ai (en pièce jointe)

Merci de votre aide.

Vince.

[dbaffaleuf]

Il faudrait regarder le contenu du fichier SQLAGENT.OUT (sous le répertoire de l'instance => \ Log)

[Oishiiii]

Sachez également que vous ne pouvez pas démarrer l'agent avec la version Express d'SQL Server.

[annedeblois]

Bonjour,

Désolée de remonter le sujet, mais j'ai exactement le même problème sur un de nos serveurs de test. L'agent est nécessaire pour trouver une meilleure solution de prise de sauvegarde de nos bases de données.

SQLAGENT.OUT m'a donné ceci:

2011-08-18 09:30:03 - ! [000] Unable to connect to server 'T2T020\MOSS1'; SQLServerAgent cannot start
2011-08-18 09:30:03 - ! [298] SQLServer Error: 18452, Login failed. The login is from an untrusted domain and cannot be used with Windows authentication. [SQLSTATE 28000]
2011-08-18 09:30:03 - ! [382] Logon to server 'T2T020\MOSS1' failed (DisableAgentXPs)
2011-08-18 09:30:03 - ? [098] SQLServerAgent terminated (normally)

Voici ce que j'ai fait jusqu'à présent:
1) Vérifier que le serveur est dans la bonne unité organisationnelle (en me disant que peut-être un petit malin l'a déplacé)
2) Faire gpupdate /force
3) Vérifier la stratégie de sécurité locale (droits des utilisateurs): le droit 'Lock pages in memory' avait été vidé complètement, alors j'ai remis le groupe local administrateurs ainsi que le compte AD dédié aux services SQL Server et Agent SQL Server, et puis j'ai redémarré
4) Vérifier que l'option NetBIOS sur TCP/IP est bien activée sur la carte réseau principale
5) Vérifier la version de MDAC
6) Changer l'authentification de Windows (intégrée) à mixte, définir un mot de passe fort à 'sa' et revenir à l'authentification Windows intégrée
7) Changer le compte de service de SQL Agent pour le compte système local, rien à faire, remettre le compte AD dédié au service
8) Tenter de réinstaller le Service Pack 2.

J'ai également soumis le problème aux responsables de la sécurité et de l'administration des serveurs Windows, car il est déjà arrivé par le passé que des applications cessent de fonctionner à la suite de la mise à jour d'un objet de sécurité de groupe (GPO). Ils ne me sont pas encore revenus à ce sujet...

C'est le brouillard total... Des idées?

Euh... ah oui, voici les informations système:
- Windows 2003 Enterprise Server SP2
- SQL Server 2008 Standard 64 bits avec SP2

[dbaffaleuf]

C'est un pb de connexion à l'instance (le paramètre -i dans le service)
Avec quel compte de service est démarré l'agent ? et l'instance ?

[annedeblois]

Le paramètre -i correspond bien à l'instance.

Le compte de service est un compte Active Directory, il s'appelle DSServiceSQL2_Tecno (tecno sans le h pour environnement de lab), et je lui ai restauré les droits administratifs ainsi que le droit 'lock pages in memory', idem le droit 'log on as a service'.

[dbaffaleuf]

Le paramètre -i correspond bien à l'instance.

Le compte de service est un compte Active Directory, il s'appelle DSServiceSQL2_Tecno (tecno sans le h pour environnement de lab), et je lui ai restauré les droits administratifs ainsi que le droit 'lock pages in memory', idem le droit 'log on as a service'.

- C'est le même compte pour l'agent et l'instance ?
- Est-il dans le groupe windows pour l'agent ou pour l'instance ? (ex pour SQL 2005:
- SQLServer2005MSSQLUser$<MACHINE>$MSSQLSERVER => groupe pour l'instance
- SQLServer2005SQLAgentUser$<MACHINE>$MSSQLSERVER => groupe pour l'agent)

Normalement ces groupes sont ajoutés à l'installation dans la liste des logins autorisés en sysadmin, ce qui permet à l'agent de se connecter à l'instance et d'attaquer msdb:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
select PR1.principal_id, PR1.name, PR1.type_desc , PR2.name 'role'
from sys.server_principals PR1
inner join sys.server_role_members R on R.member_principal_id = PR1.principal_id
inner join sys.server_principals PR2 on R.role_principal_id = PR2.principal_id
where PR1.name like 'UTRECHT\SQLServer2005%'
 
principal_id    	 name     			                           type_desc     			role
--------------------------------------------------------------------------------------------------------------------------------------
259			UTRECHT\SQLServer2005MSSQLUser$UTRECHT$MSSQLSERVER		WINDOWS_GROUP		sysadmin
260			UTRECHT\SQLServer2005SQLAgentUser$UTRECHT$MSSQLSERVER	WINDOWS_GROUP		sysadmin

[annedeblois]

Tout y est. Cela dit, j'ai trouvé le bobo: problème d'authentification (Kerberos ou NTLM, je l'ignore, c'est sûrement le premier) dû à une interface réseau qui boucle à l'infini.

Comment je l'ai résolu:

1. Démarrer le registre
2. Ouvrir la clé HKLM\System\CurrentControlSet\Control\LSA
3. Ajouter une valeur DWORD appelée “DisableLoopbackCheck”
4. Mettre la valeur à 1
5. Redémarré le serveur

Et ça marche nickel

Je n'ai pas le lien par coeur, mais c'était après plus de 6 heures de recherche sur Google...

Cela dit, merci beaucoup pour les pistes!