fool15982

Hallo, wir nutzen aktuell ESXi zur Virtualisierung einiger Server und Clients. Die ESXi Hostserver sind Mitglieder der 2003 Domäne um den Zugriff von Usern und Gruppen zentral zu steuern. Leider funktioniert jetzt die Anmeldung nicht mehr! Ich bekomme beim Login die Meldung falsches Passwort oder Benutzer unbekannt. Wenn ich mich mit dem Root Account anmelde und ein User aus der Domäne bearbeiten oder hinzufügen will, kommt folgende Meldung: Die letzte Änderung die wir durchgeführt haben war VMware KB: ESX fails to authenticate some active directory users with the error: Authentication failure (ASN.1 encoding ended unexpectedly). Das hatte auch den gewünschten Effekt, die Masse von Fehlermeldungen in unserem SysLog-Server endete. Leider scheint es aber nun die Konsequenz zu haben, dass die Authentifizierung gar nicht mehr funktioniert. Hat dies schon mal jemand erlebt, bzw kann dies als mögliche Ursache bestätigen/verneinen? Gruß Andre

Hallo Community, ich bin momentan dabei mich auf mein Upgrade vorzubereiten. Das erste Thema in dem Buch ist IPv6. Ich hab zwar etwas länger als bei IPv4 gebraucht aber so langsam steige ich hinter die Geheimnisse von v6. In dem Buch werden die grundlegenden Funktionen leider nur angerissen, weshalb ich mich entschied dies ein wenig intensiver zu testen und damit "rum zu spielen". Wie auch immer, ich denke jeder von euch kennt den DHCP Relay-Agent für IPv4. RRAS Dienst installieren, DHCP konfigurieren usw. Dies habe ich nun auch bei v6 versucht. Das Szenario sieht wie folgt aus. Ich arbeite ausschließlich mit deaktivierten TCP/IPv4 Protokoll (zu Verbindungstest bzw Überprüfung aktiviert und wieder deaktiviert) Server1: - Server 2008 Enterprise 32bit - Standortlokale IPv6: fec0:0:0:fffe::1/64 für "LAN-Verbindung 1" und fec0:1:1:fffe::1/64 für "LAN-Verbindung 2" (beide statisch) - Verbindungsdienstrolle Routing und RAS - LAN-Routing aktiviert und konfiguriert (IPv6 Häkchen gesetzt) - Zusätzlich DHCPv6 Relay Agent aktiviert Server2: - Server 2008 Enterprise 32bit - Standortlokale IPv6: fec0:1:1:fffe::2/64 für "LAN-Verbindung 1" - DNS Serverrolle (KEIN ADDS) - DHCP Serverrolle aktiviert - Bereiche für fec0:1:1 und fec0:0:0 eingerichtet - Je Serveroption für DNS eingerichtet (fec0:1:1:fffe::2) Client1: - Windows7 Enterprise 32bit - Standortlokale IPv6: fec0:0:0:fffe::c/64 für "LAN-Verbindung 1" Client2: - Windows7 Enterprise 32bit - Standortlokale IPv6: fec0:1:1:fffe::c/64 für "LAN-Verbindung 1" Also Gateway sind jeweils die IPv6 des Server1 aus dem entsprechenden Netz eingetragen. Bei statischer IPv6 ist eine Verbindung hergestellt und Ping sowie tracert sind erfolgreich. Stellt man die Clients auf DHCP empfängt Client 2 DHCP Konfigurationen. Logischer Client 1 sollte diese über den RA bekommen. Frage 1: Ist es bei jedem Windows 7 Client immer erforderlich per netsh das Routerdiscovery zu deaktivieren und managed address zu aktivieren um eine stateful Konfiguration durchführen zu können? Kann man das nicht auch einfacher handhaben bzw zentraler? Frage 2: Bei DHCP-Relay-Agent v4 war es "egal" welche Adresse der DHCP Server hat, Hauptsache der RA konnte ihn erreichen. Bei v6 verlangt er beim eintragen des Ziel DHCP-Servers im RA nach einer globalen IPv6 Adresse. Ist das immer so? Kann man das ändern? Welcher Sinn steckt dahinter? Mit einer Standortlokalen Adresse kann ich wenigstens ein wenig steuern wie weit die Pakete gehen, sofern ich das ganze Konzept verstanden habe. Ich hoffe ihr könnt mir Helfen, den Wald zu roden, in dem ich gerade stehe :) Gruß Andre P.S.: Falls jemand die Info braucht, ich arbeite mit dem Buch 70-648 70-649 Aktualisierung MCSA/MCSE auf Windows Server 2008

