Office365での独自ドメインの利用（RocketNet）でも書いたとおり、Office365のLyncでフェデレーションを利用する為にはSRVレコードが必要です。

残念ながら、日本のドメインレジストラに付帯してくるDNSホスティングサービスではOffice365の技術blog Office 365 で利用するための日本の主要なレジストラーにおける DNS の設定方法にも記載が有るとおり、ほとんど対応していない状況です。

Office365が発売されて時間も経ちましたので、折角なのでSRVレコードの対応状況を調べてみました。

まず、上記サイトでも紹介されていた5つのレジストラ

• お名前.com
• さくらインターネット
• Value Domain
• ムームードメイン
• yahoo

ですが、残念ながら現時点でもSRVレコードには対応していませんでした。折角なので、今後の対応予定が無いか尋ねてみます。Yahooのみメールでの問い合わせ窓口が分からなかったので送れませんでしたが

件名：DNSサービスの機能に関する問い合わせ

突然の問い合わせ失礼いたします、○○と申します。

マイクロソフトにて公開されております情報を読み、連絡をさせて頂いております。
 http://community.office365.com/ja-jp/blogs/office_365_technical_blog/archive/2012/05/14/office-365-dns-setting-for-major-japanese-registrar.aspx

マイクロソフトで拡販に力を入れているOffice365というサービスが有り、 中小企業を中心に
導入が進んでおります。この中で、LyncというIM/プレゼンス/テレビ会議などを実施することが
できるサービスが、他ユーザーやSkypeなど他サービスとの連携を行う際に SRVレコードの実装が
必須となっております。

ニーズとしては非常に大きいかと思うのですが、御社DNSサービスにおいて 今後SRVレコードに
対応される予定はございませんでしょうか?

よろしくお願い致します。

さすがにこの辺は回答早いですね。4サービスとも翌日には「対応予定無し」「貴重なご意見ありがとうございます」という感じの返答を頂きました。

という訳で、見つけられているレジストラは以下しか今のところは紹介できません。

• ロケットネット（GMOグループ）
• ドメインキング（GMOグループ）

ドメインレジストラのやっている無償のDNSホスティングはサービスでやっているような物ですから、新たなコンパネの機能開発投資は難しいというのは分かるんですけどね…。

SRVレコードを直接サポートというわけでは無いのですが、直接ゾーンファイルの内容をいじれるなど、間接的には以下でも実装可能ですね。

• Doレジ
• Amazon Route53

しっかり使うのであればVPSのLinux OSホスティングを月1000円くらいで借りてきて、そこでbindを運用。セカンダリ側だけレジストラに依頼するのが楽かもしれませんね。

久しぶりにADFSの環境を構築しようとして、検証環境でConnect-MsolServiceコマンドレットでWindows Azure Active Directoryに接続しようとしたところ、なぜか以下のエラーが出て接続できない事象が発生するようになりました。

PS C:> Connect-MsolService -Credential $LiveCred 
Connect-MsolService : 要求チャネルは、応答を待機してから 00:00:59.8905882 後に
タイムアウトしました。Request の呼び出しに渡すタイムアウト値を増やすか、Binding
 の SendTimeout 値を増やしてください。この操作に割り当てられた時間は、より長い
タイムアウト時間の一部であった可能性があります。
発生場所 行:1 文字:1
+ Connect-MsolService -Credential $LiveCred
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (:) [Connect-MsolService], Tim
   eoutException
    + FullyQualifiedErrorId : System.TimeoutException,Microsoft.Online.Adminis
   tration.Automation.ConnectMsolService
Connect-MsolService : 種類 'Microsoft.Online.Administration.Automation.Microsof
tOnlineException' の例外がスローされました。
発生場所 行:1 文字:1
+ Connect-MsolService -Credential $LiveCred
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (:) [Connect-MsolService], Mic
   rosoftOnlineException
    + FullyQualifiedErrorId : Microsoft.Online.Administration.Automation.Micro
   softOnlineException,Microsoft.Online.Administration.Automation.ConnectMsol
  Service

