（この投稿はプレビュー版での情報を元に作成されています。正式版リリースの際には変更されている可能性もあるのでご注意ください。）

前回のカスタムアドレス帳に加えて、今回はそれらのアドレス帳をユーザーによってフィルタする機能であるアドレス帳ポリシーについて説明したいと思います。

詳細な実装などについてはTechnetの記事「アドレス帳ポリシーの作成」などを参照頂ければと思いますが、基本は「アドレス帳セット・グローバルアドレス帳・オフラインアドレス帳の作成」「アドレス帳ポリシーの作成」「ユーザーへのアドレス帳ポリシーの割り当て」の順番になります。

基本は前回作ったアドレス帳をベースとして、今回はグローバルアドレス帳(GAL)とオフラインアドレス帳(OAB)を追加で作成します。GALは、一緒に追加しようとしているサブセットであるアドレス帳の内容を全て含む必要があります。

New-GlobalAddressList -Name "Contoso GAL" -RecipientFilter '((Alias -ne $null) -and (CustomAttribute1 -eq ''1''))'
New-GlobalAddressList -Name "Fabrikam GAL" -RecipientFilter '((Alias -ne $null) -and (CustomAttribute1 -eq ''2''))'
New-OfflineAddressBook -Name "Contoso OAB" -AddressLists "Contoso GAL"
New-OfflineAddressBook -Name "Fabrikam OAB" -AddressLists "Fabrikam GAL"

この状態で、今度はContoso用とFabrikam用のアドレス帳ポリシーを作成します。固定で必要なものの他に、表示させたいものを選んで作成します。

New-AddressBookPolicy -Name "Contoso ABP" -AddressLists "All Contoso List","Contoso Rooms","Contoso Users","Contoso Groups","Contoso Contacts" -RoomList "Contoso Rooms" -GlobalAddressList "Contoso GAL" -OfflineAddressBook "Contoso OAB"
New-AddressBookPolicy -Name "Fabrikam ABP" -AddressLists "All Fabrikam List","Fabrikam Rooms","Fabrikam Users","Fabrikam Groups","Fabrikam Contacts" -RoomList "Fabrikam Rooms" -GlobalAddressList "Fabrikam GAL" -OfflineAddressBook "Fabrikam OAB"

そして、最後にこれをユーザーに割り当てます。（ユーザーはデフォルトではアドレス帳ポリシーはどれも適用されてませんので、全部のアドレス帳が参照できる状態になっています。）　今回はPowerShellで該当する属性を持つ全ユーザーに一括してアドレス帳ポリシーを適用します。

Get-Mailbox -RecipientTypeDetails UserMailbox -Filter {CustomAttribute1 -eq '1'} | Set-Mailbox -AddressBookPolicy "Contoso ABP"
Get-Mailbox -RecipientTypeDetails UserMailbox -Filter {CustomAttribute1 -eq '2'} | Set-Mailbox -AddressBookPolicy "Fabrikam ABP"

これで、ContosoはContosoの中だけ、FabrikamはFabrikamの中だけのアドレス帳が参照されます。例えばContosoのユーザーでログインするとこんな感じになります。

これで、グループ企業などで共同利用する際に、通常は必要としないアドレス帳情報にアクセスする必要がなくなり、オフラインアドレス帳のダウンロードサイズも小さくなるなどのメリットを受けることができます。

ただ、それでも同一ディレクトリ上にユーザー情報が混在する形になるので、当然異なるABPを持つユーザー間でも組織内として扱われますし、名前解決もします。ABRグループをまたいだグループを作成した場合は向こう側の組織で所属しているグループメンバも分かる形になります。セキュリティ的な意味での厳密な分割というよりは、基本的には使い勝手の面での分割ととらえるのが良いかと思います。

以前の投稿で、オンプレミスのExchange管理コンソールからExchange 2013ベースの新しいOffice365のテナントに接続できないという話をしたかと思います。

新たにオンプレミスのExchange 2010 SP3がリリースされたので、接続を試みてみました。

