SE の雑記

自宅の検証環境は Exchange Server 2007 で最初構築していたので、現在は 2007 + 2010 の共存環境となっています。

そろそろ Exchange Server 2010 のみの環境にしようと思い、2007 の撤去を開始しました。
# Exchange 2007 を撤去しないと、TMG 2010 の検証環境の構築がリソース的に厳しいんですよね。

まずは、単純にアンインストールを試みてみました。

1. クライアント アクセスをアンインストール
   まずは簡単に役割がアンインストールできそうな CAS から撤去してみたいと思います。
   役割の削除は [コントロールパネル] の、[プログラムと機能] から[Exchange Server 2007] のアンインストールを行います。

   [Exchange 保守モード] が起動しますので、削除する役割のチェックボックスを [オフ] にします。
   
   前提条件のチェックはすんなり通過できました。
   それでは削除してみたいと思います。
   
   CAS は問題なく削除完了です。
   

2. ハブ トランスポートをアンインストール
   続いて HUB をアンインストールしてみたいと思います。

   
   送信コネクタの [送信元サーバー] として、Exchange 2007 の HUB が設定されているのでエラーとなっているようです。
   ?
   送信コネクタから 2007 の HUB を削除したところ、前提チェックも通過しました。
   
   ということでこちらも削除。
   
   前提条件を満たしているのであっさりと削除できました。
   

3. メールボックス をアンインストール
   最後にメールボックスをアンインストールします。
   最後の機能をアンストールする際には、管理ツールも削除できるようになります。
   
   いろいろとエラーになりました。
   
   それでは一つずつ解消していきたいと思います。
   1. オフラインアドレス帳生成サーバーの移動

      Exchange の管理コンソールからオフラインアドレス帳サーバーを移動させます。
      
      
      
      
      

   2. パブリックフォルダの削除

      パブリックフォルダのエラーについては検証用の環境なので、思い切ってパブリックフォルダを削除してしまいます。

      Get-PublicFolder -Server $ENV:COMPUTERNAME "" -Recurse -ResultSize:Unlimited | Remove-PublicFolder -Server $ENV:COMPUTERNAME -Recurse -ErrorAction:SilentlyContinue Get-PublicFolder -Server $ENV:COMPUTERNAME "Non_Ipm_Subtree" -Recurse -ResultSize:Unlimited | Remove-PublicFolder -Server $ENV:COMPUTERNAME -Recurse -ErrorAction:SilentlyContinue

      パブリックフォルダの削除は以下の URL が参考になります。

      パブリック フォルダ データベースの削除
      組織内の最後のパブリック フォルダ データベースを削除する方法

      このまま削除をしようとしたところ、以下のエラーが発生してしまいました。
      ?
      Exchange 2010 側でパブリックフォルダの作成をした記憶はないんですけどね…。
      ログを確認したところ、Remove-PublicFolderDatabase でエラーとなっているようでした。
      Exchange 2010 で Remove-PublicFolderDatabase を実行したのですがうまく削除できなかったので、
      ADSIエディタを使って構成パーティションからパブリックフォルダのエントリーを強制削除してしまいました。

      [CN=Configuration,DC=<ドメイン名>,CN=Services,CN=<組織名>,CN=Administrative Groups,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Servers,CN=<Exchange 2007>,CN=InformationStore]
      からパブリックフォルダのストアを強制削除。

   3. メールボックスの移動

      Exchange Server 2007 に存在しているメールボックスを Exchange Server 2010 に移動します。
      Exhcange 2010 へのメールボックスへの移動は Exchange 2010 の管理コンソールから実行します。

      ローカル移動要求を新規作成して移動させます。
      

   これで準備完了です。
   前提条件のチェックも終了したので削除します。
   ?
   事前準備が終了していたので削除も問題なく完了しました。
   ?

これで Exchange 2007 の撤去は完了です。
パブリックフォルダーに関しては調査が必要だな～と感じました。
Exchange 2007 → 2010 へ移行にするに際し、パブリックフォルダーは廃止としてもらえればいいのですが、
実際はそうもいかないと思いますので。

これで Exchange 2007 をシャットダウンした状態にできるようになりました。
ようやく TMG 2010 の検証環境を構築できます。

