Installare Google Drive con Intune tramite Enterprise App Catalog

Quando ha senso passare da Intune Enterprise App Catalog

Per distribuire Google Drive su Windows con Intune, l’Enterprise App Catalog è la strada più pulita quando vuoi ridurre manutenzione, evitare pacchetti Win32 costruiti a mano e tenere la gestione centrata su assegnazioni, rilevamento e aggiornamenti. Il punto non è solo “installare l’app”, ma farlo in modo ripetibile, con un ciclo di vita leggibile dal tenant e con un rollback semplice se qualcosa va storto.

Il caso d’uso tipico è questo: devi portare Google Drive for desktop su un parco PC Entra ID joined o Hybrid joined, vuoi che l’installazione avvenga senza intervento utente, e vuoi poter verificare da Intune se il deployment è andato a buon fine. Se hai già un packaging interno per app simili, puoi anche restare su Win32; se invece vuoi una distribuzione standard, l’Enterprise App Catalog ti fa risparmiare tempo e riduce gli errori sui parametri di installazione.

Prerequisiti che conviene controllare prima di toccare il tenant

Prima di partire, verifica tre cose: il device deve essere gestito da Intune, l’utente o il dispositivo devono ricevere l’assegnazione corretta, e il tenant deve avere accesso all’Enterprise App Catalog. In pratica, la parte che fallisce più spesso non è l’installer, ma il targeting o il requisito di piattaforma.

Controlla anche il tipo di sistema operativo. Google Drive for desktop ha senso su Windows 10/11 a 64 bit; se il parco include dispositivi non compatibili, il catalogo può comunque mostrare l’app, ma l’installazione fallirà sul client o verrà esclusa dal targeting. Su un rollout serio, il filtro di assegnazione è più importante del nome dell’app.

Se vuoi una verifica rapida lato endpoint, il minimo sindacale è confermare che il client Intune sia operativo e che l’utente sia correttamente sincronizzato:

dsregcmd /status

Atteso: stato AzureAdJoined o Hybrid AzureADJoined coerente con il modello aziendale, e MDM URL valorizzato. Se questo non c’è, non ha senso inseguire il catalogo: il problema è a monte, sul management channel.

Pubblicazione dell’app dal catalogo: percorso operativo

Nel portale Intune, il percorso pratico è quello dell’aggiunta app dal catalogo aziendale. L’idea è selezionare Google Drive, definire il nome visualizzato, assegnare il gruppo di destinazione e lasciare che il catalogo gestisca il pacchetto fornito dal vendor. Se il tenant mostra più varianti, scegli quella per desktop e non una voce generica o legacy.

1. Apri il portale Intune e vai in Apps.
2. Seleziona Windows e aggiungi una nuova app dal catalogo.
3. Cerca Google Drive e apri la scheda dell’app disponibile nel catalogo enterprise.
4. Verifica nome, publisher, piattaforma supportata e modalità di installazione.
5. Imposta il targeting su un gruppo pilota prima di allargare la distribuzione.

La scelta del gruppo pilota non è una formalità. Se l’app usa un installer con comportamento diverso in base al profilo utente, al primo deploy ti conviene limitarla a una decina di dispositivi rappresentativi: laptop standard, una macchina con profilo nuovo, una con utente già presente, e un endpoint che riceve policy da più assegnazioni. Così capisci subito se il problema è del pacchetto o del contesto del device.

Assegnazione corretta: required, available o uninstall

Per Google Drive in ambito aziendale, la modalità più sensata è Required sui dispositivi o sugli utenti che devono averlo sempre disponibile. Available ha senso solo se vuoi lasciare l’installazione a richiesta dal Company Portal. La voce Uninstall va usata con cautela, perché un targeting sbagliato può rimuovere l’app da macchine che la usano davvero.

Se devi evitare installazioni su device non conformi, usa i filtri di assegnazione o i gruppi dinamici. Per esempio, puoi escludere macchine in laboratorio, endpoint kiosk o sistemi non Windows 11. Questo evita di scoprire troppo tardi che l’app è stata proposta a un parco non omogeneo.

Una regola pratica: se stai distribuendo software che crea un componente residente o che si integra con l’Explorer, non partire subito con l’assegnazione ampia. Prima fai una prova su un gruppo ristretto, poi allarghi. È un rollback naturale: togli il gruppo pilota, correggi la policy, riapplica.

Conferma lato client: dove guardare se l’installazione non parte

Se il deploy non parte, la prima domanda non è “il catalogo funziona?”, ma “il device riceve la policy?”. Su Windows, i log Intune Management Extension sono il primo posto da guardare quando la distribuzione passa da cloud a endpoint.

Il path più utile è questo:

C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log

Se l’installazione è stata correttamente assegnata, dovresti vedere eventi di valutazione della policy, download del contenuto e avvio del setup. Se il log non mostra nulla di nuovo, il problema è di targeting o sincronizzazione. Se mostra download ma non installazione, il problema è nel package o nei prerequisiti del sistema.

Per un controllo rapido degli eventi MDM lato sistema, puoi anche usare il visualizzatore eventi oppure un filtro PowerShell. Un esempio minimale è questo:

