Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

SCCM : Mince alors... Des fenêtres de maintenance mystérieuses

ayi

<h2><a name="p-34083-quest-ce-que-jessaie-de-faire-1" class="anchor" href="#p-34083-quest-ce-que-jessaie-de-faire-1" aria-label="Heading link"></a>Qu’est-ce que j’essaie de faire ?</h2>
Nous avons quelques clients SCCM, principalement des sites web publics fonctionnant sur Windows Server 2008 R2 avec IIS 7.5, qui sont surveillés par un système appelé <a href="http://xymon.sourceforge.net/" rel="noopener nofollow ugc">XYmon</a>. Nous avons récemment remarqué que ces serveurs redémarrent après l’installation de leurs mises à jour Windows mensuelles environ une heure trop tôt. Il y a un certain délai inhérent aux actions du client SCCM et au système de surveillance, mais XYmon perd la connexion avec ces machines vers 19h20-19h30 environ, alors que les autres machines surveillées semblent redémarrer environ une heure plus tard, vers 20h20-20h30.
La fenêtre de maintenance que je m’attends à voir appliquée commence à 20h00 et se termine à 22h00, et se répète chaque jeudi.
J’essaie de comprendre pourquoi ces machines installent leurs mises à jour une heure trop tôt. Je sais que les fenêtres de maintenance multiples sont « unifiées » ou fusionnées, donc je soupçonne qu’il y a une autre fenêtre de maintenance qui s’applique également à ces clients.
Ces machines se trouvent également dans une DMZ non jointe au domaine, donc je n’exclus pas non plus des problèmes de fuseau horaire ou de décalage d’horloge.
<h2><a name="p-34083-quai-je-essay-pour-rsoudre-le-problme-2" class="anchor" href="#p-34083-quai-je-essay-pour-rsoudre-le-problme-2" aria-label="Heading link"></a>Qu’ai-je essayé pour résoudre le problème ?</h2>
J’ai pensé que le problème de fuseau horaire / décalage d’horloge était le plus probable, mais les deux machines étaient dans le bon fuseau horaire, avaient une heure synchronisée et avaient correctement géré le changement d’heure d’été du 8 mars.
Mon hypothèse suivante est que nous avions une fenêtre de maintenance erronée ou ancienne qui s’appliquait à une collection dans laquelle se trouvaient ces machines. Cela me semble un peu improbable puisqu’il y a une autre machine qui devrait être dans toutes les mêmes collections et qui redémarre à l’heure correcte de 20h00 environ.
Vérifions que le client redémarre bien quand le système de surveillance le dit !
Si je vérifie un client, <code>systeminfo</code> affiche l’heure de démarrage à 19h22. Le journal des événements semble corroborer cela :
<pre><code class="lang-auto">Log Name: System
Source: USER32
Date: 3/12/2015 7:21:02 PM
Event ID: 1074
Task Category: None
Level: Information
Keywords: Classic
User: SYSTEM
Computer: HOST09
Description:
The process C:\Windows\CCM\CcmExec.exe (HOST09) has initiated the restart of computer HOST09 on behalf of user NT AUTHORITY\SYSTEM for the following reason: No title for this reason could be found
Reason Code: 0x80020001
Shutdown Type: restart
Comment: Your computer will restart at 03/12/2015 07:21:02 PM to complete the installation of applications and software updates.

</code></pre>
A-t-il redémarré à cause des mises à jour Windows de SCCM ?
Si je creuse dans le <code>UpdatesHandler.log</code>, la réponse est un grand « oui » :
<pre><code class="lang-auto">Initiating updates scan for checking applicability. UpdatesHandler 3/12/2015 7:00:00 PM 6472 (0x1948)
Successfully initiated scan. UpdatesHandler 3/12/2015 7:00:00 PM 6472 (0x1948)
Updates scan completion received, result = 0x0. UpdatesHandler 3/12/2015 7:00:00 PM 8396 (0x20CC)
Initiating updates scan for checking applicability. UpdatesHandler 3/12/2015 7:00:02 PM 10160 (0x27B0)
Method (Apply) called from SDM. UpdatesHandler 3/12/2015 7:00:02 PM 8888 (0x22B8)
Starting job with id = {7DD179F1-1B94-4ADB-A5F1-08E9A000709F} UpdatesHandler 3/12/2015 7:00:02 PM 8888 (0x22B8)
Successfully initiated scan. UpdatesHandler 3/12/2015 7:00:02 PM 10160 (0x27B0)
Updates scan completion received, result = 0x0. UpdatesHandler 3/12/2015 7:00:02 PM 8396 (0x20CC)
Initiating Scan. Forced = (0) UpdatesHandler 3/12/2015 7:00:02 PM 8888 (0x22B8)
Successfully initiated scan for job ({7DD179F1-1B94-4ADB-A5F1-08E9A000709F}). UpdatesHandler 3/12/2015 7:00:02 PM 8888 (0x22B8)
Scan completion received for job ({7DD179F1-1B94-4ADB-A5F1-08E9A000709F}). UpdatesHandler 3/12/2015 7:00:02 PM 8396 (0x20CC)
Evaluating status of the updates for the job ({7DD179F1-1B94-4ADB-A5F1-08E9A000709F}). UpdatesHandler 3/12/2015 7:00:02 PM 8396 (0x20CC)
Initiating download for the job ({7DD179F1-1B94-4ADB-A5F1-08E9A000709F}). UpdatesHandler 3/12/2015 7:00:02 PM 8396 (0x20CC)
Bundle update (038c4fc9-664f-45e5-b838-f7263ffc4512) is requesting download from child updates for action (INSTALL) UpdatesHandler 3/12/2015 7:00:02 PM 8396 (0x20CC)

