遠程安裝操作系統

作者:管理員/ /分類: 文章
遠程安裝操作系統

發布日期:1999年9月9日

在Microsoft ® Windows ® 2000操作系統的遠程安裝功能的基礎上,遠程安裝服務(RIS)技術,使管理員能夠部署一個操作系統整個企業,而不需要物理訪問每個客戶端計算機。

其中最具挑戰性的和昂貴的職能執行的IT人員今天是部署新的操作系統的客戶端計算機。 遠程 OS安裝功能使用新的基於 PXE的遠程啟動技術幫助 IT人員與部署在Windows 2000 Professional的遠程方式,從而降低IT支持開銷帶來新的電腦上網,並在重新安裝操作系統在外地。

前言

遠程操作系統(OS)的安裝和IntelliMirror™管理技術是重要的變更和配置管理功能包括在Microsoft ® Windows ® 2000的操作系統。 遠程操作系統安裝允許系統管理員使用新的預啟動執行環境(PXE)的遠程引導技術,以及基於服務器軟件的安裝本地副本的Windows 2000 Professional操作系統的計算機上整個企業。 在Windows 2000計算機上運行,網絡管理員,使用IntelliMirror的技術,可以提供基於策略的管理用戶的基於 Windows 2000的台式機,包括數據,設置和應用軟件。

下表突出了Windows 2000的變更和配置管理功能和優點,以及基本的技術支持這些功能。

Bb742501 Remote01 28en,我們 TechNet 10 29遠程操作系統安裝

導言

其中最具挑戰性的和昂貴的職能執行的IT人員是今天部署的操作系統(OS)的新的或現有的客戶端計算機。 目前,組織花費了大量的時間和費用的規劃,設計和推出的最新版本操作系統的整個組織。 這一過程通常是手工完成,需要專業人士幫助台物理訪問每一台計算機。

遠程安裝服務(RIS),一個可選組件的Windows 2000 Server操作系統,與其他Windows 2000的技術,實施遠程 OS安裝功能,為企業提供有能力的副本遠程安裝的Windows 2000 Professional操作系統在支持的計算機在整個企業。 現在,管理員可以推出一個新版本操作系統的數百,甚至上千的客戶在同一時間,這樣做從遠程位置。

計算機 PC98標準配備一個 PXE的遠程啟動 ROM,這是必須要使用遠程 OS安裝功能。 (PC98指的是年度指南硬件開發者共同創作與英特爾,微軟,康柏,包括捐款和其他行業的硬件製造商。PC98的目的是提供標準硬件的發展,推動 PC平台,使微軟,包括先進的功能,如註冊機構,在Windows平台上。)為您的組織中的計算機不包含一個 PXE的遠程啟動 ROM,微軟提供了管理員的工具來創建一個遠程啟動盤與 RIS使用。 在RIS遠程啟動磁盤可用於多種與支持的PCI為基礎的網絡適配器卡。 該網絡的PC - 1瘦身版本的個人電腦沒有軟盤或CD - ROM驅動器,將會是第一個客戶端計算機,以利用RIS的。 由於其缺乏外部軟盤驅動器,網絡電腦將需要使用遠程 OS安裝功能的安裝工作站的操作系統。

概述了技術和術語

本節概述遠程安裝服務(RIS)和其他組件的體系結構和Windows 2000的服務,這是必須採取利用遠程 OS安裝功能。 本節還介紹了客戶端組件和服務,需要為實施遠程 OS安裝在您的組織。

遠程操作系統安裝概述

圖 1說明了服務和組件構成的遠程 OS安裝功能。

Bb742501 Remote02 28en,我們 TechNet 10 29遠程操作系統安裝

圖1:遠程操作系統安裝

遠程操作系統安裝使用了一些現有的服務可能已部署在你的組織內使用,並增加了一些額外的服務,你可能不熟悉。 Windows 2000 Server中附帶的Active Directory™目錄服務,更新的動態主機配置協議(DHCP)服務器,以及標準版本的動態域名服務器(動態域名)所需的Active Directory中。 當遠程安裝服務安裝,這些額外服務添加到服務器:

  • 啟動信息協商層(BINL)BINL服務過程中添加RIS安裝過程。 BINL服務負責回答客戶端計算機的網絡服務請求,查詢 Active Directory的代表在客戶端計算機,以及確保正確的策略和配置設置應用到客戶端計算機在安裝操作系統。
  • 普通文件傳輸協議守護程序(到tftpd),這個服務器端TFTP服務是負責主辦下載特定的文件提出的請求由客戶端計算機。 到tftpd服務用於下載客戶端安裝嚮導(CIW)和所有客戶端對話框包含在CIW的某屆會議。
  • 單實例存儲(SIS),單實例存儲服務是負責降低磁盤空間要求的數量用於存儲RIS安裝圖像。 當您安裝 RIS作為一個可選組件,系統提示您輸入一個驅動器和目錄你想安裝 RIS:這是RIS卷。 申根信息系統服務自身附加到RIS卷,並監督該卷尋找任何重複的文件放置在該卷。 如果有任何重複的文件被找到,SIS的創建一個鏈接到重複,從而減少所需的磁盤空間。

遠程操作系統安裝使用新的預啟動執行環境(PXE)基於 DHCP的遠程引導技術,以啟動安裝操作系統的源從遠程向客戶端的硬盤上。 遠程源服務器,支持遠程安裝服務(RIS)的網絡提供相當於 1基於 CD安裝 Windows 2000 Professional或預先配置遠程安裝準備(RIPrep)桌面圖片。 在Windows 2000 Professional操作系統,是目前唯一支持的安裝選項遠程安裝服務。

  • 基於CD安裝的CD的選項類似設立一個工作站直接從Windows 2000 Professional的光盤,但是,源文件駐留在網絡上可用的RIS服務器。
  • RIPrep映像格式的RIPrep的成像選項允許網絡管理員克隆規範的公司法人桌面配置,完成操作系統配置,桌面自定義,以及本地安裝的應用程序。 在首先安裝和配置Windows 2000 Professional的操作系統,它的服務,標準應用的任何計算機上,網絡管理員運行一個嚮導,準備安裝映像,並複製到一個可用的RIS服務器在網絡上安裝其他客戶端。

一旦照片被張貼在RIS服務器(縣),最終用戶配備了基於 PXE的遠程啟動功能(或兼容的啟動磁盤)客戶端計算機可以要求安裝這些圖像從任何可用的RIS服務器在網絡上。 事實上,用戶可以安裝操作系統沒有管理員援助的手段,管理員可以自由地完成其他任務,要求他或她的注意,從而節省了時間和費用通常與作業系統的安裝。

如何PXE的遠程啟動技術的工作原理

阿新形式的遠程引導技術已經建立在計算機行業。 新的遠程啟動技術,預啟動執行環境(PXE),提供企業有能力利用其現有的TCP / IP網絡基礎設施與動態主機配置協議(DHCP)來發現遠程安裝服務器,在網絡上。 淨 PC/PC98-compliant系統,並配有電腦網絡接口卡(NIC)支持在RIS遠程啟動盤可以利用遠程啟動技術包括在Windows 2000操作系統。

當啟用 PXE的客戶端計算機打開時,基於 PXE的光盤或RIS遠程啟動磁盤請求的IP地址從 DHCP服務器使用正常的DHCP發現過程。 由於部分初步DHCP發現的請求,客戶端計算機識別自己是被啟用 PXE的,這表明到遠程安裝服務器的網絡上,它正在考慮提供服務。 任何可用的RIS服務器在網絡上能作出響應,提供客戶與它的IP地址和名稱啟動文件,客戶端應請求,如果該客戶想從該服務器的服務。

下面是一個圖,圖 2,描述了分步過程 PXE的遠程啟動 ROM去通過在每一個網絡服務引導請求。

Bb742501 Remote03 28en,我們 TechNet 10 29遠程操作系統安裝

圖2:PXE的遠程啟動ROM啟動序列

手術後到達第7步,客戶端的經驗會有所不同,這取決於遠程安裝服務器供應商,是響應客戶端請求提供服務。 下一節詳細的實施遠程操作系統安裝的是包含在Windows 2000 Server操作系統。

如何遠程操作系統安裝過程工程

有一個直觀的如何遠程 OS安裝過程的工作,載於圖 3。 每一個步驟的過程定義在下面詳細的說明

Bb742501 Remote04 28en,我們 TechNet 10 29遠程操作系統安裝

圖3:遠程安裝服務架構

