ConfigMgr 2609 Upgrade Sonrası Reporting Services Point Hatası ve Çözümü

Configuration Manager 2609 güncellemesinden sonra, site sunucusundan ayrı bir sunucuda çalışan Reporting Services Point (RSP) rolü sürekli hata vermeye başlıyor. Sebep, RSP kurulum paketinde bazı DLL dosyalarının eksik olması. Resmi düzeltme yayınlanana kadar uygulanabilecek geçici çözüm, bu DLL’leri site sunucusundan RSP sunucusuna kopyalamak.

Bu yazıda sorunu nasıl tespit ettiğimizi, hangi kontrolleri yaptığımızı ve geri dönüş planıyla birlikte çözümü adım adım anlatıyorum.

Belirtiler

Güncellemeden sonra RSP sunucusundaki srsrp.log dosyasına her dakika şu satırlar düşüyor:

(!) InitializeSrsWhenNeeded error = The system cannot find the file specified.
Failures reported during periodic health check by the SRS Server (Server FQDN).

• Component Status: Monitoring > System Status > Component Status altında SMS_SRS_REPORTING_POINT bileşeni kritik duruma geçiyor.
  
• Rolü yeniden kurmak işe yaramıyor: Rolü kaldırıp tekrar ekleyince bileşen kısa süre yeşil oluyor, yaklaşık bir saat sonra tekrar kırmızıya dönüyor.
  
• Raporlar çalışmaya devam ediyor: Report Server URL’si ve raporlar normal açılıyor. Bu yüzden sorun ilk bakışta gözden kaçabiliyor.

Neden

2609 ile birlikte RSP bileşeni yeni DLL’lere bağımlı hale geliyor. Ancak bu DLL’ler RSP’nin MSI paketine eklenmemiş. Uzak sunucudaki smsexec.exe bu dosyaları kendi klasöründe bulamıyor ve SSRS başlatma adımı her denemede hata veriyor.

Sorun yalnızca RSP’nin site sunucusundan ayrı bir sunucuda (çoğu zaman SQL/SSRS sunucusunda) kurulu olduğu ortamlarda görülüyor. RSP site sunucusunun kendisindeyse bu DLL’ler zaten bin\x64 klasöründe bulunduğu için hata oluşmuyor.

İlk gözlemlerde System.Runtime.CompilerServices.Unsafe.dll dosyasının eksik olduğu fark edildi. Bu dosyayı tek başına kopyalamak çoğu ortamda yetmedi. Process Monitor ile yapılan incelemelerde smsexec.exe’nin 30’dan fazla DLL’i bulamadığı görüldü.

Ön kontroller

Çözümü uygulamadan önce RSP’nin gerçekten uzak bir sunucuda olduğunu ve kaynak klasörün doğru olduğunu doğrulayın. Aşağıdaki örneklerde sunucu adları temsilidir.

1. RSP’nin hangi sunucuda olduğunu bulun. ConfigMgr konsolundan açtığınız PowerShell’de şu komutu çalıştırın:
   
   Get-CMSiteRole -RoleName “SMS SRS Reporting Point” | Select NetworkOSPath, SiteCode
   
2. RSP sunucusunda SMS_EXECUTIVE servisini ve klasörünü kontrol edin. Servis yoksa rol o sunucuda kurulu değildir ya da kurulum tamamlanmamıştır. Sadece SMS_SITE_SQL_BACKUP_* servisini görmeniz yeterli değil, bu servis yalnızca veritabanı yedekleme için kurulur.
   
   Get-WmiObject win32_service | Where-Object Name -eq ‘SMS_EXECUTIVE’ | Select PathName
   
   Bizim ortamımızda servis yoktu. Rolü konsoldan SQL sunucusuna ekledikten sonra servis
   
   D:\SMS\bin\x64\smsexec.exe yolunda oluştu.
   
3. Site sunucusundaki kaynak klasörü doğrulayın. Kurulum klasörünün adı kurulum medyasıyla karışabilir. Gerçek kurulum klasöründe smsexec.exe, Logs ve inboxes bulunur. Üç komut da True dönmeli:
   
   $Base = “\\SITESERVER.contoso.local\d$\Microsoft Configuration Manager” Test-Path “$Base\bin\X64\smsexec.exe” Test-Path “$Base\Logs” Test-Path “$Base\inboxes”

