Wenn der SCCM Reporting Point einer anderen Site bockt…
Mittwoch, 19. Januar 2011, 22:27
Abgelegt unter: Erkenntnisse | Tags: , , , ,

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:

  1. 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.
  2. Click Start, click Run, type dcomcnfg, and then click OK.
  3. In the Component Services MMC snap-in, expand Component Services, expand Computers, right-click My Computer, and then click Properties.
  4. In the My Computer Properties dialog box, click the COM Security tab.
  5. Under Launch and Activation permissions, click Edit Limits.
  6. In the Launch Permission dialog box, make sure that the Everyone group has Remote Launch and Remote Activation permissions.
  7. In the Component Services MMC snap-in, expand My Computer, expand DCOM Config, right-click SMS_Reporting_Point, and then click Properties.
  8. In the SMS_Reporting_Point Properties dialog box, click the Security tab. Under Launch and Activation Permissions, select Customize, and then click Edit.
  9. 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!



Wenn der SCCM Distribution Point bockt…
Sonntag, 31. Oktober 2010, 21:30
Abgelegt unter: Erkenntnisse | Tags: , , , ,

Vor einiger Zeit wurde ich von einem Kollegen mit dem Problem konfrontiert, dass bei der Installation eines Softwarepaket über den System Center Configuration Manager 2007 der Download mittendrin ohne klar ersichtlichen Grund hängenbleibe. Doch wenn man im Advertisement von „Download content from distribution point and run locally“ auf „Run program from distribution point“ umstelle, könne das Paket problemlos installiert werden. Dies betreffe jedoch nur die eine Site, in einer anderen Site unserer Sitestruktur könne zudem dasselbe Paket problemlos auf beide Arten installiert werden. „Für den Installer dieser Applikation spiele es keine Rolle, ob er lokal oder über einen UNC-Pfad ausgeführt werde; beides funktioniere problemlos, wie er getestet habe. Und die verwendeten Dateien in den Paketen seien doch in allen Fällen und auf allen Distribution Points dieselben und stammten vom selben Source-Verzeichnis“, konstatierte der verzweifelte Kollege. „Ja schon, aber….“, begann meine Antwort.

