Wenn man einen Cluster unter Sever 2008 zu einem File Server macht und dann nach und nach die Ressourcen freigibt, dann kommt es zu einem eigenartigen Phänomen, dass das Cluster alle freien Ressourcen des RAM beschlagnahmt und diesen dann nicht mehr freigibt. Je nach Belastung des Clusters (I/O und Sessions) dauert es dann bis zu 48 Stunden und jeder Node bleibt mit einem Blue Screen stehen!

Zuerst dachte ich, dass es sich um einen Hardware Defekt handelt, dem war aber nicht so, da ja beide aktiven Knoten mit einem Blue Screen beendet worden sind. Das Ganze wurde auch durch die Reproduzierbarkeit des Verhalten bestätigt.

In Zusammenarbeit mit dem Microsoft Support wurde das Problem als Bug im TCPIP.sys typisiert. Als Workaround hat sich ein einfacher Trick erwiesen. Über die Verwaltung navigiert man zu der Verwaltung des virtuellen Speicher und öffnet diese Registerkarte. Ohne Einstellungen zu verändern klickt man auf ok. Das System muss nicht neu gestartet werden! Nach kurzer Zeit (ca. 30 Sekunden) gibt jeder Node das RAM frei und das Spielchen beginnt von Vorne.

Die erste Version des private Patch, welches von MS geliefert worden ist, zeigt Besserung jedoch hatte es einen kleinen Konflikt mit einem Security Patch. Eine Update zum Update scheint das Problem in den Griff zu bekommen.

Zumindest ist der File Server wieder stabil und man kann auch die Cluster Ressourcen ohne Bedenken schwenken.

Sollte ich neue Erkenntnisse haben, dann werde ich dazu weiter berichten.

 

Hier gibt es was auf die Augen und auf die Ohren

Wer schon immer in kurzer und kompetenter Form etwas über den Server 2008 R2 erfahren wollte, der sollte sich über den Link schnell zu den ca. 84 Webcasts anmelden.

http://blogs.technet.com/peteralb/archive/2009/10/29/sepago-startet-webcastreihe-zu-windows-server-2008-r2.aspx

Wer sich schon immer mal etwas von Nicki Wruck (Head of ice-Lingen) erzählen lasse wollte, der hat auch hierzu Gelegenheit. Nicki gab sich allein mit der Organisation zufrieden, dieses mal bittet er um Gehör

Sicher wird es eine hervorragende Quelle für Informationen.

Also Anmelden ist (fast) Pflicht.

 

Ich habe von Nicki eine Nominierung zum Contest Speaker Idol TechEd 2009 bekommen. Jeder bekommt ca. 5 Minuten Zeit und muss eine Minisession halten. Diese wird dann von einem Jurorenteam bewertet und mit etwas Glück bekommt man den begehrten Titel Speaker Idol. Nach Rücksprache mit Nicki und Stephen Rose (Redmond) habe ich die Erlaubnis bekommen, dass ich dazu etwas bloggen darf. Ich werde wohl eine kleine Session zum Thema Server 2008 R2 machen. Mal sehen, ob ich damit Chancen habe.

Ich fühle mich seht geehrt und werde natürlich die Bude rocken! Wann bekommt man schon mal die Gelegenheit sich von so einer hochkarätigen Jury bewerten zu lassen?

Mit anderen Worten: meet me @ TechEd in Berlin

Thanks to Nicki an Stephen for supporting me!

 

Es kann passieren, warum auch immer, dass ein Server 2008 einen Fehlercode 0xC004e002 ausgibt, obwohl er registriert und aktiviert worden ist. Dieses kann an einer inkonsistenten Lizenzdatenbank liegen, die sich dann auf den Server befindet. Eine große Menge graue Haare später habe ich einen Weg gefunden, um das Teil davon zu überzeugen, dass die Lizenz wirklich noch die echte ist. Denn der Server verrichtet seine Arbeit, aber man kann sich weder auf der Konsole noch per RDP verbinden.

Um den Workaround durchführen zu können, muss man eine CMD mit administrativen Rechten ausführen, sonst geht es nicht.

