3/11(土) 13:00より、飯田橋のIIJセミナールームをお借りして第18回のOffice 365勉強会が開催されます。

今回のテーマは ”Identity&Security” Office 365から広がるクラウドの世界とそのセキュリティ対策 ということで、私も話を是非聴きたいと思っていた著名なスピーカーの方々をお招きしてOffice 365とそれを取り巻くセキュリティ関連の最新情報をお話しして頂く予定となっております。

既に満席になっている可能性はありますが、毎回一定数のキャンセルは発生しますので、是非キャンセル待ちに登録を頂ければと思います。

詳細は こちら をご参照下さい。

告知が直前となってしまいまして申し訳ございません。

毎年恒例となりましたMicrosoft主催の開発者＆ITプロ向けのイベントであるde:code 2017に登壇します。

セキュリティトラックの中で「Active Directoryのディザスタリカバリ対策」というテーマで、いざという時にIT基盤のかなめであるActive Directoryをどう守るかについて事例を交えながらお話しできればと思っています。

既にチケットは完売しておりますが、参加される方はぜひ SC03 セッションまでお越し頂ければ幸いです。

皆さん、更新プログラムの適用はどの様に実施されていますか？

直接Windows UpdateサイトやWSUSから更新する、必要な物を事前に配置しておいて手動でスクリプトでインストールするなど環境に応じて色々有るかと思いますが、SCCMから配信をされている管理者の方も多いかと思います。

SCCMから配信する場合、クライアントPCなどはある程度えいやでインストール期日を設定してしまっても良いのですが、適用順序などが決まっている場合に前のサーバ群が終わっているかのチェックをしてからインストールする必要があるなどの理由から、ソフトウェアセンターを開いて手動で適用を実施されているケースも多いのでは無いでしょうか。

大雑把な手順としては以下の様な物となります。

1. 対象サーバにログイン
2. ソフトウェアセンターを起動
3. 左上のチェックボックス（全て）にチェック
4. 右下の[インストール(N)]をクリック
5. 失敗した物が有ったら再度チェックして実行
6. 全部成功したら再起動

数十台のレンジであれば、Remote Desktop Connection Managerなどを利用して沢山リモートデスクトップのウィンドウを開いてポチポチしていけば何とかなるレベルですが、この方法のままでは数百台以上実施するのは難しいですよね。

今回は、この処理を簡略化していきたいと思います。メインとしては「スクリプトから実施」「リモートで実行」という2点となります。SCCMクライアントへは、WMIを使ってアクセスが可能ですので、PowerShellからこれをキックしたいと思います。

Get-SCCMUpdatesStatus

SCCMのソフトウェア更新プログラムの一覧と、現在のインストールの状態を表示する。
引数無しで実行した場合はローカルホストに対して実行、引数有りの場合はそのホストに対して実行する。

function Get-SCCMUpdatesStatus ($hostname){
  if($hostname -eq $NULL) { $hostname = hostname }
  $CCMUpdates = Get-WmiObject -Query "SELECT * FROM CCM_SoftwareUpdate" -Namespace "ROOT\ccm\ClientSDK" -Computer $hostname
  foreach ($CCMUpdate in $CCMUpdates) {
    if($CCMUpdate -eq $NULL) { "No SCCM updates are available for $hostname"}
    else {
      $Output = "Status: "
      $Output += $CCMUpdate.__SERVER
      $Output += " KB"
      $Output += $CCMUpdate.ArticleID
      $Output += " "
      switch($CCMUpdate.EvaluationState){
        0 {$Output += "Available"}
        1 {$Output += "Available"}
        5 {$Output += "Downloading"}
        6 {$Output += "Waiting to install"}
        7 {$Output += "Installing"}
        8 {$Output += "Requies restart"}
        10 {$Output += "Complete"}
        11 {$Output += "Pending Verification"}
        13 {$Output += "Failed"}
        default {$Output += "Unknown"}
      }
      $Output
    }
  }
}

Start-SCCMUpdates

SCCMのソフトウェア更新プログラムの全てをインストールする。
（既に開始済み、もしくは完了している更新プロぐむには影響を与えない。）
引数無しで実行した場合はローカルホストに対して実行、引数有りの場合はそのホストに対して実行する。

function Start-SCCMUpdates ($hostname){
  if($hostname -eq $NULL) { $hostname = hostname }
  $CCMUpdates = Get-WmiObject -Query "SELECT * FROM CCM_SoftwareUpdate" -Namespace "ROOT\ccm\ClientSDK" -Computer $hostname
  foreach ($CCMUpdate in $CCMUpdates) {
    if($CCMUpdate -eq $NULL) { "No SCCM updates are available for $hostname"}
    else {
      $Output = "Starting: "
      $Output += $CCMUpdate.__SERVER
      $Output += " KB"
      $Output += $CCMUpdate.ArticleID
      $Output += " (Status: "
      switch($CCMUpdate.EvaluationState){
        0 {$Output += "Available"}
        1 {$Output += "Available"}
        5 {$Output += "Downloading"}
        6 {$Output += "Waiting to install"}
        7 {$Output += "Installing"}
        8 {$Output += "Requies restart"}
        10 {$Output += "Complete"}
        11 {$Output += "Pending Verification"}
        13 {$Output += "Failed"}
        default {$Output += "Unknown"}
      }
      $Output += ")"
      $Output
      ([wmiclass]"\\${hostname}\ROOT\ccm\ClientSDK:CCM_SoftwareUpdatesManager").InstallUpdates($CCMUpdate) | Out-Null
    }
  }
}

この2つを使ってどこかのサーバから実施すればいいわけです。

例えば、server1,server3,server5に対して実行したい場合は、以下のような感じになります。

1. foreach($hostname in @(“server1″,”server3″,”server5”)) { Start-SccmUpdates $hostname }
   を実行して、リモートでインストールを開始する。
2. foreach($hostname in @(“server1″,”server3″,”server5”)) { Get-SccmUpdatesStatus $hostname }
   を実行して、全部Completeになるのを待つ。（失敗したサーバを見つけたらStart-SccmUpdates を再実行）
3. foreach($hostname in @(“server1″,”server3″,”server5”)) { Restart-Computer -Force -ComputerName $hostname }
   を実行してリモートでインストール

実際の環境に合わせて、更新の前後にフェールオーバーなどの事前作業や再起動後の確認作業などの処理を足していけば良いという形になります。

良いSCCMライフを！

サーバーのアレイコントローラでLSI社のMegaRAIDを採用しているメーカーって多いですよね。

富士通のPrimergyとかは自分でアレイ制御用のユーティリティを被せてますが、それ以外の通常の場合はLSI社標準のMegaRAID Storage Managerとか使ってディレクアレイの状態を取得します。