接觸的過程 RIS服務器,並選擇一個操作系統映像完成幾個步驟。 下面的步驟詳細的順序發生的事件時啟用 PXE的客戶端計算機啟動的網絡,並提供服務 RIS服務器。

為了實現遠程OS安裝

  1. 啟用 PXE的客戶端連接到網絡啟動,並在上電,計算機啟動一個網絡服務請求。 由於部分網絡服務請求,DHCP探索數據包發送到網絡請求的IP地址從最近的DHCP服務器,IP地址可用的RIS服務器上,並作為該請求的一部分,客戶端發送的全局唯一標識符(GUID)的。 (GUID是存在於客戶端計算機 PC98,或Net PC的申訴,發現在系統 BIOS的計算機。)。 DHCP服務器響應請求,提供一個 IP地址給客戶端。 任何可用的RIS服務器可以響應的IP地址和名稱啟動文件應要求客戶端如果客戶選擇該 RIS服務器服務。 提示用戶按下功能鍵,F12鍵 ,啟動服務,從RIS服務器。
  2. 在RIS服務器(使用BINL服務)必須檢查 Active Directory中存在一個前舉行的客戶端計算機帳戶符合此客戶端計算機。 濱力檢查是否存在客戶端計算機通過查詢的Active Directory客戶端計算機發送匹配的GUID在第1步。
  3. 一旦註冊機構已檢查是否存在客戶端計算機帳戶,客戶端安裝嚮導(CIW)被下載到客戶端計算機,並提示用戶登錄到網絡。
  4. 一旦用戶登錄,註冊機構檢查 Active Directory中相應的用戶帳戶,驗證密碼。 註冊機構然後檢查的RIS的特定組策略設置來找出哪些安裝選項,用戶應獲得。 RIS公司還檢查,看看有哪些操作系統圖像的特定的用戶應提供和客戶端安裝嚮導使得這些方案提供給客戶。
  5. 如果用戶只允許一個單一的安裝選項和操作系統的選擇,用戶不提示您選擇任何內容。 相反,客戶端安裝嚮導警告用戶安裝將重新格式化硬盤,以前存儲的信息將被刪除,然後提示用戶啟動遠程 OS安裝。
  6. 一旦用戶確認安裝設置在摘要屏幕,操作系統安裝開始。 此時,如果客戶端計算機帳戶並沒有出席在Active Directory中,BINL服務創建客戶端計算機帳戶,從而自動提供一個名稱為計算機。 操作系統是安裝在本地作為一個無人參與的安裝,這意味著最終用戶不提供任何安裝過程中選擇作業系統安裝階段。

遠程操作系統安裝過程非常簡單從最終用戶的角度。 管理員可以指導用戶通過一個成功的操作系統安裝的前確定哪個安裝選項,如果有的話,最終用戶可以訪問。 管理員還可以限制哪些操作系統圖像或圖像,用戶可以訪問,從而保證了正確的操作系統安裝類型是提供給用戶成功安裝。

遠程安裝服務組件

Windows 2000遠程 OS安裝功能簡化了安裝任務的操作系統提供一個機制的計算機連接到網絡服務器時,最初啟動,並允許服務器驅動器本地安裝的Windows 2000專業版。 有幾個組成部分構成的遠程安裝服務(RIS),技術,支持遠程 OS安裝功能。 本節討論的各個組成部分的系統管理員或IT專業人士使用的安裝,配置,並實施註冊機構在其組織,以便部署Windows 2000 Professional操作系統。

有五個主要組成部分,使RIS進行:

  • 遠程安裝服務安裝(Risetup.exe創建)。
  • 遠程安裝服務管理。
  • 客戶端安裝嚮導(OSChooser.exe)。
  • 遠程安裝準備嚮導(Riprep.exe)。
  • 遠程安裝啟動盤(RBFG.exe實用)。

注:欲了解更多有關安裝,配置和實施遠程操作系統安裝,請參閱Windows 2000遠程OS安裝走過列出有關詳細信息 ,本文件。

遠程安裝服務安裝

RIS安裝兩種方法之一,並要求分兩個階段安裝過程。 RIS是一個可選組件的Windows 2000 Server操作系統,可以安裝在安裝過程中或在Windows 2000 Server,或安裝後使用添加/刪除程序控制面板

第一階段時發生的安裝RIS的選擇可以作為可選組件,在Windows 2000 Server安裝或安裝後,服務器使用添加/刪除程序 Windows組件嚮導顯示遠程安裝服務可以作為可選組件安裝,並在圖 4所示。

Bb742501 Remote05 28en,我們 TechNet 10 29遠程操作系統安裝

圖4:可選組件:遠程安裝服務

遠程安裝服務後,選擇了作為一個可選組件,第一階段的RIS安裝所需的文件複製到硬盤驅動器在服務器上。 在安裝服務器的完成,管理員會提示關閉並重新啟動服務器,然後再安裝遠程安裝服務。

要安裝遠程安裝服務

  1. 開始菜單上,指向程序 ,然後是管理工具 ,然後單擊配置您的服務器
  2. 配置服務器對話框中,單擊完成安裝
  3. 配置遠程安裝服務對話框中,單擊配置以啟動遠程安裝服務安裝嚮導。
  4. 遠程安裝服務安裝嚮導對話框,單擊下一步

遠程安裝服務安裝嚮導提示管理員的特定設置信息中使用RIS安裝。 該嚮導要求管理人提供下列項目:

  • 某個位置的服務器上的RIS目錄樹將被創建。
  • RIS服務器是否應服務客戶端計算機在完成安裝程序。
  • 位置的Windows 2000 Professional的CD或網絡上的位置,包含安裝文件。
  • 阿友好的描述和相關聯的幫助文本,用來描述的操作系統映像的用戶的客戶端安裝嚮導。

之後,遠程安裝服務安裝嚮導完成後,根據設置的選擇,RIS服務器或者服務的客戶端計算機,或停頓而管理員配置高級設置使用RIS管理設置。 以下部分描述了配置選項提供給一個 RIS管理員。

遠程安裝服務管理和配置選項

默認情況下,RIS服務器沒有配置客戶端計算機提供服務後,立即安裝 RIS的完成。 如果管理員想配置服務器,以服務客戶端計算機在RIS安裝完成後,管理員只需接受默認配置設置,並開始為用戶提供操作系統安裝圖像不改變單一的配置設置。

RIS提供管理員與品種的選擇和配置設置。 這些設置提供了靈活性方面的具體方案,如類型計算機自動使用命名的政策,這 Active Directory容器客戶端計算機帳戶中創建的,哪些操作系統圖像的最終用戶將能夠利用。 更多詳細信息有關個別配置選項,請參閱文件的RIS演練在部分欲了解更多信息,或查看幫助遠程安裝服務在Windows 2000 Server光盤,它也可以在Windows 2000 Server的Web站點( 呻/ www.microsoft.com/technet/prodtechnol/windows2000serv/default.mspx)。

有4種方法用於配置可用的RIS選擇。

第一種方法包括指定哪些RIS服務器允許您的網絡上運行。 此選項可防止未經批准的(通常稱為流氓)RIS服務器,以確保只有那些RIS服務器授權的管理員可以服務客戶。 如果試圖啟動一個未經授權的RIS服務器在網絡上,它會自動關閉,因此無法服務客戶端計算機。 阿RIS服務器必須獲得授權才能服務客戶端計算機。

設置 位置 默認
授權 DHCP管理器MMC管理單元 殘疾人

第二種方法是使用Active Directory用戶和計算機管理單元中設置屬性的個別 RIS服務器控制服務器如何提供遠程安裝服務給請求客戶端。 此管理單元可通過將開始菜單,指向程序 ,然後是管理工具 ,然後單擊Active Directory用戶和計算機 .. 管理單元出現如圖所示5。 希望管理員遠程管理他們的服務器從 Windows 2000 Professional工作站可以訪問管理工具的安裝管理工具包位於 Windows 2000 Server光盤。

注意:當使用管理工具在系統以外的RIS服務器,管理員不能添加其他的操作系統映像或驗證完整性RIS服務器。 所有其他的配置可供選擇。

Bb742501 Remote06 28en,我們 TechNet 10 29遠程操作系統安裝

圖5:Active Directory用戶和計算機管理單元

RIS服務器後,選中,右鍵單擊它打開屬性對話框,然後單擊遠程安裝選項卡訪問RIS服務器配置選項。 屬性對話框如圖6。

Bb742501 Remote07 28en,我們 TechNet 10 29遠程操作系統安裝

圖6:屬性對話框RIS服務器

下面的列表描述了主要的配置選項,可以在屬性對話框中:為RIS服務器