1) net stop slsvc

2) cd %windir%\ServiceProfiles\NetworkService\AppData\Roaming\Microsoft\SoftwareLicensing

3) ren tokens.dat tokens.bar

4) cd %windir%\system32

5) net start slsvc

6) cscript slmgr.vbs -rilc (Ruhe bewahren, das Teil dauert eine gewisse Zeit!!!!)

7) 2x neu starten!!!! (Ja, wirklich 2x neu starten, extrem wichtig!!!)

 

Damit sollte es gehen.

 

Bei einer File Server Migration ist es zu einer suboptimalen Situation gekommen! Wir mussten Daten von einer Domäne in eine andere migrieren und haben einen Server 2008 Cluster zum File Server gemacht. Nun sollten alle Daten per Skript mit Robocopy kopiert werden, damit wir mit ADMT die Daten im Bereich Security umstellen können. Pustekuchen! Mit einer gewissen Verwunderung stellten wir fest, dass die NTFS rechte auf dem Verzeichnissen sauber mit gewandert sind, jedoch nahezu alle Berechtigungen bei der Dateiebene fehlen!!!

Sind ja nur 1,3 TB gewesen. Also nix mit “schnell händisch nachpflegen”.

Eine Analyse des Phänomens ergab Verwirrung, denn die Logs von Robocopy zeigen nur einen erfolgreichen Abschluss an. Nachdem wir tiefer in das Problem eingetaucht sind, stelle sich der Schuldige fast freiwillig! Robocopy.exe

Betroffen sind die Versionen

• XP027 ( Vista ohne SP)
• XP028 (Server 2008 und Vista SP1)
• XP010 läuft nicht sauber unter Server 2008 und Vista (Genauso wie XP027)

 

Die Version XP026 scheint die Version zu sein, die das Problem nicht hat (Oder ich habe es noch nicht gefunden). Leider bekommt man die Version XP026 nur, wenn man die Robocopy Version mit der GUI lädt und entpackt. Darin ist diese Version enthalten, die man dann wieder kopieren und nutzen kann. Windows 7 wird mit der Version XP027 ausgeliefert. Hoffentlich wird die Version bald gefixed!

 

Man kann über ein selbsterzeugtes ADM File die Vorbelegung der Domäne für die Windows Anmeldung definieren. Diese Funktion ist hilfreich, wenn man eine Migration durchführt und den User die Auswahl abnehmen möchte (oder besser muss). Nun kam es zu dem merkwürdigen Effekt, dass wenn ein System durch den Bildschirmschoner gelockt wird und der User das System entsperren will, dann kann er sich nur lokal oder an einer anderen Domäne anmelden. Es war aber zwingend erforderlich, dass die “alte” Domäne genutzt wird. Nach etwas längeren Suchen war auch klar, was die Ursache zu dem Fehler war.

Der Ersteller hatte in dem ADM File die Option “CachePrimaryDomain” mit eingebunden. Der fleißige Admin hat brav die Option konfiguriert und auf die Domäne losgelassen. Die Option wird normalerweise seit Windows 2000 nicht mehr genutzt (berücksichtigt). Jedoch war die Einstellung daran Schuld, dass das Entsperren nicht sauber funktionierte und die Vorbelegung der Option “DefaultDomainName” immer wieder überschrieben hatte.

In diesem Punkt hat sich der Übereifer nicht ausgezahlt.

In diesem Artikel kann man nachlesen, dass die Option eigentlich keine Auswirkung hätte zeigen dürfen.

http://technet.microsoft.com/en-us/library/cc939704.aspx

 

Wie war das mit dem Verhalten zwischen Theorie und Praxis

 

ADMT ist ein schönes Tool. Wenn ich es mir oft genug einrede, dann glaub ich es auch bald!!!! Zur Migration von Computerkonten gehört es, dass man lokale Profile konvertiert. Bis hierher keine Probleme. Die Konvertierung führt man in der Quelldomäne durch bevor die Computerkonten wandern. Alles klar. Bei knapp 9000 Konten sicher keine Aufgabe für die GUI, also muss ein Skript her. Das Skript liest brav die Konten aus dem AD aus, erzeugt die Include Dateien. Option Datei und schreibt die Batches, um Los weise die Konten zu konvertieren und dann zu migrieren. Fertig – Go!

