使用 Configuration Manager 規劃簡化階層的示範案例

 

適用於: System Center 2012 Configuration Manager, System Center 2012 Configuration Manager SP1, System Center 2012 Configuration Manager SP2, System Center 2012 R2 Configuration Manager, System Center 2012 R2 Configuration Manager SP1

下列案例提供如何實作 System Center 2012 Configuration Manager 以解決一般商務需求,以及如何簡化整體階層設計的範例。

案例 1:遠端辦公室最佳化

遠端辦公室最佳化案例示範 System Center 2012 Configuration Manager 的實作,該實作可降低在網路上管理資訊流程的系統管理額外負荷。

目前的情況

客戶有一個簡單的主要站台 Configuration Manager 2007 階層,以及兩個次要站台,其中包括倉庫和偏遠地區辦公地點。 客戶在四個位置共有 5,015 個用戶端,如下表所示。

位置

站台類型

部署詳細資料

連線到總部

總部

主要

  • 3,000 個用戶端

  • 兩個標準發佈點,一個管理點,以及一個軟體更新點

不適用

倉庫

次要

  • 500 個用戶端

  • 一個標準發佈點

低速網路

地區辦公室

次要

  • 1,500 個用戶端

  • 一個標準發佈點,一個 Proxy 管理點,以及一個軟體更新點

低速網路

營業部

  • 15 個用戶端

  • 使用 Windows BranchCache

連線良好

商務需求

System Center 2012 Configuration Manager 階層必須支援下列商務需求:

商務需求

 Configuration Manager 資訊

透過網路傳送的資料不可使用過多的頻寬。

低速網路連線必須支援頻寬控制。

將所使用的伺服器數目減到最少。

盡可能安裝最少數目的站台系統伺服器。

製作可提供與裝置相關的目前資訊報告。

用戶端必須定期提交硬體清查資料、狀態訊息及探索資訊。

每天執行應用程式部署、軟體更新及作業系統部署。

內容必須可供使用者使用,包括作業系統映像的大型套件。

規劃決策

System Center 2012 Configuration Manager 階層的設計包含下列規劃考量:

挑戰

選項和考量

將部署內容從主要站台傳送到遠端位置會對網路產生相當大的影響,必須加以管理。

下列是可管理傳送內容至遠端位置的方法:

  • 針對頻寬控制啟用發佈點

  • 預先設置發佈點

  • Windows BranchCache

  • 在進行站台對站台傳送期間使用本機站台管理網路頻寬

來自大量用戶端的用戶端資訊流量可能會使網路速度變慢。

必須評估各個遠端位置的網路容量,平衡用戶端設定、位置上的用戶端數目,以及可用的網路頻寬。 這些選項包括:

  • 在進行站台對站台傳送期間使用本機主要或次要站台管理網路頻寬。

  • 若該位置上沒有站台,表示允許用戶端透過網路將未管理的資料傳送至指派的主要站台。

採取的步驟

評估需求和選項、用戶端位置和可用的網路頻寬後,可以決定下列各項:

決策

詳細資料

在總部位置部署獨立的主要站台。

以 System Center 2012 Configuration Manager 主要站台取代現有的主要站台,因為在此環境中使用管理中心網站無法獲得系統管理或內容管理的好處。

  • 主要站台最多可以支援 100,000 個用戶端。

  • 沒有規劃需要擴充其他主要站台來管理低速網路連線上的大量用戶端。

在倉庫位置部署啟用頻寬控制的發佈點。

從倉庫位置將用戶端資訊向上傳送的影響,不會對可用的網路頻寬造成嚴重的負荷。 若要取代次要站台,符合位置需求的方法是使用從主要站台部署頻寬控制的發佈點,管理向下傳送的部署內容。 此項決定不會減少使用的伺服器數目,但可排除管理其他站台的需求。

  • 目前的用戶端活動還不需要管理向上傳送的用戶端資料。

  • 只有向下傳送的內容需要管理,以避免影響低速網路連線。

  • 未來若有需要,可使用能管理雙向網路流量的次要站台取代發佈點。

在偏遠地區辦公地點部署次要站台。

