オンプレミス x Exchange Server 2016 という選択肢Track3: Office 365/Exchange

Interact x Cloud Samurai 2016 Summer

Microsoft MVP - Office Servers and Services渡辺 元気

自己紹介

名前： 渡辺 元気（わたなべ げんき）

職業： 通信事業者でクラウドサービスの開発

blog： 日々徒然 http://blog.o365mvp.com/ （Office 365、Exchangeの技術ネタを中心に公開）

Office 365 Community / Twitter / Facebook：genkiw

Microsoft MVP for Office Servers and Services

注意事項

本資料については、個人で準備した環境において、個人的に実施した検証結果を基に記載しております。

あくまで個人の意見・見解であり、所属する会社・組織及びマイクロソフト社とは一切関係はございません。

また、本資料の内容ならびに閲覧により生じた一切の問題及び不利益について、発表者は一切の責任を負う事はできませんのでご了承ください。

1.Exchange 2016の新機能Exchange Server 2016からの新機能や変更点

2013(CU12)と2016(CU1)のExchange管理シェル

【削除】1

Test-Message

【追加】44

Add-MailboxLocation

Get-MailboxLocation

Get-MailboxPreferredLocation

Get-ClientAccessService

Set-ClientAccessService

Get-CompliancePolicyFileSyncNotification

New-CompliancePolicyFileSyncNotification

Remove-CompliancePolicyFileSyncNotification

Get-ConsumerMailbox

Set-ConsumerMailbox

Get-MailboxDatabaseRedundancy

Get-MailboxServerRedundancy

Get-SubmissionMalwareFilteringServer

Set-SubmissionMalwareFilteringServer

Get-UnifiedAuditSetting

Set-UnifiedAuditSetting

Get-LAMDefinitions

Get-LAMResults

Get-ProcessInfo

Get-RbacDiagnosticInfo

Get-TimeRange

Remove-AuditStubFolder

Remove-SyncMailPublicFolder

Start-AuditAssistant

Test-DataClassification

Test-TextExtraction

Get-ComplianceServiceVirtualDirectory

Get-LogExportVirtualDirectory

Get-MailboxDeliveryVirtualDirectory

Get-OutlookServiceVirtualDirectory

Get-RestVirtualDirectory

New-ComplianceServiceVirtualDirectory

New-MailboxDeliveryVirtualDirectory

New-OutlookServiceVirtualDirectory

New-RestVirtualDirectory

Remove-ComplianceServiceVirtualDirectory

Remove-MailboxDeliveryVirtualDirectory

Remove-OutlookServiceVirtualDirectory

Remove-RestVirtualDirectory

Set-ComplianceServiceVirtualDirectory

Set-LogExportVirtualDirectory

Set-MailboxDeliveryVirtualDirectory

Set-OutlookServiceVirtualDirectory

Set-RestVirtualDirectory

Technet記載有り

1章のまとめ

Exchange Server 2013と比較して特筆すべき差は無い

• バージョンは15.1

• インストールフォルダもV15のまま

1.1.役割の統合

エッジトランスポート

クライアントアクセス

ハブトランスポート

メールボックス

ユニファイドメッセージング

エッジトランスポート(SP1-)

クライアントアクセス

エッジトランスポート

メールボックスメールボックス

2007/2010 2013 2016

1.2.セットアップ

▪ 前提条件の機能を自動的に追加する /InstallWindowsComponents スイッチの追加

▪ 再起動が必要な場合はそこで一度エラー終了する

▪ .NET Frameworks 4.5.2とUnified Communications Managed API (UCMA) 4.0 は別途手動