Error! Das angegebene Computerkonto konnte in der “Zieldomäne” nicht gefunden werden! Wie auch, ich will es ja erst migrieren. Kontrolle der Dateien keine Fehler. Hm, zu oft habe ich die Überraschung erlebt, dass es gravierende Unterschiede zwischen ADMT GUI und ADMT Skript gibt. Also das ganze mal mit der GUI gemacht. Zuerst unter Angabe der Include Datei und der Option Datei. Gleicher Fehler. Nur Option Datei – geht! Hä! Nur Include Datei – geht nicht. Ok, das Tool sucht also Streit. Es muss also einen Unterschied geben, wie der Aufruf der Computerkonten über das Tool erfolgt. Der ADMT Guide ist nicht wirklich eine große Hilfe bei der Skriptsteuerung von ADMT mit Include- und Option Datei.

Lösung:

Im Gegensatz zu allen anderen Include-Dateien benötigt die Datei für die Konvertierung von lokalen Konten einen etwas anderen Inhalt. Zeilenweise muss man das Format wie folgt wählen:

Quelldomäne\Name

Die Quelldomäne muss dabei mit dem NetBIOS Namen angegeben werden, dann klappt auch die skriptgesteuerte Konvertierung der lokalen Profile.

 

Wenn nach der Migration des Druckservers nicht alle Drucker im AD veröffentlich werden, dann müssen diese mit dem Skript prncfg.vbs aus dem Resource Kit 2003 nachträglich veröffentlicht werden. Der Aufruf des Skripts sieht folgendermaßen aus: cscript prncfg.vbs -s -b \\Server\PrinterName +published Damit das Skript ausgeführt werden kann, muss aus dem Resource Kit die prnadmin.dll registriert werden. Dieses erfolgt mit dem Kommandozeilentool regsvr32 Registrierung: Regsvr32 prnadmin.dll Ansonsten bricht das Skript mit einem Fehler ab. Dieses Phaenomen tritt auf, wenn der Druckserver eine große Menge an Druckern hostet. Bei mir waren es ca. 300 Stueck.
 

Wieder eine kleine Merkwürdigkeit, die mich doch etwas verwundert. ADMT ist ja ein beliebtes Tool für die Migration, denn dazu ist es ja gedacht. Also wollte ich das Tool seiner Bestimmung nach einsetzen und wir standen vor der Aufgabe ca. 20000 Objekte zu migrieren.

ADMT 3.1 fällt durch das Raster, weil wir keinen Server 2008 zum DC machen wollten und auch nicht dürfen. Die Version 3.0 ist ja auch kein Prima. Best Practise für ADMT ist es ja Los weise mit 100 Objekten zu arbeiten. Ok, machen wir! Um eine saubere Migration zu gewährleisten, werden die Objekte mit SID History migriert, um den Zugriff auf die andere Domäne und die Ressourcen zu ermöglichen. Bei der existierenden Vertrauensstellung wird schnell mit netdom …/quarantine:no die SID Filterung deaktiviert.

Nun kommt aber der Hammer! Um das Verfahren etwas bequemer zu machen, soll ADMT per Skript arbeiten und dazu die generierten Includ-Dateien nutzen. Allerdings kann man diesen gewählten Weg nur nutzen, wenn ADMT direkt auf dem DC installiert wird! Ist ADMT auf irgendeinem anderen System installiert (Admin Workstation), dann werden alle Objekte OHNE SID History migriert. Besser gesagt, man kann dieses Feature nicht auswählen. Wenn man bei dem gleichen System das MMC von ADMT aufruft, dann funktioniert auch die Migration mit SID History. Da es hier um eine Sruktur mit ca. 2500 Globalen Gruppen und ca 1000 OUs geht, ist dieses manuelle Verfahren ausgeschieden.Denn bei der GUI muss man jeder OU einzeln aufrufen.  Also muss ADMT auf einem DC installiert werden, damit die skriptgesteuerte Migration funktionieren kann.

