現在オフラインです。再接続するためにインターネットの接続を待っています

Exchange で重複した不要なプロキシ アドレスを削除する

この資料は、これまでに公開されていた文書番号 318774 および 329617 の資料を統合したものです。
概要
管理者が Microsoft Exchange 受信者ポリシーを使用する場合、アドレス生成ルールを使用して、すべての Exchange 受信者の電子メール アドレスを自動的に構成およびカスタマイズすることができます。受信者更新サービスを使用すると、指定されたルールに従って、新規および既存のユーザーに一括してアドレスを適用することができます。これらのルールを構成するには、Exchange システム マネージャを使用して、受信者ポリシー オブジェクトのプロパティにアクセスします。

しかし、状況によっては、使用するルールが原因で、複数のアドレスが Exchange 組織全体で重複して使用される場合があります。Exchange の通常の運用中に重複したメール アドレスが検出されると、5.1.4 エラー コードを含む配信不能レポート (NDR) がサーバーに送信され、さらに予期せぬ動作が発生する可能性があります。また、次のイベント ID メッセージがアプリケーション イベント ログに出力される場合があります。



種類 : 警告
ソース : MSExchangeIS
分類 : General
イベント ID : 9514
コンピュータ : Exchange_Server_Name
説明 : このディレクトリ内の 2 つのオブジェクト、/dc=com/dc=domain/cn=configuration/cn=services/cn=microsoft exchange/cn=organization_name/cn=administrative groups/cn=administrative_group_name/cn=servers/cn=Exchange_server_name/cn=informationstore/cn=storage_group_name/cn=public folder store (Exchange_server_name) および /dc=com/dc=domain/ou=users/cn=user_name が同じプロキシを使用しています。

この資料では、重複したアドレスが適用される状況と、重複したアドレスを削除する方法について説明します。
詳細
次のルールは、SMTP (インターネット) メール形式のアドレスの典型的なルールです。
@domain.com
このルールを使用すると、mailnickname@domain.com の受信者ポリシーが適用される受信者オブジェクトごとに、電子メール アドレスが 1 つずつ追加されます。つまり、あるユーザーの Exchange 電子メール エイリアスが user1 である場合、user1@domain.com というアドレスがこのユーザーに適用されます。

また、Exchange を使用して自動名前付けルールを定義することもできます。たとえば、受信者のインターネット電子メール アドレスを、"mailnickname@domain.com" ではなく "FirstName_LastName@domain.com" の形で構成する場合などです。この変更は、次のアドレス生成ルールを使用して行うことができます。
%g_%s@domain.com
使用可能な自動名前付けの指定子および構文の関連情報を参照するには、以下の「サポート技術情報」 (Microsoft Knowledge Base) をクリックしてください。
285136 [XADM] 受信者ポリシーを使用して SMTP 電子メール アドレスの生成をカスタマイズする方法
自動名前付け指定を使用している場合は、ルールが適用される各受信者に関して、アドレス生成ルールで参照するフィールドが実際に存在することを確認する必要があります。これを確認しないと、Exchange 組織全体で、オブジェクトの電子メール アドレスが重複して、または複数生成される場合があります。

この問題の影響は、関連する受信者によって異なります。Exchange システム オブジェクトの中にはメールボックスが有効になっているものがあります。このようなシステム オブジェクトに誤ったアドレスを適用すると、パブリック フォルダのレプリケーションが失敗する、データベースをマウントできないなどの問題が発生する場合があります。また、この資料の「概要」で説明したイベント ID メッセージが出力される場合があります。

この動作の一例として、%g_%s@domain.com というアドレス生成ルールを定義していると仮定します。このルールでは、Active Directory オブジェクトの givenName 属性および sn 属性の値が指定され、これらの値を使用して電子メール アドレスが作成されます。givenName 属性の値が Jeff で、sn 属性の値が Smith であるユーザーの場合、電子メール アドレスは Jeff_Smith@domain.com になります。

ただし、givenName 属性および sn 属性は必須ではなく、配布リストやシステム エージェントなどのメールが有効なオブジェクトには、これらの属性がない場合があります。この場合、%g_%s@domain.com アドレス生成ルールの代わりに _@domain.com アドレス生成ルールが使用されます。このルールは、givenName 属性および sn 属性の値がないオブジェクトに関して、電子メール アドレスを _@domain.com としてハードコードするルールと同じになります。

