Skip to main content

Questo tutorial nasce dall’esigenza pratica di trovare un’alternativa a Google Meet per le riunioni (collegio dei docenti, formazione, ecc.) con più di 100 partecipanti, ma ha dei risvolti e delle applicazioni che vanno molto oltre questa semplice esigenza pratica.

Il problema era trovare un modo di continuare a fare riunioni senza dover creare nuovi account, usando invece quelli di Google Workspace già esistenti, e soprattutto usando una piattaforma sicura.

La soluzione non è stata semplicissima ma molti colleghi mi hanno confermato di essere riusciti, tenete d’occhio la sezione Updates dell’articolo, nella quale ho aggiunto la soluzione a vari problemi segnalatemi.

La scelta è pertanto caduta su Office 365, che offre al pari di Google Workspace un set completo di app fruibili gratuitamente per le scuole.

I passaggi per fare in modo di accedere ad Office 365 senza dover creare nuovi account non sono semplicissimi, ma mi sono servito di queste due utilissime guide suggerite da Luca Di Fino sul suo blog, una per iscrivere la scuola ad Office 365 e l’altra per fare in modo che le app di questa piattaforma siano accessibili agli utenti Google Workspace con il loro account (senza dover creare un altro account!):

Guida per richiedere e attivare Office 365

Guida per il Single Sign-On (SSO)

Della prima guida ho seguito fino all’attivazione delle licenze illimitate, visto che non è necessario aggiungere utenti. Della seconda, sono partito direttamente dal Single Sign-on, presupponendo che la scuola abbia solo account Google Workspace e nessuno su Office 365 (altrimenti ci sono altri passaggi da fare), per poi proseguire alla parte in cui spiega come far comunicare Google Workspace e Office 365, aggiungendo quest’ultima alle App SAML. Le operazioni da fare sono essenzialmente due:

  1. Federation (il single sign-on che permette di accedere ad un sistema tramite le credenziali di un altro)
  2. Provisioning (la definizione dei permessi, ruoli gruppi degli utenti)

Una volta configurato tutto correttamente, gli utenti dovranno semplicemente andare sulla loro Dashboard di Google Workspace, dove vedranno l’app Office 365 e, aprendola, le app di questa piattaforma che gli avrete abilitato dalla console di Office 365.

Si consiglia Microsoft Edge come browser per usare Teams, oppure scaricare l’app come spiegato sotto.

Ecco il video in cui spiego tutti i passaggi necessari, non dimenticate di mettere un like al video e iscrivervi al mio canale YouTube!

Alcune parti del video sono offuscate per coprire informazioni personali.

Ho tradotto la tabella degli attributi:

Attributo A cosa serve Valore
Domain Name Il dominio della scuola che vogliamo federare Il vostro dominio (quello G SUITE)
Authentication Il metodo di autenticazione prescelto Federated
Federation Brand Name Per nostra referenza, va bene qualsiasi valore Google Cloud Identity
Issuer URI L'ID dell'Entità che effettua il SAML (Google) Entity ID (è nel file dei Metadata scaricato da G Suite)
Passive logon URI Il provider dell'identità (Google) Google SSO URL (è nel file dei Metadata scaricato da G Suite)
Active logon URI Il provider dell'identità (Google) Google SSO URL (è nel file dei Metadata scaricato da G Suite)
LogOffUri Dove l'utente deve essere reindirizzato quando fa il log out (qualsiasi indirizzo va bene) https://accounts.google.com/logout
Signing Certificate La chiave fornita da Google per il SSO X509 Certificate Value (è nel file dei Metadata scaricato da G Suite)
PreferredAuthenticationProtocol Il protocollo di autenticazione prescelto. SAMLP

Di seguito gli script di PowerShell:

$domainName = “VOSTRO DOMINIO”
$Authentication = “Federated”
$FederationBrandName = “Google Cloud Identity”
$IssuerUri = “VOSTRO ENTITY ID”
$PassiveLogOnUri = “VOSTRO GOOGLE SSO URL”
$ActiveLogOnUri = “VOSTRO GOOGLE SSO URL”
$LogOffUri = “https://accounts.google.com/logout”
$SigningCertificate = “VOSTRO CERTIFICATO X509”

Non dimenticate di eseguire il seguente comando dopo aver inserito gli attributi:
Set-MsolDomainAuthentication -DomainName $domainName -Authentication $Authentication -FederationBrandName $FederationBrandName -IssuerUri $IssuerUri -ActiveLogOnUri $ActiveLogOnUri -PassiveLogOnUri $PassiveLogOnUri -LogOffUri $LogOffUri -SigningCertificate $SigningCertificate -PreferredAuthenticationProtocol SAMLP

