Exchange OnlineにOutlook以外のクライアントで接続する場合、Autodiscoverによる自動設定が利用できないため、自分が接続する先のサーバを手動で設定する必要があります。この設定は、一度自分でExchange Onlineにブラウザ（OWA）で接続した上で、設定画面から確認を行う形になります。

ところが、Office365はマルチテナントで構成されているために、そのユーザーがデプロイされる時期によっては異なるサーバ群に配置される場合があり、事前にユーザーに手順を示しておきたい場合などに支障をきたすことがあります。

今回は、管理者がPOP/IMAP/SMTPのアドレスを取得する手法を紹介します。

まず、相手先が1人や少数などの場合。これは、管理者の代理アクセス機能を利用します。OWAにアクセスしたのちに、メニューで自分の管理（もしくは組織の管理）となっているところをクリックし「他のユーザー」を選択して調べたいユーザーを選択します。そして、自分の場合と同じように設定を確認します。

次に、複数のユーザーを一括して調査したい場合などです。

これは、PowerShellを利用します。Exchange Onlineに管理アカウントで接続した後に、Get-CASMailboxコマンドの-ProtocolSettingsオプションを利用して確認します。

$LiveCred = Get-Credential
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $LiveCred -Authentication Basic -AllowRedirection
Import-PSSession $Session -AllowClobber
Get-CasMailbox contoso01 -ProtocolSettings | select *external* | FL

例えば、こうするとcontoso01のIMAP、POP、SMTPの設定がPowerShell画面上で確認できます。

基本的にサーバ名以外はユーザーごとに変更になることはないですので、全ユーザーのサーバ設定一覧をtest.csvというファイルに出力するには、例えば以下のようなコマンドを実施します。（すいません、無理やり整形する為汚いコードになっちゃいました）

$Users = Get-CasMailbox
"UserName,IMAPAddress,POP3Address,SMTPAddress" | Out-File -Encoding default test.csv
ForEach($User in $Users) {
$SvrSettings = Get-CasMailbox -Identity $User.Name -ProtocolSettings
$name = $SvrSettings.Name
$imap = $SvrSettings.ExternalImapSettings.Replace("`r`n"," ").Split(" ") | select -Skip 1 -First 1
$Pop = $SvrSettings.ExternalPopSettings.Replace("`r`n"," ").Split(" ") | select -Skip 1 -First 1
$Smtp = $SvrSettings.ExternalSmtpSettings.Replace("`r`n"," ").Split(" ") | select -Skip 1 -First 1
"$Name,$imap,$Pop,$Smtp" | Out-File -Encoding default -Append test.csv
}

そういえば、新しいOffice365のプレビューテナントではSMTPサーバがPOP/IMAPとは違う smtp.outlook.office365.com に設定されていましたね…本番ではどうなるんでしょうか。

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

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

詳細な実装などについては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で指示されたサーバに向ける

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

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

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

Office365を導入する目的として最も多い要因は、メールシステムの更改かと思います。

各種ドキュメント、書籍や事例などによってかなり多くの情報が得られるようになってきましたが、Office365のExchange Onlineのベースとしているソフトウェア「Exchange Server」は、インターネット上で利用されてきているSendmailやPostfixなどのMTA（メール転送エージェント）と比較して、特徴的な実装となっているところがあります。

ここでは、Office365を導入する前に有益な情報となるよう、一般的なメールシステムと比較してのExchangeの特徴についていくつか記載をさせて頂きたいと思います。

①From詐称ができない

• Exchangeでは、各ユーザーは標準で「自身のプライマリアドレスでメールを送信する権限」を有しています
• 1つのユーザーに対しては、1つの「プライマリメールアドレス」と複数の「セカンダリメールアドレス」を割り当て、メールを受信することができます
• この為、他のユーザーや配布グループなどのアドレスをFromアドレスとしてメールを送信しようとすると、「権限がない」と弾かれます
• 送信者アクセス権（SendAs）という権限を割り当てる事により、Fromアドレスを変更してメールが送信できます。（内部では、そのFromのアドレスのメールボックス経由でメールが送信されるように処理がされます。）
• SendAsは、SMTPプロトコルを使ってメールを送信する場合には利用できません。