新規の電子メール アドレスを適用すると、受信者更新サービスによって、フォレスト内のオブジェクトに同じアドレスが既に存在するかどうかの確認が行われます。存在する場合、新規のアドレスには区別するための数値が追加されます。たとえば、Jeff Smith という名前のユーザーが複数存在する場合、受信者更新サービスで新たに処理されるユーザー アカウントの電子メール アドレスは Jeff_Smith2@domain.com などになります。

つまり、givenName 属性や sn 属性の値がないオブジェクトを %g_%s@domain.com アドレス生成ルールに従って処理すると、_1@domain.com、_2@domain.com、_3@domain.com のような電子メール アドレスが得られます。

電子メール アドレスを必要とする新規受信者の確認が受信者更新サービスで行われるたびに、givenName 属性および sn 属性のないオブジェクトに対して電子メール アドレスが追加で作成される場合があります。_1@domain.com というアドレスを持つオブジェクトがあると仮定します。このアドレスは _@domain.com ルールに一致しないため、受信者更新サービスでは、"ハードコードされた" _@domain.com アドレスをこのオブジェクトに適用する必要があると見なされる場合があります。重複アドレスの確認により、_@domain.com アドレスは既に他のオブジェクトで使用されていることが検出され、その結果、_4@domain.com のようなアドレスが割り当てられる場合があります。

受信者更新サービスを最後に実行した以降に Active Directory でオブジェクトの属性が何も変更されていない場合、そのオブジェクトは、受信者更新サービスで確認されません。しかし、オブジェクトが何らかの方法で変更されている場合には、受信者更新サービスによって再度スキャンされ、新規の電子メール アドレスを適用するかどうかが特定されます。つまり、時間の経過と共に、指定子属性のない単一のオブジェクトに、_NNNN@domain.com の形式の電子メール アドレスが何十個、何百個も適用される可能性があります。

通常は、追加のアドレスは有効ではないため、通常のメール送受信には影響ありません。ただし、時間の経過と共に、受信者更新サービスのアイテム処理の効率がしだいに低下します。受信者更新サービスでは、オブジェクトに新規のアドレスを割り当てる際に、重複したアドレスを繰り返し確認する必要があるためです。たとえば、_1000@domain.com というアドレスが存在する場合、受信者更新サービスでは、_@domain.com 生成ルールに基づいて新規のアドレスを割り当てるには、重複アドレスの確認を千回以上行う必要があります。

Exchange では、重複した電子メール アドレスの確認が行われますが、この確認は、次の 2 つの理由により、絶対に確実とは言えません。
  • ドメインごとに別々の受信者更新サービスを構成する必要があります。単一ドメイン環境でも、2 つの受信者更新サービスがあります。一方の受信者更新サービスはドメイン コンテナ用で、もう一方 (エンタープライズ受信者更新サービス) はサーバーの構成コンテナ用です。
  • Active Directory レプリケーションの遅延が原因で、ある受信者更新サービスで割り当てられたアドレスが、別の受信者更新サービスで使用されているフォルダ データベースに適切なときに表示されない場合があります。
重複したアドレスが最も作成されやすいのは、エンタープライズ受信者更新サービスが接続されているドメイン コントローラと、ドメイン受信者更新サービスが接続されているドメイン コントローラが異なる場合です。指定子属性のないオブジェクトをそれぞれの受信者更新サービスで並行して処理すると、重複したアドレスが生成されます。

重複した複数のアドレスを防ぐために推奨される方法

自動名前付けルールで最も多く使用される文字は、アンダースコア文字 (_) です。ここでは、アドレス生成ルール SMTP:%g_%s@domain.com を基本的な例として説明します。

%g%s@domain.com というアドレス生成ルールでは、%g_%s@domain.com と同様の問題は発生しません。givenName 属性および sn 属性のないオブジェクトの場合、アドレス生成ルールは @domain.com となり、受信者更新サービスのデフォルトの電子メール アドレス形式である mailNickname@domain.com が呼び出されます。

自動名前付け指定子を使用しており、アドレス生成ルールのユーザー部分にハード コードされた文字を使用している場合に、自動名前付け指定子によるこのような問題の発生を防ぐには、受信者ポリシーにフィルタを構成して、指定した属性が存在することを明示的にテストする必要があります。
各 Exchange 受信者ポリシーには、ポリシーの適用先オブジェクトを定義する LDAP (Lightweight Directory Access Protocol) フィルタが 1 つずつ存在します。オブジェクトに関して定義できる最も単純なフィルタは (mailnickname=*) です。LDAP フィルタ構文では、attribute=* は、"attribute exists (属性が存在する)" と解釈されます。したがって、(mailnickname=*) フィルタを使用すると、mailNickname 属性が含まれるすべてのオブジェクト、つまりメールが有効なすべてのオブジェクトにポリシーが適用されます。このフィルタは、デフォルトの受信者ポリシー用のフィルタです。

