Come installare più app in Company Portal con Microsoft Intune

Se devi mostrare più applicazioni in Company Portal con Microsoft Intune, la logica è semplice solo in apparenza: ogni app deve essere confezionata bene, assegnata al gruppo giusto e distribuita con il tipo corretto di disponibilità. Il problema, nella pratica, non è quasi mai “Intune non vede l’app”, ma una combinazione di packaging, targeting, requisiti, detection rule e priorità di assegnazione che lascia l’utente con un catalogo incompleto o incoerente.

Il punto di partenza è questo: Company Portal non è un repository magico, ma la vetrina di ciò che Intune decide di esporre a un utente o a un dispositivo. Se vuoi che più app compaiano nello stesso catalogo, devi allineare tre piani: la piattaforma supportata, il tipo di app e l’assegnazione. Saltarne uno significa finire a fare troubleshooting su sintomi diversi: app che non appaiono, app che appaiono ma non installano, app che si installano ma non risultano disponibili per l’utente.

Come ragionare prima di toccare Intune

La domanda utile non è “come faccio a mettere più app in Company Portal?”, ma “come faccio a rendere più app disponibili nello stesso perimetro senza creare conflitti?”. In Intune la risposta dipende da tre variabili: se l’app è destinata a utenti o dispositivi, se deve essere obbligatoria o facoltativa, e se la detection rule è affidabile. Se una di queste è debole, l’esperienza in portal diventa intermittente.

In ambiente reale conviene pensare per livelli. Le app di base, che devono sempre esserci, si assegnano come Required. Le app aggiuntive, che l’utente può installare da solo, si assegnano come Available for enrolled devices o Available with uninstall, a seconda del caso. Se mischi tutto in Available senza disciplina, ottieni un catalogo pieno ma poco governabile. Se spingi tutto come Required, riduci la libertà ma aumenti il controllo. La scelta va fatta prima, non dopo il primo ticket.

Prerequisiti che evitano metà dei problemi

Prima di pubblicare più app, verifica questi elementi minimi:

• Le app sono supportate sulla stessa piattaforma: Windows, iOS/iPadOS, Android o macOS.
• Le app sono impacchettate nel formato corretto: Win32, MSI, Microsoft Store app, LOB, PowerShell script o PKG dove applicabile.
• Le assegnazioni puntano a gruppi coerenti, senza conflitti tra Included e Excluded.
• Le detection rules sono univoche e non ambigue.
• Il dispositivo ha già completato la registrazione e sincronizza con Intune.

Se uno di questi punti manca, non sei davanti a un problema di Company Portal ma a un problema di delivery. La differenza è importante perché cambia il piano di verifica: prima controlli enrollment e sync, poi assegnazioni, poi packaging.

Pubblicare più app: la sequenza corretta

La sequenza operativa più pulita è questa: prepari ogni app, la assegni al gruppo corretto, verifichi la comparsa in Company Portal e solo dopo passi alla fase di scala. Non conviene caricare dieci app e poi cercare il motivo per cui due non compaiono. Meglio validare con un campione, soprattutto se le app hanno dipendenze o versioni diverse.

1. Carica o crea l’app in Intune admin center.
2. Compila nome, descrizione, publisher e icona in modo coerente. Company Portal mostra anche questi dati, quindi qui si gioca parte dell’usabilità.
3. Definisci la detection rule in modo affidabile.
4. Assegna l’app a un gruppo Azure AD/Entra ID di test.
5. Imposta la disponibilità come Available for enrolled devices se vuoi che compaia nel Company Portal.
6. Sincronizza il device e verifica la presenza dell’app nel catalogo.

Per le app Win32, il packaging conta più del resto. Se l’installer non ha parametri silenziosi corretti o la detection è fragile, il catalogo può mostrare l’app ma l’installazione fallirà. Per le app Microsoft Store, invece, il tema è spesso la compatibilità del tipo di app scelto: oggi il flusso va impostato con attenzione perché la vecchia integrazione Store è diversa dalla nuova esperienza. Non dare per scontato che “Store app” significhi sempre lo stesso meccanismo.

Disponibile, obbligatoria, o entrambe: come far comparire più app senza fare confusione

