1 04/11/2026 8 min

Quando la creazione di una app Edge in SCCM si blocca, il punto non è quasi mai “SCCM non funziona”. Di solito l’errore nasce in uno di questi punti: il pacchetto sorgente non è coerente, il detection method è scritto male, il client non vede i prerequisiti oppure il contenuto non viene distribuito come previsto. Se si parte dal wizard senza una verifica minima, si finisce a cambiare tre cose insieme e non si capisce più quale abbia risolto davvero.

Qui conviene ragionare come in un troubleshooting serio: prima si identifica il layer che sta fallendo, poi si controlla l’evidenza minima, infine si applica la correzione meno invasiva possibile. Nel caso di Edge, il problema tipico è che l’app viene creata “bene” in console ma fallisce in distribuzione o non viene rilevata correttamente sul client. L’obiettivo non è solo farla comparire in SCCM, ma farla installare e rilevare in modo stabile.

Diagnosi probabile

Classificazione: troubleshooting.

Stato atteso: l’app Microsoft Edge viene creata in SCCM senza errori, il contenuto viene distribuito ai Distribution Point, il client scarica il pacchetto, esegue l’installazione e il detection method restituisce “presente”.

Osservato di solito: la creazione dell’app fallisce già nel wizard, oppure la app risulta creata ma l’installazione non parte, fallisce in detection o resta in stato “Unknown/Failed” sul client.

Le ipotesi più probabili, in ordine, sono queste:

  1. Pacchetto sorgente o modello di creazione incoerente. Se si sta usando un installer scaricato male, una versione non adatta o un contenuto estratto in modo incompleto, SCCM può creare l’app ma poi fallire in fase di validazione o di deployment. Come falsificarla in meno di 5 minuti: confronta hash, dimensione e percorso sorgente del file usato nel wizard; se il file cambia tra un tentativo e l’altro o non è leggibile dal server, il problema è lì.
  2. Detection method errato o troppo fragile. È la causa più comune: si controlla una chiave di registro sbagliata, un file path non stabile o una versione che non coincide con quella installata. Come falsificarla: verifica sul client la presenza reale di Edge in App & features o nel registro/file system e confrontala con la regola di detection configurata in SCCM.
  3. Prerequisiti e distribuzione contenuto non allineati. Il client riceve la policy ma non riesce a scaricare il contenuto, oppure manca una dipendenza, un requisito di architettura o una condizione OS. Come falsificarla: controlla lo stato del content su DP e i log del client per capire se il download parte o se viene escluso prima dell’installazione.

Verifiche immediate

Prima di cambiare la definizione dell’app, conviene raccogliere una traccia minima e verificabile. L’idea è capire se il problema è nel contenuto, nella detection o nel client. Se hai accesso al server SCCM e al client di test, questi controlli bastano spesso a stringere il campo in pochi minuti.

  1. Verifica il log del wizard o della console SCCM. Se la creazione fallisce in fase di importazione o di validazione, cerca l’errore preciso nel log della console/admin service o nel messaggio restituito dal wizard. L’evidenza attesa è un errore che nomina esplicitamente il file sorgente, la detection o il contenuto non valido.
  2. Controlla il contenuto sorgente. Il file di installazione deve essere coerente con la versione target e accessibile dal server che crea l’app. Se il pacchetto viene da un percorso locale, da una share o da una cartella temporanea, verifica che il path sia ancora valido e che i permessi siano sufficienti. Se il file è stato aggiornato, rigenera il contenuto e non riusare un vecchio source path.
  3. Controlla il detection method sul client. Dopo una tentata installazione, verifica se Edge esiste davvero nel punto che hai dichiarato nella regola. Se la detection usa una chiave di registro, apri il registro e confronta il valore; se usa un file, verifica che il file esista e corrisponda alla versione attesa.
  4. Controlla i log del client SCCM. I log utili sono quelli dell’Application Management e del Content Transfer. Il segnale giusto è semplice: o il client scarica il contenuto e tenta l’installazione, oppure si ferma prima con un motivo chiaro. Se non c’è nessun tentativo di download, il problema è a monte della distribuzione.

Un controllo rapido che aiuta molto è questo: se l’app viene mostrata come disponibile ma non parte l’installazione, il contenuto o la detection sono i primi sospetti; se invece la creazione fallisce già in console, guarda il pacchetto e il modello di app prima di tutto. In pratica, il punto di caduta ti dice già quale layer guardare.

