Lync Online構成用のDNSレコードの変更

Lync Onlineのバージョンアップに伴い、独自ドメイン環境でOffice365を利用する場合に利用するDNSレコードが変更になったようです。

管理者メニューのドメインの所から参照すると、現在以下の様な感じになっています。

SRVレコードで_SIPというサービス名が必要だったのが無くなり、代わりにCNAMEレコードを利用した記載に変わっていますね。

あと、lyncdiscoverというCNAMEレコードが加わってます。こちらはLyncMobileへの対応用でしょうか。

ちなみに、プランPでDNSをMicrosoftにホスティングされている方(通常はこちらのパターンだと思います)については、自動的に切り替わっていますので心配されることはございません。

特に表立ってレコード変更をかけてくれというアナウンスは無かったので、何もDNSいじっていなかったのですが、問題は発生していません。気になったので、Lyncクライアント側での動作をパケットキャプチャして見てみることにします。

どうやら、先にSRVレコードで_sipのサービス名を引きに行き、それが無かった場合にsip.[domain name]のレコードをクエリしている様です。
※その他、sipinternalというレコードも見ているようです。

確かに、インターネットに接続している外部向けDNSでSRVレコードを利用するというのはあまり聞きませんし、対応しているDNSホスティングサービスも非常に少数なので、サービスとしては良い方向性に向かっているのだと思います。現状のユーザーへの影響度も少なくなるように考慮はされているのでしょう。

ユーザ側の立場からしてみるとどんどんバージョンが上がって良い物になっていくというのはクラウドサービスの良いところではありますが、システム管理者やSIerの立場からすると、その内容やタイミング含め自分の制御下で実施出来ないということは煩わしさも感じてしまう面も存在します。

いずれこなれてきて、こういった類の情報のクラウド事業者→利用者への伝達手段も洗練されたものになってくると良いですね。

広告

ソフトマッチについて試してみた

「ソフトマッチ」と聞いても、なかなかピンとこない方も多いのでは無いかと思います。これは、
先にOffice365にメールボックスが作成されているクラウドIDのアカウントに対して、後からオンプレミスのActive Directoryの同期アカウントとして紐付ける
手法です。

非サポートの手法と言われていて、仕様がいつ変わるかも分からない物だったのですが、どうやらそろそろ正式にサポートされるかも…という話を聞いたので少し検証してみます。

まず、ディレクトリ同期について、通常のフローで言うと以下の様なデータの流れになります。

  1. オンプレミスのActive Directoryのアカウント情報がディレクトリ同期によってOffice365のADに同期アカウントとして作成される。同期アカウントはOffice365側では編集不可。
  2. Office365側では、独自に作成したオンプレとは非同期のアカウントも作成可能。
  3. Exchange Onlineのサブスクリプションを付与することにより、メールボックスが作成される。
    ※Exchange Online側で先に作成されてOffice365に同期されるパターンも有り

この時、Office365上では同期アカウントと非同期アカウントがありますが、それぞれの区分を変更したりすることはできません。同期アカウントに対してはSourceAnchor(オンプレのオブジェクトのGUIDから生成)という値が保持され、これがあるかどうかで同期アカウントか判断されます。またこれにより、ディレクトリ同期サーバを再インストールしても連携が保持されます。

ここで、ケースによっては、ディレクトリ同期ツールでアカウントを作成するのが難しいことがあります。例えば、

  • 移行に合わせてフォレスト統合を行う必要があるが、Office365の利用希望日に間に合わなく先にクラウドIDを利用して開通させたい。また、統合後はメールボックスは保持したまま移行したい。
  • Office365を利用開始後、パスワード管理やアクセス制御などの問題でADFS導入を行いたい。
  • ディレクトリ同期されたアカウントのメールボックスの復活を行い、再び同期アカウントに紐付けたい。(削除済みメールボックスの回復は、非同期アカウントの新規作成と合わせた紐付けとなる)
  • BPOSの移行されてきたメールボックスをADFS環境で利用したい。