Company Portal mostra soprattutto le app assegnate come disponibili all’utente o al dispositivo. Le app Required vengono installate senza passaggio dall’utente, quindi possono non essere il focus del portale, anche se fanno parte della compliance del device. Questo è il primo equivoco da chiarire: se un’app non compare nel catalogo, non significa che non sia assegnata; può essere semplicemente Required e quindi gestita in background.

Se il tuo obiettivo è far vedere più app nello stesso Company Portal, la strada più lineare è assegnarle come Available a un gruppo utente dedicato. Un gruppo come IT-Apps-Portal o Users-Software-Optional rende il controllo più leggibile. Evita target troppo larghi all’inizio: un gruppo pilota ti fa capire subito se una delle app ha un problema di detection o di requisito di sistema.

Se invece vuoi distribuire le app a livello dispositivo, verifica che il tipo di app supporti bene quel modello. In ambienti misti, l’assegnazione per utente è spesso più prevedibile per Company Portal, perché il catalogo viene costruito in base all’identità dell’utente autenticato. Il device-based assignment resta utile per app di base o per terminali condivisi, ma non è sempre il miglior modo per ottenere una UX pulita nel portale.

Esempio pratico: tre app nello stesso catalogo

Supponiamo di voler pubblicare 7-Zip, Notepad++ e Microsoft Teams nel Company Portal per un gruppo di test. La logica non è installarle tutte allo stesso modo, ma trattarle secondo il loro ciclo di vita: Teams può essere Required se è un’app core, mentre 7-Zip e Notepad++ possono essere Available per scelta dell’utente.

1. Crei il gruppo Entra ID Users-CompanyPortal-Pilot.
2. Carichi le tre app in Intune con nome e icona corretti.
3. Per 7-Zip e Notepad++ imposti Available for enrolled devices.
4. Per Teams imposti Required se vuoi forzarne l’installazione.
5. Verifichi che il device sia registrato e che l’utente faccia login nel Company Portal con lo stesso account assegnato.
6. Forzi una sincronizzazione dal device e controlli la comparsa delle app disponibili.

Se una delle app non compare, la prima verifica non deve essere “rifaccio il pacchetto”. Prima controlla l’assegnazione e la piattaforma. Poi apri i dettagli dell’app e verifica lo stato di Device install status e User install status. Se l’app risulta assegnata ma non visibile, spesso il problema è nel targeting o nella compatibilità. Se risulta visibile ma non installabile, il problema è quasi sempre nel packaging o nella detection.

Le verifiche che fanno risparmiare tempo

Prima di cambiare configurazione, conviene raccogliere evidenza minima. Senza questa base, si lavora a sensazione e si allunga solo il ciclo di troubleshooting.

1. Dal device Windows verifica la sincronizzazione con Intune: Settings > Accounts > Access work or school > Info > Sync.
2. Controlla i log del client Management Extension, se stai distribuendo Win32: C:\\ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log.
3. Verifica la presenza dell’app in Company Portal dopo il refresh dell’account.
4. Controlla in Intune il pannello dell’app e lo stato di assegnazione.
5. Se serve, usa dsregcmd /status per confermare che il device sia correttamente joinato e registrato.

Un esempio tipico: l’utente vede una sola app su tre. In Intune le tre risultano assegnate, ma solo una è davvero disponibile. A quel punto i casi più frequenti sono due: le altre due sono assegnate a un gruppo diverso, oppure la detection rule fa credere a Intune che l’app sia già installata o non supportata. In entrambi i casi il problema non è Company Portal in sé, ma il modo in cui Intune valuta lo stato dell’app.

Detection rule: il punto che rompe tutto se è fatta male

La detection rule decide se l’app è considerata presente. Se è troppo permissiva, l’app risulta già installata e non appare correttamente come disponibile. Se è troppo restrittiva, Intune tenta installazioni ripetute o mostra stati incoerenti. Per questo, quando pubblichi più app, devi trattare ogni detection come un controllo di integrità, non come un dettaglio secondario.

Per Win32, preferisci indicatori stabili come file/versione, chiavi di registro affidabili o MSI product code quando disponibile. Evita detection basate su percorsi che cambiano con frequenza o su nomi file non univoci. Se due app condividono componenti, separa bene la detection per non creare false positività. È un errore comune quando si impacchettano tool simili della stessa vendor suite.

