クライアントアクセスルールによるIP制限

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

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

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

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

Continue reading

ドメインと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更新

詳細は以下の通りです。

Continue reading

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

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

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

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

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

Continue reading

de:code 2017に登壇いたします

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

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

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

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

第18回 Office365勉強会が開催されます

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

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

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

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

 

CSPパートナーがユーザーのAzureテナントにPowerShellで接続する

CSPパートナーがテナントを新規作成してAzureサブスクリプションを払い出した場合、CSPはユーザーテナントに対する代理管理者の権限を与えられます。この権限により、CSPはユーザーテナントの全体管理者として各種作業を代行することができます。

パートナーポータルからAzureポータルやOffice 365ポータルにも接続することができますが、PowerShellからも接続ができます。

通常アカウントと同じように、Login-AzureRmAccountでログインした後、Select-AzureRmSubscriptionにTenantIDとSubscriptionIDを指定しただけだと、Your Azure credentials have not been set up or have expired, please run Login-AzureRmAccount to set up your Azure Credentials.とエラーが表示されてしまいます。

よくよく見ると、Select-AzureRmSubscriptionの結果のContextにSubscriptionIDは入っていますが、SubscriptionNameが入っていないですね。正しく接続先の情報が渡せていないことが分かります。ここは、

Get-AzureRmSubscription -TenantId $TenantID -SubscriptionId $SubscriptionID | Set-AzureRmContext

としてあげれば、正しく接続することができるようになります。

web.configをPowerShellから変更する

Exchange Server 2013/2016では、これまでのバージョンと同じく細かいカスタマイズを行う場合やバグフィックスの為にweb.confgを直接書き換えるというシーンが比較的あります。

例)
クライアント固有のメッセージのサイズ制限を構成する
MSExchangeApplicationLogic Event 3018 in Exchange Server 2013
Exchange Server 2013 doesn’t display all OUs when it creates a new mailbox
Using security groups to set calendar permissions does not work in an Exchange resource forest

しかしながら、こちらのファイルはCUを適用する度にデフォルトの状態にリセットされます。CUは基本的に四半期に一度リリースされますので、3か月に一度設定がクリアされるという形になります。

毎回メモ帳などを利用して書き戻すというのも運用上の負担になりますし、作業漏れやミスによって障害が引き起こされる可能性もあるので、今回はその変更作業をPowerShellを利用して行いたいと思います。

web.configは中身はXMLドキュメントになりますので、Get-Contentした物を[XML]キャストすればPowerShellから普通に扱えます。例えば、KB2882961対策でOWAのweb.configのAppSettingsの欄に<add key=”UseDisabledAccount” value=”1″ />を加えたい場合、以下の様に行います。

$webConfig = "C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\Owa\web.config"
$AppSetKey = "UseDisabledAccount"
$AppSetValue = "1"
$doc = [XML](Get-Content $webConfig)
$newAppSetting = $doc.CreateElement("add")
$doc.configuration.appSettings.AppendChild($newAppSetting)
$newAppSetting.SetAttribute("key",$AppSetKey);
$newAppSetting.SetAttribute("value",$AppSetValue);
$doc.Save($webConfig)

同様に、AppSettings以外のsystem.webなどの項目も書き換えられます。例えば、ActiveSyncの最大送受信サイズを20MBにするためにCASのweb.configの既存のmaxRequestLengthを書き換える場合は、

$webConfig = "C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\sync\web.config"
$ObjKey = "maxRequestLength"
$NewValue = "20480"
$doc = [XML](Get-Content $webConfig)
$obj = $doc.configuration."system.web".httpRuntime.$ObjKey
if ($obj -ne $null) {
  $doc.configuration."system.web".httpRuntime.$ObjKey = $NewValue
  $doc.Save($webConfig)
} else {
  Write-Host "$ObjKey not found"
}

こんな感じです。(既存の値を変更するので、既存の値の存在チェックを入れています)

なお、同様に既存のweb.configの設定内容を確認することもできますので、書き戻しが必要かどうかチェックする際にも利用することが可能です。色々ご自分の環境に合わせてお試しいただくと良いかと思います。