AndiW

@Splash: Ich plane kommende Woche (Di) die ITIL Foundation Prüfung bei Prometric zu machen, gelten die Rabatt Bon's bei der Prüfung auch? Bevor du sie verfallen lässt würde ich schon gerne einen haben wenn möglich :D

@MIB76 Was Session Directory betrifft hast du die Situation richtig erfasst, dazu kommt noch dass das NLB von Windows beim Verteilen der Clients nicht auf die CPU sondern auf die Netzwerkauslastung achtet. Ist z.B. ein Terminal Server CPU-mässig ausgelastet, Netzwerk-mässig aber nicht, kann es sein dass er dennoch Clients zugewiesen bekommt. Ich glaube es gibt aber Möglichkeiten über SNMP Performance Daten abzufragen und anhand von denen die Clients dann zu verteilen, genaueres weiss ich da aber nicht. Ich implementiere bei uns selbst grad so einen TS Cluster, hab allerdings Session Directory bei uns installiert, sogar als Cluster Ressource, mal sehen wies funkt. :) Gruß Andi PS: Die Antwort kommt zwar über ein Jahr zu spät, aber besser spät als nie :D

Hi, ob es an den Platten liegt (z.B. hardwareseitiger Defekt) müsstest du eigentlich an den Lampen direkt sehen bzw. beim Initialisieren des Controllers. Gibts da Auffälligkeiten wenn du den Server startest und die Platten initialisiert werden? Werden alle Platten vom Controller erkannt? Werden die RAID Verbunde korrekt erkannt wenn du in das Konfigurations BIOS vom Controller gehst? Falls mit den Platten und dem Controller alles normal ist sollte man vorerst mal einen hardwareseitigen Defekt vernachlässigen. Was ist zuletzt passiert bevor die Maschine hängen geblieben ist? Vielleicht in der Datenträgerverwaltung die falsche Partition als aktiv markiert? Gruß Andi

Unterstützende Quellen MS Artikel 1 "How to manually re-create the Cluster service account" --> http://support.microsoft.com/kb/269229/en-us#XSLTH3145121123120121120120 MS Artikel 2 "How to move a Windows Cluster Server from one domain to another" --> http://support.microsoft.com/kb/269196/en-us Plan Hier wäre mein Plan, Verbesserungen/Anregungen sind jederzeit willkommen. - Image Kopie von beiden Cluster Nodes - NTFS Berechtigungsexport von allen File Server Verzeichnissen durch DumpSec (so habe ich zumindestens die Möglichkeit die ACL's manuell nachzubessern, auch wenn das das Horror Szenario schlechthin ist) - Share Berechtigungsexport über DumpSec - Erstellen eines neuen Cluster Accounts in der EMEA Domäne wie im MS Artikel 1 beschrieben - Berechtigen des neuen Accounts wie im MS Artikel 1 beschrieben - Hinzufügen des neuen Service Accounts zu den lokalen Administrators Gruppen der Cluster Nodes - Cluster Services auf allen Nodes auf manuell stellen - Cluster Services auf allen Nodes stoppen - Node2 herunterfahren - Migration über ADMT V2 von Node1 - Änderung der Startart des Cluster Services mit dem neuen Service Account auf Node1 - Berechtigungen der lokal Security Settings des neuen Service Accounts erneut auf Node1 prüfen (wie in MS Artikel 1 beschrieben) - Cluster Service auf Node1 starten (auf ein Wunder hoffen) :D - Test aller Cluster Services (zu diesem Zeitpunkt sind noch keine NTFS- oder Share Berechtigungen migriert!!) - Wenn alle Services normal arbeiten -> Migration von Node2 (gleiche Vorgehensweise wie bei Node1) - Cluster Service auf Node2 starten - Über ADMT V2 den Security Translation Wizzard starten und File Berechtigungen migrieren (zuerst testen, danach migrieren) Probleme - NTFS Berechtigungsfrage Bei den NTFS Berechtigungen wurde oft die Gruppe Domain Admins verwendet, wie wir ja alle wissen :) werden keine Built-In Accounts migriert - was bedeuten würde ich müsste überall wo die Gruppe Domain Admins vorgekommen ist eine neue equivalente Gruppe manuell hinzufügen. Gibt es eine Möglichkeit NTFS Berechtigungen so zu ergängen, dass alle NTFS-Berechtigungsstrukturen unangetastet bleiben aber sich überall eine Gruppe hinzufügen lässt? Z.B. wenn alle Dateien auf einem Laufwerk F liegen, dass ich ganz oben auf Laufwerksebene eine Gruppe voll berechtige und alle Berechtigungen bis ganz nach unten erzwungen werden, auch bei Ordnern wo die Vererbung deaktiviert ist? Ich kann zwar über Sicherheit->Erweitert->Haken bei "Berechtigungen für alle untergeordneten Objekte durch die angezeigten Einträge, sofern anwendbar, ersetzen" erzwingen dass die neuen Berechtigungen überall gelten, allerdings werden bei dieser Variante die bereits bestehenden überschrieben, was in meinem Fall nicht der Sinn der Sache ist. Was meinst ihr zum Plan? Hat jemand eine Idee das NTFS Problem betreffend? Grüße, Andi