ただ、GUIだと開くのに時間は掛かりますし、ディスクの玉が多い場合など面倒なので、コマンドラインから一覧で出したい時とか有りますよね。

その場合の為に、コマンドラインツールとしてStorCLIが用意されているのですが、これまた一覧表示するというよりは情報をずらーっと出すだけの感じです。このままだとスクリプトでの条件付き処理をしたい場合などには利用ができない為、PowerShellを使って簡単に整形してみます。

まずは、StorCLIを適当なフォルダ（今回は C:\Program Files\StorCLI）に解凍して、winrm quickconfigでリモートからのコマンド受付を可能にした状態にして、以下のコマンドを実行します。

$status = @()
foreach ($hostname in @("server01","server02","server03")){
  $str = ""
  $i = 0
  $results = Invoke-Command -ComputerName $hostname -ScriptBlock { & "C:\Program Files\StorCLI\storcli64.exe" /c0/eall/sall show all | select-string -Pattern "State :","Media Error Count =","Predictive Failure Count =" }
  foreach ($result in $results) {
    $str += "${result} "
    if($i -gt 1){
      $str += "`n" ; $i=-1
    }
    $i++
  }
  foreach ($drive in $str -split "`n") {
    $data = -split $drive
    if($data -ne "") {
      $status += New-Object PSObject -Property @{Hostname = $hostname ;Drive = $data[1]; MediaError=$data[8]; PDFailure=$data[13]}
    }
  }
}
$status | ? {$_.MediaError -gt 0} | select Hostname,Drive,MediaError,PDFailure

すると、メディアエラーがカウントアップしているディスクのみ一覧が表示されます。

この情報を利用して、例えば単発のメディアエラーだったら無視するが、継続的に再発する場合はディスクの予防保全交換の手配をするなどの準備をすることができますね。

ある日Exchange Server管理シェルを起動しようとしたところ、見覚えの無いエラーで何のコマンドも実行できないようになってしまいました。

「Import-PSSession を使用して現在のセッションのエクスポート モジュールを生成できません。」

特に変更をした直後ではなく、エラーメッセージの内容も良く分かりません。原因が何かを悩んでいたのですが、色々検索をしたところ、2-3日前に実行したWindows Updateが原因であることが分かりました。

発生する条件は以下の通り。

• Exchange Server 2013もしくはExchange Server 2016
• KB3000850を未適用の環境
• 2017年07月以降の月例累積更新プログラムを適用

これを満たしても、一定期間（2-3日？）についてはローカルキャッシュから利用されるために事象は発生しませんは、ふと気がつくと発生するようになります。

その環境ではKB3000850がSCCMから必須と表示されなくなっていたので気づかなかったのですが、後から手動でKBを適用したところ、解消しました。

なお、KB適用前に一時的にコマンドを実施したい場合などは、Exchange管理センター(EAC)からブラウザで実行をするか、以下のコマンドで手動でPowerShellスナップインを追加してコマンド実行が可能です。

Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn

この投稿はOffice 365 Advent Calendar 2017に参加しています。

Office 365ですが、どんどん日々進化しておりE3やE5のSuiteに含まれるサービスも増えていっています。また、今年はMicrosoft 365など、更なるバンドルライセンスも増えてきました。

6年以上前にblogのエントリーを書いた際と比較すると、例えばOffice 365 E3に含まれるパッケージは以下の様にサービス数でいうと3倍以上になりました。

今回は、現時点（2017.12.03）での各ライセンスとそれに含まれるサービスを調査してみました。

調査方法は、ライセンスプラン（SKUとも呼ばれます）と、それに含まれるライセンスプランをGet-MsolAccountコマンドレットを使って調査しました。また、対応する名前は管理者ポータルから確認しています。

結果、以下のリストの通りの出力となりました。

プラン一覧（50個/CSV）Download 2017/12/03更新
サービス一覧（85個/CSV）Download 2017/12/03更新

詳細は以下の通りです。

調査コマンド：

PS C:\> Get-MsolAccountSku

AccountSkuId                        ActiveUnits WarningUnits ConsumedUnits
------------                        ----------- ------------ -------------
nttcom:ENTERPRISEPACK               100         0            81
nttcom:EMS                          100         0            81

PS C:\> Get-MsolAccountSku | ? {$_.SKUPartNumber -eq "ENTERPRISEPACK"} | % {$_.ServiceStatus}

ServicePlan           ProvisioningStatus
-----------           ------------------
BPOS_S_TODO_2         Success
FORMS_PLAN_E3         Success
STREAM_O365_E3        Success
Deskless              Success
FLOW_O365_P2          Success
POWERAPPS_O365_P2     Success
TEAMS1                Success
PROJECTWORKMANAGEMENT Success
SWAY                  Success
INTUNE_O365           PendingActivation
YAMMER_ENTERPRISE     Success
RMS_S_ENTERPRISE      Success
OFFICESUBSCRIPTION    Success
MCOSTANDARD           Success
SHAREPOINTWAC         Success
SHAREPOINTENTERPRISE  Success
EXCHANGE_S_ENTERPRISE Success

まず、300人以下の規模の中小の組織向けに展開されているBusinessプランです。

Office 365 Business(O365_BUSINESS) 月額900円/ユーザー

Office 365 Business Essentials(O365_BUSINESS_ESSENTIALS) 月額540円/ユーザー

Office 365 Business Premium(O365_BUSINESS_PREMIUM) 月額1360円/ユーザー

Microsoft 365 Business(SPB) 月額2180円/ユーザー

Office 365 Business Premium = Office 365 Business + Office 365 Business Essentials

Microsoft 365 Business = Office 365 Business Premium + Intune + AzureAD(SMB専用プラン) + Windows 10

という感じでしょうか。Enterprise向けプランとは内容が少し異なりそうですが、それでも月額2180円/ユーザーは破格の値段だと思います。

続いてはエンタープライズ向けのプランです。

Office 365 ProPlus(OFFICESUBSCRIPTION) 月額1310円/ユーザー

Office 365 Enterprise E1 (STANDARDPACK) 月額870円/ユーザー

Office 365 Enterprise E3(ENTERPRISEPACK) 月額2180円/ユーザー

Office 365 Enterprise E5(ENTERPRISEPREMIUM) 月額3810円/ユーザー

※E5には、電話会議が提供されていない地域向けの Office 365 Enterprise E5 (電話会議なし)(ENTERPRISEPREMIUM_NOPSTNCONF) という物もございます。

Office 365 F1(DESKLESSPACK) 月額440円/ユーザー

