• [アーティクル]

Exchange Queue & AOWA のタイムアウト、コマンドレットに関するトラブルシューティングなど

KC Lemson and Nino Bilic

質問 - 最近 Exchange Server 2003 を Exchange Server 2007 に移行しましたが、Restricted Users グループのユーザーが Outlook® Web Access (OWA) 2007 にログオンするときに [これは個人のコンピュータです] オプションを選択すると、タイムアウトが発生するという苦情が寄せられています。個人のコンピュータのタイムアウトを確認するには、どの Exchange 管理シェル コマンドを使用すればよいですか。

回答 - 少し話を戻しましょう。まず、個人のコンピュータと公共のコンピュータという異なる選択肢 (図 1 を参照) が提供される理由について説明してから、それぞれの動作について説明します。これらの選択肢を提供する目的は、ユーザーが空港のパブリック キオスクなどから OWA にログオンしているのか、自宅のコンピュータを使用してログオンしているのかを選択することにより、必要なセキュリティ レベルを Exchange に指定できるようにすることです。Exchange 管理者は、それぞれのセッションの種類に異なる動作を設定できます。たとえば、個人のコンピュータでは、認証されたセッションのタイムアウトを最大 3 日に設定し、公共のコンピュータでは、それよりも短い時間 (数分など) に設定したりすることができます。また、他の設定も、ユーザーの選択内容に応じて変更されるように構成することができます。たとえば、個人のコンピュータからのログオンのみに対して、SharePoint® ドキュメント ライブラリと Windows® ファイル共有へのアクセスを許可したりすることができます。もちろん、この設定が役立つのは、ユーザーが正しいオプションを指定した場合のみです。管理者は、ユーザーの判断を信頼できない場合、どちらを選択した場合にも同じタイムアウト値とその他の構成オプションが提供されるように設定することができます。

図 1 異なるタイムアウト設定とその他の構成オプションを提供できる、公共のコンピュータ用および自宅のコンピュータ用のセッション

図 1** 異なるタイムアウト設定とその他の構成オプションを提供できる、公共のコンピュータ用および自宅のコンピュータ用のセッション **(画像を拡大するには、ここをクリックします)

問題となっているオプションは、OWA に初めてフォーム ベース認証が導入された Exchange 2003 から引き継がれたオプションです (歴史に関する注 : フォーム ベース認証の最初の実装の一部は、すばらしいプログラム マネージャによって設計されました。名前までは明らかにしませんが、彼女は後に隔月の TechNet Magazine コラムの執筆で名声と富を得ました)。**

実際にこのオプションの設定が格納されているのはレジストリですが、Windows PowerShell™ にこのレジストリを更新するためのインターフェイスが用意されているため、Exchange 管理シェルを使用してこの設定を構成できます。次の例では、ユーザーがログオン中に [これは個人のコンピュータです] オプションを選択したときのタイムアウトを 1440 分 (1 日) に設定します。

set-ItemProperty ‘HKLM:\SYSTEM\CurrentControlSet\Services\
MSExchangeOWA’ -name TrustedClientTimeout 
-value 1440 -type dword

もちろん、この設定はレジストリに格納されているため、regedit を使用して手動でキーを更新することもできます。その場合は、次の方法を選択します。

#include <standard disclaimer about mucking
   with the registry.h>
#include <musing from author about when as a
   company we will ever be able to stop making
   that standard disclaimer about mucking with
   the registry.h>

