SCCM Software Update Point (SUP) Geçişi Sonrası 0x87D00692 Hatası ve Çözümü

Giriş

Microsoft Configuration Manager (SCCM/MECM), istemci ve sunucu güncellemelerini merkezi olarak yönetebilmek için Software Update Point (SUP) rolünü kullanır. SUP rolü, Windows Server Update Services (WSUS) ile birlikte çalışarak Microsoft Update kataloglarını senkronize eder ve Configuration Manager istemcilerinin hangi güncellemelere ihtiyaç duyduğunu belirlemesini sağlar.

Kurumsal ortamlarda zaman zaman eski Software Update Point sunucusunun değiştirilmesi veya yeni bir SUP sunucusuna geçiş yapılması gerekebilir. Bu geçiş işlemleri genellikle Configuration Manager tarafında tamamlandıktan sonra istemcilerin otomatik olarak yeni Software Update Point’i kullanacağı düşünülür. Ancak istemci tarafında daha önce uygulanmış Windows Update Group Policy ayarları bu süreci tamamen etkileyebilir.

Bu makalede, eski Software Update Point sunucusundan yeni bir SUP sunucusuna geçiş sonrasında yaşanan 0x87D00692 hatasının neden oluştuğunu, problemin nasıl analiz edildiğini ve uygulanan çözümün teknik ayrıntılarını gerçek bir vaka üzerinden inceleyeceğiz.

Ortam

İncelenen ortamda mevcut Software Update Point sunucusu (SCCM01) devreden çıkarılmış ve yerine yeni bir Software Update Point (SCCM) kurulmuştur.

Yeni SUP üzerinde;

• Software Update Point rolü kurulmuş,
• WSUS senkronizasyonu başarıyla tamamlanmış,
• Güncelleme paketleri Distribution Point’lere dağıtılmış,
• Software Update Group oluşturularak ilgili sunucu koleksiyonlarına deploy edilmiştir.

Configuration Manager tarafında herhangi bir hata bulunmamasına rağmen istemciler güncellemeleri almıyordu.

İlk bakışta sorun Distribution Point veya WSUS senkronizasyonundan kaynaklanıyor gibi görünse de yapılan incelemelerde altyapının sağlıklı çalıştığı görüldü.

Belirtiler

Sorun yaşayan istemcilerde aşağıdaki belirtiler gözlemlendi.

• Software Center içerisinde güncellemeler görünmüyordu.
• Required Update sayısı 0 olarak görünüyordu.
• Bazı istemciler Past Due durumundaydı.
• Deployment başarılı olmasına rağmen güncellemeler indirilmiyordu.
• UpdatesDeployment.log içerisinde aşağıdaki hata görülüyordu.

Job error (0x87D00692) received for assignment Updates will not be made available

İlk değerlendirmede sorunun Distribution Point veya Software Update Point yapılandırmasından kaynaklandığı düşünüldü. Ancak istemci logları farklı bir durumu işaret ediyordu.

Log Analizi

Configuration Manager istemci logları incelendiğinde ilk dikkat çeken kayıt WUAHandler.log dosyasında görüldü.

Group policy settings were overwritten by a higher authority.

Bu mesaj, Windows Update Agent’ın Configuration Manager tarafından yapılandırılmasına rağmen aynı ayarın daha yüksek öncelikli bir kaynak tarafından değiştirildiğini göstermektedir. Configuration Manager istemcisi yeni Software Update Point bilgisini istemciye yazıyor, ancak kısa süre sonra Domain Group Policy aynı ayarı tekrar eski değere çeviriyordu.

Bu nedenle istemci hiçbir zaman yeni SUP üzerinden tarama yapamıyordu. Problemin gerçekten Group Policy kaynaklı olup olmadığını doğrulamak amacıyla istemci üzerinde Resultant Set of Policy (RSOP) aracı kullanıldı. Specify intranet Microsoft update service location ilkesinin etkin olduğu görüldü.

Bu politika aşağıdaki ayarları istemciye uyguluyordu.