接続できました！

残念ながら、操作可能な機能は既存のテナントへの接続に比べると制限されるようです。従来は、組織の構成の方も触れましたが、今回は受信者の構成しか触れません。

リモートドメインやトランスポートルール、OWAMailboxPolicyや保持ポリシーなどは触れないので、Exchange管理センターかPowerShellから接続する形になります。

（この投稿はプレビュー版での情報を元に作成されています。正式版リリースの際には変更されている可能性もあるのでご注意ください。）

新しいOffice 365について、着々とリリースに向けて情報が公開され始めてきております。今回は、あまり紹介はされていないのですが、個人的には特に中～大規模ユーザーには非常に有益な機能なのではないかと自分的には考えている新機能「アドレス帳のカスタマイズ」について紹介します。

機能自体はオンプレミスでは実装されているのですが、権限の問題の為でしょうか今までのOffice 365（Exchange Online）では公開されておらず、オンプレミスと比較しての制約として明示されていた物が解消された形になります。

具体的にこれがどういう機能かと言いますと、従来のグローバルアドレス帳（ならびにオフラインアドレス帳）では、社内の全アカウントがずら～～～っと同じ画面上に名前順に並んでいたかと思います。

画面で表示が可能な数十ユーザーまでの規模であればこれでも良いのですが、例えばこれが数百や数千の規模になった場合、これを目的別（例えば事業部別やロケーション別）に分割した物を作成したいというニーズが発生します。これを実現するのがグローバルアドレス帳（GAL）のサブセットであるアドレス帳のカスタマイズと呼ばれる機能になります。

1点注意が必要なのは、この機能はあくまで利便性向上の為に分割するものであり、個人が見れる範囲をセキュリティ上限定するという用途のために利用する機能ではありません。

それでは、使い方を見てみましょう。この機能を利用するためには、管理者の役割で「Address Lists」という権限が必要です。プレビュー版では、全体管理者が所属するOrganization Managementにもこの権限が割り当てられていないようなので、まずはこの権限を作業を行う管理者アカウントに付与します。

今回は、Organization ManagementにAddress Listsの権限を付与します。【アクセス許可】【管理者の役割】からリストから選択して追加します。

続いて、アドレス帳を作成するためにPowerShellに接続します。新しいバージョンのExchange Onlineに接続するには、最後のImport-PSSessionのところに-AllowClobberを付けて接続します。

$LiveCred = Get-Credential
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $LiveCred -Authentication Basic -AllowRedirection
Import-PSSession $Session -AllowClobber

ここで、作成するカスタムアドレス帳について少し解説します。アドレス帳自体は、Company（会社）、Department（部門）、StateOrProvince（都道府県）またはCustomAttribute1-15（カスタム属性）やその他Exchange関連属性をベースに作成します。各オブジェクト（ユーザーメールボックスやリソースメールボックス、グループ、メール連絡先など）に応じて入力可能な項目が異なるため、統一的なリストを作成するために、全種類のオブジェクトで利用可能なカスタム属性（15+5個存在します）を利用する事が多いです。

ただし、外部連絡先のメールアドレスは一意である必要があるので、例えばContoso、Fabrikamの両社に共通する社外の取引先などを追加しようとした場合にアドレス重複で追加できなません。実際の運用では両者のリストに含める必要があるオブジェクトについては、もう少し工夫が必要な場合もあります。（※2013/3/3注 Set-MailContactコマンドで外部連絡先にも拡張属性がセットできたので修正します）

ここでは、CustomAttribute1に会社の属性を1…Contoso社、2…Fabrikam社と事前に入力しているとします。-Containerオプションは、階層構造で親となるアドレス帳を指定できます。

