年度明け最初の週末に向けた2018/4/6(金)の夕方、比較的広い範囲のOffice 365の一部テナントでログインに関連する障害が発生しました。
幸か不幸か、私の個人用のテナントや会社で使っているテナントは影響を受けていなかったのですが、色々と気づくことも有ったのでメモ代わりに記しておきたいと思います。
Author Archives: genkiw
Exchange Onlineへのシステムメール送信
プリンターやシステムのアラートメールなど、社内ネットワークからExchange Online上にあるユーザーのメールボックスにメールを送信するにはいくつか方法があります。
その中で一番設定が簡単で利用されるシーンも多いのが、MXレコードの向け先と同じ contoso-com.mail.protection.outlook.com などのアドレスにSMTP(TCP/25)で直接送信をする方式となります。
Office 365 を使って、多機能デバイスやアプリケーションがメールを送信するように設定する方法
このケースにおいて、稀にメールが受信できないという事象が発生することがあり、調査してみるとSMTPで送信をしようとした際に4xx番台のエラーが出て失敗したという物です。
Office365のTLS1.2の強制が延期されました
メッセージセンターに通知が来たのでお気づきの方も多いかも知れませんが、Office 365によるTLS1.2暗号化の強制が2018/10/31に延期されました。
比較的急なアナウンスだったので、Office 365管理者の中には大急ぎで対応要否について調査されている方も多かったのでは無いかと思いますが、これで少し期間的な猶予ができましたね。
Exchange Online のアプリケーション偽装権限
Exchange Online と連携したアプリケーションを利用する際、アプリケーション偽装（ApplicationImpersonation）という特権（管理者権限）を利用するケースが多いです。
これを利用する事により、アプリケーションは自身の権限設定を利用して対象のユーザーになりすましてメールを取得したり、予定表を更新したりできます。
例えば、以下の様なことができます。
- モバイルアプリケーションがExchange Serverのメールを取得する
- 会議室有効利用のサービスが会議室の利用情報を取得、更新する
- メールの移行ツールが各ユーザーのメールボックスの中身を取得する
最近特にExchange Onlineと連携するアプリケーションやサービスが沢山出てきて、その中で利用されています。
クライアントアクセスルールによるIP制限
今までと同じポリシーで利用したいということで、Exchange Online で IP アドレス制限を掛けたいという話は良く聞きます。これまでは、AD FSを利用したクレームルールを構成するか、Azure AD Premiumの条件付きアクセスの機能を利用する、あるいはサードパーティのツールを利用するなどして制御するしかありませんでした。
いずれも新規でサーバを立てるなり、追加でライセンスを購入するということでコストの掛かるソリューションでしたが、Exchange Onlineに実装された（現在、まだ全てのテナントで利用可能ではありませんが）クライアントアクセスルールを利用する事により、標準機能としてこれを実装できるようになりました。
Exchange Online のクライアント アクセス規則
また、この機能は現在 AD FS などを利用してIPアドレス制限を掛けている環境においても、その不足する部分を補完する存在になり得ますので、是非この機能は注目して頂ければと思います。
ドメインとAzureADテナントの紐づけを調べる
今回はちょっとトリッキーな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）に向けるように設定して、コマンドを実行すれば大丈夫です。
Office 365プロダクトのサービス一覧を調べる
この投稿は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更新
詳細は以下の通りです。
更新プログラム適用後EMSが起動しない
ある日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
MegaRAIDのディスクのエラーカウントを取得する
サーバーのアレイコントローラで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
すると、メディアエラーがカウントアップしているディスクのみ一覧が表示されます。
この情報を利用して、例えば単発のメディアエラーだったら無視するが、継続的に再発する場合はディスクの予防保全交換の手配をするなどの準備をすることができますね。
PowerShellからSCCMの更新を開始する
皆さん、更新プログラムの適用はどの様に実施されていますか？
直接Windows UpdateサイトやWSUSから更新する、必要な物を事前に配置しておいて手動でスクリプトでインストールするなど環境に応じて色々有るかと思いますが、SCCMから配信をされている管理者の方も多いかと思います。
SCCMから配信する場合、クライアントPCなどはある程度えいやでインストール期日を設定してしまっても良いのですが、適用順序などが決まっている場合に前のサーバ群が終わっているかのチェックをしてからインストールする必要があるなどの理由から、ソフトウェアセンターを開いて手動で適用を実施されているケースも多いのでは無いでしょうか。
大雑把な手順としては以下の様な物となります。
- 対象サーバにログイン
- ソフトウェアセンターを起動
- 左上のチェックボックス（全て）にチェック
- 右下の[インストール(N)]をクリック
- 失敗した物が有ったら再度チェックして実行
- 全部成功したら再起動
数十台のレンジであれば、Remote Desktop Connection Managerなどを利用して沢山リモートデスクトップのウィンドウを開いてポチポチしていけば何とかなるレベルですが、この方法のままでは数百台以上実施するのは難しいですよね。
今回は、この処理を簡略化していきたいと思います。メインとしては「スクリプトから実施」「リモートで実行」という2点となります。SCCMクライアントへは、WMIを使ってアクセスが可能ですので、PowerShellからこれをキックしたいと思います。