エラーの内容からすると、単なるタイムアウトっぽいです。

他の環境から実行したところ特に問題く接続できるので、クラウド側の障害とかでは無さそうに思えます。下の方のレイヤでの障害が疑われるので、とりあえずWireSharkでパケットを追ってみると、何となくそれらしい所が見つかりました。

Connect-MsolServiceでは、まずlogin.microsoftonline.com（実体はlogin.microsoftonline.com.nsatc.net）に接続しに行った後、provisioningapi.microsoftonline.com（実体はprd-provisioning.msods.nsatc.net）に接続しにいくのですが、このprd-provisioning.msods.nsatc.netがAAAAレコードを持っているというところがポイントの様です。

というのも、この検証環境のOSはデフォルトの構成で適当に組んでいるので内部セグメントではIPv6が有効化されており、ドメコン上のDNSサーバで名前解決もできるのですが、ルーターやFirewall、回線はIPv6対応していなく、IPv6でインターネットに向けて通信ができないという、ちょっと特殊な環境です。

ご存じの通り、Windowsでは同一ホスト名に対してIPv4とIPv6の両方で接続ができる場合、IPv6での接続を優先的に試みます。今回、IPv6の通信がタイムアウトで失敗してIPv4にフェールバックされてくる前に、PowerShellの接続モジュールの方が耐えきれなくなってタイムアウトしている…という状況のようです。

…というわけで、IPv6を切ったら何の問題も無く繋がるようになりました。

Office365も段々とIPv6対応してくるサービスが増えてくるようなので、もう少ししっかりIPv6の構成をオンプレでも見直していった方が良いかもしれませんね。

前回のOffice 365 Midsize Businessに引き続き、今回はOffice 365 Enterpriseにおける独自ドメインについて書きたいと思います。

すいません、最初に言っておきます。この記事を投稿した時点ではMidsize Businessとの違いが見つけられませんでした。（今後変更になるかもしれないので、一応エントリーは分けて作成しておきます）

ドメイン関係のメニューなので、[ドメイン]メニューを開き、[ドメインの追加]を選択します。

Enterpriseのドメインの確認プロセスは、以下の3つのプロセスです。

1. ドメイン名の確認
2. 独自ドメイン名を持つユーザーの作成
3. ドメインの目的の設定とDNSレコードのチェック

まずはドメインの確認を行います。ドメイン名を入力すると

そして、ここで出力された物をDNSサーバーに登録します。

DNSキャッシュのせいで少し時間が掛かる可能性が有りますが、これでドメインの所有確認が完了します。

続いてはこの独自ドメイン名を持つユーザーを追加するという工程ですが、これは後からでも追加できますので、特に追加せずに次に進みたいと思います。

最後に、独自ドメインを利用する上でのDNSのチェックです。以前はこの部分は後からトラブルシュートで実施することができましたが、今回からはウィザード中で実施する必要があるようです。

まずはドメインの用途を「Exchange Online」「Lync Online」「SharePoint Online」で選択します。デフォルトでは、Exchange OnlineとLync Onlineのチェックが付いていますが、SharePointのみ排他利用なので、チェックを入れる場合（サイト名として利用する場合）はExchange,Lyncでは利用できません。

ここでLyncのチェックを外したとしてもログオン用のIDとしてその独自ドメインを利用した場合、そのユーザーにLyncのサブスクリプションを付与するとその独自ドメインのSIPアドレスを持つアカウントがLyncで作成されてしまうので、あまり意味は持たないのかもしれません。

独自ドメイン名自体をExchange,Lyncにして、wwwなどのサブドメインを作成してそちらをSharePoint Onlineで利用されるというパターンが多いようです。

ここで表示されたレコードをDNSサーバーの方に設定させて、チェックが通ればこの工程は終了です。ちなみにここのチェックが完了していなくても、設定自体は完了しているのでOffice365は問題なく利用できます。特にSRVレコードが作成できない場合や、他のメール配信サーバーがあってSPFのTXTレコードの値をカスタマイズしている場合など、無視して利用する形になります。