Enterprise Mobility + Security E3(EMS) 月額950円/ユーザー

Enterprise Mobility + Security E5(EMSPREMIUM)  月額1610円/ユーザー

Microsoft 365 E3(SPE_E3) 月額3690円/ユーザー

Microsoft 365 E5(SPE_E5) 月額6640円/ユーザー

Microsoft 365 F1(SPE_F1)  月額1090円/ユーザー

EMS = Azure Active Directory Premium + Azure RMS(Information Protection) + Intune

Microsoft 365 = Office 365 + EMS + Windows 10

という感じですね。Microsoft 365 E5とか、全部入りすぎて正直全機能を使いこなすのは至難の業じゃないでしょうか。

他にも、単体で買えるプランや特定のプランのオプションとして買える物も有ります。以下、主要な物だけとなりますが、調査した結果です。

如何でしたでしょうか。

今回、沢山のサブスクリプションを追加・削除したので、随分と汚いテナントになってしまいましたが、これからも定期的にウォッチしていきたいと思います。

今回はちょっとトリッキーなTipsです。

色々なテナントをテストで利用していて、ふと「あれ、この独自ドメイン紐づけていたのどのテナントだっけ」となったり、「あの会社確かOffice 365使っていると言っていたけどテナント（xxx.onmicrosoft.com）どこだろう」…と調べたくなることがあると思います。

こういったときには、Exchangeの管理シェルからGet-FederationInformationコマンドで調べられます。Exchange Onlineに接続し、以下のコマンドを実行してみます。

[PS] C:\>(Get-FederationInformation -DomainName mirogo-shoji.com -BypassAdditionalDomainValidation).DomainNames

Domain
------
mirogo.onmicrosoft.com
mirogo-shoji.com

この例では、mirogo-shoji.com のドメインが紐づけられているテナントは mirogo.onmicrosoft.com だということが分かります。逆の場合（特定の xxx.onmicrosoft.com に紐づけられているのはどんな独自ドメインか）も同様のコマンドで調べられます。

なお、この例では Autodiscover のDNSをきちんとOffice 365用に設定していないと調べられません。

その場合は、ちょっと面倒ですが、Exchange Server（バージョンはいくつでも良いです）を1台立てて、そのサーバ上のHostsファイルに autodiscover.[調べたいドメイン名] を autodiscover.outlook.com のどれかのIP（例えば40.100.154.56）に向けるように設定して、コマンドを実行すれば大丈夫です。

今までと同じポリシーで利用したいということで、Exchange Online で IP アドレス制限を掛けたいという話は良く聞きます。これまでは、AD FSを利用したクレームルールを構成するか、Azure AD Premiumの条件付きアクセスの機能を利用する、あるいはサードパーティのツールを利用するなどして制御するしかありませんでした。

いずれも新規でサーバを立てるなり、追加でライセンスを購入するということでコストの掛かるソリューションでしたが、Exchange Onlineに実装された（現在、まだ全てのテナントで利用可能ではありませんが）クライアントアクセスルールを利用する事により、標準機能としてこれを実装できるようになりました。

Exchange Online のクライアント アクセス規則

また、この機能は現在 AD FS などを利用してIPアドレス制限を掛けている環境においても、その不足する部分を補完する存在になり得ますので、是非この機能は注目して頂ければと思います。

Exchange Online では認証を自身で行わずに Azure Active Directory(Azure AD) で行っています。アクセス制御についてもAzure AD側で実施をしており、認証のタイミングでの条件でアクセストークンが発行されます。トークンのあるユーザーに対しては既定で Exchange Online は無条件でアクセスを受け入れますので、例え、クライアント側でその条件が途中で満たされなくなっても理論上アクセスは継続されます。

簡単なイメージですが、モバイル PC を WiFi で社内 LAN につないで Exchange Online に接続したとします。AD FS を利用して社内からしかアクセスできないように制限をしていたとしても、この PC をそのまま外に持ち出してWiFiをスマートフォンのテザリングなどに切り替えても、アクセスが継続可能です。

これを、クライアントアクセスルールを併用して社内 LAN からインターネットに出ていく際のグローバルIPアドレスのみ許可するような設定をしていた場合、WiFiを切り替えた瞬間に利用できなくなります。

今までは、こういったケースに関しては「社内PCを外に持ち出す」「外で利用するPCを社内LANに接続させる」など別次元のセキュリティリスクの話として片付けるしか無かったのですが、クライアントアクセスルールの併用でそういった穴を塞ぐことができます。

また、注意事項が1つ。

クライアントアクセスルールの IP アドレス制限は、中間層アプリケーション、平たく言えば Outlook for iOS や Outlook for Android など、クライアントからの接続を中継するアプリケーションに関しては機能しません。

まあ、そもそも何処でも使えるモバイル環境に安全に、キャッシュを残さずに利用できるようにという思想の物ですので、社内だけで利用できてもあまり意味は無いですよね。どうしてもクライアントアクセスルールで塞ぎたければプロトコル（REST）ごと塞ぐという感じになるかと思います。

Exchange Online と連携したアプリケーションを利用する際、アプリケーション偽装（ApplicationImpersonation）という特権（管理者権限）を利用するケースが多いです。

これを利用する事により、アプリケーションは自身の権限設定を利用して対象のユーザーになりすましてメールを取得したり、予定表を更新したりできます。

例えば、以下の様なことができます。

1. モバイルアプリケーションがExchange Serverのメールを取得する
2. 会議室有効利用のサービスが会議室の利用情報を取得、更新する
3. メールの移行ツールが各ユーザーのメールボックスの中身を取得する

最近特にExchange Onlineと連携するアプリケーションやサービスが沢山出てきて、その中で利用されています。

導入手順などでは、単純に「①システムで利用するアカウントを作る　②作成したアカウントのパスワードを無期限に設定する　③作成したアカウントにApplicationImpersonationの権限を付与する」などの内容が詳細な手順と共に記載されていることが殆どです。

確かに、アプリケーション開発者の立場からするとそういった記載になるのは理解はできるのですが、Exchange管理者の立場としては、単にアプリケーションを利用するにはこの手順が必要だから…と思考停止せずに、きちんとこれを設定することの意味（リスクを含めた）を理解した上で設定する必要があります。

○権限に対する認識について

この特権は、全てのユーザーに偽装してメールを読み書きできます。つまり、このアカウントが悪用された場合、役員を含む全てのメールボックスの内容を見られてしまいます。

しかも、都合の悪いことに、このアカウントは平常時から様々なメールボックスにアクセスしているため、メールボックス監査のログからも悪用されていること自体が判別することが困難です。

○役割ベースアクセス制御（RBAC）について

