SE の雑記

今日、業務で Exchange 2010 の Exchange Management Console を使っていてはじめて気付きました。

Exchange 2007 の Exchange 管理コンソールでもメールボックスの新規作成や、移動などの操作では、操作内容の
PowerShell が出力される機能が付いていました。
Exchange 2010 でも引き続き一部の操作では PowerShell が表示されます。

それとは別に PowerShell を表示する機能が Exchange 2010 に存在していたんですね。

■変更箇所の PowerShell の生成機能

Exchange 2010 の設定をしていたところ左下に見慣れないアイコンが。

このアイコンです。

普段はグレーアウトしているのですが設定を変更すると色がつきます。
# 適用ボタンが押せるタイミングと一緒に変わっているみたいです。

何だろうと押してみたらこんなダイアログが。

変更した部分の管理シェルを生成してくれる機能のようです。

Exchange 2010 は Beta のときから少しずつは触っていたのですが今まで気づきませんでした…。

Exchange 2007 ではメールボックスの復旧をする際に使用する [回復ストレージグループ] を EMC の
[データベース回復管理] から作成することが可能でした。

Exchange 2010 では、[データベース回復管理] がなくなっています。

また、Exchange 2010 ではストレージグループがなくなっていますので、[回復ストレージグループ] ではなく、
[回復用データベース] となっています。

回復用データベースの使用は、EMC からではなく、EMS を使用してコマンドでデータベースの作成を行います。
New-MailboxDatabase

回復用データベースを使用したメールボックス回復の一連の作業としては、

というようにコマンドベースで回復を行っていきます。

サードパーティーのバックアップソフトを使わなくてもOS 標準の Windows Server バックアップ + 回復用データベースで
ある程度は復旧ができますよね。

一度メモを残しておくと便利そうでしたので投稿しておきたいと思います。

Exchange Server 2007 では Standard Edition ではクラスタを使用することができませんでした。
Exchange Server 2007 のエディションおよびクライアント アクセス ライセンス

そのため、Standard Editoin では [シングル コピー クラスタ] と [クラスタ連続レプリケーション] はサポートなしとなっています。

クラスタの構成がされている評価版 (Standard Evaluation) で Standard Edition のプロダクトキーを設定すると、
以下のエラーが発生し、プロダクトキーを確定することができません。

Exchange Server 2010 の場合はエディションによる機能比較は以下の情報ぐらいしか見当たりませんでした。
Exchange 2010: Editions and Versions

Exchange 2010 でも作成できるメールボックスデータベース数には差があるのですが、機能面に関しては特に言及されていません。
試しに DAG が設定されている評価版 (Standard Evaluation) で Standard Edition のプロダクトキーを設定してみました。

Exchange 2010 では Standard Edition で DAG (クラスタ構成の Exchange) を構成することが可能です。
# 海外のブログで Standard Edition + DAG について書かれているものがいくつかあります。

機能面に関しては、Standard CAL または Enterprise CAL のどちらを使用するかで変わるようですね。
Exchange Server 2010 Standard Edition + Enterprise CAL という組み合わせもできたはずです。
この辺の情報はパートナー向けの Exchange 2010 の販売ガイドが記載されています。

Windows Server 2008 R2 Enterprise Edition + Exchange Server 2010 Standard Edition で冗長構成を持った
メールボックスサーバーが構築できるのはコストを抑えられて良いですね。

Exchange 2010 で承認済みドメインを変更しながら、メールフローの確認をしていました。
[電子メールアドレスポリシー] の [Default Policy] で設定されている承認済みドメインを [外部の中継ドメイン] に
変更しようとしたところ、以下のエラーが発生しました。

電子メールアドレスポリシーで設定されているドメインに関しては、[外部の中継ドメイン] に設定できないようでしたので、
[Default Policy] から該当のドメインを削除しようとしたところ、以下のエラーが発生してしまい EMS からは変更できませんでした。

既定の電子メール アドレス ポリシーは EMC ではなく EMS (Exchange Management Shell) で変更する必要があります。
既定の電子メール アドレス ポリシーでは、[-EnabledEmailAddressTemplates] と [-Identity] 以外は指定できないのが原因のようです。

EMS で以下のようなコマンドを実行することで既定の電子メール アドレス ポリシーを変更することが可能です。

Exchange 2007 で既定の電子メール アドレス ポリシーを設定し、Exchange 2010 に移行していたため、ポリシーを
操作する機会がなく、今までエラーが発生することに気づきませんでした。

Exchange Server 2007 ではメッセージの配信状況を確認する際に、[追跡ログ エクスプローラー] を使用していました。
Exchange Server 2010 でも引き続き追跡ログ エクスプローラーが提供されています。

しかし、エッジト ランスポートサーバーで追跡ログ エクスプローラーを使用しようとすると以下の画面のエラーとなります。
# ハブ トランスポートでは発生しません。

?

Exchange 2010 でこの現象が発生するのは知っていたのですが、今まで原因を調べていませんでした。
今日、時間があったので少し調べてみたところ技術情報が掲載されていました。

アシスタントの Exchange トラブルシューティング ツールは、Exchange Server 2010 エッジ サーバー上でメッセージ追跡用のタスクが動作しません。