Dopo aver eseguito il comando è possibile verificare l’effettiva federazione del dominio attraverso questo comando:

Get-MSolDomainFederationSettings -DomainName $domainName | Format-List *
Se si è sbagliato ad indicare le variabili o si sono utilizzate le variabili di esempio,  all’accesso da Google Workspace alle app Office 365 vedrete questo errore:

Message: AADSTS50107: The requested federation realm object ‘https://accounts.google.com/o/saml2?idpid=#########’ does not exist.

 

In tal caso, ridefinire correttamente le variabili ed eseguire di nuovo questo comando:
Set-MsolDomainFederationSettings -DomainName $domainName -PassiveLogOnUri $PassiveLogOnUri -IssuerUri $IssuerUri -ActiveLogOnUri $ActiveLogOnUri -PreferredAuthenticationProtocol Samlp

Updates:

  • Qualcuno mi diceva che non dovrebbe essere necessario inserire i record CNAME e SRV per usare Teams (ma dovete verificarlo).
  • Il dominio che usate con Google Workspace NON deve essere impostato come dominio principale in Office 365, quello principale deve essere quello onmicrosoft.com
  • L’account amministratore di Office 365 deve restare quello iniziale su dominio .onmicrosoft.com. Non usate esclusivamente un account federato come amministratore di Office 365 (come ad esempio l’account admin di Google Workspace).
  • Se PowerShell non trova il primo comando Connect-MsolService vi manca il modulo MSOL, vi basta istallarlo con i comandi: Install-Module MSOnline
    Import-Module Msonline
  • Come sperimentato dal collega Francesco Piccolo, che ringrazio per i sempre preziosi suggerimenti, è possibile attivare Office 365 anche a livello di unità organizzativa, non necessariamente usando il gruppo, che è solo per la fase di test. Se fate ciò, ricordatevi di togliere il provisioning al gruppo che avevate attivato inizialmente, altrimenti gli utenti presenti nella UO scelta non passeranno nella console di Office 365. Una volta passati, potete assegnare le licenze.
  • Pare che a seguito di aggiornamenti si verifichi un errore 500 quando si prova ad accedere ad Office 365, io ho risolto rigenerando il certificato su Google Workspace nella sezione Dettagli del fornitore di servizi, rifacendo la parte PowersShell per inserire il nuovo valore.
  • Abbiate pazienza quando fate il federation, i dati non si aggiornano subito, consiglio di aspettare qualche ora.
  • Consiglio vivamente di scaricare l’app di Teams per PC o al massimo usare Edge come browser per fare l’accesso a Teams, eviterete fastidiosi problemi di re-indirizzamento su Chrome.

Qui trovate una guida per i docenti.

Potete scaricare l’app di Teams per PC o dispositivo mobile da questo link. In questo video mostro come fare il login:

Aggiornamento: adesso, grazie al componente aggiuntivo disponibile sul Google Workspace Marketplace, è possibile creare le riunioni di Meet direttamente in Google Calendar e inviare l’invito su Gmail ai partecipanti, ne ho parlato qui.

La configurazione richiede un po’ di esperienza ma è fattibile e vi assicuro che ho testato che funzioni, ad ogni modo non esitate a contattarmi nel caso voleste provare ad usare questa soluzione per la vostra scuola.

Modulo di contatto

Elenco dei corsi

A presto con nuovi consigli e soluzioni per la didattica digitale.

P.S. Io consiglio vivamente di provare a fare la procedura o contattarmi per una consulenza, ma se proprio non riusciste e il vostro problema sono solo i collegi docenti, potete sempre generare un Team con l’account amministratore di Office 365 e inviare il link ai docenti che entreranno come ospiti, inserendo nome e cognome. Per le presenze potete usare un modulo Google a cui ovviamente i docenti risponderanno con l’account G Suite.

©Google and Google Workspace apps are trademarks of Google LLC and this site is not endorsed by or affiliated with Google in any way.