今週の頭に Exchange 2010 のエッジトランスポートサーバーの検証環境を構築して、出社の電車の中で、
ルーターと受信コネクタの設定をしていました。
# 私は通勤時間が片道 2 時間近くなので通勤時間を利用したサーバー構築もなんのそのです。

電車の中で少し寝て、まだ会社の最寄駅まで時間があったので、構築を再開しようとしたところ、
やけにサーバーが重いことに気付きました。

何だろうとメールキューを確認してみたところ 12 万通を超える大量のスパムメールが溜まっていました…。

幸い、送信コネクタを設定する前だったので外部に配信はされませんでしたが、今後このようなことが
発生しないように最低限実施することをメモとして。

今回は電車の中で気づいたので、ひとまずルーターのポート 25 の転送を停止し、MX レコードを削除して
帰宅してからの対応としました。
企業向けのメールサーバーでこんな対応したら始末書ですね…。

• 準備が終わるまで送信コネクタは有効にしない
  Exchange では外部にメールを送信する際には、アドレススペースを [*] に設定しているコネクタ経由で
  メールを送信するのが一般的な設定だと思います。
  ?
  一通りの設定が終了するまではこのコネクタは無効にしておいた方がよいかと。
  今回はこれに救われました。

  エッジサブスクリプションを設定している場合は、エッジトランスポート側では送信コネクタを変更できませんので、
  ハブトランスポートで同一名の送信コネクタを無効にしてから、ハブトランスポートで

  Start-EdgeSynchronization ?Server $ENV:COMPUTERNAME

  を実行してエッジトランスポートに設定を伝搬させます。

  これで一通りの設定が終了するまではインターネットにはメールが送信されなくなります。Exchange 2007 SP 1 以降はハブトランスポートにはデフォルトだと [*] のコネクタは作成されないようになっていたかと。
  # エッジトランスポートにはデフォルトで作成されていた気がします

• 受信コネクタの設定確認
  インターネットからのメール受信をするための受信コネクタでは、[匿名ユーザー] を許可した状態にします。
  
  Exchange では匿名ユーザーで接続された場合は、[承認済みドメイン] に設定されているドメインにのみ
  メールが送信できるようになっています。
  承認済みドメインに設定されているドメインへのメール送信に関しては、
  

  250 2.1.5 Recipient OK

  となりメール送信が可能ですが、承認済みドメインに設定されていないドメインに対しては、

  550 5.7.1 Unable to relay

  となり中継ができないという動作になります。

ただし、受信コネクタで、[外部的にセキュリティで保護] を有効にしていると、承認済みドメインに
設定されていないドメインに対してもメールが中継できてしまいますので注意が必要です。

?

以下のような設定が一般的なのでしょうか。


• MTAにメール検疫ソフトの導入
  Microsoft 製品の場合は [Forefront Protection 2010 for Exchange Server] (FPE) が最新のメールに関しての
  検疫ソフトになります。
  ?

  FPE で使用される検索エンジンは以下のものになります。
  ?

  試しにインストールした環境を作ってみたのですが、最低でもメモリは 2G ぐらいないとテスト用途でもつらいですね。

  エッジトランスポートでも標準機能として以下のスパム対策が実行することができるのですが、
  ウイルス対策はできませんので。

  IP 禁止一覧

  IP 禁止一覧プロバイダー

  IP 許可一覧

  IP 許可一覧プロバイダー

  Sender ID

  コンテンツ フィルター

  受信者フィルター

  送信者フィルター

  送信者評価

• 匿名接続時の外部ドメインへの送信確認
  これができてしまうと、スパムメールの踏み台の温床となります。
  ?
  最初は telnet で接続して動作確認をした方がいいのかなと思います。

  Windows Server 2008 / R2 では標準の状態では Telnet クライアントがインストールされていないので、
  コマンドプロンプトで telnet を実行することができません。
  追加できる機能には含まれていますので、テスト用にインストールしておくと便利だと思います。
  Tera Term でもよいと思いますが、テスト用にしか使わないので私は telnet コマンドでテストしています。
  ?

  telnet でメール送信のテストをするには以下のコマンドを実行していきます。

  telnet <MTA の IP アドレス> 25 helo <ドメイン名> mail from: <FROM (送信者) アドレス> rcpt to: <TO (宛先) アドレス> DATA <メール本文> . QUIT 例) telnet 127.0.0.1 25 helo test.local mail from: user1@test.local rcpt to: user2@test.local DATA test mail . QUIT

  後は FROM と TO の組み合わせテストを実施します。
  上記のコマンド実行の場合、メール送信は匿名認証となります。
  承認済みドメインとして test.local が設定されている場合の結果は以下になるはずです。
  # test.local も test2.local も匿名認証なので結果は同じになります。

  FROM	TO	結果
  user1@test.local	user2@test.local	OK
  user1@test.local	user2@test2.local	NG
  user2@test2.local	user2@test.local	OK
  user2@test2.local	user2@test2.local	NG