②MessageIDが重複するメールは1通しかメールボックスに届かない

• Exchangeでは、短時間（1時間以内）に同一MessageIDであるメールが同じメールボックスに到着した場合、後から到着したメールを重複として破棄します。
• これにより、Toを本人としCcをメーリングリストとして送信されたメールは、Toで直接配送されてきたメールのみ受信され、Ccで展開された後のメールは受信されません。
• メーリングリストでSubjectに通番を付けているような場合、その番号のメールのみ欠落して見えるなどの症状となります。

③メールアドレスの表示名がサーバ側で自動的に書き換えられる

• Exchangeでは、FromやToなどの欄に表示される名前をグローバルアドレス帳の情報によって解決します。
• この為、従来は自身でアドレス帳登録した名前、”舞黒 部長”<maikuro@contoso.com>などを宛先として送付できたのが、自動的に舞黒太郎<maikuro@contoso.com>などの全社的なグローバルアドレス帳に登録されている名前（通常、フルネームをベースとしている値）に自動的に書き換えられて送信されます。
• デフォルトの設定だと、日本語の表記のまま海外のユーザーにも配送されてしまいます。特定ドメイン、もしくは全体に対して明示的に表示名をアルファベット表記に変更できます。変更方法はこちら。
• この処理は、SMTPプロトコルを使ってメールを送信する場合には該当しません。

④MIMEエンコードはExchange外部に出る際に実施される

• Exchange内部では、SMTPで通常利用されるエンコードではなく独自の形式でメールが送受信されます。
• SMTP送信時に必要となるMIMEエンコードなどはクライアントでは必要なく、OutlookやOWAはエンコード処理を行いません。
• エンコードのオーバーヘッド（約3-40%）が必要無い分、SMTPよりネットワークトラフィックは軽くなります。
• Office365は25MBのメールサイズが上限ですが、これはエンコード前の値を仕様として表記した物であり、内部では35MBの容量が設定されています。この為、30MBの添付ファイルはOutlookでは送信できるが、Thunderbirdでは送信できないという事象が発生します。（勿論、外部に送信する際にはエンコードされるので35MBの上限値に引っかかりますが）
• MIMEエンコードされるのは、Exchangeから外部に送信される際に相手先のサーバを自動判定してエンコードが実施されます。
• 外部サーバがExchangeと判定された場合、TNEF形式でメールがエンコードされます。外部連絡先に登録したユーザーにwinmail.datの添付ファイルだけ付いた空メールが届くという事象のはこの自動判定に起因する物です。
• この処理は、SMTPプロトコルを使ってメールを送信する場合には該当しません。

⑤Exchange内部ではMXレコードを参照せずに配信する

• Exchange内部では、他のMTAで権限のあるドメイン（MyDestination）と設定した場合と同様、内部ドメインはDNSを参照しません。
• DNSの代わりに、ActiveDirectoryの中のProxyAddressesの値（プライマリメールアドレス、セカンダリメールアドレス）で一致する物を検索し、有った場合はそのユーザーのメールボックスへの配送を行います。
• 内部ドメインであるが、そのアドレスがADに無かった場合の挙動は、そのドメインの種別によって異なります
  • 「ホスト」 宛先不明としてメールを破棄し、配送不能メール（NDR）を送信元に送ります
  • 「中継」 FOPEからMXレコードを参照して外部に配送します

⑥キャッチオールアドレスは作成できない

• 存在しない宛先宛てのメールを全て特定の受信者（例えば管理者）に送信することはできません。
• オンプレミスのExchange 2010 Serverであれば、キャッチオールメールボックスという物を作成することによって近い機能を実装できますが、Office365では提供されていません。

⑦配布グループは通常メール以外は受け取れない

• 配布グループは仕様上通常配送のメールのみ受け取ることができ、NDRなどは展開することができません。
• この為、配布グループ宛に送信したメールが展開された後に、例えばメンバーの退職、メールボックス溢れなどが有った場合のエラーメールなどは「破棄する」「配布グループの代表所有者に返信」「送信元に返信」の3つの処理しかできず、通常のメーリングリストなどで良く見られる「管理者グループ宛に返信する」という形式は利用できません。（管理者グループを作成したとしても、エラーメールを展開できないからです）

