Il parco dispositivi oltre le sale

Il dominio “Teams Rooms e dispositivi” non si esaurisce nelle sale riunioni: comprende i Teams phone personali assegnati a un utente, i common area phone installati in reception, magazzino, corridoi o ascensori, i telefoni da conferenza da tavolo e i Teams panel all’ingresso delle sale. La distinzione che conta all’esame è di licensing e di identità: un telefono personale usa l’account dell’utente e la sua licenza Teams Phone; un common area phone usa un account dedicato con una licenza pensata per i dispositivi condivisi, e le sue capacità (chiamate in uscita, ricerca in rubrica, hot desking, join alle riunioni) dipendono dalle policy assegnate a quell’account, non dall’hardware. Il panel, invece, non fa chiamate: mostra stato e prenotazioni della sala e si appoggia al resource account della room.

Tutti questi oggetti si governano dal Teams admin center, sezione Teams devices, mentre le sale con piano Pro trovano monitoraggio, inventario, gestione degli aggiornamenti e ticketing nel Teams Rooms Pro Management portal. Le due console non sono alternative: la prima resta il punto di configurazione, la seconda aggiunge operatività su scala.

Configuration profile, device tag e Intune

La leva di configurazione di massa è il configuration profile: un set di impostazioni (lingua, fuso, display, comportamento del dispositivo, opzioni di rete) assegnato a una categoria di dispositivi. I device tag sono invece etichette libere applicate ai dispositivi per costruire inventario e viste: si filtra per tag e si eseguono azioni bulk — restart, update, raccolta log, applicazione di un profilo — su un sottoinsieme, tipicamente per sede, piano, tipo di sala o fase di rollout. Se lo scenario chiede “applicare la stessa impostazione a un gruppo di dispositivi e monitorarli separatamente”, la risposta è tag più configuration profile, non intervento sul singolo device.

Sul fronte identità, ogni dispositivo si autentica con un account Microsoft Entra ID: perciò le conditional access policy lo raggiungono. Se una policy richiede un dispositivo compliant, i device devono essere enrollati in Intune; se richiede MFA interattiva, un account di sala o di telefono condiviso non riesce a soddisfarla e va gestito con criteri dedicati. Per i dispositivi Android, la gestione si è spostata sul management AOSP in Intune, che sostituisce l’enrollment legacy basato su device administrator, e sulla piattaforma MDEP con cui Microsoft distribuisce firmware e componenti sui dispositivi certificati: pianifica la migrazione dei device esistenti, non darla per automatica.

Per Teams Rooms on Windows vale la regola opposta a quella dei PC: l’appliance va collocata in una OU esclusa dalle group policy generali (in particolare quelle che toccano lockdown, aggiornamenti, power management, criteri di logon), perché il sistema si aggiorna e si autologa da solo. La personalizzazione supportata passa da un file di configurazione XML locale (SkypeSettings.xml), che imposta tema, dual screen, comportamento del contenuto e delle periferiche.

Spazi flessibili: hot desking, bookable desk, BYOD

L’hot desking consente a un utente di accedere temporaneamente a un dispositivo condiviso (telefono o display) portandoci la propria identità, chiamate e chat, con logout automatico a fine sessione o a scadenza timeout: è una funzione del dispositivo, abilitata via configuration profile. I bookable desk sono un’altra cosa: la scrivania diventa una risorsa prenotabile, riconosciuta tramite la periferica presente alla postazione, così l’utente vede il posto occupato o libero e può riservarlo. Il proximity join permette di far entrare in riunione la sala dal proprio client quando si è fisicamente vicini, e richiede il beaconing Bluetooth attivo sul room device.

Restano gli spazi BYOD: sale con schermo e periferiche USB ma senza console Teams Rooms, dove si entra dal proprio laptop. Vanno comunque censite come tipo di room nell’inventario, altrimenti spariscono dai report di utilizzo e dalla capacity planning; con la gestione Pro possono essere seguite insieme alle sale native.

Trappole tipiche d’esame

  • Telefono in reception che deve solo chiamare → common area phone, non account utente: serve un account dedicato con licenza per dispositivi condivisi e le policy di calling adeguate; assegnare una licenza utente è sovradimensionato e complica la gestione.
  • Centinaia di telefoni SIP esistenti da non sostituire → SIP Gateway: riusa l’hardware certificato, ma va abilitato nella calling policy dell’utente e offre un set di funzioni ridotto; non aspettarti l’esperienza completa di un Teams phone.
  • Conditional access blocca l’accesso dei dispositivi → enrollment Intune ed esclusioni mirate: i requisiti di device compliance vanno soddisfatti registrando i device; per gli account condivisi si escludono i requisiti interattivi, non si disattiva la policy per tutti.
  • Aggiornare o riavviare i dispositivi di una sola sede → device tag e azioni bulk: i tag esistono per segmentare l’inventario; senza di essi il rollout a ondate diventa manuale.
  • Teams Rooms on Windows instabile dopo il join al dominio → escludere l’OU dalle GPO e usare il file XML: le group policy generiche interferiscono con l’autologon e gli aggiornamenti; la personalizzazione supportata è locale.
  • “Serve prenotare la postazione” vs “serve accedere a un dispositivo condiviso” → bookable desk vs hot desking: il primo prenota uno spazio, il secondo porta l’identità su un device; scambiarli è l’errore più comune sugli spazi flessibili.