Mise à jour : Il semble que l'application du CU2 avant la mise à jour du SP1 évite ce problème.
Ma première mise à jour d’une infrastructure System Center 2012 Configuration Manager vers le Service Pack 1 du produit a été quelque peu chaotique ! Je conseille d’ailleurs pour le moment de prendre un peu de temps avant de mettre à jour vos infrastructures ConfigMgr 2012 RTM pour voir les premiers retours. Si vous installez une nouvelle hiérarchie, vous pouvez directement utiliser les binaires incluant le Service Pack 1 car vous n’expérimenterez pas les mêmes problèmes.
Voici le scénario :
- Mise à jour d’un site primaire autonome System Center 2012 Configuration Manager RTM sans Cumulative Update (5.00.7711.0000) vers System Center 2012 Configuration Manager Service Pack 1 (5.00.7804.0000)
- Avant mise à jour, vous disposez déjà de plusieurs applications ; on ne parle pas ici de packages. Vos applications se déploient sans aucun problème sur l'ensemble du parc.
- Après mise à jour, vous observez les phénomènes suivants :
- Côté client :
- Les clients n’arrivent plus à déployer d’applications (même si celles-ci sont inclues dans des séquences de tâches).
- Le client bloque sur le téléchargement des sources. Vous pouvez observer dans le fichier de journalisation CAS.log qu’aucun point de distribution (DP) n’est disponible pour cette application.
- Le contenu de l’application est bien déployé sur le point de distribution
- Les groupes de limite et limites sont correctement configurés et le point de distribution est associé à celui-ci.
- Si le déploiement et des points de distribution sont configurés pour autoriser le rabattement (fallback) des clients, vous observez le même blocage.
- Les applications nouvellement créées ne sont pas impactées par ce phénomène.
- Côté point de distribution :
- Côté client :
-
- La distribution du contenu des applications ne fonctionne pas (statut In Progress) pour les applications créées avant mise à jour. Les nouvelles applications (créées après mise à jour) sont distribuables.
- Dans le fichier de journalisation distmgr.log, vous pouvez observer que l’application n’a pas de sources associés et qu’il n’est donc pas nécessaire de la déployer ou mettre à jour.
Le processus de mise à jour semble avoir « cassé » le schéma des applications présentes avant l’opération. Un problème est signalé au travers d’un article dans la base de connaissances Microsoft, mais ne cible que les mises à jour de SCCM 2012 SP1 Beta à SCCM 2012 SP1 RTM. Je ne peux dire si les deux problèmes ont la même cause mais celui auquel j’ai fait face à bien touché une mise à jour SCCM 2012 RTM vers SCCM 2012 SP1 RTM.
Dans la console, on observe que les types de déploiement n’ont pas de Content ID. Pourtant l’application a bien une source valide.
Pour résoudre le problème, il vous suffit d’éditer tous les types de déploiement de vos applications créées avant mise à jour et d’ajouter un commentaire par exemple.
Lors de la validation de la modification vous pourrez observer l’affichage d’un identifiant de contenu (Content ID) là où il n’y en avait pas.
Attention : Ceci engendre la redistribution du contenu sur tous les points de distribution ciblés même si ceux-ci ont déjà les sources localement.