Get-WinEvent -LogName 'Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin' -MaxEvents 30 | Select-Object TimeCreated, Id, LevelDisplayName, Message

Atteso: eventi coerenti con ricezione policy e applicazione dell’app. Se trovi errori di enrollment o di applicazione criteri, non insistere con re-install: prima chiudi il problema di gestione, poi riprovi il deployment.

Verifica pratica dopo il deploy di Google Drive

Una volta completata l’installazione, non fermarti al fatto che “l’app compare”. Devi verificare che il processo sia vivo, che il componente di sincronizzazione sia presente e che l’utente riesca ad autenticarsi senza loop o prompt anomali. Il controllo più semplice è osservare il processo e la presenza del binario installato.

Su Windows, puoi controllare rapidamente il processo e la cartella di installazione con comandi standard:

Get-Process | Where-Object { $_.ProcessName -like '*Drive*' }
Get-ChildItem 'C:\Program Files\Google' -ErrorAction SilentlyContinue

Se il processo non è presente ma l’app risulta “installed” in Intune, hai un caso classico di installazione nominale ma non funzionale. In quel punto conviene verificare il log dell’applicazione, la presenza di errori di servizio o la compatibilità con il profilo utente.

Dal lato utente, il criterio di successo non è solo “apre la finestra”, ma “si autentica, sincronizza e non rompe il desktop”. Se Google Drive viene usato per file condivisi o documenti di lavoro, verifica anche che i percorsi sincronizzati siano coerenti e che non ci siano ritardi evidenti nella comparsa delle cartelle.

Gestione degli aggiornamenti: evitare di trattare l’app come statica

Google Drive non va considerato un software “installo una volta e basta”. Gli aggiornamenti contano perché toccano compatibilità, sicurezza e comportamento della sincronizzazione. Se il catalogo gestisce la versione in modo dinamico, devi comunque capire come si comporta il tenant quando cambia il pacchetto upstream.

La verifica periodica deve essere semplice: controlla in Intune lo stato della app, confronta la versione attesa con quella effettiva e tieni una finestra di test prima di una diffusione ampia. Se noti regressioni dopo un update, la mitigazione più rapida è sospendere l’assegnazione sui gruppi non pilota e mantenere solo il ring di test.

Qui il principio è lo stesso di qualsiasi software endpoint: aggiornare in modo controllato, non “subire” l’aggiornamento. Se hai esigenze di compliance, documenta la versione approvata e il gruppo pilota, così puoi sempre risalire a quale build è stata distribuita in una certa data.

Errori tipici e come leggerli senza perdere tempo

Il primo errore tipico è il targeting sbagliato: l’app è assegnata, ma il gruppo non contiene i device giusti. Il secondo è il contesto di installazione: l’app arriva, ma l’utente non ha i permessi o il device non soddisfa i requisiti. Il terzo è il conflitto con altri componenti di sync o con vecchie installazioni residue.

1. Se Intune dice che l’app è assegnata ma il client non la vede, controlla membership del gruppo e tempi di sync.
2. Se il client scarica ma fallisce, cerca il codice di errore nel log IME e nel log dell’installer dell’app.
3. Se l’app parte ma si comporta male, verifica residui di versioni precedenti e conflitti con software simili.

Un dettaglio che spesso viene ignorato: i problemi non arrivano solo dal pacchetto, ma dal profilo utente. Su macchine condivise o con profili sporchi, un’app come Google Drive può ereditare impostazioni vecchie, token scaduti o directory già occupate. In quei casi, il fix non è “reinstallare tutto”, ma pulire il contesto utente in modo mirato e tracciato.

Rollback e blast radius: come tornare indietro senza fare danni

Il rollback più sicuro, se il deployment crea problemi, è togliere l’assegnazione dal gruppo pilota o spostare l’app da Required a non assegnata mentre analizzi il caso. Questo limita il blast radius ai soli endpoint coinvolti e ti evita disinstallazioni automatiche non volute.

Se hai già distribuito l’app su larga scala e devi fermare l’impatto, la priorità è bloccare nuove installazioni prima di inseguire i singoli client. Dopo, puoi valutare se mantenere l’app installata ma disabilitarne l’uso operativo con policy aggiuntive o procedere con un uninstall mirato solo sui gruppi interessati.

Ogni cambio su Intune va trattato come un change controllato: annota gruppo, versione, finestra temporale e risultato. Se qualcosa si rompe, questo è ciò che ti permette di distinguere un difetto dell’installer da un errore di targeting o da un problema ambientale.

Sequenza consigliata in pratica

1. Conferma enrollment e join del dispositivo con dsregcmd /status.
2. Apri Intune e verifica che l’app Google Drive sia presente nel catalogo e assegnata al gruppo corretto.
3. Applica prima un gruppo pilota, non una distribuzione ampia.
4. Controlla sul client il log C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log.
5. Verifica processo, cartella di installazione e autenticazione dell’utente.
6. Solo dopo estendi il deployment ai gruppi di produzione.

Se vuoi una regola semplice da tenere a mente, è questa: il catalogo ti semplifica il packaging, non ti sostituisce la disciplina operativa. La qualità del risultato dipende soprattutto da targeting, osservabilità e rollback, non dal fatto che l’app sia “ufficiale” o già pronta nel catalogo.