⑧メール以外の情報もメールボックスに格納されている

• 例えば、主要な機能である予定表、タスク、個人の連絡先などはメールボックスの中の特殊フォルダとして管理されています。
• その他、受信トレイルールや宛先情報のキャッシュなど、細かい設定情報などもメールボックス上に存在します。
• これらの情報は、通常のPOP/IMAPなどのクライアントからはアクセスできない為、それらのクライアントでは機能自体を利用する事ができません。
• 「迷惑メール」フォルダに関しては通常メールボックスとしてIMAPからアクセスできますが、POPは受信トレイにしかアクセスできません。この為、POPを常用する場合は定期的にOWAでアクセスして、迷惑メールフォルダの内容を確認（間違えてspamと判定されている物は無いかなど）するという運用が必要になります。

⑨メール送信処理はサーバー（メールボックス）で実施され、送信履歴も残る

• メールをクライアントが送信しようとした場合、その処理は直接送信ではなく「送信フォルダに送信したいメッセージを作成する」という処理になります。
• サーバ側では、定期的に各送信フォルダからメールをピックアップし、送信処理を行います。送信が完了すると、そのアイテムを送信済みフォルダに移動します。
• この為、Exchangeでは受信メールだけではなく、受信メールに関しても全てExchangeサーバ側で保管されています。この仕組みをベースとして訴訟ホールドなどの機能で監査対応などを実施します。
• この処理は、SMTPプロトコルを使ってメールを送信する場合には該当しません。この為、Outlook/OWA以外を利用する場合、一部（内→外）のメールの監査ができない可能性がございます。

⑩送ったメールのリボーク（取り消し）ができる

• 送信済みメールを取り消したり置き換えたりすることができます。
• 例えば、送り先を間違えた場合や添付ファイルを忘れた場合など、あわてずにOutlookクライアントから送信済みアイテムを開き、「メッセージの取り消し」を行うと、自動的にアイテムを削除したり置き換えたりしてくれます。
• 相手先が未開封（もしくはPOPなどの場合は未ダウンロード）だった場合に限ります。

いかがでしたでしょうか？

知らない機能であったり、移行してみて少し挙動が変だなと思うことがあるような要因になるようなものを集めてみましたが、他にも「こんな事あるよ」とか「こうなってるのはどうなの？」とか有りましたら教えて頂けると幸いです。

Exchange Onlineは、Exchange Server 2010をベースに構成されております。この為、基本的な機能はオンプレミスのExchangeと同じですが、細かい使い勝手で差分があります。

クラウドサービスであるOffice365を使う上では、導入前にその差分について十分検討し、Fit&Gapを行っていくことが重要です。機能一覧上は一見オンプレミスと同じだし、価格も安いので…というだけで導入を決めてしまうとあまり良い結果を生まないと思います。

ここでは、構築運用実績のあるExchangeエンジニアの立場として、オンプレミスのExchange 2010と比較した場合のクラウド（Office 365）のExchange Onlineについて、いくつかのポイントに絞って考えてみたいと思います。

詳細はExchange Onlineサービス詳細の巻末の機能比較表をご覧下さい。

①インターネット上にあるパブリッククラウドサービスである

• インターネット接続が必要
  • クライアントから直接インターネット上の名前解決が必要
  • クライアントからインターネットへのIPルーティングが必要
• 内部にメールサーバを置く場合に比べ、回線の帯域がより多く必要
  • 内部メールの送受信も経由する為
  • 1通のメールに複数の宛先や配布グループが含まれている場合の、展開後の個々での受信処理
• 通常はPIPからGIPへのNAT（NAPT）が必要
  • TCPポートの割り当て数に制限が有るので、推奨は2000クライアントごとに1GIP
• URLは他のテナントと共有
  • 他テナントのExchange Onlineとドメイン上は区別が付かない。「インターネット上のWebメールサービスは利用不可」などのコンテンツフィルタルール不可