Auch wenn die Dateien tatsächlich in allen Fällen dieselben sind, ist der Weg, wie die Dateien vom Server zum Client transportiert werden, grundverschieden. Im Falle des „Run program from distribution point“ greift der Client via SMB (d.h. normalen Fileserver-Zugriff) auf den Distribution Point zu. Im Falle von „Download content from distribution point and run locally“ will der Client jedoch die Dateien via BITS (d.h. den „Background Intelligent Transfer Service“) vom Server beziehen, womit auch der IIS („Internet Information Server“ des Distribution Point ins Spiel kommt. Somit liegt der Verdacht nahe, dass es sich beim vorliegenden Problem gar nicht um ein SCCM, sondern ein IIS-Problem handelt.

Denn der IIS blockt standardmässig bestimmte Dateierweiterungen, womit Dateien dieser Typen in der IIS-Standardkonfiguration nicht via BITS heruntergeladen werden können. Dies wird auch im Technet-Artikel „Konfigurieren von Windows Server 2008 für Standortsysteme“ beschrieben:

Wenn an BITS-fähige Verteilungspunkte verteilte Paketquelldateien Dateierweiterungen enthalten, die in IIS 7.0 standardmäßig blockiert sind, muss der Abschnitt „requestFiltering“ der Datei „applicationHost.config“ so geändert werden, dass die erforderlichen Dateierweiterungen zugelassen werden.

Und dies geschieht auf folgende Art und Weise: In der Datei „applicationHost.config“ im Verzeichnis „%windir%\System32\inetsrv\config\“ des Distribution Points muss der Abschnitt „<requestFiltering>“ gesucht werden. In diesem Abschnitt sind Einträge in der folgenden Art zu finden:

<add fileExtension=".mdb" allowed="false" />

Wird hier „false“ durch „true“ ersetzt, die Datei „applicationHost.config“ danach gespeichert und der IIS neu gestartet, können nun auch Dateien mit der Endung „.mdb“ über BITS übertragen werden. Und so kann diese Einstellung für jeden benötigten Dateityp vorgenommen werden. Kandidaten in unserer Umgebung waren primär Dateierweiterungen wie „.config“, „.java“, „.mdb“ und „.ldf“. Natürlich lässt sich dies auch gleich pauschal lösen, indem alle entsprechenden Zeilen auskommentiert oder gelöscht werden, denn für alle nicht aufgeführten Dateitypen ist der Transfer gemäss der Default-Einstellung erlaubt. Man muss sich einfach bewusst sein, dass man durch derartige Anpassungen die Angriffsfläche des Servers vergrößert, zumal die Änderungen für alle Websites auf dem jeweiligen Server gelten.

Ganz abgesehen davon, dass man bei der Installation eines neuen Siteservers selten im voraus weiss, welche Dateitypen dann tatsächlich benötigt werden, verschweigt der besagte Technet-Artikel jedoch einen Punkt, der uns schon mehrfach Probleme verursacht hat:

Es gibt nicht nur bestimmte Dateiendungen, die standardmässig geblockt werden, sondern auch Pakete, welche ein Unterverzeichnis „bin“ haben, können in der IIS-Standardkonfiguration nicht via BITS heruntergeladen werden. Hierzu findet man in derselben Datei „applicationHost.config“ etwas weiter unten einen Abschnitt „hiddenSegments“ mit den dazugehörenden Einträgen in der Form:

<add segment="bin" />

Wird diese Zeile (resp. die passende Zeile bei anderen blockierten Verzeichnisnamen) gelöscht, die geänderte Datei gespeichert und der IIS neu gestartet, können danach auch Pakete mit „bin“-Verzeichnissen über BITS ausgeliefert werden.

Dass in unserem Problemfall der Download von einem Distribution Point geklappt hat und vom anderen nicht, lag schlicht und einfach daran, dass die notwendigen Modifikationen der Datei „applicationHost.config“ auf dem einen Server bereits vorgenommen, auf dem anderen jedoch unterlassen wurden.

Bei der Aufarbeitung dieser Thematik als Blogbeitrag bin ich noch über weitere Blogs bzw. Diskussionen gestossen, welche ähnliche Probleme beschreiben. Diese habe ich in unserem Umfeld zwar nicht direkt angetroffen, doch ich denke, dass die abschliessende Erwähnung dieser Beiträge und Links in diesem Zusammenhang durchaus Sinn macht:



Installation MS System Center Service Manager – Teil 7 – Installation „Service Manager Webportal“
Sonntag, 3. Januar 2010, 19:33
Abgelegt unter: Anleitungen | Tags: , , ,

Als letzter Teil der Installation des Service Managers möchte ich nun noch das Webportal installieren.

Voraussetzungen

Auch heute halte ich mich an einen Blogbeitrag aus Belgien, der die Voraussetzungen für die Installation des Webportals nennt. Da dieses auf dem IIS basiert, muss zuerst ein Standard-IIS eingerichtet werden, der folgende zusätzlichen Role Services benötigt:

  • Asp.Net (und alle davon abhängigen Features)
  • Windows Authentication
  • IIS 6.0 Metabase Compatibility

Auf meinem Server ist der IIS zwar bereits installiert, doch die zusätzlichen Role Services fehlen noch, deshalb installiere ich diese als erstes nach.

Installation des Portals

Nun starte ich den Setup Wizard und wähle „Install the Service Manager Web Portals“. Als nächstes muss ich nun den Namen und die Organisation eingeben und den Lizenzvertrag abnicken. Das Feld für den Product-Key bleibt leer, da für die Beta-Version noch kein Product-Key benötigt wird. Im nächsten Dialogfenster wird nach dem Installationsort gefragt und darauf hingewiesen, dass 1 GB freier Diskplatz benötigt werde. Der Diskplatz ist vorhanden, zudem übernehme ich den vorgeschlagenen Pfad.

Danach werden diverse Checks durchgeführt: Beim Memory Check erhalte ich eine Warnung, dass das System nur über 2GB Memory verfüge, empfohlen wären 4GB. Da alle anderen Checks erfüllt sind, kann das Setup dennoch fortgesetzt werden.

Nun wird nach dem Namen und dem Port für die Website gefragt: Hier übernehme ich den vorgegebenen Namen „SCSMPortal“ und den Port 443. Eine Meldung weist daraufhin, dass das SSL-Certificate nicht automatisch hinzugefügt werde, wozu es im Deployment Guide zusätzliche Informationen gebe.

Als nächstes muss konfiguriert werden, wo die Service Manager Datenbank zu finden ist. Ich trage den Namen des Servers ein und erhalte umgehend die entsprechende Instanz angeboten. In dieser kann ich die Service Manager Datenbank bequem auswählen.

Nun muss ein Konto angegeben werden, mit welchem das Service Manager Portal auf die Datenbank zugreifen kann. Es wird verlangt, dass dieselben Credentials verwendet werden, wie bei der Installation des Management Servers. Ich trage die entsprechenden Angaben ein, klicke auf den Knopf „Test Credentials“ und erhalte die Bestätigung, dass die Angaben passen.

Jetzt folgen noch die Fragen zum “Customer Experience Improvemend Program” und zum “Error Reporting”. Da wir hier eine Beta-Version einsetzen, bejahe ich mal beides. Nun wird noch das Summary angezeigt, danach startet die Installation. Es dauert nur wenige Sekunden, dann erhalte ich die Meldung: „Setup completed successfully“.

Der Setup-Vorgang hat zwei Portale eingerichtet:

  • https://<Servername>:443/EndUser
  • https://<Servername>:443/Analyst

Installation des SSL-Zertifikates

Ich starte nun den „Internet Information Services (IIS) Manager“, klicke unter Connections auf den Servernamen und öffne „Server Certificates“. Hier klicke ich auf „Create Domain Certificate“. Hier werden zuerst nach den Angaben zum „Distinguished Name“ gefragt. Hier muss als „Common Name“ der vollqualifizierte Servername eingetragen werden, die restlichen Felders sind geeignet auszufüllen.

Da wir eine eigene Certification Authority betreiben, kann ich diese im nächsten Schritt bequem auswählen. Noch ein passender „Friendly Name“ eingetragen und schon kann ich das Zertifikat mit dem Klick auf „Finish“ beziehen. Das neu ausgestellte Zertifikat wird nun in der Liste angezeigt.

Nun expandiere unter Connections dem Servernamen und „Sites“. Ich klicke mit der rechten Maustaste auf das SCSMPortal und wähle „Edit Bindings…“ In der Dialogbox „Site Bindings“ klicke ich auf Edit und kann nun das SSL-Zertifikate auswählen, danach schliesse ich den Dialog wieder.

Ein erster Test

Neugierig öffne ich nun die Adresse „https://<Servername>:443/EndUser“ im Browser. Und tatsächlich, ich erhalte eine Anmeldeaufforderung. Flugs die passenden Daten eingetragen und ich sehe erstmals das End-User-Portal vor mir. Es sieht zwar noch sehr hässlich aus, da das CSS-fehlt und auch noch die Icons durch ein rotes Kreuz ersetzt werden, aber immerhin.

Troubleshooting

Nun folgt eine lange Suche in den Abgründen des IIS, weshalb die Icons und das CSS fehlen; es ist unmöglich, hier zu beschreiben, wo ich überall gesucht habe. Doch als ich nochmals die Installation des IIS durchsehe, um das Logging zu aktivieren, stelle ich fest, dass schlicht und einfach die Role Services „Common HTTP Features“ mit allen Unterservices wie „Static Content“ etc. nicht installiert sind. Ich habe dies nachgeholt und siehe da: Keine Kreuzchen mehr, das CSS lädt wunschgemäss. Endlich habe ich die Seite so vor mir, wie ich sie mir etwa vorgestellt habe:

Service Manager EndUser Portal

Abschliessend folgt noch die Konfiguration der Kontakteinstellungen, dieich in der SCSM-Konsole vornehme. Hierzu navigiere ich in der Konsole zu „Administration“, „Portal“, „Settings“ und öffne dort die „End-user portal Contact IT settings“. Hier trage ich die passenden Informationen ein und kontrolliere nachher kurz im Portal, ob diese wunschgemäss angezeigt werden.

Persönliches Fazit zur Installation des Service Manager

Mit der Bereitstellung des Webportals ist meines Erachtens die grundsätzliche Installation des Service Manager abgeschlossen, womit auch diese Reihe von sieben Blogbeiträgen zu diesem Thema ihren Abschluss findet. Es ist mir absolut bewusst, dass nun erst der Anfang geschafft ist. Bis aus der vorliegenden Grundinstallation eine brauchbare Umgebung geworden wird , wird es noch viel Konfigurationsarbeit benötigen.

Die Installation selber lief in vielen Bereichen sehr problemlos ab. Doch wenn es mal klemmte, dann klemmte es gleich richtig. Die mitgelieferte Dokumentation konnte zwar etliche Fragen beantworten und auch einen Leitfaden darstellen, am meisten habe ich jedoch von den Beiträgen in den folgenden Blogs profitiert:

Aber eben: Die Grundinstallation und die Grundkonfiguration ist gemacht, nun kann der Aufbau der Service Manager Umgebung erst richtig anfangen. Und auch dabei wird es sicher wieder weitere Erkenntnisse geben, die in zukünftige Blogbeiträge von mir einfliessen werden.

In diesem Sinne: Leicht verspätet die besten Wünsche zum neuen Jahr!
Euer Michael Hottinger

1 Kommentar