Esperto a tutto tondo: Gestire Office 365 con Windows PowerShell
Per coloro che non avessero mai considerato l'utilizzo di Windows PowerShell per gestire applicazioni basate su cloud quali Office 365, in questo articolo è contenuta una guida rapida per il principiante totale.
Greg Shields
La mia azienda, Concentrated Technology, ha recentemente completato la transizione da Google Apps for Business a Microsoft Office 365. La nostra migrazione si è rivelata incredibilmente semplice. Mediante una semplice soluzione di terze parti, abbiamo migrato i nostri dati alla nuova piattaforma con poco più di due password e un semplice clic del mouse per ciascun utente.
Improvvisamente, ci siamo trovati in un'infrastruttura completamente nuova con una nuova serie di regole totalmente nuove. Benché siamo un gruppo di utenti abbastanza esperti nelle tecnologie Microsoft, l'impiego di Windows PowerShell in Office 365 ci ha colto in qualche modo impreparati. L'idea di utilizzare Windows PowerShell con Office 365 può apparentemente risultare conflittuale. Gli utenti cercano soluzioni come Office 365 in parte perché ricercano la semplicità.
Benché il completamento di attività con Windows PowerShell non sia necessariamente complesso, non è certamente semplice. La parte più difficile è forse l'inizio. Pertanto questo mese, ho preparato una guida introduttiva curata su Windows PowerShell per Office 365 per il principiante totale. Attenendosi a questi passaggi e apprendono alcuni cmdlet fondamentali, è possibile che si scopra che i termini "potente" e "semplice" non si escludono in modo reciproco.
Passaggio 1: acquisire familiarità con l'esecuzione (realmente) remota
Windows PowerShell è uno strumento indubbiamente potente. Vi è una fase nella curva di apprendimento, tuttavia, in cui il principiante totale spesso si perde, ovvero dopo aver appreso i cmdlet più elementari ma prima di aver acquisito una completa padronanza su come creare soluzioni utili. Una cosa è eseguire Get-Process e visualizzare i processi in esecuzione nel computer locale, un'altra è pianificare l'esecuzione di una serie di cmdlet in un computer remoto per completare un'operazione reale.
Consiglio di dedicare accuratamente del tempo a comprendere il funzionamento delle comunicazioni remote di PowerShell all'interno della propria rete LAN. È necessario, ad esempio, comprendere che il parametro computerName funziona con alcuni cmdlet, mentre è necessario utilizzare il cmdlet Invoke-Command con altri. Consiglio inoltre di acquisire familiarità con il cmdlet Get-Help e la relativa opzione -exa incredibilmente utile per la visualizzazione degli esempi.
Sarà necessario acquisire queste competenze perché in Office 365 se ne fa un uso tale da richiedere delle basi solide. Con i cmdlet di Office 365, i comandi verranno eseguiti tramite i server Microsoft e non i propri server locali e verranno inviati via Internet invece che all'interno della propria rete LAN. Questo richiede un'attenta riflessione, ma porterà i propri frutti. L'acquisizione di familiarità con tali concetti si rivelerà notevolmente proficuo specialmente quando tutto diventerà "estremamente chiaro".
Passaggio 2: preparazione di PowerShell
Windows PowerShell non è compatibilmente nativamente con il linguaggio di Office 365. Per far comunicare un desktop Windows 7 con Office, sono necessarie alcune attività preparatorie.
Accedere alla pagina relativa all'utilizzo di Windows PowerShell per la gestione di Office 365 e installare i cmdlet di Office 365. Vengono installati insieme al Modulo dei Microsoft Online Services per Windows PowerShell e sono disponibili per edizioni di Windows x86 e x64. Prima di installarli, nel computer desktop sarà inoltre necessario installare e attivare l'Assistente per l'accesso ai Microsoft Online Services, nonché Windows PowerShell e .NET Framework 3.5.1.
Passaggio 3: importazione del modulo, creazione della sessione, importazione dei comandi
L'installazione dei cmdlet di Windows PowerShell è solo la prima fase e non ha alcun effetto sull'effettiva connessione al cloud di Microsoft Office 365. La connessione al cloud richiede una procedura complessa ma intuitiva in cinque passaggi:
1. Importazione del modulo Online Services appena installato
2. Immissione delle credenziali di Office 365
3. Creazione di una sessione remota
4. Importazione dei comandi della sessione nella sessione locale di Windows PowerShell
5. Connessione ai servizi di Office 365
I cinque comandi per completare la procedura hanno un aspetto simile al seguente:
Import-Module MSOnline $O365Cred = Get-Credential $O365Session = New-PSSession -ConfigurationNameMicrosoft.Exchange -ConnectionUri https://ps.outlook.com/powershell -Credential $O365Cred -Authentication Basic -AllowRedirection Import-PSSession $O365Session Connect-MsolService –Credential $O365Cred
Questa struttura potrebbe sembrare complicata in prima analisi, ma occorre ricordare che Windows PowerShell è progettato per adattarsi alle esigenze di tutti gli utenti. Di conseguenza, alcuni comandi sono semplicemente più lunghi di altri. È necessario rendersi conto che tale struttura ha come obiettivo cinque operazioni: In primo luogo, utilizza il cmdlet Import-Module per aggiungere i cmdlet di Office 365 alla sessione per consentire alla sessione locale di comunicare con Office 365.
In secondo luogo, viene avviata una finestra di dialogo in cui viene chiesto di immettere il nome utente e la password di Office 365 (in modo simile a: nomeutente@dominio.onmicrosoft.com). Tali informazioni sulle credenziali vengono memorizzate nella variabile $O365Cred, per poter essere utilizzate nuovamente in seguito.
È a questo punto che la situazione diventa interessante. Con il terzo e il quarto comando viene creata una nuova sessione di Windows PowerShell nel cloud all'indirizzo https://ps.outlook.com/powershell e vengono importati i cmdlet di tale sessione nella sessione locale, in modo simile all'utilizzo dell'utilità PSExex per accedere al prompt dei comandi di un server remoto. La sostanziale differenza risiede nel fatto che il server remoto si trova in un punto del cloud e la relativa sessione remota viene in realtà integrata nella sessione locale (vedere la Figura 1).
.jpg)
Figura 1 Creazione di una sessione di Office 365 remota
Ora, osserviamo il testo di colore giallo nella Figura 1. Noteremo qualcosa di simile a quanto segue:
WARNING: Your connection has been redirected to the following URI: "https://pod51018psh.outlook.com/PowerShell-LiveID?PSVersion=2.0" WARNING: Your connection has been redirected to the following URI: "https://sn2prd0702psh.outlook.com/PowerShell-LiveID?PSVersion=2.0"
L'URI visualizzato sarà leggermente diverso rispetto a quello mostrato qui. La connessione di una sessione remota alla pagina https://ps.outlook.com/powershell ne comporta il reindirizzamento automatico ai server che ospitano le risorse di Office 365. In questo caso, i server sono pod51018psh.outlook.com e sn2prd0702psh.outlook.com.
Nel vostro caso la situazione sarà diversa. Questi saranno i server con cui si interagirà direttamente quando si richiameranno successivamente i comandi Windows PowerShell di Office 365.
Passaggio 4: esaminare la nuova libreria di comandi
Una volta avviata una connessione, sarà possibile gestire le risorse di Office 365. Attualmente, l'accesso di Windows PowerShell è limitato alle risorse Office 365 ed Exchange e presto sarà aggiunto l'accesso a SharePoint.
Digitando Get-Command -module MSOnline, verrà visualizzato un elenco dei cmdlet di Office 365. Fare clic qui per accedere inoltre a una comoda tabella dei comandi con relative brevi descrizioni.
Di seguito un cmdlet particolarmente utile per modificare una password di Office 365 e e reimpostarla in P@ssword!. È possibile inoltre omettere il parametro -NewPassword per generare automaticamente una password casuale:
Set-MsolUserPassword -UserPrincipalName nomeutente@dominio.onmicrosoft.com -NewPassword P@ssword!
Tali cmdlet sono tutti correlati agli oggetti di Office365. In aggiunta a essi, è disponibile una seconda serie che consente di gestire le risorse di Exchange con cui interagiscono tali oggetti. Esistono una vasta gamma di cmdlet, ma qui è disponibile un comodo riferimento a essi.
Passaggio 5: i profili semplificano la vita
I cinque comandi riportati nel Passaggio 3 che consentono all'utente di connettersi al cloud rappresentano senza dubbio una porzione sostanziosa di testo. La ridigitazione di un tale blocco di testo a ogni accesso può far sembrare l'utilizzo di Windows PowerShell più complesso del necessario. Tuttavia, Windows PowerShell e in generale la creazione di script nella shell implica la creazione di stringhe di comandi una sola volta per poi beneficiarne per sempre.
Ogniqualvolta viene avviata una sessione di Windows PowerShell, verranno eseguiti tutti i comandi trovati in uno speciale file definito dalla variabile $profile. È possibile verificare la posizione del file eseguendo il comando dir $profile nella shell.
In questo caso, il file $profile corrisponde al file Microsoft.PowerShell_profile.ps1 (see Figura 2), che si trova nella cartella C:\Utenti\gshields\Documenti\WindowsPowerShell. È possibile modificare questo documento nel proprio editor di testi preferito in aggiunta ai cinque comandi di connessione. Ora, a ogni avvio di Windows PowerShell, sarà necessario digitare solo il nome utente e la password per connettersi automaticamente a Office 365, nonché ad altre risorse nella rete.
.jpg)
Figura 2 Visualizzazione del file $profile.
Da un grande potere derivano grandi responsabilità
Attenersi a questa procedura per creare un'area di lavoro perfettamente integrata in cui sia possibile gestire le risorse locali e remote. Tuttavia, la stessa area di lavoro può rivelarsi tanto utile quanto pericolosa.
Se apprendere i risultati dell'esecuzione del comando Get-Process | Stop-Process (meglio evitare) ci hanno fatto sogghignare, rabbrivideremo quando ci renderemo conto della potenza del comando Get-MsolUser | Remove-MsolUser. Quindi, fate attenzione ai nuovi poteri acquisiti e alle responsabilità che ne derivano.
.jpg)
Greg Shields, MVP, è partner in Concentrated Technology. Per ottenere ulteriori suggerimenti da parte di Greg Shields, esperto a tutto tondo, è possibile visitare il sito ConcentratedTech.com.