Abgelegt unter: Erkenntnisse | Tags: Error500, IIS, ReportingPoint, SCCM, Server2008R2
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!
Abgelegt unter: Erkenntnisse | Tags: CAL, Lizenzierung, Server2008R2, Virtualisierung, VMWARE
Die leider nicht zu vermeidende Vorbemerkung…
Dieser Beitrag entstand im Anschluss an einen Microsoft Lizenzierungsworkshop, den ich vergangene Woche besucht habe, und fasst meine Notizen zu dieser Thematik zusammen. Auch wenn ich mir bei der Erstellung dieses Beitrages grösste Mühe gegeben habe, die präsentierten Informationen möglichst korrekt und vollständig wiederzugeben, muss ich hier folgenden Warnhinweis anfügen:
Ich weise ausdrücklich darauf hin, dass dieser Beitrag keinerlei rechtsverbindlichen Charakter hat, sondern ausschliesslich das Verständnis der Microsoft-Produktlizenzierung verbessern soll. Die einzig rechtsverbindlichen Lizenzinformationen sind in den entsprechenden Endbenutzerlizenzverträgen (als Beilage zu Softwarepaketen) oder Produktbenutzungsrechten der Microsoft Volumenlizenzprogramme zu finden.
Die Grundlagen zur Volumenlizenzierung im virtualisierten Umfeld
Je nach erworbener Windows-Serverlizenz darf eine unterschiedliche Anzahl virtualisierter Instanzen auf einem physischen Server betrieben werden. Dabei sind stets die „Running Instances“ relevant, d.h. die Anzahl Instanzen, die gleichzeitig betrieben werden dürfen:
- Windows Server 2008 R2 Standard: 1 physische Installation + 1 virtuelle Instanz
- Windows Server 2008 R2 Enterprise: 1 physische Installation + 4 virtuelle Instanzen
- Windows Server 2008 R2 Datacenter: 1 physische Installation + unlimitierte virtuelle Instanzen.
Nur ausgeführte Instanzen müssen lizenziert werden. Ist einem physischen Server z.B. 1 Lizenz „Windows Server 2008 R2 Enterprise“ zugewiesen, dürfen auf diesem Server vier virtuelle Instanzen von Windows Server Enterprise (oder Standard) ausgeführt und beliebig viele nicht-ausgeführte Instanzen erstellt werden, welche auch auf einem anderen als dem lizenzierten Server oder in einem SAN gespeichert werden dürfen.
Wurde eine höhere Edition lizenziert, darf auch eine tiefere Edition ausgeführt werden: Wurde ein Server beispielsweise für „Windows Server 2008 R2 Enterprise“ lizenziert, darf darauf auch „Windows Server 2008 R2 Standard“ ausgeführt werden. Während auf einem für „Windows Server 2008 R2 Standard“ lizenzierten Server nur „Windows Server 2008 R2 Standard“ ausgeführt werden darf, ist für die Ausführung von „Windows Server 2008 R2 Datacenter“ die Lizenzierung von „Windows Server 2008 R2 Datacenter“ notwendig. Auf einem für „Windows Server 2008 R2 Datacenter“ lizenzierten Server dürfen alle drei Editionen in beliebiger Anzahl und beliebiger Kombination ausgeführt werden.
Eine Windows-Serverlizenz wird nie der virtualisierten Instanz direkt zugewiesen, sondern muss immer dem physischen Server zugewiesen werden, auf dem die virtualisierte Instanz betrieben werden soll. Eine Hardwarepartition oder ein Blade wird in diesem Zusammenhang als separater physischer Server betrachtet. Dabei ist zu beachten, dass eine Windows-Serverlizenz einem lizenzierten Server mindestens 90 Tage zugewiesen bleiben muss. Erst nach Ablauf dieser 90-Tage-Frist darf eine Lizenz einem anderen Server (und somit auch einem anderen Blade) neu zugewiesen werden. Die Neuzuweisung darf nur dann ausnahmsweise früher erfolgen, wenn der lizenzierte Server (bzw. das lizenzierte Blade) wegen eines dauerhaften Hardwarefehlers ausser Dienst gestellt wird. Sollen die virtualisierten Instanzen vor Ablauf der 90 Tage aus anderen Gründen auf einen anderen, bisher nicht lizenzierten (z.B. neu erworbenen) Server verschoben werden, muss der neue Server (bzw. das neue Blade) separat lizenziert werden.
Einem physischen Server darf auch mehr als eine Lizenz zugewiesen werden, um zusätzliche virtuelle Instanzen auf diesem Server ausführen zu können. Werden beispielsweise einem physischen Server zwei Lizenzen von „Windows Server 2008 R2 Standard“ zugewiesen, dürfen darauf zwei virtuelle Instanzen von „Windows Server 2008 R2 Standard“ betrieben werden, da „Windows Server 2008 R2 Standard“ nur eine virtualisierte Instanz pro Lizenz erlaubt. Werden dem physischen Server hingegen zwei Lizenzen von „Windows Server 2008 R2 Enterprise“ zugewiesen, dürfen darauf insgesamt acht Instanzen von „Windows Server 2008 R2 Standard“ und „Windows Server 2008 R2 Enterprise“ in beliebiger Kombination ausgeführt werden.
Zu beachten ist im weiteren, dass „Windows Server 2008 R2 Standard“ und „Windows Server 2008 R2 Enterprise“ pro Gerät (also pro Server) lizenziert werden, der „Windows Server 2008 R2 Datacenter“ hingegen pro physisch vorhandener Prozessor zu lizenzieren ist, wobei jedoch die Anzahl der Cores pro Prozessor keine Rolle spielt. Bei der Datacenter-Edition müssen zudem minimal 2 Lizenzen pro Maschine erworben werden, der Einsatz der Datacenter-Edition auf Single-Prozessor-Servern ist von Microsoft nicht vorgesehen.
Das Verschieben von virtuellen Instanzen auf einen neuen Server ist erlaubt, sofern durch diese Verschiebung keine Lizenzbestimmungen verletzt werden. So darf z.B. eine Instanz nur dann auf einen mit „Windows Server 2008 R2 Enterprise“ lizenzierten physischen Server verschoben werden, wenn auf diesem erst maximal drei andere Instanzen betrieben werden, da nur maximal vier Instanzen zulässig sind. Ebenso darf eine unter „Windows Server 2008 R2 Enterprise“ betriebene Instanz nicht auf einen mit „Windows Server 2008 R2 Standard“ lizenzierten physischen Server verschoben werden. Dasselbe gilt auch für Instanzen mit „Windows Server 2008 R2 Datacenter“, welche ausschliesslich auf einem für „Windows Server 2008 R2 Datacenter“ lizenzierten Server betrieben werden dürfen. Das Verschieben von Instanzen auf einen für „Windows Server 2008 R2 Datacenter“ lizenzierten Server hingegen ist unproblematisch, da darauf Instanzen beliebiger Editionen in beliebiger Zahl betrieben werden dürfen. Nicht zuletzt aus diesem Grund wird von Microsoft für virtualisierte Serverfarmen die Lizenzierung von „Windows Server 2008 R2 Datacenter“ als „Rundum-Sorglos-Paket“ empfohlen.
Wie funktioniert das ganze nun unter VMWARE bzw. anderen Virtualisierungstechnologien?
Wird VMWARE (oder ein anderes Produkt eines Drittherstellers) als Virtualisierungsschicht eingesetzt, verzichtet man aus Sicht von Microsoft gewissermassen auf den Einsatz der physischen Installation, die entsprechende Lizenz muss aber trotzdem dem entsprechenden physischen Gerät zugewiesen werden. Je nachdem ob dem VMWARE-Device nun eine Standard-, Enterprise, oder Datacenter-Lizenz zugewiesen wird, dürfen darauf nun eine, vier oder beliebig viele Windows-Server mit den jeweils erlaubten Editionen betrieben werden.
Während „Windows Server 2008 R2 Standard“ und „Windows Server 2008 R2 Enterprise“ einfach pro Server bzw. pro Blade zu lizenzieren sind, wird die Anzahl vorhandener physischer Prozessoren auch beim Einsatz von VMWARE bzw. anderer Virtualisierungstechnologien für die Lizenzierung von „Windows Server 2008 R2 Datacenter“ relevant. Es müssen genauso viele Lizenzen erworben werden, wie physische Prozessoren vorhanden sind, auch wenn auf dem betreffenden physischen Device schlussendlich nur vereinzelte Windows-Server-Instanzen neben beliebig unzähligen weiteren z.B. Linux-Instanzen betrieben werden sollen.
Soll zudem Loadbalancing eingesetzt werden und ggf. sogar automatisiert Serverinstanzen von ausgelasteten physischen Server auf weniger belastete Server verschoben werden, wird die Problematik der korrekten Lizenzierung noch zentraler, da in diesem Falle alle physischen Server, auf denen Windows-Serverinstanzen betrieben werden sollen, separat lizenziert sein müssen. Denn gerade hier schlägt die „90-Tage Frist“ zu, welche eine rasche Neuzuweisung von Windows-Server-Lizenzen verbietet, da die Server-Lizenzen – wie bereits erwähnt – immer dem betreffenden ausführenden physischen Server und nicht den herumschiebbaren virtuellen Instanzen zuzuweisen sind.
In heterogenen Umgebungen wird es demzufolge äusserst ratsam, die Windows-Serverinstanzen zu konsolidieren und nur auf dezidierten (und somit zu lizenzierenden) physischen Server zu betreiben und die anderen, z.B. Linux-Instanzen auf anderen physischen Server zu betreiben, auf denen niemals Windows-Serverinstanzen betrieben werden, welche somit nicht lizenziert werden müssen.
Nicht zu vergessen: Die Clientzugriffslizenzen (CAL)
Der Erwerb von Serverlizenzen reicht leider in den wenigsten Fällen aus, einen korrekt lizenzierten Windows Server zu betreiben, denn es werden zusätzlich für alle Zugriffe auf einen Windows Server sogenannte CAL („Client Access License“) benötigt. Das gilt für Windows Server Standard, Enterprise und Datacenter. Zugriffe externer Nutzer können über CALs oder einen „External Connector“ lizenziert werden. Es gibt folgende Arten von CAL:
- Windows Server 2008 CAL
- Windows Server 2008 RDS CAL
- Windows Server 2008 RMS CAL
Dabei gibt es zwei Typen von CAL, welche in beliebiger Kombination verwendet werden dürfen:
- Eine „Benutzer-Zugriffslizenz“ („User CAL“) wird dauerhaft einem Benutzer zugewiesen und erlaubt diesem, von einem beliebigen Gerät auf Instanzen von Windows Server 2008 R2 auf die lizenzierten Windows-Server zuzugreifen.
- Eine „Geräte-Zugriffslizenz“ („Device CAL“) wird dauerhaft einem Gerät zugewiesen und erlaubt beliebigen Benutzern dieses Gerätes, auf Instanzen von Windows Server 2008 R2 auf lizenzierten Servern des Unternehmens zuzugreifen.
CAL dürfen zwar neu zugewiesen werden, aber dies nur, wenn die neue Zuweisung „dauerhaft“ sein soll, oder wenn es sich um ein temporäres Ersatzgerät oder eine Aushilfsperson handelt, währenddessen das lizenzierte Gerät ausser Betrieb (z.B „in Reparatur“) bzw. der lizenzierte Benutzer abwesend ist. Somit wird es klar, dass bei der Definition der benötigten CAL keinesfalls irgendeine Zahl gleichzeitig aktiver („concurrent“) Benutzer relevant ist, sondern die effektive Anzahl unterscheidbarer Benutzer bzw. Geräte, die in den meisten Fällen leider wohl deutlich höher liegen dürfte.
Ein „Windows Server 2008 CAL“ wird erforderlich, sobald auf irgendeine Art und Weise auf einen Windows Server zugegriffen werden soll, wozu es allerdings auch Ausnahmen gibt: So ist kein Windows CAL erforderlich für maximal zwei Benutzer bzw. zwei Geräte, wenn der Zugriff ausschliesslich zur Administration des Servers geschieht. Auch wenn der Zugriff unidentifiziert via Internet erfolgt (z.B. anonymer Zugriff auf eine öffentlich zugängliche Website) erfolgt, werden keine CAL benötigt; sobald aber der Benutzer (bzw. das Gerät) beim Zugriff auf irgendwelche Art und Weise identifiziert wird, wird der entsprechende Erwerb der benötigten Anzahl „Windows Server 2008 CAL“ fällig.
Zur Nutzung von Remote Desktop Services (RDS) wird zusätzlich ein „Windows Server 2008 RDS CAL“ pro Benutzer oder pro Gerät benötigt, dieser berechtigt zudem dazu, „Application Virtualization für Terminaldienste“ zu nutzen. Zur Nutzung der Rights Management Services (RMS) von Windows Server 2008 R2 wird analog ein „Windows Server 2008 RMS CAL“ benötigt.
Auch externe Benutzer (wie Geschäftspartner und Kunden) könnten grundsätzlich über einzelne CALs pro externen Benutzer lizenziert werden, doch gerade in diesem Umfeld wird es sehr schwierig, die genaue Anzahl der benötigten CAL zu bestimmen; der „pauschal“ lizenzierende „External Connector“ vereinfacht dies deutlich. Wie zu erwarten, gibt es neben dem Basis „Windows Server 2008 External Connector“ auch je einen „Windows Server 2008 RDS External Connector“ und einen „Windows Server 2008 RMS External Connector“. Ein „External Connector“ unterliegt zudem ebenfalls der 90-Tage-Frist für die Neuzuweisung analog zu den Windows-Server-Lizenzen.
Weitere Serverprodukte… und weitere CAL…
Werden auf den virtualisierten Instanzen von Windows Server weitere Server (wie Exchange, Sharepoint, System Center Produkte, usw.) betrieben, sind diese jeweils gemäss den Anforderungen zum jeweiligen Produkt zu lizenzieren. Wird nun eine derartige Instanz von Windows Server auf einen anderen physischen Server verschoben, muss die entsprechende Lizenz mitverschoben werden. Im Gegensatz zum Windows Server profitieren diese Server-Produkte jedoch zumeist von der sog. „License Mobility“, d.h. bei diesen Produkten existiert keine 90-Tage-Frist für die Neuzuweisung der Lizenz, sondern diese Lizenzen dürfen je nach Bedarf neuen Servern zugewiesen werden, sofern diese zur selben „Serverfarm“ gehören. Welche Lizenzen konkret von „License Mobility“ profitieren, ist mit „LM (License Mobility)“ im Microsoft Dokument „Product Use Rights“ dokumentiert.
Auch hier müssen für die jeweiligen Server-Produkte vielfach entsprechende CAL lizenziert werden, damit diese Produkte nicht nur installiert, sondern auch von den Benutzern (bzw. von den entsprechenden Devices her) genutzt werden dürfen.
Eine umfassende Zusammenstellung der Lizenzierungmöglichkeiten aller Serverprodukte würde jedoch den Rahmen dieses Beitrages bei weitem sprengen. Der Leser sei diesbezüglich auf die Dokumentationen von Microsoft zum jeweiligen Produkt verwiesen (siehe Links am Ende des Beitrages).
CAL-Suiten
Um die Lizenzierung zu vereinfachen, bietet Microsoft zwei sog. „CAL-Suiten“ an, welche den Clientzugriff für mehrere Produkte in einem Schritt lizenzieren:
- Die sog. „Microsoft Core Cal Suite“ umfasst folgende Clientzugriffslizenzen:
- Windows Server CAL
- Exchange Server Standard CAL
- SharePoint Server Standard CAL
- SC Configuration Manager Client ML
- Die umfassendere „Microsoft Enterprise CAL Suite“ enthält alle Clientzugriffslizenzen der „Microsoft Core Cal Suite“ und bringt zusätzlich folgende Clientzugriffslizenzen mit:
- Windows Rights Management Services (RMS) CAL
- Exchange Server Enterprise CAL
- SharePoint Server Enterprise CAL
- SC Client Management Suite (SCOM, SCDPM; und SCSM Client ML)
- OCS Standard CAL (Lync Server Standard CAL)
- OCS Enterprise CAL (Lync Server Enterprise CAL)
- Forefront Protection Suite
- Forefront Unified Access Gateway CAL
Einzig die „Remote Desktop Services CAL“ ist in keiner Suite enthalten und muss deshalb immer separat lizenziert werden.
Abschliessende Worte und weiterführende Links:
Soweit also mein Versuch, diese komplexe Thematik in diesem Beitrag zusammenzustellen. Falls Fragen auftauchen sollten, wie nun ein bestimmtes Szenario konkret lizenziert werden müsste, dürfte der einzig sinnvolle Ansprechspartner wohl der jeweilige Handelspartner („Large Account Reseller LAR“) sein, über den die Volumenlizenzen beschafft werden.
Zum Abschluss dieses Beitrages nun noch einige weiterführende Links:
- Die Lizenzierung von „Windows Server 2008 R2“ erklärt Microsoft auf deutsch unter: http://www.microsoft.com/germany/windowsserver2008/r2-lizenzierung.mspx
- Informationen zur Lizenzierung von virtualisierten Serversystemen liefert Microsoft auf deutsch unter: http://www.microsoft.com/germany/server/virtualisierung/lizenz/servervirtualisierung.mspx
- Die Clientzugriffslizenzen erklärt Microsoft auf deutsch unter: http://www.microsoft.com/germany/Licensing/about-licensing/client-access-license.aspx
- Zu den CAL-Suiten gibt es eine englischsprachige Seite von Microsoft: http://www.microsoft.com/calsuites/en/us/default.aspx
- Das 28-seitige PDF-Dokument „Die Microsoft Produktbenutzungsrechte schnell erklärt“ von Microsoft gibt einen Ãœberblick über die Produktnutzungsrechte: http://download.microsoft.com/download/9/6/8/968CBB7B-A07A-4303-AB57-C50B7C62931A/PUR_explained_german_1109.pdf
- Das aktuelle Dokument „Produktnutzungsrechte“ von Microsoft ist auch auf Deutsch zu finden unter: http://www.microsoftvolumelicensing.com/userights/DocumentSearch.aspx?Mode=3&DocumentTypeId=1
- Die aktuelle „Produktliste“ von Microsoft ist auch auf Deutsch zu finden unter: http://www.microsoftvolumelicensing.com/userights/DocumentSearch.aspx?Mode=3&DocumentTypeId=3
- Die englischsprachige Hauptseite zur Volumenlizenzierung von Microsoft, über welche auch Lizenzierungsinformationen zu einzelnen Produkten abrufbar sind, ist zu finden unter: http://www.microsoftvolumelicensing.com/
Abgelegt unter: Der gelöste Fall | Tags: 0x800706BE, Features, Roles, Server2008R2, ServerManager
Als ich auf einem unserer Server (mit Windows Server 2008 R2) per Remote-Desktop einloggte, wurde wie üblich gleich der Server Manager gestartet. Doch anstatt mir irgendwelche Daten unter „Roles“ und „Features“ zu zeigen, meinte dieser lapidar: „Error.“ Bei den Fehlerdetails wird folgendes angegeben: „Unerwarteter Fehler beim Aktualisieren von Server-Manager: Der Remoteprozeduraufruf ist fehlgeschlagen. (Ausnahme von HRESULT: 0x800706BE)“. [engl.: „Unexpected error refreshing Server Manager: The remote procedure call failed (Exception from HRESULT: 0x800706BE)“]
Server Manager Error: Exeption from HRESULT: 0x800806BF
Als ich nach Hinweisen zu diesem Fehler suchte, der übrigens auf unseren Servern mit Windows Server 2008 R2 schon mehrfach zugeschlagen hat, fand einen Thread in den Windows Server Foren von Microsoft, bei welcher dieses Problem diskutiert wurde. Als Lösung wird dort folgendes vorgeschlagen:
Please follow the instructions from the following website to download and run System Update Readiness Tool on your computer.
http://support.microsoft.com/kb/947821If the issue is not resolved after running the tool, please check the result of CheckSUR.log (%windir%\logs\cbs\checksur.log) and ServerManager.log (inside C:\Windows\Logs)
Obwohl ich mir auf Anhieb keinen Reim auf die Zusammenhänge zwischen einem „System Update Readiness Tool“ und einem nicht funktionierenden Server Manager machen konnte, schaute ich mir den KB-Artikel 947821 an und lud mir das dort referenzierte und knapp 100MB grosse Tool für den Server 2008 R2 herunter und startete dieses per Doppelklick, worauf der „Hotfix for Windows (KB947821)“ installiert wurde. Dies dauerte eine geraume Zeit und wurde schlussendlich mit „Installation complete“ quittiert.
Darauf startete ich erneut den Server Manager: Fehlanzeige! Immer noch dieselbe Fehlermeldung! Also konsultierte ich das beschriebene CheckSUR.log, das im Verzeichnis %windir%\logs\cbs zu finden ist.
CheckSUR.log
In diesem Log stachen mir zwei Dinge ins Auge: Erstens wurde eine „CBS MUM Corruption 0x00000000“ in einem bestimmten File gefunden (was auch immer das heissen soll), zweitens wurde weiter unten genau zum betreffende MUM-File (und dem offenbar dazugehörenden CAT-File) angemerkt, dass das „Repair File“ fehle:
Unavailable repair files:
servicing\packages\Package_for_KB2387149_RTM~31bf3856ad364e35~amd64~~6.1.1.1.mum
servicing\packages\Package_for_KB2387149_RTM~31bf3856ad364e35~amd64~~6.1.1.1.cat
Was die zwei fehlenden Repair-Files mit meinem nicht funktionierenden Server Manager zu tun haben sollten, war mir keineswegs klar. Und was diese Meldungen nun tatsächlich bedeuten sollten, hatte ich erst recht keinen blassen Schimmer. Also suchte ich weiter und fand die Anleitung „Advanced guidelines for diagnosing and fixing servicing corruption“ bei MSDN, die mir hier etwas weiterhalf: Diese Meldungen sollten wohl heissen, dass das Systemupdate-Vorbereitungstool zwei Dateien eines Patches erkannte, die wohl nicht korrekt im Servicing-Store abgelegt waren:
If you get the Unavailable repair files message, this indicates that some of the inconsistent files found by the tool cannot be fixed as the correct versions of the replacement files are not carried by the tool.
Und zum Glück sind in dieser Anleitung auch die Schritte zur Lösung des Problemes beschrieben:
Get the files required from other sources. The options available can be found in the “Options for obtaining files†section below.
Da es sich bei den fehlenden Files offenbar um Dateien zum Update KB2387149 handelt, habe ich dieses Update – es handelte sich in meinem heutigen Fall um das Sicherheitsupdate für den Windows Server zum Security Bulletin MS10-074, welches am 11. Oktober 2010 publiziert worden ist – manuell heruntergeladen und in einen temporären Ordner entpackt, wobei die Platzhalter <…> in nachfolgendem Befehl mit den passenden Werten zu ersetzen und der Ordner, wohin die Files ausgepackt werden sollen, vorgängig anzulegen sind:
expand <...pfad zu...>\<...Update...>.msu /f:* c:\<...Auspackziel...>
Als nächstes habe ich das CAB-File entpackt, welches nun in diesem Ordner zu finden war:
expand <...pfad zu...>\<...Update...>.cab /f:* C:\<...Auspackziel...>
Und da lagen nun in diesem zweiten Ordner die beiden Dateien, die im CheckSUR.log als „unavailable“ bezeichnet wurden, vor mir. Wie die Anleitung „Advanced guidelines for diagnosing and fixing servicing corruption“ beschreibt, kopierte ich die beiden Dateien nun in das passende Verzeichnis:
All files of type *.mum and *.cat should be placed in the %windir%\Temp\CheckSUR\servicing\packages directory
Danach habe ich das Systemupdate-Vorbereitungstool erneut gestartet und die Dateien wurden sauber in den Servicing-Store übernommen, wie das neue CheckSUR.log bestätigt:
CheckSUR.log bestätigt erfolgreiche Reparatur
Auch der Server-Manager konnte sofort danach wieder ohne Probleme ausgeführt werden:
Der Server Manager funktioniert wieder!
Weshalb der Server-Manager nicht mehr funktionieren wollte, habe ich immer noch keinen blassen Schimmer… Und weshalb dieses Problem überhaupt aufgetreten ist, weiss ich noch weniger. Tatsache ist einfach, dass ich dieses Problem bisher noch jedesmal auf genau diese Weise lösen konnte:
- Als ich das erste Mal mit diesem Problem konfrontiert wurde, habe ich Stunden damit verbracht, den Server Manager des betroffenen Servers wieder funktionstüchtig zu machen.
- Als dieses Problem zum zweiten Mal zuschlug, konnte ich mit Hilfe einiger Notizen vom ersten Fall das Problem rascher lösen, wobei ich mir dabei detailliertere Aufzeichnungen machte.
- Ich hoffe, das es nun mit Hilfe dieses Beitrages, den ich heute anlässlich des dritten Vorkommnisses nebenher erstellt habe, auch weiteren Lesern gelingt, das offenbar häufiger auftretende Problem zügig lösen zu können.
Nachtrag vom 9.11.2010:
Heute hat Microsoft den KB-Artikel 2461206 „You are unable to view Roles and Features and receive error code 0x800706BE in Server Manager“ zu dieser Problematik publiziert.