どちらの方法を使用した場合でも、OWA が新しい設定を取得できるように、IIS を再起動する必要があります。IIS を再起動するには、[スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックした後、iisreset /noforce を実行します。

質問 - 職場で完全版の MAPI Outlook クライアントを使用しているすべてのユーザーに、今すぐ必要でないアイテムはすべて個人用フォルダ (.pst) ファイルにアーカイブするように呼びかけています。しかし、それらのアーカイブされたアイテムは、ユーザーが自宅から Outlook Web Access にログインすると表示できません。これらの .pst ファイルを OWA インターフェイスから表示するにはどうすればよいですか。

回答 - 残念ですが、OWA では .pst ファイルへのアクセスはサポートされていません。OWA は、始めからオンライン専用クライアントとして使用することを想定して構築されました。中でも、ローカル コンピュータ上に個人データを一切残さないようにすることに力が注がれました。たとえば、Exchange 2003 から導入された、セキュリティで保護されたログオフ メカニズムや、Exchange 2007 で導入された、添付ファイルのキャッシュされたコピーがハード ドライブ上に残らないようにする WebReady ドキュメント表示などの機能がその一例です。このため、OWA から .pst ファイルにアクセスするということは、OWA を展開しやすいオンライン専用クライアントにするという目的に合っていません。

そうは言うものの、一般的な .pst ファイルの使用方法は、議論してみたい興味深いシナリオの 1 つです。昨年の秋に会ったある顧客の環境では、ユーザーに与えられているメールボックス クォータのサイズが約 200 MB で、すべてのユーザーが 1 つ以上の .pst ファイルを持っていました。この組織には、ユーザー コンピュータを入れ替える際の作業を最小限に抑えるという方針があったため、すべてのユーザーは各自の .pst ファイルをネットワーク共有に格納する必要がありました。その代わり、このネットワーク共有は、中央のシステムによってバックアップされていました。

まず、ネットワーク共有からの .pst ファイルへのアクセスに関しては、既知の問題がいくつかあります。OWA が初めからオンライン専用クライアントとして設計されたのと同様に、.pst ファイルはもともとローカル コンピュータに格納するものとして設計されました。また、どんなに優れたネットワーク環境でも、待ち時間やその他の問題の影響を受けるため (さらに複数のユーザーが同時に特定のコンピュータにアクセスする必要があるため)、リモート コンピュータにデータを格納することは厄介な作業になる可能性があります。

2 番目に、この組織では、すべてのメール データを Exchange に格納したくないということ、およびこれらのデータを後からバックアップするということを理由に、やや小さいメールボックス クォータを使用していました (確かに会社のメールボックスのサイズが約 2 GB もあるという現在のような状況はぜいたくなのですが)。しかし、ユーザーは、バックアップされるネットワーク共有上の .pst ファイルにデータを格納しているため、管理者の作業はあまり軽減されていません。実際は、さまざまな要因によって作業が増加している可能性もあります。たとえば、複数の .pst ファイルを格納する単一のストレージ インスタンスがないこと、.pst ファイルの問題 (パスワードを忘れたユーザー、一般的なネットワークの問題など) に関連するヘルプデスクのコストがかかること、ウイルス攻撃後に .pst ファイル内のメッセージを消去しにくいこと、法的な問題が発生したときに .pst ファイル内のメッセージを検索しにくいこと、異なるバックアップ システムの管理オーバーヘッドが発生することなどが考えられます。

このため、構成に関連するすべての要素にかかるコストを考慮することを強くお勧めします。コストが積み重なり、別の構成を使用した方が最終的には良い結果が出る場合もあります。

質問 - Exchange 管理シェル コマンドのことで悩んでいます。コマンドが動作しません。どこに問題があるのでしょうか。

回答 - その質問に答えることはできませんが、どのような問題が発生しているかにかかわらず、解決に役立つ最善の方法は、start-transcript という Windows PowerShell の組み込みのコマンドレットを使用して、実行したコマンドとその結果を記録することです。このコマンドを実行することにより、記録されたコマンドの詳細をコピーして、電子メール メッセージ、ブログの投稿、フォーラムでの質問などに貼り付けて使用することができます。

Exchange 管理シェル セッションを開き、図 2 のように「start-transcript」と入力します。これにより、以降のコマンドが、Exchange 管理シェルによって図 3 のようなテキスト ファイルに自動的に記録されるようになります (心配は要りません、このテキスト ファイルの場所はアプリケーションによって表示されます)。記録を停止するには、「stop-transcript」と入力するだけです。

図 2 実行したコマンドとその結果を記録できる start-transcript コマンドレット

図 2** 実行したコマンドとその結果を記録できる start-transcript コマンドレット **(画像を拡大するには、ここをクリックします)

図 3 Windows PowerShell によってテキスト ファイルとして保存されたコマンドのコピー

図 3** Windows PowerShell によってテキスト ファイルとして保存されたコマンドのコピー **(画像を拡大するには、ここをクリックします)

使用したコマンドと返された結果がすべて記載された一覧は、どの担当者が問題のトラブルシューティングを行う場合でも非常に役立ちます。ただし、知らないユーザーや信頼していないユーザーとログを共有する場合は、機密データが含まれていないかどうかを事前に確認する必要があります。

質問 - Exchange 2007 セットアップでは、ルート ドメインに Microsoft Exchange Security Groups という新しい組織単位 (OU) が作成され、この組織単位には 5 つの新しい Exchange 2007 セキュリティ グループが含まれるそうですが、これらのグループを他の OU やドメインに移動することはできますか。

回答 - これは、Active Directory の準備段階でルート ドメインに作成される 5 つのユニバーサル セキュリティ グループ (USG) のことですね。この 5 つを次に示します。

  • Exchange Organization Administrators
  • Exchange Recipient Administrators
  • Exchange View-Only Administrators
  • Exchange Servers
  • ExchangeLegacyInterop

Exchange 2000 と Exchange 2003 では、既定のセキュリティ グループ (Exchange Domain Servers と Exchange Enterprise Servers) の移動に関する制限がありました。もう少しわかりやすく言うと、移動することはできましたが、移動すると問題が発生しました (この問題の詳細については、support.microsoft.com/kb/260914 を参照してください)。このため、非常に制限されていたと言えます。

Exchange 2007 では、この動作が変更されました。既定の 5 つのグループは移動することができます。これらのグループは、同じドメイン内の異なる OU や、異なるドメインに移動することができます。

これら 5 つのグループを見失い、どこに移動したか (つまりどの OU またはドメインに移動したか) がわからなくなった場合は、次のコンテナにある otherWellKnownObjects 属性の値で場所を確認できます。

CN=MicrosoftExchange,CN=Services,
CN=Configuration,DC=<DomainName>,DC=com

グループが移動されると、対応するこの属性の値も更新されるため、常にグループの場所を確認できます。すてきでしょう?

質問 - ドメイン内に Exchange Install Domain Servers というグローバル セキュリティ グループを見つけました。このグループの目的について教えてください。

回答 - 管理している Active Directory® について非常によく把握していますね。実際に、Exchange 2007 サーバーがインストールされているすべてのドメインには、Exchange Install Domain Servers というグループがあります。このグループは、Microsoft Exchange システム オブジェクト (MESO) OU 内に作成されます。このグループを確認すると、ユニバーサル セキュリティ グループである、ルート ドメインの Exchange Servers グループのメンバになっていることがわかります。

簡単に言うと、Exchange Install Domain Servers グループは、いずれかの子ドメインで Exchange 2007 セットアップを実行した場合に Active Directory のレプリケーション サイクルにかかる時間が長くなるという問題を回避するために使用されます。たとえば、Root というルート ドメイン、Child という子ドメイン、および Grandchild という Child の子ドメインがあるとします (ええ、この名前付け方式は素晴らしいですね。パスワードも想像がつくのではないでしょうか)。

この組織で Exchange 2007 のセットアップを開始するには、まずスキーマを拡張し、Root ドメインを準備する必要があります。これにより、1 つ前の回答で説明した、最初の 5 つの USG が作成されます。

次に、Grandchild ドメインでセットアップを実行する必要があるとしましょう。セットアップは、ローカル ドメインで Exchange 2007 サービスを開始できるようにするために、Root ドメインにある Exchange 2007 コンピュータのコンピュータ アカウントを Exchange Servers グループに配置します。しかし、現在は Grandchild ドメインで操作を行っているため、Exchange Servers グループのメンバシップがレプリケートされるまでにしばらく時間がかかる場合があります。

Exchange Servers はユニバーサル グループであるため、このグループのメンバシップはフォレスト全体にレプリケートされます。レプリケーションでは待ち時間が発生する可能性があるため、Grandchild ドメインで実行されたセットアップが完了するまでにアクセス許可がレプリケートされず、セットアップがサービスを開始できない場合があります。この理由から、ドメインで最初の Exchange 2007 サーバーがセットアップされたときに、そのローカル ドメイン内に Exchange Install Domain Servers グループが作成されます。

この Exchange サーバーのコンピュータ アカウントは、セットアップ処理によって、このグループのメンバとして配置されます。このグループのメンバには、セットアップの終了時に Exchange Servers グループのメンバシップが Root ドメインからまだレプリケートされていなくてもサービスを開始できるアクセス許可が与えられます。通常は、ローカル ドメインのレプリケーションの方がドメイン間のレプリケーションよりも時間がかからないことに注意してください。

質問 - Exchange 2007 のドキュメントには、Exchange 2007 用にスキーマを拡張する前でも、/PrepareLegacyExchangePermissions スイッチを指定してセットアップを実行する必要があると記載されていましたが、この理由を教えてください (また、このスイッチの名前はもっと長くなる可能性はあったのでしょうか)。

回答 - セットアップの実行前にこのドキュメントを読んでいただき、ありがとうございます。参考になったでしょうか。

正確に言うと、/PrepareLegacyExchangePermissions (省略形は /pl) は、Exchange 2000 と Exchange 2003 の受信者更新サービス (RUS) に、Exchange Information および Personal Information プロパティ セットへの書き込みを行うためのアクセス許可を与えるスイッチです。Exchange 2007 用にスキーマを拡張する処理を実行すると、いくつかの属性 (プロキシ アドレスなど) が Active Directory のパブリック インフォメーション プロパティ セットから Exchange Information プロパティ セットに移動されます。既定では、Exchange 2000 と Exchange 2003 の RUS は、Exchange Information プロパティ セットに書き込むための権限を与えられていません。これは、実際の環境で、最初に Exchange 2007 用にスキーマを拡張する処理を実行した場合、Exchange 2000 と Exchange 2003 RUS が新しい受信者をスタンプできなくなるため、これらのサービスで問題が発生することを意味します (これらのプロパティ セットの詳細については、msexchangeteam.com にある私たちのブログをご覧ください)。

このため、スキーマを Exchange 2007 用に拡張する前に /pl スイッチを実行することは非常に重要です。また、この変更が Exchange 2000 または Exchange 2003 受信者が属する (つまり、RUS が存在する) すべてのドメインにレプリケートされるようにする必要があります。後から新しいドメインをフォレストに追加し、Exchange 2000 または Exchange 2003 の RUS をそれらのドメインに追加する必要が生じた場合、それらのドメインでも /pl スイッチを実行する必要があります。

それに関連した話ですが、初めて /pl スイッチを実行する場合、Enterprise Admins グループのアカウントを使用してこのスイッチを実行すると役立ちます。このアカウントを使用した場合、ルート ドメインで実行されたセットアップは、/pl を実行する必要があるドメインを識別し、それらのすべてのドメインで /pl スイッチを実行します。Enterprise Admins グループのアカウントを使用していない場合は、Domain Admins グループのアカウントを使用して、ドメインごとに /pl スイッチを実行する必要があります。幸運にも、Exchange 2007 のドキュメントには、アクセス許可の要件がすべて記載されています。

最後に、このスイッチの名前がもっと長くなる可能性はあったかという質問がありましたね。/PrepareLegacyExchangePermissions と早口で 3 回言ってみましょう。

PrepareLegacyExchangePermissions

PrepareLegacyExchangePermissions

PrepareLegacyExchangePermissions

/Prepare-LegacyExchangePermissionsWOWThisIsaReallyLongname という名前にしようかとも思いましたが、短くてわかりやすい /PrepareLegacyExchangePermissions を採用しました。

そうです、この話は今作りました。しかし、省略形の /pl を使用できるという話は本当です。これは本当です。絶対に本当ですから。

KC Lemsonは、Exchange Server のユーザー エクスペリエンス マネージャです。暇な時間は、子供の大学進学資金をどのように投資したらよいかが書かれた電子メールが届くのを待っています。

Nino Bilicは Exchange Server のテクニカル リードです。彼は、通常の勤務時間中は Halo を何回プレイできたかを確認することに追われています。

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; 許可なしに一部または全体を複製することは禁止されています.