• 第三者中継テストの実施
  メールサーバーの第三者中継テストをしてくれるサイトを利用して最終的な確認をするとよいかと。

  私はよく以下のサイトを利用させていただいています。
  第三者中継チェック – RBL.JP

  Exchange の送信コネクタ / 受信コネクタの設定だけで自ドメイン内の存在しないメールアドレスへのテスト以外は
  通過させることができるはずです。

  存在しないメールアドレスのテストについては、スパム対策の受信者フィルターで、[ディレクトリに存在しない
  受信者宛てのメッセージをブロックする] を有効にする必要があります。

  
  エッジトランスポートで実施する場合は、エッジサブスクリプションを有効にする必要があるようです。
  ハブトランスポートで実施する場合は、ハブトランスポートで以下のコマンドを実行してスパム対策を
  有効にしてから受信者フィルターを設定します。

  ./install-AntispamAgents.ps1 Restart-Service MSExchangeTransport

他にもいろいろとテストはあると思いますが、最低限実施しておいた方がよいものをメモとして。

Exchange Server 2010 RU1 の提供が開始されたようです。
この間 RTM したばかりだと思っていたのですが早いですね～。

Exchange 2010 RU 1 has been released
Update Rollup 1 for Exchange Server 2010 (KB976573)
Exchange Server 2010 の更新プログラム ロールアップ 1 の説明

現在、自宅の検証環境の Exchange を 2010 に移行中なのでこの機会に適用しておきたいと思います。

Windows Server 2008 SP2 で AD DS と Exchange Server 2007 の共存環境を構築しようとした場合、
環境によってはインストール中に以下のエラーが発生することがあります。
# SP2 でなくてもエラーにはなると思います。私が試した環境はたまたま、OS が SP2 でした。

[Microsoft Exchange Transport] サービスが起動できないためにエラーとなるようです。

最初は以下の現象が発生したのかと思ったのですが、Exchange Server 2007 SP2 の場合は、対象のアセンブリの
構成ファイルで [<generatePublisherEvidence enabled="false" />] は設定されているみたいなんですよね。
Exchange Server 2007 用更新プログラムのロールアップをインストールすると Exchange Server 2007 マネージ コード サービスが開始されない

いろいろ調べていたところ、TechNet Magazine? 2008 年 11 月の以下の記事に解決策が載っていました。
# 最後の QA が今回の現象に該当します。

Outlook Anywhere と IPv6、リモート接続アナライザなど

ドメインコントローラーと Exchange Server 2007 を共存させたときは、IPv6 を有効にしておく必要があるようですね。
今回は Exchange Server 2007 SP2 をインストールしようとしたのですが、本現象は発生しました。
OS の基本セットアップ終了後は IPv6 を無効にするようにしているのですがそれが裏目に出てしまったようです。
IPv6 を有効にするとインストールも正常に完了します。

最初はドメインコントローラーと Exchange Server 2007 の共存がサポートされていないのかと思っていたのですが、
この構成はセキュリティの面から推奨はされないがサポートされる構成のようです。

Exchange 2007 のシステム要件

記載されている内容が微妙なんですよね…。
以下のように記載されているので一見、NG なのかと思えば、

?

?

と記載されている個所も。
併用というのはおそらく、Windows Server 2008 のドメインコントローラーを認証基盤として使えるかということだと
思うのですが、表現がいまいちわかりにくいです。
# Exchange 2000 が併用不可となっているので有効なドメインコントローラーになりえるかということだとは思うのですが。

以下の KB もあるようですので、再起動時にサービスの手動起動が必要になる可能性もあるようですね。

