Jeden z doporučených nástrojů pro ladění problémů s MSDTC je tzv. DTC Ping. Stáhnout si jej můžete např. zde
Již podle názvu je patrné, že jde o nástroj jehož jediným cílem je poslat PING a zjistit, zda je síť prostupná pro RPC pakety v obou směrech. Správná funkčnost distribuovaných dotazů vyžaduje obousměrnou komunikaci serverů. V principu tento nástroj funguje jednoduše. Mějme dva servery Server01 a Server02:
- Na serveru 01 spustíme DTCPing
- Na serveru 02 spustíme DTCPing
- Na serveru 01 zadáme Remote Server Name Server02 (jedná se o NETBios name) a stiskneme tlačítko PING
- Na serveru 02 zadáme Remote Server Name Server01 a opět stiskneme tlačítko PING.
Nejprve se provede PING na Server02, který odezvu vrátí. Pak Server02 provede POKE na Server01, který odezvu vrátí. Jednotlivé akce se postupně logují do textových souborů, lze tedy vidět v jaké fázi komunikace selhala. Okomentované příklady logů jsou součástí instalačního balíčku DTC Pingu.
Jak taková komunikace mezi servery vypadá nám napoví analýza síťového provozu mezi servery.
První tři pakety slouží k navázání TCP spojení mezi servery. Zdrojový port komunikace je 49191, cílový 135.
Další čtyři pakety slouží k navázání spojení s RPC Endpoint Mapperem (RPC Bind) a odeslání požadavku na sdělení cílového portu (MAP Request). Endpoint mapper tedy slouží k předávání informací klientovi, na kterém portu běží RPC služba, což v našem případě udělá posledním čtvrtým paketem (MAP Response), ve kterém nám sdělí číslo portu RPC služby.
Jak takový MAP Response vypadá, můžete vidět na obrázku výše. Jde o ukázku obsahu posledního paketu. Data se předávají pomocí protocol toweru. Cílový port je tedy 5008.
Následně je opět iniciováno TCP spojení, tentokrát z portu 49192 na port 5008. Dojde k navázání spojení mezi servery (RPC Call) a odeslání požadavku (RPC Request). Cílový server vrátí data (RPC Response).
Obdobně probíhá zbytek komunikace DTC Pingu. Příště se podíváme na další diagnostický nástroj, který se může hodit v souvislosti s MSDTC.