Soluzione consigliata passo-passo

La soluzione più pulita è ricreare l’app partendo da un sorgente controllato e da una detection semplice, poi testare su un client pilota. Evita di “correggere” più elementi insieme: se cambi installer, detection e requisiti nello stesso giro, non saprai quale modifica ha risolto il problema.

  1. Ricostruisci il sorgente dell’app. Usa un file di installazione noto e stabile, idealmente scaricato di nuovo da una fonte ufficiale o estratto in una cartella dedicata. Se il contenuto arriva da una share, assicurati che il server SCCM abbia accesso in lettura costante. Rollback: conserva la vecchia definizione dell’app senza eliminarla finché la nuova non passa i test.
  2. Semplifica il detection method. Se la regola è complessa, riducila a un controllo univoco e verificabile: una chiave di registro stabile, un file versionato o un prodotto installato. Una detection troppo elegante spesso è quella che rompe la distribuzione. Verifica attesa: dopo l’installazione, la detection deve passare in modo immediato e ripetibile sul client di test.
  3. Controlla i requisiti dell’app. Verifica architettura, versione di Windows, eventuali prerequisiti e condizioni di installazione. Se l’app è destinata a sistemi x64 e il requisito è impostato male, SCCM può escludere il client prima ancora di provare l’installazione. Rollback: annota i requisiti originali prima di modificarli, così puoi ripristinarli se il change non risolve.
  4. Ridistribuisci il contenuto ai Distribution Point. Dopo aver corretto sorgente o detection, aggiorna il contenuto e verifica che lo stato del package sia “Success” sui DP. Se la distribuzione resta in errore, il problema non è più nella app ma nel content distribution path o nei permessi del server.
  5. Testa su un solo client pilota. Forza il machine policy retrieval, lancia il deployment e osserva il comportamento. Se l’installazione parte ma fallisce, il motivo va cercato nel log del client; se non parte proprio, il problema è nella policy, nei requisiti o nella distribuzione del contenuto.

Nel caso specifico di Edge, una buona pratica è evitare detection basate su elementi troppo volatili o su percorsi che cambiano tra release. Meglio una regola semplice, stabile e coerente con il tipo di installazione che stai usando. Se usi un installer enterprise o un metodo ufficiale, allinea la detection a quello che davvero lascia sul sistema dopo l’installazione. Questo riduce i falsi negativi e rende più leggibile il troubleshooting futuro.

Se l’errore riguarda la creazione dell’app e non il deployment, il cambio più utile è spesso quello di rifare la definizione da zero con un source pulito. Non è elegante, ma è molto più veloce che inseguire una configurazione corrotta o un wizard parzialmente salvato. In ambienti SCCM, soprattutto quando si lavora su app standardizzate, una definizione nuova e pulita vale più di una correzione a catena su un oggetto già compromesso.

Controlli finali / rollback

Dopo la correzione, il risultato corretto non è solo “l’app esiste in console”, ma questo insieme di condizioni: il contenuto è distribuito con stato OK sui DP, il client scarica il pacchetto, l’installazione termina con exit code atteso e la detection torna positiva. Se uno di questi punti manca, la correzione è incompleta.

  1. Verifica lo stato del deployment. L’app deve risultare distribuita correttamente e il client deve ricevere la policy. Se il deployment resta in errore, il fix non è ancora valido.
  2. Verifica la detection post-installazione. Sul client, la regola deve passare senza interventi manuali. Se serve toccare a mano file o registro per farla passare, la detection è sbagliata.
  3. Verifica la stabilità dopo un refresh policy. Dopo un nuovo ciclo di policy, il client non deve tentare di reinstallare una app già presente. Se lo fa, hai ancora un problema di detection o di rilevazione del prodotto.
  4. Rollback. Se la nuova definizione non funziona, ripristina la versione precedente dell’app o disattiva temporaneamente il deployment verso i client non pilota. Questo limita il blast radius e ti evita di propagare una configurazione non verificata all’intera collection.

Assunzione: il problema sia su una normale applicazione SCCM per Microsoft Edge, con accesso ai log del server e di un client di test, e senza vincoli particolari di rete o di compliance che impediscano la revisione del package.