Hallo Community, ich brauche eine Bestätigung/Korrektur! Windows 2003 Domäne Funktionsebene Windows Server 2003 3 Domaincontroller Auf DC1 und DC2 laufen DNS Dienste DNS ins AD-Integriert Replikation auf alle DNS-Server in der AD-Domain (http://bit.ly/ftv9Ki) Wir haben im DNS-Protokoll die Warnung 4515 stehen, welche in diesem Artikel (Ereignis-ID 4515 wird unter Windows Server 2003 im DNS-Server-Protokoll protokolliert) behandelt wird. So weit so gut. Wenn ich mit ADSIEdit die 3 Verzeichnisse öffne, finde ich jeweils im ForestDNSZones und DomainDNSZones je einen Eintrag mit "CN=MicrosoftDNS\DC=DOMÄNE.de". Bei Option 3 finde ich "nur" die Einträge zu den RootDNS. Da, wie im 1. Screenshot zu sehen, die Einstellungen auf "DNS-Server in AD-Domain" gestellt sind, würde ich den Eintrag DC=DOMÄNE.de aus DC=ForestDNSZones löschen. Habe ich die Anleitung richtig verstanden und kann ich das so machen ohne, dass etwas flöten geht? Gilt das auch für die Reverseeinträge in der ForestDNSZone? Gruß Andre

Hat super geklappt! Vielen Dank!

Ja ist es auch! Habs mal geprüft! Da sind denke ich nach der Vorlage nicht mit NewSID neue SIDs erstellt worden. Ich hab in dem Thread und hier MS nur den Hinweis gefunden, dass es an für sich keine Probleme gibt. Um mein ursprügliches WSUS Problem zu lösen, wäre ja eine Erneuerung der SID notwendig. Bei den nicht DCs sehe ich da auch kein Problem außer einigen Neustarts. Wie löse ich das aber bei den DCs? Da soweit ich das gelesen habe, die DCs alle die gleiche SID haben, nämlich die der Domäne. Ich würde jetzt so vorgehen, alle betroffenen nicht DCs aus der Domäne entfernen, NewSID drüber laufen lassen und anschließend die Server wieder in die Domäne aufnehmen. Bei den DCs würde ich DC2 und DC3, nacheinander (also erst DC2 komplett, dann DC3) herabstufen, aus der Domäne entfernen, mit NewSID verarzten und sie dann wieder aufnehmen und promoten. Hab ich dabei was vergessen oder übersehen? Gibts dafür eine einfachere Lösung? Natürlich vorher von den DCs die SID auslesen und notieren und eine Sicherung der VMs durchführen. Gruß Andre

Hallo Community, mir ist gerade etwas aufgefallen, was ich mir nicht erklären kann. Wir haben (fast alle) unsere Server mit ESXi virtualisiert. Es handelt sich um eine W2k3 Standard Umgung mit einem AD. Folgende Server sind virtuell: DC1 (mit DNS und DHCP) DC2 (mit DNS und DHCP) DC3 WSUS1 PRINTSERVER1 AV1 MAILSERVER Folgende Server sind "echt": FILESERVER1 FILESERVER2 Das Phänomen macht sich nun folgendermaßen bemerkbar. Die virtuellen Maschinen werden NICHT in der WSUS-Konsole angezeigt sondern nur der, der als letztes auf Updates geprüft hat. Ist das "normal" bzw erklärbar? Die "echten" Server werden wie alle anderen Clients angezeigt. Updates werden auf alle Server verteilt und auch installiert. Der Updatestand ist up to date. Auch handelt es sich hier nicht nur um einen ESXi sondern zwei auf denen die virtuellen Maschinen verteilt sind (kein Cluster). Hat das jemand schon gehabt oder dafür eine Erklärung? Gruß und frohe Weihnachten Andre

Ich glaub man versteht nicht ganz was du wissen willst! Du kannst sicherlich unter W2k3 Server ebenfalls Drucker installieren und diese dann (im Verzeichnis) freigeben. Start > Drucker & Faxgeräte > Drucker hinzufügen... Gruß Andre

Ja an den NTFS Berechtigungen lag es nicht! Die waren alle gegeben (versuchsweise kurzeitig Jeder Vollzugriff). Es muss was damit zu tun haben, dass ich den Datenbankdienst nicht mit dem Netzwerkdienst Prinzipal starten konnte. Warum weiß ich allerdings nicht. Bei anderen Diensten konnte ich als Benutzer den Netzwerkdienst eintragen und er startete auch. So werde jetzt die grobe Kelle nehmen und das System neu aufsetzen.

Diese Einstellungen sind alle so wie sie laut dem Appendix C sein sollen. WSUS läuft auf Port 80 und ist auch so im IIS eingetragen. Ich hab echt keine Idee mehr! Falls euch nichts einfällt werde ich es Wohl oder Übel mit der groben Kelle machen müssen und die Server neu installieren.

Du hast mich falsch verstanden :)! Mir ist schon klar, dass der Netzwerkdienst = NetworkService ist, nur stand dieser, wie gesagt, nirgends drin als zugriffsberechtigt. Dies habe ich nun geändert. Aber leider ohne Erfolg. Das Ergebnis ist das gleiche. Das schöne ist ja, dass die Clients den WSUS finden und sich auch dort eintragen. Jedoch schicken sie keine Berichte und entsprechend bekommen sie auch keine Updates. ClientDiag bringt diese Meldung: Welche laut Google auf nicht vorhandene Treiberupdates zurückzuführen ist und ignoriert werden kann. Da ich aber vorher auch keine Treiber als Updates über den WSUS verteilt habe und diese Meldung nicht erschien, zweifele ich dies an. PS: Natürlich habe ich ihn NICHT beim Selfupdate Ordner eingetragen!

