Abgelegt unter: Erkenntnisse | Tags: ActiveDirectory, Replication, SCCM, SiteHierarchy
Die Frage tauchte auf, ob es möglich sei, SCCM-Sites über Domänengrenzen zu einer Hierarchie zu verbinden. So sollen z.B. alle Pakete der übergeordneten Site (Central Site) für die Systeme der untergeordneten Site (Primary Site) bereitgestellt werden und die Systeme der untergeordneten Site aus der übergeordneten Site mitverwaltet werden. Doch die unterzuordnende Site befindet sich in einer anderen Active-Directory-Domäne, ja sogar in einem anderen Forest. Und dass zwischen den beiden Forests keine Vertrauensstellungen existieren, macht die Angelegenheit noch interessanter. Ist so ein Szenario überhaupt machbar?
Um die Antwort gleich vorweg zu nehmen: Ja, es geht. Und dies sogar erstaunlich einfach!
Nachfolgend werden die dazu notwendigen Schritte beschrieben, dabei gehe ich davon aus, dass beide Siteserver bereits mit derselben Version von SCCM installiert sind.
Notwendige Vorbereitungen
In vertrauten Umgebungen werden normalerweise die Computerobjekte der Site-Server in die passende Gruppe(n) aufgenommen, um die Kommunikation zwischen den Site-Servern zu ermöglichen. Genau dies ist jedoch in diesem Szenario nicht möglich, da das Computerobjekt des anderen Site-Server in der unvertrauten Domäne nicht sichtbar ist. Aus diesem Grund muss in jeder Domäne ein passendes Benutzerkonto erstellt werden, das für die Kommunikation verwendet werden kann.
Ich erstellte deshalb folgende beiden Benutzerkonti in der jeweiligen Domäne(die <Platzhalter> wären mit den passenden Werten zu ersetzen)
- <Parentdomain>\SCCM-Sender-<Child>-to-<Parent>
- <Childdomain>\SCCM-Sender-<Parent>-to-<Child>
Auf jedem Siteserver existiert eine lokale Gruppe mit dem Namen „SMS_SiteToSiteConnection_<Sitecode>“, in welche das soeben generierte AD-Benutzerkonto aufzunehmen ist, womit für die Vergabe der notwendigen Zugriffsrechte an diese Benutzerkonti gesorgt wird. Auch dies war mit wenigen Mausklicks erledigt.
Definition der Sender
Nun können die Sender konfiguriert werden, welche für die Ãœbermittlung der Daten sorgen. Dazu wird in der SCCM-Konsole zu „Site Database“, „<Site>“, „Site Settings“, „Site Settings“, „Addresses“ navigiert und dort eine neue „Standard Sender Address“ erstellt:
Die Definition der "Standard Sender Address"
Wichtig ist hier einfach, dass wir beim Sender der Parent-Site das AD-Konto der Child-Domäne konfigurieren und beim Sender der Childsite das entsprechende Konto der Parent-Site.
Austausch der Schlüssel
Innerhalb von vertrauten Active-Directory-Forests können die Sites ihre öffentlichen Schlüssel selbständig austauschen, dies muss nun in diesem Szenario manuell nachgeholt werden, da ansonsten die Sitehierarchie nicht erstellt werden kann. Dazu muss auf dem Siteserver der zukünftigen Parent-Site der Befehl
preinst.exe /KEYFORCHILD
Wir starten dazu eine CMD.exe mit Administratorrechten und wechseln ins Verzeichnis <Path-to>\Microsoft Configuration Manager\bin\i386\00000409, wo preinst.exe zu finden ist und setzen den genannten Befehl ab. Damit wird im Root-Verzeichnis der betreffenden Festplatte die Key-Datei „<Parentsitecode>.ct5“ erstellt.
Auf dem Siteserver der zukünftigen Child-Site muss nun der entsprechende Befehl
preinst.exe /KEYFORPARENT
ausgeführt werden, womit auf diesem im Rootverzeichnis der betreffenden Festplatte die Key-Datei „<Childsitecode>.ct4“ erstellt wird.
Randbemerkung: Als ich dies im konkreten Falle durchführen wollte, wurde ich bei der Ausführung von preinst.exe plötzlich mit folgender Fehlermeldung konfrontiert: „This site’s public key has not been created, and configured yet. Therefore, keys cannot be dumped from this site. Please allow Hierarchy Manager to correct the situation, and try again.„ Diese Meldung lässt ein gröberes Problem befürchten, hat aber eine einfache Ursache: Die CMD.exe wurde nicht mit Administrator-Rechten gestartet. Mit Administrator-Rechten funktionierte es problemlos…
Die beiden Key-Files müssen nun manuell ausgetauscht werden:
Der öffentliche Schlüssel der Child-Site muss auf der Parent-Site importiert werden. Dazu muss die Datei <Childsitecode>.CT4 in den Ordner <Path-to>\Microsoft Configuration Manager\inboxes\hman.box auf dem Parentsite-Server kopiert, die <Parentsitecode>.CT5 in den entsprechenden Ordner der Childsite kopiert werden.
Die Komponente „SMS_Hierarchy_Manager“ importiert nun den jeweiligen Schlüssel, was in <Path-to>\Microsoft Configuration Manager\logs\hman.log protokolliert wird.
Damit ist nun das Gröbste geschafft, nun muss nur noch in der Childsite die entsprechende Parent-Site konfiguriert werden, wozu wir in den „Properties“ der Childsite den Button „Set Parent Site“ finden. Sobald hier die Parent-Site konfiguriert wurde, beginnen die Siteserver mit dem Austausch der Daten, was z.B. in folgenden Protokollen mitverfolgt werden kann:
- hman.log
- sender.log
- replmgr.log
- objreplmgr.log
- distmgr.log
- …
Tauchen dort keine Fehlermeldungen auf und die Replikation läuft wunschgemäss, ist der Sprung über die Domänengrenze geschafft und die Childsite in der fremden AD-Domäne kann nun wie jede andere Childsite von der Parent-Site her verwaltet werden.
Abgelegt unter: Der gelöste Fall | Tags: KB2416472, KB2473228, MS10-070, SCCM, SoftwareUpdates, Update
Vor zwei Wochen erreichten uns – während ich in den Ferien weilte - mehrere Meldungen von Benutzern, die allesamt dasselbe Problem feststellten, was dann auch von Administratoren-Kollegen verifiziert werden konnte:
Download hängt stundenlang bei 66%
Auf allen betroffenen Geräten blieb der Download des „Sicherheitsupdate für Microsoft .NET Framework 4“ (MS10-070/KB2416472) bei 66% stehen, worauf sich in dem abgebildeten Dialog stundenlang nichts mehr bewegte, bis die Benutzer entnervt auf „Cancel“ klickten. Leider dauerte es dann jeweils nicht allzulange, bis die Installation des Updates erneut gestartet wurde, da dieses unseren Client zur Installation zugewiesen ist und die entsprechende Zeitpunkt für das Assignment bereits deutlich in der Vergangenheit liegt.
Dieser Effekt trat im laufenden Betrieb der Clients auf und hat nichts mit den Problemen beim Schritt „Install Updates“ in Tasksequenzen zu tun, den wir in unserer Umgebung leider auch beobachten.
Auf den betroffenen Geräten konnte – wie meine Admin-Kollegen rasch herausfanden – das fragliche Update als Workaround problemlos über Microsoft-Update installiert werden, worauf dann die nervenden Installationsversuche durch den Configuration Manager Client aufhörten.
Zurück aus den Ferien habe ich dann versucht, die Ursache dieser Downloadprobleme zu ergründen und wurde auch recht rasch fündig. Die Geschichte des betroffenen Updates ist relativ lang; so ist auch im entsprechenden Security-Bulletin MS10-070 zu lesen, dass dieses inzwischen viermal überarbeitet wurde.
Beim Update KB2416472 handelt es sich um ein gebündeltes Update, d.h. unter dem Eintrag dieses Updates werden in der Konsole mehrere Updates aufgelistet. Und genau hier lag das Problem:
Unvollständiges Update zum KB2416472
Wie man im obigen Screenshot erkennen kann, wurden in der Konsole drei Updates zum KB2416472 aufgelistet, dabei handelt es sich um die Varianten für x86-, x64- und Itanium-Systeme. Alle drei Updates werden als „Downloaded: yes“ ausgewiesen, wie das der grüne Rahmen zeigt. Betrachtet man nun jedoch die „Content Information“ zu einem der drei Updates, kann man sehen, dass hier mehrere Updates gebündelt sind. Und wie das im roten Rahmen zu sehen sind, sind zwei dieser drei Updates heruntergeladen, das dritte jedoch nicht. „Zwei von drei Updates?“ Genau: „66%!“
Wie zudem im blauen Rahmen zu sehen ist, hat das fehlende Update zudem eine deutlich höhere Content-ID als die anderen beiden, was den Schluss nahelegt, dieses erst später nachgeliefert wurde. Und das passt auch zu unseren Beobachtungen: Schliesslich wurde MS10-070 bereits am 28. September 2010 publiziert und unzählige unserer Clients konnten dieses Update in den vergangenen Monaten problemlos installieren. Erst in jüngster Zeit wurden hier Probleme gemeldet.
Die jüngsten Installationsversuche dieses Updates schlugen also fehl, da die Clients versuchten, auch den dritten, nicht verfügbaren Teil beim Distribution Point abzuholen. Dies sieht man bestens im UpdatesHandler.log eines betroffenen Gerätes:
Bundle update (8b86deae-c862-4405-8fca-3a2dcfae1de0) is requesting download from child updates for action (INSTALL)        UpdatesHandler        09.02.2011 09:33:12        2876 (0x0B3C)
Starting download on action (INSTALL) for Update (57529fa0-4c49-458f-bd14-08c1c87679d7)        UpdatesHandler        09.02.2011 09:33:12        2876 (0x0B3C)
Contents already available for the update (bfa8bdd3-cf5c-44e9-b937-98aad87e0451).        UpdatesHandler        09.02.2011 09:33:12        2876 (0x0B3C)
Contents already available for the update (ee89b5c2-ac3b-4216-9bb2-e0654ef63626).        UpdatesHandler        09.02.2011 09:33:12        2876 (0x0B3C)
CancelJob received from SDM.        UpdatesHandler        09.02.2011 15:35:52        4908 (0x132C)
So zeigt dieser Logauszug, dass das „Bundle Update“ den Download der „Child-Updates“ verlangt. Zwei Inhalte sind „already available“, der dritte Inhalt soll jedoch heruntergeladen werden. Doch dann geschieht nichts mehr, bis der der betroffene Benutzer unzählige Stunden später auf „Cancel“ geklickt hat.
Dies erklärt auch, weshalb das Problem auch durch manuelle Installation via Microsoft Update gelöst werden konnte, denn dort dürften ja – im Gegensatz zu unserem Distribution Point – alle benötigten Files vorhanden gewesen sein.
Die definitive Lösung dieses Problems war nun trivial: Ich habe nun die betreffenden Updates zum KB2416472 nochmals heruntergeladen und die Distribution Points aktualisiert. Danach waren die Updates komplett, wie im grünen Rahmen zu sehen ist:
Vervollständigtes Update zum KB2416472
Auch war nun das Update mit der im Protokoll genannten GUID 57529fa0-4c49-458f-bd14-08c1c87679d7 tatsächlich auf unseren Distribution Points zu finden, die Hänger bei 66% waren beseitigt.
Beim zusätzlichen Update handelte es sich übrigens im konkreten Falle um das „Update für Microsoft .NET Framework 4 für Probleme bei ausstehenden Dateiumbenennungsvorgängen“ zum Microsoft KB-Artikel 2473228.
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: Bluescreen, Harddisk Failure, KB307545, LSASS, RecoveryConsole, SATA, WindowsXP
Ein Besitzer eines Notebooks vom Typ HP Pavilion dv9000 meldete sich bei mir und fragte nach Hilfe: Er könne Windows nicht mehr starten, stattdessen erscheine die Meldung, dass die Festplatte überprüft werden müsse. Lasse er dies zu, beginne die Festplattenüberprüfung, bliebe jedoch kurz darauf stehen, worauf stundenlang nichts mehr geschehe. Breche er die Festplattenüberprüfung ab, erscheine kurz darauf eine Meldung mit weisser Schrift auf blauem Grund:
STOP: c0000218 {Registrierungsdatei fehlgeschlagen} Die Registrierung konnte die Struktur(datei): \SystemRoot\System32\Config\SOFTWARE oder ihr Protokoll oder ihre Alternative nicht laden
Rasch war diese Beobachtung reproduziert und nach einer kurzen Suche fand ich den Microsoft KB-Artikel 307545, der genau diese Meldung beschreibt. „Das Problem scheint bekannt, die Reparaturanleitung ist in der Microsoft Knowledge Base zu finden“, sagte ich, „also nix wie los!“
Die vom Benutzer mitgelieferte Windows-CD wurde eingelegt, von dieser gebootet und bei der entsprechenden Dialogmeldung mit „R“ die Wiederherstellungskonsole gestartet. Aber oha:
Es konnten keine installierten Festplattenlaufwerke gefunden werden.
Stellen Sie sicher, dass alle Festplattenlaufwerke eingeschaltet und richtig mit dem Computer verbunden sind, und dass alle Hardwareeinstellungen für die Festplatten korrekt sind. Hierzu können Sie beispielsweise ein Diagnose- oder Installationsprogramm des Herstellers ausführen.
Die Installation kann nicht fortgesetzt werden. Drücken Sie die F3-Taste, um die Installation abzubrechen.
Hoppla! Ist die Festplatte derart komplett hinüber, dass sie nicht einmal gefunden wird? Nein, da es sich um ein HP Pavillion dv9000 (genauer gesagt das Modell „dv9097ea“) handelt, sind darin SATA-Disken eingebaut. Und mit SATA-Disken kann die Installationsroutine von XP von Haus aus nicht umgehen, weshalb eine entsprechende Treiberdiskette benötigt wird. Und genau diese war natürlich nicht vorhanden…
Also war ein Besuch auf der Homepage von Hewlett-Packard fällig, wo ich nach dem passenden Treiber suchte: Aber nix da, das Modell „dv9097ea“ ist unbekannt: „Wir konnten Ihr Produkt nicht finden“. Doch nach einem expliziten Wechsel zur Homepage „Schweiz – Deutsch“ von HP konnte dann das fragliche Gerät tatsächlich lokalisiert werden und der passende Treiber „für den „Intel SATA AHCI-Controller“ lokalisiert werden. Flugs lud ich auf meinem Desktopsystem, das unter Windows Vista läuft, das Treiberpaket „sp32478.exe“ herunter, kramte mein altes USB-Floppy hervor und suchte nach einer leeren Diskette.
Das Treiberpaket wurde entpackt und die Generierung der Treiberdiskette gestartet. Doch kurz darauf durfte ich auf meinem Vista-System eine weitere Fehlermeldung bestaunen:
„Windows Error N.5Â Zugriff verweigert“.
Nach einer längeren Suche fand ich in einem Forum folgenden Hinweis:
When you load up the WinImage file (the exe for creating disk image) make sure you run it without having a floppy in the drive. It will search, and come back with floppy not found. Now insert the floppy disk, and click retry. And voila, it writes the image to the disk!!!!
Tatsächlich: Auch wenn dieser Tipp ziemlich auf den ersten Blick ziemlich abstrus erschien, klappte auf diesem Weg die Erstellung der Diskette. Allerdings nicht im ersten Versuch, denn ich musste ziemlich suchen, bis ich in meinem Fundus noch eine Diskette fand, auf welche sich das Image tatsächlich extrahieren liess. Tja, „neue 3.5-Zoll-Disketten“ ist nichts, was bei mir noch im Dutzendpack herumliegen würde…
Nun ging es also zurück ans Notebook, diesmal bewaffnet mit USB-Floppy und passender Diskette. Auf diese Weise bekam ich nun den benötigten SATA-Treiber eingebunden und konnte nun auf dem Gerät die Wiederherstellungskonsole starten. Und schon stand ich vor der nächste Hürde: „Wie lautet das Administrator-Passwort“?
Rasch waren drei Fehlversuche erreicht und das Gerät startete neu. Nach einigen weiteren, zeitaufwendigen Extrarunden stellte sich dann heraus, dass das Administrator-Passwort schon dasjenige war, welches der Benutzer ursprünglich vermutete, allerdings war dessen Aussage „besteht nur aus Kleinbuchstaben“ ziemlich falsch.
Endlich konnte ich also loslegen und führte die Befehle aus, die im Microsoft KB-Artikel 307545 im Abschnitt 1 unter Punkt 5 dokumentiert sind. Funktionierte fast alles bestens, doch beim allerletzten Befehl brach der Kopiervorgang der Datei „C:\windows\repair\default“ mit einer Fehlermeldung ab. Tja, aber glücklicherweise wurde ja mit dem ersten Set von Befehlen ein Backup der Dateien erstellt, welches ich dann sofort zurückkopierte.
Aber da war ich wieder am Anfang angelangt: Beim Startversuch wurde die Festplattenüberprüfung gestartet, welche weiterhin kurz nach dem Start hängenblieb. Brach man diese ab, wurde man sogleich mit einem Bluescreen bestraft. Aber immerhin wusste ich nun, dass ich drei Sätze der Registrierungsdateien hatte: Die defekten Registrierungsdateien in „C:\windows\system32\config“, die unbrauchbaren in „C:\windows\repair“ und eine Kopie der defekten in „C:\Windows\tmp“. Was nun?
Ich startete wieder die Wiederherstellungskonsole und versuchte, dort „chkdsk.exe“ auszuführen, doch auch in der Wiederherstellungskonsole blieb chkdsk bei 26% hängen und machte nicht mehr weiter. Also versuchte ich es mit einer Reparaturinstallation. Diese startete problemlos, bis zum Punkt „Festplatte wird überprüft“. Dass diese Prüfung bei 26% hängenblieb, und die Reparaturinstallation nicht mehr weitermachen wollte, wunderte mich schon fast nicht mehr.
Tja, da war ich ziemlich ratlos. Die Anleitung im Microsoft-KB-Artikel war nicht umsetzbar, chkdsk.exe blieb andauernd hängen, die Reparaturinstallation funktionierte auch nicht. Was konnte ich noch tun? War wirklich die Festplatte hinüber?
Mehr zufällig schaute ich mal noch in den BIOS-Einstellungen herum und entdeckte da die Option „Native SATA-Support“, die auf „enabled“ stand. So änderte ich diese auf „disabled“ und startete das Gerät neu. Wiederum wurde beim Starten von Windows die Festplattenüberprüfung angemahnt, und – siehe da! – diese blieb nicht mehr hängen. Unzählige Meldungen der Art „Fehler im Index … der Datei … werden berichtigt“ und weitere Meldungen ratterten vorüber, dann war die Festplattenprüfung abgeschlossen, Windows startete durch und…
… die nächste Fehlermeldung war auf dem Bildschirm zu lesen:
Lsass.exe: „Einem Dienst oder einer Funktion wurde ein ungültiger Parameter übergeben“.
Die Recherche förderte einzig zu Tage, dass man sich doch bitte schön an den eingangs zitierten Microsoft KB-Artikel 307545 halten solle. Einfach die fünf Registrierungsdateien wieder aus dem Repair-Verzeichnis ins Config-Verzeichnis kopieren, dann würde es schon wieder gehen. Tat es aber im vorliegenden Falle nicht, denn egal wieviele Male die Dateien noch kopierte: Auch mit frisch aus dem Repair-Verzeichnis kopierten Dateien gabs erneut den LSASS-Fehler, diejenigen im TMP-Verzeichnis waren von Anfang an defekt und weitere Kopien gabs schlicht und einfach nicht.
Hier war nun das Ende der Fahnenstange erreicht, denn diese Lsass-Fehlermeldung tauchte nun auf, egal was ich versuchte: Normaler Windows-Start, Start im abgesicherten Modus, Start im abgesicherten Modus (nur Eingabeaufforderung). Selbst beim Versuch, eine Reparaturinstallation durchzuführen, tauchte die LSASS-Fehlermeldung nach dem ersten Neustart auf, mit welchem vom textbasierten Setup in die graphische Oberfläche gewechselt wird, worauf die Reparaturinstallation abbrach. Tja: Die weisse Fahne wurde gehisst, eine Neuinstallation war trotz allen Reparaturversuchen fällig!
Fazit:
Manchmal hat man einen Microsoft KB-Artikel vor sich, bei dem man davon ausgeht, dass er exakt zum aktuellen Problem passt:
- Die beschriebene Fehlermeldung passt exakt,
- der Artikel passt zum vorhandenen Betriebssystem,
- die beschriebene Lösung scheint sinnvoll zu sein.
- und Erinnerungen im Hinterkopf lassen vermuten, dass man derartige Probleme doch schon früher mehrfach und erfolgreich auf exakt diese Art und Weise gelöst hat.
Frohen Mutes startet man also mit der Reparatur. Und dann kommt doch alles anders…
Epilog:
Nach einer Neuinstallation von Windows XP habe ich die Festplatte – es handelt sich um eine Western Digital WD3200BEVT (d.h. nicht um die Platte, mit welcher das Notebook von HP ursprünglich ausgeliefert wurde) – mit der Windows-Version der „Western Digital Data LifeGuard Diagnostics“ (die DOS-Version bzw. das bereitgestellte ISO-Image wollten sich auf keine Art und Weise starten lassen) auf vorhandene Probleme untersucht:
Test Option:Â Â Â QUICK TEST
Model Number:Â Â Â WDC WD3200BEVT-00ZAT0
Unit Serial Number:Â Â Â WD-WX80A89X….
Firmware Number:Â Â Â 01.01A01
Capacity:Â Â Â 320.07 GB
SMART Status:Â Â Â PASS
Test Result:Â Â Â FAIL
Test Error Code:Â Â Â 06-Quick Test on drive 1 did not complete! Status code = 07 (Failed read test element), Failure Checkpoint = 97 (Unknown Test) SMART self-test did not complete on drive 1!Test Option:Â Â Â EXTENDED TEST
Model Number:Â Â Â WDC WD3200BEVT-00ZAT0
Unit Serial Number:Â Â Â WD-WX80A89X….
Firmware Number:Â Â Â 01.01A01
Capacity:Â Â Â 320.07 GB
SMART Status:Â Â Â PASS
Test Result:Â Â Â FAIL
Test Error Code:Â Â Â 08-Error was detected while repairing bad sectors.
Diese Testergebnisse sind deutlich genug: Die Festplatte dürfte kaputt sein, ein Austausch ist fällig.
Nachtrag (17.01.2011): Inzwischen habe ich auch eine entsprechende Antwort vom Western Digital Support erhalten: Bei den festgestellten Testergebnissen sei die Festplatte tatsächlich ein Garantiefall und solle über den Verkäufer oder direkt bei WD ausgetauscht werden.
Nachdem wir in der letzten Zeit problemlos unzählige neue Geräte via SCCM installieren konnten, erreichte mich heute morgen der Hilferuf eines Kollegen: „Was gestern noch ging, wolle heute nimmer funktionieren…“ Er erhalte folgende Fehlermeldung, kurz nachdem die zu installierende Maschine das WindowsPE gestartet habe:
The certificate associated with this media has expired!
„Aber ich benutze doch gar kein Medium, sondern habe via PXE gebootet“, fügte dann der Kollege noch hinzu. So machte ich mich auf die Fehlersuche und warf zuerst mal einen Blick in den Site Status, wo sich der Component Status des „SMS_PXE_SERVICE_POINT“ tief rot zeigte:
Komponente "SMS_PXE_SERVICE_POINT" meldet Errors!
Ein Blick in die dazugehörenden Status Messages zeigte dann sofort, dass es offenbar ein Problem mit dem entsprechenden PXE-Zertifikat gibt:
The SMS PXE Certificate used for PXE clients is not valid. Please provide a valid certificate.
Ich schaute mir dann das entsprechende Zertifikat an und siehe da:
Der 30. November 2011 war gestern!
Die Ursache der Fehlermeldung war nun sonnenklar. Das bisherige Zertifikat war genau bis gestern abend um 22:30 Uhr gültig. Kein Wunder also, dass heute entsprechende Fehlermeldungen generiert werden. Aber wie erneuert man das PXE-Zertifikat? Mir schwante böses: seitenlange Technet-Artikel mit unzähligen vorzunehmenden Schritten, …
Doch nein: Nichts dergleichen war nötig. Ein kurzer Blick in die Eigenschaften des „ConfigMgr PXE service point“ zeigte mir den Ablaufzeitpunkt des Zertifikates von gestern abend:
Eigenschaften von "ConfigMgr PXE service Point"
„Da könnte man doch einfach mal probieren, ein neues Datum zu setzen…“, war mein erster Gedanke, was ich sogleich machte: Und siehe da:
Ein neues Zertifikat wurde erstellt!
Das bisherige Zertifikat wurde auf „blocked“ gesetzt, daneben wird nun ein neues Zertifikat aufgelistet. Und schon funktionieren auch die Installationen via PXE wieder… Hoffentlich weiss ich Anfangs 2012 noch, was zu tun ist, wenn dasselbe „Problem“ wieder auftaucht…
Abgelegt unter: Erkenntnisse | Tags: Collection, SCCM, SoftwareDistribution, x64, x86
Wenn ein Hersteller eine neue Version einer von uns verwendeten Software bereitstellt, gehen wir immer nach demselben Schema vor, falls wir die neue Softwareversion bereitstellen wollen:
- Wir erstellen ein aktualisiertes Paket in der Testumgebung und testen dieses. Dabei kontrollieren wir nicht nur die Funktionstüchtigkeit einer Neuinstallation, sondern überprüfen auch, ob bestehende Installationen vonVorversionen der betreffenden Software aktualisiert werden können.
- Sobald wir von der Tauglichkeit des neuen Paketes überzeugt sind, stellen wir dieses als zusätzliches Paket in der Produktionsumgebung bereit. Das Paket der Vorversion bleibt daneben unverändert erhalten.
- Ab diesem Zeitpunkt wird dann normalerweise auf den Clients die neue Version installiert, doch ein Rückgriff auf die Vorversion wäre nötigenfalls immer noch möglich, falls mit der neuen Version unerwartete Probleme auftauchen sollten.
- Zu einem bestimmten Zeitpunkt – bei uns normalerweise gebündelt mit der monatlichen Microsoft-Updaterunde - wird dann die Aktualisierung der auf den Clients installierten Vorversionen in Angriff genommen. Hierzu wird unseren Benutzern die Installation des Updates eine Woche lang angeboten; während dieser Zeit kann der Benutzer sich den für ihn geeigneten Installationszeitpunkt selber auswählen. Danach wird die Installation des Updates per Assignment durchgesetzt.
- Sobald die Aktualisierung aller Clients abgeschlossen ist, kann das veraltete Paket der Vorversion entsorgt werden. (Aber gerade bei diesem Schritt lassen wir uns üblicherweise tüchtig Zeit… )
Wie man Softwarepakete via SCCM verteilt, dürfte wohl jedem Administrator bekannt sein, der sich mit diesem Thema beschäftigt. Doch wie funktioniert der Schritt „Aktualisierung installierter Vorversionen“ genau?
Hierzu erstellen wir jeweils eine Collection, an welche die Installation des Updates dann advertised bzw. assigned werden kann. Die Mitgliedschaft in dieser Collection wird jeweils anhand einer Query definiert, welche bei uns immer folgenden Aufbau hat: „Gesucht sind alle Clients, die eine bestimmte Software installiert haben, jedoch nicht in der von uns aktuell gewünschten Version“. Wie dies in einem konkreten Fall aussieht, möchte ich anhand des kürzlich publizierten Update „Java Version 6 (Update 22) zeigen:
Ein x86-Client mit einer veralteten Java-Version
Wir erkennen hier im Bereich „Programme und Funktionen“ in der Systemsteuerung eines Clients, dass auf diesem noch das Update 20 von Java installiert ist. Genau diese Information können wir auch für folgende WQL-Query zur Definition einer Collection in SCCM verwenden:
select SMS_R_SYSTEM.ResourceID, SMS_R_SYSTEM.ResourceType, SMS_R_SYSTEM.Name, SMS_R_SYSTEM.SMSUniqueIdentifier, SMS_R_SYSTEM.ResourceDomainORWorkgroup, SMS_R_SYSTEM.Client
from SMS_R_System
inner join SMS_G_System_ADD_REMOVE_PROGRAMS
on SMS_G_System_ADD_REMOVE_PROGRAMS.ResourceID = SMS_R_System.ResourceId
where SMS_G_System_ADD_REMOVE_PROGRAMS.DisplayName like "Java%"
and SMS_G_System_ADD_REMOVE_PROGRAMS.Version not like "6.0.220%"
Wir suchen also nach Programmen mit der Zeichenkette „Java“ am Anfang des Anzeigenamens, die nicht eine Versionsbezeichnung haben, welche mit „6.0.220“ beginnt. Bei der Versionsnummer gilt es zu beachten, dass es sich hier um eine Zeichenkette und nicht um einen Wert handelt; eine Query in der Form „Version < 6.0.220“ funktioniert nicht. Dass man auch bei der Wahl des Suchbegriffes im Anzeigenamen die nötige Vorsicht walten lassen sollte, dürfte sich von selbst verstehen. Schliesslich möchte man ja nicht ein Java-Update auf einen Client installieren, weil dort auch noch zufälligerweise irgendein „Java-Free-Editor“ (und dummerweise leider nicht in der Version 6.0.220.7) vorhanden ist. Den Suchbegriff sollte man also möglichst spezifisch definieren, nötigenfalls lässt sich auch noch ein Hersteller mit einer weiteren Klausel in der Form „and ..._ADD_REMOVE_PROGRAMS.Publisher like "...%"“ einbeziehen.
Dies funktionierte im vorliegenden Fall bestens und schon hatten wir die passende Collection aller Clients, welche dringend ein Java Update nötig hätten, bereit. Wirklich?
Nein, leider nicht ganz. Denn wir haben nicht nur 32bit (d.h. x86)-Systeme im Einsatz, sondern es sind auch 64bit (d.h. x64)-Systeme vorhanden. Und da sieht das Ganze leicht anders aus:
Ein x64-Client mit zwei veralteten Java-Versionen
Wir erkennen in diesem Screenshot, dass auf diesem Client zwei Java Versionen installiert sind; zwar in beiden Fällen die Version 6u20, aber einmal als 32bit- und einmal als 64bit-Variante. Also galt es dafür zu sorgen, dass überall dort, wo die 32bit-Version installiert ist, auch das 32bit-Update installiert wird und überall dort, wo die 64bit-Version vorhanden ist, auch das entsprechende 64bit-Update geliefert wird.
Leider passt die oben angegebene WQL-Query auch auf „Java(TM) 6 Update 20 (64-bit)“. Und wir beabsichtigen nicht, auf allen Clients die 32bit-Version nachzuinstallieren, auf denen nur die 64bit-Variante installiert ist. Zudem fehlt noch eine passende Collection für die Aktualisierung der 64bit-Variante. Also flugs eine zweite Collection erstellt und die erste modifiziert!
select SMS_R_SYSTEM.ResourceID, SMS_R_SYSTEM.ResourceType, SMS_R_SYSTEM.Name, SMS_R_SYSTEM.SMSUniqueIdentifier, SMS_R_SYSTEM.ResourceDomainORWorkgroup, SMS_R_SYSTEM.Client
from SMS_R_System
inner join SMS_G_System_ADD_REMOVE_PROGRAMS
on SMS_G_System_ADD_REMOVE_PROGRAMS.ResourceID = SMS_R_System.ResourceId
where SMS_G_System_ADD_REMOVE_PROGRAMS.DisplayName like "Java%"
and SMS_G_System_ADD_REMOVE_PROGRAMS.DisplayName not like "Java%(64-bit)"
and SMS_G_System_ADD_REMOVE_PROGRAMS.Version not like "6.0.220%"
select SMS_R_SYSTEM.ResourceID, SMS_R_SYSTEM.ResourceType, SMS_R_SYSTEM.Name, SMS_R_SYSTEM.SMSUniqueIdentifier, SMS_R_SYSTEM.ResourceDomainORWorkgroup, SMS_R_SYSTEM.Client
from SMS_R_System
inner join SMS_G_System_ADD_REMOVE_PROGRAMS
on SMS_G_System_ADD_REMOVE_PROGRAMS.ResourceID = SMS_R_System.ResourceId
where SMS_G_System_ADD_REMOVE_PROGRAMS.DisplayName like "Java%(64-bit)"
and SMS_G_System_ADD_REMOVE_PROGRAMS.Version not like "6.0.220%"
Und jetzt: sind wir nun bereit für die Verteilung der beiden Updates? Nein, leider immer noch nicht…
Im Falle der ersten Collection für die 32bit-Variante scheint alles bestens: Es sind genau diejenigen Systeme in der Collection enthalten, welche das 32bit-Update nötig haben. Die zweite Collection ist … leer!?!
Dabei wussten wird doch ganz genau, dass es bei uns Systeme gibt, welche die 64-bit-Java-Version installiert haben. Nach einer längeren Suche nach der Ursache entdeckten wir dann des Rätsels Lösung: Es gibt nicht nur eine Tabelle „SMS_G_System_ADD_REMOVE_PROGRAMS„, sondern auch noch eine zweite Tabelle „SMS_G_System_ADD_REMOVE_PROGRAMS_64„. Die Angaben über die auf einem Client installierte Software werden also in separaten Tabellen für 32-bit- und zu 64-bit-Software gespeichert. Kein Wunder also, dass unsere obige Query ein unbrauchbares Ergebnis liefert und demzufolge die Collection leer bleibt, denn wir suchen schlicht und einfach in der falschen Tabelle!
Wir haben dann die Collection für die 64-bit-Java-Version nochmals angepasst, worauf diese dann tatsächlich das gewünschte Ergebnis lieferte:
select SMS_R_SYSTEM.ResourceID, SMS_R_SYSTEM.ResourceType, SMS_R_SYSTEM.Name, SMS_R_SYSTEM.SMSUniqueIdentifier, SMS_R_SYSTEM.ResourceDomainORWorkgroup, SMS_R_SYSTEM.Client
from SMS_R_System
inner join SMS_G_System_ADD_REMOVE_PROGRAMS_64
on SMS_G_System_ADD_REMOVE_PROGRAMS_64.ResourceID = SMS_R_System.ResourceId
where SMS_G_System_ADD_REMOVE_PROGRAMS_64.DisplayName like "Java%(64-bit)"
and SMS_G_System_ADD_REMOVE_PROGRAMS_64.Version not like "6.0.220%"
Endlich hatten wir die notwendigen Collections definiert und die Verteilung der beiden Updates konnte starten. Erst später merkten wir dann noch, dass im Falle der ersten Collection für die 32-bit-Java-Version die Erweiterung ..._ADD_REMOVE_PROGRAMS.DisplayName not like "Java%(64-bit)" gar nicht nötig gewesen wäre, da ja in der betreffenden Tabelle gar keine Angaben zu installierten 64bit-Versionen gespeichert sind.
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: Erkenntnisse | Tags: BITS, DistributionPoint, IIS, Package, SCCM
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:
- Im Beitrag „This package was a challenge…“ des Blogs „The D-Spot – Tickle your deployment needs“ schreibt Steve De Peet, er hätte noch ein Problem mit „hidden“ (d.h. „versteckten“) Files gehabt, welche zu einem „Hash Verification Error“ führten. Nachdem das Hidden-Flag entfernt und ein Refresh des Distribution Points durchgeführt worden sei, hätte der Download dann geklappt.
- In der Diskussion „Programmdownload bleibt einfach stehen“ in den deutschsprachigen Microsoft System Center Technet Foren zeigte sich, dass weitere Zeichen im Dateinamen (im dortigen Fall handelte es sich um „+“-Zeichen) Probleme verursachten, welche mit Hilfe des Microsoft KB-Artikels 942076 (Error message when you visit a Web site that is hosted on IIS 7.0: „HTTP Error 404.11 – URL_DOUBLE_ESCAPED“) gelöst werden konnten.
- Im Beitrag „Troubleshooting SCCM and BITS Downloads“ liefert Matthew Boyd weitere Hinweise und Tipps zur Lösung von Problemen aus diesem Umfeld.
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.
Abgelegt unter: Erkenntnisse | Tags: DistributionPoint, Package, SCCM, Unsupported
Kürzlich entfernte ich einen nicht mehr gebrauchten Distribution Point. Dies ging ruckzuck: Flugs im „Site Management“ unter den „Site Systems“ der entsprechenden Site den betreffenden Server ausgewählt und die Rolle „ConfigMgr Distribution Point“ entfernt. Fertig!
Fertig? Nein, leider nicht ganz…
Der Distribution Point wurde überall aus den Listen entfernt und man konnte auf diesem auch keine Pakete mehr verwalten. Auf den ersten Blick schien alles in bester Ordnung zu sein. Auf den zweiten Blick hingegen…
Immer wieder tauchten seither Fehlermeldungen auf, dass ein bestimmtes Paket auf dem betreffenden Distribution Point nicht bereitgestellt oder entfernt werden konnte. Und wenn man dann die betreffenden Pakete in der Konsole betrachtete, war tatsächlich der betreffende Distribution Point noch im „Package Status“ aufgelistet, zumeist mit einem Status „Removal Pending“. Dabei war doch dieser Distribution Point längst gelöscht und der entsprechende Server ausrangiert und entsorgt.
Was nun?
Ein entsprechender Artikel „How to Remove a Distribution Point“ aus dem Microsoft Technet half etwas weiter, da dort folgendes dokumentiert ist:
1. Remove all distribution package folders and the SMSPKGSIG signature folder from the distribution point computer.
Important: You must manually remove these components before removing the distribution point role.
Tja, hinterher ist man immer schlauer. Bloss war es etwas schwierig für mich, diese Anweisung nachträglich umzusetzen, da der Distribution Point längst weg war.
Da ich vermutete, dass ich nicht der einzige bin, der einen Distribution Point gelöscht hat, bevor er die Packages von diesem Distribution Point entfernt hatte, suchte ich weiter und fand einen Thread in den System Center Foren von Microsoft, bei welcher dieses Problem diskutiert wurde. Als Lösung wurde dabei auf einen Beitrag im „System Center WebLog by Russ Slaten“ verwiesen, dessen Titel „Removing a retired DP from all your packages“ vielversprechend aussah.
Dieser Beitrag beschreibt, dass das Entfernen der Rolle „Distribution Point“ nicht auch automatisch die Pakete von diesen Distribution Point entferne. Man müsse vorgängig die Pakete vom Distribution Point entfernen, was ziemlich mühsam werden kann, wenn man eine grössere Menge von Paketen auf dem betreffenden Distribution Point bereitgestellt hat. Netterweise stellt Russ Slaten bei dem betreffenden Beitrag ein VB-Skript bereit, mit dem diese Aufgabe automatisiert durchgeführt werden kann. Die Angabe der Namen des Site Servers und des leerenden Distribution Points als Parameter bei Aufruf seines Skriptes „SMSDPClean.vbs“ reichen, und schon würden alle Pakete vom betreffenen Distribution Point entfernt werden.
Wie ich dann leider herausfinden musste, funktioniert dieses Skript problemlos, zumindest solange der Distribution Point noch nicht vom Netzwerk entfernt wurde. Das Skript deckt zwar mit einer kleinen vorzunehmenden Modifikation den Fall ab, dass ein Distribution Point schon gelöscht wurde, doch in meinem Falle mit dem bereits entsorgten Distribution Point half das Skript nicht wirklich weiter.
Langsam aber sicher fragte ich mich, weshalb beim Entfernen der Rolle „Distribution Point“ keine entsprechenden Warn- oder Fehlermeldungen erscheinen, die darauf hinweisen, dass man diese Rolle nicht entfernen solle bzw. könne, da diesem Distribution Point noch Packages zugewiesen seien. Wehmütig dachte ich an den Assistenten, der beim Löschversuch einer Collection erscheint, der auf detaillierteste Weise beschreibt, was alles geschehen wird, wenn man diese Collection löscht.
Jegliches Sinnieren über mögliche Unzulänglichkeiten der SCCM-Konsole half mir jedoch nicht weiter. Ich hatte ein Problem, und das sollte gelöst werden! Also las und suchte ich weiter und stiess auf den Artikel „Deletion of Orphaned Distribution Points“ von Brett Wilms in seinem „System Management Blog“. Und dieser Beitrag half tatsächlich weiter!
Doch bevor ich die Lösung des Problemes präsentieren kann, ist nun ein Warnhinweis fällig:
Die direkte Modifikation einer SCCM-Datenbank wird von Microsoft grundsätzlich nicht unterstützt, ausser sie erfolgt direkt auf Anweisung der Microsoft Support Services. Die beschriebene Lösung hat beim Autor dieses Artikels funktioniert und wird als Beispiel publiziert, wie die Problematik gelöst werden könnte. Die unsachgemässe Anwendung der beschriebenen Lösung kann negative Folgen auf eine SCCM-Umgebung haben. Testen Sie die beschriebene Lösung unbedingt in Ihrer Testumgebung, bevor sie diese auf eigene Verantwortung und eigenes Risiko in Ihrer Produktionsumgebung anwenden. Bitte wenden Sie diese Lösung in Ihrer Umgebung nur genau dann an, wenn Sie wissen was sie tun, und kontaktieren Sie die Microsoft Support Services bei jeglicher Unsicherheit.
Mit Hilfe des SQL Server Management Studio konnte ich mit Hilfe der nachfolgenden beiden Queries sehen, welche Einträge zum fraglichen Distribution Point noch in der Datenbank vorhanden waren, wobei natürlich <DistributionpointName> durch den Namen des gelöschten Distribution Points zu ersetzen ist:
SELECT * FROM PkgServers WHERE NALPath like '%<DistributionpointName>%'
SELECT * FROM PkgStatus WHERE PkgServer like '%<DistributionpointName>%'
Als ich mich davon überzeugt hatte, dass diese beiden Queries tatsächlich genau (und nur!) die Einträge zum gelöschten Distribution Point lieferten, und ich mich zudem vergewissert hatte, dass ich ein korrektes und aktuelles Backup der betreffenden Site vorliegen hatte, wagte ich es, die folgenden beiden Queries zu starten, um die Spuren des gelöschten Distribution Points in der Datenbank zu beseitigen:
DELETE FROM PkgServers WHERE NALPath like '%<DistributionpointName>%'
DELETE FROM PkgStatus WHERE PkgServer like '%<DistributionpointName>%'
Und tatsächlich: Seither sind die Fehlermeldungen verschwunden.