ADSI 中的事件追蹤
Windows Server 2008 和 Windows Vista 引進 Active Directory 服務介面中的事件追蹤(ADSI)。 ADSI LDAP 提供者的某些區域具有複雜的基礎實作,或牽涉到一連串的步驟,因此難以診斷問題。 為了協助應用程式開發人員進行疑難解答,事件追蹤已新增至下列區域:
ADSI 中的 IAD 介面要求在用戶端上快取 LDAP 架構,以便正確封送處理屬性(如 ADSI 架構模型中所述)。 為了達成此目的,ADSI 會從儲存在本機磁碟上的架構 (.sch) 檔案,或從 LDAP 伺服器下載它,將每個進程的架構(以及每個 LDAP 伺服器/網域的架構)載入記憶體。 相同客戶端電腦上的不同進程如果可用且適用,則會在磁碟上使用快取的架構。
如果無法從磁碟或伺服器取得架構,ADSI 會使用硬式編碼的默認架構。 發生這種情況時,無法封送處理不屬於此預設架構的屬性,ADSI 會在擷取這些屬性時傳回錯誤。 許多因素可能會導致這種情況發生,包括剖析架構時發生問題,以及無法下載架構的許可權不足。 通常很難判斷使用特定預設架構的原因。 在此區域中使用事件追蹤有助於更快速地診斷問題並加以修正。
ChangePassword 和 SetPassword 會採用多個機制,根據可用的組態來執行要求的作業(如使用 LDAP 提供者設定和變更使用者密碼中所述)。 當 ChangePassword 和 SetPassword 失敗時,可能很難判斷確切的原因,而事件追蹤將有助於針對這些方法的問題進行疑難解答。
ADSI 會在內部嘗試盡可能重複使用LDAP連線(請參閱 連線快取)。 進行疑難解答時,追蹤是否已開啟新的連線以與伺服器通訊,還是使用現有的連線,這非常有用。 追蹤連線快取的生命週期(有時稱為系結快取)及其建立或關閉,以及是否進行連線轉介也很有用。 在無伺服器系結的情況下,ADSI 會呼叫DC定位器,為用戶內容網域選取伺服器。 ADSI 接著會針對後續連線維護網域伺服器對應的快取。 事件追蹤有助於追蹤DC的選擇,因此有助於針對連線相關問題進行疑難解答。
若要開啟 ADSI 追蹤,請建立下列登錄機碼:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\adsi\Tracing\ProcessName
ProcessName 是您想要追蹤的進程完整名稱,包括其延伸模組(例如“Svchost.exe”。 此外,您可以在此機碼中放置名為 PID 之 DWORD 類型的選擇性值。 強烈建議您設定此值,因此只追蹤特定進程。 否則,將會追蹤 ProcessName 所指定之應用程式的所有實例。
然後執行下列命令:
tracelog.exe -start sessionname **-guid #**provider_guid -f filename -flag traceFlags -level traceLevel
sessionname 只是用來標記追蹤工作階段的任意識別碼(稍後當您停止追蹤工作階段時,您必須參考此工作階段名稱)。 ADSI 追蹤提供者的 GUID 是 “7288c9f8-d63c-4932-a345-89d6b060174d”。 filename 會指定要寫入事件的記錄檔。 traceFlags 應該是下列其中一個值:
旗標 | 值 |
---|---|
DEBUG_SCHEMA |
0x00000001 |
DEBUG_CHANGEPWD |
0x00000002 |
DEBUG_SETPWD |
0x00000004 |
DEBUG_BINDCACHE |
0x00000008 |
根據下表,這些旗標會決定要追蹤哪些 ADSI 方法:
旗標 | 方法 |
---|---|
DEBUG_SCHEMA |
|
DEBUG_CHANGEPWD |
|
DEBUG_SETPWD |
|
DEBUG_BINDCACHE |
|
您可以結合 traceFlags 自變數中的適當位來合併旗標。 例如,若要指定 DEBUG_SCHEMA 和 DEBUG_BINDCACHE 旗標,適當的 traceFlags 值將會0x00000009。
最後, traceLevel 旗標應該是下列其中一個值:
旗標 | 值 |
---|---|
TRACE_LEVEL_ERROR |
0x00000002 |
TRACE_LEVEL_INFORMATION |
0x00000004 |
TRACE_LEVEL_INFORMATION會導致追蹤程序記錄所有事件,而TRACE_LEVEL_ERROR會讓追蹤程式只記錄錯誤事件。
若要終止追蹤,請執行下列命令:
tracelog.exe -stop sessionname
在上一個範例中, sessionname 與啟動追蹤區段之命令所提供的會話名稱 相同。
藉由指定特定 PID 來追蹤特定進程,比追蹤電腦上的所有進程更有效率。 如果您需要追蹤同一部計算機上的多個應用程式,可能會對效能造成影響;程式代碼的效能導向區段中有大量的偵錯輸出。 此外,系統管理員必須小心,才能在追蹤多個進程時正確設定記錄檔的許可權;否則,任何使用者都可能能夠讀取追蹤記錄,而其他使用者將能夠追蹤包含安全資訊的處理程式。
例如,假設系統管理員設定應用程式「Test.exe」的追蹤,而且不會在登錄中指定 PID 來追蹤進程的多個實例。 現在其他使用者想要追蹤應用程式「Secure.exe」。 如果追蹤記錄檔未正確限制,則所有用戶都必須將 「Secure.exe」 重新命名為 「Test.exe」,而且會加以追蹤。 一般而言,最好只追蹤疑難解答時的特定程式,並在疑難解答完成後立即移除追蹤登錄機碼。
由於啟用事件追蹤會產生額外的記錄檔,系統管理員應該仔細監視記錄檔大小;本機電腦上的磁碟空間不足可能會導致拒絕服務。
案例 1:系統管理員在設定使用者帳戶密碼的應用程式中看到意外的錯誤,因此他們會採取下列步驟,使用事件追蹤來修正問題。
撰寫可重現問題的腳本,並建立登錄機碼
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\adsi\Tracing cscript.exe\
使用下列命令,啟動追蹤會話,將 traceFlags 設定為 0x2 (DEBUG_CHANGEPASSWD), 並將 traceLevel 設定為 0x4 (TRACE_LEVEL_INFORMATION):
tracelog.exe -start scripttrace -guid #7288c9f8-d63c-4932-a345-89d6b060174d -f .\adsi.etl -flag 0x2 -level 0x4
使用測試腳本執行cscript.exe以重現問題,然後終止追蹤會話:
tracelog.exe -stop scripttrace
刪除登錄機碼
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\adsi\Tracing cscript.exe\
執行 ETW 工具Tracerpt.exe來剖析記錄檔中的追蹤資訊:
tracelog.exe -start scripttrace -guid #7288c9f8-d63c-4932-a345-89d6b060174d -f .\adsi.etl -flag 0x2 -level 0x4
案例 2:系統管理員想要追蹤已在執行中 w3wp.exe ASP 應用程式中的架構剖析和下載作業。 若要這樣做,系統管理員會採取下列步驟:
建立登錄機碼
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\adsi\Tracing w3wp.exe\
在該索引鍵內,建立名為 PID 的 DWORD 類型值,並將它設定為目前在本機電腦上執行之 w3wp.exe 實例的進程標識碼。
然後,他們會建立追蹤會話,將 traceFlags 設定為 0x1 (DEBUG_SCHEMA), 並將 traceLevel 設定為 0x4 (TRACE_LEVEL_INFORMATION):
tracelog.exe -start w3wptrace -guid #7288c9f8-d63c-4932-a345-89d6b060174d -f .\w3wp.etl -flag 0x1 -level 0x4
重現需要疑難解答的作業。
終止追蹤工作階段:
tracelog.exe -stop w3wptrace
刪除登錄機碼HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\adsi\Tracing\w3wp.exe。
執行 ETW 工具tracerpt.exe,以剖析記錄檔中的追蹤資訊:
tracerpt.exe .\w3wp.etl -o -report