Hi Velius, @Drucker Sichern und Wiederherstellen Hab mir das Druckertool mal angesehen, die Sicherung der Drucker ist, zumindest auf den ersten Blick, auf einem Cluster nicht möglich. Die Drucker können generell nur über den virtuellen Print-Cluster-Namen angesprochen werden und mit einem virtuellen Namen kann das Tool nicht umgehen. Fehlermeldung: Bad Machine Name Egal ob ich es direkt am Cluster Node der gerade die Print Services ausführt aufrufe oder im Tool selbst den virtuellen Clusternamen angebe, die Drucker können nicht angezeigt oder exportiert werden. @Microsoft File Server Migration Toolkit Das Tool ist laut MS nur geeignet wenn man auf einen Windows Server 2003 migriert und scheidet somit mal aus für mich. @File Shares Sichern und Wiederherstellen Danke für den Tipp, ich werde zwar von beiden Notes eine Sysstate Sicherung machen wo die Registry ja auch dabei ist aber zusätzlich noch den Registry Zweig extra sichern in dem die Shares definiert sind. Ich muss gestehen ganz wohl ist mir bei der Migration nicht, im Grunde kann mir niemand sagen ob es klappen wird oder nicht und die Aussage von MS selbst is auch ein Hammer. Ich danke jedenfalls allen für eure Unterstützung, werde dann mal meinen Migrations Plan posten, vielleicht hat ja noch jemand Anregungen - bin für jede Erfahrung dankbar!! :) Gruß Andi

Asooo, verstehe :D

Hi Velius, leider hab ich recht wenig KnowHow im Aufbau eines Clusters. Ich habe zwar schon mal fast alle Ressourcen was den File-Server Dienst betrifft neu erstellen müssen, aber generell fehlt mir das Knowhow und was noch schlimmer ist, die Zeit. Ich muss alle Server (nur der Cluster fehlt jetzt noch) bis Ende des Jahres migriert haben, ein Update auf 2003 würde den Zeitrahmen auch in jedem Fall sprengen. Werd wohl leider den Versuch wagen müssen, wie im MS Artikel beschrieben. Heute Nacht wird in jedem Fall noch ein Full Backup aller Daten sowie morgen vor der Migration dann noch System Images von beiden Cluster Nodes gemacht, falls was schief laufen sollte muss ich den Status von vor der Migration wieder herstellen und mir was anderes überlegen. Ein Feedback von jemandem der schon mal erfolgreich einen W2K Cluster migriert hat ohne ihn neu zu erstellen würde mir auf alle Fälle helfen. Natürlich bin ich auch für Tipps von allen anderen dankbar. Auf alle Fälle dank ich dir mal für deine Tipps und den Link bez. IIS, obwohl ich sagen muss dass unser Intranet keine allzugrosse Priorität hat, wenn das ein paar Tage ausfällt ist das nicht weiter dramatisch, die File & Print Services machen mir da bedeutend mehr Sorgen. Den IIS könnte ich zur Not auch neu aufbauen falls was schief laufen sollte. LG Andi

