1 25/10/2026 7 min

Quando in SCCM compare 0X87D20417, il problema raramente è “SCCM generico”: quasi sempre il punto debole sta nella deployment rule, cioè nel modo in cui il client decide se un’applicazione è installata, se può essere scaricata o se deve partire l’azione prevista. In pratica, il client non riesce a far combaciare ciò che vede sul dispositivo con la regola definita nella console.

La prima cosa da chiarire è lo stato atteso rispetto a quello osservato: ti aspetti che la deployment rule riconosca correttamente la macchina come idonea e che l’app venga rilevata o installata; invece il client resta fermo con il codice 0X87D20417, spesso senza un messaggio abbastanza esplicito da guidare subito alla causa. Per questo conviene ragionare per livelli: client, content, detection, dipendenze.

Diagnosi probabile

La causa più frequente è una detection rule incoerente: la regola cerca un file, una chiave di registro, una versione prodotto o un MSI ProductCode che non corrisponde più allo stato reale del dispositivo. In seconda battuta, il problema può essere una deployment rule con dipendenze o supersedence configurate male, oppure un client SCCM non allineato con policy e contenuti aggiornati.

Un’ipotesi meno comune ma da non ignorare è il problema di content distribution: il client punta a un DP che non risponde bene, ha contenuto incompleto o una boundary group non corretta. In quel caso il codice che vedi come errore applicativo è solo il riflesso di un problema a monte nella catena di distribuzione.

Ordine pratico delle ipotesi: 1) detection rule errata, 2) dipendenze/supersedence o condizioni di deployment sbagliate, 3) contenuto non disponibile o client non aggiornato. Questo ordine è utile perché ti permette di falsificare i casi più probabili in pochi minuti senza toccare subito la console in modo invasivo.

Verifiche immediate

Prima di modificare qualsiasi cosa, verifica il comportamento reale del client. Se hai accesso alla macchina interessata, controlla gli stati di esecuzione e i log locali: il punto non è “guardare un log a caso”, ma capire se il client sta fallendo nel download, nell’installazione o nel riconoscimento della presenza dell’applicazione.

Le verifiche minime che valgono quasi sempre sono queste:

  1. Apri il Software Center e verifica se l’app risulta disponibile, in errore o già installata. Se l’interfaccia mostra stato incoerente rispetto alla realtà della macchina, il sospetto si sposta subito sulla detection rule.

  2. Controlla i log del client, in particolare AppEnforce.log, AppDiscovery.log e CAS.log. Se trovi righe che indicano detection fallita, content non trovato o installazione interrotta, hai già una direzione concreta.

  3. Se l’app dipende da un’altra applicazione o da una versione specifica, verifica la presenza della dipendenza sul client. Una dependency chain sbagliata può far fallire la deployment rule anche quando il pacchetto principale è corretto.

Un controllo rapido lato console è vedere se il deployment è davvero assegnato al collection corretta e se la modalità è Required o Available nel modo previsto. A volte il problema non è il detection method, ma una distribuzione fatta sulla collection sbagliata o con un requisito non compatibile con il dispositivo.

Se vuoi una prova rapida e reversibile, forzare una Machine Policy Retrieval & Evaluation Cycle sul client è spesso il test più utile: non risolve da solo, ma ti dice se il problema è di policy stale o di logica della deployment rule. Se dopo l’aggiornamento policy l’errore resta identico, la causa è più probabilmente nella regola o nel contenuto.

Artefatto verificabile: nei log del client cerca una sequenza coerente con l’azione eseguita. Se la detection è il problema, troverai messaggi che indicano mancato riconoscimento dell’app; se è il content, vedrai riferimenti a download o accesso al DP; se è la policy, il client non aggiorna lo stato come atteso.

Soluzione consigliata passo-passo