共同存在的遠程安裝服務器的來自多個供應商:對於公司有遠程啟動和安裝來自其它廠商的服務器正在運行在同一物理網絡,RIS服務器可以設置為只響應來自客戶端請求提供服務已預先按在Active Directory中。 當設置為忽略未知請求啟動客戶端,RIS服務器可以引進無干擾的網絡預先現有的遠程安裝服務器使用相同的遠程啟動協議。

  • 什麼客戶的RIS服務器應響應,這些選項允許管理員指定是否RIS服務器應響應客戶端計算機,如果是,是否作出回應時,沒有以前的知識,客戶端計算機在Active Directory(在客戶端沒有預先按 )。 Prestaging客戶允許共存的遠程安裝服務器與多家供應商在同一個物理網絡,可選的負載平衡,以及更高的安全性比什麼系統可以執行遠程 OS安裝。 默認設置也可以改變,在遠程安裝服務安裝嚮導(Risetup.exe創建)。
    設置 位置 默認
    響應客戶端計算機的請求服務 遠程安裝標籤 殘疾人
    不響應未知客戶端計算機 遠程安裝標籤 殘疾人
  • 自動客戶端計算機命名格式 ,當客戶端計算機的名稱自動生成,此選項決定如何名稱應被格式化。 有幾個可用的命名方案,其中包括能夠使用自定義命名格式為特定的組織。 此選項提供了靈活性,命名新的客戶端計算機操作系統安裝過程中,而不需要為最終用戶或管理員的參與。
    設置 位置 默認
    客戶端計算機命名格式 高級設置,新客戶卡 用戶名
  • 默認Active Directory位置為創造新的客戶端計算機帳戶 ,這個選項允許管理員選擇默認Active Directory位置,所有遠程安裝的客戶端計算機帳戶將被創建在操作系統的安裝。 管理員可以選擇任何默認容器或組織單位(OU),或創建一個新的OU具體到RIS安裝客戶端計算機。
    設置 位置 默認
    客戶帳戶的位置 高級設置,新客戶卡 計算機容器
  • 現有的操作系統映像 ,這個選項允許管理員添加新的操作系統版本或RIPrep映像現有RIS服務器安裝的客戶端。 此外,管理員可以關聯多種無人參與的安裝模板,基於 CD的安裝映像,從而提供更大的靈活性,安裝選項。 例如,管理員可以選擇只添加一個 Windows 2000 Professional的光盤的圖像在RIS服務器上,但可以關聯多個不同的腳本無人參與的安裝文件,所有指著一張 CD的圖像。
    設置 位置 默認
    操作系統圖像列表 高級設置,圖像卡 基於 CD的Windows 2000專業形象
  • 第三方獨立軟件開發商維護和故障診斷工具 ,提供行政人員,如果適用的最終用戶,獲得預操作系統維護和故障排除工具,從第三方供應商。 這些工具可用於維護和故障排除之前,客戶端計算機裝載或安裝操作系統。 例如,閃光系統的BIOS之前,OS安裝。 其他的例子包括內存病毒掃描,電腦診斷工具,或基於庫存的工具。
    設置 位置 默認
    工具上市 高級設置,工具標籤 無工具安裝

    最佳做法如果自動設置是唯一的安裝選項提供給用戶(因為它是默認情況下),安裝選項菜單將不會顯示,減少的可能性最終用戶錯誤或混淆。

    第三種方法涉及到的配置使用組策略可以指定安裝選項將出現不同的用戶群體,在客戶端安裝嚮導(CIW)。 例如,它可能不適合用戶訪問自定義安裝選項或可用的工具下的維護和疑難解答菜單。 相反,管理員可能希望允許普通用戶只能訪問自動設置選項,並限制訪問的所有其他選項,管理員或服務台的工作人員。

    設置 位置 默認
    CIW的安裝選項 默認域策略,用戶配置,Windows設置,遠程安裝服務 自動安裝程序只為所有用戶域

    最佳做法自動化操作系統的形象是某些用戶安裝,確保這些用戶只能訪問的形象,他們應該安裝。 當只有一個單獨的圖像可用,圖像選擇屏幕不顯示和單可用圖像自動選擇。

    第四個也是最後的配置方法使用安全描述符,或自由訪問控制列表(DACL),以指定哪些用戶或組的用戶應訪問的操作系統映像可以在RIS服務器。 管理員可以使用此方法來指導用戶通過選擇無人參與的OS安裝適合自己的角色在公司內部。 默認情況下,當一個操作系統映像添加到RIS服務器,圖像將提供給所有用戶提供服務的RIS服務器。

    設置 位置 默認
    OS映像的用戶提供在CIW 上的DACL。sif文件中圖像的模板文件夾 提供給所有用戶

    最佳實踐為減少工作的維護安全應用的圖像,在可能的情況設置安全模板文件夾中的形象,而不是個人。sif文件本身,使用用戶組授予和限制進入,而不是個人用戶。

    經過必要的配置選項,註冊機構已經確定,管理員準備服務的遠程啟動功能或兼容的客戶端計算機。 概述客戶端安裝嚮導(CIW),提出在未來的一段,並說明現有的安裝方案,能提供給最終用戶。 如上所述,為了請求服務從 RIS服務器,客戶端計算機可以使用一個基於 PXE的遠程引導 ROM,或網絡卡的支持,在RIS遠程啟動磁盤。

客戶端安裝嚮導

擴展的字符在CIW:由於CIW是運行在預啟動執行環境,也沒有支持擴展字符無論是在文字中顯示或輸入字段(用戶名,密碼,域,或任何自定義輸入參數)。 應認真考慮採取在創建用戶或網域名稱包含擴展字符因為它們將無法使用與RIS。

一旦客戶端計算機建立一個連接與RIS服務器,提示用戶啟動網絡服務啟動按F12鍵功能鍵。 客戶端安裝嚮導(CIW),如圖 7,然後自動下載到客戶端計算機。 提示用戶輸入他們的用戶名,密碼和域。 經過認證的用戶在Active Directory中,CIW的選擇提供了最終用戶或IT管理員有能力從菜單中選擇安裝選項和操作系統映像來控制和圖像的作業系統,將安裝。 如果用戶運行 CIW中只被獲准進入自動安裝選項和一個操作系統映像,沒有菜單顯示,用戶直接收益的確認和總結屏幕。

Bb742501 Remote08 28en,我們 TechNet 10 29遠程操作系統安裝

圖7:客戶端安裝嚮導

下面的安裝選項包括在客戶端安裝嚮導。 可自動設置默認。 註冊機構使用組策略設置為允許使用自動設置選項只,並限制所有用戶和管理員從剩下的安裝選項說明如下。

為了控制設置選項顯示給用戶在CIW中,使用組策略中所描述的“管理和配置選項”一節。

  • 自動安裝 ,這個選項提供了最簡單的作業系統安裝路徑。 它允許用戶選擇操作系統的安裝,但不提示用戶特定的配置設置。 如果只有一個操作系統選項提供,用戶不會得到提示,並自動安裝操作系統的映像會自動啟動。
  • 自定義安裝 ,這個選項允許用戶運行CIW的覆蓋全自動電腦命名過程,以及默認位置在Active Directory在客戶端計算機帳戶將被創建。 幫助台或管理員可以使用此選項來預安裝的客戶端計算機別人在企業內部。
  • 重新啟動前安裝的嘗試 ,如果選中,此選項會自動重新啟動操作系統安裝過程時,安裝嘗試失敗才完成。 此選項不複製文件從哪裡上安裝嘗試失敗了,但是用戶無須回答任何問題在CIW之內接聽,從以前的安裝嘗試。
  • 維護和故障排除 ,此選項提供對第三方維護和故障排除工具,可以用來安裝操作系統之前。 這些工具的例子包括系統快閃 BIOS更新,電腦診斷工具和病毒掃描工具。 請參閱更多信息一節的獨立軟件開發商和OEM廠商提供有效的工具與 RIS使用。

如果用戶有一個以上的操作系統映像提供給他們安裝,列表顯示的圖像供選擇。 The user is then presented with confirmation and summary screens, after which the installation of the image on the client computer begins immediately.

The screens and text displayed in the CIW can also be customized, and additional screens can be displayed to the user if desired. For example, if users must enter a specific configuration parameter during the CIW, a custom screen can be created and linked to those already displayed. Such parameters can then be passed to the .sif file of the selected operating system installation image. For more information on customizing the CIW screens, see the Windows 2000 Server Resource Kit (available in Microsoft TechNet).

Remote Installation Preparation Wizard