ついでなので、PowerShellからドメインを追加する場合の手順について記載します。

ドメインの追加には、Windows PowerShell 用 Microsoft Online Services モジュールを立ち上げてOffice 365に接続後、New-MsolDomainコマンドレットを実行します。ドメイン認証用コードの取得はGet-MsolDomainVerificationDnsです。

確認はConfirm-MsolDomainコマンドレットで行います。エラーが出ない場合は成功です。画面の表示は変わりませんが、Get-MsolDomainでのStatusがUnverifiedからVerifiedに変わります。

また、最初に追加されたドメインの場合はそのテナントの既定のドメインにするという設定に自動的になりますので、そちらも必要に応じて修正します。

New-MsolDomain -Name ドメイン名
Get-MsolDomainVerificationDns -Mode DnsTxtRecord -DomainName ドメイン名
Confirm-MsolDomain -DomainName ドメイン名
Set-MsolDomain -Name ドメイン名 -IsDefault

1点だけ異なるのが、デフォルト状態でのドメインの用途がGUIから追加した場合はExchange OnlineとLync Onlineにチェックが入っていますが、PowerShellから作成した場合は用途に何も設定されていません。

このままだと、作成するDNSレコードの詳細などが分からないので[ドメイン]メニューから[DNS設定の表示]を開き、[ドメインの目的を変更する]でGUIのSTEP3のメニューを手動実行しましょう。

また、これは少し原因が分からないのですが、Confirm-MsolDomain コマンドレットで認証を行った場合、GUIの設定画面のSTEP1の最後の部分がエラーが出て完了できません。前述の通り、ドメインの認証さえ終わっていれば（GUIの場合DNS設定の表示が出せる状態、PowerShellの場合はGet-MsolDomainの値がVerifiedになっている状態）「セットアップが進行中です」のステータスのドメインでも問題なく利用できますが、少し気持ち悪いですね。

2月より新たに提供開始された1-250名規模の企業向けのプラン、Office 365 Midsize Businessにおける独自ドメインの使用について紹介したいと思います。

Midsize Businessのメニュー体系は、プランEとほぼ同じです。独自ドメインの追加は[ドメイン]メニューの[ドメインの追加]から実施します。
 

Small Business Premiumが5ステップだったのに対して、こちらはDNSサーバをユーザー側で用意する分、手順が3ステップとかなり簡単になっています。

1. ドメイン名の確認
2. 独自ドメイン名を持つユーザーの作成
3. ドメインの目的の設定とDNSレコードのチェック

まずは、追加したい独自ドメイン名を入力します。
 

手順の中では主要レジストラの手順が紹介されていますが、日本の場合は[一般的な手順]を読むと良いでしょう。

既存のDNSサーバに指定されたTXTレコードを記載します。ちなみに、このゾーンは試験用に作ったドメインということでデフォルトのTTL（最初の行）が300秒に設定されてますが、通常は3600（1時間）とか86400（1日）とかが多いと思うので、その場合はレコード毎のTTLを少し落として設定しても良いですね。（後でSPFとして利用されるTXTレコードの設定値をチェックする工程があるので、そこでの確認時間短縮のため）

最初のうちは以前の値がキャッシュされていたり、セカンダリDNS側への伝搬が完了していなかったりするので認証されなかったりしますが、キャッシュがクリアされ次第認証されます。（以前にTXTレコードが1つも無かった場合は、”そんなレコードは無い”という情報が他のDNSサーバでキャッシュされている可能性がありますが、ネガティブキャッシュと呼ばれるこの種のキャッシュの生存期間はSOAレコードの最後の行:minimumで指定されています。上記例であれば1日。気になるようであれば300秒とかに短縮しておきましょう）
 

続いて、独自ドメイン名のアカウントを作成できます。特に後からでも追加できますので、ここでは[今はユーザーを追加しません]を選択します。

