Les mises à jour automatiques de vos Teams Phones et Teams Rooms on Android ne s’installent pas, alors que les mises à jour manuelles passent ? Voici un guide opérationnel, orienté TAC, anneaux, fenêtres de maintenance et réseau.
Sommaire
Mises à jour automatiques des Teams Phones et Teams Rooms on Android qui ne s’appliquent pas
Vue d’ensemble de la question
Des appareils restent figés sur une ancienne version (ex. 202401…) alors qu’une version plus récente (ex. 202406…) est disponible. Ils sont affectés à la phase d’auto‑mise à jour General (default) — généralement déployée progressivement ~30 jours après la disponibilité — mais seules des mises à jour manuelles depuis le Teams Admin Center (TAC) aboutissent. Des redémarrages ont été effectués, et une fenêtre de maintenance est configurée sans effet.
Réponse & Solution
Constat principal : si l’update manuelle fonctionne, la pile logicielle/firmware n’est pas en cause. Le blocage réside quasi toujours dans la planification (anneau, politique, fenêtre) et/ou les pré‑requis (connectivité, énergie, état de l’appareil).
Ci‑dessous, un plan d’action concret et priorisé. Appliquez‑le à 1–2 appareils pilotes, puis généralisez.
- Vérifier la politique d’update côté TAC
- Confirmez que chaque appareil reçoit une seule politique d’update et qu’il est bien dans la phase General (default) (aucune appartenance simultanée à un anneau pilote/early).
- Assurez‑vous qu’aucune version n’est « épinglée » (pin) sur l’appareil, son groupe ou sa politique.
- En cas de doute, dupliquez la politique et créez une politique de test affectée à 1–2 appareils pilotes ; enregistrez, forcez une synchronisation depuis le TAC.
- Revoir la fenêtre de maintenance
- Contrôlez la zone horaire utilisée par l’appareil et celle paramétrée dans la politique.
- Vérifiez que l’appareil reste réveillé, sous tension, connecté, et hors réunion/appel pendant toute la fenêtre.
- Pour lever l’ambiguïté, programmez une fenêtre courte imminente (ex. dans les 1–2 heures) sur un pilote.
- Contrôler la connectivité requise
- Sortant stable en HTTP/HTTPS (80/443), sans interception TLS rompant le téléchargement.
- Pas de proxy/censure vers les CDN Microsoft et/ou serveurs OEM hébergeant les paquets (applications, firmware, pilotes).
- Latence et pertes raisonnables ; pas de coupure Wi‑Fi durant l’apply.
- Écarter les « gatings »/pauses de déploiement
- Les déploiements par anneaux peuvent être gelés temporairement ; déplacez 1 appareil vers un anneau pilote/early pour vérifier qu’une offre automatique existe réellement.
- Aligner la version de base
- Certaines filières exigent un saut intermédiaire (ex. 202401 → 202403 → 202406). Mettez à jour manuellement 1–2 appareils vers la version pivot, puis laissez l’auto‑update reprendre.
- Redéployer proprement (ré‑association)
- Dissociez l’appareil de son groupe/politique, redémarrez, ré‑associez‑le, puis forcez une synchronisation depuis le TAC. Attendez la fenêtre suivante.
Pourquoi l’automatique échoue alors que le manuel réussit ?
L’update manuelle déclenche immédiatement le téléchargement et l’application, en ignorant certaines contraintes de calendrier. L’update automatique, elle, respecte strictement :
- le ring (anneau de déploiement) ;
- la fenêtre de maintenance ;
- les pré‑requis d’état (inactivité, alimentation, connectivité, stockage) ;
- les pauses/gatings éventuels imposés par Microsoft ou l’OEM ;
- des dépendances de version (saut intermédiaire requis).
| Condition | Automatique | Manuelle (TAC) | Impact si non respectée |
|---|---|---|---|
| Fenêtre de maintenance | Obligatoire | Contournée partiellement | Aucune tentative pendant les heures non autorisées |
| Anneau/ring éligible | Obligatoire | Non requis | Version non proposée en « General » → attente indéfinie |
| Appareil inactif (hors appel) | Obligatoire | Vérifié mais plus permissif | Planification glisse chaque jour |
| Alimentation & batterie | Obligatoire | Obligatoire | Apply refusé, rollback ou re‑tentative |
| Connectivité CDN/OEM | Obligatoire | Obligatoire | Téléchargement partiel → apply jamais déclenché |
| Version pivot | Obligatoire si requise | Forçable | Mise à jour ignorée car pré‑requis non atteint |
Procédures détaillées dans le Teams Admin Center (TAC)
Contrôler l’affectation de politique et l’anneau
- Ouvrez l’appareil dans le TAC → onglet Update/Software.
- Vérifiez le ring effectif (ex. General (default), Pilot, Early).
- Repérez toute mention d’une version épinglée (pinned) au niveau de l’appareil, du groupe ou de la politique.
- En cas d’incohérence, retirez l’appareil des groupes concurrents et affectez une politique unique.
Forcer une resynchronisation côté service
- Depuis la page de l’appareil, lancez Sync et attendez le passage de l’état à Up to date/En ligne.
- Exécutez un Reboot planifié hors réunion (pour valider l’éveil durant la fenêtre).
Reconfigurer et tester la fenêtre de maintenance
- Dans la politique, définissez une fenêtre courte (ex. 02:00–03:00 heure locale de l’appareil).
- Vérifiez la time zone de l’appareil (paramètres système/OEM) et son horloge (Network time recommandé).
- Assurez‑vous que l’appareil ne se met pas en veille durant la fenêtre (désactiver l’extinction d’écran temporairement si nécessaire).
Piloter un appareil dans un anneau précoce
Créez une politique Pilot ou Early reprenant exactement la même fenêtre de maintenance, assignez‑la à 1 appareil, sync → attendre la fenêtre. Si la version se propose et s’applique, le problème venait du ring General (gating ou propagation retardée).
Lecture et analyse des journaux (logs)
Où récupérer les logs
- Teams Admin Center (TAC) : depuis la page de l’appareil → Download logs.
- Depuis l’appareil (si accessible) : menu Export/Collect logs dans les réglages (fabricant).
Que chercher dans les logs
- Mots‑clés :
update,firmware,download,apply,error,failure,timeout,scheduler,maintenance window,pinned,policy. - Événements réseau : codes HTTP (403/404/5xx), erreurs TLS/CRT, DNS (NXDOMAIN, timeout).
- Ressources : messages espace disque, alimentation (sur secteur vs batterie), état d’inactivité.
Exemples de fragments de logs utiles
[2024-06-12 02:15:09] UpdateScheduler INFO Window check: local=02:15; window=02:00-03:00; eligible=true
[2024-06-12 02:15:11] UpdateService INFO Offer found: version=202406.1 ring=General
[2024-06-12 02:15:12] PackageDownloader WARN GET https://.../package.zip -> HTTP 403 (forbidden)
[2024-06-12 02:15:12] TLS ERROR Handshake failed: unknown_ca
[2024-06-12 02:18:47] UpdateService WARN Download incomplete (67%); retry scheduled in 3600s
[2024-06-12 03:00:00] UpdateScheduler INFO Window ended; deferring apply
[2024-06-13 02:03:22] PolicyManager INFO Device pinned to 202401.7 by group 'MeetingRooms-Paris'
[2024-06-13 02:03:25] UpdateService INFO Skipping offer due to pin constraint
Outils d’analyse
- Il n’existe pas d’outil officiel intitulé « Microsoft Teams Log Analyzer » à télécharger pour ce scénario.
- Utilisez des outils génériques : Log Parser, éditeurs avec recherche multi‑fichiers, tableur/BI (colonnes timestamp, niveau, source, message).
Checklist de diagnostic rapide
| Contrôle | Comment vérifier | OK si | Actions si KO |
|---|---|---|---|
| Etat dans le TAC | Page appareil → statut | En ligne, dernier check < 5 min | Forcer Sync, vérifier réseau/alimentation |
| Politique unique | Groupes & étiquettes | Un seul ring/policy visible | Retirer doublons, recréer une policy de test |
| Version non « pinned » | Section Update/Software | Aucune version épinglée | Dé‑épingler au niveau appareil/groupe |
| Fenêtre de maintenance | Policy & time zone | Heures cohérentes avec l’heure locale | Modifier fenêtre, tester dans 1–2 h |
| Inactivité | Logs/salle non utilisée | Hors réunion/appel durant la fenêtre | Bloquer la salle, réduire veille |
| Connectivité | Proxy/pare‑feu/CDN | HTTP/HTTPS OK, pas d’inspection TLS | Autoriser domaines CDN/OEM, bypass inspection |
| Espace disque | Logs OEM ou statut stockage | > 1 Go libre (recommandé) | Nettoyage cache/logs, redémarrer |
| Version pivot | Release notes internes | Sur une build minimale requise | Mettre à jour manuellement 1–2 appareils |
Réseau : exigences et symptômes typiques
Les mises à jour automatiques sont sensibles aux politiques de sécurité. Voici les points à contrôler.
Exigences réseau (indicatives)
- Sortant TCP 80/443 vers les domaines Microsoft (services Teams/Office/CDN) et les hôtes OEM (fabricant du téléphone/room).
- Aucune interception TLS sur les flux de mise à jour (les certificats de substitution provoquent des erreurs unknown_ca).
- Autoriser les téléchargements volumineux (jusqu’à plusieurs centaines de Mo) sans coupure ni proxy « content‑filter » trop agressif.
Symptômes → Pistes
- 403/407 : authentification proxy requise ou refus.
- 404 : URL de package non atteignable (filtrage/miroir OEM indisponible).
- 5xx récurrents : saturation/timeout proxy ou CDN temporaire (réessayer dans un anneau pilote).
- Téléchargement à 60–80% puis stop : coupure Wi‑Fi ou veille de l’appareil.
Fenêtres de maintenance : bonnes pratiques
- Choisissez une plage de 60–120 minutes en heures creuses locales.
- Désactivez la mise en veille pendant la fenêtre (temporairement) et branchez l’appareil sur secteur.
- Évitez les fenêtres « glissantes » (ex. 00:00–00:15) trop courtes pour un téléchargement complet.
- Bloquez la salle (pas de réunion) durant la plage pour garantir l’inactivité.
Exemple de planification robuste (salles très utilisées)
- Fenêtre A : 02:00–03:00 (nuit impaire)
- Fenêtre B : 04:00–05:00 (nuit paire)
- Basculer automatiquement les pilotes entre A et B pour traverser d’éventuels gatings.
Stratégie de pilote & validation
- Sélectionnez 2–3 appareils représentatifs (modèles, sites, réseaux différents).
- Assignez‑les à un anneau pilote avec une fenêtre proche (dans les 24 h).
- Surveillez les logs et l’état TAC (download → apply → reboot).
- Si OK en pilote mais KO en General : patientez le temps du déploiement global, ou étendez le pilote.
- Si KO en pilote : investiguez réseau, pinned, pré‑requis.
Cas particuliers à connaître
- Appareils gérés par un MDM tiers (Intune/OEM) : des politiques peuvent restreindre le Wi‑Fi ou les mises à jour système. Vérifiez qu’aucun Compliance Policy ne bloque le trafic durant la fenêtre.
- Stockage quasi plein : le téléchargement échoue sans message clair. Libérez de l’espace (logs, cache, enregistrements).
- Heure système fausse : avec 5–10 minutes d’écart, la fenêtre peut être mal évaluée et TLS échouer (certificats non valides). Utilisez le network time.
- Wake locks côté OEM : désactivez temporairement la mise en veille agressive pendant le patch.
Modèle d’arbre de décision (prêt à l’emploi)
- Manuel OK ? Oui → aller à 2. Non → incident matériel ou image → escalade OEM.
- Anneau = General, pas de pin ? Oui → 3. Non → corriger politique/pin.
- Fenêtre correcte (TZ, durée, appareil éveillé) ? Oui → 4. Non → corriger & retester.
- Connectivité CDN/OEM (80/443, pas d’inspection) OK ? Oui → 5. Non → corriger pare‑feu/proxy.
- Version pivot requise ? Non → 6. Oui → mise à jour manuelle vers pivot, puis retour auto.
- Gating possible ? Oui → déplacer 1 appareil en Pilot/Early. Non → 7.
- Ré‑association (retirer groupe, reboot, ré‑associer) puis sync → attendre la fenêtre.
Exemples d’erreurs fréquentes & remèdes
| Symptôme | Cause probable | Correctif |
|---|---|---|
| « No eligible maintenance window » | Time zone ou plage incorrecte | Aligner TZ appareil/policy, fenêtre ≥ 60 min |
| « Pinned to version » | Version épinglée par groupe | Dé‑épingler dans la policy/groupe, resync |
| Téléchargement reste à 0% | Proxy bloque CDN | Autoriser domaines CDN/OEM, pas d’auth proxy |
| Échec vers 70–80% | Veille/écran/wi‑fi coupés | Désactiver veille pendant fenêtre, brancher secteur |
| Erreur TLS unknown_ca | Inspection SSL | Bypass inspection pour les flux de mise à jour |
Procédure de « redéploiement propre » (pas à pas)
- Dans le TAC, retirer l’appareil de son groupe d’update.
- Redémarrer l’appareil (depuis le TAC ou physiquement).
- Ré‑associer l’appareil à un groupe/politique pilote (fenêtre proche).
- Sync immédiat et vérification du statut en ligne.
- Attendre la fenêtre ; contrôler logs ; si OK, replacer en General après la réussite.
Bonnes pratiques d’exploitation continue
- Segmentez vos salles/téléphones en 3 anneaux minimum : Pilot (5–10%), Early (20–30%), General (60–75%).
- Documentez la version pivot minimale et les incompatibilités connues.
- Surveillez 48–72 h après chaque release : taux de réussite, durée moyenne, erreurs réseau.
- Conservez 1–2 appareils « lab » sur un sous‑réseau sans proxy pour trancher réseau vs politique.
Compléments utiles (check‑list rapide)
- ✅ Appareil en ligne dans le TAC, pas de duplicat d’affectations (tags/groupes/politiques).
- ✅ Heure/zone horaire correctes sur l’appareil (la planification dépend de l’heure locale).
- ✅ Aucune politique tierce (Intune/MDM/OEM) ne bloque les mises à jour ou ne restreint le Wi‑Fi uniquement.
- ✅ Stockage suffisant pour télécharger/appliquer le package.
- ✅ Tester un appareil pilote : anneau différent + fenêtre de maintenance proche.
- ✅ Après succès manuel, surveiller si l’auto‑update reprend un cycle normal au patch suivant.
Résultat attendu
En garantissant un anneau pertinent, une fenêtre de maintenance valide et la connectivité adéquate (sans inspection TLS intrusive), vos Teams Phones et Teams Rooms on Android doivent reprendre un cycle de mises à jour automatiques dans le délai prévu. Les logs permettent d’identifier quelle étape échoue (découverte de l’offre, téléchargement, application, redémarrage planifié) et d’ajuster précisément la politique, la fenêtre ou le réseau.
FAQ (express)
Q : Faut‑il laisser l’appareil allumé toute la nuit ?
R : Oui pendant la fenêtre, idéalement sur secteur, écran éveillé (pas de veille agressive).
Q : Une mise à jour manuelle réussie garantit‑elle la suivante en automatique ?
R : Pas forcément. Elle valide l’intégrité du package, mais pas la politique/fenêtre/réseau. Surveillez au patch suivant.
Q : Combien de temps un déploiement « General » peut‑il prendre ?
R : Les vagues sont progressives. Si un anneau pilote reçoit l’update mais pas « General », suspectez un gating temporaire et maintenez le pilotage.
Modèle de message d’incident (à copier)
Objet: Auto-update KO – Teams [Phone/Room Android] – [Site/Modèle]
Symptômes: Appareil bloqué en 202401.x, General ring, fenêtre 02:00–03:00
Vérifs faites: Pas de pin, sync OK, manuel OK, logs HTTP 403 sur CDN
Actions demandées:
- Réseau: Bypass inspection TLS pour domaines updates/CDN
- Exploit.: Étendre anneau Pilot à 10% pour validation
- Salle: Bloquer créneaux 02:00–03:00 pendant 3 nuits
Résumé exécutable
- Un seul ring, aucun pin, fenêtre ≥ 60 min, TZ alignée.
- Pas d’inspection TLS, HTTP/HTTPS libres vers Microsoft/OEM, appareil sur secteur.
- Piloter 1–2 appareils en Early/Pilot pour lever tout doute de gating.
- Version pivot : faire 1 saut manuel si requis, puis revenir en auto.
- Ré‑associer l’appareil si l’état TAC demeure incohérent.