New-AddressList -Name "All Contoso List" -RecipientFilter '((Alias -ne $null) -and (CustomAttribute1 -eq ''1''))'
New-AddressList -Name "Contoso Rooms" -RecipientFilter '((Alias -ne $null) -and (((RecipientDisplayType -eq ''ConferenceRoomMailbox'') -or (RecipientDisplayType -eq ''SyncedConferenceRoomMailbox'')) -and (CustomAttribute1 -eq ''1'')))' -Container "All Contoso List"
New-AddressList -Name "Contoso Users" -RecipientFilter '((Alias -ne $null) -and (((((ObjectCategory -like ''person'') -and (ObjectClass -eq ''user'') -and (-not(Database -ne $null)) -and (-not(ServerLegacyDN -ne $null)))) -or (((ObjectCategory -like ''person'') -and (ObjectClass -eq ''user'') -and (((Database -ne $null) -or (ServerLegacyDN -ne $null)))))) -and (CustomAttribute1 -eq ''1'')))' -Container "All Contoso List"
New-AddressList -Name "Contoso Groups" -RecipientFilter '((Alias -ne $null) -and (ObjectCategory -like ''group'') -and (CustomAttribute1 -eq ''1''))' -Container "All Contoso List"
New-AddressList -Name "Contoso Contacts" -RecipientFilter '((Alias -ne $null) -and (ObjectCategory -like ''person'') -and (ObjectClass -eq ''contact'') -and (CustomAttribute1 -eq ''1''))' -Container "All Contoso List"
New-AddressList -Name "All Fabrikam List" -RecipientFilter '((Alias -ne $null) -and (CustomAttribute1 -eq ''2''))'
New-AddressList -Name "Fabrikam Rooms" -RecipientFilter '((Alias -ne $null) -and (((RecipientDisplayType -eq ''ConferenceRoomMailbox'') -or (RecipientDisplayType -eq ''SyncedConferenceRoomMailbox'')) -and (CustomAttribute1 -eq ''2'')))' -Container "All Fabrikam List"
New-AddressList -Name "Fabrikam Users" -RecipientFilter '((Alias -ne $null) -and (((((ObjectCategory -like ''person'') -and (ObjectClass -eq ''user'') -and (-not(Database -ne $null)) -and (-not(ServerLegacyDN -ne $null)))) -or (((ObjectCategory -like ''person'') -and (ObjectClass -eq ''user'') -and (((Database -ne $null) -or (ServerLegacyDN -ne $null)))))) -and (CustomAttribute1 -eq ''2'')))' -Container "All Fabrikam List"
New-AddressList -Name "Fabrikam Groups" -RecipientFilter '((Alias -ne $null) -and (ObjectCategory -like ''group'') -and (CustomAttribute1 -eq ''2''))' -Container "All Fabrikam List"
New-AddressList -Name "Fabrikam Contacts" -RecipientFilter '((Alias -ne $null) -and (ObjectCategory -like ''person'') -and (ObjectClass -eq ''contact'') -and (CustomAttribute1 -eq ''2''))' -Container "All Fabrikam List"

これで、All Contoso Listをトップの階層とするContosoのみのグローバルアドレス帳とAll Fabrikam ListをトップとするFabrikamのみのグローバルアドレス帳が作成されます。残念ながらOWAでは階層構造は表現されませんが、Outlookの中では階層的に表示されます。

1点TIPSとして紹介しますが、新規でカスタムアドレス帳を作成したあと、その反映までに非常に（何日もかかる場合も）時間が掛かります。オンプレミスの環境では通常Update-Addresslistコマンドで手動更新を行いますが、このコマンドは現時点で開放されていないようです。

この為、カスタムアドレス帳を作成した場合、それに該当するオブジェクトの何かの属性（例えばCustomAttribute15）をダミーの値に変更してオブジェクトに手動で更新をかけてあげれば即時に反映されます。

Get-Mailbox | Set-Mailbox -CustomAttribute15 0
Get-DistributionGroup | Set-DistributionGroup -CustomAttribute15 0

次はアドレス帳ポリシーについて紹介しようと思います。

あまりアナウンスはされていませんが、現行のOffice365のExchange Onlineは、オンプレミス用のExchange 2010の管理コンソール（EMC）から接続して（オンプレミスにExchange Serverが無い場合でも）管理を行うことができます。