</code></pre>
Le <code>ServiceWindowManager.log</code> montre que cette fenêtre de maintenance a été appliquée à 19h00 :
<pre><code class="lang-auto">Active Service Windows List has 1 windows ServiceWindowManager 3/12/2015 7:28:13 PM 2404 (0x0964)
Service Window with ID = {F51051BF-90E8-4ED7-BA06-F74F9E74A098} having Starttime=03/12/15 19:00:00 ServiceWindowManager 3/12/2015 7:28:13 PM 2404 (0x0964)
Duration is 0 days, 08 hours, 00 mins, 00 secs ServiceWindowManager 3/12/2015 7:28:13 PM 2404 (0x0964)

</code></pre>
OK… D’où vient cette fenêtre de maintenance ?
Un peu de SQL devrait me montrer toutes les fenêtres de maintenance appliquées à un client SCCM particulier :
<pre><code class="lang-auto">select
v_FullCollectionMembership.Name as Computername ,v_Collection.Name as CollectionName,
v_ServiceWindow.Description as "Next Maintanance Window"
from v_ServiceWindow
inner join v_FullCollectionMembership on (v_FullCollectionMembership.CollectionID = v_ServiceWindow.CollectionID)
inner join v_Collection on (v_Collection.CollectionID = v_FullCollectionMembership.CollectionID)
order by Computername

</code></pre>
et j’obtiens les résultats suivants :
<pre><code class="lang-auto">Computername CollectionName Next Maintanance Window
HOST09 Default Maintenance Window Occurs on 9/15/2013 1:00 AM
HOST09 Weekly Maintenance Window - Thursday Occurs every 1 weeks on Thursday effective 11/1/2013 8:00 PM

</code></pre>
Une petite explication s’impose : tous nos clients SCCM appartiennent à une collection à laquelle est assignée une fenêtre de maintenance par défaut qui ne se produit qu’une seule fois et est dans le passé. Cela empêche les changements d’appartenance à la collection et les demandes intempestives de stratégie client de provoquer l’exécution immédiate d’actions par les clients qui les avaient différées. Cependant, puisque les fenêtres de maintenance sont « unifiées », la fenêtre de maintenance hebdomadaire devrait s’appliquer… à 20h00.
Par intuition, j’ai listé toutes les collections auxquelles ce client appartenait, puis j’ai vérifié si elles avaient des fenêtres de maintenance assignées :
<pre><code class="lang-auto">SELECT dbo.v_Collection.Name
FROM dbo.v_FullCollectionMembership INNER JOIN dbo.v_Collection ON dbo.v_FullCollectionMembership.CollectionID = dbo.v_Collection.CollectionID
WHERE (LOWER(dbo.v_FullCollectionMembership.Name) = LOWER('HOST09'))

</code></pre>
Pour faire court : elles n’en ont pas.
<h2><a name="p-34083-quels-rsultats-attendiez-vous-3" class="anchor" href="#p-34083-quels-rsultats-attendiez-vous-3" aria-label="Heading link"></a>Quels résultats attendiez-vous ?</h2>
Je m’attendais vraiment à voir une collection ayant une fenêtre de maintenance commençant à 19h00, et à moins que mon SQL soit erroné et que je l’aie ratée, ce n’est apparemment pas ce qui se passe ici.
Le fait que ce soit une heure trop tôt m’incline aussi fortement à penser que cela pourrait être un problème de fuseau horaire ou de décalage d’horloge, mais cela semble également conforme aux attentes.
Je pense toujours que mes deux hypothèses sont valables et n’ont pas été réfutées, mais je ne sais pas comment recueillir plus d’informations pour trancher. Avez-vous des idées sur la façon dont je devrais procéder pour le dépannage ?
Y a-t-il autre chose que je devrais envisager ? Quelles autres causes pourraient expliquer cela ?
<h2><a name="p-34083-modification-4" class="anchor" href="#p-34083-modification-4" aria-label="Heading link"></a>MODIFICATION :</h2>
J’ai vérifié le groupe de mises à jour logicielles pour les mises à jour de ce mois et il y a une date limite fixée au 10/03/15 à 20h53 mais le comportement de la date limite pour les activités à effectuer en dehors de la fenêtre de maintenance est désactivé à la fois pour l’installation des mises à jour logicielles et le redémarrage du système.
Quant à l’heure actuelle de la machine, elle semble vraiment correcte, mais je vérifie simplement la date et l’heure dans le Panneau de configuration :
<hr>
Source : <a href="http://xymon.sourceforge.net/" rel="noopener nofollow ugc">Server Fault</a>.)