権限の付与にはExchangeの役割ベースアクセス制御（RBAC）という物が利用されます。これにより、設定された権限の組み合わせを元にした管理者役割グループの作成や、ユーザーへの権限の割り当てを行います。

この中に、管理役割スコープの設定という項目が有り、これを利用する事によりこの権限が有効な範囲を決定することができます。

例えば、一般社員向けにモバイルアクセスの為の権限付与で必要な場合に、そのスコープに役員を初めとしたモバイルを使わない社員を含めない事により、リスクを最小化することが可能です。

会議室のスケジューラーのアプリケーションには、会議室メールボックスに対する権限のみスコープに含めれば、例え会議室に設置されているKIOSKがハッキングされたとしても、その端末に設定されている権限を利用して社長のメールボックスにアクセスされるというリスクは少なくなります。

○アカウントの棚卸しについて

Exchangeの最上位である組織管理者（Organization Management）の権限については、それが付与されているユーザーについての棚卸しが行われているケースが多いかと思います。

ApplicationImpersonationの権限を持つユーザーに関しても、前述の通り非常に強い特権になりますので、同様にきちんと棚卸しをする必要があります。Get-ManagementRoleAssignment コマンドレットを利用すれば、その権限を付与されているユーザーもしくはグループの一覧が取得できます。（以下、出力例）

PS C:\> (Get-ManagementRoleAssignment -Role "ApplicationImpersonation").RoleAssigneeName
Organization Management
RIM-MailboxAdmins6be8fce7ca594ef89a6175fb7746b304
admin

システムの仕組み上、パスワードの変更が容易でないというケースもあるかと思いますが、それでも不可能では無いと思いますので、メンテナンスなどのタイミングで実施は試みた方が良いと思います。

アクセス元のIPアドレス情報などが取得できる環境であれば、設定したシステム以外からアクセス試行が無いかもきちんと管理しておくとより望ましいですね。

メッセージセンターに通知が来たのでお気づきの方も多いかも知れませんが、Office 365によるTLS1.2暗号化の強制が2018/10/31に延期されました。

比較的急なアナウンスだったので、Office 365管理者の中には大急ぎで対応要否について調査されている方も多かったのでは無いかと思いますが、これで少し期間的な猶予ができましたね。

プリンターやシステムのアラートメールなど、社内ネットワークからExchange Online上にあるユーザーのメールボックスにメールを送信するにはいくつか方法があります。

その中で一番設定が簡単で利用されるシーンも多いのが、MXレコードの向け先と同じ contoso-com.mail.protection.outlook.com などのアドレスにSMTP(TCP/25)で直接送信をする方式となります。

Office 365 を使って、多機能デバイスやアプリケーションがメールを送信するように設定する方法

このケースにおいて、稀にメールが受信できないという事象が発生することがあり、調査してみるとSMTPで送信をしようとした際に4xx番台のエラーが出て失敗したという物です。

詳細なログを確認してみると、以下の様なエラーコードで失敗しています。

451 4.4.0 Message failed to be made redundant due to A shadow copy was required but failed to be made with an AckStatus of Retry

451 4.4.0 Message failed to be made redundant due to A shadow copy was required but failed to be made with an AckStatus of Fail

451 4.7.0 Temporary server error. Please try again later. PRX5

452 4.3.1 Insufficient system resources (ProcessorTime)

452 4.3.1 Insufficient system resources (TSTE)

452 4.3.1 Insufficient system resources (UsedVersionBuckets[D:\Queue])

これらは、いずれもExchange Onlineの接続したサーバ環境が一時的に高負荷であり、接続が許容されなかった（≒再送して下さい）という物で、サポートなどに調査依頼や再発防止などを依頼しても解決しない問題となります。これは複数ユーザーの利用するパブリッククラウドであるExchange Onlineでは不可避の問題です。

これはあくまで私の感覚的な数字ですが、0.1～0.01%の間（数千通に1度）程度はコンスタントに発生していますが、継続して発生するようなことはなく、殆どが次回の再送で送信完了しております。

ここで、SMTPクライアントとして直接Exchange Onlineに送信しているような物だと、ソフトウェアの作りによっては再送を行う事はせず、一度の送信失敗でそのまま異常終了してしまうケースがあります。

この場合、そのメール自体がロストしてしまうという自体になってしまいます。この為、届かないと困る重要なメールをExchange Onlineに送信する場合は、

1. きちんとエラーコードを判別して4xx番台の一時的なエラーだった場合は再送する
2. アプリケーションは、ローカルやネットワーク内のSMTPサービス（PostfixやSendmailなど）に投げ、そちらできちんと再送制御を行った上で送信する

のどちらかの解決策をとることを強く推奨させて頂きます。

年度明け最初の週末に向けた2018/4/6(金)の夕方、比較的広い範囲のOffice 365の一部テナントでログインに関連する障害が発生しました。

幸か不幸か、私の個人用のテナントや会社で使っているテナントは影響を受けていなかったのですが、色々と気づくことも有ったのでメモ代わりに記しておきたいと思います。

一番最初に気がついたのは、17:36にFacebookのOffice 365コミュニティに書き込まれた書き込みでした。（ちなみに、このグループは2018年4月現在1600名以上の参加者のいる私の知る限り日本最大のOffice 365ユーザーコミュニティです）

クラウドサービスの障害の対応を考えるときに最初にやることはその事象が自分だけなのか、他のテナントもなのかの切り分けです。こういった時にFacebookコミュニティは非常に有用です。1回書くと、恐らく数十のテナントで同様の障害が発生しているかどうかを参加者の方がテストしてくれると思います。

サービス正常性ダッシュボードを最初に見るように言われたり、いきなりサポートリクエストを送信するようにしているケースも有りますが、以下の様な問題点があるので、迅速な対応をしたい場合は自力でのある程度の切り分けを推奨します。

1. サービスの障害としてMicrosoftが認識するトリガーは、複数のユーザーからの同様の障害申告（よって、テナント固有の問題は除外されるし、少しタイムラグがある）
2. そもそもログインしないと見れないサイト上にサービス正常性が表示されている
3. 通常のサポートリクエストの手順は管理者としてログイン後の物であり、電話番号や契約情報をメモっていない限りは電話での依頼はできない

そうこうしているうちに、他のユーザーから 17:40にも同様の書き込みが行われ、どうやら障害っぽような雰囲気になってきました。Twitterでも検索すると同様の書き込みが散見され出しました。日本以外のAPACやオセアニアからも同様の書き込みがされています。

この辺のサイトでヒートマップとかも表示されていて参考になりました。
Outage Report