Un controllo utile è confrontare ciò che Intune pensa dello stato dell’app con ciò che vedi localmente sul device. Se la GUI dice “Installed” ma il file non c’è, la detection è sbagliata. Se il file c’è ma Intune non lo riconosce, la regola non intercetta il criterio giusto. Qui non servono tentativi casuali: serve un confronto tra evidenza locale e log di management.

Quando più app non compaiono: cause ricorrenti

Nelle installazioni reali, le cause ricorrenti sono poche e abbastanza prevedibili:

• Targeting errato: app assegnata a un gruppo diverso da quello dell’utente.
• Tipo di assegnazione sbagliato: app messa come Required quando ci si aspetta che appaia nel portal.
• Detection rule errata: Intune considera l’app già presente o non installabile.
• Compatibilità di piattaforma: app pubblicata su un OS non supportato dal device.
• Sincronizzazione incompleta: il device non ha ancora ricevuto la policy aggiornata.

La parte importante è l’ordine di verifica. Prima guardi assegnazione e piattaforma, poi detection, poi sync. Se parti subito dal pacchetto, rischi di correggere il sintomo invece della causa. È così che si perde mezza giornata su un problema che stava in un gruppo Entra ID sbagliato.

Organizzare il catalogo per l’utente, non per l’amministratore

Company Portal funziona meglio quando il catalogo ha una logica percepibile. Le app devono essere nominate in modo chiaro, con publisher coerente e descrizioni che distinguano le varianti. Se pubblichi tre versioni della stessa suite, l’utente deve capire subito qual è quella giusta. Un nome come Adobe Acrobat Reader - Standard è molto più utile di un generico Acrobat duplicato con versioni diverse.

Lo stesso vale per le icone. Non è un vezzo grafico: l’icona riduce l’errore dell’utente e abbassa i ticket. In un catalogo con molte app, l’identificazione visiva conta quasi quanto il nome. Se un’app ha branding errato o immagine non caricata, il catalogo appare meno curato e l’utente tende a fidarsi meno anche quando la policy è corretta.

Se devi cambiare qualcosa, fallo in modo reversibile

Quando correggi la pubblicazione di più app, il cambiamento minimo e reversibile è quasi sempre il migliore. Prima prova su un gruppo pilota, poi estendi. Se devi modificare l’assegnazione, conserva il gruppo precedente fino alla verifica. Se devi cambiare la detection rule, versiona mentalmente il pacchetto o annota il cambio nel campo notes dell’app, così puoi tornare indietro senza ambiguità.

1. Duplica il gruppo di test o crea un sottoinsieme ristretto di utenti.
2. Applica la nuova assegnazione solo al gruppo pilota.
3. Forza la sincronizzazione del client e verifica il catalogo.
4. Se l’app non compare o installa male, torna alla configurazione precedente senza toccare le altre app.
5. Solo dopo la verifica estendi il targeting al gruppo produttivo.

Il rollback più semplice, in questo scenario, è rimuovere l’assegnazione del gruppo pilota o riportare l’app allo stato precedente. Non serve reinventare il pacchetto se il problema è nel targeting. E non serve allargare il blast radius a tutta l’utenza quando basta un singolo gruppo di prova per isolare il difetto.

Checklist finale per una pubblicazione pulita

Prima di considerare chiuso il lavoro, verifica queste condizioni:

• Ogni app è assegnata al gruppo giusto.
• Le app che devono comparire nel Company Portal sono impostate come Available.
• Le app Required sono documentate come tali, così non le cerchi nel posto sbagliato.
• Le detection rule sono state testate su un device reale.
• Il client ha sincronizzato e il catalogo riflette la policy recente.

Se vuoi un criterio pratico, considera il lavoro finito solo quando un utente del gruppo target vede nel Company Portal esattamente le app previste, può installarle senza errori e gli stati di Intune tornano coerenti. Tutto il resto è rumore operativo.

Assunzione: il target è un ambiente Microsoft Intune con dispositivi Windows e Company Portal già installato e registrato correttamente.