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

文書翻訳 文書翻訳
文書番号: 318774 - 対象製品
この資料は、これまでに公開されていた文書番号 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=com
changetype: add
proxyAddresses: smtp:_3516c8@domain.com
proxyAddresses: SMTP:_160b1b@domain.com
proxyAddresses: smtp:_@domain.com
proxyAddresses: smtp:EXCHANGE1-PubIS@domain.com
proxyAddresses: 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=com
changetype: add
proxyAddresses: smtp:_5b4ac@domain.com
proxyAddresses: SMTP:_137336@domain.com
proxyAddresses: smtp:_2ee369@domain.com
proxyAddresses: smtp:_2124b1@domain.com
proxyAddresses: smtp:_136617@domain.com
proxyAddresses: smtp:_5a29c@domain.com
proxyAddresses: smtp:_2ed263@domain.com
proxyAddresses: smtp:_1f3e3d@domain.com
proxyAddresses: smtp:_134a14@domain.com
proxyAddresses: smtp:_58b1d@domain.com
proxyAddresses: smtp:_2dcff6@domain.com
proxyAddresses: smtp:_20fa76@domain.com
proxyAddresses: smtp:_133b9e@domain.com
proxyAddresses: smtp:_927c0@domain.com
proxyAddresses: smtp:_2bd94@domain.com
proxyAddresses: smtp:_3340fd@domain.com
proxyAddresses: smtp:EXCHANGE1-SRS@domain.com
proxyAddresses: 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 OFF

REM This script processes an LDIF Active Directory input file to create

REM an output file of proxy addresses to be deleted. You may set a

REM 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] pattern

REM Example: proxyfix.bat export.ldf export.out smtp:_

setlocal

set infile=%1

set outfile=%2

set pattern=%3

if {%pattern%}=={} set pattern=proxyAddresses

set pattern=%pattern:"=%

echo Input file is: %infile%

echo Output file will be: %outfile%

echo Current pattern is: %pattern%

pause

if exist %outfile% del %outfile%

:echo.>%outfile%.TMP

for /f "delims=" %%A in (%infile%) do call :DO_EACH_LINE "%%A"

echo ->>%outfile%.TMP

echo.>>%outfile%.TMP

echo Change "delete: proxyAddresses" to "add: proxyAddresses" to set instead of delete addresses>%outfile%.ERR

for /f "delims=" %%A in (%outfile%.TMP) do call :CHECK_EACH_RECORD "%%A"

copy /A %outfile%.ERR + %outfile%.TMP %outfile% >NULL

if errorlevel 0 if not errorlevel 1 (

del %outfile%.tmp

del %outfile%.err

echo LDIF import file saved as "%outfile%"

) ELSE (

echo FAILURE. Examine "%outfile%.tmp" and "%outfile%.err".

)

goto :EOF

:DO_EACH_LINE

set line=%1

set 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 :DN

if "%line:~0,15%"=="changetype: add" (

echo changetype: modify>>"%outfile%.TMP"

echo delete: proxyAddresses>>"%outfile%.TMP"

)

if "%line:~0,16%"=="proxyAddresses: " GOTO :FINDPROXY

goto :EOF

:DN

echo ->>%outfile%.TMP

echo.>>%outfile%.TMP

echo Processing %line%

echo %line%>>%outfile%.TMP

goto :EOF

:FINDPROXY

echo %line% | find /I "%pattern%"

if errorlevel 0 if not errorlevel 1 echo %line%>>%outfile%.TMP

GOTO :EOF

:CHECK_EACH_RECORD

IF NOT DEFINED CHECKNEXT SET CHECKNEXT=NO

set line=%1

set line=%line:"=%

IF "%CHECKNEXT%"=="NO" (

IF "%line:~0,4%"=="dn: " SET DN="%line%"

echo Checking %DN%

)

if "%line:~0,22%"=="delete: proxyAddresses" (

set CHECKNEXT=YES

GOTO :EOF

)

IF "%CHECKNEXT%"=="YES" (

IF "%line%"=="-" (

echo             !!!WARNING!!!>>%outfile%.ERR

echo All proxy addresses will be removed from>>%outfile%.ERR

echo %DN%>>%outfile%.ERR

echo by importing this file to Active Directory.>>%outfile%.ERR

)

set CHECKNEXT=NO

GOTO :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=com
    changetype: modify
    delete: proxyAddresses
    -
    							
    特定のプロキシ アドレスの名前がレコードに含まれていない場合、すべてのアドレスが削除されます。次のレコード形式では、1 つのプロキシ アドレスのみが削除されます。
    dn: CN=OBJECT,CN=CONTAINER,....,DC=com
    changetype: modify
    delete: proxyAddresses
    proxyAddresses: 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

プロパティ

文書番号: 318774 - 最終更新日: 2007年12月3日 - リビジョン: 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
"Microsoft Knowledge Baseに含まれている情報は、いかなる保証もない現状ベースで提供されるものです。Microsoft Corporation及びその関連会社は、市場性および特定の目的への適合性を含めて、明示的にも黙示的にも、一切の保証をいたしません。さらに、Microsoft Corporation及びその関連会社は、本文書に含まれている情報の使用及び使用結果につき、正確性、真実性等、いかなる表明・保証も行ないません。Microsoft Corporation、その関連会社及びこれらの権限ある代理人による口頭または書面による一切の情報提供またはアドバイスは、保証を意味するものではなく、かつ上記免責条項の範囲を狭めるものではありません。Microsoft Corporation、その関連会社 及びこれらの者の供給者は、直接的、間接的、偶発的、結果的損害、逸失利益、懲罰的損害、または特別損害を含む全ての損害に対して、状況のいかんを問わず一切責任を負いません。(Microsoft Corporation、その関連会社 またはこれらの者の供給者がかかる損害の発生可能性を了知している場合を含みます。) 結果的損害または偶発的損害に対する責任の免除または制限を認めていない地域においては、上記制限が適用されない場合があります。なお、本文書においては、文書の体裁上の都合により製品名の表記において商標登録表示、その他の商標表示を省略している場合がありますので、予めご了解ください。"

フィードバック

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com