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 はインストールできないとは認識していたのですが、
スキーマ拡張まで実行できないとは思っていませんでした。

記憶に残っているうちに投稿しておきたいと思います。

ISA 2006 Enterprise Edition のシステム要件には以下のように記載されています。
ISA Server 2006 のシステム要件

?

ISA 2006 Enterprise Edition は統合 NLB を設定することにより、ISA で NLB を統合管理することができるようになります。

ISA 2006 の既定の設定では、NLB がユニキャストモードで設定されます。
ユニキャストモードの NLB では NIC の MAC アドレスの書き換えが発生し、各ホスト間は NLB で使用している NIC では
通信ができなくなります。
そのため、ISA 2006 Enterprise Edition の統合 NLB では、ホスト間通信用に追加の NIC が必要とされています。
ISA はホスト間通信ができないと、アレイ内のサーバー通信ができなくなってしまいノード間の死活監視ができなくなります。

Windows Server 2003 SP1 以降であればレジストリを変更することでホスト間通信が可能になるのですが試したことはありません…。
大抵、マルチキャストモードで構築してしまうんですよね。

Windows Server 2003 では、NLB が有効なネットワーク アダプター経由で通信できないユニキャスト NLB ノード

TMG 2010 であれば統合 NLB の設定時にユニキャスト / マルチキャストの選択ができるのですが、ISA 2006 では管理コンソールで
普通に設定を行うとユニキャストモードとなります。

マルチキャストモードで ISA 2006 の統合 NLB を使用する場合には、以下の KB の作業を実施する必要があります。

ISA Server NLB の統合の更新を有効にマルチキャスト操作

[/nlb:multicast] でマルチキャストモードに設定することにより、単一 NIC でもホスト間通信が可能となります。
Enterprise Edition でも単一 NIC で統合 NLB が使用できるのでメモとして。

SCCM 2007 の検証を少し始めています。

まだまだ初期段階なのですが、関連情報をメモとして投稿しておきたいと思います。
2 年ぐらい前までは日本語の情報はあまりなかったみたいなのですが、今は情報が充実しているようですね。

Windows Server 2008 R2 + SQL Server 2008 SP1 RU5 + SCCM 2007 R2 SP2 という環境を構築している最中なのですが、
結構リソースを多めに割り当てないと検証が厳しいかもしれないですね。
メモリ 2 GB + 2 CPU の環境でも少し重いような気がしています。
# OpsMgr もメモリが 2 GB ないと厳しかったような。

SCCM 2007 SP2 であれば Windows Server 2008 R2 にも対応しています。
マイクロソフト製品の Windows Server 2008 R2 対応状況

R2 の SSRS 統合が SQL Server 2008 の SSRS にも対応できるかはまだ未検証です。
SSRS がなくてもレポート実行はできるので、統合させなくても運用面では問題はないのではと考えてはいます。

■自習書

■日本の System Center チームのブログ

運用管理とセキュリティのウタタゴト

■日本の System Center チームの SkyDrive

SCCM

■ネイティブモードと混在モード

System Center Configuration Manager 2007 ~ よくある質問 1 ~

混在モードは互換モードなのかと思っていたのですが、そういうわけでもないんですね。
実際の運用環境でネイティブモードを使うと証明書運用も考慮しないといけないので、混在モードのほうが敷居が低く導入が
できそうな気がしています。
お客様の運用工数が上がりそうな構成は個人的には好きではないです。

■Active Directory スキーマ拡張

Configuration Manager に対して Active Directory スキーマを拡張する方法

[ldifde] で [CONFIGMGR_AD_SCHEMA.LDF] を適用するか、[extadsch.exe] で拡張
スキーマ拡張後は、[System Management] コンテナを作成し、SCCM のコンピュータアカウントのフルコントロールを付与
インストールはドメインユーザーで実行しないと、インストールのチェックでスキーマ拡張が警告になるような気が。
# ローカルユーザーでは警告が表示され、ドメインユーザーでは全項目正常に完了していました。

■WebDAV の設定

Windows Server 2008 をサイト システムとして構成する方法

IIS 7.5 の場合は標準で WebDAV を追加することが可能ですので、別途 WebDAV をダウンロードする必要はありません。
WebDAV の設定は既定の Web サイト (ポート 80 のサイト??) に対して実行する必要があるようですね。

現在、クライアントプッシュインストールがうまくできていないので、この辺の設定が影響していそうな気がします。
管理ポイント関連の設定がうまくできていないと思うのですが、現在調査中です。

■クライアントのファイアウォール

Configuration Manager クライアントのインストールおよびアップグレードに関する問題

クライアントのファイアウォールも正しく設定されていないとプッシュインストールができません。
この辺に関してはグループポリシーで一括設定をする方向で考える必要がありそうです。

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

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