Note: See the “Remote OS Installation Usage Scenarios” section later in this document for details on how to combine the Windows 2000 Group Policy and Software Installation and Maintenance features with Remote OS Installation to create standard desktop images that include applications.

There are two types of operating system images supported by Remote OS Installation: CD-based images and RIPrep images. The CD-based option is similar to setting up a client operating system directly from the Windows 2000 Professional CD, but in this case, the source files reside on an RIS server. However, more companies are beginning to implement a corporate standard desktop policy. This policy requires that users install only approved versions of an operating system and associated applications or application suites. These desktop standards have a variety of names, such as Standard or Common Operating Environments (SOEs or COEs), but all usually involve packaging the operating system, required service packs, a set of applications, and appropriate operating system and application configuration settings into a single, tested, and supported unit.

In order to build and maintain standard desktops, many companies use disk imaging or cloning software that allows an administrator to configure a client computer exactly how he or she wants it, following company standards and software policies, and then make a copy of that image for installation on client computers on the network. Remote OS Installation supports creation and installation of standard desktop images using the RIPrep feature.

One of the biggest limitations in most imaging technologies is the requirement that the destination computer (the computer that will receive the image) contain identical hardware to that of the source computer used to create the image.

An important element of the RIPrep feature is the fact that the destination computer (the computer that installs the image posted to the RIS server) is not required to contain hardware identical to that of the source computer that was used to create the image. RIPrep uses the Plug and Play support in the computer running Windows 2000 Professional to detect differences between the source and the destination computers' hardware during image installation. The exception is that the hardware abstraction layer (HAL) drivers must be the same between the source computer and all destination computers that later install the image. However, in most cases, workstations do not require the unique HAL drivers that servers require. The primary difference in HAL drivers for workstations is whether systems contain Advanced Configuration Power Interface (ACPI) support versus a non-ACPI supported computer. When using RIPrep, you must create and maintain separate installation images for systems that have ACPI or other features that require the use of specific HAL drivers, but other hardware differences, such as video or disk controllers, can be automatically accommodated for hardware compatible with Windows 2000.

Bb742501 Remote09 28en-us TechNet 10 29 in Remote Operating System Installation

Figure 8: The RIPrep wizard

Note: If the source computer contains a 1 gigabyte (GB) disk drive and the destination computer contains a 2-GB disk drive, by default RIS will format the destination computers drive as a 2-GB partition in the same file system format as the source computer used to create the image.

The Remote Installation Preparation wizard (RIPrep.exe), which is part of the Remote OS Installation feature, is illustrated in Figure 8. The RIPrep wizard provides the combined ability to prepare an existing Windows 2000 Professional installation for use as an image to be installed on other computers, including any locally installed applications and/or specific configuration settings, and to replicate that image to an available RIS server on the network. The RIPrep feature currently supports replicating a single disk-single partition (C partition only) Windows 2000 Professional installation to an available RIS server. This means that the operating system and all of the applications that make up the standard installation must reside on the C partition prior to running the RIPrep wizard.

Creating the Source Computer

To create the source computer, the administrator first uses the Remote OS Installation feature to remotely install the base Windows 2000 Professional operating system. Once the operating system is installed, the administrator can install applications or application suites including in-house line of business (LOB) applications. The administrator then configures the workstation to adhere to company policies. For example, the administrator may choose to define specific screen colors, set the background bitmap to a company-based logo, remove any games installed by the base operating system, and set Internet Explorer proxy settings.

Configuring the Workstation

When creating RIPrep images, it is important to understand the relationship of user profiles, the changes made to a RIPrep source computer, and the desired result for users that log on to computers that are installed using the RIPrep image. Windows 2000 Logo-compliant applications properly separate user-specific and computer-specific configuration settings and data, and can therefore be installed computer-wide so that they are available to all users of the system. Such applications would also then be available to all users of systems later installed with the resulting RIPrep image. Non-Windows 2000-compliant applications may perform and/or rely on per-user configurations that are specific to the profile of the user actually installing the application prior to running RIPrep (typically a local administrator), rather than to all users of the system. Such configurations remain specific to that user, which may result in the application or configuration setting not being available or not functioning properly for users of computers installed with the RIPrep image. In addition, some non-application configuration changes, such as the wallpaper specified for the user desktop, are by default applied only to the current user's profile, and will not be applied to users of systems installed with the RIPrep image.

Therefore, you must thoroughly test any applications or configuration settings desired for use in a RIPrep image to ensure they will work properly with your organization's implementation of user profiles. To do so, make the change as one user (typically a local administrator of the computer), log off, and log on as a user account that is representative of your organization. If the changes you made are applied to the second user, the changes should also apply to users that log on to systems installed with a RIPrep image that contains the same change. To complete the test, create a RIPrep image, restore it to a different computer, and log on as a different representative user. Verify that the changes are applied and fully functional.

Some configuration settings can be copied directly from the profile they were applied to (the local administrator in the above example) to the All Users profile, such as the desktop wallpaper, some Start menu options, and shortcuts. However, all such changes must be tested carefully to verify that their functionality is not broken by the manual adjustments.

Running the Remote Installation Preparation Wizard

Once the workstation is configured exactly the way the administrator likes, they are ready to run the Remote Installation Preparation wizard.

The RIPrep wizard starts by prompting the administrator for specific settings relating to the image they are about to post on the RIS server. The administrator is asked where the image should be replicated, that is to which RIS server, and to provide a directory name on the RIS server where the image should be replicated. The wizard prompts the administrator to provide a friendly description and associated Help text describing the contents of this image to end users running the Client Installation wizard. After the initial image questions have been answered, the wizard configures the workstation to a generic state, removing anything unique to the client installation such as the computer's unique security ID (SID), computer name, and any registry settings unique to that system. Once the preparation phase is complete, the image is automatically replicated to the RIS server provided. After the image is replicated to the RIS server, it is added to the list of available OS installation choices displayed within the CIW. At this point, any remote boot-enabled or compatible client computers that use the PXE-based remote boot technology can install the image.

Remote Installation Services Boot Disk

There are two types of remote boot-enabled client computers:

  • Computers with PXE-based remote boot ROMs.
  • Computers with network cards supported by the Remote Installation Boot Disk. Bb742501 Remote10 28en-us TechNet 10 29 in Remote Operating System Installation
    圖9:遠程啟動磁盤生成

The RIS remote boot disk generator (Rbfg.exe), illustrated in Figure 9, can be used to create a boot disk to support existing client computers that do not have a PXE-based remote boot ROM, but that do have a supported network adapter. Using the RIS boot disk eliminates the need to retrofit existing client computers with new network cards that contain a PXE boot ROM in order to take advantage of the Remote OS Installation feature. The RIS boot disk simulates the PXE remote boot sequence, and supports frequently used network cards. The RIS boot disk works like the PXE boot process: turn on the computer, boot from the RIS boot disk, press F12 to initiate a network service boot, and the Custom Installation wizard (CIW) is downloaded and starts. Once the CIW starts, the rest of the RIS process is identical regardless of whether the client was booted using a PXE boot ROM or the RIS remote boot disk. For the complete listing of network cards currently supported by the RIS boot disk, see Appendix B.

Using Remote OS Installation in an Organization

Companies today have a variety of operating system deployment and installation mechanisms in place. This section explains how you can use the Remote OS Installation feature in addition to existing deployment mechanisms to further reduce the costs associated with OS and application deployment.

The following list of scenarios cover the majority of these deployment mechanisms in use today:

  • Manual (attended) OS installation using a CD-ROM.
  • Automatic (unattended) OS installation using a server share.
  • Third party OS plus application imaging technologies.

Manual (Attended) OS Installation Using a CD-ROM

This scenario is one of the most expensive mechanisms for deploying an operating system within an organization. Many companies today send a technician to the user's desk to perform an OS installation using a CD-ROM. Or the technician pre-installs the computer before it's delivered to the end user. This installation type is manual in nature, requiring a technician to physically visit the end user, and manually install the operating system. The technician must be skilled enough to answer technical questions during the installation, specifically regarding the hardware contained within the computer. The cost associated with just one computer installation using this method varies from approximately $180.00 to more than $300.00 depending on the success or failure of the installation process, and can result in variance from corporate standards for system configurations.

By setting up a single Windows 2000-based RIS server, a company can reduce the costs associated with this deployment method and ensure standardization of client computers. RIS can be used to reduce the costs associated with this OS deployment method in these two ways:

  • First, the technician would use RIS to initiate an unattended installation of the Windows 2000 Professional operating system over the network using either the built in remote boot capabilities of the computer, or by using the easy to create RIS boot disk. By employing RIS, the company reduces the time required by the technician, as well the required skill of the technician needed to install the OS. The technician would not be required to carry around the CD and boot disks, and since the installation is fully unattended, the technician could initiate the OS installation, and then move on to the next user.
  • As another option, the company could choose to forgo the necessity of the technician altogether by allowing the end user to install the OS on their own computer. As noted above, the administrator can guide the user through the correct OS selection, or choose an OS image to be selected for installation automatically when the user logs on to the Client Installation wizard. If the end user need only press F12 , enter their username and password, and then press ENTER , substantial costs can be avoided when deploying the operating system company wide.

Automatic (Unattended) OS Installation Using a Server Share

This deployment mechanism involves the creation of a boot disk containing, in most cases, a copy of the MS-DOS® operating system, a network card driver specific to the computer being booted, and networking software that connects the computer to a network server share containing the OS installation files. This mechanism is also very costly, and requires a substantial amount of technical knowledge, and understanding of the hardware in use throughout the company.

By adding a RIS server to the mix, the technician can use the RIS boot disk, which is created with a single click by the administrator or end user. The RIS boot disk supports a variety of network cards in use today. You can use the RIS boot disk with computers that contain supported PCI-based network adaptors. The RIS boot disk does is not MS-DOS-based, and does not require specific MS-DOS-based networking software to connect to an available RIS server. Rather, the RIS boot disk simulates the PXE boot ROMs described earlier in this paper, and all necessary network card drivers are contained within the single RIS boot disk.

No longer will a technician have to create NIC-specific LAN-enabled boot disks, configure an MS-DOS-based boot disk with regard to conventional memory management, or configure networking settings specific to the organization or division. If your company already uses DHCP and TCP/IP, there is nothing more that needs to be configured to implement Remote OS Installation. Add to this the ability of the administrator to offer base CD unattended installations and/or fully populated RIPrep images that include applications and configuration settings, and you can see the cost saving potential.

Third Party OS Plus Application Imaging Technologies

Many companies have switched to implementing image-based OS deployment technologies. Companies are investing a substantial amount in the creation of hardware specific images that contain both the OS and applications used within the company. There are several third party imaging vendors that provide solutions for deploying the Microsoft Windows family of operating systems. These technologies can be less expensive, require less time to install, and in some cases, require less technical expertise than the deployment methods listed above. In some cases, companies actually perform hardware-based drive duplication, where the hard disk of the source computer is duplicated with a hardware disk duplicator. The resulting hard disk is then installed in a computer and shipped directly to the end user. Other companies can use the existing network for image replication from the source computer to the destination, using a form of boot disk that loads and connects to the network.

All of the imaging technologies available today require that the destination computer (the computer that will install the image) contain the exact same hardware as the source computer used to create the image. These technologies also require in most cases the use of an MS-DOS-based boot disk, which requires some knowledge of the network card hardware in existing computers. By using the RIPrep component of Remote OS Installation, companies can create a single image, and deploy that image across different types of computer hardware within the company. If the existing computers within your organization do not contain a compatible PXE boot ROM, the RIS boot disk can be used to initiate the installation of the RIPrep image.

Given the substantial investment in existing images, Microsoft is working with several of the third party imaging companies to provide integration support that will allow using the existing OS images with RIS. For more information on which vendors are integrating with RIS, see the For More Information section.

The following examples show how Remote OS Installation can reduce costs and increase productivity in an enterprise environment. The scenarios below may be useful in determining the best way to use the Remote OS Installation feature within your organization if you do not already have an OS deployment mechanism in place. The section below will cover the following scenarios:

  • Fresh OS Installation on new or existing computers.
  • Disaster OS recovery.
  • Pre-installing vs. prestaging.
  • Using Client Installation wizard options.

Remote OS Installation Usage Scenarios

Scenario 1: New or Existing Computers: A Fresh OS Install

When companies order a computer from an original equipment manufacturer (OEM) or independent hardware vendor (IHV), the computer arrives pre-installed with an operating system. In many cases, the installed OS violates the company's standard desktop policies. As a result, many companies erase the existing OS, and install a version that meets their corporate desktop standards. Companies might also have existing computers on which they want to install a new operating system, and avoid the upgrade process altogether.

Net PC and PC98-compliant computers support the DHCP-based PXE remote boot technology. You can use this technology to install the new OS image on these computers. For pre-Net PC/PC98 computers, the Windows 2000 Server operating system includes a remote boot disk generator that creates a floppy disk, which simulates the PXE remote boot ROM.

Remote OS Installation is configured to install the Windows 2000 Professional operating system by first repartitioning and formatting the hard disk. Once the repartition and format are complete, the operating system is installed in an unattended manner. The administrator can create customized, unattended .sif files that perform OS installations with different settings and features based on specific organization or company standards. For example, a company may require its sales teams to install their computers with only the TCP/IP protocol, yet allow the finance department to install both the TCP/IP and the IPX/SPX protocols due to their in- house accounting system. By using two types of unattended .sif files, the administrator can use a single CD-based operating system image for two different types of OS installations.

RIS also provides the ability to install a RIPrep-based OS image, complete with locally installed applications and configuration settings that the administrator has determined meet the company's desktop standard. The administrator first uses Remote OS Installation to install a client computer with the base Windows 2000 Professional operating system. Then they can install the application or full application suite, and any line of business applications specific to the company or division. The administrator may customize the installation to include a company specific background bitmap, and links on the desktop to relevant corporate resources. After the administrator tests the installation to ensure everything works and is compliant, they then replicate that installation (only a single disk/single partition is supported) to an available RIS server on the corporate network.

Once the OS image replication completes, it is now available for installation by any user the administrator has determined should have access to install that image.

Scenario 2: Disaster OS Recovery

有時,在一台計算機的硬件可能會失敗,無法修復。 In this situation, Remote OS Installation provides the ability to quickly and easily re-install the base operating system or RIPrep image on a computer that has failed completely. By combining the IntelliMirror technology, another change and configuration management feature of the Windows 2000 Server operating system, with the Remote OS Installation feature, a company can recover a large percentage of the entire user and computer configuration and data, including the user's personal data and settings. Once a new hard disk has been placed in the computer, the administrator or end user can initiate Remote OS Installation to install the base OS, or a RIPrep image complete with a base set of applications. After the image installation completes, the user logs on to the computer. At this point, any applications assigned to the user by the software installation and maintenance feature of IntelliMirror are available, as they were prior to the failure. Other Group Policy settings will be re-applied, the user's roaming profile is copied to the computer from the network, and user documents stored in a redirected My Documents folder are made available from the network. By separating the user state from the computer state, in a matter of minutes, the end user is up and running with everything they had prior to the hard disk failure, without the need for a help desk professional to re-install the operating system and the user's applications, and restore data from a backup.

Scenario 3: Pre-installing vs. Prestaging

Many companies today pre-install their client computers with an operating system before delivering the computer to the end user. Pre-installing the computer means that they have loaded the operating system and possibly applications, and have configured the system to meet company standards, before delivering to users. Pre-installation of the operating system by IT staff is a costly process, and increases the company's total cost of ownership. However by pre-installing, the administrator can manually enter a unique computer name and choose the specific Active Directory container the computer account will be created in. The administrator can use the RIPrep feature to install the OS and applications prior to delivery of the system.

Prestaging a computer account, on the other hand, is the process of creating a valid computer account object within the Windows 2000 Active Directory directory service. Prestaging a computer for use with Remote OS Installation allows the administrator the ability to deliver a blank computer directly to the user for OS installation. By prestaging the computer account in Active Directory, the administrator can configure the RIS servers to only respond to prestaged computers. This ensures that only those computers that have been prestaged as Authorized users are allowed to install an operating system from the RIS server. Prestaging can save both time and money by reducing, and in some cases eliminating, the need to fully pre-install the computer.

By prestaging the client computer, the administrator can define a specific computer name, and optionally, which RIS server will service the client computer. In order to prestage a client computer within Active Directory for use with Remote OS Installation, the administrator should follow the steps below.

To pre-stage a client computer

  1. Locate the container in the Active Directory service in which you would like your client computer accounts to be created.
  2. Right click the container, and then click New , and then Computer . The New Object-Computer dialog box appears, as illustrated in Figure 10. Bb742501 Remote11 28en-us TechNet 10 29 in Remote Operating System Installation
    Figure 10: Pre-staging a client computer
  3. Enter the computer name and authorize domain join permissions for the user or security group containing the user that will receive the physical computer this computer account represents.
  4. In the next dialog box, illustrated in Figure 11, you are prompted for the GUID/UUID of the computer itself, as well as whether you intend to use this computer as a managed (Remote OS Install-enabled) client. Enter the GUID/UUID and select the This is a managed computer check box.

The GUID/UUID is a unique 32-character number that is supplied by the manufacturer of the computer, and is stored within the system BIOS of the computer. It should be posted on the case of the computer, or on the outside of the box it was shipped in. If not, locate the GUID by unpacking the computer and running the system BIOS configuration utility. The GUID should be stored as part of the system BIOS. Contact your OEM for a Visual Basic® Scripting Language (VBScript) that can be used to prestage newly purchased client computers within Active Directory for use with Remote OS Installation.

Bb742501 Remote12 28en-us TechNet 10 29 in Remote Operating System Installation

Figure 11: Selecting a managed computer account

The next screen prompts you to indicate which RIS server this computer should be serviced by. This option can be left blank, which indicates that any available RIS server can answer and service this client computer. You can use this option to manually load balance clients across the available RIS servers within your organization, as well to segment the network traffic, if you know the physical location of the specific RIS server and where this computer will be delivered. For example, if a RIS server was located on the fifth floor of your building, and you are delivering these computers to users on that floor, then you could choose to assign this computer to the RIS server on the fifth floor.

Scenario 4: Creating Standard Desktops with RIPrep and Software Installation and Maintenance

If an Administrator wants to use Remote OS Installation to stage and standardize their computers, then they can consider installing the organization's key software at the same time.

The best way to describe this is to provide an example. Consider an organization that wants to bring in new computers, and customize both the Windows 2000 operating system and the Office 2000 suite of applications.

The administrator has Remote OS Installation set up and configured, and has the Software Installation and Maintenance feature of IntelliMirror configured. That is, there are existing Group Policy objects to manage the computers in the organization. The administrator has a Software Distribution Point for Office 2000, they have customized Office 2000, and then they have assigned Office 2000 to the computers in the appropriate GPOs. (For more information on how to do this, reference the Windows 2000 Software Installation and Maintenance Walkthrough listed in the For More Information section.)

Note: Care must be taken to configure the RIPrep source computer with applications from the same GPOs that apply to the destination computers (those that will install the RIPrep image) when they are deployed. The applications may be removed or removed and reinstalled if a different policy is applied to the computer when it is deployed.

The administrator installs the Windows 2000 operating system on a computer (that has the same HAL as the desired target systems), and configures the operating system the way that they want it. When Windows 2000 is installed and configured, the administrator adds it to the same Active Directory container where it will live when it is deployed. This container has a GPO with Office 2000 assigned to the computer.

The administrator starts the computer, and the Software Installation and Maintenance technology in IntelliMirror installs Office 2000 (applications assigned to the computer install when the computer starts).

After Office 2000 is installed, the administrator can take the computer running Windows 2000 with Office 2000 installed on it, and use the RIPrep tool of Remote OS Installation to build a Remote OS Installation image, and put this image on the Remote OS Installation server. Once this image is available, a person getting a new computer that supports Remote OS Installation only has to connect the peripherals (keyboard, mouse, monitor), connect to the network (plug a cable between the network card and the hub), turn on the computer, and press F12 when prompted to initiate a network boot.

The computer finds the Remote OS Installation server; download the operating system and the applications. When the computer restarts after remotely installing the OS, Windows Installer realizes that the software is already on the machine, and then only updates the application's advertisement information. This update of the advertisement information only takes a few seconds.

Note that when the user logs on to the computer, and selects the first Office 2000 application, the Windows Installer starts. Why is this? Office 2000 separates installation from user configuration to ensure proper separation between user-specific and machine-specific configuration. The Windows Installer starts each time a new user starts the application, in order to perform a small amount of user-specific configuration.

The key point is that Remote OS Installation and Software Installation and Maintenance allows administrators to rapidly and efficiently deploy both the operating system and applications, and still bring the applications into a state where they can be managed by Software Installation and Maintenance for future updates, and if necessary, removal.

Using the Client Installation Options

Using the Automatic Setup Option

The automatic setup option is the client installation option that all users of the Remote OS Installation feature have access to by default. The automatic setup option can be used to guide the user through a successful OS installation. The administrator is able to restrict the OS installation options in such a way that the user simply logs on, and the OS installation starts automatically. The user is not asked a single question during the OS install, which avoids lengthy calls to help desk professionals for assistance, thus saving the company additional expenses in support costs.

If the administrator decides, they can provide the user with multiple unattended OS choices. Remote OS Installation allows the administrator to provide a friendly description and associated help text that describes the OS options in such a way that an end user can choose the OS that best fits their need or role within the company. For example, the administrator can create several unattended answer files that install an OS tailored for the marketing users within the company. Each of the OS types provides a different subset of OS features given a specific type of marketing user. The administrator would restrict these OS types to only the marketing security group which ensures that only users that are members of that marketing security group are offered these OS choices. Now, the end users have a variety of OS installation types to choose from, but are able to make the choice based on the friendly description and help text provided when selecting each of the OS choices.

By pre-selecting the Remote OS Installation configuration options, the administrator predefines the automatic machine naming format and the location within Active Directory where client computer accounts will be created. IT staff will no longer have to manually preinstall computers for end users, ensuring that the computer account is created within the correct domain, or with the correct computer name. The administrator can simply define these attributes for a given RIS server and everything is done automatically during OS install.

Considerations:

  • By default, end users are restricted to only see the automatic setup option by the settings in the Default Domain Policy Group Policy object. If necessary, the administrator can modify the settings in the Default Domain Policy, and/or create additional group policy objects that allow end users access to the other installation options. For more information, see the Windows 2000 Help regarding Group Policy settings.
  • If you choose to offer end users multiple OS installation types, ensure the number offered is relatively small (a maximum of 3-5 is suggested). This will help to avoid confusion, and will assist in ensuring that end users select the OS that best meets their need and role within the company.
  • Group individual end users into security groups and use those groups to restrict the available OS installation options. Setting permissions for individual users on the individual setup information files (.sif) can become an administrative burden. Instead, use security groups to restrict the choices and where possible apply security on the Templates folder itself (which will apply to all .sif files in the folder) rather than on the individual .sif files.

Using the Custom Setup Option

The custom setup option is very similar to the automatic setup option, yet provides the administrator or help desk professional with the ability to set up a computer for someone else within their organization. This option can be used to fully pre-install a client computer or to prestage the client computer by creating a corresponding computer account within the Active Directory service. This setup option in many cases will only be used when the IT or help desk professional must perform the initial setup or re-installation of an end user's computer.

The custom setup option lets the administrator or help desk professional override the automatic computer naming and where the computer account is created within Active Directory. By default, the RIS server will generate a computer name based on a format defined by the Remote OS Installation administrator. The administrator can also define where client computer account objects (CAO) will be created in the Active Directory service during the operating system installation. By default, the automatic computer naming policy is set to create computer names based on the person who logs on to the Client Installation wizard.

In the case where an administrator or help desk professional is pre-installing the OS on the computer for someone else within the organization, it may not be appropriate to name the computer after the help desk staff. In that case, the staff person would be provided access to the custom setup option through Group Policy, and would be offered the ability to override the automatic computer name and default Active Directory location.

The custom setup option also gives an administrator or help desk professional the ability to prestage the client computer. Prestaging a client computer simply creates a corresponding computer account object within the Active Directory for that computer. Once the computer account has been prestaged, the administrator is assured that this is an authorized Known client computer that can be serviced by any available RIS server. Prestaging a computer account using the Client Installation wizard is done by entering all the information necessary to perform the installation, which results in the CAO being created, but canceling the CIW just prior to the actual OS installation starting.

Note: The simplest way to prestage a group of client computer accounts for use with Remote OS Installation is by using the VBScript provided by Microsoft to system vendors. The script uses a Microsoft Excel spreadsheet containing the required information to prestage client computers for use with RIS. When placing orders for computers that you want to prestage, contact your system vendor to request this script and a copy of the spreadsheet pre-filled with the GUIDs of the new systems you will be receiving.

Considerations:

  • If users are allowed to perform their own OS installations using Remote OS Installation, the custom setup option will not typically be used so that the standards defined for computer naming and location will always be followed. However, in cases where an IT or help desk professional must visit the end user, or perform a manual installation of the OS, the custom setup option can be used as appropriate.
  • Use custom setup if your company has a policy that requires that all computers are preinstalled with an OS prior to delivery to end users. The Remote OS Installation feature should provide the ability to avoid pre-installs, but if it is company policy to do so, the custom setup option is provided.

Using the Restart a Previous Setup Attempt Option

The option to restart a previous setup attempt is provided in the event that the installation of the OS fails for any reason. The Client Installation wizard can be customized to ask a series of questions about the specific OS being installed. For example, if an administrator wants to create a version of the Client Installation wizard that asks the user which type of protocols should be installed, which video resolution, and what the specific company name was, when restarting a failed OS setup attempt, the end user would not be asked these questions again. Rather, Setup would already have this information, and would simply restart the file copy operation and complete the OS installation.

Considerations:

  • Restarting a previous setup attempt does not restart the OS installation at the point where it failed. Rather, this option restarts the OS installation over from the beginning of setup.
  • This option may not be appropriate to offer to end users. This option will not attempt to fix any problems that occurred with the previous setup attempt and as such should be used as a Remote OS Installation troubleshooting option for IT or help desk staff.

Using the Maintenance and Troubleshooting Option

The Maintenance and Troubleshooting tool provides access to third party hardware and software vendor tools. These tools range from system BIOS flash updates and memory virus scanners, to a wide range of computer diagnostic tools that check for hardware related problems. These tools are available before installing and starting the operating system on the client computer.

If the options to display the Maintenance and Troubleshooting Tools menu is enabled by Group Policy, user access to individual tool images is controlled in the same way as operating system options, by setting specific end user permissions on the individual answer file (.sif) for that tool. For example, the Remote OS Installation administrator can allow end users access to only one computer diagnostic tool, yet provide help desk professionals with access to the entire suite of diagnostic tools. When the user calls a help desk professional for assistance, the professional can guide them through the diagnostic tool for retrieval of information necessary to diagnose the problem being encountered. If the help desk staff must visit the end user for further investigation, they simply log on to the Client Installation wizard and, based on their credentials, can access the tools they need to resolve the problem.

Consideration:

  • The maintenance and troubleshooting option may not be appropriate for end users. Make sure that if you allow access to this installation option, that you provide only those tools that cannot damage the computer or cause further problems.
  • See the For More Information section for details on vendors working on RIS-enabled maintenance and troubleshooting tools. If you do not see the vendor of a tool you use listed, contact the vendor directly.

摘要

The Remote OS Installation feature is one of the many features in the Windows 2000 Server operating system that helps reduce the costs associated with deploying a new version of an operating system throughout an enterprise. The Remote OS Installation feature provides an administrator with a number of options that both simplify and streamline the process of rolling out a new version of an operating system, and ultimately reduce the total cost of ownership.

For More Information

For the latest information on Windows 2000 Server, check out Microsoft TechNet or the Microsoft Windows 2000 Web site ( http://www.microsoft.com/technet/prodtechnol/windows2000serv/default.mspx ).

You can find the latest copy of the Remote OS Installation Walkthrough ( http://www.microsoft.com/windows2000/docs/RemoteOS.doc ), used to install, configure and use the Remote OS Installation feature on the Microsoft Windows 2000 Web site.

For information on the IntelliMirror Management features, and for a complete listing of the associated Walkthrough documents, please see Management Services ( http://www.microsoft.com/windows2000/technologies/management/default.asp ) on the Microsoft Windows 2000 Web site.

For more details on individual Remote OS Installation configuration settings, please see the Windows 2000 Documentation ( http://www.microsoft.com/technet/prodtechnol/windows2000serv/default.mspx ), Product Help, which can be found on the Windows 2000 Web site ( http://www.microsoft.com/technet/prodtechnol/windows2000serv/default.mspx ), and search for Remote Installation Services.

Several vendors have announced products or product plans for utilities that integrate with Remote OS Installation. For more details on tools compatible with the Maintenance and Troubleshooting option, search for integration papers on the Windows 2000 Web site under Management Services ( http://www.microsoft.com/windows2000/technologies/management/default.asp ).

Appendix A: Hardware Requirements

Remote Installation Server and Workstation Hardware Requirements

Server Hardware Requirements

  • Pentium or Pentium II 166 MHz (200 MHz or larger processor recommended).
  • 64 MB Ram minimum. If additional services such as Active Directory, DHCP, and DNS are installed, then the minimum amount of RAM required is128 MB.
  • 2 GB hard disk dedicated for the Remote Installation Service directory tree.
  • 10 or 100 mbps network adapter card (100mbps preferred)

Note: A partition separate from the system's boot partition is required to install the Remote Installation Services. To accommodate the operating system installation images, you may want to dedicate an entire hard disk specifically to the RIS directory tree.

Client Hardware Requirements

  • Pentium 166MHz or faster processor.
  • 32 MB Ram minimum.
  • 800 MB hard disk drive.
  • Supported PCI Plug and Play network adapter card. (See Appendix B for supported network cards for use with the RIS boot disk.)
  • Optional: PXE-based remote boot ROM version .99c or later.

Appendix B: Network Cards Supported by the RIS Boot Disk

The following is a list of network card models that are supported by the RIS boot disk. The boot disk generator tool is available within the \Admin\i386 Subdirectory under the \Remoteinstall directory and is called Rbfg.exe.

Network Cards Supported by RIS Boot Disk:

3 Com Network Adapters:

  • 3c900 (Combo and TP0)
  • 3c900B (Combo, FL, TPC, TP0)
  • 3c905 (T4 and TX)
  • 3c905B (Combo, TX, FX)

AMD Network Adapters:

  • AMD PCNet and Fast PC Net

Compaq Network Adapters:

  • Netflex 100 (NetIntelligent II)
  • Netflex 110 (NetIntelligent III)

Digital Equipment Corp (DEC) Network Adapters:

  • DE 450
  • DE 500

Hewlett Packard Network Adapters:

  • HP Deskdirect 10/100 TX

Intel Corporation Network Adapters:

  • Intel Pro 10+
  • Intel Pro 100+
  • Intel Pro 100B (including the E100 series)

SMC Network Adapters:

  • SMC 8432
  • SMC 9332
  • SMC 9432

Note: The RIS boot disk generator only supports PCI-based network cards (ISA, EISA, and Token Ring cards not supported).

Appendix C: Frequently Asked Questions

Question: How do I know I have the correct PXE ROM version?

Answer: When the Net PC or client computer containing a remote boot ROM starts, the PXE ROM message appears on the screen. You should see which version of the PXE ROM code is displayed during the boot sequence of the client computer. Windows 2000 RIS supports .99c or later PXE ROMs, except in very few situations that will require the .99L version. You may be required to obtain a newer version of the PXE-based ROM code from your OEM in the event you are not successful with the existing ROM version installed on a client computer.

Question: How do I know if the client computer has received an IP address and has contacted the RIS server?

Answer: When the client computer starts, you see the PXE boot ROM begin to load and initialize. The following sequence occurs with most PC98 and Net PCs, PXE ROM-based computers, and computers using the RIS boot disk:

Remote boot ROM load sequence:

Step 1: The client computer displays the message DHCP . This message indicates the client is requesting an IP address from the DHCP server. This may also indicate the client has obtained an IP address from DHCP and is awaiting a RIS server response. To verify if the client is receiving an IP Address, you can check the IP leases that have been granted on your DHCP server.

Troubleshooting: If the client does not get past the DHCP message it may mean the client is not receiving an IP address or that the BINL server is not responding, things to check are:

  • Is the DHCP server available and has the service started? DHCP and RIS servers must be authorized in Active Directory in order for their services to start. Check to ensure the service has started and other non-remote boot-enabled clients are receiving IP addresses on this segment.
  • Does the DHCP server have a defined IP address scope and has it been activated?
  • Is there a router between the client and the DHCP server that is not allowing DHCP packets through?
  • Are there any error messages in the event log under the System Log for DHCP?
  • Can other client computers—that is non-remote boot-enabled clients—receive an IP address on this network segment?

Step 2: When the client receives an IP address from the DHCP server, the message may change to BINL . This indicates the client successfully leased an IP address and is now waiting to contact the RIS Server. The client computer will eventually timeout, and post the error message “No Bootfile received from DHCP, BINL, or Bootp”

Troubleshooting: If the client does not get past the BINL message it means the client is not receiving a response from the RIS server. Things to check are:

  • Is the RIS server available and has the BINL (BINLSVC) service started? RIS servers MUST be authorized to start on the network. Ensure the RIS servers are authorized to run on the network. Use the DHCPMGMT.MSC snap-in to authorize both DHCP and RIS servers within the Active Directory.
  • Are other remote boot-enabled clients receiving the Client Installation wizard? If so, this may indicate this client computer is not supported or is having remote boot ROM-related problems. Check the version of the PXE ROM on the client computer. Also check in Active Directory to see if the administrator has prestaged this client computer to a specific RIS server that may be offline or unavailable to the client computer.
  • Is there a router between the client and the RIS server that is not allowing the DHCP-based requests/responses through? The RIS server communicates using the DHCP packet type during the initial service request/response sequence. You may need to configure the router to forward the DHCP packets.
  • Are there any error messages in the event log under the System or Application logs specific to RIS (BINLSVC), DNS, or the Active Directory?

Step 3: The client will then change to TFTP or will prompt the user to press the function key, F12 . This means that the client has contacted the RIS server and is waiting to TFTP the first image file, which is the Client Installation wizard. You may not see the BINL and TFTP message, because on some computers this sequence simply flashes by too fast.

Troubleshooting:

If the client computer does not get a response from the RIS server, the client computer will timeout, and displays an error message saying that it did not receive a file from DHCP, BINL, or TFTP. In this case, the RIS server did not answer the client computer. Things to check are:

  • Stop and restart BINLSVC on the RIS server. On the Start menu, click Run , and then type CMD . In the CMD window, type:
    Net Stop BINLSVC Net Start BINLSVC 
  • Check the RIS server properties to ensure that the Respond to Known client computers option is checked, and that the Do not respond to Unknown client computers is not checked, unless you have prestaged the client computers in the Active Directory prior to starting the client computer.
  • Check in the event log to ensure no errors relating to DHCP, DNS, RIS (BINLSVC), and/or the Active Directory exist.

If the client computer does not receive an answer after attempting to stop and restart the service, and after checking the properties of the RIS server to ensure the correct settings have been set, you should check the Event Log on the RIS server for any errors relating to DHCP, DNS, or RIS (BINLSVC). If possible, capture the network activity between the server and the client with a network sniffer, and you can provide the Microsoft Product Support Services with this information.

Step 4: At this point, the client should have downloaded the Client Installation wizard, and been greeted with the Welcome page.

Question: Does Remote OS Installation support the older remote boot protocol Remote Program Load (RPL)-based ROMs?

Answer: The Remote OS Installation feature uses the new PXE DHCP-based remote boot ROMs. As such, there is no support in the Windows 2000 operating system for the older RPL-based remote boot.

Question: Does Remote OS Installation support remote installation of Windows 2000 Server CD-based or RIPrep OS images?

Answer: No. Remote OS Installation does not support remotely installing Windows 2000 Server.

Question: Does Remote OS Installation support remotely installing an OS image (RIPrep or CD Based) on laptop computers?

Answer: Yes and No. Remote OS Installation has been tested with laptop computers in docking stations that support the required PXE ROM code, and with laptop computers in docking stations that contain NICs supported by RIS boot floppy. The systems must be located within the docking station with the network cable plugged into the network adapter located with the docking station. The Toshiba Protégé 7010CT and Tecra 8000 are examples of laptops that support the PXE boot ROM when used with the Toshiba NetDock (docking station). In order for these systems to function with RIS, they require the 99L or later version of the PXE ROM code for the specific network card located within the NetDock.

RIS does not support laptop computers that contain PC Card or PCMCIA network cards.

Question: Is the pre-boot portion of the PXE remote boot ROM secure?

Answer: No. The entire ROM sequence and operating system installation/replication is not secure with regard to packet type encryption, client/server spoofing, or wire sniffer based mechanisms. As such, use caution when using Remote OS Installation on your corporate network. Ensure that you only allow authorized RIS servers on your network, and that the number of administrators allowed to install and/or configure RIS servers is controlled.

Question: Can RIPrep-based OS images be replicated to alternate media such as DVD, CD, and/or Zip drives?

Answer: No. In a Windows 2000-based system, you can only replicate the source image to a single available RIS server on the network.

Question: Does Remote OS Installation preserve the file attributes and security settings defined on the source computer when using the RIPrep image feature?

Answer: Yes. The file attributes and security settings that are defined on the source computer will be preserved on the destination computer that installs that image. However, be aware that the RIPrep feature does not support the encrypted file system if enabled and used on the source client computer.

Question: Does the RIPrep feature support different hardware between the source computer used to create the RIPrep-based OS image and the destination computer that will install the image?

Answer: Yes. The hardware between the source computer and the destination computer can be different. The one exception to this is the Hardware Abstraction layer (HAL) driver used. For example, if the source computer has Advanced Configuration Power Interface (ACPI) support it will use a specific ACPI HAL driver. If you attempt to install this RIPrep image on a computer without ACPI support, it will fail.

Question: Does the RIPrep wizard support multiple disks and or multiple partitions on a given client computer?

Answer: No. The RIPrep utility only supports a single disk with a single partition (C:\ Drive) in this release of Remote OS Installation.

Question: How does the RIPrep wizard deal with disks that differ in size between the source computer used to create the image and the destination computer that will receive it?

Answer: The destination computer's disk size must be equal to or larger than the source disk used to create the image. For example, if the source computer has a 1-gigabyte (GB) hard disk, when that image is installed on a destination computer that has a larger (for example 2-GB)hard disk drive, the full 2-GB drive will be partitioned and formatted prior to installing the OS image. You can also configure support for formatting the destination computer's hard disk to the same physical size of the source computer. For more information, see the online documentation for on the UseWholeDisk= parameter.

Question: How do I replicate all of the OS images currently located on one of my RIS servers to other RIS servers on the network for consistency across all client installations?

Answer: The Remote OS Installation feature does not provide a mechanism for replication of OS images from one RIS server to another. There are several mechanisms that can be employed to solve this problem. Use the strong replication features of the Systems Management Server product. This product provides for scheduled replication, compression, and slow link features. You can also employ third party vendor solutions for OS image replication. Ensure that the replication mechanism supports maintaining the file attributes and security settings of the source images.

Question: Can I have a RIS server and a third party remote boot server on the network at the same time? f so, what are the implications?

Answer: Yes, you can have multiple vendor Remote Boot/Installation (RB/RI) servers on one physical network. It is important to understand that currently the remote boot PXE ROM code does not know the difference between different vendor's RB/RI servers. Therefore, when a remote boot-enabled client computer starts and requests the IP address of a RB/RI server, all of the available servers will respond to that client. Thus, the client has no way to ensure it is serviced by a specific RB/RI server. Using Remote OS Installation, an administrator can prestage client computers in the Active Directory, and mandate which RIS server will service that client. By configuring the RIS server to only answer known (prestaged) client computers, the administrator is assured that the client will be serviced by the correct RIS server. Not all RB/RI vendors have implemented the ability to ignore service requests, and therefore, you may need to segment off the specific vendors servers on the network so that clients are not answered by these vendors RB/RI servers.

Question: Can I remotely manage the RIS servers from Windows 2000 Professional-based workstations on my network?

Answer: Yes. If you are an administrator in the domain, and you have installed the Administrator Tools package on your Windows 2000 Professional-based workstation, you can administer the majority of the RIS configuration settings. There are some items that you cannot manage, for example, you cannot remotely add additional operating system images to RIS servers from computers running Windows 2000 Professional.

Question: Can I add additional network adapter cards to the RIS boot disk?

Answer: No. The Rbfg.exe utility is hard coded with regard to the number of supported network card adapters for this release of Remote OS Installation. Updates to the Rbfg.exe utility will be made available through normal distribution channels such as the Microsoft Windows Web site ( http://www.microsoft.com/windows ), Windows Update, and future Service and Feature Pack updates.

Question: Can I use Active Directory object attributes to create a naming format for use with the Remote OS Installation automatic computer-naming feature?

Answer: No. Currently the existing attributes supported with the automatic computer-naming feature use the Active Directory service. However, not all of the Active Directory object attributes are currently supported.

Question: Where do I look on the client computer to find the GUID/UUID for prestaging clients in Active Directory for use with Remote OS Installation?

Answer: The GUID/UUID for client computers that are PC98 or Net PC compliant can in most cases be found in the system BIOS of the computer. Microsoft encourages OEMs to ship either a floppy disk containing a comma separated file or spreadsheet that contains a mapping of computer system serial number to GUID/UUID. This allows you to script prestaging client computers into the Active Directory directory service. Microsoft also encourages the OEMs to post the GUID/UUID on the outside of the computer case for easy identification and prestaging of computer accounts. If the GUID is not found in the above-mentioned locations, you can use a network sniffer to analyze the network traffic of the client, locate the client's DHCP discover packet, and within that field will be the computer's 32 byte GUID/UUID.

  • Share Save 171 16 in Remote Operating System Installation

Tags: , , ,

留下回复