グローバル カタログ サーバーに Exchange 2007 または Exchange Server 2010 をインストールすると、Exchange 2007 または Exchange Server 2010 のサービスが自動的に開始できない

できればドメインコントローラーと Exchange は別立てにしたいですがお客様の費用や規模によっては共存せざるを得ないことも
あるかと思います。
# EBS 2008 での提案というのもありかとは思うのですが。

そのようなときの注意事項のメモとして。

2010/4/21 追記

ドメインコントローラー以外でも IPv6 が無効になっていると現象が発生しますね…。
本現象は AD DS にかかわらず以下の KB が当てはまるようです。

Windows Server 2008 ベースのコンピューターで、Exchange Server 2007 のハブ トランスポートの役割または Microsoft Exchange Server 2010 のハブ トランスポートの役割のインストールが失敗する

AD DS でも上記 KB の対応をすれば、IPv6 が無効でもインストールできます。

ここまでの設定でデータベース可用性グループを設定して対象のサーバーを追加するところまでは作業が完了しました。

最後にメールボックスデータベースを DAG でレプリケーションされるように設定します。

1. 対象のメールボックスデータベースを右クリックして、[メールボックス データベース コピーを追加] をクリックします。
   今回は、EXCHANGE-01 に MB01 を EXCHANGE-02 に MB02 を配置しています。
   
2. [参照] をクリックします。
   
3. サーバーを選択して、[OK] をクリックします。
   
4. [追加] をクリックします。
   
5. [終了] をクリックします。
   

これで DAG の設定は完了です。
データベースコピーにサーバーが 2 台設定されているのが確認できます。

?

データベース コピーは両サーバーで同一のディレクトリに設定されるようです。
コピーを作成するサーバーで同一のディレクトリが作成できない場合は、エラーになるようです。

EXCHANGE-02 にしか存在していない E ドライブに設定しているメールボックスデータベースを EXCHANGE-01 にコピーとして
設定した場合の画像が以下になります。

DAG の設定は以上で終了です。

DAG ですが WSFC の技術を使っていますので、AD 上にコンピュータアカウントと、DNS の登録がされるようです。
?

クラスタサービスとしてはメールボックス等は登録されておらず、フェールオーバークラスタの管理から見れるのは、
クラスタコアリソースだけのようですね。
クラスタの管理は、フェールオーバー クラスタ マネージャからではなく Exchange 管理コンソール (EMC) から行う形になるかと。

DAG 内のメールボックスのレプリケーションに使用するネットワークの設定は (EMC)? からできるようです。
ネットワーク負荷を考慮するとサービス用 / レプリケーション用 / WSFC ハートビート用の NIC が必要になるかもしれないですね。
?

Exchange Server 2010 から、可用性をもつ MBX と CAS / HUB が共存できるようになったのですが、WSFC と NLB は
共存できないため、機能の共存環境で CAS を冗長化させるためにはハードウェアロードバランサが必要となりそうです。

Exchange 2007 と比較して簡単に可用性を持つメールボックスデータベースを構築できますが、ディスク容量やネットワークに関しては
2010 用に考える必要がありそうですね。

時間がある時に CAS アレイも勉強したいとは思いますが DAG の設定はここまでで。

今回の環境は自習書を参考にしながら構築してみました。
Exchange Server 2010 自習書シリーズ

作成したデータベース可用性グループにメンバーを追加したいと思います。

1. 作成した DAG を右クリックして、[データベース可用性グループのメンバーシップの管理] をクリックします。
   
2. [追加] をクリックします。
   
3. 追加するサーバーを選択して、[OK] をクリックします。
   
4. [管理] をクリックし、サーバーを登録します。
   
5. [終了] をクリックします。
   

これで DAG のメーンバーにサーバーを追加できました。

構成を何度か試していたのですが、たまにメンバーの追加で 2 台目のサーバーだけエラーになることがあるんですよね。

