SCCM 2509 Reporting Services-Punkt Installation Error

Fehlerbild

Bei der Installation bzw. Neuinstallation des Microsoft Configuration Manager Reporting Services Point (SRSRP) wurde die Rolle durch MCM wiederholt als fehlerhaft erkannt. Obwohl die Installation von srsrp.msi laut srsrpsetup.log mit Return Code 0 erfolgreich abgeschlossen wurde, scheiterte die anschließende Registrierung der SRSRP-Komponente.

Typisches Fehlerbild:

Installing ...\srsrp.msi SRSRPINSTALLDIR="D:\SMS_SRSRP"

srsrp.msi exited with return code: 0

Installation was successful.

Cannot register D:\SMS_SRSRP\srsserver.dll, it doesn't exist

Cannot register SRSRP interop DLL D:\SMS_SRSRP\srsserver.dll. Installation cannot continue.

Fatal MSI Error - srsrp.msi could not be installed.

Auffällig war eine Inkonsistenz zwischen dem von MCM erwarteten Installationsverzeichnis und dem durch Windows Installer verwendeten bzw. aus einer vorherigen Installation bekannten Pfad.

Ursache

Die Analyse ergab, dass nach einer vorherigen Installation bzw. fehlgeschlagenen Deinstallation des Reporting Services Point noch eine Windows-Installer-Registrierung des Pakets „ConfigMgr Reporting Services Point“ vorhanden war.

Das MSI-Logging zeigte unter anderem:

Product registered: entering maintenance mode

ProductState = 5

CcmSwitchToRepairMode

REINSTALL = ALL

Damit wurde srsrp.msi von Windows Installer nicht als vollständige Neuinstallation behandelt, sondern als Maintenance-/Repair-Vorgang eines bereits registrierten Produkts. In diesem Zustand konnten alte Installationsinformationen, insbesondere die bisherige Verzeichniszuordnung, weiterverwendet werden. Dies führte letztlich dazu, dass MCM srsserver.dll in einem anderen Verzeichnis erwartete, als die MSI-Installation verwendete.  

Fehlerbehebung

Zur Bereinigung wurde folgende Reihenfolge durchgeführt:

1. Die MCM-Rolle Reporting Services Point regulär über die MCM-Konsole entfernt.
2. Mit einem PowerShell-Skript wurde das verbliebene MSI-Paket „ConfigMgr Reporting Services Point“ ermittelt und dessen ProductCode dokumentiert.

$Installer = New-Object -ComObject WindowsInstaller.Installer$Installer.Products() | ForEach-Object {
    $ProductCode = $_
    try {
        $ProductName = $Installer.ProductInfo($ProductCode, 'ProductName')
        if ($ProductName -like '*ConfigMgr*Reporting*Services*Point*') {
            [PSCustomObject]@{
                ProductName = $ProductName
                ProductCode = $ProductCode
                Version     = $Installer.ProductInfo($ProductCode, 'VersionString')
                LocalPackage = $Installer.ProductInfo($ProductCode, 'LocalPackage')
            }
        }
    }
    catch {
        # Nicht lesbare MSI-Produkte überspringen
    }
} | Format-List

3. Danach wurde das weiterhin registrierte MSI-Paket anhand des zuvor ermittelten ProductCodes explizit über Windows Installer deinstalliert.

msiexec.exe /x {Productcode} /L*v C:\Temp\SRSRP_Uninstall.log

4. Nach der Bereinigung wurde der Reporting Services Point erneut über MCM installiert.

Nach dieser Vorgehensweise wurde die Rolle vollständig und fehlerfrei installiert. Die zuvor wiederkehrenden Installationsversuche und Fehler bei der Registrierung von srsserver.dll traten nicht mehr auf.

Fazit

Bei SRSRP-Installationsfehlern, bei denen srsrp.msi erfolgreich mit Return Code 0 endet, anschließend jedoch srsserver.dll nicht gefunden bzw. registriert werden kann, sollte neben der MCM-Rollenkonfiguration auch der Windows-Installer-Status des „ConfigMgr Reporting Services Point“ geprüft werden.

Eine verbliebene MSI-Registrierung kann dazu führen, dass eine vermeintliche Neuinstallation als Repair/Reinstall einer alten Installation ausgeführt wird. Als funktionierende Lösung hat sich die Reihenfolge bestätigt.

• MCM-Rolle entfernen
• MSI-Produkt identifizieren
• verbliebenes MSI-Paket deinstallieren
• MCM-Rolle neu installieren