②シェアドサービスであり、設定変更（カスタマイズ）できる範囲に制限がある

• アドレス帳のカスタマイズ
  • 階層型アドレス帳の利用不可
  • 分割やフィルタ不可（部門毎のアドレス帳の作成や、グループ企業利用の際の公開範囲を自社のみへの限定など）
• 送受信コネクタのカスタマイズ
  • 匿名アクセスを許可した受信コネクタ（認証無しのSMTP接続が可能）の作成不可
  • システムメールの送信は認証無しでは不可（内部向けのみの場合は送信先をFOPEのアドレスにして外部メール扱いで対処するなど可能）
• パブリックフォルダ
  • パブリックフォルダ利用不可
  • Outlook2003からのMAPI接続不可（予定表などの機能利用不可）
• 閾値制御
  • 公平制御の為、送信速度や宛先数などに上限値の制限が掛かっている（一部SRにて緩和可能）
  • NW帯域がLANに比べると遅い。特にGB単位のデータ移行やコピーは経験上2GB/時間程度を目安にして、気長にやった方がいい。
• ログファイル
  • メッセージ追跡ログやパフォーマンスモニタなど、サーバの生ログデータを利用した、メール関連の統計情報（送受信通数、サイズ、トラフィック量、内・外区分など）が取得できない
  • メッセージ追跡ログの取得期間の延長ができない
• セキュリティ
  • 送信元のIPベースの制限不可
  • 別AD組織なので、シングルサインオンするにはADFSが必要
  • 証明書ベースの認証不可

③クラウドサービスであり、オンライン側で運用され、随時更新される

• メジャーバージョン含めて、バージョンアップされる
  • メンテナンス事前告知は原則有る。仕様変更は全テナント完了後の場合が多い
  • バージョンアップなので基本的に改善
  • 変更したくない場合でも原則実施される
  • 要件に合わせてクライアントも随時バージョンアップする必要がある。場合によっては新規購入を含めた処理が必要。
• コミュニケーション
  • メンテナンスは基本的に一方的な通知によって行われる。サービス断がある場合でも自社で定めたメンテナンスウィンドウなどの考慮は行われない
  • 故障発生時も同じく基本的にポータルにて通知される。故障問い合わせは受け付けて貰えるが、実際のデータセンタでの対応状況などの確認は困難
  • 電話での受付はあるが、オンサイトでの対応は原則不可
• 随時サービス仕様が変わる
  • 接続先サーバーのURL、IPアドレスなどは仕様変更や収容変更、増設などによって随時変更される
  • IP情報は公開される。比較的頻繁に追加され、IPベースのフィルタ制御は推奨されていない

簡単に並べるとこんな所でしょうか？

これだけ書くと、デメリットばかり並べているように見えますが、これだけ多くのお客様がOffice365を導入しているという事例などを見ますと、代替案などを検討して上手く落としどころを作ったり、サービスの方に合わせて自社の運用を変えたり、割り切ったり…という決断をされたお客様は結構多いということなのではないでしょうか。

BPOS-S ではSRで受信トレイルールの上限値を増加することが可能でしたが、Office 365では当初64KBに上限値が設定され、その上限値を上回る受信トレイルールを作成することはできませんでした。

この為、作成の仕方によっては（例えば、多数のメルマガを受信していてそのメルマガ毎に専用のフォルダに振り分ける、ある条件に合致したメールを特定の携帯などのアドレスに転送する、などの使い方などをされている場合）、この上限値に引っかかって新規で受信トレイルールを作成できなくなることがございました。

Office365サービスの改訂により、PowerShellが利用可能な場合、この制限を管理者が緩和できるようになったようなのでやり方を紹介します。

Set-Mailbox username@contoso.com -RulesQuota 256KB

このコマンドにより、username@contoso.comの受信トレイルールのクォータサイズが標準の64KBから最大値（256KB）に拡張されます。単純に計算して4倍の受信トレイルールを作成することが出来るわけです。

なお、テナントによってはまだ実施できない可能性も御座いますので、その場合は修正が適用されるまでお待ち下さい。