また、エラーの発生しているユーザーからの情報で、エラーの内容は、[フェデレーションドメイン名はシステムに存在しません][サブスクリプションが見つかりません]などという物。かなり根が深そうな印象でした。

さて、皆さんご承知の通り、JapanやAustraliaはOffice 365的には Go Local というGeoであり、APACのAzure ADの張り出しみたいな形で実装されています。この為、この時点でAPACのAzure ADがおかしいのかな、と思い始めます。

注）後にEU側からも同様な報告が来ていたので、たまたまタイムゾーン的な話でAPACの報告が多かったようです

たまたま今回の障害はログイン出来るテナントがあったので確認をしたところ、サービス正常性ダッシュボードに障害の情報が掲載されていたことを確認。この時点で発生時から既に1時間ほど経過していましたが、まだ原因が特定されていなかったので、結構時間が掛かってるなという印象。

ここまで来ると、もう各ユーザーテナント側でできることはありません。社内向けに何か情シスが求められたとしても

『Office 365で、アジアを中心に一部のテナントでログインできないという障害が発生中。Microsoft側の対応を待っています。』

程度流しておくしかできないです。回復見込みはいつだ、定期報告しろ、根本原因は？とか騒ぐような方がいるような組織の場合はご愁傷様です、ユーザ側にこれ以上できることは根本的には無いのです…。

そうこうしているうちに20:08頃よりサインインできるようになったとか、サインイン出来るけどTeamsはまだとかそういった情報が流れるようになって来ました。20:30頃には大体収まったような感じでしょうか。

平行して、TwitterではMicrosoftの公式アカウントである Office 365 Status から状況の報告が出てました。今回の場合、サービス正常性ダッシュボードが確認出来ないので、こう言った広報手段というのは普段から確保しているのでしょうね。ちなみに、18:18初報、20:53終了報なので、少しタイムラグが有りそうです。

今後もこのアカウントでの告知は平行して行われるようですので、フォローしていない人はフォローしておいた方が良いかもしれませんね。

というわけで。実質3時間ほど一部テナントに影響するインシデントが発生したわけですが、認証系というかなり根が深い部分で障害だったにも関わらず、障害の認識から回復までの時間は短い方だったと思います。

PIR（事後インシデントレポート）を見る限りは根本原因はメンテナンス作業に伴う設定ミスですが、直そうとしている方向性が「①例え設定ミスしても検知できるトレンド分析」「②ユーザーからの申告より先に障害に気付ける仕組み作り」であるのは、同じクラウドサービスのサービス提供事業者として個人的に好感が持てました。

どうしても日本の企業だと、「なぜユーザー通知無しでメンテナンスを行うのか」「なぜまだ業務時間内なのにメンテナンスするのか」「そもそも何で設定ミスしたのか」などというユーザーからの直の声をそのまま対策にも反映させてしまいがちですが、正直そんなところはもう何百何千と考えて品質向上を実行してきたのでしょうからね。

Azure Infrastructure as Code 隊 Terraform Bootcampに参加してきました。

（当日の資料はこちら）

会場は渋谷のヒカリエの8階にあるAzure Antenna、こんな格好いいフロアの奥の方にあります。スケジュールが提示されているので見てみると、何と、通年でここのスペースを借りているようです。（成果が出るかどうかで続くかどうかが決まるそうなので、是非これからも色々と活用していきたいと思います）
　 

4名掛けのテーブルが2つ。こんな感じの場所でMicrosoftの真壁さんのハンズオンという、何とも贅沢な内容でした。

さて、ここから本題。

私自身はTerraformはマルチクラウド対応のInfrastructure as Codeのツールとして、回りで使っている人がいるので、「概要くらいは知っているけど使った事は無い」という感じでした。自分的にもなかなかこういったハンズオンとか無いと触るきっかけがないので、今回のハンズオンは正に渡りに船という感じでしたので、案内を見た瞬間に申込みをさせて頂きました。

ハンズオン受講前はTerraformに対する印象として「便利そうだけど、本当に商用で本格的に使っていって大丈夫なのだろうか…」という漠然とした不安を頂いておりましたが、受講後の感想は…

絶対来る、間違いない。
AzureのIaaSのエンジニアとしては習得必須の技術。

まあ、理由はあの真壁さんが言っているのだから…という一言に尽きるのですが、少しだけ言うなら以下の理由により、今後Azure管理のデファクトになっていくだろうな、と感じました。

• マルチクラウド環境実現できるOpen Sourceだが、AWSとAzureはかなり動きが活発
• Cloud Shellを立ち上げるだけで認証が済んだ状態でTerraformが使える
• HashiCorpの日本法人もできて、Microsoftとも協業を発表している
• ARMからTerraformリソースプロバイダ経由でAzure外のリソースをいじれるなど連携している

ちなみに、「ファイルの分割規則」「ARMテンプレートとの使い分け」「認証方式は？」とか、色々選択肢がある中でどれを選択すれば良いのかという疑問に関しては、ほとんどがスライド中で述べられていました。

真壁さん自身も、日本語のまとまった情報が殆ど無く、この資料を作成していく中で自分の中でも色々と整理することができたというコメントが有ったのですが、本当にTerraformはまとまったドキュメントが少ないので、当日のスライドはとても有意義な内容でした。

既に間に合っていない感はあるのですが、このサイトを常時SSL化させました。

SSL証明書は、Let’s Encrypt 使ってみようかなとも思ったのですが、更新が面倒なので商用の2年物を買ってきました。前に使っていた所がカード決済できなくなってしまったので、https://www.e-ssldirect.com/  でComodoのPositive SSLを2年1,842 円で調達しました。

設定自体は、さくらインターネットのWordPressなので、サイトにSSL証明書をインストールしてSNIで/wpに割り当て、WordPressのさくらインターネットの常時SSL化プラグインを有効化させるだけで簡単にできました。

一箇所だけ、プラグインの有効化の時に最初

重大なエラーを引き起こしたため、プラグインを有効化できませんでした。

と表示されて有効化できなかったのですが、きちんとFAQサイトにPHPのバージョンが古いためという記載があり、バージョンアップして対応できました。

いつもお世話になっている北端さん、太田さんと共著させて頂いた書籍「Office 365管理者のための逆引きPowerShellハンドブック」が11/15に発売されることになりました。

コマンドの説明であればオンラインヘルプや Technet を見れば十分に事足りると思い、サンプルスクリプトなどもなるべく実務よりで Tips が多くなるように書きました。

書き切れなかったことや補足、訂正したいことなども今後色々出てくると思うので、内容については今後この Blog 内でフォローしていきたいと思っていますので、こちらも参照いただければと思います。

11/5-7 の Tech Summit 2018で先行販売されるとのことですので、イベントに参加される方はよろしければ手に取ってみて下さい。