Exchange 2010 の不具合のようですね。
現状は [Get-MessageTrackingLog] コマンドレットで追跡ログを確認するしかないようです。

SP1 で修正されるようですが、最近 RU1 が提供されたばかりですので修正はもう少し先になるのでは。

検証用に Exchange 2007 のクラスタ環境を作成しようと思い、ドメインコントローラーを Windows Server 2008 R2 で
構築していました。

Windows Server 2008 R2 で Exchange 2007 SP2 用のスキーマ拡張をしようとしたところ以下のエラーが。

Windows Server 2008 R2 上では Exchange 2007 のスキーマ拡張はできないようですね。

Windows Server 2008 スキーマ拡張を実行したところ、Windows Server 2008 R2 でドメインコントローラーを
構築していてもスキーマ拡張を実行することができました。

Windows Server 2008 R2 上では Exchange Server 2007 はインストールできないとは認識していたのですが、
スキーマ拡張まで実行できないとは思っていませんでした。

1/4 になってしまいましたが新年明けましておめでとうございます。
本年も日々、勉強を積み重ねていきたいと思います。

年末、年始はちょっとした調べ物やインストールマニアックスの作業を少しずつこなしていました。

インストールマニアックスに関しては総インストール数が 50 ぐらいで終了してしまいそうですが、時間がある限り、
インストールをしていきたいと思います。

本年の初投稿は Exchange 関連の内容から。
SQL Server 関連の投稿をしたかったのですが、直近で調べていたのが Exchange だったもので…。
# Exchange の引き合いを対応することが多くなってきました。

Exchange 2007 SP2 以降では、Windows Server 2008 の Windows Server バックアップに対応した VSS プラグインが組み込まれています。

Exchange Server 2007 SP2 の新機能

Exchange 2007 の書籍は、Windows Server 2003 をベースに記載されていることが多く、Windows Server 2008 を使用した場合の
バックアップは今まできちんと調べたことがなかったので、年末の暇な時間を利用していろいろと調べてみました。

• Exchange 2007 SP1 以前のバージョン
  VSS プラグインが組み込まれたのは Exchange 2007 SP2 からになります。
  それ以前のバージョンに関してはバックアップを取得してもトランザクションログの切り捨てが行われません。
  そのため、Exchange に対応したバックアップを取得する場合は、サードパーティーのバックアップ製品を使用する必要がありました。

  [vssadmin list writers] を実行すると、[Microsoft Exchange Writer] が表示されるので、一見すると完全に対応した
  バックアップを標準の Windows Server バックアップでで取得できそうに見えるのですが、この状態でバックアップを
  取得してもトランザクションログは切り捨てがされずに蓄積されていきます。

  

• Exchange 2007 SP2  / Exchange 2010
  Exchange 2007 SP2 / Exchange 2010 では Windows Server バックアップに対応したプラグインが組み込まれます。
  プラグインが組み込まれることにより、Windows Server バックアップを取得した際に、トランザクションログの切り捨てが
  実行されるようになります。
  また、リストア時に Exchange のデータのみをリストアすることが可能になります。
  # アプリケーションとして、[Exchange] が選択できるようになります。

  以下の画像は、Exchange 2010 のレジストリを表示したものになるのですが、Windows Server バックアップのライタとして、
  Exchange が登録されていることが確認できます。

  – Exchange 2010 の VSS の登録状況 –
  

プラグインが組み込まれることで、Windows Server バックアップが Exchange に対応するのですが、取得時には以下の設定を
する必要があります。

1. 完全バックアップを取得
2. ストレージグループ (Exchange 2010 ではデータベース) を含むボリューム全体を取得

Windows Server バックアップを使用した Exchange データのバックアップと復元

[完全バックアップを取得]

[完全バックアップ] で取得することで、バックアップ取得時にトランザクションログの切り捨てが実行されます。
Windows Server バックアップのデフォルトは、[完全バックアップ] ではなく、[コピーバックアップ] となっています。

– Windows Server 2008 R2 のバックアップ設定 –
 

そのためバックアップの設定をする際に、明示的に [完全バックアップ] として設定する必要があります。
デフォルトの状態でバックアップを取得すると [コピーバックアップ] となっているため、トランザクションログが切り捨てられません。

[ストレージグループ (Exchange 2010 ではデータベース) を含むボリューム全体を取得]

バックアップを取得する際は、ストレージグループのディレクトリのみを取得するのではなく、ストレージグループを含む
ボリュームを取得する必要があります。
ストレージグループをディレクトリのみを取得した場合、リストア時に [Exchange] をリストア対象として選択することができません。
# ファイルとしてはリストアできるのですが、アプリケーションとしてリストアすることはできません。

– アプリケーションから Exchange をリストア –

Windows Server 2008 R2 の Windows Server バックアップであれば、バックアップの取得先は無印と比較して、
柔軟に選択できますので、標準機能だけでも小規模な環境であれば、基本的なバックアップは取得できそうです。
ストレージグループ / データベース単位でのリストアはできないので、細かな障害回復はできませんが、
全体を特定時点まで戻して、残っているトランザクションログでロールフォワードといった運用は可能かと。

サードパーティ製品を使わないでもある程度バックアップ / リストアができるようになっていると提案に幅ができていいですね。

自宅の検証環境は 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 に移行中なのでこの機会に適用しておきたいと思います。