US の TechNet のフォーラムでもエラーになることはあることが投稿されていました。
?Problem adding a second server to DAG (Error: Cluster API ‘"AddClusterNode() (MaxPercentage=12) failed with 0x80070005. )

可用性グループの再作成、Exchange 管理コンソールを再起動したりと何度かやり直していたところ、正常に追加できるようになりました。
[Organization Management] グループのユーザーだと駄目なのかと思っていたのですが、権限は特に付与しなくても
追加できたので権限系でエラーになっているわけでもなさそうなのですが。

メンバーを追加するタイミングで監視サーバーにディレクトリが作成されます。

共有ディレクトリも設定されていますね。

監視サーバーは WSFC の [ノードおよびファイル共有マジョリティ] で使用される、[ファイル共有監視] として使用されます。
WSFC の設定状況は、DAG の設定が一通り完了したら改めてみてみたいと思います。

これでメンバーの設定は完了です。

最後にメールボックスデータベースのコピーを設定します。
こちらは次の投稿で。

2 台構成の Exchange 環境ができましたので DAG を設定します。

Exchagne Server 2007 では高可用性のソリューションがいくつかありましたが Exchange Server 2010 では、
Database Availability Group (DAG) 1 種類となりました。

WSFC とメールボックスのレプリケーションを組み合わせた設定になるようですね。
設定をしながらクラスタがどのように構築されているのか確認していきたいと思います。

今回は AD 1 台 （EXCHANGE-AD) と Exchange 2 台 (EXCHANGE-01 / EXCHANGE-02) の環境で構築をしています。
DAG の監視サーバーとしては、AD を使用したいと思います。

?

1. ドメインの [Exchange Servers] [Exchange Trusted Subsystem] に [EXCHANGE-AD] を追加します。
   
2. ドメインの [Builtin] コンテナ の [Administrators] に [Exchange Trusted Subsystem] グループを追加します。
   # 監視サーバーの [BUILTINAdministrators] に [Exchange Trusted Subsystem] を追加する必要があります。

   各Exchange の [Administrators] グループにはインストール時に [Exchange Trusted Subsystem] と
   [Organization Management] ドメイングループが追加されているようですね。

   

3. Exchange Management Console を起動します。
4. [組織の構成] → [メールボックス] を選択します。
5. [データベース可用性グループの新規作成] をクリックします。
   
6. [データベース可用性グループ名] を入力し、[新規作成] をクリックします。
   ?
   監視ディレクトリを明示的に設定しないと、[C:DAGFileShareWitnesses<DAG 名の FQDN>] が
   設定されるようです。
7. [終了] をクリックします。
   

まずは管理グループの作成が終了しました。

この時点では監視サーバー上にディレクトリは作成されないようです。

続いてクラスタ IP を設定します。

1. [Exchange Management Shell] を実行します。
   
2. 以下のコマンドを実行して作成し、DAG に対して IP アドレスを設定します。
   

   Set-DatabaseAvailabilityGroup -Identity DAG01 -DatabaseAvailabilityGroupIpAddresses 172.23.0.10

上記コマンドを実行し、IP を設定していないと DAG にメンバーを追加した際に以下のエラーとなります。

これで DAG にメンバーを追加するまでの設定は完了です。
次の投稿でメンバーの追加作業をまとめたいと思います。

Exchange 2010 の DAG を勉強しようと思い、Exchange 2010 の新規インストールをしてみました。
最近はアップグレードばかりで新規インストールの方法をすっかり忘れていました…。

今回は、AD / Exchange 共に Windows Server 2008 R2 で構築しています。
コマンドは基本的に管理者として実行します。

1. Active Directory の準備
   Exchange? Server 2010 のインストールメディアを AD DS にセットし、以下のコマンドを実行します。
   [Schema Admin] と [Enterprise Admin] の権限が必要かと。
   
   

   setup.com /ps setup.com /p /OrganizationName:<組織名>

2. Exchane Server 2010 に必要な役割 / 機能のインストール
   Exchange Server 2010 のインストールメディアを Exchange 用サーバーにセットし、以下のコマンドを実行します。
   Windows Server 2008 R2 では ServerManagerCmd は推奨されていませんが、一括で役割をインストールできるのは
   便利ですね。
   役割 / 機能のインストールが終了したら再起動します。
   
   

   ServerManagerCmd ?inputpath D:ScriptsExchange-Typical.xml

3. Net.Tcp Port Sharing Service の自動化
   Net.Tcp Port Sharing Service がデフォルトでは [手動] となっているので、[自動] に設定します。
   SC コマンドで自動化してみました。?
   

   sc config NetTcpPortSharing start= auto