評估本機用戶端所造成的影響後,判斷將會需要使用與先前相同設定的次要站台。

  • 1,500 個用戶端產生的用戶端資訊,會超過主要站台的可用網路連線。

  • 由於無法獲得主要站台所提供的系統管理效益,因此不需要使用主要站台,而階層的合併用戶端總數可以透過總部位置的主要站台來處理。

Windows BranchCache 由營業部地點進行維護。

由於此位置只能服務 15 個用戶端,且與總部位置透過快速網路進行連線,因此目前使用 Windows BranchCache 作為內容部署解決方案仍是最好的選擇。

商業優勢

以啟用頻寬控制的單一發佈點取代次要站台及其發佈點,使客戶能滿足在低速網路管理內容的商務需求。 此外,此變更會減少系統管理工作量,以及站台接收用戶端資訊的時間。

案例 2:減少基礎結構與用戶端設定管理

減少基礎結構和用戶端設定案例示範了 System Center 2012 Configuration Manager 的實作,其減少使用的基礎結構,同時亦使用自訂的用戶端設定繼續管理用戶端。

目前的情況

在此範例中,一家公司使用由一個中央站台和三個主要子站台所組成的單一 Configuration Manager 2007 階層管理分散在兩個實體位置的 25,000 個用戶端。 中央站台和一個主要站台位於芝加哥,另外兩個主要站台位於倫敦。 位於各個地理位置的主要站台採用相同的實體網路,且使用連線良好的網路連線。 不過,芝加哥和倫敦之間有頻寬限制。

目前的部署詳細資料:

位置

站台類型

部署詳細資料

芝加哥總部

主要 – 中央站台

19,200 個用戶端,已針對用戶端代理程式設定的公司標準設定進行設定。

芝加哥總部

主要 – 中央的子站台

電腦上的 300 個用戶端由人力資源部門人員所使用。 此站台已針對用戶端遠端控制用戶端代理程式設定進行設定。

倫敦辦公室

主要 – 中央的子站台

5,000 個桌上型用戶端,已針對用戶端代理程式設定的公司標準設定進行設定。

倫敦辦公室

主要 – 中央的子站台

500 個伺服器用戶端,已針對自訂硬體清查用戶端代理程式設定進行設定。

商務需求

Configuration Manager 階層必須符合下列商務需求:

商務需求

Configuration Manager 資訊

在芝加哥維護集中式管理階層。

從芝加哥進行集中式管理,需要透過網路傳送倫敦 5,500 個用戶端的內容和用戶端資訊。

除非特定商務需求另有要求,否則請指派標準用戶端設定給所有用戶端。

所有用戶端必須可以使用用戶端設定的標準設定。

人力資源部門員工的電腦,不得啟用遠端控制用戶端代理程式。

這些自訂用戶端設定必須指派給人力資源部門員工所使用的電腦。

位於倫敦的伺服器,每個月最多只能執行一次硬體清查。

這些自訂用戶端設定必須指派給倫敦伺服器的用戶端。

在芝加哥和倫敦之間傳送資料時,請控制網路頻寬。

低速網路連線需要進行頻寬控制。

將伺服器數目減到最少。

避免安裝站台系統伺服器,盡可能降低系統管理工作及基礎結構成本。

規劃決策

System Center 2012 Configuration Manager 階層設計包含下列規劃考量:

挑戰

選項和考量

在芝加哥集行集中式管理。

這項需求的選項包括下列各項:

  • 在芝加哥部署獨立主要站台,以管理兩個網路位置的用戶端:

    • 必須仔細評估來自倫敦透過低速網路傳送的用戶端資訊數量。

  • 在各個位置部署主要站台,並在芝加哥部署管理中心網站:

    • 管理中心網站無法指派用戶端這些站台。

    • 如果階層中有兩個或多個主要站台,則需要使用管理中心網站。

從芝加哥傳送內容到倫敦,需要消耗大量的網路頻寬,因此必須控制此資料傳輸。