追加の受信者ポリシーを作成する場合、ポリシーが適用されるオブジェクトを制限すると、フィルタはより複雑になることがあります。Exchange では、フィルタを手動で作成する代わりに、常識的な条件に基づいて管理者用のフィルタを構築するユーザー インターフェイスが提供されています。

たとえば、Exchange ユーザー、連絡先、グループをすべて取得するために、次のフィルタが自動的に生成されます。
(&(&(& (mailnickname=*) (|(&(objectCategory=person)(objectClass=user)(!(homeMDB=*))(!(msExchHomeServerName=*)))(&(objectCategory=person)(objectClass=user)(|(homeMDB=*)(msExchHomeServerName=*)))(&(objectCategory=person)(objectClass=contact))(objectCategory=group)(objectCategory=publicFolder) ))))
あるポリシーに関してこのフィルタを作成するには、次の手順を実行します。
  1. Exchange システム マネージャを起動します。
  2. [受信者]、[受信者ポリシー] を順に展開して、編集するポリシーのプロパティを開くか、新規のポリシーを作成します。
  3. [全般] タブで、[変更] をクリックします。
  4. [全般] タブのすべてのチェック ボックスをオンにします。
  5. [格納域] タブをクリックして、[任意のサーバー上のメールボックス] をクリックします。

    [詳細] タブでは、何も構成する必要はありません。
givenName 属性および sn 属性が存在することを確認するように、このフィルタを変更するには、次の手順を実行します。
  1. 受信者ポリシーのプロパティを開いて、[変更] をクリックします。
  2. [詳細] タブをクリックし、[名] ユーザー フィールドと [姓] ユーザー フィールドを選択して、これらのフィールドの状態を [存在する] に設定します。
この 2 つの手順を完了すると、LDAP フィルタは次のようになります。
(&(&(&(& (mailnickname=*) (| (&(objectCategory=person)(objectClass=user)(!(homeMDB=*))(!(msExchHomeServerName=*)))(&(objectCategory=person)(objectClass=user)(|(homeMDB=*)(msExchHomeServerName=*)))(&(objectCategory=person)(objectClass=contact))(objectCategory=group)(objectCategory=publicFolder))))(objectCategory=user)(givenName=*)(sn=*)))
フィルタの最後近くに (objectCategory=user)(givenName=*)(sn=*) が追加されていることが確認できます。このフィルタでは、givenName 属性と sn 属性の両方を持つユーザーのみが取得されます。このフィルタでは、配布リスト、連絡先、Exchange システム オブジェクトは無視されます。

重複したアドレスの検出と削除

自動名前付け指定子によって作成された重複アドレスは、通常は予測可能なパターン (_12345@domain.com、_12346@domain.com) に従います。その結果、これらのアドレスを自動的に検索して、自動クリーンアップを実行することができます。

Windows 2000 に含まれている Ldifde.exe ユーティリティを使用すると、Active Directory 情報をテキスト形式として LDIF 形式でエクスポートおよびインポートできます。Ldifde では、Exchange 受信者ポリシーのフィルタと同じ、標準的な LDAP 検索構文が使用されています。受信者ポリシーのフィルタを Ldifde コマンド ラインに貼り付け、コンテナ内のフィルタで取得されたすべてのオブジェクトを一覧表示するテキスト ファイルを作成することができます。次のコマンドは、テキスト ファイルを作成する一般的な構文の例です。
ldifde -f file.txt -d "dc=subdomain,dc=domain,dc=com" -l [attribute list] -r "[ldap filter]"
このコマンドでは、サブドメイン内の、フィルタに適合するすべてのオブジェクトが File.txt に書き込まれます。構成コンテナからオブジェクトを取得するには、コンテナおよびフォレストに最初にインストールされたドメインを指定する必要があります。例は次のとおりです。
ldifde -f file.txt -d "cn=configuration,dc=firstdomain,dc=com" -l [attribute list] -r "[ldap filter]"
-l パラメータを指定すると、File.txt に書き込むオブジェクトの属性を制限できます。-l を省略すると、各オブジェクトに関してすべての属性が一覧表示されます。属性をまったく表示しない場合は、-l nothing を使用します。これにより、各オブジェクトの識別名のみが File.txt にエクスポートされます。