などです。最後の項目があるのでサポートせざるを得ないだろうという話なんでしょうね。ここで解決法として登場してくるのがソフトマッチです。(※ちなみに、上記で記載したSourceAnchorによるマッチングは「ハードマッチ」と呼ばれます。)

ディレクトリ同期ツールからしてみると、新規でアカウントを作成しようとしますが、Office365側のアカウント作成プロセスにおいて条件をチェックし、「新規作成」から「変更(SourceAnchor含む)」に勝手に変更してくれるという形になります。

つまり、先にディレクトリ同期されてOffice365側に対応する同期アカウントが出来ていて、後から属性の変更などで条件を満たすようになったとしても、このマッチングは行われません。(というか、属性の一意性エラーで同期ツールによる変更が実施されません。)

ここでの特定条件のマッチングですが、以前はUPNとメールアドレスの完全一致とか言われてましたが、どうやら今はメールアドレスだけで判定されているという話なので、いくつかパターン見て調べてみます。

  1. UserPrincipalName、mail、ProxyAddresses(SMTP:で始まるプライマリ)が完全一致…OK
  2. UserPrincipalName、ProxyAddresses(SMTP)が完全一致…OK
  3. mail、ProxyAddresses(SMTP)が完全一致…OK
  4. ProxyAddresses(SMTP)が完全一致…OK
  5. ProxyAddresses(smtp)がOffice365側の追加アドレスに一致(smtp:で始まる)…OK
  6. mailがOffice365側のプライマリアドレスに一致…OK
  7. mailがOffice365側の追加アドレスに一致…OK
  8. 一度同期されたオブジェクトを Explicit Disconnector にする手法を使ってOffice365から消して、mail属性を追加アドレスと一致させてから再同期…OK

Office365側に作成済みのアカウントのメールアドレス(mail、ProxyAddresses(SMTP:)、ProxyAddresses(smtp:))のいずれか1つでも等しいADのオブジェクトが、ディレクトリ同期でOffice365側に同期され、アカウントの新規作成が実施されようとした際にソフトマッチが行われるようです。

ただ、1点注意事項。8番で実験しましたが、一度ソフトマッチに失敗しても、オンプレ側のADを削除することなくリカバリをすることは可能です。逆に、一度でもソフトマッチで同期オブジェクトになってしまった場合は元には戻せません。Office365側にオンプレと同じsourceAnchorが付与されて、ハードマッチの状態になってしまうからです。(まあ、SR上げて気長に1週間くらい待てば可能かもですが)

一度同期されればハードマッチ状態になりますので、気を遣わなくてはいけないのは一度だけです。また、現時点ではいつ仕様が変わるか分からないので、直前に検証(仕様が変わっていないか)は必要かと思いますが、上手く使いこなせれば展開方法の柔軟性が格段に増すかと思います。

簡単に手順を記載します。同期アカウント(contoso-jp.com)と非同期アカウント(fabrikam-jp.com)の混在環境が合ったとします。

ここで、fabrikam-jp.comのユーザがcontoso-jp.comへのフォレスト統合が完了したとして、contoso-jpのアカウントを保持したと仮定します。

ここで、ディレクトリ同期が走る前に電子メール(mail)属性をマッチングさせたいOffice365側のメールアドレスと一致させます。

手動同期を実施すると、

ソフトマッチによりfabrikam01のアカウントが同期アカウントに変更されます。

ここで注意点ですが、シングルサインオン(ADFS)として構成している場合は問題ないのですが、ディレクトリ同期のみで実装している場合、ユーザのログオンアカウント名(UserPrincipalName)についてはオンプレミスでの変更はOffice365側に同期されません。整合性を取るため、mail属性だけではなく、UPN名についても一致した状態でソフトマッチさせることを推奨いたします。

上記例の場合は、先にOffice365側でfabrikam01@fabrikam-jp.comからfabrikam01@contoso-jp.comにユーザ名を変更してからソフトマッチするということになります。。

今後のMicrosoft側の発表についても、ウォッチしたいと思います。

