Limites du reporting de Configuration Manager
Après avoir eu plusieurs fois la même conversation chez différents clients, j’ai été contacté récemment par une personne relayant l’insatisfaction d’un client sur les capacités du reporting de System Center Configuration Manager 2007 (ConfigMgr 2007) et se demandant si la prochaine version (ConfigMgr 2012) aurait les mêmes limitations.
Il me semble utile de préciser quelques points et de donner des pistes de solution.
Les limites de montée en charge de ConfigMgr 2007 sont décrites dans les pages officielles des configurations supportées. Avec ses nouveaux mécanismes, ConfigMgr 2007 R3 a porté cette limite à 300 000 ordinateurs gérés dans une même hiérarchie quand la limite initiale était à 200 000.
Pour autant, est-il possible de lancer un rapport qui afficherait cette liste de 300 000 ordinateurs, voire une combinatoire de, par exemple, la liste des mises à jour pour chacun de ces 300 000 ordinateurs ?
En théorie, il est possible que cela fonctionne, mais, très probablement, dans un grand nombre de rapports, la réponse serait négative.
Sur le plan purement pratique, je me pose toujours la question de l’utilité de sortir un rapport de plusieurs centaines de lignes voire au-delà. Je me souviens d’une période où les gros systèmes crachaient des centaines de pages de listing qui finissaient par faire le bonheur des écoles maternelles. Aujourd’hui que les rapports ne sont plus systématiquement sur papier, le bon sens ne semble plus l’emporter et, plutôt que de mieux cibler les résultats attendus, les utilisateurs n’hésitent plus à lancer des rapports très volumineux ; quitte à les retraiter, ensuite, sur Excel. Pourquoi, dans ce cas, ne pas lancer directement la requête depuis Excel ? Est-ce par manque de compétence sur le langage SQL ? Je m’égare, un peu.
Sur le plan technique, différentes limitations peuvent intervenir.
Le fichier d’aide de Configuration Manager indique comment modifier nombre maximal de lignes renvoyées par une requête de rapport. Cette limite est réglée sur 10 000 par défaut. Dans les articles voisins de celui-ci, vous trouverez également comment configurer le paramètre de dépassement de délai du script ASP ainsi que comment configurer les paramètres de connexion et de délai d'expiration de commandes.
Le reporting classique de ConfigMgr repose sur différents composants dont Internet Information Services (IIS) et Active Server Pages (ASP). L’article kb944886 détaille une raison possible de dysfonctionnement du reporting classique de ConfigMgr et donne une piste pour résoudre le problème.
Ces solutions repoussent le moment où le reporting classique atteindra ses limites, mais ne les élimine pas.
Sans aller jusqu’à éliminer les limites, l’utilisation de SQL Server Reporting Services (SSRS) permet d’aller encore un peu plus loin. Pour mémoire, le point Reporting Services ou Reporting Service Point (RPS) est un rôle de système de site apporté par ConfigMgr 2007 R2 et qui est également présent dans ConfigMgr 2007 R3.
Les services de reporting apportés par SSRS ont évolués dans le temps. Dès SQL Server 2005, il est possible de bénéficier d’un moteur 64 bits qui tire parti des architectures des processeurs actuels. Pour une meilleure montée en charge, il peut être utile de regarder les capacités de SSRS dans SQL Server 2008 ou SQL Server 2008 R2. Là où SSRS repose sur IIS et ASP.Net dans SQL Server 2005, SQL Server 2008 et SQL Server 2008 R2 apportent leur propre moteur de restitution de pages fondé sur HTTP.SYS.
Pour reprendre la question initiale, est-ce que ConfigMgr 2012 permettra d’aller plus loin que ConfigMgr, la réponse est indéniablement oui, mais pour la bonne et simple raison que le seul outil de reporting de ConfigMgr 2012 est uniquement fondé sur SSRS. Ceci étant écrit, je reste sur ma position qu’il est préférable d’éviter de tomber dans le travers qui renvoie trop de données.