在杜拜已經快3周了，今天在建立exchange 2010 的dag時遇到了乙個小問題。
一行熟悉的建立dag的shell命令下去，居然報錯了！
錯誤內容如下：
c.x.com（客戶的網域名稱 ） 上 active directory 操作失敗。此錯誤不可重試，其他資訊： 拒絕訪問。 active directory 響應： 000000005：secerr:dsid-031521d0,problem 4003(insuff-acces-rights),data 0. 使用者沒有足夠的許可權。
震驚些許後，淡定了下來。
開始分析問題原因：
一、排除基礎邏輯問題：
1、確定我的操作帳戶許可權：使用者是domain admins 、 eterprise admins、 scheme admins、 exchange organization 組成員。結論：排除使用者許可權不足的問題；
2、分析ad結構，使用者的ad是典型的多域結構，林為x.com,下面的子域為a.x.com、b.x.com、c.x.com；自從ad公升級到2008r2後，主要應用的是c.x.com。杜拜的兩台dc和4臺exchange server 正是部署在c.x.com域的dubai站點中。此站點中的dc01和dc02都是gc。結論：排除站點中無gc問題；
二、綜合分析：
a、多域結構，多站點。複製鏈路頻寬不同，複製週期分三檔；
c、exchange架構是在根域擴充套件的，exchange trust subsystem組在根域；
b、exchange server 又是在子域安裝的，檢查exchange trust subsystem中的成員杜拜站點的4臺exchange server都在其中；
d、鏈路情況：北京到杜拜走的是4m國際鏈路專線，強制ad複製，問題依舊；
初步判斷問題原因：應該是多域｜多站點｜多鏈路複製｜的ad設計結構在缺乏監控維護時容易出現的許可權快取問題。
如何解決此類問題呢？兩種辦法：
a、常規辦法（見效慢，可治本）：等待ad複製機制自行解決。（這要考驗大家的耐性了！）
b、應急辦法（見效快，可治標）：將杜拜站點中的兩台dc加入到exchange trust subsystem組後，依次重新啟動dc01、dc02和4臺exchange。（dag建立完畢後一段時間後，可將杜拜站點中的兩台dc從exchange trust subsystem組移除出來。畢竟有點拔苗助長的感覺。）
android 乙個ad分析
入口new thread new runnable catch exception v4 start 在程式入口 有個g 方法下 修改g 方法 跳轉到s 方法進入遊戲 com.zplay.android.sdk.zplayad zplayad類的方法制空 com.zplay.android.sdk....
乙個memset引發的血案
前幾天做了一道bst題,提交了幾次都是wa,今天抽空拿了出來仔細瞧瞧總算被我發現禍頭根源.總結原因還在於自己對memset不太了解,以前用對估計也是瞎貓撞見死耗子 memset的介紹 void memset void buffer,int ch,size t count buffer 指向某段記憶體...
乙個分號引發的「血案」
再多的表情也無法詮釋我現在的心情！a b for matrices 這是很水的一道題，然而卻整整折騰了我2個多小時。從晚上6點多開始，花了沒幾分鐘就把 敲好了，可是資料一測，竟然不對，然後就開始找問題，找了很久，我竟然都還沒看出問題在哪，越找心裡越不爽，這麼做明明對的呀，一執行怎麼就錯了呢？一直到了...