Leider ist mir keine Erklärung eingefallen, warum dieses so ist.

 

Es ist wie aus dem Bilderbuch. Kaum macht man ein paar kleinere Arbeiten am System schon sind alle Fehler auf diesen Punkt zurückzuführen! Nach einen Schmeaupdate auf die Version 44 (Server 2008) tauchen im Eventlog sporadisch Fehlermeldungen auf.

Event ID: 11 Source: KCC DS_Service_Principal_Name Was bedeuten soll, dass es bei einem Server doppelt registrierte SPNs geben soll. Ok, ich konnte mir zwar nicht vorstellen was mein Schemaupdate mit dem SPN zu tun hat, aber egal: der Consultant ist immer Schuld!

Ich machte mich mit den üblichen Tools auf die Suche, um den Server zu suchen der diesen SPN doppelt hat!

Setspn –L <Server> zeigt nicht wirklich was Ok!

ldifde –f SPN.txt –t 3268 –d “DC=Domain,DC=Suffix” –l ServicePrincipalName –r “(ServicePrincipalName=*)”  -p subtree um alle Server abzufragen, auch nichts?

ADSIEdit und dort alle ServicePricipalName Einträge von Hand kontrolliert… auch ok?

Und nun die Auflösung:

Wenn man einen Server installiert und diesen von einer in die andere Domäne bringt, dann sollte man auch das Computerkonto löschen oder  wenigsten deaktivieren

Nur gut, dass der Server kundenseitig zur Verfügung gestellt (installiert) wurde

 

Bei einer Migration habe ich heute ein Attribut gefunden, bei dem ich mich wirklich ernsthaft frage: Wozu benötigt man dieses Information im Active Directory?

Aber seht einfach mal selbst

 

Ich nehme einen Doppelten

 

Ich bin bei einer Migration dabei das Testlab einer 4 Domänenstruktur aufzubauen, um die nötigen Schritte zu planen und zu verifizieren. Soweit ganz einfach. Heute gab es dann ein kleines Problem, denn der DNS Dienst wollte nicht so wie ich wollte.

Nachdem alle Metadaten gesäuberten worden sind (NTDSUTIL, ADSIEdit) und die Replikation und Trusts sauber funktionieren, war da immer noch das DNS Problem. Im Eventlog stand ein Fehler 4521 mit unbekannter Source.

Die Namensauflösung funktioniert sauber und die User werden sauber authentifiziert. GC ist auch sauber. Der Befehl:

DNSCMD /config /bootmethod

brachte nur eine kleine Verbesserung. Des Rätzels Lösung war, dass das System auf Biegen und Brechen nach der .-Zone (Root) sucht. Erst nachdem ich eine AD integrierte DNS Root Zone erstellt habe hörten die Fehler im Eventlog auf. Nun werde ich morgen die Root Zone aus dem AD entfernen (Primary Stand Alone) und dann löschen. Danach sollte der Fehler Geschichte sein.

Ich werde weiter Berichten.

 

Wieder einmal hat sich gezeigt, dass es weiterhin unglaubliche Phänomene gibt, wenn man SAMBA Server mit Server 2008 verbinden möchte (oder muss.)

Bei einem Kundenprojekt habe ich die Migration von einer Windows 2000 Domäne zu Server 2008 Domäne durchgeführt. Alles verlief völlig Problemlos. bis die Migration der Fileserver in den neuen DFS Stamm (AD integriert) durchgeführt werden sollte. Die alten Fileserver wurden über Snapboxen von Overland Storage (ehemals Adaptec) betrieben. Die Zugriffe wurden per samba.conf definiert. Im Webinterface gab es auch die Möglichkeit ein Domain Joining in Active Directory durchzuführen (laut Handbuch Kerberos V5). Somit sollte der Umzug problemlos klappen, denn in der 2000er Domäne wurden alle Gruppen korrekt erkannt. Da die alten DC noch ein wenig mitlaufen sollten, war kein Problem zu erkennen, denn auch der Hersteller sagte, dass es KerberosV5 ist und funktionieren sollte. Nach ein paar Tagen fingen dann die Probleme an. Zuerst waren es vereinzelt Dateíen auf die User nicht mehr zugreifen konnte, dann war das Schreiben nicht mehr möglich. Somit wurde die Situation im Minutentakt immer "unschöner" und die Frustration stieg weiter an.