ayi_2

Comme pour la plupart des choses dans System Center Configuration Manager, je suis sûr qu’il y a des raisons parfaitement logiques pour lesquelles les choses sont ainsi, mais en tant que modeste technicien, je suis aussi sûr que je ne comprendrai jamais pourquoi.
J’ai vérifié en utilisant Policy Spy du <a href="http://www.microsoft.com/en-us/download/details.aspx?id=36213">System Center 2012 R2 Configuration Manager Toolkit</a> et j’ai de nouveau confirmé que, oui, j’obtiens les deux fenêtres de maintenance que je m’attendais à trouver, sauf que <code>F51051BF</code> commence une heure plus tôt que prévu :
Si je corrèle cette liste avec toutes les fenêtres de maintenance disponibles, je trouve les ServiceWindowID des fenêtres de maintenance exactes que je m’attendais à voir, et bien que ce soit coupé dans la capture d’écran, <code>F51051BF</code> commence bien à 20h00 :
<pre><code class="lang-auto">SELECT * FROM v_ServiceWindow
ORDER BY ServiceWindowID

</code></pre>
Qu’en est-il d’une machine qui a les mêmes fenêtres de maintenance et qui fonctionne comme prévu (c’est-à-dire que la fenêtre de maintenance commence à 20h00) :
<pre><code class="lang-auto">Biggest Active Service Window has ID = {F51051BF-90E8-4ED7-BA06-F74F9E74A098} having Starttime=3/5/2015 7:00:00 PM ServiceWindowManager 3/5/2015 10:00:00 PM 68400 (0x10B30)

</code></pre>
Attendez, QUOI ? Cette ligne provient du ServiceWindowManager.log d’un autre client et celui-ci croyait certainement que 19h00 était l’heure appropriée pour commencer. J’en ai vérifié quelques autres. Devinez quoi. Pas une seule mention de <code>F51051BF-90E8-4ED7-BA06-F74F9E74A098</code> commençant à 20h00… mais si je regarde ce qui est listé dans la base de données ET dans la console Configuration Manager, la fenêtre de maintenance du jeudi soir est indiquée comme commençant à 20h00.
<h2><a name="p-34084-mince-alors-ce-nest-pas-une-fentre-de-maintenance-mystrieuse-cest-une-fentre-de-maintenance-masque-1" class="anchor" href="#p-34084-mince-alors-ce-nest-pas-une-fentre-de-maintenance-mystrieuse-cest-une-fentre-de-maintenance-masque-1" aria-label="Heading link"></a>Mince alors ! Ce n’est pas une fenêtre de maintenance mystérieuse ! C’est une fenêtre de maintenance masquée !</h2>
Il semble que pour une raison quelconque, <code>F51051BF</code> soit configurée pour commencer à 20h00. La console Configuration Manager le rapporte ainsi que la base de données, mais si je regarde une poignée de clients, certains indiquent 19h00 et d’autres 20h00.
Deux hypothèses hasardeuses : 1) Nous avons d’anciennes stratégies machine qui traînent d’un site ConfigMgr 2007 précédemment implémenté. ou 2) La stratégie de la fenêtre de maintenance a été modifiée de 19h00 à 20h00 à un moment donné et toutes les machines n’ont pas reçu l’information. Bref. Je ne sais pas vraiment ce que je fais ici.
<h2><a name="p-34084-rsolution-2" class="anchor" href="#p-34084-rsolution-2" aria-label="Heading link"></a>Résolution</h2>
J’ai créé une nouvelle fenêtre de maintenance pour remplacer <code>F51051BF</code> et l’ai assignée à la collection appropriée. J’ai attendu une heure ou deux que les clients effectuent leurs récupérations de stratégie et devinez quoi :
<pre><code class="lang-auto">Service Window with ID = {D047CD9F-25E4-4EDC-95E3-44E971E234FA} having Starttime=3/19/2015 8:00:00 PM ServiceWindowManager 3/16/2015 12:13:41 PM 15500 (0x3C8C)

</code></pre>
Mystère résolu ? Pas vraiment. Problème résolu ? Plus ou moins… étrange, non ?