Ancak Configuration Manager istemcisi artık yeni Software Update Point olan; http://SCCM.kayasystem.local:8530 adresini kullanması gerekiyordu. Dolayısıyla istemci üzerinde iki farklı mekanizma aynı Windows Update yapılandırmasını yönetmeye çalışıyordu.

Configuration Manager istemcisi Software Update Point bilgisini Windows Update Agent üzerine otomatik olarak yazar.

Ancak aşağıdaki Group Policy etkin olduğunda Windows Update Agent bu bilgiyi Configuration Manager’dan değil Domain Group Policy’den alır.

• Computer Configuration
• Administrative Templates
• Windows Components
• Windows Update
• Specify intranet Microsoft update service location

Bu politika istemci üzerinde aşağıdaki registry anahtarlarını oluşturur. HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate Özellikle aşağıdaki değerler Windows Update Agent tarafından doğrudan kullanılır.

• WUServer
• WUStatusServer
• UseWUServer

Bizim senaryomuzda bu registry anahtarları hâlâ eski Software Update Point sunucusunu gösteriyordu.

Sonuç olarak Configuration Manager yeni SUP bilgisini istemciye gönderse bile Group Policy her yenilendiğinde registry tekrar eski sunucuyu gösterecek şekilde güncelleniyordu.

Çözüm

İlk olarak eski Software Update Point adresini içeren Group Policy istemcilerden kaldırıldı. Sonrasında Configuration Manager istemcisi üzerinde sırasıyla;

• Machine Policy Retrieval & Evaluation Cycle
• Software Updates Scan Cycle
• Software Updates Deployment Evaluation Cycle

çalıştırıldı. Bu işlemler sonrasında WUAHandler.log yeniden incelendiğinde istemcinin artık yeni Software Update Point adresini kullandığı doğrulandı.

Ardından istemciler eksik güncellemeleri algılamaya başladı ve Software Center içerisinde Required Updates listelenmeye başladı.

Çözüm Sonrası Gözlemler

Group Policy kaldırıldıktan sonra istemciler yeni Software Update Point üzerinden güncelleme taraması gerçekleştirdi. Deployment’lar yeniden değerlendirildi. Güncelleme paketleri Distribution Point üzerinden başarıyla indirildi. Kurulum işlemleri sorunsuz şekilde tamamlandı.

Bazı istemciler kısa süreliğine Past Due durumunda görünmeye devam etti. Bunun nedeni istemcilerin deployment deadline’ını, yanlış Software Update Point kullandıkları dönemde kaçırmış olmalarıydı. Güncellemeler tamamlanıp istemciler yeniden başlatıldıktan sonra Compliance bilgileri güncellendi ve istemciler normal durumuna döndü.

Sonuç

Software Update Point değişiklikleri sonrasında yaşanan güncelleme problemleri her zaman SCCM altyapısından kaynaklanmayabilir. Özellikle daha önce WSUS veya eski bir Software Update Point kullanılmış ortamlarda, Windows Update yapılandırmasını yöneten Group Policy ayarları istemcilerin yeni SUP’a geçmesini engelleyebilir.

Bu vaka çalışmasında görüldüğü gibi Configuration Manager tarafında tüm bileşenler sağlıklı olmasına rağmen tek bir Group Policy ayarı istemcilerin eski Software Update Point’e yönlenmesine neden olmuş ve bunun sonucunda Software Update Scan, Compliance değerlendirmesi ve güncelleme dağıtımı başarısız olmuştur.

Bu nedenle Software Update Point geçişleri sonrasında yalnızca SCCM yapılandırmalarının değil, istemcilere uygulanan Windows Update Group Policy ayarlarının da mutlaka kontrol edilmesi önerilir. Özellikle Specify intranet Microsoft update service location ilkesinin eski bir SUP veya WSUS sunucusunu göstermediğinden emin olunması, benzer problemlerin yaşanmasını önleyecek en önemli kontrollerden biridir.

Bu bilgilerin faydalı olması dileğiyle…