@zahni der Begriff Enterasys is mir unbekannt, was meinst damit? :)

Die Migration des Clusters hab ich mal für morgen Abend angesetzt ... vielleicht hat ja noch jemand Erfahrungswerte in diesem Gebiet? Microsoft macht einem ja nicht gerade Hoffnung wenn man den Beitrag so liest, Zitat: "The steps in this article allow the Cluster service to start in the new domain. However, you may or may not be able to bring the resources online in the new domain, and the resources that can be brought online may or may not work properly." Sind doch die besten Voraussetzungen für eine Cluster Migration oder? :D Andi

Hi weg5st0, die Informationen in dem Artikel (ist übrigens wirklich nur auf englisch zu lesen) hören sich zwar nicht gerade optimistisch an, sind aber genau das was ich gesucht haben. Danke!! LG Andi

@TheDonMiguel Du kannst über die ProLiant Support Packs für 200X (kannst du über die HP Homepage runterziehen) alle Komponenten und Treiber der Server auf den letzten Stand bringen, unter anderem natürlich auch die Management HP von den Servern. Diese Treiberupdates übernimmt dann in Zukunft (wenn du das so einrichtest) der Version Control Repository Manager, der auf dem zentralen HP Management Server installiert wird. Dieser zieht sich neue Treiber- und SW-Updates in definierbaren Zeitabständen von der HP Seite (z.B. in der Nacht). Wenn die anderen Server richtig konfiguriert sind können diese dann die Updates zentral vom Version Control Repository Manager beziehen, ähnlich wie bei WSUS. Also nochmal zusammengefasst, 2 Möglichkeiten: 1. Manuelle Installation aller HP Agents/Tools/Treiber/Management über die ProLiant Support Pack 2. Installation eines Version Control Repository Manager und Konfiguration aller Server diesen dann für Updates zu benutzen Gruß Andi

Hallo, der HP Insight Manager ist ein gutes und vor allem kostenloses Tool um alle Compaq bzw. HP Server hp-seitig zu verwalten. Wenn du dich über die Features informieren willst geh auf die HP Seite und such nach dem Insight Manager, dort ist recht gut beschrieben was er alles kann. Wir benutzen ihn auch und ich muss sagen ich bin zufrieden. Wir benutzen ihn hauptsächlich: - zur Kontrolle der Server (falls was nicht stimmt bekomme ich dann Mails) - Treiberupdate der HP Komponenten Die Daten der System Management Homepage kann man sicher exportieren bzw. ausdrucken, bilde mir ein dass ich das schon mal genutzt habe. Über die Diagnostic Seite auf der Management Page müsstest du gute Informationen zu allen Komponenten der Server bekommen. Klick dich mal durch und sieh dir alles an, ob wirklich alles dabei ist was ihr braucht kann ich so jetzt aber nicht sagen. Gruß Andi

Die IP des DC auf dem du DNS installieren hast lassen. Gruß Andi

Um auch dieses Rätsel noch zu lösen - doch schon eine zeitlang her der Beitrag - Hr. Rossi hatte recht, es lag wirklich am Switch. Ein kompletter Restart aller Nortel Komponenten hat das Problem dann beseitigt. Für alle die mal ähnliche Probleme haben. Gruß Andi