これは、Exchangeコントロールパネル（ECP）からは設定できないような詳細な設定だが、PowerShellで設定しないといけないというのは敷居が高いと感じる方などにとっては良い手段になっておりました。

Office 365体験記 – フィルター、アーカイブ…、Exchange Onlineの管理

現在プレビュー中の次期Office365は、Exchange2013をベースとして動作しています。そして、Exchange2013からはExchangeの管理インターフェイスは、現在のECPをベースとした「Exchange管理センター(EAC)」と従来からの「Exchange管理シェル（EMS）」のみになり、EMCは提供されなくなりました。

試しに、オンプレミスのExchange2010のEMCからアクセスしようとしてみても、接続に失敗してしまいます。また、従来の移行時の設計思想からすると、新旧バージョンの混在の場合「メールボックス移行前のユーザー→旧バージョンの管理ツール」「メールボックス移行後のユーザー→新バージョンの管理ツール」という形での管理になっていましたので、おそらくExchange2010のEMCからExchange2013は管理できないと思った方が良いかもしれません。

とはいえ、次期のExchange管理センターは意外と良い出来で、ECPをベースとしながらも多くの設定をWebベースでできるようにし、利用度の低いコマンドをそぎ落とし、シンプルで分かりやすい構成になっていると思います。今まではECPからは設定できず、PowerShell（EMS）からしか設定出来なかった項目の多くがWeb上から設定できるようになりました。

という訳で、今Exchange管理コンソールを利用されている方は、バージョンアップ後に新しいインターフェイスに頑張って慣れて貰うか、PowerShell（EMS)は変わらないので今のうちからそちらに習熟しておくか…どちらかがよろしいのではないでしょうか。

次期Office365は現在プレビュー中です。GAが待ち遠しいですね。

最近久しぶりにドメインの設定を確認していたところ、独自ドメインを利用する際に必要なDNSレコードが変更されていることに気がつきました。

変更になったところは、Exchange Onlineを利用する際に利用するTXTレコードでSPFレコードと呼ばれている物です。これは、ドメインの所有者がメールサーバのIPアドレスを明示し、公開することによって、その他のアドレスから送信されるメールをspamである、もしくはspamの可能性が高いということを示す物です。

旧）v=spf1 include:outlook.com ~all

新）v=spf1 include:spf.protection.outlook.com -all

ここで、主な変更点は2つです。①対象となるIP帯（CIDR）が一部変更になっている　②~all（弱い失敗）が-all（失敗）になったということです。

①については、現時点においては後述の通りほとんどIP帯が同じ為に、しばらくの間は問題ないかもしれません。とはいえ、いつまで両側のドメインが同じ設定で更新されていくか分かりませんので、早めに切り替えた方が良いかもしれません。

②については、少し注意が必要です。というのは、この設定は「Office365で指定しているIP帯以外からはこのドメインのメールは送信されないので、受信拒否をして下さい」という意味になります。この為、メール移行が完全に完了していない（未だ古いメールサーバを利用して送信しているユーザーがいる）場合や、独自ドメインを利用したシステムメールやメールマガジンの発行など、Office365以外からそのドメインのメールを送信する環境の場合、SPFに対応したメールサーバ宛にはDNSを切り替えた瞬間にメールが送れなくなってしまいます。

DNSの切り替えは、その実施する内容について十分吟味し、慎重に行いましょう。

以下が現時点での新旧のSPFの比較です。重複しているところを青色で表記していますがメインとなっているアドレス帯は同じようですが、一部のアドレス帯は異なるようですね。ただ、わざわざ変えてくるということは、今後Exchange Online Protection（旧FOPE）とOutlook.comなどのサービス間で今後サーバ群を変えてくるつもりということなのでしょうかね？

Continue reading →

この投稿は、Office365 Advent Calendarに参加しています。

Office365への導入ですが、実際に行う場合はどのように進められてますでしょうか。勿論、マイクロソフトやパートナーに依頼するのが楽かとは思いますが、予算的、もしくは期間的な問題などで自分たちで移行をしなくてはいけないパターンもあるかと思います。