11/23に開催された第23回Office 365 勉強会に登壇しました。

今回のテーマは「O365勉強会的、AzureAD勉強会」。主催者メンバーの中での企画段階では、色々とBlogでお世話になっていて、今年Microsoft MVPになった @Miya_Microsoft さんにOffice 365勉強会に来て貰いたいというのが最初で、以前そういえば国井さんの事をインスパイアしてたなぁ…と思い、2人セットでブッキングできそうなテーマとして選びました。（毎回ではないですが、結構ユルい感じでテーマ決めとかしてます）

当日の様子はこちら : 第23回 Office 365 勉強会 #o365jp まとめ

私のセッションでは、「Azure ADのテナント設計」ということで、Office 365管理者としてはおそらく意識せずに使っているAzure ADのテナントについて、今後AzureやD365などの他のサービスが利用するようになってきた場合にも、どうしていったら良いかきちんと考えられるよう、注意事項や指針などについて話をさせて頂きました。

アンケートなどでも良い反応を頂けたようですので、またこのBlogなどでもこの辺の話題について詳細やアップデートなど発信していければと思っています。

この blog は Office 365 Advent Calendar 2018 に参加しています。

Office 365の管理者アカウントの利用に多要素認証を検討されている（もしくは既に実装済み）というユーザーは多いかと思います。

現状、Microsoftでは利便性を重視してスマートフォンでのアプリケーション Microsoft Authenticator を利用したアプリ通知による認証を推していますが、環境によっては利用が難しいケースがあります。

そもそもBYODが認められていない組織での利用（Authenticatorを入れた自分のスマートフォンを業務利用できない）であったり、管理用端末がセキュリティ管理エリアにあってスマートフォン自体が持ち込み不可のような場合です。

私も、委託を受けてお客様の導入を支援したり運用を代行することがあるのですが、その際はお客様環境のルールに応じた対応をしなくてはなりません。作業場所でスマートフォンを持ち込めるか、直通の電話が受けられる固定電話があるかどうかなどを事前に調整するのも限度があるので、最近はAuthenticatorの他にハードウェアトークンも併用するようにしています。

ハードウェアトークンも色々と使える物が増えてきてますが、個人的に一番使い勝手が良い（専用のAuthenticatorのインストールが必要だが、ユーザー側作業のみで設定可能、電池交換が不要など）のでYubiKeyを使っています。

現在日本で簡単に購入できる物は YubiKey 4かYubico Security Key by Yubicoですが、今回紹介する方法で利用できるのは YubiKey4 の方のみです。

それでは、YubiKey 4での Office 365 への多要素認証の設定について紹介します。まずは、ワンタイムパスワードを生成するためのアプリケーション Yubico Authenticator をYubicoのページからダウンロードしてインストールします。

インストールが完了して起動すると、こんな画面になります。

続いて、認証する Azure AD 側での設定です。うまくQRコードを読み込めない事があるので Yubico Authenticator を起動した状態でブラウザを開き、Office 365にログインし、右上の顔写真のところから [マイアカウント]を選択し、[セキュリティとプライバシー] – [追加のセキュリティ検証]を開き、[アカウントのセキュリティに使用する電話番号を更新します]をクリックします。

現在登録されている多要素認証の要素の一覧が表示されますので、[認証アプリまたはトークン]にチェックを入れ[Authenticatorアプリの設定]をクリックします。（※なお、初回のアクセスの場合は、最初から登録を促される画面が表示されます）

Microsoft Authenticatorに登録する際と同じ画面が表示されます。ここで表示されるQRコードは、既定であるアプリケーション通知の設定になりますので、QRコードの横にある [通知をオフにしてアプリを構成] をクリックします。

これで、Yubico Authenticator が設定できるQRコードが表示されます。

続いて、PCのUSBインターフェイスにYubiKey を差し込みます。
Yubico Authenticator の [No YubiKey detected.] の表示が [No credentials found.]に変わります。

画面にブラウザのQRコードが表示されている状態で [File]メニューから[Scan QR Code…]を選択します。

上手く読み込めると、以下の様にアカウント名と Security keyなどを含めたワンタイムパスワード生成用の情報が Yubico Authenticator に表示されます。[Save credential] を押すとYubiKey にこれらの情報が書き込まれます。（読み込めなかった場合は、再度ブラウザを起動し直すか、画面に表示されている内容を参考に手動で [New credential] で構成することもできます）

OTP生成用の情報が保存されると、Yubico Authenticatorには次のような6桁のパスワードと残り時間を示す緑色のバーが表示されるようになります。

なお、前の登録画面のところで[Require touch]のチェックボックスを付けると、Yubico Authenticator上では通常時アカウント情報のみ表示されるようになります。

OTPを表示させるには、アカウント名をダブルクリック、または[Edit]メニューもしくは右クリックから[Generate code]を選択します。画面に [Touch your YubiKey to generate the code.]とダイアログが表示されている間にYubiKey本体の金色の y の部分を物理的に触ることにより表示されます。

これにより、多少手順は面倒になりますが、[物理的にハードウェアトークンを持っている]ということが証明され、より強固な多要素認証を保証することが可能です。（例えば、YubiKeyが差し込まれたままのPCにリモートデスクトップで接続して表示させたのではないと証明できる）

元のブラウザに戻り、[次へ] を選択します。[確認が必要です] と表示されるので、[今すぐ確認] をクリックします。

確認コードを入力する画面になりますので、Yubico Authenticator に今表示されている6桁の確認コードを入力します。

これで認証アプリの欄に新しい物が追加されました。既定の確認オプションが変更されるので、必要に応じてアプリの通知に戻します。[認証アプリ] の横にデバイス名が表示されないことからも推測できるかと思いますが、Yubico Authenticator はモバイルのMicrosoft Authenticatorと違ってデバイスが固定ではなく、可搬性があります。

ワンタイムパスワードの生成に必要な情報は YubiKey 側に格納されているので、どの端末でもYubico Authenticatorがインストールしてあれば特に追加で設定する必要無く利用できます。

YubiKey を忘れた場合や無くした場合に代替できるように、通常は電話番号での認証、もしくはスマートフォンのMicrosoft Authenticatorなども合わせて設定しますが、最も強いレベルの保護はもう1本 YubiKeyを設定しておいて、合鍵として利用することが推奨されています。

こういった運用フェーズでの話も、また別の機会に少しまとめて書きたいと思います。

また、Security Key by Yubico（青い方）で FIDO2を使ったWindows 10 / Azure ADへのパスワードレスログインなどもそろそろ登場してくる予定のようですので追って紹介していきたいと思います。