Hallo allerseits, wir führen gerade eine Domänen Migration (mittels ADMT 2) durch und ich bin fast fertig. Was noch fehlt ist unser Windows 2000 Cluster (mit 2 Nodes). Wie gehe ich da am besten vor, hat schon jemand Erfahrungen damit? Auf dem Cluster laufen folgende Services - File Server - Print Server - Intranet Server Die ACL Listen in den NTFS Berechtigungen hätte ich generell mal während dem Migrationsvorgang über ADMT 2 ändern lassen. Spricht etwas dagegen? Gibts bessere Tools? Erfahrungswerte? Meine Vorgehensweise wäre wie folgt: - Alle Cluster Dienste auf Node1 verlegen - Cluster Dienst auf Node2 beenden und deaktivieren - Node2 mit deaktiviertem Cluster Dienst in die neue Domäne migrieren - Nach erfolgreicher Migration Node2 mit deaktiviertem Cluster Dienst herunterfahren - Node1 mit allen Cluster Services migrieren - Node2 wieder hochfahren und Cluster Dienst reaktivieren Was haltet ihr davon? Wird das so klappen? Wäre für Erfahrungsberichte, Tipps & Verbesserung sehr dankbar! Gruß Andi

Hallo brolek, wird die Domänenmitgliedschaft wirklich nicht geändert oder scheinen nur unter "ipconfig /all" die alten Domänendaten auf? 1. Prüfe die Domänenmitgliedschaft unter Arbeitsplatz -> Eigenschaften -> Computername (dort müsste nach der Migration die neue Domäne stehen) 2. Prüfe im Migrationsprotokoll ob ganz unten steht dass die Domänenmitgliedschaft erfolgreich geändert worden ist 3. Wenn die Computer normal in die neue Domäne übernommen worden sind (wie im Punkt 1 geprüft) gehe auf die Eingabeaufforderung und gib für XP Clients ein gpupdate /Force ... ich habe die Erfahrung gemacht dass ein Update der Policies auch die neuen Domäneneinträge aktualisiert. Falls es sich um Windows 2000 Clients handelt gibt die secedit Parameter ein um die Policies zu refreshen. 4. Ich habe bereits über 30 Clients & 20 Server migriert, die Domänenmitgliedschaft wurde bei jeder Migration problemlos durchgeführt. Ein Update der GPO's war allerdings fast bei allen nötig. 5. Ein ipconfig /renew könntest du auch noch machen falls die Clients die IP Parameter über DHCP bekommen. Auch das könnte ein refreshen sämtlicher Daten bewirken, danach starte den Client durch. Nachtrag 6. Wenn die Clients ihre IP Daten über DHCP bekommen prüfe am DHCP Server üb das neue Domänen-Suffix mitgegeben wird oder sie noch das alte erhalten. Frage: Wie äußert sich deine Annahme dass die Clients nicht migriert worden sind? Gruß Andi

Hallo Leute, wollte nur abschließend mitteilen, dass das Problem nun gelöst ist. Die Lösung sieht simpler aus als gedacht, unter Windows 2000 TS ist der bevorzugte Lizenzserver in der Konsole nicht sichtbar, wenn er aber als bevorzugter Lizenz Server in die Registry eingetragen ist, werden die Lizenzen auch wirklich von diesem Server geholt, ob er nun unter Terminal Services Licensing aufscheint oder nicht. D.h. einen bevorzugten Lizenzserver aus einer anderen Domäne als der Mitgliedsdomäne des TS selbst zu wählen funktioniert sowohl unter Windows Terminal Server 2000 als auch unter 2003. Danke für eure Unterstützung! Gruß Andi

@snake Gegen ein geringeres Gehalt in der Einarbeitungszeit ist ja nichts zu sagen, aber es sollte von Anfang an klar gestellt sein wie lange die Einarbeitungszeit (ca.) sein wird und welche Gehaltsänderung sich nach dieser Zeit ergeben wird. Am besten wäre es gleich ausschließlich und direkt über das Gehalt zu verhandeln das nach der Einarbeitungszeit gültig sein wird. Wenn man jetzt nur sagt während der Einarbeitungszeit geringeres Gehalt ohne genauere Definitionen kann das der AG wieder auslegen wie er will und der AN schaut durch die Finger. Gruß Andi

