DNS Suffixes List

環境及問題描述：

        Server A（SA）用來share檔案，Client A（CA）是一台虛拟機，用來做一些測試。Client B（CB）是我的工作機，平時通過CB Remote Desktop SA和CA進行工作。

SA和CA在同一個機房，CB在辦公室，三台機器在同一個域（A.com）。CA使用另一個域（B.com）的賬号（userA.B.com）登陸，且userA.B.com有通路SA的share files的權限。

CA原本可以通過在位址欄中輸入\\SA可以通路SA的share Files，現在突然要求使用者名和密碼，正确填寫的情況寫依然提示密碼不正确，但是CB可以正常通路。三台機器都能互相ping通。

問題分析：

       三台機器都能互相ping通，首先說明網絡沒有問題。但是在環境沒有任何更改的情況下，突然不能通路，首先想到的是賬号的密碼被改變了。于是使用這個賬号在CB上嘗試通路SA的share files，OK，可以通路。密碼被修改的可能性排除。由于是跨域通路，想到是不是SA上的設定的通路權限發生了變化，仔細檢查，發現沒有異樣。這樣基本确定不是我們的機器出了問題。難道是IT在域控中做了某些新的設定，導緻了我們無法跨域通路？如果是這樣，那看來隻能聯系IT了。問題由此陷入僵局。抱着試一試的态度，使用Tracert指令檢視以下網絡情況，發現tracert SA 傳回的竟然是SA.C.com，終于發現問題了，原來是域字尾加錯了。看來是另一個域中新加了一台Server，名字竟然和我們的Server一樣，而且它所在的域的字尾名比我們的域字尾名有更高的優先級，是以導緻在使用\\SA通路時，實際通路的是另一台Server。

解決方案：

        既然是因為域字尾順序的問題，那麼把我們的Server所在的域的字尾名的優先級提高就OK了。網上查到資料，可以手動設定，也可以修改系統資料庫。

        這個網址有個很好的腳本可以解決這個問題：http://www.networksteve.com/forum/topic.php/Where_in_the_registry_are_the_keys/values_which_set_the_'Append/?TopicId=20181&Posts=2