以前の投稿で紹介したように、Yubikey (+ yubico Authenticator)による登録は各ユーザーがセルフサービスで実施することができて、気軽に利用できます。

しかしながら、この手順は一般ユーザーにとっては若干複雑です。また、いくつか問題が発生する可能性のあるポイントもあります。例えば、以下の様な物です。

• 画面に秘密鍵やログインIDを含む情報が直接表示されているため、ショルダーハック（覗き見）により悪意ある人間に合鍵を作られる可能性がある
• 同じ秘密鍵を複数のトークンに設定することが可能なので、作ってることをIT管理者側に知られずに本人が意図的に合鍵を作ることもできる
• 紛失時のために複数のYubikeyを登録した場合でも、一覧からは「認証アプリ」としか表示されず、無くしたYubikeyだけではなく全ての秘密鍵を無効化して再設定する必要がある

今回は、こうした要求に応えるため管理者側で一括して登録する方法について説明します。（本機能は執筆時においてプレビュー機能の為、変更になる可能性があります）

まずは、登録する情報を収集します。最低限必要な情報は UPN と 秘密鍵、組織内で重複しないトークンのシリアル番号です。以下の形式のCSVとして保存します。

upn,serial number,secret key,timeinterval,manufacturer,model

秘密鍵はBASE32（大文字小文字区別無しのアルファベットa～zと区別のつきづらい0と1を除いた2～7の数字）32桁で構成されます。パスワードジェネレーターで生成しても良いですが、BASE32に対応したジェネレータというのも少ないのでPowerShellで生成してしまうのが楽だと思います。

PS C:\> 1..32 | % { $randkey += $(Get-Random -InputObject a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,q,r,s,t,u,v,w,x,y,z,2,3,4,5,6,7) }
PS C:\> $randkey
5wj2v7ywvrxj7fm5lpwvnm7mplcuwil4

シリアル番号は、YubikeyはUSBコネクタの金属面ではない方に小さく7桁の数字が刻印されています。

ただ、システム上は重複さえしなければ何を振っても問題ありません。小さくて見えづらいですし、削れて消えやすいのでテプラなどで独自の物を振っても良いかもしれません。これらの情報を元に、以下のようなCSVファイルを作成します。

upn,serial number,secret key,timeinterval,manufacturer,model
genkiw@mirogo.onmicrosoft.com,8578003,5wj2v7ywvrxj7fm5lpwvnm7mplcuwil4,30,yubico,YubiKey4

この情報を ①Azure AD　②YubiKey のそれぞれに登録します。まずはAzure ADからです。作業はAzureポータルから実施します（そのテナントにAzureのサブスクリプションは無くても作業は可能です）。Office365で利用している管理者のアカウントで https://portal.azure.com/ にアクセスします。

[Azure Active Directory]のメニューを開き、[MFA]をクリックします。

[OATHトークン]を開き、[アップロード]を選択し、先ほど作成したCSVファイルをアップします。（合鍵を作れてしまう秘密鍵の情報が含まれてます。CSVファイルはアップロードが成功したら確実に消去しましょう）

しばらく待って[更新]を押すと、登録が完了し、CSVファイルのトークンが一覧に表示されます。
（エラーが発生しましたと表示されることがありますが、詳細を開いて、[成功]になっていれば特に動作に問題はないので無視して進みます）

最後に [アクティブ化] を実施するのですが、その前にYubiKey側に登録します。Yubico AuthenticatorのGUIからちまちま入力しても良いですが、管理者が一括で実施する場合はCLIツールで実施した方が簡単なので、そちらの手順を紹介します。

まずは、YubiKey Manager をダウンロードしてインストールします。この中に含まれる ykman.exe というツールを利用します。

先ほどの情報に組織名（任意です）、発行者としてMicrosoftを入れて以下のようにコマンドを実行します。

PS C:\> cd 'C:\Program Files\Yubico\YubiKey Manager\'
PS C:\Program Files\Yubico\YubiKey Manager> .\ykman.exe oath uri 'otpauth://totp/ミロゴ商事:genkiw@mirogo.onmicrosoft.com?secret=5wj2v7ywvrxj7fm5lpwvnm7mplcuwil4&issuer=Microsoft'

これで、YubiKey側にOTPを生成するための情報が書き込まれ、Yubico Authenticatorを開くと認証コードが表示されるようになります。

Azureポータルに戻り、先ほど登録した情報の右側の [アクティブ化] をクリックして、その時点でYubico Authenticatorに表示されている確認コードを入れます。

アクティブ化の欄にチェックが入り、登録完了です。

ユーザーからの追加のセキュリティに関する画面は以下のようになります。

• 利用開始するにあたり、ユーザー側での操作は必要ありません
• 製造者やシリアルが明示され、複数存在していても識別しやすいです
• 自身で[削除]はできず[無効化]のみ可能で、実施すると非アクティブ状態になります。削除（もしくは再アクティブ化）は管理者がOATHトークンの画面から実施します。

キー自体を会社からの貸与とする場合など、組織の運用や習熟度に合わせて、セルフサービスでの追加と使い分けていくと良いと思います。

YubiKeyでの運用で気を付けなければならないのは、キー自体を忘れたときの管理です。代替の方式として個人のスマートフォンでの電話やMicrosoft Authenticatorや固定電話などが設定できる環境であればそれで代替してもいいですが、今回はセキュリティの強度が高いとして推奨されている予備のYubiKeyを用意する方法について、どう利用するかの例を紹介します。

もちろん、各個人に2個ずつ YubiKey を配布し、一つは会社の机の中に入れておくなども可能かと思いますが、5000円程度するデバイスなので数がまとまると結構な「合鍵」代となってしまい、二の足を踏んでいるところをよく見かけます。

ただ、ここで合鍵代をケチったばかりに職場へのスマートフォン端末持ち込みを許可させたりというのも本末転倒ですよね。

そこで運用上の節約術なのですが、共通で合鍵を用意します。ちょうど、総務がロッカーや袖机の合鍵の束を管理してたりする事の YubiKey 版と思えばいいと思います。

YubiKeyは1本に複数の認証情報を保持できます。例えば、YubiKey 4では32個のOATH認証情報を保持することができます。つまり、1アカウントあたり 5000 / 32 ≒ 156円ほどで合鍵が作れることになります。

これくらいの値段であれば万が一のために作っておいて、IT管理部門や各部門の管理者などに預けておいても良いですよね。

作り方は、基本的には 以前の記事 と同じです。まずは、管理者が一括登録用のCSVを作成します。まずは PowerShell で必要な個数分の秘密鍵を生成します。例えば、32個生成するのであれば以下のようにします。

