Lorsqu’une organisation est compose de 3 niveaux hiérarchiques avec un grand nombre de serveur primaire et d’enfant, il n’est pas rare que les packages de mise à jour ainsi que les listes ne soient pas visibles sur les primaires.
Cela bien sur empêche le bon déroulement du déploiement des correctifs et ouvre une faille de sécurité dans l’organisation.
Un article de Michael Wiles (en anglais) traite en détail de ce problème :
- Attention : Microsoft ne soutient pas les résolutions qui passent par une édition de la base de données et sa modification.
Pour déterminer avec précision d’où vient notre problème de synchronisation nous utiliserons le fichier de log ObjReplMgr.log
La première action avant de prendre le risque de toucher à la base de donnée est de créer un fichier appeler <code site>.SHA dans le dossier : <dossier d’installation de SCCM>\inboxes\objmgr.box de votre central.
Attention à ne pas laisser trainer l’extension TXT. Le fichier SHA n’est qu’un fichier texte vide qui servira à SCCM pour relancer la synchronisation.
Par exemple : si mon primaire SCCM enfant dispose du code site QSD, je dispose un fichier QSD.SHA dans le répertoire <dossier d’installation de SCCM>\inboxes\objmgr.box
Notez que cela va initier la réplication complète de tous les objets entre le site primaire SCCM Enfant et le serveur Central. La bande passante entre ces deux serveurs sera donc utilisée de manière intensive. Pensez à ne pas effectuer cette opération en heure pleine si vous ne disposez pas d’une bande passante suffisante.
Vous pouvez consulter les détails et l’état d’avancement de la réplication dans le fichier log ObjReplMgr.log.
Lorsque SCCM a terminé sa réplication le fichier <code site>.SHA est supprimé automatiquement. Vous trouverez cette information dans le fichier de log en recherchant l’entrée : “Deleted site attachment file D:\SCCM\inboxes\objmgr.box\<code site>.SHA”
Ensuite SCCM met à jour toutes ses tables et ses entrées liées à ces objets. Cela peut prendre encore plusieurs heures avant que le processus ne soit complet (3-4 heures)
Dans 90% des cas cela devrait suffire à rendre le service et sans toucher à la base de donnée.
Si hélas ce n’est pas le cas voici d’autres solution
Solution N°1
Effectuez les 6 requêtes suivantes sur le site enfant peux résoudre le problème :
- Note : Remplacez CEN avec le code site de votre serveur central.
L’exécution des requêtes ci-dessus purgera les données de mises à jour logicielles sur le serveur primaire enfant.
Attendez ensuite environ 30 minutes, puis redémarrez les services suivant sur le serveur primaire enfant :
- SMS_EXECUTIVE
- SMS_COMPONENT_MANAGER
Ensuite procéder à l’exécution de la méthode de base décrite plus haut.
Solution N°2
Si la solution de base et la solution N°1 n’ont pas suffi pas de panique, suivez pas à pas la solution N°2
Sur le serveur primaire enfant, supprimer tous les fichiers à l’intérieur de <dossier d’installation de SCCM>\inboxes\objmgr.box, <dossier d’installation de SCCM>\inboxes\objmgr.box\INCOMING, <dossier d’installation de SCCM>\inboxes\objmgr.box\INCOMING\retry et <dossier d’installation de SCCM>\inboxes\objmgr.box\INCOMING\retry\Bad
Exécuter la requête SQL ci-dessous pour nettoyer les informations de mises à jour du site primaire enfant.
Arrêter le service SMS_EXECUTIVE et SMS_COMPONENT_MANAGER du serveur primaire enfant.
Dans le dossier <dossier d’installation de SCCM>\Bin\I386 renommer la DLL objreplmgr.dll en objreplmgr.dll.old
Relancer SMS_COMPONENT_MANAGER, SMS_EXECUTIVE se relancera automatiquement.
Créer le fichier SHA sur le central comme dans la méthode de base.
Attendre sa disparition plus 2 à 3 heures.
Arrêter à nouveau le service SMS_EXECUTIVE et SMS_COMPONENT_MANAGER du serveur primaire enfant.
Dans le dossier <dossier d’installation de SCCM>\Bin\I386 renommer la DLL objreplmgr.dll.old en objreplmgr.dll
Relancer SMS_COMPONENT_MANAGER, SMS_EXECUTIVE se relancera automatiquement.
Vous devriez retrouver vos listes synchronisée sur le serveur primaire enfant.