次に、ドメインの目的とDNSのレコードチェックを行います。用途としては、ほぼ2択であり「(デフォルト)①Exchange、Lyncでサービス用のIDとして利用する」「②SharePointのWebサイトとして利用する」のどちらかになります。

ちなみに、ここで下の高度なセットアップを開いて[社内のメールボックスがOffice365で動作するようにセットアップ～]を選択すると、オンプレミスのExchange 2010とのハイブリッド構成用のコネクタの作成などがこの工程中で実施できます。

DNSサーバに設定するレコードの一覧が表示されます。メールで利用するTXTレコード、MXレコードの値が.protectionのサブドメインの付く新しい値に変わっているので、前のバージョンに慣れていた方は入力ミスにご注意下さい。

以前はここでウィザードは終了だったのですが、ここでDNSレコードがしっかり登録できたかどうかのチェックが終わらないと、セットアップが完了しないようになりました。以前もトラブルシュートの画面から設定を手動で確認することができたのですが、今回からは必須要件になったようです。

全てのレコードの設定が正しくないとエラーがでます。TXTとMXが正しく設定しているのに確認が取れないという場合は、おそらく手順1のチェックの際に取得した値をMicrosoft側のDNSがキャッシュとして保持していた場合のエラーなので、おとなしくキャッシュがクリアされる時間を待って再度確認します。

この工程ですが、チェックが完了していなくてもドメインの使用自体は既にできるようになっておりますので、お急ぎの場合は[閉じて後で戻る]などでも良いと思います。その場合、ドメインメニューを開いた場合のステータスが[セットアップが進行中]になります。そのリンクをクリックするとまたこのウィザードに戻る事が可能です。

これが完了すると、ドメインが正しく追加されます。DNSの設定を確認したりドメインの目的を編集したい場合は、[DNS設定の表示]を開いて行います。

余談ですが、また追加後の独自ドメインのステータスが[アクティブ]になりましたね。これ、以前のバージョンで、リリース当初は[アクティブ]だったのですが、途中からいつのまにか[確認済み]に仕様変更されていて、よくユーザーから「マニュアルの手順通りにやっても書いてある結果（アクティブ）にならない。どうしてだ？」と問い合わせを受けたものです…

特に、Small Business Premiumに関しては、専門の管理者外無くても構築・運用することが可能なように開発者側でケース毎のシナリオを多が用意され、セルフサービスにて解決が可能なように開発されております。

今回は、Small Business Premiumを実環境で利用する上で一番最初にやる必要があることが多い「自社ドメインの追加」について、実際の画面のイメージを交えながら解説していきたいと思います。

ドメインの追加は、[はじめに]ウィンドウと呼ばれる基本メニューの中の一番最初「電子メールアドレス」から実施します。

まず、一番最初に[Office365の電子メールアドレスを変更しますか]と聞かれるので、[今すぐ開始]を選択します。次の画面では、具体的に追加しようとするドメイン名について聞かれますので入力し、[次へ]をクリックします。
 

次に、そのドメインの用途として「①メールアドレスとして利用しているか」「②www.独自ドメイン名のサイトを持っているか。持っている場合は今のWebサーバをそのまま継続するか」について尋ねられます。ここでは、「①はい」「②はい。引き続き現在ホストされている場所に置きます。」を選択します。

ちなみに、ここで「はい。ただし、Office 365 で新しい Web サイトを作成して置き換えます。」を選択した場合は、電子メールアドレスを切り替えた後に「一般向けWebサイト」で移行をしてくれと表示されます。結局、ここで何と答えても、後からOffice365でホストするように変更が可能です。

これで、ようやくメインのドメイン追加プロセスに移ります。追加プロセスは主に5つのプロセスで行われます。

1. ドメインの所有確認
2. Webサイト向けDNSレコードの生成
3. 既存ユーザーのログイン名/電子メールアドレス変更
4. 独自ドメインのログイン名/電子メールアドレスを持つ新規ユーザーの追加
5. ネームサーバーの変更