1..32 | % {
	[String]$randkey = ""
	1..32 | % { $randkey += $(Get-Random -InputObject a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,q,r,s,t,u,v,w,x,y,z,2,3,4,5,6,7) }
	$randkey
}

これを元にこんな感じのCSVを作成します。シリアル番号は重複できないので、適当に末尾にS00の通番を入れています。

これを Azure ポータルからアップロードします。

続いて、YubiKeyへの登録用のコマンドを作成します。合鍵を利用した際に他の人のOTPが見えてしまうのも何となく気持ち悪いので、 -t オプションをつけてこんな感じの物を作ってYubiKeyのコマンドラインツールを実行します。

.\ykman.exe oath uri -t 'otpauth://totp/ミロゴ商事:10101@mirogo-shoji.com?secret=54fuwns7bwoybvfdjpmpfnr4vwggplxm&issuer=Microsoft'
.\ykman.exe oath uri -t 'otpauth://totp/ミロゴ商事:10102@mirogo-shoji.com?secret=bl46n3bd3ypsuryaiblsovsuxp53zotv&issuer=Microsoft'
.\ykman.exe oath uri -t 'otpauth://totp/ミロゴ商事:10103@mirogo-shoji.com?secret=cafqhec7cflb265sn2ugkt2ae2gyvcti&issuer=Microsoft'
…

これを実行すると、Yubico Authenticatorに32個の認証情報が表示されます。他のユーザーのOTPも見ようと思えば見えますが、あくまでID/PASSを入力した後の＋αの2要素目として利用しているので、セキュリティ上のリスクは、代替手段を会社の固定の内線電話とした場合と比べても高くありません。

最後に、これら32件それぞれのアカウントに対して、このキーを1個1個 [アクティブ化]していきます。 -t をつけているので、Yubico Authenticatorでキーを表示させる際には都度金属部分をタッチします。

面倒ですが、初回のみ頑張って実施して下さい。ユーザー数が多い場合はうまく検索やフィルタを使って作業するとやりやすいと思います。

他にもこんな運用上の工夫があるよ、などあったら教えて貰えると嬉しいです。

Office 365やAzureとインターネットを経由せずに接続できる Express Route ですが、料金プランは無制限データプランを選ばれてますか？　それとも従量制課金データプランですか？

私の知っているユーザーですと、9割以上が無制限データプランを選択されているように感じます。主な理由としては「従量制だと料金がいくら課金されるか分からないし、試算するにも実際にどれくらいデータ転送量が分からない」「毎月課金がぶれると予算措置をするのが大変」というケースがほとんどです。

ただ、敢えて私は個人的に従量制プランの方を強くお勧めさせて頂きます。理由は主に以下の3つからです。

1.使ってみると、単純に従量制の方が圧倒的に安くなる（ことが多い）

もちろん、アプリケーションの種類や使い方、ユーザーの就労形態によってブレはあると思うのですが、概ねユーザートラフィックの平日における波形は以下に近似します。青がダウンロード【課金】、赤がアップロード【非課金】のトラフィックとなります（Exchange Client Network Bandwidth Calculatorより）

この時、最頻時の10時台のトラフィックを100%とすると、1日の平均トラフィックは約31%程度になります。また、これは平日の波形になりますので、働いている人が少ない休日に関しては日中帯トラフィックは限りなく0に近づく形となります。

日本企業の平均の年間休日は120と言われていますので、1年365日中の120日は平均が多く見積もっても10%以下の利用となり、年平均では (245*31+120*10)/365 で24%程度に落ち着きます。

さて、ではExpress Routeでは平均でどれくらいの帯域を利用すれば得になるのでしょうか。日本の場合はゾーン2の区分になるので、下り方向のトラフィックに 5.6円/GB の従量課金となります。

この為、帯域毎の無制限データプランがオトクになる利用率は以下の表の通りになります。

帯域が大きいほど損益分岐の割合が下がる傾向にありますが、それでも51%です。仮に、従量制で30%の利用率（上記の通り、これでも想定をかなり超える利用量ですが）だったとして、以下の違いが出ます。

1Gbps従量制：598,113 (48,832+5.6*326,953*30%)　/　1Gbps無制限：974,400

これだけ差が出ると、余った予算で一つ上の回線帯域に変更したり、BCP対策でDRサイト側（西日本）にもゲートウェイ作ったりなど色々できますね。

2.平均利用率が無制限を超えるような環境は、そもそも帯域設計が間違い

それでも、想定より多くのトラフィックが出た場合に無制限プランを大きく超えるような課金になってしまうという懸念ですが、それは杞憂です。

そもそもそんなに常時帯域が出るような環境の場合、帯域設計が誤っており回線帯域が足りていません。

そんな状態ですと回線が一杯で、ユーザー影響が出て使い物にならないような状態になっている可能性が非常に高く、従量制にせよ無制限にせよ、より上のプランを選択する必要があります。

3.無制限データプラン、使ってみると全然月額定額じゃない

サイトを見ると、Express Routeの無制限データプランの料金は月額いくらという記載しかないですし、月額固定に見えます。

ただ、実際に使ってみると毎月の請求額がブレます。理由は主に3つあります。

• 月額は変わらないが、実際は毎日の利用量が 0.03225816 ずつ消費されていき、31暦日ある月だとほぼ1（0.03225816 * 31 = 1.00000296）になるが、30暦日の月は0.97程度の消費となる。※注：この値は度々変わります
• 課金システム上の問題か、上記ロジックで1を若干オーバーしている補正のためか、必ず月に1日以上消費量が上記より若干少ない日が出る。何日なのか、数値はなどは不定
• 課金の締めの最終日の課金は24時間分フルには行われず、翌月の請求に回ることがある。回らないこともあれば、10時間分翌月に回ることもある。何時間分回るかは不定

Azure Chinaのサイトなどには *Monthly price estimates are based on 744 hours of usage per month. などと注記があるのですが、Azureグローバル側には説明ありません。

おそらく、Express Route は月の途中で増速したり従量制から無制限へのプラン変更がオンラインでできるので、その日割処理を実施するために課金システム上は月額ではなく分課金/時間課金に近いような仕組みで実装されているのだとは思いますが、ちょっと分かりづらいですね。

結論：大部分の環境では従量制が良い

ただ、どうしても心配な場合は一度従量制で開通させて転送量をウォッチしましょう。日の平均利用が0.7など非常に大きく、土日や夜間もかなり多くのトラフィックが発生しているような環境と判断したら無制限に変更しましょう。

従量制から無制限へはオンラインで変更できますが、逆はできない（廃止新設処理）ですので、最初だけは従量制でやっても遅くは無いと思います。