本篇文章講解如何利用 PowerShell 來管理微軟線上服務 ( Microsoft Online Services )，使用 PowerShell 管理工具有許多好處，針對一些繁複且容易操作錯誤的管理工作，透過 PowerShell 指令的方式來操作，不但能減少發生操作錯誤的機率，還能提高整體 IT 管理效率，甚至還能做到許多目前微軟線上服務的 Web 介面無法設定的參數，因此要深入 Office 365 管理，勢必要學習如何使用 PowerShell 管理相關資訊。
>>> 試用 Office 365 的申請連結 <<<
執行環境要求
- 作業系統必須 Windows 7 或 Windows Server 2008 R2 以上版本
- 必須安裝 Windows PowerShell (已內建) 與啟用 .NET Framework 3.5.1 功能
- 必須安裝 Microsoft Online Services 登入小幫手 (Microsoft Online Services Sign-In Assistant)
- 必須安裝 Microsoft Online Services Module for Windows PowerShell (包含一堆 Cmdlets 命令)
※ 補充說明
當安裝完 Microsoft Online Services Module for Windows PowerShell 之後，安裝程式會在桌面新增一個捷徑，如下圖示：
該捷徑的目標如下，其重點在於 Import-Module MSOnline 這段命令，這代表開啟 PowerShell 視窗時，會先執行這行命令載入 MSOnline 模組，該模組包含許多用來管理微軟線上服務的 Cmdlets 自訂命令：
powershell.exe -NoExit -Command "Import-Module MSOnline"
也代表著，如果你今天直接開啟 Windows PowerShell 視窗，手動指令 Import-Module MSOnline 也可以匯入 MSOnline 模組裡定義的那些 Cmdlets，如下圖示：
如果你想查詢 MSOnline 模組中有哪些 Cmdlets 可用，可以輸入以下指令查詢：
Get-Command -Module MSOnline
取得 Cmdlets 命令清單的圖示如下：
使用 Microsoft Online Services Module (MSOnline) 裡的 Cmdlets 自訂命令
在開始使用這些 Cmdlets 命令前，你必須先讓目前的 PowerShell 階段工作環境 (PSSession )登入到微軟線上服務，因此每次開啟 PowerShell 命令視窗後，都應該先輸入 Connect-MsolService 指令登入：
接著我用【使用者管理】為例，逐步說明使用這些 Cmdlets 自訂命令的方法。
1. 新增使用者 (New-MsolUser)、列出使用者 (Get-MsolUser)、更新使用者 (Set-MsolUser)、指定授權(Set-MsolUserLicense)
不過，在開始介紹使用 New-MsolUser 命令來新增使用者之前，我想先介紹在微軟線上服務中是如何透過 Web 介面新增使用者的，讓大家了解這兩種操作方式的關聯性，以及找不到關聯性時的解決辦法。
第一步，輸入使用者詳細資料，這裡的必填欄位是【顯示名稱】與【使用者名稱】
第二步，我們會【設定使用者位置】，至於指派權限的部分，預設通常不會賦予特別的角色權限。
第三步，必須【指派授權】使用者才能使用如 Exchange Online 或 SharePoint Online 等服務。
註：當然，你也可以不指定任何授權，單純的先建立帳號，待日後購買訂閱授權後再指派授權也可以。
第四步，設定使用者建立成功後的密碼要寄送到哪裡，預設就是組織管理者的 Email 地址：
第五步，使用者建立完成，並取得一個使用者的暫時密碼！
上述就是透過 Web 介面建立使用者的完整過程，由於過程中我們有指派 Exchange Online 授權，因此使用者建立完成後，該使用者就可以立刻登入微軟線上網站，並使用 Outlook Web App 網站來收發郵件。
接著我們就要準備改用 PowerShell 命令來幫我們建立使用者帳號，那麼我們要指定甚麼參數，才能建立出完全一樣的使用者帳號呢？就讓我們繼續看下去…
若要了解 New-MsolUser 命令的用法，最簡單的方式就是呼叫 help 即可叫出說明文件與使用範例，如下範例指令就會列出每一個參數的說明，並在說明文件的最後提供幾個範例，讓你了解參數應該如何指定：
help New-MsolUser -detailed
不過，有些參數其實是有「預設值」的，透過上述 -detailed 參數並不會顯示預設值為多少，如果你想知道，可以改輸入已下指令，這將會列出更加詳細的參數說明與預設值定義：
我們先用另一個 Get-MsolUser 取得剛剛建立的那位【林測試】的帳號資訊，其用法如下範例：
Get-MsolUser -UserPrincipalName testuser@miniasp.onmicrosoft.com
上述範例利用 -UserPrincipalName 參數，並指定該使用者的 Email 地址，就可以取出該帳號的資料：
事實上這位【林測試】帳戶有許多欄位，但畫面上只顯示三個而已，透過上述指令無法顯示完整欄位，因此你可以考愈改成以下指令，最後加上 | fl 即可 (fl = Format-List)，以顯示完整的帳戶欄位資料：
Get-MsolUser -UserPrincipalName testuser@miniasp.onmicrosoft.com | fl
接著我們用 New-MsolUser 命令的詳細說明 ( -detailed ) 提供的範例來做加強說明，第一個範例是單純的建立帳號，說明中提到的範例如下：
New-MsolUser -UserPrincipalName user@contoso.com -DisplayName "John Doe" -FirstName "John" -LastName "Doe"
我將其改寫如下，建立另一個 testuser2@miniasp.onmicrosoft.com 帳號：
New-MsolUser -UserPrincipalName testuser2@miniasp.onmicrosoft.com -DisplayName "林測試" -FirstName "測試" -LastName "林"
執行過程如下圖示，你可以發現，該使用者的暫時密碼也會顯示在畫面上，這密碼你必須記錄下來，因為透過 PowerShell 建立帳號並不會將密碼通知信發給管理者，這點要特別注意。
基本上，光用這個範例來建立帳號會缺少許多必要的設定值，我們拿來跟從 Web 介面建立的過程做比較，就可以知道我們還缺乏了以下兩個設定：
- 設定使用者位置
- 指派授權 ( 如上圖的 isLicensed 值為 False )
我們接著來看 New-MsolUser Cmdlet 說明中提到的第二個範例的確有提到上述兩個缺少的設定：
New-MsolUser -UserPrincipalName user@contoso.com -DisplayName "John Doe" -FirstName "John" -LastName "Doe" -UsageLocation "US" -LicenseAssignment "Contoso:BPOS_Standard"
當我們要設定 -UsageLocation 與 -LicenseAssignment 參數時，相信各位一定會卡住，因為你不知道正確的參數值為多少。為了解決這個問題，參照剛剛建立的【林測試】帳號就非常重要了，因為我們剛剛建立的那個帳號可以當成我們的範本，我們只要去看該帳號在該欄位的設定值，就知道我們要設定哪一個了!! 我們一樣用 Get-MsolUser 命令取得剛剛第一次建立的那位 testuser@miniasp.onmicrosoft.com 的帳號資訊，查看看有沒有我們要的參考資料：
Get-MsolUser -UserPrincipalName testuser@miniasp.onmicrosoft.com | fl
如下圖示，我們的確可以找到我們要的資訊：
不過，你怎麼知道我們第二次建立的 testuser2@miniasp.onmicrosoft.com 缺少這個參數值呢？我們一樣用 Get-MsolUser 命令取得剛剛第二次建立的那位 testuser2@miniasp.onmicrosoft.com 的帳號資訊，查看看有沒有我們要的參考資料：
Get-MsolUser -UserPrincipalName testuser2@miniasp.onmicrosoft.com | fl
如下圖示，我們的確可以發現，欄位真的都是空的：
接著我們把範例指令改成如下，建立我們第三個測試帳戶：
New-MsolUser -UserPrincipalName testuser3@miniasp.onmicrosoft.com -DisplayName "林測試" -FirstName "測試" -LastName "林" -UsageLocation "TW" -LicenseAssignment "miniasp:ENTERPRISEPACK"
這時我們可以看到該帳號已經有指定授權了!
我們一樣再次使用 Get-MsolUser 命令取得剛剛第三次建立的那位 testuser3@miniasp.onmicrosoft.com 的帳號資訊，查看看有已經設定好沒有要指定的欄位值：
Get-MsolUser -UserPrincipalName testuser3@miniasp.onmicrosoft.com | fl
如下圖示，我們的確可以發現，欄位值都補上去了：
如果這時我們要把第二次建立的 testuser2@miniasp.onmicrosoft.com 補上值，那麼你可以改用 Set-MsolUser 命令，去修正 UsageLocation 的值(也可用其他參數更新帳戶資料)，如下範例：
Set-MsolUser -UserPrincipalName testuser2@miniasp.onmicrosoft.com -DisplayName "林測試" -FirstName "測試" -LastName "林" -UsageLocation "TW" -PreferredLanguage "zh-TW"
由於 Set-MsolUser 命令無法指派授權，因次如果要將缺少的授權加入該帳戶的話，必須改用 Set-MsolUserLicense 這個 Cmdlet 才行，以下就是新增授權到 testuser2@miniasp.onmicrosoft.com 的範例：
Set-MsolUserLicense -UserPrincipalName testuser2@miniasp.onmicrosoft.com -AddLicenses "miniasp:ENTERPRISEPACK"
這樣就會把授權給加上了!
2. 重設密碼 (Set-MsolUserPassword)
直接重設特定帳號密碼，系統會自動指派一個亂碼為暫時密碼，使用者首次登入後會被要求更改密碼：
Set-MsolUserPassword -UserPrincipalName testuser@miniasp.onmicrosoft.com
也可以直接指定一個新密碼給該使用者：
Set-MsolUserPassword -UserPrincipalName testuser@miniasp.onmicrosoft.com -NewPassword P@ssw0rd
3. 變更使用者的使用者主要名稱 (使用者 ID) (Set-MsolUserPrincipalName)
在剛開始使用 Office 365 時，通常都會用一個試用網域，所以等轉換到正式網域後，勢必會轉換每個帳戶的 User ID，這時就可以利用 Set-MsolUserPrincipalName 來變更 User ID，例如我們要將 testuser@miniasp.onmicrosoft.com 轉換成 testuser@miniasp.com，這時可以用以下指令完成：
Set-MsolUserPrincipalName -UserPrincipalName testuser@miniasp.onmicrosoft.com -NewUserPrincipalName testuser@miniasp.com
4. 移除使用者(Remove-MsolUser)
最後，我們用 Remove-MsolUser 命令把這些測試帳號刪除，指令範例如下：
Remove-MsolUser -UserPrincipalName testuser@miniasp.com
以下是刪除的畫面圖示，每次刪除都會需要再次確認：
※ 補充說明
從微軟線上服務刪除的使用者預設會被保留 30 天，以防止誤刪帳號的情事發生！如果要復原帳號，可以先登入 Microsoft Online Services 網站，在【使用者】管理的地方切換到「已刪除」分頁，就可以將使用者帳戶還原，如下圖示：
總結
使用 PowerShell 替 IT 工作帶來效益，建議每位 IT 人員都應該設法了解 PowerShell 的各種應用，相信熟悉之後無論何種管理工作都能帶來十足的幫助！
心得分享
自從我們公司把 Exchange Server 整個搬上 Office 365 雲端平台後，說實在的減輕了我許多 IT 管理上的風險與壓力，也節省了許多看的見與看不見的成本開支。你也知道中小企業的 IT 總是能省則省，安裝 Exchange 時最多也只有一台主機，也只買得起一套授權，無法架設高可用性 (HA) 的叢集環境。
以我們為例，之前我在管理公司 Exchange 時，平時根本就沒在碰 Exchange 伺服器，都是只有出問題的時候才會去看，我管 Exchange 將近五年，平均 1 年多會出一次問題，遇過硬碟掛掉 (還好有做備份)、一次是主機板壞掉、一次是電源供應器壞掉，每次都會讓郵件服務中斷好幾個小時到好幾天，為此我還特別架設一台 Linux 的 MX 主機負責收那些當我們主機掛掉時的暫時收信管道，其實付出的時間還蠻難計算的。有時候運氣好是在周五晚上掛掉，不會影響公司運作，不過整個周末都在拯救這台 Exchange 伺服器，心情自然不會太好了。
也就是因為這些 IT 工作的隱含成本太高，許多企業主或 IT 人員不是很容易理解，或意識到這些成本支出，我簡單算過我們公司在【郵件服務】開支，真的一點都不低。因為 Exchange 功能非常多，我不可能全心投入 Exchange 管理，也相信大部分中小企業的 IT 也不會對 Exchange 能有多深入的了解、也請不起顧問，因此當公司需要特定功能時，每次都要花上不少學習時間去設定，設定完還不一定正確，會有失誤成本。除此之外，我們有一台 Exchange 主機 (沒有HA)，所以這台 Exchange 軟體授權、該主機的備份軟體 (因為 Mail 是重要服務，所以我有買比較專業的備份工具軟體)、硬體費用 (買組裝電腦節省成本)、主機 24hrs 開機消耗的電費，如果攤提五年的話，每個月大概是兩、三千塊的成本。除此之外，我還在 IDC 另外架設一個備援用的 MX 伺服器，由於我架設的是 Linux 主機，所以只有硬體成本，有些學習與設定的成本，而且不是每家公司都能這樣設定，我是剛好會 Linux + Postfix 才架設起來的。全部加起來之後，總體成本已經高於 Office 365 – Exchange Online 的月租成本！
上述我僅針對【看的見的錢】來做分析，還有許多看不見的隱含成本都還沒計算呢！例如研究設定所花的時間，以及對 IT 工作的「風險」造成的心理負擔成本，我指的風險就是不知道電腦甚麼時候會壞掉，劃掉能不能修、會不會修、找不找的到人問、修理的費用、備份的完不完整、換掉後能不能復原、…等等。
現在，我把這些重要又不緊急 (不出事都不緊急) 的「郵件服務」搬上雲端後，已經無後顧之憂，我知道有一群比我熟悉 Exchange 幾百倍的專家幫我管理 Exchange 主機，郵件也受到標準的服務等級協議 (SLA) 所保障，每個月有 99.9% 的上線保證，當然大部分的情況是沒事的，你幾乎不太會感受到有中斷服務的情況。
企業導入 Office 365 顧問服務
我們近期已經替兩家公司導入 Office 365 雲端平台，所以我接下來會陸續整理一些 Office 365 的管理經驗，有空就會寫成文章分享，如果各位也有興趣嘗試，可以用以下試用連結，申請一個免費 30 天的 Office 365 試用看看，有任何問題都可以留言給我：
>>> 試用 Office 365 的申請連結 <<<
將現有的郵件環境轉上 Office 365 雲端平台是有一點小小的門檻，但轉上去之後就再也不用煩惱了！
如果你們公司需要 Office 365 導入顧問，也可以找我們，基本上諮詢服務都是免費的喔，幫企業分析規劃導入的部分才會有些微顧問費用產生！
相關連結