La correzione migliore è procedere dal punto più economico da cambiare al più invasivo, senza rifare subito l’intera deployment. In molti casi basta correggere la regola di detection e rilanciare la valutazione sul client.

  1. Rivedi la detection rule. Se usi una chiave di registro, controlla che path, hive e valore siano esattamente quelli presenti sul client. Se usi file/versione, verifica che il percorso sia stabile e che il file non venga creato solo dopo il primo avvio dell’app. Se usi MSI, controlla che il ProductCode non sia cambiato tra release.

  2. Seminifica le condizioni di deployment. Verifica requirement rules, OS architecture, collection targeting e eventuali supersedence. Una regola troppo stretta o una condizione di piattaforma errata può far sembrare “rotto” il deployment quando in realtà il client è semplicemente escluso.

  3. Controlla le dipendenze. Se l’app principale richiede un runtime, un agent o un componente base, assicurati che la dipendenza sia realmente installabile e già presente dove previsto. In alcuni casi il problema non è l’app target ma il prerequisito che non viene risolto.

  4. Valida il content su Distribution Point. Se il pacchetto è stato aggiornato di recente, verifica che sia stato redistribuito e che il DP riporti stato sano. Un contenuto non completamente distribuito può generare comportamenti intermittenti, soprattutto su collection ampie o su boundary group multiple.

  5. Forza una nuova valutazione sul client. Dopo la correzione, esegui il ciclo di policy e rilancia la detection. L’obiettivo è vedere se il client passa da errore a stato coerente senza dover cancellare cache o reinstallare il client SCCM.

Se il problema è nella detection, il fix tipico è modificare la regola in modo che descriva lo stato reale, non quello “ideale”. Per esempio: un file creato dal software solo dopo la prima esecuzione non è un buon indicatore di installazione se il deployment deve rilevare la presenza subito dopo l’installazione. In quel caso è meglio una chiave di registro stabile, un servizio installato o un MSI ProductCode corretto.

Se invece la regola è corretta ma il client non la vede, il sospetto passa al WMI repository, al client SCCM o alla cache. Qui la prudenza conta: prima di fare interventi più pesanti, raccogli evidenza dai log e verifica se altri deployment sullo stesso client funzionano. Se fallisce solo una singola app, la diagnosi si restringe molto.

Blast radius: modificare detection, requirement o supersedence impatta solo il deployment interessato, ma può cambiare lo stato di compliance per un’intera collection. Rollback: conserva uno screenshot o export della regola attuale prima della modifica e ripristina il criterio precedente se il comportamento peggiora.

Controlli finali / rollback

Dopo la correzione, il risultato atteso è semplice: il client deve mostrare lo stato corretto nel Software Center o nella console, i log devono indicare detection riuscita o installazione completata, e il codice 0X87D20417 non deve ripresentarsi sulla stessa macchina nelle stesse condizioni.

Verifiche finali utili:

  • Controlla che AppEnforce.log non riporti più l’errore associato alla deployment rule.

  • Verifica che AppDiscovery.log mostri la detection come positiva, se l’app è già installata.

  • Controlla in console lo stato della deployment su una macchina campione: Success, In Progress o Failed devono corrispondere allo stato reale del client.

  • Se hai toccato la rule di detection, fai un test su almeno un client pulito e uno già “sporco” per capire se la regola funziona in entrambi gli scenari.

Se il fix non regge, torna indietro alla regola precedente e confronta il diff della deployment. Il rollback più sicuro è quasi sempre quello logico: ripristinare detection, requirement o dependency come erano prima della modifica. Evita interventi più aggressivi sul client se non hai ancora dimostrato che il problema nasce lì.

Assunzione operativa: il codice 0X87D20417 viene trattato qui come errore legato alla valutazione della deployment rule sul client SCCM; se nel tuo ambiente il messaggio completo è diverso o è agganciato a un workflow specifico, conviene partire dal log corrispondente e non dal solo codice.

In pratica, il modo più efficiente per chiudere il caso è questo: prima confermi se il client vede davvero l’app come dovrebbe, poi correggi la regola che descrive quello stato, infine verifichi che il comportamento sia stabile su più macchine. È la strada più rapida per evitare di inseguire sintomi e di fare cambi inutili sulla console o sul device.