Ein Hallo an alle, ich habe mir nur die ca. 10 letzten Seiten durchgelesen. :D Was ich allerdings bestätigen kann ist, dass 1500€ Brutto ein Witz sind und zweitens dass es eine wesentliche Rolle spielt welches Gehalt zu Beginn einer Tätigkeit vereinbart wird, die Megasprünge wirds danach nicht mehr geben. Wenn man sich also zu Beginn z.B. auf 1500€ Brutto einigt hat man sehr schlechte Chancen ein angemessenes Gehalt dann weiter herauszuverhandeln. Meiner Meinung nach ist das erste Gehaltsgespräch eines der wichtigsten überhaupt, wenn man sich da schlecht verkauft zerrt man die ganzen nächsten Jahre daran, sollten sich manche vielleicht zu herzen nehmen wenn sie sich bei der nächsten Firma bewerben. Gruß Andi

Hallo krool, du könntest mal testweise bei einem Benutzerprofil die Datei NTUSER.DAT gegen eine austauschen die für diesen Benutzer bei einer neuen Anmeldung generiert wird. So bleiben die Profil Einstellungen (wie z.B. Favoriten, individuelle Installationen etc.) erhalten und die Policies werden neu übernommen. Ich denke dass alle GPO Einstellungen in dieser Datei gespeichert werden - hatte mal ein ähnliches Problem da hat mir das geholfen. Allerdings waren es bei mir servergespeicherte Profile, sind eure Profile lokal oder servergespeichert? Falls lokal könntest du mal versuchen bei einem Test Benutzer das lokale Profil zu sichern, umzubennen, den Benutzer neu anmelden zu lassen, die so neu generierte NTUSER.DAT in das Originalprofil zu kopieren, Originalprofil wieder auf den Originalnamen zurückbenennen, Test Benutzer neu anmelden und sehen obs geklappt hat. Übrigens bei einem Ersetzen der NTUSER.DAT gegen eine neue werden alle gemappten Drucker entfernt - test dich da halt mal durch und schau dir die Auswirkungen bei so einem NTUSER.DAT Tausch für eure Umgebung an. Gruß Andi

Hallo stronzo75, generell würde ich nur die Update genehmigen die benötigt werden. Sobald ein Update für irgendeine Gruppe auf "installieren" genehmigt wird, ladetet es der WSUS Server herunter. Es werden keine Updates heruntergeladen die generell nur auf "ermitteln" genehmigt sind. Ich würde die Updates an deiner Stelle vor einer Ausrollung an 100 Clients zuerst mal mindestens bei einem Client testen, d.h. erstelle eine zweite Gruppe Test oder ähnlich und verschiebe mal einen Client dort rein, genehmige alle vom Client benötigten Updates für diese Gruppe Test, dann werden die nötigen Updates auf diesem Client installiert. Läuft alles glatt kannst du die Updates auch für die "grosse Gruppe" genehmigen. Bei XP (SP2) oder W2K Clients (SP4) empfielt es sich auch zuerst die letzten Service Packs auszurollen, das wird die Anzahl der dann benötigten Updates von der Anzahl her auch einschränken. Vergiss nicht, es kann bei der Update installieren immer etwas schief laufen oder ein Update kann nicht 100% funktionieren --> also immer Testen, bei Servern brauch ich das hoffentlich gar nicht erwähnen und ist selbstverständlich für dich. ;) Als Beispiel kann ich dir berichten dass z.B. ein Windows 2000 Pro Client immer Updates haben wollten die nur unter XP installiert werden können, nobody is perfect und WSUS ist da keine Ausnahmen. Gruß Andi