重複した、または複数のプロキシ アドレスをすべて検索するには、組織内のすべてのドメインに対して、またフォレストの構成コンテナに対して、それぞれ Ldifde を実行します。これを行うには、不要なアドレスのみに一致する一意な検索パターンを定義する必要があります。

この例では、検索パターンを *SMTP:_*@* とします。この検索パターンでは、アンダースコアで始まる SMTP (インターネット メール) Exchange 電子メール プロキシ アドレスがすべて検索されます。たとえば、次のコマンドを実行します。
ldifde -f badproxies.txt -d "dc=domain,dc=com" -l proxyaddresses -r "(proxyaddresses=*smtp:_*@*)"
このコマンドにより、次のようなデータが Badproxies.txt にエクスポートされます。
dn: CN=Public Information Store (EXCHANGE1),CN=First Storage Group,CN=InformationStore,CN=EXCHANGE1,CN=Servers,CN=First Administrative Group,CN=Administrative Groups,CN=Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain,DC=comchangetype: addproxyAddresses: smtp:_3516c8@domain.comproxyAddresses: SMTP:_160b1b@domain.comproxyAddresses: smtp:_@domain.comproxyAddresses: smtp:EXCHANGE1-PubIS@domain.comproxyAddresses: X400:c=US;a= ;p=Organization;o=First Administrative Group;s=EXCHANGE1-Pub IS;dn: CN=Microsoft DSA,CN=EXCHANGE1,CN=Servers,CN=First Administrative Group,CN=Administrative Groups,CN=Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain,DC=comchangetype: addproxyAddresses: smtp:_5b4ac@domain.comproxyAddresses: SMTP:_137336@domain.comproxyAddresses: smtp:_2ee369@domain.comproxyAddresses: smtp:_2124b1@domain.comproxyAddresses: smtp:_136617@domain.comproxyAddresses: smtp:_5a29c@domain.comproxyAddresses: smtp:_2ed263@domain.comproxyAddresses: smtp:_1f3e3d@domain.comproxyAddresses: smtp:_134a14@domain.comproxyAddresses: smtp:_58b1d@domain.comproxyAddresses: smtp:_2dcff6@domain.comproxyAddresses: smtp:_20fa76@domain.comproxyAddresses: smtp:_133b9e@domain.comproxyAddresses: smtp:_927c0@domain.comproxyAddresses: smtp:_2bd94@domain.comproxyAddresses: smtp:_3340fd@domain.comproxyAddresses: smtp:EXCHANGE1-SRS@domain.comproxyAddresses: X400:c=US;a= ;p=Microsoft;o=Desperation;s=JESSICA-SRS;					
プロキシ アドレスにアンダースコアで始まる SMTP アドレスが含まれるオブジェクトのレコードが、Badproxies.txt ファイルに出力されます。これらのオブジェクトの他のアドレスもすべてエクスポートされます。これらの不要なアドレスは、後でフィルタを使用して除外できます。

アンダースコアで始まるアドレスは正規のアドレスとして使用することができます。その場合は、該当するオブジェクトを Badproxies.txt ファイルから削除してから作業を進める必要があります。該当するオブジェクトを特定するには、次の Ldifde コマンドを実行します。
ldifde -f file.txt -d "dc=domain,dc=com" -l givenname,sn,samaccountname,mailnickname,displayname -r "(|(givenname=_*)(sn=_*)(samaccountname=_*)(mailnickname=_*)(displayname=_*))"
このコマンドでは、名、姓、Windows ログオン名、Exchange エイリアス、表示名のいずれかがアンダースコアで始まるオブジェクトが検索されます。特定の環境に適したパターンに検索フィルタを適合させることができます。

: Ldifde コマンドの構文が誤っていても、エラーが返されない場合もあります。代わりに、検索結果がまったく表示されない場合があります。検索でオブジェクトがまったく返されない場合は、検索フィルタを若干変更して、Ldifde コマンドで結果が返されるかテストします。たとえば、アンダースコアを A の文字に置き換えます。

また、オブジェクトや属性を表示するアクセス許可がない場合も、検索でこれらの項目が返されず、特定のオブジェクトに対するアクセス許可がないことを知らせるエラーが表示されません。ドメイン コンテナを検索する場合は、ドメイン管理者としてログオンすることをお勧めします。構成コンテナを検索する場合は、エンタープライズ管理者としてログオンすることをお勧めします。

