Wie ich im letzten November geschrieben habe, aktualisieren immer mal wieder Anwendungen auf neue Versionen. Wenn derartige Deployments von Anwendungsupdates alle Child-Sites betreffen, steuern wir diese aus unserer Central Site. Und damit auch die Administratoren der Child-Sites bequem kontrollieren können, welche ihrer Clients noch nicht aktualisiert wurden, wollte ich diesen einige vorkonfigurierte Reports zur Verfügung stellen. „Vorkonfigurierte Reports?“

Die meisten Reports werden ja mit irgendwelchen Parametern aufgerufen, so z.B. auch der Report „Computers with specific software registered in Add Remove Programs“, den ich zu diesem Zwecke herangezogen habe. Dieser Report will nun mit Parametern  für den „Software Title“ (d.h. den Namen, unter welchem die Software eingetragen ist) und die auszuwertende Collection aufgerufen werden. Und diese Werte jedesmal nachzuschlagen, finde ich noch ziemlich mühsam, denn gerade beim „Software Title“ muss der exakte Wert angegeben werden, ansonsten der Report ein leeres Ergebnis liefert. Hat man nun den gewünschten Report erhalten, lassen sich noch die Spalten wunschgemäss sortieren. Dann findet man in der Adresszeile des Browsers die genaue URL, welche diesen Report generiert, d.h. irgendwas in der Form:

http://<siteserver>/SMSReporting_<sitecode>/Report.asp?ReportID=92&displayname=<genaue%28!%29%20Bezeichnung%20der%20Software>&CollID=<collection>&SortRs1Col=1&SortRs1Dir=1

Kennt man diese URL, lässt sich der entsprechende Report jederzeit wieder mit den aktuellen Daten neu generieren, ohne dass man wieder umständlich die passenden Parameter zusammensuchen muss.  Und diese URL lässt sich also als Lesezeichen im Browser ablegen, oder – wie ich das vorgesehen hatte – auf einer Intranetseite verlinken. Und so suchte ich alle notwendigen URLs zusammen, erstellte die Intranetseite, testete erfolgreich alle Links und kontaktierte einen unserer Admins einer Childsite, damit er sich das mal ansehen möge. Doch am anderen Ende der Telefonleitung blieb die grosse Freude aus. Stattdessen hiess es nur: „Aehemm…. ich erhalte da bloss einen Error 500!“

Bei mir funktionierten immer noch alle Links perfekt, beim Kollege Child-Site-Admin jedoch nicht. Sogleich vermutete ich ein Rechteproblem, denn bei uns haben alle Child-Site-Admins ausschliesslich Adminrechte für ihre eigene Site und bloss ein Leserecht für die Central-Site und alle anderen Sites. Doch die Rechte in SCCM waren korrekt vergeben; auch nach mehrmaligem Nachkontrollieren kam ich zum Schluss, dass der Kollege alle benötigten Rechte haben müsste, um die Reports abrufen zu können. Doch irgendwas klemmte da noch immer…

Doch dann fiel mir ein: „Error 500!“. Das bedeutet ja üblicherweise nicht „Access denied“, sondern „Internal Server Error“! Also warf ich mal einen Blick in das Webserver-Protokoll und wurde da tatsächlich fündig:

Error 500: ASP_0178_:_80070005|Server.CreateObject_Access_Error

Nach längerer Suche fand ich dann eine Diskussion über ein Problem „Error accessing reporting services – DCOM“ in den Microsoft Technet Foren.  Als Lösung wird dort die Deaktivierung der „User Account Control“ vorgeschlagen, was ich allerdings nicht unbedingt tun wollte. Doch im letzten Beitrag schrieb der Benutzer „EddieAdams“:

I was having the exact same problem but solved it by adding ‚Authenticated Users‘ to the local ‚SMS Reporting Users‘ group on the SCCM Server.

Das war ein einfacher Lösungsvorschlag, den ich sofort umsetzte. Doch der Kollege sah weiterhin bloss „Error 500!“

Also suchte ich weiter und stiess dann auf den Artikel „Error message when you try to use the SMS Web Reporting Tool: „Server object error ‚ASP 0178 : 80070005′““ in der Microsoft Knowledge Base. Dieser beschreibt exakt das angetroffene Problem, bezieht sich zwar explizit auf den Server 2003 SP1, führte aber auch unter Server 2008 R2 zur Lösung:

This problem occurs because the following conditions are true:

• You are a member of the SMS Reporting Users security group on the Windows Server 2003 SP1-based computer that is acting as the SMS site server.
• You are not a member of the local Administrators group on the Windows Server 2003 SP1-based computer that is acting as the SMS site server.

In this case, the DCOM permissions are locked down on the Windows Server 2003 SP1 site server.

Genau dies trifft im vorliegenden Fall zu: Mein Kollege Child-Site-Admin ist zwar nun Mitglied der Gruppe „SMS Reporting Users“, seit ich dort „Authenticated Users“ hinzugefügt hatte, doch ist er keineswegs lokaler Administrator unseres Central-Site-Servers. Und so setzte ich die im Artikel beschriebene Anleitung um:

Log on to the Windows Server 2003 SP1 computer that is acting as the SMS site server by using an account that has administrative permissions.

Click Start, click Run, type dcomcnfg, and then click OK.

In the Component Services MMC snap-in, expand Component Services, expand Computers, right-click My Computer, and then click Properties.

In the My Computer Properties dialog box, click the COM Security tab.

Under Launch and Activation permissions, click Edit Limits.

In the Launch Permission dialog box, make sure that the Everyone group has Remote Launch and Remote Activation permissions.

In the Component Services MMC snap-in, expand My Computer, expand DCOM Config, right-click SMS_Reporting_Point, and then click Properties.

In the SMS_Reporting_Point Properties dialog box, click the Security tab. Under Launch and Activation Permissions, select Customize, and then click Edit.

In the Launch Permission dialog box, make sure that the SMS Reporting Users local group has following permissions:

• Local Launch
• Remote Launch
• Local Activation
• Remote Activation

Component Services -> SMS_Reporting_Point Properties -> Launch and Activation Permissions

Und tatsächlich: Nun können auch die Administratoren unserer Childsites die von mir vorbereiteten Reports auf dem Central Site Server abrufen!