Das verwirrt mich! Wie gesagt als System kann man den Dienst starten.

Das habe ich getan! In keinem Stand der Netzwerkdienst drin. Ich habe es nun laut dem Dokument angepasst. Doch wenn ich den Dienst "Windows Internal Database (MICROSOFT##SSEE)" wieder als "NT AUTHORITY\NetworkService" starten will, kommt eine Meldung, dass der Dienst nicht gestartet wurde, Fehlercode 5 und im Eventlog steht: Systemlog Anwendungslog

Nein nicht das ich wüsste! Der ist ganz frisch installiert worden und außer den Updates (per offline update) ist noch Windows Virtual Server 2005 mit drauf. Ändert dieser vlt etwas essentielles? Ich habe jetzt den MS Internal Database Dienst sowie die WSUS Seite im IIS mit "Lokalem System" starten lassen und seither gehts. Ist auber nicht unbedingt die Musterlösung da er jetzt mehr Rechte hat als er braucht, oder?! //EDIT Das ist das Ergebnis wenn ich mit ClientDiag die Konnektivität des Clients zum WSUS prüfe! Kann damit jemand was anfangen?

Hallo Gemeinschaft, folgendes hat sich mein WSUS für heute ausgedacht: Meine Frage ist, wer braucht Zugriff, welcher Art um diesen Fehler zu beheben? Gruß Andre