今回は、数人～数百人程度の規模までのケースとして、基本的な移行パターンを少し詳しく書いていこうと思います。

まずは、ケースとする環境の説明からです。現在、既存のメールサーバに対して各ユーザーはOutlook 2010から利用してアクセスしている状態を想定しています。この環境をOffice365のExchange Onlineに移行してみたいと思います。

まず、何はともあれOffice365を申込みます。とはいっても、いきなり本契約するのではなくまずはテスト用に無料の試用版をWebから申し込んでスタートしても大丈夫です。もちろん、お金を払って本契約に移行する場合も試用の際に利用していたデータは保持されます。個人的には、値下げもされて価格差も少なくなったので、特に問題がないのであれば、サポート有りのEプランの方をお勧めします。

まず最初にやる作業としては、自社で利用しているドメインをOffice365でも利用できるように認証を行います。過去の記事がいくつか参考になるかと思います。プランEの場合はドメインの用途にはExchange Onlineにチェックを入れます。

• Office365を独自ドメインで利用する
• Office365を独自ドメインで利用する（プランP） ※プランPの場合はネームサーバを変更しないように気をつけて下さい。

そして、最初に基本的な検証項目である「そもそも社内の環境から利用できるのか」「使い勝手はどうか」「移行はできるか？」などを行うある程度ITリテラシーのある管理者を初めとしたメンバーを選出します。試用版を利用するので、基本的には最大25名です（後述する方法を先行して利用するなら人数制限無し）。

実際にメールアカウントを追加する前に、いくつか準備を行う必要があります。

①ドメインの管理画面に出てくる情報を元に、独自ドメインにautodiscoverのCNAMEレコードを追加する（後ほどのOutlookのセットアップ作業で必要になります）

②Exchange Onlineの管理画面で[メールの制御]-[ドメインと保護]から、独自ドメインの種類を[ホスト]から[共有]に変更します。これを行うことにより、Office365から既存のメールサーバ上のユーザーへのメールの送信が可能になります。

③既存のサーバーから送信（もしくは転送）されてくるメールが迷惑メールとして拒否されないよう、FOPE（Forefront Online Protection for Exchange）に既存サーバ０のIPアドレスをホワイトリストとして登録をします。許可のポリシールールを作成するか、受信コネクタを作成します。

これが完了した段階で、試験用ユーザーのアカウントを作成します。アカウントを作成して試用版のサブスクリプション割り当てたあと、スムーズに検証ができるように以下のことを行います。

④Exchange Onlineのユーザーの管理画面の[メールオプション]から、独自ドメイン以外のメールアドレス（例えば、最初から設定されているxxxxx.onmicrosoft.com）を「その他の電子メールアドレス」として設定する。このアドレスは受信用のアドレスとして構成されます。

⑤既存のメールサーバに、テストユーザー宛に届いたメールを上で設定した@xxxxx.onmicrosoft.comのアドレス宛にメールボックスに残して転送するように設定する。

完了後に、トライアルユーザーのOutlookでExchangeアカウントの追加を行います。基本的にはAutodiscoverで設定できますので、メールアドレスとID/PASSを入力すれば設定が可能です。

結果、クライアントの参照している設定とメールサーバー側のフローは以下の様になります。

• トライアルユーザーのOutlookから、既存メールサーバーとOffice365のメールの両方を見ることができる
• 一般ユーザーのOutlookからは、既存メールサーバーのメールを見ることができる
• 外部から送信されたメールは、既存メールサーバー宛てに届く。そのうち、トライアルユーザー宛のメールは転送されてOffice365のメールボックスにも届く
• 一般ユーザーからトライアルユーザー宛に送信されたメールも、同様に既存メールサーバーとOffice365に届く
• トライアルユーザーが他のトライアルユーザーに送信したメールは、既存メールボックスに届かずOffice365のみに届く
• トライアルユーザーが一般ユーザーに送信したメールは既存メールボックスに届く

