Il grosso del lavoro di un amministratore Workspace non sono i progetti, sono i ticket ricorrenti. Averne in testa la procedura corretta significa chiuderli in minuti invece che in giorni.

Account, password e verifica in due passaggi

Quasi tutto si risolve da Directory > Users, aprendo l’utente e andando alla scheda Security. Da lì si esegue il reset della password con Ask for a password change at the next sign-in, si gestiscono passkey e security keys, si revocano le application-specific password e le connected applications, si aggiorna la recovery information e si usa il reset dei sign-in cookies per disconnettere l’utente da tutti i browser e dispositivi (mossa obbligatoria quando si sospetta una compromissione).

Se l’utente non riesce a superare una verifica d’identità perché è senza campo o senza telefono, la stessa pagina offre Login challenge > Turn off for 10 minutes: una finestra breve, che può richiedere qualche minuto per propagarsi. Per la verifica in due passaggi, la scheda Security mostra lo stato di iscrizione e permette di ottenere i backup verification codes per un utente bloccato, oppure di disattivare la 2SV se non è imposta a livello di organizzazione. I lockout di massa nascono quasi sempre da uno spostamento di utenti non ancora iscritti dentro un’OU con enforcement attivo, o da un cambio di metodo consentito: si prevengono usando un configuration group con enforcement su Off, ricordando che una policy 2SV impostata su una OU figlia ha sempre la precedenza sul gruppo di configurazione. Quando invece manca l’accesso a un solo servizio, prima di indagare oltre verificate licenza assegnata e stato del servizio per la OU dell’utente.

Posta: log, intestazioni, inoltri e filtri

Per un messaggio che «non è arrivato» si parte da Email Log Search, che copre gli ultimi 30 giorni e si interroga per mittente, destinatario, oggetto o message ID. Se il messaggio non compare affatto, non ha mai raggiunto la rete Google: la causa è a monte. Se compare, il delivery status dice dove si è fermato (Delivered, Quarantined, Marked spam, Rejected, Dropped, Bounced, In progress).

Quando il mittente è esterno, chiedete all’utente l’intestazione completa del messaggio e incollatela nel Messageheader del Google Admin Toolbox: restituisce il percorso dei server attraversati, i tempi di ogni salto e l’esito dei controlli di autenticazione SPF, DKIM e DMARC. Un SPF che fallisce indica che il server mittente non è autorizzato dal record del suo dominio; un DKIM non valido segnala firma assente o messaggio alterato in transito; un DMARC in fail nasce dal disallineamento fra il dominio del From e quello autenticato, e con una policy di quarantine o reject spiega da solo la sparizione del messaggio. Se il problema riguarda il vostro dominio in uscita, la correzione sta nei record DNS: SPF, DKIM e DMARC.

Per inoltri, filtri ed etichette la verifica è a due livelli. Lato amministratore si controlla se l’inoltro automatico è consentito per la OU dell’utente; lato utente si guardano le regole di inoltro e i filtri della casella, perché un filtro che archivia o cancella in automatico è la spiegazione più comune di una posta «scomparsa» che in Email Log Search risulta Delivered.

Calendar: sincronizzazione e permessi

Gli eventi che non compaiono su Apple Calendar o Outlook sono un problema di client, non di server: si verifica il metodo di connessione usato, si ricrea l’account sul client e si tiene presente che la sincronizzazione ha una latenza propria e che una cache locale corrotta si risolve rimuovendo e riaggiungendo il calendario. Confrontate sempre con l’interfaccia web: se lì l’evento c’è, il server è sano.

Sui permessi si lavora in Apps > Google Workspace > Calendar > Sharing settings. L’impostazione di dominio è un tetto che il singolo utente non può superare: se External sharing options for primary calendars è su Only free/busy information (hide event details), nessuno all’esterno vedrà i dettagli, per quanto l’utente condivida. È esattamente la causa dei ticket sul free/busy non visibile verso partner esterni, insieme al fatto che i calendari secondari hanno impostazioni proprie, applicate globalmente e non per unità organizzativa.

Drive: condivisione, client desktop e recupero

Gli errori di condivisione si spiegano quasi sempre in Apps > Google Workspace > Drive and Docs > Sharing settings: l’opzione Off blocca ogni condivisione esterna, Allowlisted domains la limita ai domini fidati, e il visitor sharing decide se si può condividere con chi non ha un Account Google. Le restrizioni si applicano alla OU o al gruppo del proprietario del file, e i Drive log events mostrano chi ha condiviso cosa.

Per Drive for Desktop le mosse utili sono: verificare che il client sia consentito per quella OU, disconnettere e riconnettere l’account, controllare proxy, firewall e spazio disco locale, e raccogliere i log del client se il caso va scalato. L’accesso offline richiede che la funzione sia abilitata a livello di dominio, che l’utente l’abbia attivata sul proprio profilo e che il browser sia supportato: sui profili ospite non funziona.

Sul recupero, i file di un utente eliminato si riportano indietro solo entro 20 giorni, ripristinando prima l’account da Directory > Users > More options > Recently deleted users e poi trasferendo la proprietà dei file a una persona attiva. Superata la finestra il dato è perso, motivo per cui i contenuti critici andrebbero su shared drives, dove appartengono al team. Per Gmail e Drive esiste anche il ripristino amministrativo dei dati cancellati di recente da un utente attivo, mentre le esigenze di conformità si coprono con Vault.

Meet: accesso e qualità

Chi non riesce a entrare in una riunione va verificato in ordine: il servizio Meet acceso per la sua OU, le meeting access settings e la waiting room, e se sta usando un account fuori dominio. Per audio e video scadenti si usa il Meet quality tool nella sezione Reporting, che per ogni partecipante mostra latenza, jitter, perdita di pacchetti e occupazione di CPU. Se i numeri di rete sono cattivi si torna ai requisiti: circa 1 Mbps in uscita e 1,3 Mbps in ingresso per partecipante video, porte UDP 3478 e 19302-19309 aperte, porta 443 in TCP e UDP, e i domini Google raggiungibili senza ispezione.