Soooooo, nun hab ich mich mal durchgearbeitet. Das erste (de/register der scecli.dll) hat nur solange was gebracht, bis die Maschine einen Neustart durchgeführt hat. Kommt ja mal vor bei Updates oder neuinstallierter Software. Ist also keine Dauerlösung (zumindest bei mir nicht). Erfolg hatte ich mit dem Schritt die DDCP auf "Werkseinstellung" zurückzusetzen. Habe dies mit dem mitgelieferten Tool "dcgpofix" gemacht. Seither scheint es zu laufen. Ich warte noch mal einen Tag ab aber sieht sehr gut aus! Danke @Sunny61! #Top

jop da steht die selbe Meldung drin (ist ja das gleiche Eventlog) und bei der Übersicht steht Gibt es etwas worauf ich speziell auchten sollte?

Hallo, neben meinem anderen Problem, habe ich gleich noch eines, welches ich nicht mit den angebotenen Mitteln beheben kann. Direkt nach der Meldung erscheint die Meldung Nach dem ich heute mehrfach das MS Workaround angewendet habe, weiß ich nun nicht mehr weiter! Der Fehler erscheint dennoch. Hat jemand einen Tipp? Gurß Andre

Ich unterstelle mal, dass du das nicht ernst meinst! Ja ich habe auf OK geklickt! Ich poste das auch nicht um mit meinen OK-Klick Fähigkeiten :) zu prahlen sondern, weil dieser Hinweis nach einigen Minuten wieder erscheint wenn man eine beliebige GPO (außer DDP & DDCP) anklickt. Das kann nicht richtig sein, oder irre ich mich?

Guten Morgen^^, wir haben nach einem "worst case" unsere Domäne neu hochgezogen. Nachdem nun einige GPOs erstellt wurden, bekomme ich nun immer wieder die Meldung Selbstverständlich habe ich mir diesen Rat auch gleich zu herzen genommen und den Artikel gelesen. Dort wird empfohlen, dass man Service Pack 1 installieren soll um das Problem zu beheben. Schade nur, dass ich frisch installierte und geupdatete Server 2003 mit Service Pack 2 habe. Hat jemand eine Idee wobei es sich bei diesem Hinweis noch handeln kann und wie ich die Konsistenz dauerhaft erhalte? Der Hinweis kommt bei allen GPOs außer der DDP und DDCP! Die DCs sind Server 2003 SP2.

Nun ich brauch/kann es nicht mehr testen. Nach einem Neustart des Servers war der Ordner weg. Alles sehr strange!

Vielen Dank! Genau das wollte ich bestätigt haben.

Ich hatte dies auch mal! Server (DC und Printserver) neugestartet, dann ging alles wieder. Wir haben mehr als einen DC und konnten daher mal "kurz neustarten"^^ :D

Ich habe nach Anleitung von MS die Staging Pfad geändert. Jetzt ist der "alte" Staging Ordner noch vorhanden. Meine Frage, wird der Inhalt noch verwendet? Wie kann ich das feststellen, ob? Kann man ihn (bedenkenlos) von Hand löschen? Hat jemand Erfahrung mit dieser Sache gemacht? Gruß Andre

Die sagt nichts dazu! Warum auch, ist ja kein "Fehler" aus ihrer Sicht und der Objektzugriff wird nicht überwacht. Ja die gibt es! Es kann nicht an der dll liegen, da bei "Nachbarverzeichnissen" der Reiter angezeigt wird. Ich wiederhole nochmal, der Reiter wird nur bei diesem einen Verzeichnis nicht angezeigt!! Da ein Neustart des Servers immer angekündigt und in einer ruhigen Phase durchgeführt werden muss, werde ich meine letzte Option (Neustart+ChkDsk) erst heute Nachmittag oder morgen Abend prüfen können. @Defcon5 Ich muss mich gerade mal gekonnt dumm stellen, ich kann nichts mit Cygwin-Tools nichts anfangen?!

Leider ist es nicht so einfach! a) Register "Sicherheit" fehlt und Kommandozeile sagt Zugriff verweigert b) Vererbung von übergeordnetem Ordner fällt aus, da ich dann auch die NTFS Berechtigung der anderen Ordner überschreiben würde.