早速[手順1を開始する]を選択し、追加プロセスに入っていきたいと思います。マイクロソフトがいくつかDNSホスティングサービスを実施している業者の手順を作成してくれているのですが、残念ながら日本の物はありません。[この件に対応してくれる人物がいます。]という選択肢を選んだ場合の表示内容が一番シンプルでしっかりまとまっているので、今回はそちらを選びます。

TXTレコードまたはMXレコードを作成してくれというメッセージが表示されます。MXレコードは既存メールサーバへの配信が変わる可能性が有る（実際は、～.msv1.invalidという存在しないドメイン名なので理論的には悪影響は無いはずですが）ので、今回はTXTレコードで認証を行いたいと思います。bindのゾーンファイルを変更して、@（ドメイン名自身）のTXTレコードとしてMS=ms78940134を追加します。両側の” “はおまじないです。無くても別に認証は通ります。
 

登録が完了したら、[今すぐ確認する]を選択します。タイミングが早すぎるとエラーがでますが、少し待つと認証できるかと思います。（デフォルトTTLの設定や既存でTXTレコードが有るかどうかにもよるが、数分～1日程度だと思います）　これで、STEP1は終了です。
 

さて、STEP2に移ります。

STEP2は、既存（もしくは新しく移行する）Webサイトの設定情報をOffice365でホストされるDNSのレコードに反映させる作業です。最初に既存のWebサイトのアドレスを調べてきて下さいという内容が出ます。丁寧に、「私のサイトのIPか、静的IPでなければFQDNを教えて下さい」というサンプル文書が表示されるのですが、残念ながら英語です。

調べたIPアドレス（もしくはFQDN）を入力します。ご丁寧に現在のDNSレコードを引いて、それと正しいかどうか見てくれるみたいです（そこまでわざわざやってくれるなら元から自分で検索して初期値として設定してくれればいいのに…とも思いますが）。これにより、wwwのCNAMEレコードとIPアドレスの場合は@のAレコードが、FQDNの場合はCNAMEレコードが裏で生成されます。
   

STEP3は既存ユーザーのメールアドレスの変更です。

既存のユーザー一覧が表示されますので、その中から電子メールアドレスを独自ドメインに変更したい物をチェックし、[更新]を押します。なお、この際に一緒にログイン名も独自ドメインに変更されます。

STEP4は独自ドメインのメールアドレスを持つユーザーアカウントの新規追加になりますが、今回は既存で作ってあり、STEP3で変更済みのため新規では作成せず、[いいえ。～の電子メールを使用しているのは私だけです]を選択します。既存のメールサーバーを利用しており、まだそのアドレスを持ったユーザーをOffice365に作成していない場合は、メールの受信を継続できるよう、ここの段階で必ず追加する必要があります。

最後のSTEP5は、ドメインのネームサーバをOffice365に変更するという一番大きい工程です。ここでミスしてしまうと、メールが受信できなくなったりWebサーバに接続できなくなったりかなり影響が大きいので、慎重に今までのSTEPが完了していることを確認してから実行しましょう。
 

ここでも各種レジストラの設定情報が表示されますが、残念ながら[使用しているサービスが一覧にない]を選択します。ネームサーバー1、ネームサーバー2として記載のある ns1.bdm.microsoftonline.com / ns2.bdm.microsoftonline.com のアドレスをメモしておきます。

前項でメモしたネームサーバーに、利用したい独自ドメインのネームサーバーを変更します。画面のイメージはお名前.comで実施した場合のイメージです。

反映にはしばらく時間が掛かることがありますが、完了したら以下の様に処理完了の旨の表示が出るので、[完了]をクリックし、[完了しました。]をクリックします。

これでドメインの追加は完了です。ドメインのステータスも、[確認済みの表示になります。]

ドメイン名を選択し、[DNSの管理]から既存の設定を見たり、WebサーバーのIPアドレスを変更したり、新たなホストレコードの追加などが可能になります。