ここで注意しなくてはならないのは赤字の部分です。Office365上にメールアドレスの存在するメールは、DNSのMXレコードの設定に関係なく内部と見なされて配送されてしまいます。つまり全てのメールを確認するにはOffice365側のメールを確認しなくてはならないということで、トライアル終了後の移行に対して最も影響します。

言い換えると、移行のためOffice365にメールボックスを作成した後は、既存のメールサーバーにも接続はできますが、Office365のメールボックスを見に行くようにしないと見落とすメールが出てきてしまうということです。

さて、この状態になればある程度通常の業務のメールもトライアルユーザーのOffice365のメールボックスの方にも届くようになりますので、ある程度実状に近い形でテストが行えるかと思います。一般的には以下の項目などを確かめると良いかと思います。

• 受信トレイルール含めたメールソフトとしての使い勝手
• 他人とのスケジュールの共有や会議室予約
• 外出先からのOWAの接続
• スマートフォン（ActiveSync）空の接続

さて、これが終わった後はいよいよ移行です。予算的に可能であれば、もちろんこの時点で全社員分のサブスクリプションを購入しても良いかと思いますが、まだ不安であったり、展開に1ヶ月かかるなどで少しでも費用を削減したいということであれば、以下のような手段を取ることも可能です。2013/3/4 注）Exchange管理ポータルからユーザーを作成する手順は新しいOffice365ではサポートされなくなりました。サブスクリプションを購入の上、管理者ポータルからユーザーを作成下さい

• Office365ポータルではなくExchange Onlineからユーザーを作成する（個別に新規作成もしくはCSVからのインポート）
• 猶予期間（30日間）以内にメールの移行を行い、完了後にサブスクリプションを購入して割り当てる

基本的にはこれでも一通りのことができるかと思いますが、一点、制約事項としてはこの方法で作成したユーザーはOffice365ポータル（https://portal.microsoftonline.com）に接続しようとするとサブスクリプションが割り当てられていないというエラーが出てアクセスできません。この為、OWAの試験を行う場合はポータルからではなく、直接OWAにアクセスする必要があります。（http://mail.office365.com/か https://outlook.com/owa/[独自ドメイン名] ）

さて、いよいよ実際の移行となった場合、ユーザーには事前に少なくとも以下の事について周知を行います。

• メールサーバが移行される日程
• 新しいメールサーバの設定方法の手順
• アクセスする際に必要なID/PASS
• 過去や移行期間のメール（既存のメールサーバのデータ）のアクセス、移行方法

そして、移行対象社員が最後にアクセスした後、次に出社する前に以下の作業を実施します。ユーザー数が多い場合は、Office365にメールボックスを作成するのにも時間が掛かりますので、例えば土日で作業して月曜日から新しいサーバを使って貰うよう周知するなどが良いかと思います。

⑦Office365にメールボックスを作成する

⑧Office365に@xxxxx.onmicrosoft.comのアドレスを追加する

⑨移行対象者に、これ以降のメールは新サーバー（Office365）のみに届くという通知メールを送る

⑩既存のメールサーバに@xxxxx.onmicrosoft.comへの転送設定を入れる（残さず転送）

各ユーザーは、移行対象日の朝になったら①Outlookのプロファイル作成　②移行期間中に来たメール（既存メールサーバー）のダウンロード　③必要に応じて過去メールや連絡帳データなどのOffice365へのコピーを行います。

この移行作業を必要な回数繰り返して実施をします。また、合わせて最終作業に向けてMXレコードのTTLの値も短く（例えば1時間）しておきます。全アカウントの移行が終わったら、以下を行います。

⑪MXレコードをOffice365で指示されたサーバに向ける

⑫②で行ったドメインの設定を[ホスト]に戻す

⑬既存のメールサーバを廃止する（合わせて各ユーザーの既存のプロファイルからメールサーバ関係の設定を削除する）

これが一応基本かなとは思っていますが、他にも良いアイディアや懸念事項など有りましたら教えて頂けると幸いです。