4. 2007 Office System コンバータ：Microsoftフィルタ パック のインストール
   以下の URL から 2007 Office System コンバータ：Microsoftフィルタ パック をダウンロードしインストールします。
   http://go.microsoft.com/fwlink/?LinkId=123380

   

5. 言語パックバンドルのダウンロード
   今回の環境はインターネットに接続されていない環境のため、以下の URL から言語パックバンドルをダウンロードしておきます。
   http://go.microsoft.com/fwlink/?LinkId=147077
   
6. Exchange Server 2010 のインストール
   Exchange Server 2010 をインストールします。
   Exchange のインストールを実施するアカウントは [Organization Management] または [Domain Admins]
   ドメイングループのメンバーの必要があります。
   
   1. [Exchange 言語オプションの選択] をクリックします。
      
   2. [言語バンドルからすべての言語をインストールする] をクリックします。
      
   3. [ハード ドライブまたはネットワーク共有上の言語ファイルのパスを指定する] を選択して、
      ダウンロードした言語パックを参照し、[次へ] をクリックします。
      
   4. [完了] をクリックします。
      
   5. [Microsoft Exchange のインストール] をクリックします。
      
   6. [次へ] をクリックします。
      
   7. [使用許諾契約書に同意します] を選択し、[次へ] をクリックします。
      
   8. エラー報告を設定し、[次へ] をクリックします。
      
   9. [Exchange Server のカスタム インストール] を選択して、[次へ] をクリックします。
      
   10. インストールする役割を選択して、[次へ] をクリックします。
       まずは 1 台構成でインストールをします。
       2010 からフェールオーバークラスタのインストールはセットアップで実行しなくなっているんですよね。
       mstep で Exchange 2010 を受講したときに始めて知りました。
       
   11. Outlook 2003 の使用有無の設定をして、[次へ] をクリックします。
       
   12. CAS の外部ドメイン名を設定して、[次へ] をクリックします。
       
   13. CEIP の設定をして、[次へ] をクリックします。
       
   14. 前提条件の確認が終了したら、[インストール] をクリックします。
       
   15. [終了] をクリックします。
       ?

以上で、インストール完了です。
今回は DAG の構成を作りたいため、同様の作業をもう一台のサーバーで実行して Exchange を追加します。

まずは 2 台構成の環境ができました。
これで DAG を設定するための下準備は完了です。
次の投稿で DAG を設定してみたいと思います。

SQL Server のクラスタ構成では Is Alive のチェックで定期的な間隔 (デフォルトは 1 分) で

SELECT @@servername

が実行され、クラスタリソースの起動状況の確認がされます。

Windows Server 2003 上で SQL Server を MSCS で構築した場合は、Is Alive のチェックには、
クラスタサービスのサービスアカウント (ドメインユーザー) が使用されていました。
そのため、SQL Server のログインからクラスタのサービスアカウントを消してしまうとリソースが
起動できなくなります。

Windows Server 2008 の WSFC では、クラスタのサービスの起動アカウントはドメインユーザーではなく、
ローカルシステムアカウントで起動されます。

Windows Server 2008 だと、Is Alive のチェックはローカルシステムアカウントで実行されているのか
気になって調べてみました。

手っ取り早く調べるため、SQL Server Profiler を実行して確認してみました。

WSFC + SQL Server ではローカルシステムアカウントで Is Alive のチェックが実行されているようですね。

クラスタのサービスアカウントでチェックがされるという動作は WSFC でも変わらないようです。

すこし時間が空いてしまいましたが、件数を絞って削除するパターンで時間を計測してみたいと思います。

今回のテスト用のテーブルには date 型のフィールドを設定しています。

レコード削除時に日付を指定して削除を実行してみます。

– TOP を指定しないで範囲削除 –

– 削除の処理時間 –

?

続いて TOP と ROWCOUNT を指定して削除してみます。

– 10,000 件ずつ削除 –

?

– 削除の処理時間 –

特定件数ずつ削除したほうが遅いですね。

単純復旧モデルでチェックポイントを明示的に発生させながら、ログを切り捨てる場合以外は、
件数を指定して削除させるメリットはないかもしれないですね。

今まで処理効率が良いのかなと考えていたのですが違っていたようで。