75 Comments

  • R. FRONTE ha detto:

    Salve,
    per attivare questa procedura si devono abilitare le opzioni “federazione” e “single sign on” su Azure Active Directory, giusto?
    L’applicazione per fare questa abilitazione è Azure AD connect che non si può installare su Windows 10.
    Come posso fare?
    Grazie per la sua attenzione….
    R. Fronte

  • R. Fronte ha detto:

    Ho provato più volte ma non mi fa federare il dominio, mi dice che è managed non federated

  • Daniele ha detto:

    Salve,
    tutto chiaro e di immediata applicazione, tranne (nel mio caso) la parte che riguarda PowerShell. SOno riuscito a ottenere la creazione degli utenti GSuite in Microsoft365, ma ovviamnete, senza quel passaggio, il login non viene eseguito.
    Il messaggio d’errore che ottengo è sempre lo stesso, nonostante abbia provato con molteplici interventi che ho trovato in Rete:
    Chiedo aiuto!
    Grazie!
    Daniele

    PS C:\WINDOWS\system32> Connect-MsolService
    Connect-MsolService : Termine ‘Connect-MsolService’ non riconosciuto come nome di cmdlet, funzione, programma
    eseguibile o file script. Controllare l’ortografia del nome o verificare che il percorso sia incluso e corretto,
    quindi riprovare.
    In riga:1 car:1
    + Connect-MsolService
    + ~~~~~~~~~~~~~~~~~~~
    + CategoryInfo : ObjectNotFound: (Connect-MsolService:String) [], CommandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException

  • Mario Buonvino ha detto:

    Salve, ho capito bene che devo sostituire questa stringa con i miei attributi:

    Set-MsolDomainFederationSettings -DomainName $domainName -PassiveLogOnUri $PassiveLogOnUri -IssuerUri $IssuerUri -ActiveLogOnUri $ActiveLogOnUri -PreferredAuthenticationProtocol Samlp

    Ma non capisco dove devo mettere ad esempio il dominio che è fermimondolfo.onmicrosoft.com

    Grazie in anticipo

    • Lorenzo Redaelli ha detto:

      Ciao,

      no quel comando deve essere eseguito così com’è, dovrà prima inserire i valori delle variabili uno per uno come indicato sopra. Il dominio che deve inserire è quello che vuole federare, ossia quello di G Suite.

  • Rino ha detto:

    Ciao Lorenzo, intanto grazie per la tua guida ben descritta e dettagliata, adesso sto solo aspettando la verifica e l’accettazione da parte di Microsoft, provo a chiederti come e se possibile attivare le licenze in modo massivo a tutti gli utenti, grazie.

    • Lorenzo Redaelli ha detto:

      Ciao e grazie!

      Puoi selezionare fino a 100 utenti sulla console e poi cliccare su Gestisci licenze prodotto in alto.

      • Rino ha detto:

        Ciao Lorenzo,
        ricevo questo messaggio dall’app Microsoft di G-suite
        AADSTS50107: The requested federation realm object ‘https://accounts.google.com/o/saml2?idpid=C010ug3p3’ does not exist.

        Ho seguito tutto da powershell e non mi ha dato nessun errore, cosa può essere secondo te?
        Grazie.

        • Lorenzo Redaelli ha detto:

          Ciao,

          prova a vedere se tutti i parametri inseriti in PowerShell sono corretti, se lo ha appena fatto potrebbe volerci un po’ di tempo.

        • Daniele ha detto:

          Salve Rino, anche a me dà questo errore:
          AADSTS51004: The user account ………………..it does not exist in the 5cd17eba-fc7a-487d-b7a2-16ca32766ecb directory. To sign into this application, the account must be added to the directory.
          Come ha risolto?
          Grazie

  • daniele debiagi ha detto:

    ciao Lorenzo, grazie per la guida: seguito e impostato, molto utile. ho una domanda per un passo ulteriore
    effettuato correttamente il provisioning degli utenti da g suite verso office 365, bisogna assegnare le licenze: c’è modo di automatizzare questa procedura?
    io conosco pochissimo l’ambiente windows/office e l’uso di azure active directory; ho visto che su aad c’è modo di assegnare le licenze ad un gruppo, che è già un passo importante: mi manca di scoprire – se c’è modo – come assegnare automaticamente gli utenti ad un gruppo
    sono alla ricerca di una guida giusta, aad è un mondo inesplorato…

  • Rino ha detto:

    Ciao, come dominio predefinito deve essere quello onmicrosoft.com, giusto?

  • Fabrizio ha detto:

    Ciao Lorenzo, grazie innanzitutto per tutto il materiale utilissimo che hai messo a disposizione e poi volevo chiederti: ad alcuni utenti migrati in office 365 succede che al momento dell’accesso dalla dashboard vengono richieste numerose volte le credenziali ma non viene mai consentito l’accesso almeno che non entrino in modalità in incognito oppure non provino ad entrare con il mio pc. Ho fatto ripulire la cache ma nulla da fare, quale potrebbe essere il problema?
    Grazie in anticipo

  • Marco Gaggioli ha detto:

    Buongiorno Lorenzo.
    Sono giorni che impazzisco per cercare di federare gmail con office365, ho più volte cancellato la federation e reinserito con power shell e sempre con risposte positive, ma non riesco a farli dialogare, su SAML di g suite ottengo sempre lo stesso errore:
    Autoprovisioning for following users failing,,
    Email ID, Error code, Error Details
    utente@icmarconifrosini.edu.it, 45003, StatusCode: 400 : Bad Request : {
    error : {
    code : Request_BadRequest
    message : The domain portion of the userPrincipalName property is invalid. You must use one of the verified domain names in your organization.
    innerError : {
    date : 2020-10-24T19:37:10
    request-id : 55ac5fe1-75ad-48ba-8909-bfe3018ebdf2
    client-request-id : 55ac5fe1-75ad-48ba-8909-bfe3018ebdf2
    }
    details : [
    {
    target : userPrincipalName
    code : InvalidValue

    Per tutti gli utenti.
    Questo errore lo trovo nel log di Provisioning automatico
    Sembra che non riconosca il dominio ma la federation con power shell è sempre andata a buon fine senza errori.
    Chiedo disperatamente aiuto.

    • Lorenzo Redaelli ha detto:

      Ciao Marco,

      l’errore sembrerebbe indicare che il dominio su Office non è stato verificato, hai fatto questo passaggio nel pannello di controllo del dominio?

      • Marco Gaggioli ha detto:

        Il dominio su office è stato verificato, ho inserito tutti i protocolli sul provider e sono state attivate le licenze di office A1 per il dominio icmarconifrosini.edu.it, devo fare altri passaggi?

  • Marco Gaggioli ha detto:

    Avevo effettuato la federetion anche su un altro dominio scolastico e anche su questo mi dava lo stesso errore nonostante avessi fatto tutto come la guida e il comando di controllo risultasse positivo, poi all’improvviso su office 365 sono apparsi gli account di g suite.
    Sul dominio icmarconifrosini.edu.it ancora niente.

  • Emanuele ha detto:

    Ciao Lorenzo, la tua procedura ha funzionato (usando powershell in Windows, con powershell in Mac non funziona) e ti ringrazio.
    La domanda è la seguente: come faccio, dopo la cancellazione di uno o più utenti in Microsoft 365, a forzare il sync nuovamente per farli ricomparire in Microsoft 365? Devo rifare la procedura?
    Ti ringrazio in anticipo per la tua cortese risposta.

    • Lorenzo Redaelli ha detto:

      Ciao,

      quando li cancelli in Office vanno a finire per 30 giorni tra gli utenti eliminati, quindi puoi ripristinarli da lì.

  • Emanuele ha detto:

    Grazie della risposta. In realtà volevo che si sincronizzasse nuovamente da Google Workspace perché in Microsoft 365 mi dava dei problemi.

  • Antonio ha detto:

    Ciao Lorenzo e grazie di tutto, è filato tutto liscio ho anche assegnato le licenze a tutti, l’unico problema che noto è utilizzando l’app office 365 su Chrome va in loop il reindirizzamento è normale?

    • Lorenzo Redaelli ha detto:

      Ciao,

      sì devi disconnetterti e riconnetterti dall’account G Suite, ad ogni modo io consiglio di usare Edge o l’app di Teams proprio per evitare questo problema.

  • Fabiana Sartori ha detto:

    Grazie mille per la tua preziosa guida, oggi dopo vari tentativi sono riuscita a portare a termine la possibilità per gli utenti di loggarsi in Office 365 con account Gsuite, ho trovato diverse difficoltà e problemi che poi leggendo attentamente i consigli che davate sono riuscita a risolvere. Volevo solo aggiungere una cosa, qualora un utente vi dia errore nel provisioning, createlo con Powershell tramite i seguenti comandi:
    Connect-MsolService
    New-MsolUser -UserPrincipalName “d.test@customer.nl” -DisplayName “Daniel Test” -FirstName “Daniel” -LastName “Test” -UsageLocation “NL” -ImmutableId “d.test@customer.nl”
    le indicazioni le ho trovate sul seguente sito “https://www.peppercrew.nl/index.php/2019/07/g-suite-sso-provisioning-accounts-with-azure-ad-and-manually-deleted-accounts-in-azure-ad/” e serve per risolvere gli errori :
    d.test@customer.nl,45003,”StatusCode: 404 : Not Found : {
    error : {
    code : Request_ResourceNotFound
    message : Resource ‘215ed45c-0012-4d87-b86a-14ebcae41e44’ does not exist or one of its queried reference-property objects are not present.
    innerError : {
    request-id : 9a00c647-2217-4046-9ff6-ed3583034810
    date : 2019-07-10T15:31:39
    Ancora grazie a tutti per i Vostri preziosi consigli.

    • Lorenzo Redaelli ha detto:

      Ciao Fabiana,

      mi è capitato proprio ieri per una scuola che seguo, l’utente non era più tra gli eliminati in Office ma comunque non passava, creandolo da PowerShell tutto ok.
      La guida che hai condiviso potrà essere utile per chi si trova nella stessa situazione.

  • Paola ha detto:

    Ciao Lorenzo, ho seguito le tue indicazioni e anche noi, abbiamo configurato Teams In GSuite. Funziona tutto perfettamente.
    Al momento ho solo dato la licenza di Teams; quale altra licenza mi consigli di assegnare ai docenti per il Collegio? Gli studenti, al momento utilizzeranno GSUite. Ci sono 24 app, ma mi sono perso. Grazie

  • Paola ha detto:

    Ciao Lorenzo ho bisogno del tuo aiuto, se possibile.Prima ho effettuato una prova di provisionig con un piccolo gruppo di 6 utenti e tutti gli utenti sono migrati in Teams, ho aggiunto il settimo utente nuovo al gruppo in GSuite e anche quest’ultimo è stato migrato in Teams. Ho effettuato il provisionig di un altrol gruppo, quello del collegio docenti della GSuite composto da 121 docenti e dopo un giorno e mezza non vedo ancora nulla. Dove ho sbagliato’ Grazie mille in anticipo. Paola, Cagliari

    • Lorenzo Redaelli ha detto:

      Ciao,

      difficile dirlo, io controllerei se hai aggiunto il gruppo nell’ambito del provisioning o se nella sezione provisioning ci sono errori.

  • Andrea ha detto:

    Ciao Lorenzo, grazie alla tua illuminante guida sono riuscito già da molto tempo ad importare gli utenti da G-Suite a Microsoft 365.
    Tuttavia il provisioning dei nuovi utenti non è mai riuscito, in particolare compare l’errore

    25001 Backend/servizio Google momentaneamente non disponibile. Configura di nuovo il provisioning automatico.

    Mi consigli di aspettare (sono settimane che non funziona!) o elimino quella configurazione e ne creo una nuova?
    Grazie in anticipo

    • Lorenzo Redaelli ha detto:

      Funziona già dopo qualche ora, quindi evidentemente c’è qualcosa che non è andato a buon fine nel settaggio del provisioning.

  • Alfredo Milone ha detto:

    Buongiorno Prof Redaelli, avrei l’esigenza di fare l’operazione inversa a questa guida, cioè a scuola utilizziamo office365, abbiamo successivamente attivato g-suite e vorrei evitare di ricreare tutti gli utenti e fare in modo che con l’accout di office365 si possa accedere anche a g-suite. Esiste qualche guida per questo.
    Grazie

  • Emanuele Viani ha detto:

    Finalmente dopo 2 mesi di odissea siamo riusciti a federare i 1300 utenti del nostro istituto
    e ad assegnare a tutti la licenza office acquistata.
    Siccome alla fine dopo tanta fatica anche assegnare la licenza è stata una cosa difficilissima
    vi lascio lo script di powershell che mi ha permesso di assegnare a tutti la licenza, senza doverla assegnare
    uno per uno o a gruppetti (come mi voleva far fare l’assistenza Microsoft)

    Ecco lo script di codice da digitare in POWERSHELL connessi col comando Connect-AzureAD

    Get-msoluser -all | Where-Object {$_.UsageLocation -eq $Null} | Export-Csv C:\scripts\Users.csv
    $users = “C:\scripts\users.csv”
    Import-Csv $users | ForEach {
    Set-Msoluser -ObjectId $_.ObjectID -UserPrincipalName $_.UserPrincipalName -UsageLocation “IT”
    }
    Get-MsolUser -All -UnlicensedUsersOnly | Set-MsolUserLicense -AddLicenses “istitutoberenini:OFFICESUBSCRIPTION_STUDENT”

    La prima parte serve ad assegnare l’area geografica agli utenti (diversamente si avrà un errore)
    La licenza ed il dominio vanno sostituiti con quelli effettivamente posseduti
    #Per elencare le licenze (prima connettere col comando Connect-MsolService) e poi usare Get-MsolAccountSku

    Grazie a Lorenzo per l’utilissima guida che mi ha permesso di riuscire nell’impresa (non da poco)

  • Andrea Bindossi ha detto:

    Ciao, guida utilissima.
    Che tu sappia, è possibile configurare un provisioning in modo che gli utenti della OU GSuite chiamata Docenti vengano federati nel gruppo di Azure chiamato Docenti, e gli utenti della OU GSuite Studenti vengano federati nel gruppo di Azure chiamato Studenti?
    Sto cercando da giorni informazioni, ma non riesco a trovare nulla..

    • Lorenzo Redaelli ha detto:

      Ciao,

      la versione A1 di Office 365 non permette di usare i gruppi dinamici, ma credo sia possibile farlo con i comandi giusti in Powershell, non ho una guida al riguardo però mi spiace.

  • Marisa ha detto:

    Ciao,
    come bisogna procedere se si erano già generati anche tutti gli account su Office 365?

    • Lorenzo Redaelli ha detto:

      Ciao,

      ahimé non è semplice. Se sono pochi consiglio il metodo indicato nella guida di Goldy Arora per cambiare gli ImmutableID.

  • Arianna ha detto:

    Grazie per la guida,
    purtroppo mi blocco quasi subito in PowerShell perché quando digito il comando Connect-MsolService mi viene indicato il seguente errore
    Connect-MsolService: Could not load file or assembly ‘System.IdentityModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089’. The system cannot find the file specified.
    Hai idea di come posso risolvere?

    • Lorenzo Redaelli ha detto:

      Ciao,

      potrebbe dipendere dalla versione di Powershell, prova a scaricare una versione diversa (non la 7).

    • Anna ha detto:

      Avevo il tuo stesso problema con Poweshell vers 7. Io ho letto molto su powershell e Office poi ho risolto cosi: Entri in powershell come amministratore e digiti powershell.exe -ep bypass (bypassa le credenziali del computer in uso) Connect-MsolService -Credential $MsolCred con MsolCred forzi il sistema a chiedere le credenziali di amministratore di Office. Poi tutto liscio come da guida del mitico Lorenzo

  • raffaele M. ha detto:

    Ciao Lorenzo, grazie mille per la tua utilissima guida. Sono riuscito a federare tutti quasi tutti i docenti del mio istituto che adesso usano Teams senza problemi. L’unica nota stonata è che quando aggiungo un nuovo utente nell’amministrazione di G Suite, nonostante il provisioning automatico risulti attivo, questo non mi compare in office 365. Qualche soluzione? Non so proprio che pesci pigliare.
    Grazie

    Raffaele

    • Lorenzo Redaelli ha detto:

      Ciao Raffaele,
      il senso della federation è proprio che quando aggiungi un utente in Google Workspace deve passare automaticamente in Office 365, altrimenti c’è qualcosa che non va. Nella sezione
      Provisioning è possibile scaricare un log degli errori, controlla se sono segnalati errori. Inoltre guarderei l’ambito del provisioning per vedere se questi nuovi docenti sono in una UO o gruppo autorizzati a Office 365.

      • Raffaele ha detto:

        Ciao Lorenzo, e grazie della tua risposta.
        Nel log degli errori mi dà questo:
        docente1@xxxxxxx.edu.it, 17013, Generating access token for the SP failed
        Ho disabilitato il servizio per tutti (UO comprese), eccetto che per un paio di gruppi in cui il provisioning ha funzionato nei primi giorni, poi nulla. In altre parole quando inserisco un nuovo utente nel gruppo, quello di sopra è l’errore che ricevo.

        Quasi in concomitanza con questo errore ho ricevuto questa email da Google Workspace:
        “L’impostazione Condivisione esterna directory della Console di amministrazione Workspace ha mostrato un’opzione errata nell’interfaccia utente. L’impostazione Condivisione esterna directory consente di specificare la quantità di informazioni della directory che le app esterne sono autorizzate a utilizzare ed è accessibile da Impostazioni directory > Impostazioni di condivisione nella Console di amministrazione Workspace. Per impostazione predefinita, l’impostazione attivata è “Dati di dominio e pubblici”. Tuttavia, l’impostazione predefinita visualizzata era “Campi profilo di base utente autenticato e dati pubblici”. Il problema ha interessato solo l’interfaccia utente e non ha avuto alcun impatto sul comportamento previsto. Le impostazioni della Console di amministrazione Workspace sono state corrette in modo da riflettere l’impostazione predefinita corretta”.

        Potrebbe dipendere da ciò in qualche modo? O mi conviene autorizzare di nuovo il provisioning?

        • Lorenzo Redaelli ha detto:

          Ciao,

          io autorizzerei il provisioning facendo attenzione a farlo con l’account admin globale .onmicrosoft.com. Se non ti permette di scegliere entra nell’admin di Google Workspace da una scheda in incognito.

  • Quintino Cavalera ha detto:

    Ciao, scusa se ricorro nuovamente a te per risolvere un problema
    Nel momento in cui ho federato GSuite con Office ho predisposto il passaggio solo per parte degli utenti GSuite, adesso se vado ad aggiungerli per consentirgli di usare Office con GSuite, lato GSuite me li dà in elenco, lato Office non entrano.
    Qualche idea su quale sia l’errore?
    Grazie ancora per la disponibilità

    • Lorenzo Redaelli ha detto:

      Ciao!
      Io verificherei nella sezione provisioning se ci sono degli errori ed eventualmente scaricherei il log con la descrizione.
      Se non ci sono errori, verifica se per caso nell’ambito del provisioning hai lasciato autorizzato un gruppo ma poi hai selezionato delle UO in seconda battuta.

  • Quintino Cavalera ha detto:

    Aggiornamento:
    Siccome sono riuscito ad effettuare il passaggio, riporto le azioni effettuate nel caso qualcun altro si trovasse con lo stesso problema
    Per attivare i nuovi utenti bisogna andare nella pagina della “App web e per dispositivi mobili” e selezionare il sevrizio “Microsoft Office 365”
    Quindi aprire la pagina “Provisioning automatico” e selezionare “Ambito del provisioning (facoltativo)” – voce “Modifica” aggiungere i nuovi gruppi da esportare su Office e poi cliccare su “Aggiorna”
    Passaggio completato

    • Lorenzo Redaelli ha detto:

      Ciao, sì esatto è quello che ti dicevo, in realtà hai due possibilità: o fai come hai detto tu oppure cancelli tutti i gruppi dall’ambito del provisioning e gestisci le autorizzazioni direttamente dalla scheda Accesso utenti (in cui ci sono anche le UO). Io consiglio il secondo metodo, magari il gruppo nell’ambito del provisioning lo mettete solo per i test iniziali, ma ricordatevi di toglierlo poi 🙂

  • Fabio Marca ha detto:

    Ciao grazie per il tuo tutorial; avrei due domande :
    1) La prima voce che devo inserire nella powershell e cioè domain name è il dominio di office 365 non quello di gsuite; è corretto?
    2) Il dominio di office 365 è già popolato con gli account di onmicrosoft.com quindi da come ho capito non posso fare la federazione se non andando a lavorare sugli immutabled ma se faccio la federazione con un altro dominio creato dal dominio principale che resta senza utenti posso avere successo nell’operazione di federazione?
    Grazie per le risposte
    Fabio Marca

    • Lorenzo Redaelli ha detto:

      Ciao Fabio,

      1) Il dominio che devi inserire in PowerShell è il dominio della vostra Google Workspace, quella che vuoi federare.
      2) Di conseguenza non devi usare gli account su .onmicrosoft.com ma quelli che arriveranno direttamente da Workspace. Si interviene sugli ImmutableID solo se hai già gli account sullo stesso dominio di Workspace anche su Office, ma non mi pare sia il tuo caso.

      In bocca al lupo!

      • Fabio ha detto:

        Scusa Lorenzo quando parli dei gruppi per il provisioning intendi le unità organizzative di workspace oppure gruppi veri e propri? E nel caso si voglia lasciare anche agli studenti la possibilità di accedere ad office 365 tramite workspace si può utilizzare qualche carattere jolly per farli entrare tutti o bisogna indicare tutti i gruppi delle classi? (nel workspace del nostro istituto i gruppi studenti corrispondono ai gruppi delle varie classi).
        Ti ringrazio
        fabio

        • Lorenzo Redaelli ha detto:

          Ciao Fabio, dalla console di Google puoi scegliere se far passare su Office dei gruppi o delle unità organizzative. Nel caso degli studenti ti consiglio di abilitare l’intera UO.

          • Fabio ha detto:

            Grazie Lorenzo ne approfitto ancora; ho visto che nel verificare il dominio, Microsoft ha cambiato qualcosa: nel secondo passaggio c’è sempre exchange per la posta a cui come consigli tu ho tolto il segno di spunta, ma in quelli avanzati hanno tolto la voce meet e hanno lasciato solo skype e dalla descrizione sembra di capire che meet sia già utilizzabile senza aggiungere gli scrpt nel dns del fornitore del dominio. Non so però se ho capito bene. Che cosa mi consigli di fare ? Tolgo il segno di spunta anche a quello o procedo per abilitare skype.
            Ti ringrazio molto e scusa per le troppe domande
            Fabio

          • Lorenzo Redaelli ha detto:

            Non è necessario abilitare quei record, Teams funzionerà comunque. Fai solo la verifica del dominio.

  • Fabio Marca ha detto:

    Ciao Lorenzo sono riuscito a federare alla fine i due domini; unico problema una quindicina di utenti sono rimasti fuori dal provisioning con questo messaggio di errore :
    45003, StatusCode: 400 : Bad Request : { error :{ code : Request_BadRequest message : Invalid value specified for property ‘department’ of resource ‘User’. details :[{ target : department code : InvalidLength }] innerError :{ date : 2021-08-05T20:45:24 request-id : fe5545c8-d733-447b-bb62-bd52ef663907 client-request-id : fe5545c8-d733-447b-bb62-bd52ef663907 }}}
    Ho cercato in vari modi di risolvere il problema : inserendo gli utenti non passati su office 365 in un’altra UO e aggiungendola a quelle che avevano i permessi per utilizzare office 365, disattivando e riattivando il provisioning e infine inserendo di nuovo le credenziali.
    Mi chiedo se sia possibile forzare il passaggio in qualche modo su office 365 di questi utenti ma non sono riuscito a trovare niente in rete.
    Avresti qualche suggerimento da darmi ?
    Ti ringrazio
    Fabio

    • Lorenzo Redaelli ha detto:

      Ciao, no mi spiace questo errore non l’ho mai visto, difficile sapere cosa è andato storto senza metterci le mani.

  • Alessandra Errigo ha detto:

    Buongiorno Lorenzo… ti sarei molto grata se potessi rispondere ad un quesito riguardo alla nuova configurazione del Collegio Docenti. Lo scorso anno ho fatto la Federation per utilizzare Teams durante i Collegi. Poiché su Google Workspace ho sospeso alcuni docenti che hanno terminato il servizio nel nostro istituto, vorrei sapere se verranno sospesi automaticamente anche su Microsoft 365. Inoltre, data la mia poca esperienza su Teams (lo usiamo solo per i Collegi Docenti, per l’appunto), vorrei sapere se c’è un modo semplice per far partecipare alle riunioni gli utenti esterni all’organizzazione.

    • Lorenzo Redaelli ha detto:

      Ciao Alessandra,

      se in fase di configurazione hai impostato il provisioning in modo che sospendendo un utente su Google, questo venga automaticamente sospeso su Office 365 allora sì. Puoi controllare nella sezione provisioning dell’app Office 365 nella console di Google.
      Più semplicemente, vai nella console di Office e verifica lo stato di questi utenti, ed eventualmente sospendili manualmente.

  • Alessandra Errigo ha detto:

    Buongiorno Lorenzo
    mi sembra di capire, quindi, che non posso agire più da Google o c’è un altro modo per farlo? E da Office non c’è un’azione che mi permetta di farlo massivamente?

    • Lorenzo Redaelli ha detto:

      Devi agire dalla console di Google, nella sezione provisioning, lì trovi le opzioni per stabilire cosa deve succedere agli utenti su Office quando li sospendi su Google.

      • Alessandra Errigo ha detto:

        Grazie Lorenzo…in realtà queste opzioni sono già selezionate su Google ma su Office mi compaiono tutti gli utenti attivi e, tra l’altro, anche cliccando sulle azioni dei singoli utenti non appare la voce “sospendi” ma solo “elimina”

  • Vanessa ha detto:

    Ciao Lorenzo..
    nel log di controllo mi appare il seguente errore:
    17013, Generating access token for the SP failed
    cosa posso fare?

    • Lorenzo Redaelli ha detto:

      Ciao Vanessa,

      dovrebbe bastare andare nella sezione Provisioning e fare autorizza di nuovo. Accertati di loggarti con un account che sia anche amministratore globale in Office 365 o da una scheda in incognito.

Lascia un commento

Questo sito usa Akismet per ridurre lo spam. Scopri come i tuoi dati vengono elaborati.

%d blogger hanno fatto clic su Mi Piace per questo: