SCCM 循環 OSD 任務序列
更新：
下面的問題是在下面接受的答案的幫助下解決的。但是，問題的實際原因是由於錯誤。我在下面為這個問題添加了另一個答案，其中包含此錯誤的詳細資訊以及已發布的修補程序解決方案的詳細資訊。
問題：
在我的組織中，我們有一個必須每週重新映像的電腦實驗室。我們目前正在通過 SCCM 2007 執行此操作。目前，這是通過每週為有效的 OSD 任務序列 (TS) 創建一個新的強制廣告來完成的。但是，我想通過在定期計劃中設置一個廣告來做到這一點。
為了讓 TS 在一台機器上重複執行，您必須啟用廣告選項“始終重新執行程序”，否則 TS 只會執行一次。
我遇到的問題是，在執行機器的重新映像時，會安裝一個新的客戶端，因此會創建一個新的 GUID。這意味著我必須提供一些自動方法來將該新客戶端 GUID 讀取到通告重複 TS 的集合中。當然，由於客戶端有一個新的 GUID，這意味著 SCCM 認為 TS 尚未在這台機器上執行，並在它被讀取到集合後立即開始重新映像，從而有效地將機器置於無限重建循環中。
我考慮過簡單地將客戶端建構到映像中，以便它通過重新映像維護相同的 GUID，但這種方法還有其他問題。
有關如何設置每週重新映像機器一次的重複 TS 的任何建議？
編輯：
為了澄清一些事情，我將更好地解釋這種情況：
- 我嘗試執行的 OSD 任務序列大約需要一個半小時才能完成，這將發生在凌晨 3 點左右。作業系統部署完成後，需要執行另一個 TS 以安裝最後一個程序，由於某些程序限制，該程序必須通過單獨的 TS 完成。
- 其次，當我提到上面的 GUID 時，我實際上指的是分配給新安裝的 ConfigMgr 客戶端的 SMS GUID。當然，還有其他原因會創建新的 SMS GUID，但在這種情況下這些都不是問題。
解決方案詳情：
根據下面 newmanth 的建議，我執行了以下操作來解決此問題：
- 對於 OSD 任務序列和相關廣告，我設置了以下設置：
- 最大允許執行時間（分鐘）：90（TS 屬性 -> 高級）
- 程序重新執行行為：始終重新執行程序（廣告屬性 -> 計劃）
- 廣告時間表：凌晨 3 點，每週重複一次
- 對於包含相關電腦的集合，我使用了以下設置：
- 維護時段持續時間：凌晨 3 點 - 凌晨 4 點 35 分，每週重複一次。
我還選中了“此計劃僅適用於作業系統部署任務序列”選項。這允許我在維護視窗之外執行上面提到的第二個 TS，但可以防止在將客戶端重新添加到集合後立即重新生成。
維護視窗必須大於或等於 TS 或程序的最大執行時間加上廣告程序客戶端代理倒計時持續時間（我的設置為 5 分鐘）。由於我的 TS 的最大執行時間為 90 分鐘，因此我必須將視窗設置為 95 分鐘。
- 集合會員更新時間表：凌晨 4:45，每天重複。
重建完成，維護視窗於凌晨 4:35 關閉。我現在等待 10 分鐘以進行良好的測量並安排集合成員更新，以便重新添加新安裝的客戶端。我可以在重建的同一天每週進行一次，但出於其他原因我每天都這樣做。
根據您的集合添加新客戶端成員的方式，您可能還需要安排您的發現方法在此更新發生之前執行。例如，如果您的集合基於 Active Directory 組添加新的客戶端成員，那麼您將需要首先執行相應的 Active Directory 發現方法，以便新創建的客戶端記錄填充其相應的 Active Directory 資訊。否則，新客戶記錄將沒有任何 AD 組資訊，並且不會添加到集合中。
使用上面的設置，重建過程應該是這樣的：
- 維護視窗在凌晨 3 點打開。
- OSD 任務序列從凌晨 3 點開始。
- OSD 任務序列大約在 1 個半小時後（凌晨 4:30）結束。
- 維護視窗在凌晨 4:35 關閉，防止立即重複 TS。
- 凌晨 4 點 45 分收集會員更新，重新添加新安裝的客戶端。
- 在客戶端策略檢索之後，上面提到的第二個 TS 執行。
- 步驟 1-6 應在下周自動重複。
我認為您可以通過對相關集合設置每週一次的維護視窗以及始終重新執行廣告來實現此目的。確保視窗足夠長以允許廣告執行一次。這將阻止後續執行，直到維護視窗再次出現。技術網：http ://technet.microsoft.com/en-us/library/bb632801.aspx
這個問題的公認答案確實幫助我為所描述的情況設置了一個工作解決方案，並且在我附加的解決方案中使用上述設置將起作用。然而，事實證明這不是必需的，因為我的問題的核心真正問題是由於 SCCM 2007 的錯誤，該錯誤已被修復。
KB977203
http://support.microsoft.com/kb/977203
不要讓那篇知識庫文章的標題欺騙您，因為這個特定的錯誤在 SCCM 2007 中的影響比它最初指出的要多。
注意：雖然此修補程序已被其他幾個修補程序取代，但仍需要此修補程序附帶的 CCMCertFix.exe 實用程序，並且僅此特定修補程序附帶。
這是KB2028442的摘錄，它解釋了正在發生的事情：
該問題是由 ConfigMgr 2007 客戶端在混合模式下自動生成的自簽名證書引起的。如果生成證書時客戶端 PC 上未安裝KB977203 ConfigMgr 2007 客戶端更新檔，則證書將在友好名稱中嵌入 NULL 字元，如KB974571中所述。
當 OSD 任務序列用於刷新 PC 時，ConfigMgr 2007 客戶端證書會從舊的 Windows 作業系統遷移到新的 Windows 作業系統。如果原始 Windows 作業系統上的 ConfigMgr 2007 客戶端證書在友好名稱中嵌入了 NULL 字元，如KB974571中所述，並且如果KB974571作為任務序列部署的參考映像的一部分安裝，則當新的 Windows 作業系統安裝後，KB974571將阻止遷移友好名稱中嵌入了 NULL 字元的 ConfigMgr 2007 客戶端證書。這將導致 ConfigMgr 2007 客戶端無法安裝。
現在在我的情況下，客戶端安裝得很好，但由於這個 NULL 字元，證書仍然沒有正確遷移，因此它只是在 SCCM 中創建具有不同 SMS GUID 的新客戶端記錄。因此，每次我重建客戶端電腦時，我都必須執行集合成員身份更新以將客戶端重新添加到集合中。當然，由於 ConfigMgr 認為這是一台新的客戶端機器，它沒有記錄它曾經執行過 OSD 任務序列，因此立即再次執行它，有效地將其置於無限重建循環中。
將此修復應用到客戶端（我實際上使用取代它的KB977384修復）並在 OSD 任務序列執行之前執行 CCMCertFix 實用程序後，我將不再為最近重建的客戶端獲取新的 SMS GUID，因此不再具有將客戶端重新添加到集合中，OSD TS 現在會看到它剛剛在客戶端上成功執行，並且不會再次嘗試重建它。
CCMCertFix.exe
CCMCertFix.exe 實用程序必須在 TS 啟動之前執行。這意味著它不會作為您的 TS 中的一個步驟。為此，您必須轉到 TS 的屬性，並在“高級”選項卡上選擇“首先執行另一個程序”。您還需要設置“始終首先執行此程序”選項。
要獲取 CCMCertFix.exe 實用程序，您必須在伺服器上安裝KB977203修補程序，然後系統會提示您為其自動創建一個包。使用創建的包，添加一個只需執行 CCMCertFix.exe 實用程序的新程序。
對我來說，我首先安裝了取代此修補程序的KB977384並不重要。它仍然成功執行並為我創建了包。我也不需要將該修補程序部署到客戶端，因為我已經應用了KB977384修補程序。