Badproxies.txt に、削除対象の電子メール アドレスを持つオブジェクトのみが含まれていることを確認したら、再度インポートできるように LDIF ファイルをフィルタ処理し、再フォーマットする必要があります。LDIF のインポート ファイルの形式とエクスポート ファイルの形式は、大幅に異なります。

次のサンプル スクリプトを使用すると、インポート ファイルの変換およびフィルタ処理を行うことができます。このスクリプトはサンプルとしてのみ提供されています。このスクリプトは、自己の責任において使用または変更してください。このスクリプト自体では Active Directory 情報を変更することはできません。変更を行うには、スクリプトから Active Directory へ、出力ファイルを手動でインポートする必要があります。行の不適切な折り返しを検出しやすいように、スクリプトの行間は 2 行に設定されています。このスクリプトを実行するには、次のテキストをコピーしてテキスト形式のファイルに貼り付け、ファイルに Proxyfix.bat という名前を付けます。
@ECHO OFFREM This script processes an LDIF Active Directory input file to createREM an output file of proxy addresses to be deleted. You may set aREM pattern to determine what addresses will be added to the output file.REM If no pattern is set, all addresses will be exported and available for deletion.REM Wildcard characters in the pattern are not permitted.REM "Quotes" in the input and output filenames are not permitted.REM Command line syntax:REM proxyfix.bat [input file] [output file] patternREM Example: proxyfix.bat export.ldf export.out smtp:_setlocalset infile=%1set outfile=%2set pattern=%3if {%pattern%}=={} set pattern=proxyAddressesset pattern=%pattern:"=%echo Input file is: %infile%echo Output file will be: %outfile%echo Current pattern is: %pattern%pauseif exist %outfile% del %outfile%:echo.>%outfile%.TMPfor /f "delims=" %%A in (%infile%) do call :DO_EACH_LINE "%%A"echo ->>%outfile%.TMPecho.>>%outfile%.TMPecho Change "delete: proxyAddresses" to "add: proxyAddresses" to set instead of delete addresses>%outfile%.ERRfor /f "delims=" %%A in (%outfile%.TMP) do call :CHECK_EACH_RECORD "%%A"copy /A %outfile%.ERR + %outfile%.TMP %outfile% >NULLif errorlevel 0 if not errorlevel 1 (del %outfile%.tmpdel %outfile%.errecho LDIF import file saved as "%outfile%") ELSE (echo FAILURE. Examine "%outfile%.tmp" and "%outfile%.err".)goto :EOF:DO_EACH_LINEset line=%1set line=%line:"=%IF "%line:~0,1%"==" " (echo.echo Broken line encountered! Could not process this line:echo "%line%"echo.pause)if "%line:~0,4%"=="dn: " GOTO :DNif "%line:~0,15%"=="changetype: add" (echo changetype: modify>>"%outfile%.TMP"echo delete: proxyAddresses>>"%outfile%.TMP")if "%line:~0,16%"=="proxyAddresses: " GOTO :FINDPROXYgoto :EOF:DNecho ->>%outfile%.TMPecho.>>%outfile%.TMPecho Processing %line%echo %line%>>%outfile%.TMPgoto :EOF:FINDPROXYecho %line% | find /I "%pattern%"if errorlevel 0 if not errorlevel 1 echo %line%>>%outfile%.TMPGOTO :EOF:CHECK_EACH_RECORDIF NOT DEFINED CHECKNEXT SET CHECKNEXT=NOset line=%1set line=%line:"=%IF "%CHECKNEXT%"=="NO" (IF "%line:~0,4%"=="dn: " SET DN="%line%"echo Checking %DN%)if "%line:~0,22%"=="delete: proxyAddresses" (set CHECKNEXT=YESGOTO :EOF)IF "%CHECKNEXT%"=="YES" (IF "%line%"=="-" (echo             !!!WARNING!!!>>%outfile%.ERRecho All proxy addresses will be removed from>>%outfile%.ERRecho %DN%>>%outfile%.ERRecho by importing this file to Active Directory.>>%outfile%.ERR)set CHECKNEXT=NOGOTO :EOF)GOTO :EOF
  • このスクリプトで生成される出力ファイルは、Active Directory にインポートする前に、編集する必要があります。スクリプトの実行方法によっては、ドメイン全体のすべてのプロキシ アドレスを削除するファイルが生成される場合があるためです。出力ファイルは、慎重に調べたうえで Active Directory に適用し、期待する動作が実行されることを確認する必要があります。
  • ファイルの最初の 3 行はコメントと空白です。ファイルを実行する前に、この部分を削除する必要があります。ファイルの先頭に警告がある場合も、削除する必要があります。
  • "Broken line encountered!" というメッセージでスクリプトが中断した場合は、報告されている行を修正してから、スクリプトを再度実行する必要があります。
  • LDIF 標準では、長い行は複数の行に分割されます。その際、改行後の最初の列にはスペースが入ります。サンプル スクリプトでは、このような行が見つかった場合の報告を除き、この標準は考慮されていません。ファイル内に損傷している行が多数ある場合は、グローバルな検索および置換の手順を使用してこれらを修正できます。これを行うには、複数行にまたがる検索と置換をサポートするテキスト エディタを使用します。Microsoft Word を使用してグローバルな検索と置換を行うことができますが、編集後のファイルは必ずテキスト ファイルとして保存します。Word で、次の項目を検索し、置換機能を使用して削除することができます。
    ^p[space character]
    検索テキストはキャレット文字 (^) と小文字の p であり、Ctrl + P ではありません。
  • 出力ファイル内のレコードによってすべてのプロキシ アドレスがオブジェクトから削除される場合、スクリプト ファイルの先頭に警告が挿入されます。このスクリプトを使用して LDIF インポート ファイルを生成する場合は、これらのファイルを詳細に調べて、インポートする必要のあるレコードのみが含まれていることを確認する必要があります。

    次のレコード形式では、すべてのプロキシ アドレスが削除されます。
    dn: CN=OBJECT,CN=CONTAINER,....,DC=comchangetype: modifydelete: proxyAddresses-							
    特定のプロキシ アドレスの名前がレコードに含まれていない場合、すべてのアドレスが削除されます。次のレコード形式では、1 つのプロキシ アドレスのみが削除されます。
    dn: CN=OBJECT,CN=CONTAINER,....,DC=comchangetype: modifydelete: proxyAddressesproxyAddresses: SMTP:OBJECT@domain.com-						
  • 出力ファイルで行われた変更を取り消すには (全体的な削除を行うレコードを除く)、出力ファイルを検索し、"delete: proxyAddresses" を "add: proxyAddresses" に置き換えてから、ファイルを再度インポートします。
  • コンテナ内のすべてのオブジェクトに関して、すべてのプロキシ アドレスをエクスポートするには、Ldifde 検索フィルタとして -R "(proxyAddresses=*)" を使用します。

    このファイルは、特定の時点で存在したプロキシ アドレスのバックアップ ファイルとして使用できます。Proxyfix.bat を使用してこのファイルを処理すると、このファイルをインポート ファイルにし、必要に応じてアドレスの復元に使用することができます。
  • Proxyfix.bat コマンド ラインの 3 番目のパラメータでフィルタを定義しない場合、入力ファイルに含まれるプロキシ アドレスがすべて出力ファイルにコピーされます。スクリプトの "delete: proxyAddresses" を "add: proxyAddresses" に変更すると、Active Directory 内の既存のアドレスに、アドレスをマージすることができます。また、"replace: proxyAddresses" を使用して、Active Directory からすべてのプロキシ アドレスを削除し、出力ファイルに含まれているアドレスのみで置き換えることもできます。
  • すべてのオブジェクトからすべてのプロキシ アドレスを削除すると、オブジェクトが削除されているため、受信者更新サービスが起動され、現在の受信者ポリシーに従ってすべてのアドレスが復元されます。しかし、この処理が完了する前に、送信中のメールの配信不能レポート (NDR) 生成される場合があります。構成コンテナ内のアドレスが削除されると、Exchange サービスが停止する場合や、既に停止している Exchange サービスを開始できない場合があります。マイクロソフトでは、特に構成コンテナ内のオブジェクトに関してプロキシ アドレスを処理するときは、細心の注意を払うことをお勧めします。
LDIF ファイルをインポートするには、次のコマンドを実行します。
ldifde -i -f delproxies.txt
reviewdocid XADM
プロパティ

文書番号:318774 - 最終更新日: 12/03/2007 07:53:00 - リビジョン: 5.5

  • Microsoft Exchange Server 2003 Enterprise Edition
  • Microsoft Exchange Server 2003 Standard Edition
  • Microsoft Exchange 2000 Server Standard Edition
  • Microsoft Windows Small Business Server 2003 Premium Edition
  • Microsoft Windows Small Business Server 2003 Standard Edition
  • kbinfo KB318774
フィードバック
src="https://c.microsoft.com/ms.js" '="">om/ms.js" '="">