64bit版ディレクトリ同期ツールを触ってみた

64bit版のディレクトリ同期ツールを軽く触ってみました。

まず、一番試したかったこと、ADFS2.0との同居です。今までは、32bit版の動作環境を確保するために3時間に1回しか動作しないOSを1個立てなければならなかったですが、可能なら構成する台数が1台減ります。

結論から言うと、ディレクトリ同期ツールインストール→ADFS2.0インストール、ならびにADFS2.0インストール→ディレクトリ同期ツールインストールのどちらの順番でも共存可能でした。

ADFS自身もかなり負荷は少ないので、数百人クラスのユーザーであれば、MSの推奨構成とは異なりますが

①(新規)ADFS 2.0+ディレクトリ同期を追加する。
②(既存)ドメインコントローラの1台にADFS2.0を追加する。
③(新設)ADFS Proxy。※外部からのアクセスまたはOutlookなどのOWA以外のメーラーを利用する場合

辺りで十分でしょうか。

続いて、同期間隔の調整について。こちらは同じ設定ファイルが有るので、同じように書き換えたところ問題なく動作しました。

C:\Program Files\Microsoft Online Directory Sync\Microsoft.Online.DirSync.Scheduler.exe.Config

PowerShellが2.0になったので、リモートから接続して手動同期掛けられるようにしたいと思います。

ディレクトリ同期サーバ側

Enable-PSRemoting

操作サーバ側(同一ドメインから、ログインしてる管理者アカウントで接続)

Enter-PSSession -Computername servername.contoso.com
Add-PSSnapin Coexistence-Configuration
Start-OnlineCoexistenceSync

その他の操作感とかもほぼ一緒ですね。折角なのでPowerShell使ったり色々といじってみたいです。

Office365の64bit版ディレクトリ同期ツール

待望のOffice365のディレクトリ同期ツールの64bit版が11/17にリリースされましたので、早速試してみました。

Windows 2008R2へのインストール手順

1.準備

  • ドメインのメンバサーバとして所属させます
  • .NET Framework 3.5.1の機能を追加します

2.ディレクトリ同期ツールのダウンロード

管理メニューのユーザーから、Active Directory同期のセットアップをクリックします。

4番目の項目で、Windows 64bit版を選択し、ダウンロードをクリック

3.ディレクトリ同期ツールのインストール

ダウンロードしたdirsync-ja.exeをダブルクリックし、インストーラーを起動します。

特にここで気にしなければならないことは無いので、指示に従って進めます。
      

4.ディレクトリ同期ツールの構成

インストールに引き続き、ディレクトリ同期構成ウィザードで設定を行います。

インストールに必要なのは、①Office365の管理者のID、PASS ②Active Directoryの管理者(フォレスト全体を同期するのでEnterprise Admins)のID、PASS ③Exchange2010の高度な共存環境(ディレクトリの書き戻しの有効化)の有無です。
  

必要項目を入力し、インストールを完了させます。
  

5.ディレクトリ同期ツールの追加設定

以上で、ディレクトリ同期ツールの設定は基本的に完了です。特に何も設定すること無く、3時間に1回ずつディレクトリ情報の同期を行ってくれます。

ここでは、もう少し便利に使うために追加設定を行います。

①ディレクトリ同期ツールの権限の設定

ディレクトリ同期ツールをインストールすると、ローカルにMIIS_Serviceというサービス用のアカウントと、FIMならびにSQL関係のグループがいくつか作成されます。このうち、MIISAdminsというグループが、ディレクトリ管理ツールの管理権限を持つユーザとなります。

デフォルトでは、インストールしたユーザならびにMIIS_Serviceしか入っていませんので、ここに管理上必要なアカウントやグループを登録します。Office365ならびにフォレスト全体の情報が登録されてますので、厳密に管理を行う必要があります。今回はEnterprise Adminsを登録しておきます。

②手動同期PowerShell実行用のショートカットの設定

