本页内容執行摘要
架構變更介紹
Microsoft Active Directory 的環境
變更管理系統的架構
變更流程逐步解說
降低風險
最佳作法與 IdM 標準
結論
執行摘要MicrosoftR Active DirectoryR (AD) 是一個全域通用的身份識別與存取管理架構，它具備一般目錄的功能和擴充性，如果仍在開發的應用程式需要目錄功能，AD 是應用程式開發人員最好的選擇。AD 能夠將目錄管理工作集中簡化，降低開發成本，促進資料相容性。舉例來說，對同一個應用程式採用 AD 驗證與授權服務互通功能可謂一舉兩得： 無須額外建立安全性資料庫，還能簡化企業安全性管理。
需要使用 AD 支援商務處理流程或新工具時，應用程式開發人員會將 Active Directory 的架構加以延伸。架構是 AD 的元件，可以定義目錄服務用來儲存資料所需的所有物件和屬性。一般來說，架構變更是由架構管理員獨自進行，或在軟體安裝過程中自動進行。Microsoft 建議您採用制度化的變更管理系統，使架構變更以最佳結果呈現。
本文與讀者分享 Microsoft IT 是如何以制度化的工作流程來管理 AD 的架構變更過程。有了制度化的流程，才能夠確實將每個變更的設計、實作、使用、所有權、安全性徹底部署在整個系統中。根據 Microsoft IT 部門的經驗，採用 MicrosoftR Operations Framework (MOF) 建構出功能強大且規劃仔細的變更管理系統，結果能使架構的基礎結構非常容易管理。Microsoft IT 採用 MOF 設計出分階流程，包含考量、評估、測試、試用和實作五大里程碑。因為仔細規劃並試用架構變更，加上管理與客戶的溝通與認知，AD 架構變更的過程相當順利，同時將 AD 的風險降至最低。更由於全程掌握，沒有意外，各方能夠專心實現商業上的目標。
企業若有志於透過制度化的工作流程，使每一次的架構變更都能夠得到最好的結果，本文件適合您閱讀。本文撰寫對象是熟悉 Windows 功能、AD 和識別管理的 IT 專業人員、架構人員和目錄服務專業人員。文中深入探討 Microsoft IT 採用的架構變更管理解決方案，包括最佳作法、建議和部署方面的的考量。您可以使用 Microsoft 產品，將變更管理規劃方面的建議、原則和技巧落實在大多數的企業級 IT 環境。然而企業環境各不相同，採用時不應該把這份文件當作是程序指南，每個企業應該根據本身的需求對下列內容作選擇性的採用。
附註： 基於安全性考量，本文所採用的樹系、網域、內部資源、組織的名稱，以及內部開發的安全性檔案名稱並非 Microsoft 內部實際採用的資源名稱，而且僅供說明之用。
返回页首
架構變更介紹有經驗的 Windows 應用程式開發人員在建立需要目錄功能的應用程式時，會利用或延伸既有的 AD 功能，包括識別管理、集中配置和存取管理，或是一般的目錄功能。延伸或使用 AD 功能可讓應用程式利用既有的安全子系統以及全域目錄中的共享資料，使資源達到最大效率，因此 Microsoft 建議您使用或延伸既有的 AD 功能，而非在 AD 外另行建立新的識別資料庫。
附註： 延伸架構 指的是修改或更新架構的過程。
由於這對 AD 可能會造成相當大的影響，您一定要確定架構變更不會造成意料之外的結果。只要有變更規劃、測試和用戶認知管理，企業就能夠順利的變更架構。
架構基礎概念架構是 AD 的元件，可以定義目錄服務用來儲存資料所需的所有物件和屬性。目錄服務把物件當作是儲存的單位，每回目錄服務處理資料時，都會向適當的物件定義要求架構。接著目錄服務會根據架構內的物件定義，來建立物件並儲存資料。舉例來說，系統管理員建立新的使用者物件時，AD 就會使用架構定義來建立並配置預設的使用者物件。架構的實體架構是由目錄內架構磁碟分割中的物件定義所組成，樹系中的所有網域都分享同一個架構。
物件定義決定了物件能夠儲存的資料類型以及資料語法。如 [圖 1] 所示，子類別物件繼承了上層類別的特性。而架構就是藉著這些資訊，確保所有的物件遵守各自的標準定義。因此 AD 有辦法儲存、擷取和驗證所管理的資料，不管資料由何種應用程式產生。唯有已經在架構內具有物件定義的資料才能夠儲存在目錄中。
如果需要在目錄中儲存新類型的資料，架構管理員得先在架構中建立新的資料物件定義。
[圖 1] 具備繼承能力的架構物件類別
修改架構一般來說，使用者日常作業並不需要直接接觸到架構。AD 使用架構來協助建立已經儲存在目錄中的物件，使用者與這些物件而不是架構進行互動。系統管理員則會直接接觸到架構，透過添加或修改既有定義的方式來調整架構。由於存取控制清單 (ACL) 保護架構物件，唯有經過授權的使用者才能修改架構。
延伸架構預設的架構是由 AD 樹系提供的一組類別和屬性所構成。如果架構內既有的類別和屬性定不符合組織的需求，組織可以透過添加或修改架構物件的方式來延伸架構。有經驗的開發人員和系統管理者可以替既有的類別定義新的類別與屬性，以便在目錄中存放新類型的資訊，達到延伸架構的目的。
架構管理員修改架構的原因通常是：
- 套裝應用程式使用 AD 功能：安裝的應用程式如果具備 AD 功能，可能會添加自訂物件定義以便在目錄中儲存資訊，連帶的修改了架構。例如，Microsoft Office Live Communications Server 2003 會在架構中添加新的物件類別和額外屬性，以便隨時感知目前狀態。
- 內部應用程式使用 AD 功能：安裝自訂的應用程式若使用 AD 功能也可能會需要改動架構。
架構修改範圍延伸架構是進階操作，需要經過審慎的規劃和測試。要在樹系中使用和操作 AD，絕對少不了架構。因此，企業在延伸或變更系統提供的基底架構前，一定要仔細思量，以免發生意外。架構變更可能會可能會影響各種重要設定，如目錄資料庫索引、通用目錄資料可用性，以及 AD 資料庫的大小和完整性。
一般來說，架構一旦修改就沒有辦法復原，因此考量變更時切記以下三點：
只要事前規劃、試用架構變更，加上管理與客戶的溝通與認知，系統管理員就能順利地進行 AD 架構變更，並將 AD 的風險降至最低。
架構變更管理延伸架構並不複雜，並能帶來強大的功能。只要變更管理系統規劃得當，組織就能夠以可預期且一致的方式實施架構變更，將心力放在業務或營運目標上。因此，企業在延伸架構前，務必要建立正規化的架構變更管理流程。
流程設計設計完善的變更管理流程可作為標準的工作流程，實現最佳結果。有了流程，參與各方的責任歸屬和認知才會清清楚楚。流程應該提供整個工作從頭到尾的詳細指示，不管是提出最初的變更要求，還是決定由誰向參與各方報告變更完成，都要清楚界定。
Microsoft IT 採取的流程Microsoft 在 Microsoft Windows 2000 Server 中部署了 AD 目錄服務，自此即成為 AD 與開發使用 AD 功能軟體方面的權威。由於 Microsoft 本身即是軟體開發公司，我們內部變更 AD 架構比一般企業客戶還要頻繁，再加上 Microsoft 開發的軟體通常也使用 AD 功能，因此 所以 Microsoft IT 內部安裝和測試軟體時經常需要變更架構。此外，由於 Microsoft IT 在開發過程中的生產環境使用自己的 Beta 版軟體，必須替每一個程式安裝數個發行前的過渡版本，每次都可能需要進行架構更新。
過去五年來 Microsoft IT 已經進行不下 25 次各不相同的架構變更，大部分部署至多個樹系。當時所建立的工作流程已經隨著時間演變為正規化的變更流程，隨著經驗的累積，Microsoft IT 將工作流程標準化，成為 Microsoft 內所有架構變更採用的正式變更管理系統。Microsoft IT 架構變更管理流程不僅能架構變更標準化，還為主要產品首展帶來了最佳結果，包括：
- Exchange Server 2003：Microsoft IT 為了測試目的，替 Exchange 安裝了六個測試過渡版本，每次都替四到六個生產環境變更架構，而且在不干擾網路運作的情況下完成任務。
- Data Protection Manager (DPM)：Microsoft IT 將 DPM 的測試版安裝至四個生產環境，架構變更後使用者能夠復原自己存放在檔案伺服器共享目錄中的檔案。
- Avaya Unified Messaging：Microsoft IT 將 Avaya 毫無問題地延伸至三個生產環境。
返回页首
Microsoft Active Directory 的環境要瞭解 Microsoft 採用的架構變更流程，一定要知道 AD 的環境、所支援的 Identity and Access Management 基礎結構以及支援 AD 的團隊所具備的特性。
基礎結構概觀Microsoft Identity and Access Management 基礎結構與其他大型的企業組織環境很類似，基礎結構提供 Microsoft 運算環境不可或缺的成套服務。AD 是每一個樹系內識別基礎結構的根基，能夠集中管理識別，使資源可用與安全。Microsoft 的經驗證明，基礎結構也可以當作 Microsoft 開發的試用版識別管理軟體的基礎。
多樹系設定如 [圖 2] 所示，Microsoft Identity Infrastructure 具有集中管理數個樹系的特性。
[圖 2] Microsoft Identity Infrastructure 的組織架構
Microsoft IT 對這些樹系有相當豐富的管理經驗，我們還與每個樹系技術團隊管理其他的樹系。每個樹系與「企業樹系」共享單向或雙向信任。Microsoft 使用的應用程式中，有百分之七十都在「企業樹系」上。這些樹系內又有超過 35 個識別存放區，包括 AD、SAP、Siebel、Group Membership Manager、Account Manager Application 等各式各樣的存放區。Microsoft IT Identity Management 團隊在多個識別存放區之間使用 Microsoft Identity Integration Server (MIIS) 2003 with Service Pack 1 (SP1) 應用到同步化的識別資料。
Microsoft 內部需要多樹系有許多原因。軟體應用程式在開發期間，例如 Exchange 的發行前版本，需要有自己的樹系以避免在發行前的開發和測試初階干擾到「企業樹系」。透過外部網路與外部夥伴合作時，樹系也扮演安全性角色。此外，基於 MSNBC 合資上的法律要求，MSNBC 也需要有一個額外的樹系。最後，Microsoft IT 也額外替公司內的業務部門 (例如 MSN 部門) 建立樹系。
網路設定Microsoft 在全球有 215 個 DC，分處於 5 個由 Microsoft IT 管理的樹系。包括超過 16 個網域、138 個樹系 DC 和 30 個外部網路 DC。共有 184 個 AD 站台，其中 63 個有 DC，每日處理 60,000 個各不相同的樹系登入。企業樹系有九個網域，內有超過一百萬的物件數量，通用目錄檔案平均大小為 9.0 GB。網路平均每秒提供 1.5 MB、每秒平均 256 KB 的最小頻寬。
複寫拓樸Microsoft IT 在站台間使用五個躍點，使端對端延遲長達五小時，藉此設定樹系每小時複寫。我們維護一個複雜的拓樸，以對應在全球超過 300 個站台的網路拓樸。架構變更等絕大多數的系統管理修改都在美國華盛頓州的 Redmond 進行。Redmond 是一個中間點，與其他站台的最大延遲可達三小時。
架構變更支援環境Microsoft IT 負責指導和維護微軟全球資訊系統的所有相關活動。Microsoft IT 組織中，Identity Management (IdM) 團隊和 Infrastructure Engineering (IEng) 團隊負責 AD 事宜。IdM 團隊專門負責跨樹系的識別管理，尤其是 AD 架構管理。而 IEng 團隊負責管理 DC 和複寫。
Microsoft IT 組織Microsoft IT 負責帶動全球營運，並提供 IT 服務給微軟公司上下。Microsoft IT 負責指導和維護微軟全球資訊系統的所有相關活動，維護技術基礎結構、企業以及行銷資訊系統，包括生產、分銷等關鍵的內部系統。Microsoft IT 努力提供世界級的工具軟體，使業務能夠順利運作，因為我們的工作就是帶頭設計並整合公司的策略、流程和架構。
Microsoft IT 提供各式各樣的服務，包括伺服器和使用者支援、電信管理、網路運作和資訊安全性。我們也負責管理全球超過 300,000 台個人電腦的連線，確保分處 90 個國家，超過 400 個微軟據點的 63,000 名人員以及 35,000 名的承包商和供應商都能夠一天 24 個小時，一週七天，隨時存取企業網路服務與資源。
由於 Microsoft 的主要業務是軟體設計，IT 也肩負不同於全球其他提供者的第二個職責。Microsoft IT 是全公司採納新技術的先鋒，在產品正式發行給客戶前負責測試和部署各種 Microsoft 產品，例如 SharePoint™、Windows Server 2003、Microsoft Identity Integration Server 2003 和 Exchange Server 2003。咱們微軟內部戲稱發行前的部署過程為「試吃自己做的狗食」，簡稱「吃狗食 (dogfooding)」。
Microsoft IT 在微軟企業環境使用發行前的產品，徹底地測試產品在實際環境的情況，評估產品的商業價值，藉此調整最後產品的配置，界定出最佳作法，作為客戶產品開發的引導。我們以 dogfooding 積極地在企業環境中進行測試，使 Microsoft 有信心發行高品質的產品。產品小組從這個過程中學習經驗，改善產品設計，提升最終版本的價值。
Microsoft IT Identity Management 團隊 (IdM)IdM 團隊負責管理 Microsoft 的識別管理基礎結構，負責所有相關的應用程式或工具、帳戶與群組，以及新增或變更的工作流程。
IdM 團隊管理所有使用者帳戶，包括一般使用者、提升存取使用者、服務帳戶以及內建帳戶，還負責管理員等群組與相關的內部應用程式。此外，IdM 團隊也管理組織單位、群組原則物件和信任。該群組使用 MIIS 2003 SP1 監督樹系間的同步作業，以便將各種物件類型如使用者和群組、站台和子網路，以及印表機佇列進行同步化，這樣使用者在不同的樹系間切換時應用程式的功能以及資源的使用才會一致。
IdM 團隊的職責包括管理 AD 架構。IdM 團隊對目錄的內容具有所有權，所以能將目錄中的資料以單一邏輯使用案例的方式管理。為了要做到跨樹系的一致性，IdM 團隊在變更一個樹系的架構時，也會一併變更所有其他的樹系。雖架構變更流程是由 IdM 團隊管理，但是他們並不管理流程中所有的事務，例如 DC、複寫拓樸或應用程式就不是由他們親自管理，而是由 IEng 團隊和特定的應用程式所有者來負責。
Infrastructure Engineering 團隊 (IEng)IEng 團隊負責 Microsoft IT 的核心基礎結構伺服器，其中包括 AD 所在的 DC。這個團隊管理伺服器的效能、系統管理和設定，還負責根據應用程式的相依性和網路連線能力，判斷將 DC 放在網路中哪個位置。IEng 團隊負責管理資料複寫拓樸。正由於肩負資料複寫拓樸的責任，他們也參與架構變更流程，與 IdM 團隊攜手合作，確保架構變更能成功地複製到所管理的每一個樹系中。
Microsoft 架構管理軟體開發是微軟內部進行架構變更的主要原因。每次業務單位安裝或更新使用 AD 功能的軟體而影響到架構時，該單位就必須逐一走過架構變更管理過程。Microsoft IT 在微軟的生產環境進行 dogfooding 測試 Beta 軟體，支援每個產品團隊的開發工作。Dogfooding 使得架構管理工作更加複雜，因為 Microsoft IT 需要在開發過程中安裝好幾個過渡建置版本，無形中帶來更多架構變更。
變更管理系統IdM 團隊設計了一個供內部使用的網站，引領任何要求架構變更的人員逐步作業。網站裡有步驟的概略介紹、相關資訊的連結，還有一個線上架構變更表單，提出要求的人要填寫表單，由 IdM 團隊審核。確定填表人確實填寫完畢，而且所有相關問題都解決後，IdM 團隊會評估變更要求在業務上的必要性。如果業務上的確需要，IdM 團隊會將要求送到變更佇列中。要求表單一經核准，該團隊就會建立一個架構組件文件。架構組件是一個會隨著變更開始到結束而變動的文件。一完成過程中的各個步驟，IdM 團隊即輸入所有的額外資訊並予以批准。IdM 團隊修改架構時，IEng 團隊會從樹系中進行複寫，並確保沒有失誤。大功告成後，IdM 團隊會將表單、指令碼和所有相關的資訊都放在一個資料夾內，存放在安全的地方以供備份。
架構變更IdM 架構變更管理系統負責：
- 延伸：Microsoft 中最常見的架構變更就是延伸。在所有的架構管理方法中，延伸比較簡單，可能的衝擊也比較少。添加新的定義，而非變更既有的定義，可以避免影響現有的應用程式。
- 修改：架構修改不如延伸常見。如果既有物件遭到變更，很可能會對依賴該物件的應用程式造成負面影響，因此 IdM 團隊會仔細的衡量對既有架構物件的影響，只有在徹底瞭解後果後才行事。此外，Microsoft 不認為有哪個 Windows Server System 提供的屬性是未使用的。每個屬性都有存在的意義，因此我們只會對自訂屬性修改未使用的定義。
- 停用：Microsoft IT 鮮少將未使用的定義停用。如果 Microsoft IT 不再需要哪個屬性或物件資料，會刪除屬性值或物件執行個體，反正未使用的架構物件也不會佔用太多資源；其實，Microsoft 特地設計過 AD，使它能包含分散的資料。此外，架構管理員無法將預設的 Windows 架構物件停用，只能將自訂的架構物件停用。
AD 效能AD 中未使用的定義並不會拖累 AD 的效能，架構定義只會使表格變得更大，就像在資料庫內添加一個資料行一樣，而且架構定義並不會使檔案變得更大，頂多也只不過使得一些架構管理工具啟動時稍微慢了一些。
返回页首
變更管理系統的架構由於 Microsoft 進行的架構變更相當多，必須採用健全的步驟管理這些變更作業。Microsoft IT 採用 Microsoft Operations Framework (MOF) 作為核心管理流程的基礎，IdM 團隊也已採用 MOF 定義的變更管理流程來管理架構變更要求、測試和實作。您可以到 MOF 網站，取得詳細的 MOF 文件：http://www.microsoft.com/mof (英文)。
IdM 團隊的架構變更管理系統由正規的流程、內部網站和變更管理文件所組成。這個流程定義了 Microsoft 內部所有架構變更的管理辦法，詳細解說每項活動，從最初的變更要求到成功完成變更如何宣布都鉅細靡遺的規定。IdM 團隊使用內部網站作為管理所有架構變更的起點，藉此強制實施這套正規流程。這個網站界定了認知、因應常見問題 (FAQ)，並可用來存取線上變更要求表單，也就是一份程序文件，作為標準化工作流程的架構，藉此落實正規流程。
架構所有權由於架構管理和修改很可能會造成相當大的衝擊，Microsoft 內每一個架構變更由 IdM 團隊負責，把架構當作是一個能累積所有架構變更的實體來管理，以便詳細的瞭解架構目前包含的所有架構元件，以及額外變更所帶來的衝擊。
詳細瞭解以下項目：
- 設計：IdM 團隊分析每個架構元件的設計，判斷是否符合預定的架構作法。文中的＜最佳作法與 IdM 標準＞一節完整介紹定義的架構作法。
- 實作與使用：不僅與設計和使用權有關，也牽涉到系統管理員採取何種方式完成架構延伸，以及在目錄內填入元件執行個體的方法。
- 所有權： IdM 團隊追蹤自訂架構元件的所有權，確保該聯絡管道在日後變更牽涉到該元件時能夠提供幫助。
- 安全性：架構元件安全性必須經過界定、追蹤與管理，每一個元件必須有相對的所有權、物件權限指派以及更高階的企業安全性目標。
Microsoft IT 規定只能由 IdM 團隊進行架構變更，保障我們對系統的瞭解。IdM 團隊擔任守門員的角色，積極管理所有的架構變更，來維持 AD 架構的健全。
變更原則Microsoft IT 也限制架構管理群組必須來自 IdM 團隊的成員，來落實架構變更的限制。除此之外，IdM 團隊會根據進行核准變更所需的時間，將成員身份暫時指派給架構管理群組，否則預設的架構管理群組一般都是空的。
IdM 團隊有權力設定原則，確保使用架構變更管理系統、遵守適當的標準並界定了各方的認知。架構變更需要有：
- IdM 核准：所有架構變更都需要經過 IdM 團隊的首肯。
- 使用架構變更管理系統：所有的架構變更都需要通過 IdM 團隊的 AD 架構流程與核准服務。
- 先前測試：架構變更要求者有責任測試架構變更的功能，包括實作的方法。IdM 團隊不會考慮任何缺乏適當測試的要求。
- 適當的文件：接觸 IdM 團隊的前提之一就是將架構功能和測試過程以文件記錄，連實作方法也不例外。要求者一定要將這些項目和其他必須的資訊都記載在架構要求表單中，IdM 團隊才會排定初步檢閱。
變更基礎結構用來管理架構變更管理系統的基礎結構並不複雜，只要有一個內部網站、IdM 團隊的參與，加上適當的測試環境即可。
內部網站IdM 團隊會建立一個供內部使用的 Microsoft SharePoint 2003 網站，用來當作 IdM 團隊與要求變更的人員互動的介面，這也是變更管理系統的起點。一開始由要求者透過網路表單提供必要資訊，IdM 團隊會將網路表單以簡單的 SharePoint 調查呈現，而調查中會儲存要求的歷史記錄並允許修改，也會透過 SharePoint 的警示機制告知團隊任何變更。IdM 團隊再取得表單中的資料，建立架構組件文件，隨者文件內容的變動進行維護，並將文件添加至架構變更流程的每一個步驟。該團隊會在 SharePoint 網站文件庫的專案資料夾中對表單和架構組件文件進行維護。
IdM 團隊IdM 團隊收到要求後會進行處理，審視所要求的變更，自行進行測試，並進行必要的溝通，最後實作變更。這些過程需要用到 IdM 的內部網站和 Microsoft Terminal Server 服務，並存取裝載 Schema Master Flexible Single-Master Operation (FSMO) 的 DC。此外，還需要具有 Schema Admin 權限的帳號，以及存取任何必要環境的能力。所有的架構變更由資深的技術專家操刀。
測試環境要求者向 IdM 團隊提出任何架構變更要求前，自己必須先進行測試。IdM 團隊會替每一個架構變更進行兩層測試，測試是漸進式的，一個步驟完成後才會進行下一個步驟。測試階段包括實作測試和功能測試。
IdM 團隊負責實作測試，先將架構變更載入一個虛擬環境，再移至實驗室環境，在這些環境中測試能夠抓出實作的問題和命名衝突。IdM 團隊每次都會在虛擬環境重新安裝 Windows Server 2003 以測試系統衝突。這項初步測試能夠驗證架構變更是否生效，實驗室環境包含 Microsoft 所做的各種架構延伸，以便與自訂或協力廠商延伸變更進行衝突測試。由這個第二層的實作測試決定是否要進行功能測試。
提出架構變更的團隊必須負責進行功能測試，將架構變更載入試驗環境，以便讓應用程式所有者測試應用程式功能與變更之間的關係。試驗環境為有限制的生產樹系環境，裡面有真實的使用者，依賴樹系作為存取網路的主要管道。這樣就能在有限的生產環境中實際測試應用程式，並由應用程式的所有者決定試驗環境的成敗。
延伸管理管理架構變更時，架構管理過程需要三方的參與： 提出要求的人員、IdM 團隊以及 IEng 團隊。各方都有自己的需求與責任，認知也有差異，例如時機、結果、責任、標準等預期。要實現最佳結果，統一由變更管理流程將各種認知加以歸納，儘量避免模糊不清。IdM 團隊做到這點的的方法是讓參與各方從一開始就完全瞭解專案。過去的經驗證明，初步文件越清楚完整，過程就越順暢，成果也更佳。Microsoft 決心要清楚界定認知以帶來最佳的結果，所以規定變更管理系統一定得提供透明的標準和程序、證實合理的預期，時間表方面也要溝通清楚。
透明的標準和程序這三方要能合作無間，一開始就要有透明的標準和程序。有了這些標準，才能避免意外，允許過程順序進行。IdM 團隊會在內部網站中詳細列出架構變更的標準。這個網站除了作為流程的起點，也提供完整的指示、原則和標準。一旦要求者徹底瞭解進行架構變更的標準，下一步就是記錄並提出要求。
證實合理的預期要求者得完成必要的文件，證實目標合理可行，如果有任何部分不符合 IdM 措施和標準，必須詳細解釋原因，表單內還必須就商業和技術做合理解釋。
只要有合理的商業或技術解釋，IdM 團隊通常不會拒絕要求，並會從建議者的角度，以這些資訊判斷目標是否可行或是解決方案是否是最好的。如果不然，IdM 團隊會提出改善建議，排除不必要的架構變更或錯誤的變更要求。
溝通清楚的時間表IdM 團隊預期所有的標準變更從要求到實施至少需要七週，這些都在綱要列在網站上。七週內有三週用來探索和審視，四週用來測試和部署。如果變更複雜，IdM 團隊可能需要更多時間。
標準的七週時間會受到幾個因素影響，但不論影響因素是什麼，這些變更還是得遵守高標準。其中包括：
- 緊急準則：IdM 團隊會自動替要求指定優先順序狀態，對於符合既定緊急準則的要求給予加快時間表。IdM 團隊在架構變更網站中列出這些準則。
- 迫切程度：即便架構變更可能未達緊急準則，只要情況迫切就可以採取加速時間表。舉例來說，架構要求者可能需要將某個 AD 使用者屬性解除功能，以便強迫使用新的全域商務應用程式的其他屬性。這種情況下要求者就可以請求加速時間表。IdM 團隊會視要求的複雜程度、可用資源和其他優先的要求來做決定。
- 其他優先的架構變更：一般來說是由 IT 環境中最資深的團隊成員處理架構變更，但這些人通常也很忙。這時除非要求符合緊急準則，否則要求者必須將新的架構變更要求排在佇列的最後面。在異常忙碌的情況下，要允許更多時間來完成。
附註： 不管要求多複雜、時間多麼急迫，IdM 團隊都是以最高標準處理每一個架構變更。
變更流程階段架構變更流程有五個主要階段：
- 探索
- 審視
- 實作測試
- 測試應用程式的功能
- 部署至生產環境
本文下面幾個小節會對各個階段作詳細說明。
返回页首
變更流程逐步解說下圖說明架構變更管理流程需進行的各項作業。
[圖 3] 架構變更流程圖
一般 IT 各個領域中的許多相關變更是由變更管理系統負責溝通和追蹤，因此有必要將架構變更流程與根據 MOF 定義的 Microsoft IT 變更管理系統整合，確保架構變更不會和其他領域的 IT 產生衝突。我們的作法是在架構變更流程中納入填寫變更控制通知這個步驟 (如 [圖 3] 所示)，使流程保持一致。IdM 團隊核准架構變更可實施後，會將架構變更告知變更顧問委員會 (CAB)，以便 CAB 能夠在架構變更流程中因應任何可能發生的 IT 衝突。而且 CAB 也是溝通的橋樑，負責在各個團體間提供諮詢。
評估要求者的專業能力架構變更要求者通常代表了正在開發新產品的產品小組、業務單位或 IT 基礎結構群組，希望透過延伸架構來支援新的應用程式。截至目前為止，Microsoft 內的架構變更要求主要來自 Exchange 和 Windows 產品小組。IdM 團隊會根據產品小組的架構變更提供意見，並建議導入的各種方法。
舉例來說，Microsoft Exchange Server 2003 安裝時提供的 forestprep.exe 會自動更新並延伸架構、建立新物件和設定新物件的權限。IdM 團隊希望在安裝檔添加物件並將資料填入 AD 之前，能分別延伸架構。所以 IdM 團隊要求產品小組提供 LDIF 檔案選擇，這項建議就納入了最終產品。
因應協力廠商產品的架構變更比較難實施，因為任何應用程式都有隱藏的架構變更需求。協力廠商的應用程式是透過 .EXE 檔案來延伸架構，因此要隔離出變更更加困難，而且 .EXE 檔案可能只會在安裝過程中載入 LDIF 檔案，所以很難取得 LDIF 檔案進行測試。
舉例來說，Microsoft 需要協力廠商的架構延伸來支援 Avaya Unified Messaging System，這樣 Microsoft 才能整合語音郵件和 Exchange，達到統一通訊的目的。結果安裝檔案包含隱藏的架構變更，使得安裝因為缺乏足夠的權限而失敗。
提交架構變更要求所有架構變更都從 IdM 網站開始，這個網站可供所有 Microsoft 內部人員存取，指示中包含連結至線上要求表單和額外資訊的連結。
指示指示給予至少三週的基本時間進行探索和審視，一旦要求經 IdM 團隊核准，額外再加四週的基本時間進行測試和實作。如果架構變更符合緊急準則，則可於七週的標準額外開例。
[圖 4] 架構要求表單觀看完整大小的影像
要求表單能讓 IdM 團隊根據實作架構變更所需的知識，有效地界定使用者預期。舉例來說，要求者必須提交適當且獨一無二的物件識別碼 (OID)、先前測試的結果以及功能測試計畫。要求者還必須以 LDIF 文字檔案的格式提供架構變更要求，LDIF 格式清楚的顯示每項變更，包含系統授權來源。
緊急要求萬一需要緊急進行架構變更時，業務單位主任必須提交要求並證明的確符合特定準則，例如阻撓工作、阻撓業務或安全性問題。IdM 團隊再向 IdM 主管提供建言，所有的架構變更在部署前一定要經過 IdM 主管的核准，這項過程需要快速完成。
以便探索架構變更表單提交後，IdM 團隊成員從頭到尾參與直到變更完成。第一項工作是審核商業或技術合理解釋以及要求細節，審核可能會需要一些時間，在此期間，IdM 團隊可以將文件送回好幾次，以取得更多資訊或修正錯誤。一旦要求符合 IdM 標準，就會被接受並進到下一步。
商業和技術合理解釋為了避免非必要的架構變更或要求變更有錯，IdM 團隊規定要求者必須就商業和技術上提出合理解釋。
商業合理解釋指的是說明變更對業務單位的價值，讓 IdM 團隊瞭解要求者為何作此要求，以及實施變更期限。舉例來說，產品小組可能需要部署一個使用 AD 功能的應用程式到 Microsoft 生產環境，以便在交付製造前能夠得到意見。
技術合理解釋則是明確定義出提議架構變更所希望達成的目標，IdM 團隊會把要求的變更與技術目標相比對，判斷目標是否可行，或是解決方案是否是最好的。
產品小組雖然負責添加功能和確保產品的安全性，還是得依賴 Microsoft IT 測試應用程式對作業環境的影響，有時候應用程式設計上的重大缺失就是由 IdM 團隊揪出來的。舉例來說，IdM 團隊可能察覺到產品小組使用 AD 擷取經常變更的資料，因為變更太頻繁，結果資料還沒完全複寫到樹系就變更了。因為這樣，樹系內的一些 DC 裡可能有不一致的資料，這種情況下就不值得進行架構變更。
審視架構變更要求一旦 IdM 團隊瞭解並接納商業和技術上的合理解釋，就會徹底的審視 LDIF 檔案，找出錯誤、分析設計，然後給予作者意見。這種意見簽核過程有助於作者寫出更好的解決方案，重新修飾要求以求通過。
審視架構檔案其間，檢視者會：
IdM 團隊使用指令碼來蒐集大部分的一般資訊。檢視者如果覺得提交的資訊充分，就會接受變更要求、安排時間表然後進行實作測試。
測試實作架構變更要求一經接受，IdM 團隊就會安排變更進行實作測試。端視設計而定，Microsoft 內各個樹系的樹系架構可能不一樣。舉例來說，各個樹系會持有不同版本的 Microsoft 軟體以便提供舊版支援和開發。這時 IdM 團隊不會分別測試每一個樹系，而是使用一個累積架構並包含所有樹系架構延伸的實驗室環境。IdM 團隊只要在這個環境成功地實作測試，就可以在部署前抓出樹系內的任何衝突。
IdM 團隊將 LDIF 檔案載入實驗室環境，藉此驗證沒有 OID 或命名衝突，而且 LDIF 檔案能夠完整的載入。要驗證這一點，只要在實作其間啟用載入選項，並檢查記錄檔是否有錯誤就可以了。IdM 團隊會調查所有的錯誤，如果檔案需要修改就會將 LDIF 檔案退還給要求者。最後的 LDIF 檔案一定得正確的安裝。
核准部署IdM 團隊審視變更要求並測試實作之後，會核准或否決部署。一經核准，IdM 團隊會通知 CAB 並將變更要求移至功能測試。如果是否決，IdM 團隊會將變更要求退回給要求者，並詳細說明拒絕的原因。
通知變更顧問委員會變更顧問委員會 (CAB) 是 Microsoft IT 內為因應 MOF 而成立的一個單位。CAB 獨立於 IdM 團隊之外，也是一個多功能的團隊，專為審核業務需要、優先順序、成本與益處衡量，以及對其他系統或流程的潛在衝擊而提出的所有 Microsoft IT 變更要求。一般來說，CAB 會建議實作、進一步分析、延期處置或取消。
IdM 團隊向 CAB 發出變更要求通知後，CAB 即根據自己的流程與 IdM 團隊一併行事。CAB 是與 Microsoft IT 一般變更管理門券系統的接合點。
IT 環境極端複雜，關乎交互相依性，往往牽一髮動全身。CAB 決定變更對於交互相依系統和部門的影響，並負責協調部門間的變更。協調變更的方式是使用 Microsoft IT 變更系統搭配架構變更管理系統。CAB 審視變更要求，以判斷：
- 授權：進行變更的人員所具備的權限。
- 交互相依性：變更可能會影響到許多不同的群組及其服務等級協定 (SLA)。
- 衝突：CAB 全局掌握 Microsoft IT，所以能判斷是否有必要對變更進行修改以及變更的時機，避免發生衝突。
審視變更要求後，CAB 會給予核准，或將它退回並提供變更建議。一經核准，CAB 會將變更要求添加至一般變更管理系統，取得門券號碼，並以電子郵件通知所有交互相依的小組。通知可讓這些小組有機會作適當的安排，避免衝突並協調變更。
測試應用程式的功能如果 LDIF 檔案能夠順利載入實驗室環境，下一步就是開始進行第一項試驗。試驗能讓要求者有機會根據功能性測試計畫進行功能測試。IdM 團隊通常會使用 Windows 開發樹系來進行第一項試驗。這個樹系是一個有限制的生產樹系，使用者會透過這個環境來測試使用的情況，也就是 dogfooding 。要求者通常有一個禮拜的時間來測試功能，判斷架構變更是否如預期般運作。如果要求者想在額外的樹系進行測試，IdM 團隊會準備第二項試驗。每個試驗階段最後，要求者會確認功能性測試是否成功完成。功能測試期間要求者可能會因應一些小問題而稍作修正，如果要求者發現嚴重問題，流程必須暫止，讓要求者重新修改架構變更。
部署至生產環境一旦實作和功能測試成功完成，就有一個經過完整審核和測試的 LDIF 檔案可供部署。IdM 團隊接著會安排架構變更部署的時間表。部署變更的日期與時間要看要求的時間表、變更規模、複寫影響，以及 IdM 與 IEng 團隊目前的工作量而定。IEng 團隊負責監督複寫過程。經過適當測試後，IdM 團隊會在同一天陸續載入小型變更，如果可能的話再載入重大的架構變更。週五晚間 (太平洋時間) 保留給 IdM 團隊進行架構變更，確保複寫能夠完成，而且在亞洲週一早晨到來前使 AD 負載回復正常。
IdM 團隊透過指令碼完成流程，以便將同樣的變更套用在每個樹系中，無須手動操作。所有架構延伸變更會逐步套用在每個樹系中。IdM 團隊會將記錄檔末端記載的成功變更數目與其他樹系做比較，判斷變更流程是否成功。如果數目不符，IdM 團隊會審視記錄檔的內容，如果發現重大錯誤影響到 AD 的穩定性，IdM 團隊可能會與 IEng 團隊合作著手進行復原計畫。
成功完成部署後，IdM 團隊會將指令碼、LDIF 檔案、每個樹系的記錄檔，以及錯誤檔案 (如果有的話) 都壓縮起來，然後將該記錄添加至所有架構變更的變更歷史檔。
IdM 團隊將變更部署至目標樹系後，由 IEng 團隊監督複寫過程，確認架構順利的複寫到每一個樹系。如果發生嚴重問題，由 IEng 團隊負責進行復原。架構變更徹底的複寫到每一個樹系，而且 IEng 團隊也對成果感到滿意後，就會傳送電子郵件給每一位參與的人員，通知大家架構變更複寫大功告成。
返回页首
降低風險要減少架構變更的風險，企業必須先對風險有所瞭解，判斷起因，然後採取行動減少問題。企業還必須準備偶發事件應變計畫，以因應可能發生的問題。
衡量風險Microsoft IT 以衝擊和發生的可能性為出發點，衡量事故的風險。對於可能會造成嚴重衝擊的事故，例如系統失靈，Microsoft IT 會先以安全措施和冗餘系統加以因應，預備能夠抵禦高風險、高衝擊事故的計畫，對於破壞性最大的意外以不怕一萬只怕萬一心態作準備。雖然有必要為高衝擊事故作準備，但是以抵禦中級風險的方法作事情會比較有效率。Microsoft 建議您衡量下面討論的各種風險。
複寫衝擊： 低衝擊，中度風險AD 複寫使用優先權系統在任何資料變更前先複寫架構變更，這樣會使得數個 DC 間集中資料花更多時間，如果進行大幅的架構變更，可能會阻礙依賴 AD 的應用程式所需的資料變更，並波及需要使用該資料的人員。舉例來說，架構變更期間，透過樹系複寫群組成員可能需要比一般的五小時複寫延遲更長的時間，因為群組成員複寫會等到架構延伸完成後才進行。
如果實作的是使用 AD 功能的大型應用程式 (如 Exchange 2003)，會牽引出許多架構變更，這時依樹系的站點拓樸而定，每一個躍點可能需要不只一輪的複寫循環。IdM 團隊通常會在周五晚間實作這些類型的變更，儘量減少對生產力的衝擊。其他可能會造成複寫負擔的的因素包括索引屬性、局部屬性集 (PAS) 重建或繼承的安全性描述項 (SDProp)。有時候這些變更是實現某些系統功能不可或缺的條件，系統管理員無法避免，只要實作規劃得當就能減少任何負面影響。
應用程式失敗： 中度衝擊，中度風險AD 在樹系內提供一些應用程式功能，包括安全性和存取通用目錄。此外，延伸 AD 架構的應用程式所具備的額外功能能否使用，要看應用程式能否存取 AD 以及架構變更是否成功。應用程式會使用架構延伸提供的定義來建立運作所需的物件，如果無法存取 AD，應用程式可能就失去特殊功能，甚至可能整個失效。
上述問題可能是因為架構變更設計不良，使相依應用程式所需的既有元件失效。此外，架構延伸如果不當實作，可能只會帶來局部變更，而導致應用程式發生錯誤或新應用程式無法正常運作。
系統失敗： 高衝擊，低風險AD 替使用 AD 功能的應用程式管理網路資源存取以及功能，所以 AD 一旦無法使用，樹系的使用者就無法存取這些資源和一些應用程式功能。但是要網域內所有的 DC 失敗，AD 才會無法使用，光是一個 DC 失敗並不會影響整個樹系的 AD。因為 DC 甚少失敗，這種情況屬於低風險。
DC 失敗可能是由硬體或軟體失靈造成，DC 失靈可以透過解決硬體失敗或重新安裝軟體來解決。如果系統管理員部署好幾個 DC 作為冗餘系統，DC 失靈不一定代表 AD 也會失敗。但如果架構主機在架構變更時間失敗，系統管理員將伺服器恢復連線時最好要小心，確保狀態一致。
因為資料失敗造成複寫 AD 毀損並不常發生。萬一複寫 AD 真的毀損，只要實施災害復原方案即可。
管理風險瞭解風險後，就不難看出重大架構變更問題的兩大原因是設計不良與實作不當。設計瑕疵可能會使得複寫延遲，或增加 DC 系統的負載，造成應用程式不相容甚或整個停頓。實作不當包括部分實作阻礙功能或是時機不良，使得複寫延遲超出一般的時間限制，複寫延遲可能會影響對延遲敏感的應用程式。因此要降低或避免風險，不能不管理架構變更的設計和實作。為了做到這一點，由 IdM 團隊全權在 Microsoft IT 管理的樹系中進行所有的架構變更。
管理設計上的風險IdM 架構變更管理系統規定架構變更要求者必須遵循特定的步驟，取得變更許可。IdM 團隊會將規劃有瑕疵的架構變更延後處理，直到技術細節經過修飾，值得重新審核。變更管理系統利用下例途徑管理設計的風險：
- 文件管理：文件記錄不當可能會造成實作上的問題，為了避免這種情況，要求者必須在審核開始前提交標準化的文件。
- 設計分析：IdM 團隊根據 IdM 的標準分析架構設計，並將規劃不良的變更要求退回給原作者，並附帶註解及建議。
- 標準制度：IdM 團隊強制實施一套高標準和最佳作法，定義可接受的架構變更。這些標準能夠減少與現有架構物件產生衝突的可能性，強調使用哪些屬性可能會造成複寫負載暴增。這些標準都列在本文的＜最佳作法與 IdM 標準＞一節。
- 協力廠商的責任：不是所有的供應商都會固定提供 LDIF 檔案或架構安全性描述元供設計或安全性評估。基於相容性考量，系統管理員一定要徹底的審視協力廠商的架構安全性描述元，取得並驗證記載的架構變更。
管理實作上的風險一旦架構變更經過採納和設計，就開始實作與功能性測試，這些程序包括：
- 處理指令碼：IdM 團隊使用標準的指令碼將 LDIF 檔案實作到所有的樹系內，確保整個公司內的樹系都使用正確和一致的參數，減少實作過程中會造成架構變更不完整的常見人為疏失。
- 實作測試：在實驗室環境測試 LDIF 檔案的實作情況，就能在將檔案部署到生產環境前，及早發現錯誤與衝突並進行修正。
- 功能性測試：在有限制的環境中試驗架構變更，由要求者判斷應用程式的功能表現。IdM 團隊會根據試驗的結果決定是否要實作架構變更，避免因為實施運作不良的架構設計帶來的問題。
- 實作標準：IdM 團隊已經擬定出實作標準和最佳作法，能更將風險降至最低。其中包括：
- 直接在架構主機進行實作：IdM 團隊使用終端機伺服器在架構主機本機上實作架構變更，這樣實作就不會受到工作站問題或網路連線的影響，也避免因為這些問題使得實作架構變更不完整。
- 複寫衝擊的考量：IdM 團隊一般會在週五晚間實作架構變更，讓複寫能夠在週末進行，儘量減少對其他複寫網路流量的衝擊。
- 驗證複寫成敗：IEng 團隊會驗證架構變更是否成功的複寫到整個樹系中，以避免因為架構變更沒有完全複寫，在生產環境內造成意料之外的應用程式行為。
為災難復原進行規劃有時候架構變更引起的問題很難修復，這時比較理想的復原方法就是修改架構。但是有時候修改架構並不切合實際，這時系統管理員就必須還原網域或樹系。
IEng 團隊負責進行災難復原，採用好幾個步驟回復架構變更。其中包括：
- 備份和還原：要採行這種方法，企業必須定期將 DC 系統狀態備份起來，驗證備份成功，並定期執行回復。IEng 團隊執行定期回復流程的方法是每個月作一次非授權回復來測試流程，以及每三到四個月執行授權回復來協助失去資料的使用者。在架構變更的情況下，需要進行樹系回復，也就是大幅度的進行備份和還原。IEng 團隊每年會在實驗室進行一回樹系回復，測試程序是否得當。這兩項選擇中，IEng 團隊比較傾向採用備份和還原，因為這比較容易進行。
- 將架構主機離線：IdM 團隊在架構主機上進行架構變更時將主機離線，以便能在架構主機恢復連線前先驗證實作的成敗，如果需要將架構變更復原，就可以將架構主機當作是單一個 DC 來復原。這種作法雖然不能驗證應用程式，但是可以確保架構安裝無誤。
返回页首
最佳作法與 IdM 標準IdM 團隊從過去幾年部署架構變更擷取了許多經驗，我們進行了許多次的架構變更，並從中不斷的改善過程，最後歸結出一套最佳作法和標準，可加強流程並確保得到最佳結果。
最佳作法Microsoft IT 建議的最佳作法是：
- 將變更管理流程標準化：設計得當的變更管理流程可讓企業當作正規化的工作流程，實現最佳結果。有了流程，參與各方的責任歸屬和認知才會清清楚楚。整個流程必須包含完整的工作流程，不管是以可接受的格式提出最初的變更要求，還是決定由誰向參與各方報告變更完成，都要清楚界定。
- 應用程式安裝和延伸架構要分開：安裝應用程式如果需要架構變更，要將應用程式與架構變更分開進行。使用 LDIF 檔案延伸架構是比較理想的作法，因為這樣更能掌握架構變更的細節。IdM 團隊規定內部產品小組和外部的供應商都要提供 LDIF 選擇。IdM 團隊只會在另外延伸架構變更成功後，允許安裝建立物件、設定權限和填入資料。
- 實作前徹底測試：將架構變更實作到生產環境前要徹底測試所有的架構變更，包括實作測試和功能測試。並於所有內部開發的應用程式進行功能性測試，至於可現成購買的產品可能不需要功能性測試。
- 瞭解每一個架構變更對 AD 的衝擊：架構變更的影響層面很廣，可能會影響物件的安全性、目錄中發行的資料類型、目錄資料庫索引的方式、通用目錄中資料的可用性，以及 AD 資料庫的大小。因此將架構延伸到生產環境前，一定要瞭解變更會對 AD 的安全性、資料使用、基礎結構需求、複寫和相依的應用程式造成何種影響。
- 以指令碼進行處理：使用標準化的指令碼執行所有的架構變更，使流程能夠達到一致。執行 LDIF 檔案變更的指令碼會使用必須的 ldifde.exe 命令列來切換和處理每一個有關變數，如此能避免遺漏，並確保所有的架構變更都遵照標準的程序，並能傳回一致的結果。標準化的指令碼包括：
- 自動樹系命名：LDIF 檔案替每個新增或修改的物件指定辨別名稱 (DN)。由於 DN 必須包含樹系根網域的元件，LDIF 檔案必須根據目標樹系的特定 DC 元件來修改。LDIF 檔案的標準就是將 DC=X 作為 DC 元件的預留位置。在 LDIF 內使用 DC=X，指令碼就可以判斷目前的網域名稱內容，並以有意義的值取代它。這樣能提升 LDIF 檔案的可攜性，並允許同一個指令碼在每個樹系中執行，不需要手動修改 LDIF 檔案，同時免除版本控制的問題。
- 適當的使用命令列切換：指令碼使用一套標準的參數來操作 LDIFDE.exe 命令列工具，使用命令參數 J 來產生一個文字記錄檔。指令碼也會使用命令參數 C，以搜尋和取代的方式自動變更樹系名稱。如果架構變更過程中出現錯誤，指令碼會使用指令參數 K 繼續執行並避免遺失元件。這一點相當重要，因為系統管理員為了方便起見，通常會在原來架構變更最後面添加額外的架構變更，而執行指令碼時，重複的架構變更會以錯誤的方式呈現，但不會造成指令碼失敗。執行驗證測試期間，一定要謹慎地檢視記錄檔，因為命令參數 K 會在發生條件約束違規錯誤後仍繼續運作。請務必確認每個記錄的錯誤都有合理的解釋。
- 樹系一致性：在所有的樹系中使用同一套指令碼，不僅免去手動修改的麻煩，也能使樹系間的架構更加一致。手動變更 LDIF 檔案可能會引起錯誤，使得架構變更不完整。
- 處理一致性：如果過程未經過指令撰寫，操作者必須每次輸入正確的參數，很可能造成人為疏失。舉例來說，如果沒有使用參數 J，一旦處理執行完畢，操作者就沒有辦法建立記錄檔。此外，忘記使用參數 K 可能會造成架構變更不完全，而需要對記錄檔進行深究。
- 對架構主機的本機進行變更：進行架構變更時，可利用終端機伺服器的工作階段來登入架構主機。因為終端機伺服器是在架構主機的本機上進行變更，能夠減少因為造成架構變更不全而拖累網路和客戶的情況。
- 保留架構變更的歷史記錄：為每一項架構變更的所有記錄都保存副本，藉此建立變更歷史記錄，而必要時有結果摘要可供研究。保留檔案還有另一個好處，系統管理員可以在 LDIF 檔案末端添加變更，簡化日後的變更工作。每回有架構變更，Microsoft IT 就會將指令碼、LDIF、記錄檔和每個樹系的錯誤檔案壓縮保存起來。
- 一併測試循序進行的架構變更：強烈建議系統管理員部署循序進行的架構變更之前，一定要對每一個順序分別進行測試。個別進行架構變更以便替每一個環節保留獨特的指令碼。
- 從不需要的架構物件移除舊資料：如果在 AD 裡有不需要的資料，最好移除，並重新建置簡化的指令碼來歸還資源。如此一來，不僅能釋放空間，還能降低伺服器在索引和複寫時的負擔，而且清除老舊資料還能避免不小心而保留甚至暴露可能的機密或敏感資訊。
Microsoft IT IdM 標準IdM 團隊規定所有的架構變更都要遵循以下標準，這些標準能夠確保架構變更流程一致，並呈現出最佳的結果。各項標準如下：
- 架構設計
- 所有的架構元件必須有具備有效的 ODI。
- 符合 Microsoft 建議的命名慣例。
- 系統管理員只需要對獨特且廣泛用於填入的元件進行索引。
- 只有在必要時才在局部屬性集內添加內容。
- 所有對自訂屬性集的變更必須經過所有者的核准。
- AD 內的單一物件不得大於 1 MB。
- 架構所有權
- 架構元件的所有者必須是全職員工。
- 至於內部開發的應用程式，必須在延伸實作前先指定每一個架構元件的所有者。
- 所有者有責任通知 IdM 團隊任何未使用的架構元素，以便解除功能。
- 架構的實作與使用
- 架構內不得有目的雷同的元件。
- 使用 LDIF 指令碼進行所有的架構修改。協力廠商產品若使用可執行檔或安裝包裝函式，必須準備供檢視或手動安裝的 LDIF 檔案 (或兩者皆準備)。
- 將所有的 LDIF 歸檔供日後參考。
- 唯有 IdM 團隊才能將架構變更實作到任何由 Microsoft IT 管理的樹系。
- 記錄提議的架構延伸已經進行的測試層級。
- 提供實作程序，實作任何使用 LDIF 指令碼、程式可執行檔、安裝包裝函式等的架構修改。
- 架構安全性
- IdM 團隊在修改架構的預設安全性描述元時非常小心，因為這對網路安全性有所影響。
- 在多樹系中預演
- 實作時必須保持一致性。IdM 會在不同樹系間預演架構變更，以驗證實作的方法、指出所有相容性方面的衝突，並確保樹系間保持一致性。
返回页首
結論Microsoft IT 建議準備制度化的 AD 架構變更流程，包含考量、評估、測試、試用和實作五大里程碑。Microsoft IT 並建議將架構變更流程與既有的變更管理系統整合，以減少衝突和風險。
Microsoft IT 指派一個特定的小組來處理所有的架構變更並落實標準，標準必須經過明確的定義並且可推行。有了架構變更流程，方可落實標準和程序，適當建立並管理預期，並明確地溝通時間表。
架構變更需要積極的管理，也可能需要相關各方的參與。Microsoft 架構變更流程可指派職責，並能夠制衡各方所扮演的角色。因為有標準的逐步流程，能夠減少誤會，實現所有的需求。
Microsoft IT 因為有架構變更流程，所以能以制度化的工作流程將架構變更正規化，落實組織的標準並明確界定預期。現在，工作流程不僅能在流程早期揪出架構變更的瑕疵，還能讓參與各方明白自己的職責，進而促進合作，使最後結果能夠即時而完美的呈現。
|
|
