MECM 2303 sur SQL Server 2022 impose un choix précis : laisser le niveau de compatibilité par défaut (160) ou le fixer à 150. Voici une réponse nette, des explications techniques et un guide pas‑à‑pas pour configurer correctement votre base site ConfigMgr.
Niveau de compatibilité SQL pour MECM 2303 installé sur SQL Server 2022
Vue d’ensemble de la question
Lors de l’installation d’un nouveau site Microsoft Endpoint Configuration Manager (MECM) 2303 adossé à SQL Server 2022, la documentation recommande d’utiliser le niveau de compatibilité 150 (équivalent SQL Server 2019). Or, si vous pré‑créez manuellement la base dans SQL Server Management Studio (SSMS), la liste déroulante propose par défaut 160 (niveau propre à SQL 2022). D’où la question : faut‑il laisser 160 ou forcer 150 ?
Réponse & solution (court et clair)
Oui, il faut absolument fixer le niveau de compatibilité à 150 pour rester dans la matrice de support ConfigMgr 2303. Deux méthodes équivalentes :
- Pendant la création manuelle de la base
SSMS → New Database → onglet Options → Compatibility level → sélectionnez SQL Server 2019 (150) au lieu de 160. - Après la création
Exécutez la commande T‑SQL suivante :ALTER DATABASE <NomDeLaBase> SET COMPATIBILITY_LEVEL = 150;
Remplacez<NomDeLaBase>
par le nom réel de votre base ConfigMgr (ex.CM_PRI
).
L’opération est en ligne : aucun redémarrage du service SQL n’est requis et la base reste disponible. Attendez-vous simplement à une régénération transitoire de certains plans d’exécution dans la base concernée.
Pourquoi 150 et pas 160 ? Explications techniques utiles
Le niveau de compatibilité pilote les règles d’optimisation de SQL Server (Cardinality Estimator, lot d’optimisations Intelligent Query Processing, heuristiques diverses). Avec SQL 2022, le niveau 160 active de nouvelles optimisations (par ex. gestion affinée des plans sensibles aux paramètres, variantes d’estimation de cardinalité, feedbacks supplémentaires, etc.). MECM 2303 n’est pas officiellement qualifié pour ces comportements 160. Rester en 150 garantit :
- Conformité support côté ConfigMgr (matrice de compatibilité)
- Prévisibilité des plans d’exécution et des statistiques au regard des requêtes propres à MECM
- Moins de surprises en production (éviter des régressions potentielles de performance ou d’indexation dues à un changement d’optimiseur)
Important à comprendre : le moteur reste SQL Server 2022. Seul le pipeline d’optimisation se comporte comme en 2019. Vous ne « perdez » pas SQL 2022 : vous neutralisez seulement des optimisations non encore certifiées pour MECM 2303.
Checklist rapide de conformité (pré‑création ou post‑création)
Élément | Valeur/Action recommandée | Pourquoi | Commande de vérification |
---|---|---|---|
Niveau de compatibilité | 150 | Matrice de support ConfigMgr 2303 | SELECT compatibility_level FROM sys.databases WHERE name='CM_XXX'; |
Collation | SQL_Latin1_General_CP1_CI_AS | Recommandation traditionnelle ConfigMgr | SELECT collation_name FROM sys.databases WHERE name='CM_XXX'; |
Récupération | Simple (souvent utilisé pour CM) | Limite la croissance du journal (contexte CM) | SELECT recovery_model_desc FROM sys.databases WHERE name='CM_XXX'; |
Auto stats | ON (création/mise à jour) | Maintenir des plans pertinents | SELECT is_auto_create_stats_on, is_auto_update_stats_on FROM sys.databases WHERE name='CM_XXX'; |
CU SQL 2022 | Appliquer la CU recommandée | Correctifs et stabilité du moteur | SELECT @@VERSION; |
Droits d’installation | sysadmin (ou dbcreator+securityadmin) | Création/assignation propres des objets CM | Contrôle via SSMS / documentation interne |
Guide détaillé selon votre scénario
Scénario A : vous pré‑créez la base dans SSMS
- Ouvrez SSMS → connectez‑vous à l’instance hébergeant la base site.
- Databases → clic droit → New Database…
- Nom : CM_<CodeSite> (ex.
CM_PRI
). - Onglet Options :
- Compatibility level = SQL Server 2019 (150)
- Collation =
SQL_Latin1_General_CP1_CI_AS
- Recovery model = Simple (adaptez si vos exigences de RPO/RTO diffèrent)
- Auto Create/Update Statistics = True
- Onglet Files :
- Choisissez des tailles initiales réalistes (ex. fichier de données en dizaines de Go selon la taille attendue)
- Préférez une croissance fixe en Mo plutôt qu’en pourcentage (ex. 512 Mo ou 1024 Mo)
- Séparez données et journaux sur des volumes adaptés (IOPS/latence)
- Validez.
- Vérifiez immédiatement :
SELECT name, compatibility_level, collation_name, recovery_model_desc FROM sys.databases WHERE name = 'CM_PRI';
Scénario B : la base existe déjà en 160
- Fenêtre de maintenance : planifiez un créneau court (l’opération est en ligne mais peut invalider le cache de plans de la base).
- Sauvegarde : effectuez une sauvegarde de la base et du journal (bonne pratique).
- Basculer à 150 :
ALTER DATABASE CM_PRI SET COMPATIBILITY_LEVEL = 150;
- Vérifier :
SELECT name, compatibility_level FROM sys.databases WHERE name = 'CM_PRI';
- Surveiller : contrôlez brièvement l’activité (attentes, CPU, lectures) et les jobs CM/SQL habituels.
Bonnes pratiques complémentaires (spécifiques MECM)
- Laisser ConfigMgr créer la base lorsque c’est possible : l’assistant positionne automatiquement 150. Le « cas 160 » survient surtout lors d’une pré‑création manuelle.
- Collation : utilisez
SQL_Latin1_General_CP1_CI_AS
pour éviter des incohérences de tri/égalité au sein des tables CM. - Dimensionnement fichiers : préallouez pour minimiser les croissances automatiques (surtout le journal, très sollicité lors des synchronisations et traitements de maintenance).
- Automatisation : vérifiez le niveau de compatibilité dans vos scripts de provisioning afin d’éviter la dérive (exemple PowerShell ci‑dessous).
- CU SQL 2022 : restez à jour sur les mises à jour cumulatives afin de bénéficier des correctifs du moteur et des performances.
- Permissions : pendant l’installation initiale, fournissez au compte de service et à l’ordinateur site server les droits nécessaires (sysadmin recommandé pendant le setup, à affiner ensuite si votre politique l’exige).
Scripts prêts à l’emploi
Détecter d’un coup d’œil les niveaux de compatibilité
SELECT
name,
compatibility_level,
collation_name,
recovery_model_desc
FROM sys.databases
ORDER BY name;
Forcer 150 si la base CM est en 160
IF DB_ID('CM_PRI') IS NOT NULL
BEGIN
DECLARE @lvl int = (SELECT compatibility_level FROM sys.databases WHERE name = 'CM_PRI');
IF @lvl <> 150
BEGIN
PRINT 'Basculer CM_PRI vers le niveau de compatibilite 150...';
ALTER DATABASE CM_PRI SET COMPATIBILITY_LEVEL = 150;
PRINT 'OK. Nouveau niveau : ' + CAST((SELECT compatibility_level FROM sys.databases WHERE name='CM_PRI') AS varchar(10));
END
ELSE
BEGIN
PRINT 'CM_PRI est deja en 150.';
END
END
ELSE
BEGIN
RAISERROR('Base CM_PRI introuvable.', 16, 1);
END
PowerShell (module SqlServer) : contrôle et mise en conformité
# Requiert le module SqlServer (Install-Module SqlServer)
$Instance = "MONSERVEUR\INSTANCE"
$DbName = "CM_PRI"
$svr = New-Object Microsoft.SqlServer.Management.Smo.Server $Instance
$db = $svr.Databases[$DbName]
if (-not $db) {
throw "La base $DbName n'existe pas sur $Instance"
}
if ($db.CompatibilityLevel -ne "Version150") {
Write-Host "Bascule de $DbName vers Version150..."
$db.CompatibilityLevel = "Version150"
$db.Alter()
Write-Host "OK. Nouveau niveau : $($db.CompatibilityLevel)"
} else {
Write-Host "$DbName est déjà en Version150."
}
Comparatif synthétique : 150 vs 160 (dans le contexte MECM 2303)
Le tableau ci‑dessous n’oppose pas des « bonnes » et « mauvaises » options, mais résume le risque de dérive pour MECM 2303 :
Aspect | Compat. 150 | Compat. 160 | Conséquence pour MECM 2303 |
---|---|---|---|
Comportement Optimiseur | Aligné SQL 2019 | Nouveautés SQL 2022 | 150 = base de référence support; 160 = potentiellement non qualifié |
Stabilité des plans | Prévisible vis‑à‑vis de MECM | Peut changer | Évite les régressions inattendues |
Fonctionnalités moteur 2022 | Disponibles | Disponibles | Rien de « perdu » en restant à 150 (hors optimiseur 160) |
Support officiel CM 2303 | Oui | Non garanti | Restez à 150 |
Procédure d’installation MECM avec base conforme (pas‑à‑pas)
- Pré‑requis SQL : instance SQL 2022 dimensionnée (CPU, RAM, stockage), CU récente appliquée, protocoles réseau approuvés.
- Création base : laissez MECM la créer (recommandé) ou faites‑le vous‑même en forçant 150 + collation recommandée.
- Permissions : compte de service SQL et ordinateur du site server avec droits adéquats (idéalement sysadmin durant l’installation).
- Installation MECM : exécutez le setup, pointez sur l’instance SQL, laissez l’assistant valider les prérequis.
- Vérifications post‑setup :
- Recontrôlez le niveau de compatibilité :
SELECT compatibility_level FROM sys.databases WHERE name='CM_XXX';
- Confirmez la collation et le mode de récupération
- Exécutez un cycle de maintenance CM standard pour s’assurer de la stabilité
- Recontrôlez le niveau de compatibilité :
Validation & diagnostic
Vérifier rapidement la conformité
SELECT
d.name AS DBName,
d.compatibility_level,
d.collation_name,
d.recovery_model_desc,
suser_sname(d.owner_sid) AS OwnerName
FROM sys.databases AS d
WHERE d.name LIKE 'CM_%';
Points de contrôle côté ConfigMgr
- Logs d’installation : vérifiez que l’assistant n’a pas signalé d’incompatibilités SQL.
- Console MECM : surveillez les composants (statut vert), la réplication inter‑sites (si hiérarchie), la santé des rôles (MP, SUP, etc.).
- Performances : regardez les latences disque et les temps d’exécution des jobs de maintenance (index, statistiques).
FAQ & cas particuliers
Ai‑je « moins » de SQL 2022 en 150 ?
Non. Vous utilisez toujours le moteur SQL 2022 (sécurité, stockage, planification, TDS, etc.). Seules des optimisations d’optimiseur spécifiques au niveau 160 sont neutralisées. Vous restez donc éligible aux améliorations générales du produit (hors celles explicitement conditionnées par 160).
Peut‑on repasser en 160 plus tard ?
Oui, techniquement c’est un simple ALTER DATABASE
. Mais faites‑le uniquement lorsque votre version de ConfigMgr le recommande explicitement. Avant de changer : sauvegarde, test de charge et plan de retour arrière.
Impact en ligne de la bascule 160 → 150 ?
Le service SQL ne redémarre pas. La base reste en ligne. Les plans d’exécution de la base sont invalidés et se régénèrent au fil des requêtes. Impact typique : pic CPU/IO modéré et transitoire.
Always On / Availability Groups
Le niveau de compatibilité est par base. Répliquez le réglage 150 sur toutes les réplicas pour garantir un comportement cohérent après bascule.
Collation différente
Évitez de diverger de SQL_Latin1_General_CP1_CI_AS
pour la base site. Changer une collation existante après coup est complexe ; mieux vaut créer correctement dès le départ.
Runbook d’intervention (copier‑coller)
- Identifier la base :
CM_<CodeSite>
. - Capturer l’état :
SELECT name, compatibility_level, collation_name, recovery_model_desc FROM sys.databases WHERE name='CM_PRI';
- Basculer au besoin :
ALTER DATABASE CM_PRI SET COMPATIBILITY_LEVEL = 150;
- Confirmer :
SELECT name, compatibility_level FROM sys.databases WHERE name='CM_PRI';
- Surveiller 30–60 min (CPU, IO, temps de requêtes clés MECM).
Modèle d’automatisation (pipeline d’infra)
Lorsque vous provisionnez des environnements via IAC/DevOps, ajoutez une étape « validation ConfigMgr » qui impose 150 sur la base site.
# Exemple de bloc DSC/Pipeline : pseudo-code
Task "Enforce-CM-DB-Compat" {
Invoke-Sqlcmd -ServerInstance "SQL01" -Database "master" -Query @"
IF DB_ID('CM_PRI') IS NOT NULL AND
(SELECT compatibility_level FROM sys.databases WHERE name='CM_PRI') <> 150
BEGIN
ALTER DATABASE CM_PRI SET COMPATIBILITY_LEVEL = 150;
END
"@
}
Erreurs fréquentes & corrections
- « L’assistant MECM refuse la base » : vérifiez collation, compatibilité (150), droits et espace disque.
- « Performances erratiques après création en 160 » : repassez en 150, regénérez les statistiques si nécessaire, laissez un cycle de charge se stabiliser.
- « Le journal grossit trop » : contrôlez le mode de récupération (Simple recommandé pour CM) et planifiez des opérations de maintenance régulières.
Récapitulatif décisionnel
Pour MECM 2303 hébergé sur SQL Server 2022, la ligne directrice est simple :
- Nouveau site ou base pré‑créée : choisir 150 avant de lancer le setup.
- Site existant en 160 : revenir à 150 et valider la stabilité.
- Évolutions ultérieures : n’envisager 160 qu’en fonction des recommandations explicites des versions suivantes de ConfigMgr.
Annexes
Requêtes utiles d’inventaire SQL
-- Version et build SQL
SELECT @@VERSION AS VersionDetaillee,
SERVERPROPERTY('ProductVersion') AS ProductVersion,
SERVERPROPERTY('ProductLevel') AS ProductLevel,
SERVERPROPERTY('Edition') AS Edition;
-- Liste des bases CM et niveaux
SELECT name, compatibility_level
FROM sys.databases
WHERE name LIKE 'CM_%'
ORDER BY name;
-- Paramètres d'auto-statistiques
SELECT name,
is_auto_create_stats_on,
is_auto_update_stats_on
FROM sys.databases
WHERE name LIKE 'CM_%';
Bonnes pratiques de fichiers (rappel)
- Fichier de données : tailles initiales adaptées + croissance fixe.
- Fichier journal : taille initiale suffisante (éviter l’extension trop fréquente) + croissance fixe.
- Stockage séparé pour mdf/ndf et ldf si possible.
- Surveillez la fragmentation des index et actualisez les statistiques selon votre fenêtre de maintenance.
Conclusion
Le sujet peut sembler subtil car SQL 2022 incite naturellement à sélectionner 160. Pourtant, pour Configuration Manager 2303, la bonne décision est de fixer 150. Cela vous maintient dans le périmètre de support, évite des changements imprévus de plans d’exécution et assure une trajectoire stable pour vos opérations MECM. Suivez le guide ci‑dessus (pré‑création ou correction post‑création), validez avec les requêtes de contrôle et inscrivez ce réglage dans vos scripts d’automatisation. Ainsi, votre site ConfigMgr s’appuie sur une base SQL 2022 moderne, sans prendre le risque d’optimisations non qualifiées.
En un mot : SQL 2022 moteur, compatibilité 150, MECM 2303 heureux.