Hallo VP

zuerst besten Dank für deinen Support.

Ich habe/hatte mich entschlossen meinen SCCM Server im LAB neu aufzusetzen.

Nun klappt es per dato einwandfrei.

Gruss, mame

Hallo nochmal**, Mame Meier,**

Ich wollte nur nachhaken. Um die vorherige Empfehlung zusammenzufassen: Der Installationsfehler wird durch eine Logikaufteilung verursacht, bei der der Site Component Manager Binärdateien auf Ihr sekundäres Laufwerk (D:) schreibt, der MSI-Registrierungsprozess jedoch fälschlicherweise das Systemlaufwerk (C:) anvisiert. Die Lösung besteht darin, eine NO_SMS_ON_DRIVE.SMS Datei auf die Wurzel von C:s zu legen, was den Hierarchiemanager dazu zwingt, dieses Volumen zu disqualifizieren und die Installationsvariablen mit dem D:-Laufwerk auszurichten.

Wenn der Site-Server die Laufwerksausschlussdatei nicht sofort respektierte, bleibt die Directory Junction-Methode die präziseste technische Lösung für diesen spezifischen Pathing-Fehler. Indem mklink /J "C:\Program Files\SMS_SRSRP" "D:\Program Files\SMS_SRSRP" du in einer erhöhten Eingabeaufforderung ausführst, erstellst du einen symbolischen Link, der die fest programmierte Abfrage des Installers in C: erfüllt, während du die I/O auf den tatsächlichen Dateistandort in D:umleitest. Bitte bestätigen Sie, ob Sie versucht haben, die Verbindung zu erstellen, und falls die Installation weiterhin fehlschlägt, geben Sie das Update ansrsrp.log, damit ich überprüfen kann, ob der Fehlercode von der fehlenden DLL zu einem Berechtigungsproblem übergegangen ist.

Wenn das Problem erfolgreich gelöst wurde, erwägen Sie bitte, die Antwort zu akzeptieren , da dies auch anderen mit derselben Frage zugutekommt. Vielen Dank!

VP

Hi Mame Meier,

Zuerst müssen Sie sicherstellen, dass der Installationsprozess der ConfigMgr-Rolle daran gehindert wird, Laufwerk C: als gültigen Kandidaten für Inhalte oder Binärdateien zu betrachten. Entferne die fehlerhafte Rolle Reporting Services Point aus der Konsole und verifiziere deren Entfernung in srsrp.log. Erstelle eine leere Textdatei, die NO_SMS_ON_DRIVE.SMS auf der Wurzel des C:-Laufwerks benannt ist. Diese Datei wirkt als harte Einschränkung für den Site Component Manager, zwingt ihn, gültige Installationspfade neu zu berechnen und die Variable oft so zu korrigieren SRSRPINSTALLDIR , dass sie mit dem D:-Laufwerk übereinstimmt, auf dem sich Ihr Standort befindet.

Wenn die Einschränkung NO_SMS_ON_DRIVE.SMS den Installer nicht zwingt, die Variable auf D:s umzustellen, hast du wahrscheinlich aufgrund der SQL 2022 SSRS-Konfiguration eine Registrierungsfehler. Navigiere zu HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\SSRS\Setup (oder zum entsprechenden Schlüssel für deine spezifische SSRS-Instanz-ID) und inspiziere die Path or-String-Werte InstallationDirectory . Wenn diese auf C: hinweisen, erbt der SRSRP-Installer diesen Standort. Obwohl das Bearbeiten dieses Schlüssels riskant ist, ist eine sicherere Lösung für eine Laborumgebung, die Pfadlücke mit einem Directory Junction zu überbrücken. Erstellen Sie das Verzeichnis D:\Program Files\SMS_SRSRP manuell. Öffne eine erhöhte Eingabeaufforderung und führe mklink /J "C:\Program Files\SMS_SRSRP" "D:\Program Files\SMS_SRSRP". Setze die Rolle wieder ein. Der Installer schreibt auf den C:-Pfad (Tunneling zu D:), und der Registrierungsschritt, der nach der DLL bei C: sucht, wird erfolgreich sein, wodurch die Rollback-Löschung verhindert wird.

Sollten Sie weitere Fragen haben, können Sie gerne eine Nachricht hinterlassen. Bitte überlege, die Antwort zu akzeptieren, wenn du etwas Nützliches gefunden hast. Schönen Tag!

VP