▪ オススメ: Install Exchange 2016 Prerequisites v1.3 ( https://gallery.technet.microsoft.com/office/Install-Exchange-2016-48983e13)

1.2.セットアップ

▪ Exchange 2016 CU1から.exe→.isoに

▪ 2013/2016 RTM

▪ .exe形式 1.5～1.7GB程度

▪ 2016 CU1,CU2

▪ .iso形式 6GB超

▪ 解凍不要、片面1層式DVDには入らない

▪ .isoマウントしてそのまま実行すると、言語設定を認識しない日本語にしたい場合はローカルHDDにコピーして実行

1.3.Outlook on the Web（OotW、旧OWA）

▪ iOSとAndroidの両端末のプラットフォーム固有のエクスペリエンス

▪ 電子メール機能（1行表示、アーカイブ、絵文字、メッセージの削除・移動など）

▪ 予定表（電子メールによるリマインダ、会議出席依頼の候補表示、検索の向上）

▪ 検索候補と絞り込み

▪ リンクのプレビューやインライン動画

▪ ピン止め及びフラグ付け

1.4.Outlook

▪ データのセキュリティ向上

▪ Windows/Android/IOS上のOutlookクライアントからのActive Directory Authentication Library(ADAL)の認証モデル(modern authentication)のサポート

▪ MAPI over HTTP

▪ デフォルトで有効化されて既定の接続方式に

▪ ネットワークの再接続性の向上

▪ 互換性確保の為、2013混在環境、もしくはOutlook Anywhereの有効化されていない2010との混在環境では有効化されない

▪ キャッシュモードでの検索の統合（Outlook2016のみ）

▪ Outlook 2016 + キャッシュモードでの検索はサーバー側のFASTを用いて高速に実行される

1.5.ドキュメントコラボレーション

▪ SharePoint Online / SharePoint 2016との統合

▪ OneDrive for Businessへの添付ファイルの自動アップロード

▪ Office Online Server(OOS)

▪ 旧Office Web Apps Server

▪ WebReadyは実装されなくなったので、ドキュメントプレビューを行うにはサーバー別立てが必要

1.6.ハイブリッド構成

▪ ハイブリッド構成ウィザード(HCW)がサーバーにインストールされたプログラムではなく、Webからダウンロードして利用する形式に

▪ Office 365側の仕様変更等への柔軟な対応

▪ 診断やトラブルシュート機能の高度化

1.7.メッセージングポリシーとコンプライアンス

▪ データ損失防止

▪ 新たなトランスポートルールによるより柔軟なルール作成条件 ：「任意の添付ファイルに次のプロパティがある場合（次のいずれかの単語を含む）」アクション：「受信者にメッセージで通知する」アクション：「インシデントレポートを生成し送信する」

▪ インプレース保持

▪ パブリックフォルダのコンテンツがインプレース保持の対象

▪ 検索インデックスの作成できないファイルは保持されない

▪ コンプライアンス検索

▪ 非常に大規模の検索を1回の検索で実施可能

1.8.ワークロードの削減

▪ ディスクのIOPSをExchange 2013から更に22%改善

▪ 高負荷時に遅延再生を構成しているデータベースのコミットを遅延

▪ DAGの複製トラフィックを約20-30%削減

▪ インデックス生成の元データの転送が無くなったため

2.Exchange 2016の詳細Exchange Server 2016の詳細

2.1.システム要件

OS メールボックス、エッジトランスポートWindows Server 2012 R2 Standard / Datacenter

Windows Server 2012 Standard / Datacenter

管理ツールWindows Server 2012 R2 Standard / Datacenter

Windows Server 2012 Standard / Datacenter

Windows 10（64bit版）、Windows 8.1（64bit版）※いずれもServer CoreモードはNG

CPU Intel 64 / AMD 64※Itanium IA64はNG、物理構成の場合HyperThreading Off推奨

メモリ メールボックス：最小8GB エッジトランスポート：最小4GB※推奨される（効率的に利用される）最大容量は96GB

ページングファイル 搭載RAM+10MB以上※32GB以上の場合は32778MB

ディスク領域 Windowsシステムドライブ: 200MB以上の空き容量Exchangeをインストールするドライブ: 30GB以上メッセージキュー：500MB / UM言語パック1言語ごと：500MB

Exchange Server

2.1.システム要件

ドメインコントローラ 全てのドメインコントローラが以下のいずれかであること• Windows Server 2012 R2 Standard / Datacenter

• Windows Server 2012 Standard / Datacenter

• Windows Server 2008 R2 Standard / Enterprise / Datacenter

• Windows Server 2008 Standard / Enterprise / Datacenter

サイト Exchange Server専用のサイトを配置するデータセンタごとに作成することが推奨

グローバルカタログ Exchange Serverを展開するサイト毎に必要※RODCは非サポート

フォレスト Windows Server 2008以上の機能レベル

Active Directory

【参考】ドメインの機能レベルをWindows 2003 から引き上げる場合の注意点https://blogs.technet.microsoft.com/exchangeteamjp/2015/03/04/windows-2003/

対処: 全てのドメインコントローラでKDCサービスを再起動

2.1.システム要件

.NET Framework 4.5.2以降が必要CU2から4.6.1 + Hotfix (KB3146715)がサポート

IPv6 IPv4と共に有効化の場合のみサポート※無効化しないことを推奨

仮想化 Windows Server 2012 R2 Hyper-V

Windows Server 2012 Hyper-V

Microsoft Hyper-V Server 2012 R2

Microsoft Hyper-V Server 2012

Windows Server Virtualization Validation Programに記載されたサードパーティ製のハイパーバイザ

【参考】Exchange 2016 virtualizationhttps://technet.microsoft.com/ja-jp/library/jj619301(v=exchg.160).aspx

その他

2.1.システム要件

Outlook Outlook 2010 SP2(KB2956191 + KB2965295)以降Outlook 2013 SP1(KB3020812)以降Outlook 2016

Outlook for Mac 2011以降Outlook for Mac for Office 365

※Outlook 2003,2007、Outlook for Mac 2008は非サポート

POP3,IMAP4,SMTP POP3、IMAP4、SMTPをサポートするメーラー

Webブラウザー Microsoft Edge

Internet Explorer 11

Google Chrome 44またはそれ以降Firefox 39またはそれ以降Safari 8またはそれ以降（OS X/iOSのみ）

モバイル端末 Exchange ActiveSyncプロトコルをサポートする端末

クライアント

2.2.アーキテクチャ

▪ サーバーの役割

▪ エッジを除く全ての役割がメールボックスサーバに統合され、以下の2つのみになった

▪ メールボックスサーバー

▪ エッジトランスポートサーバー

▪ 設計思想

▪ 大きく以下の3つの設計思想に基づいて設計

▪ スケーリング

▪ ハードウェアリソースの有効活用

▪ 障害分離の単純化

▪ 役割統合によるメリット

▪ アップグレードの順番を任意に決められる

▪ 全て同一のスペックのサーバにできる

▪ サーバ間の負荷分散によりスケーラビリティ向上 CAS HUB MBX MBX

Exchange 2010 Exchange 2016

2-3.クライアントアクセスサービス(CAS)

▪ Outlookクライアント

▪ RPC(MAPI)接続の廃止

▪ MAPI over HTTPまたはOutlook Anywhere(RPC over HTTP)のみ

▪ RPC over HTTPは重視されなくなった

▪ プロファイル作成にはAutodiscoverの使用が強く推奨

▪ 接続先はユーザーごとに異なる[ExchangeGUID]@contoso.com

▪ Outlook 2016からはAutodiscoverのみサポート

2-3.クライアントアクセスサービス(CAS)

▪ MAPI over HTTP

▪ Exchange Server 2013 SP1以降で実装されたプロトコル

▪ 既定で有効化（2013との混在組織、Outlook Anywhereが有効でない2010との混在組織の場合を除く）

▪ 目的

▪ 再接続性の向上による接続の信頼性と安定性の向上

▪ ハイバーネーションからの復帰やローミング（無線／有線）発生時の再接続速度の改善

▪ セッション切断時も15分以内の再接続の際に同一のCookieでセッションを再利用可能

▪ 有効化

▪ Exchange 2013においては有効化単位は組織全体、クライアント側を無効化するにはOutlookのレジストリ

▪ Exchange 2016からはSet-CASMailbox -MapiHttpEnabledでユーザーごとに制御可能となり、より柔軟なテスト、展開が可能に

HTTPS

MAPIRPC

HTTPS

MAPI

RPC over HTTP MAPI over HTTP

2-3.クライアントアクセスサービス(CAS)

▪ Autodiscover

▪ Exchange 2010からの変更点

▪ Exchange 2013からEXHTTP、mapiHttpノードが追加

▪ 以前のEXPR、EXCHは使用されなくなった

▪ Exchange 2010/2013との混在環境

▪ Exchange 2010/2013ユーザーはExchange 2016でAutodiscoverを生成できる

▪ Exchange 2013/2016ユーザーはExchange 2010でAutodiscoverを生成できない（上位へのProxy）

▪ Exchange 2016ユーザーはExchange 2013でAutodiscoverを生成できる（2013/2016は相互運用可）

Exchange 2010

Client Access

Exchange 2013

Client Access

Exchange 2016

Client Access

OK

OK OK

OKNG

Proxy : NG

2-3.クライアントアクセスサービス(CAS)

▪ HTTP Proxy

▪ クライアントからのアクセスを一度CASが受けて、適切なMBXにルーティングする処理

▪ クライアント側のパーシステンスは不要

▪ ADサイトをまたいでもProxy処理する

▪ Exchange 2013 CASはExchange 2016に処理をProxyできる

ADサイト境界2010 MBX

2010 CAS

2013 MBX

2013 CAS

2016 MBX

LB

DB

IIS

HTTP Proxy

Protocol Head

2016 MBX

DB

IIS

HTTP Proxy

Protocol Head

2016 MBX

DB

IIS

HTTP Proxy

Protocol Head

2-3.クライアントアクセスサービス(CAS)

▪ メールボックスアンカー

▪ リクエストを転送する先のメールボックスサーバーを探し出すプロセス

▪ ①IISでユーザーを認証 → ②ADでSID検索 → ③Active ManagerでDBがマウントされているMBXを確認 → ④転送先のサーバのURLを生成（https://[Mailbox FQDN]:444/OWA/など）

▪ Exchange 2010との混在環境の場合は、MBXと同一ADサイト内のCASサーバのFQDNに対してProxy接続する。

▪ 接続可能なCASを管理するため、死活監視（メンテナンスやFirewallなどの事情でProxy先から除外したい場合は2010CASをSet-ClientAccessServer -IsOutOfServiceで除外可能）

:443

FrontEnd

:444

BackEnd

2-3.クライアントアクセスサービス(CAS)

▪ Proxyとリダイレクト

▪ プロトコルと条件によりProxy処理もしくはリダイレクト処理

プロトコル 処理

OWA/ECP ・接続先が別ADサイト、かつExternal URLの設定がある場合※External URLが同一の場合除く）：リダイレクト・その他：Proxy

EAS Proxy

OutlookAnywhere Proxy

Autodiscover Proxy

EWS Proxy

POP/IMAP Proxy

OAB Proxy

2-4.メールボックスサービス(MBX)

▪ ストアプロセス

▪ Exchange 2010までは単一のExchange Information Storeサービス(Store.exe)がクラッシュすると全DBが影響を受けていたが、2013からはDBごとにワーカープロセスになり、影響範囲を極小化

▪ DB作成やコピー追加の際のInformation Store再起動要求はExchange2016でも変わらず

2-4.メールボックスサービス(MBX)

▪ IOPSの削減

▪ Exchange 2013から更に22%改善

▪ Exchange 2016より実装されたIO待ち時間に基づく動的なログ再生の制御による改善（遅延DAGを構成していない場合は大きな変化無し）

2-4.メールボックスサービス(MBX)

▪ 検索インデックスの生成方法の変更による複製トラフィックの削減

▪ Exchange Server 2010/2013：検索インデックスの作成の基となる情報はActive側から読み取る

▪ Exchange Server 2016：コピーされたPassive側の情報を元に検索インデックスを作成するため、その情報取得にかかるトラフィックが発生しない

▪ およそ2-30%程度の削減

DB1

DB1

Index

DB1

DB1

Index

PassiveActive

DB1

DB1

Index

Passive

DB1

DB1

Index

Passive

DB1

DB1

Index

DB1

DB1

Index

PassiveActive

DB1

DB1

Index

Passive

DB1

DB1

Index

Passive

Exchange 2010/2013 Exchange 2016

2-4.メールボックスサービス(MBX)

▪ インプレースアーカイブ

▪ Enterprise CALが必要

▪ デフォルトで100GBのサイズ

▪ 自動拡張機能が備わっていて、クォータの制限に達すると50GB単位でアーカイブのサイズを自動的に増加させる

▪ 大容量メールボックスのサポート

▪ 100GB以上のサイズ

▪ 100万以上のアイテムの処理

2-4.メールボックスサービス(MBX)

▪ データベース可用性グループ(DAG)

▪ Exchange Server 2013 SP1からサポートされたクラスター管理アクセスポイント無しの構成が既定

▪ 同一サイト上のCASやHUBが無くなった為、その他のファイルサーバやAzure上のファイル共有をWitnessとして選択する

▪ WitnessとするサーバのLocal AdministratorもしくはAdministratorグループにExchange Trusted Subsystemグループを追加しておく

▪ ダイナミッククォーラムが既定で有効化

▪ （計画停止であれば）過半数のサーバを停止可能

▪ JBOD構成の場合は耐障害性のため自動再シード機能を利用する

▪ CU2よりBitLocker環境における自動再シードをサポート

2-5.トランスポートサービス(Transport)

▪ トランスポート

▪ ①フロントエンドトランスポートサービス ②トランスポートサービス ③メールボックストランスポートサービスの3層で構成

▪ 受信コネクタが既定で1台あたり5個作成される

外部SMTPサーバSMTPクライアント

Client Frontend Default Frontend:587 :25

Client Proxy Default

Client Proxy Send

:465 :2525

Outbound Proxy Frontend

Outbound

Proxy Virtual

Send

:717(新規)送信コネクタ

フロントエンドトランスポートサービス

トランスポートサービス

※既定はトランスポートサービスから送信

2-5.トランスポートサービス(Transport)

▪ DAG : メールのルーティングの境界

▪ ADサイト間を跨いでも同一DAG内は直接配送

▪ 同一ADサイト内での配送も、DAGが分かれているとトランスポートサービス間で1Hop増える

サイトA サイトB

DAG1

DAG2

MBX11 MBX12

MBX21 MBX22

MBX13

MBX23

Transport

MBX

Transport

MBX

Transport

MBX

Transport

MBX

Transport

MBX

Transport

MBX

2-5.トランスポートサービス(Transport)

▪ シャドウ冗長

▪ トランスポートサービスで受け付けたメールを、250 OKを返す前に別のトランスポートサービスのmail.queにシャドウコピーを作成し、受信直後のトランスポートサービスの障害に備える

▪ ADサイトを跨いでDAGが構成されている場合デフォルトで別ADサイトにコピー（DC間トラフィックの増加）

▪ コピー先設定は①別サイト優先 ②ローカルのみ ③リモートのみ。コピーできない場合に接続を拒否することも可

▪ Set-TransportConfigの-ShadowRedundancyEnabled $falseで無効化は可能

▪ セーフネット

▪ 配送が完了したmail.que(アクティブキュー、シャドウキュー)のデータをプライマリセーフティネット、シャドウセーフティネットとして一定期間保持し、メールボックスDBのスイッチオーバーに備える

▪ デフォルトで2日分のメールが保持されるため、mail.queのサイズに注意（例:4000ユーザー x 平均100KB x 平均100通/日 x 2日 / 2台 = 40GB）

▪ 遅延DAGを構成する場合、その期間（例えば7日）以上に設定する

3.実構成におけるTIPS

3.オンプレExchange か、クラウドか

▪ セキュリティ

▪ 社内網とインターネットの間のFirewallでセキュリティ上の境界線が明確に決められていて、それをこのタイミングで変更する事が難しいのであれば、既存のポリシーを崩さないオンプレミスが適している

▪ クラウドを入れるなら、これを期に社内網を社外扱いにしてどこからでも業務ができるようにポリシーも見直していく位の気構えが必要

▪ 価格

▪ まったく同じ条件ではないが、単に必要十分なメール機能だけの話でいうのであれば、ID数が数千以上のレンジであれば、オンプレミスでSIで作ってもID月額単価は500円～1000円程度に収まるケースが多い

3.1.ハードウェア構成

▪ サーバー

▪ 基本的な設計思想としては3.5インチのディスクを多く内蔵できるサーバーを収容ユーザー数と冗長数に応じてスケールさせる

▪ SuperMicro Super Server 6048R-E1CR36H （4Uに3.5インチSAS / SATAを36本搭載可能）

▪ ユーザーのMBX容量とRAID構成に応じて積むディスクを決める

▪ RAID 10の場合 一人当たり12.5GBなら 4TB、25GBなら8TBなど

▪ RAID 6またはJBODの場合 一人当たり容量は上記の約2倍

▪ .edbファイルは2TB以下推奨、かつサーバあたり最大100DB

• RAID6は32本までしか組めない。RAID10は8スパンまでしか組めない（4x8本とかは組める）• 最大消費電力は1280Wだが、構成により平均500 - 700W程度• UPS並みに重いので、ラック設置は下の方推奨

3-500万円/台：4000MBXs

3.2.Exchangeバージョンの選択

▪ 2013か2016か

▪ Exchange Server 2013ならびにWindows Server 2012 R2の延長サポート終了が2023年（ハードウェアを使い倒す前提であればそろそろ終わりが見えている）

▪ Exchange Server 2013は更新プログラムがCU13、Exchange Server 2016はCU2までリリースされている

▪ ハイブリッド構成にするならExchange 2016の方が良い

▪ 2013にしなければならない制約事項

▪ Exchange 2007からの更改

▪ ADの機能レベルがまだ2003ですぐには上げられない

（5年使うなら）

本命はもう少し待ってExchange Server 2016 + Windows Server 2016

3.3.構成・設定について

▪ 仮想化(Hyper-Vの利用)

▪ メールボックスサーバーの他、LBやADDS、エッジ、Witnessなど必要になるサーバは存在するので、一定規模以下の場合は仮想化したほうが効率的

▪ .VHDXは固定長のみサポート（作成時は負荷が非常に高いので注意）

▪ NTFSかReFSか

▪ 判断材料が少ない。使うならストリーム整合性を無効化すること

▪ DiskReclaimerを有効化（既定で有効）して、Set-DatabaseAvailabilityGroup -FileSystem ReFS

▪ RAIDかJBODか

▪ RAIDだとリビルド中やディスクが半死の場合、RAID全体のパフォーマンスが落ちる

▪ 故障時のリビルド時間が長い（特に高負荷環境の場合1週間たっても終わらない）ので二重故障に注意

▪ JBODがサポートされる単一DC内でのx3コピーもしくは複数DCでの各x2の構成が取れる場合、JBOD＋AutoReseed構成として、1割くらい壊れたら初めてオンサイト対応などの方が楽

• 同一ドライブ上にDBファイルを多数配置するとフラグメントするケースあり（推奨4以下）

3.4.バックアップ

▪ ファイルベースバックアップの限界

▪ 平常時は増分のみとなるため取得可能だが、全体のデータ量が大きく、障害時にSLAを満たすことが難しい

▪ 3つ以上のコピーを作成し、そのうち1つを遅延再生のあるDAGに

▪ 最大14日（2日以上にする場合はセーフティネットの期間も一緒に伸ばす） ※論理障害に気付くまでの期間

▪ 再生し終わるまでそのDBはマウントできない

▪ バックアップ代わりに遅延DAGの確保が確実に必要なら、その部分はJBODではない方が良い

3.5.DRの構成

DC1 DC2

DC3

(Azure)

LB1 LB2

DNSラウンドロビン:

mail.contoso.com 10.1.1.1 10.2.1.1

10.1.1.1 10.2.1.1

DNSクエリ結果10.1.1.1 10.2.1.1

witness

VPN

DNSクエリ結果10.2.1.1 10.1.1.1

Microsoftの推奨構成

データセンタ単位での障害時、何もオペレーション無くサイトに接続※潤沢なHWリソース（DRサイト側の冗長レベルもメインサイトと同じ）とNWリソースが必要

（①DRサイト側にも冗長性を持たせる必要 ②平常時からサイトを跨いだトラフィック）

3.6.運用について

▪ アップデートの適用

▪ CUが四半期に一度出る。最新とその1つ前のCU以外Microsoftでサポートがされないので、ペースを合わせて毎回適用する

▪ 監視について

▪ 基本的に各サーバ上で動作しているMicrosoft Exchange Health Managementサービスがローカルの正常性を監視している

▪ 2007,2010,2013と大きく変わってきたSCOMの管理パックは、2013が2016以降ものまま利用される

まとめ

まとめ

▪ Exchange Server 2013と大きくは変わらない

▪ 逆に、変わらない分、最新バージョンを利用しない理由が無い時期が来る

▪ Exchange Server 2010のサポート終了まで3年半

▪ そろそろ情報収集などの準備

▪ クラウド(Exchange Online)に移行するなら、インフラやポリシーの整備・検討に十分な時間を。