Hallo arnd, einerseits weil ich etwas unter Zeitdruck stehe und das Migrationsprojekt noch dieses Jahr abgeschlossen sein sollte und andererseits weil unter den Windows 2000 Terminal Servern (derzeit 3 Stück) Applikationen laufen die noch nicht sauber unter 2003 laufen und erst getestet und/oder upgedatet werden müssen - wir setzen seit Jahren auf Terminal Server, da ist ein Update auf 2003 nicht ganz so einfach wegen den Applikationen die laufen müssen. (z.B. Verbindungen zu IBM iSeries Servern, verschiedene ODBC Settings sind nötig usw.) Als Lizenzserver soll ein internationaler verwendet werden, wenn möglich sollten wir lokal keinen haben, deswegen gibts die Problematik auch. Im Grunde bin ich eh schon kurz vor dem Ziel dass der 2000er TS den internationenalen Lizenzserver annimmt, ich kann den Lizenzserver z.B. nur mit dem Servernamen ohne Suffix pingen, kann mich manuell über die Konsole zu ihm verbinden aber er verbindet sich nicht automatisch zu ihm, das ist das Problem. :) Falls ich es nicht schaffe, müssen wir temporär lokal einen Lizenzserver mit Windows 2000 CALs installieren, aber das wollen wir vermeiden. Gruß Andi

Hallo Wolke2k4, der Lizenzserver (Member von Domäne A) ist ein Windows 2003 Server der sowohl Windows 2000 wie auch Windows 2003 CALS hostet. Mit einem Windows 2003 Terminal Server (Mitglied von Domäne B) klappt es, mit einem Windows 2000 Terminal Server (Mitglied von Domäne B) klappt es noch nicht ganz wegen der bereits angeführten Probleme. Gruß Andi

Hallo Leute, das Thema ist wieder aktuell. Unter Windows Server 2003 funktioniert die Lizenzausgabe von einem entfernten Lizenzserver sehr gut, leider habe ich es unter Windows 2000 noch nicht ganz geschafft. Der Lizenzserver welcher die TS-CAL's ausgeben soll befindet sich in einer anderen Domäne als der Terminal Server selbst. Beide Domänen befinden sich aber innerhalb der gleichen Gesamtstruktur. Laut folgendem MS Artikel ist es möglich einen bevorzugten Lizenzserver anzugeben -> http://support.microsoft.com/default.aspx?scid=kb;en-us;239107 Funktioniert auch insofern, dass der Server versucht den in der Registry angegebenen Server zu finden, allerdings sucht er mit dem falschen Domänensuffix und findet ihn so nicht automatisch. Situation: - Terminal Server ist in Domäne B - Lizenzserver ist in Domäne A - Beide Domänen sind innerhalb einer Gesamtstruktur - In der Registry wird der NetBIOS Name des Servers verlangt (also ohne Suffix) - Wenn ich jetzt am Terminal Server die Console "Terminal Services Licensing" öffne, sehe ich zwar dass der richtige Server gesucht wird, allerdings mit Lizenzserver.SuffixvonDomäneB anstatt Lizenzserver.SuffixvonDomäneA - Ich habe bereits einen Eintrag in der hosts Datei am Server gemacht, er sucht trotzdem in der falschen Domäne nach dem Lizenzserver und findet ihn so nicht - Ein ping mit nur dem Servernamen ohne Suffix funktioniert problemlos - Manuelles Verbinden zum Lizenzserver über die Console "Terminal Services Licensing" ist ebenfalls problemlos möglich Frage: - Wie bringe ich den Terminal Server dazu den Lizenzserver in der richtigen Domäne zu finden? Hat irgendjemand eine Idee? :) Würde mich über Tips und/oder Tricks freuen damit die Sache klappt. Recht herzlichen Dank! Andi

Ich weiss zwar nicht genau wie das passieren konnte, aber der Beitrag is von mir AndiW, und nicht AndyW :)