向下一個階層傳送的內容,可以透過下列方法進行管理:

  • 針對頻寬控制啟用的發佈點。

  • Windows BranchCache。

  • 倫敦站台已設定為管理站台對站台傳送的網路頻寬。

從倫敦傳送用戶端資訊時,需要管理網路頻寬。

評估倫敦位置的可用網路頻寬,以及如何降低 5,500 個用戶端所產生的資料量。 這些選項包括:

  • 允許用戶端透過網路傳送未經管理的資料至芝加哥指派的主要站台。

  • 在倫敦部署次要站台或主要站台,以便在對芝加哥進行站台對站台傳輸期間管理網路頻寬。

必須為所有位置提供一套標準的用戶端設定。

針對階層提供一組預設的用戶端代理程式設定。

兩個內含人力資源部門員工的群組和倫敦的伺服器,需要與標準設定不同的用戶端設定。

用於指派自訂用戶端設定的集合。

採取的步驟

評估商務需求、網路結構和用戶端設定的需求後,在芝加哥部署管理中心網站,並在芝加哥部署一個子主要站台,以及在倫敦部署一個子主要網站。 下表說明這些設計選擇。

決策

詳細資料

管理中心網站部署於芝加哥。

  • 此符合藉由提供報告和整個階層設定的中央位置來提供集中管理的需求。

  • 由於管理中心網站會存取階層中所有用戶端和站台資料,同時它是兩個主要站台的直接父系,因此是裝載所有位置內容的理想位置。

芝加哥需要一個主要站台。

  • 芝加哥位置需要一個主要站台來管理用戶端,因為無法將用戶端指派給管理中心網站。

  • 需要使用本機主要站台在本機管理 14,800 個用戶端。

  • System Center 2012 Configuration Manager 中的站台未用於設定用戶端設定,如此便可將某個位置的所有用戶端指派給相同的站台。

在倫敦部署一個主要站台。

  • 站台對站台位址設定,可以在從芝加哥的管理中心網站傳送內容時控制網路頻寬。

  • System Center 2012 Configuration Manager 中的站台未用於設定用戶端設定,如此便可將某個位置的所有用戶端指派給相同的站台。

  • 部署本機主要站台以管理 5,500 個本機用戶端,如此用戶端就不會透過網路對芝加哥傳送資訊和用戶端原則要求。 主要站台可確保透過今日實作的階層設計來管理倫敦未來的成長。

    System_CAPS_note注意事項

    決定部署主要站台或次要站台時,可考量下列各項:

    • 評估可供站台伺服器使用的硬體

    • 某個位置目前的用戶端數目

    • 其他用戶端對未來的期望

    • 政治因素

    • 系統管理連絡人的區域點

將用戶端設定的標準設定套用到階層的每一個用戶端。

  • 設定預設用戶端代理程式設定,並將其套用到階層中的每一個用戶端,如此可使每一個用戶端的設定一致。

建立集合以納入人力資源部門員工的使用者帳戶。 此集合會設定為定時更新,如此在建立新帳戶後,便可立即將其加入到集合中。

  • 此集合已使用停用遠端控制的自訂用戶端設定進行設定。 這些設定會修改整個階層的預設值,並提供具有人力資源部門員工所需之自訂用戶端設定的集合成員。

  • 由於此集合會動態更新,因此人力資源中的新員工會自動收到自訂的用戶端設定。

  • 所有站台共用集合,因此會將這些自訂項目套用至階層中任何位置的人力資源員工,而不考慮其電腦的指派站台。

設定一個集合以包含位於倫敦的伺服器。

  • 此集合使用自訂用戶端設定,因此會使用硬體清查自訂設定來設定伺服器。

商業優勢

在 System Center 2012 Configuration Manager 中使用自訂用戶端設定可以達到下列商業需求:

  • 移除僅用於對用戶端子集提供自訂用戶端設定的站台,因此可以減少基礎結構需求。

  • 管理中心網站會將用戶端設定的標準設定套用至階層中的所有用戶端,因此可以簡化系統管理作業。

  • 會有兩個用戶端集合使用必要的自訂用戶端設定。

  • 在芝加哥和倫敦之間傳送資料時,能夠控制網路頻寬。