Nach eingehender Analyse folgender Konfiguration wurde schnell klar, wo der Hase im Pfeffer liegt.

samba.conf.

kerb5.conf

resolver,conf

smb.conf

SMB Signing funktioniert nicht wirklich und was da an Kerberos Infos (ads_kinit) kommt ist auch nicht sauber.

Also Klist und Kdestroy, um zu gucken ob das eine Abhilfe schafft. Ja, aber nur temporär. als nächsten Schritt habe ich die Kerberos Einstellungen soweit aufgeweicht, dass es ohne Probleme hätten klappen sollen, aber ohne wirkliche Besserung schlug der Versuch auch fehlt.

Mit diesen Infos sind wir an den Hersteller ran und dann kam auf einmal die Aussage, dass selbst mit dem nächsten Update Server 2008 nicht unterstützt wird. Ob überhaupt, stelle ich hier mal ganz deutlich in Frage.

Also wurde alle Daten schnell mit dem lokalen Konto Root mit dem Other Flag versehen und dann per Robocopy Skript (/copyall Schalter) auf einen DFS Server kopiert. Hier habe ich mit icacls.exe die Berechtigungen wieder korrigiert und die Replikation konnte beginnen. Natürlich mussten noch Loginscripte angepasst werden und die Pfade für die Verbindlichen Profile ebenfalls.  Der Kunde war total begeistert, dass man die Daten doch noch retten konnte und er man nächsten Tag wieder voll funktionstüchtig war.

Danke Overland für eine schlaflose Nacht!

 

Wenn man den Systemstate mit Windows Boardmitteln sichern will, dann konnte man bis zur Version Server 2003 einfach das interne Backup Tool NTBACKUP dazu nutzen indem man den Haken bei Systemstate setzt.

Bei Server 2008 ist das Tool NTBACKUP nicht mehr Bestandteil des Systems. Nun muss man die zuerst über den Server Manager - Features die Windows Server Sicherungsfeatures installieren. Wichtig ist dabei, dass man die Befehlszeilentools und die Powershell zusätzlich mit installiert. Die Powershell wird automatisch ausgewählt, wenn man die Befehlszeilentools zur Installation auswählt.

Möchte man nur den Systemstate sichern ist man mit der grafischen Oberfläche schnell am Ende und stellt fest, dass die Funktion nicht anwählbar ist, besser gesagt: Sie existiert gar nicht!

Dazu benötigt man die Befehlszeilentools. Wozu sonst auch die Installation

Über die CMD, die mit administartiven Rechten (oder zumindest Mitglied in der Gruppe Sicherungsoperatoren) ausgeführt werden muss gibt man folgenden Befehl ein:

wbadmin start SystemStateBackup -backuptarget:ZIEL:

Ziel: beschreibt den Ort an den die Sicherung geschrieben wird. Es kann sogar auf die Partition C: erfolgen.

Beispiel: 

wbadmin start SystemStateBackup -backuptarget:c: (Doppelpunkte beachten)

Allerdings ist die Sicherung gegenüber der Sicherung mit NTBACKUP komplett überarbeitet worden. Neben dem Systemstate wird auch eine *.vhd Datei erzeugt, die das Systemverzeichnis und "wichtige" Dateien aus dem Programmverzeichnis sichert. Somit kann die Sicherung auch schnell mal 80% der Gesamtgröße der C: Partition betragen. Das sollte man bei der Planung berücksichtigen. Über den Taskplaner kann man den Systemstate sichern lassen, wenn man die Kommandos in einer Batch Datei hinterlegt.