Çözüm adımları

Tüm adımları RSP sunucusunda, PowerShell’i yönetici olarak açarak çalıştırın.

1. Hedef klasörü yedekleyin. Script mevcut dosyaların üzerine yazmaz, ama yedeği almak birkaç saniye sürer ve geri dönüşü kolaylaştırır.
   
   $Backup = “D:\SMS_bin_x64_yedek_$(Get-Date -Format ‘yyyyMMdd_HHmm’)” Copy-Item “D:\SMS\bin\x64” -Destination $Backup -Recurse
   
2. Eksik DLL’leri kopyalayın. Script, site sunucusundaki bin\x64 klasöründe olup RSP sunucusunda olmayan tüm DLL’leri kopyalar. Kopyaladığı her dosyanın adını bir listeye yazar.
   
   $Source = “\\SITESERVER.contoso.local\d$\Microsoft Configuration Manager\bin\X64”
   $Target = “D:\SMS\bin\x64” $LogFile = “C:\Temp\2609_kopyalanan_dll.txt”
   
   if (-not (Test-Path $Source)) { Write-Warning “Kaynak bulunamadı: $Source”; return } New-Item -ItemType Directory -Path C:\Temp -Force | Out-Null Stop-Service SMS_EXECUTIVE -Force Get-ChildItem $Source -Filter *.dll | Where-Object { -not (Test-Path (Join-Path $Target $_.Name)) } | ForEach-Object { Copy-Item $_.FullName -Destination $Target Add-Content $LogFile $_.Name }
   
   Start-Service SMS_EXECUTIVE Write-Host “Kopyalanan DLL sayısı: $((Get-Content $LogFile -ErrorAction SilentlyContinue).Count)”
   
3. Servisi kontrol edin. Script SMS_EXECUTIVE servisini kendisi başlatır. Kopyalamayı elle yaptıysanız servisi
   
   Start-Service SMS_EXECUTIVE komutuyla başlatın.

Gerekli DLL’leri tek tek bulmak mümkün ama zahmetli. Process Monitor’da smsexec.exe için NAME NOT FOUND sonuçlarını filtrelemek gerekiyor. Ayrıca bazı dosyaların site sunucusunda bile bulunmadığı görüldü. Bu yüzden toplulukta en çok tercih edilen yol tüm DLL’leri üzerine yazmadan kopyalamak oldu.

Doğrulama ve geri alma

Çözüm işe yaradıysa srsrp.log dosyasında servisin yeniden başladığını ve SSRS yapılandırma adımlarının hatasız tamamlandığını görürsünüz. Logu canlı izlemek için:

Get-Content D:\SMS\Logs\srsrp.log -Tail 30 -Wait

• Log: InitializeSrsWhenNeeded error satırı birkaç dakika boyunca tekrar etmemeli.
• Component Status: SMS_SRS_REPORTING_POINT 1-2 saat sonra da yeşil kalmalı. Rol yeniden kurulduğunda bileşen kısa süre yeşil göründüğü için bu bekleme önemli.

Geri dönmeniz gerekirse ya da Microsoft resmi düzeltmeyi yayınladığında, eklenen DLL’leri listeye göre silebilirsiniz:

Stop-Service SMS_EXECUTIVE -Force
Get-Content C:\Temp\2609_kopyalanan_dll.txt | ForEach-Object { Remove-Item "D:\SMS\bin\x64\$_" -Force }
Start-Service SMS_EXECUTIVE

Liste oluşmadıysa (örneğin kopyalamayı elle yaptıysanız) klasörü 1. adımda aldığınız yedekten geri yükleyin.

Diğer 2609 sorunları ve sonuç

2609’a geçmeden önce toplulukta bildirilen diğer sorunları da göz önünde bulundurun:

Sonuç olarak, uzak RSP kullanan ortamlarda 2609 sonrası srsrp.log hatası DLL kopyalama ile giderilebiliyor. Bu işlem geçici bir çözüm. Microsoft resmi düzeltmeyi yayınladığında kopyalanan DLL’lerin temizlenmesi gerekir. Güncellemeyi üretime almadan önce, üretimle aynı rol dağılımına sahip bir test ortamında denemek bu tür sürprizleri önler.