ディレクトリ同期は、標準で3時間毎に同期されておりますが、ユーザを登録した直後など、手動で同期を実行することがサポートされております。C:\Program Files\Microsoft Online Directory Sync\DirSyncConfigShell.psc1からPowerShellコンソールを開くので、こちらのショートカットをデスクトップに作成します。

手動同期を実施したい場合は、PowerShellからStart-OnlineCoexistenceSyncコマンドレットを実行します。

③ディレクトリ同期ツールの管理コンソールのショートカットの作成

②の手動同期の結果の確認や、細かい操作はディレクトリ同期ツールのコンソールから実施することができます。ILM 2007ベースの32bit版とは少し違う場所ですが、C:\Program Files\Microsoft Online Directory Sync\SYNCBUS\Synchronization Service\UIShell\miisclient.exe にあるので、ショートカットを作成します。

ここで、一度資格情報をリセットするために一度ログアウトする必要があります。そのまま起動しようとするとエラーが表示されます。

再度ログインしてmiisclientを起動すると、無事管理コンソールが起動できます。

次回以降、32bit版の時にできていた各種オペレーションやカスタマイズ可否を確認してみたいと思います。

デバイスの「場所」情報に基づくNICのリネーム

Windowsは、接続されているNICに「ローカル エリア接続 xx」という名前を付けて管理をしますが、この名前付けはランダムであり、同じ構成のマシンを同時にインストールしてても違う名前が付いたりします。

 

通常は、インストール中に接続されている物理ポートに応じて名前を付けたり並び替えたりするのですが、複数のNICを有しているサーバ機では結構その作業が面倒です。Linuxの様にMACアドレスで特定するにも、インストール前に特定するのは難しいです。そこで、PCIバスの番号や機能などによりポートを特定して並び替えるPowerShellスクリプトを作ってみました。(実行には管理者権限で実行する必要があります)

function rename-nic($i, $j ,$k ,$x) {
    $newname = "$x"
    $location = "PCI bus $i, device $j, function $k"
    $location_jp = "PCI バス $i, デバイス $j, 機能 $k"
    $drvinfo = (Get-WmiObject Win32_PnPSignedDriver | Where-Object {$_.Location -eq $location -or $_.Location -eq $location_jp}).DeviceID
    $nic = Get-WmiObject Win32_NetworkAdapter | Where-Object {$_.PNPDeviceID -eq $drvinfo}
    $oldname = $nic.NetConnectionID
    if ($oldname -eq "$newname") {
        write-host "既に指定された名前になっています"
    }
    elseif ($newname -eq '') {
        write-host "新しい名前を指定して下さい"
    }
    elseif ($oldname -eq '') {
        write-host "指定されたバスにNICが見つかりません"
    }
    else {
        write-host "NIC名変更: $oldname => $newname"
        $nic.NetConnectionID = $newname
        $nic.Put()
    }
}

$model = (Get-WmiObject Win32_ComputerSystem).Model

if ($model -eq "PRIMERGY RX200 S6             ") {
    write-host "Fujitsu PRIMERGY RX200 S6のNIC名を変更を実行します"
    rename-nic "1" "0" "0" "ローカルエリア接続1"
    rename-nic "1" "0" "1" "ローカルエリア接続2"
    rename-nic "4" "0" "0" "ローカルエリア接続3"
    rename-nic "4" "0" "1" "ローカルエリア接続4"
    rename-nic "4" "0" "2" "ローカルエリア接続5"
    rename-nic "4" "0" "3" "ローカルエリア接続6"
    rename-nic "3" "0" "3" "ローカルエリア接続7"
    rename-nic "3" "0" "2" "ローカルエリア接続8"
    rename-nic "3" "0" "1" "ローカルエリア接続9"
    rename-nic "3" "0" "0" "ローカルエリア接続10"
}

サンプルとして、富士通の1UサーバにQUADポートの増設NICを2枚刺した物をベースに作りました。(PCIバスの3番と4番は片方がLPになっていて指す方向が逆なので機能番号が逆順になっています)

各マシンやNICごとに、rename-nic関数の引数を変えて行けば使い回しできそうですね。