Automatisation et worker

PatchFactory continue de travailler lorsque l’interface cliente est fermée.

Tâche planifiée

L’installation crée la tâche PatchFactory\Client Automation. Elle démarre PatchFactory-Worker.exe sous le compte SYSTEM.

La tâche est déclenchée au démarrage de Windows puis toutes les heures. Le worker vérifie l’échéance enregistrée, exécute le cycle lorsqu’il est dû puis se ferme. L’état En cours ne doit donc apparaître que pendant un traitement réel. Si la tâche disparaît, le worker tente de la recréer avant de quitter.

Cycle automatique

À chaque cycle, le worker :

1. renouvelle son accès avec la licence active ;
2. synchronise le catalogue et son plan d’exécution versionné par le service central ;
3. compare la version et la révision d’artefact attendues avec les publications locales ;
4. télécharge les artefacts autorisés ;
5. publie une nouvelle version ou actualise le contenu existant selon le plan ;
6. entretient les bundles OSD gérés ;
7. envoie la synthèse quotidienne Teams ou SMTP à l’heure configurée ;
8. enregistre chaque résultat dans le journal opérationnel.

Une reconstruction serveur produit une nouvelle révision r2, r3, etc. Même lorsque la version éditeur ne change pas, le worker actualise alors le contenu MECM ou Intune en conservant l’identité de l’application et ses affectations. La révision n’est mémorisée comme appliquée qu’après une publication réussie ; un échec sera donc retenté au cycle suivant.

Lors de la première utilisation de ce suivi, PatchFactory adopte sans republication une application dont la version distante et l’artefact local vérifié correspondent déjà au plan. En l’absence de cette preuve locale, il préfère une actualisation contrôlée afin de ne jamais déclarer une révision appliquée à tort.

Le plan expose aussi la version minimale du client capable de l’exécuter. Une incompatibilité bloque proprement la publication et demande une mise à niveau du client, au lieu d’interpréter une nouvelle politique avec un ancien moteur.

La planification des notifications utilise toujours l’heure de Paris (Europe/Paris) et ne dépend pas de l’ouverture de l’interface. Les secrets de connexion sont protégés par DPAPI à l’échelle de la machine afin que le worker exécuté sous SYSTEM puisse les utiliser sans les exposer en clair.

Mise à jour MECM et séquences de tâches

PatchFactory conserve le même objet application MECM et le même CI_ID lors d’une mise à jour. Il actualise son contenu, sa version, sa détection et ses métadonnées sans casser les références existantes dans les séquences de tâches OSD.

Avant l’actualisation, la version publiée est archivée sans déploiement. Le service central conserve la version courante et les deux versions précédentes de chaque artefact afin que le client puisse restaurer rapidement la version antérieure.

Restaurer une version MECM

Dans le catalogue MECM, sélectionnez une seule application puis utilisez Restaurer la version MECM précédente dans le menu contextuel. PatchFactory :

1. télécharge et vérifie l’artefact précédent conservé par le service central ;
2. republie cette version dans le même objet MECM avec une détection exacte ;
3. protège localement le package utilisé pour le rollback ;
4. suspend les mises à jour automatiques de cette application.

Le badge Rollback épinglé reste affiché tant que la version restaurée est maintenue. Utilisez Reprendre les mises à jour automatiques pour republier la version courante puis retirer le verrou local. Cette reprise est volontaire : un cycle automatique ne doit jamais annuler silencieusement un rollback décidé par l’administrateur.

Vérifier son fonctionnement

Dans PowerShell administrateur :

Get-ScheduledTask -TaskPath '\PatchFactory\' | Get-ScheduledTaskInfo
Get-Content 'C:\ProgramData\PatchFactory\Client\Data\State\client-automation-schedule.json'

Dans PatchFactory, consultez Activité et Notifications. Les opérations nocturnes restent historisées avec l’application, la version, la plateforme et le résultat.

Comportement en cas d’erreur

Une application en échec n’arrête pas le cycle complet. Le worker journalise l’erreur, poursuit les autres applications puis retentera selon la prochaine cadence ou lors d’une action manuelle. Une plateforme activée mais incomplète est signalée comme bloquée ; pour MECM, le code de site, le SMS Provider et la racine de contenu sont obligatoires avant toute publication automatique.

La suppression volontaire d’une application publiée crée une suspension locale pour la plateforme concernée. Le worker ne la recrée pas au cycle suivant ; une nouvelle publication manuelle lève automatiquement cette suspension. Les publications et suppressions MECM sont également sérialisées afin d’éviter les collisions de verrou du SMS Provider.

Une licence exclusivement BIOS & Drivers Factory ne déclenche pas les cycles Apps ni l’entretien des bundles applicatifs. Le catalogue matériel reste synchronisé automatiquement par PatchFactory Server ; la préparation et l’actualisation des profils MECM/OSD sont explicites dans la première version de BIOS & Drivers Factory.