Jump to content

mcdaniels

Premium Member
  • Content Count

    1,675
  • Joined

  • Last visited

Community Reputation

10 Neutral

2 Followers

About mcdaniels

  • Rank
    Board Veteran

Recent Profile Visitors

388 profile views
  1. Nachdem ich auf den DCs keinerlei Probleme finden konnte, habe ich mir jetzt nochmal alle Eventlogs durchgeschaut. Hierbei ist mir aufgefallen dass die fehlerhafte Auth. immer wieder vom Mailclient (mit dem Userkonto) ausgeht, der per SSO arbeitet (über AD). Das hat mich wieder so einiges gelehrt. Den Benutzer zu fragen: "Bist du noch auf einem anderen PC angemeldet, der eingeschaltet ist und hast etwas offen (Mail zb.)" ist sinnlos!". Denn da kommt dann ein: "Nein". Und bei Konfrontation mit dem aktellen Stand ein: "Oh, daran hab ich nicht gedacht...". Konkret war der User wohl schon länger auf einem PC angemeldet/gesperrt (Mailprogramm offen etc), hat dann auf einem anderen Arbeitsplatz weitergearbeitet und dort das Passwort geändert. Dies dürfte in letzter Instanz die Sperrorgie ausgelöst haben. Allerdings kann ich mir die Medung des DC noch nicht ganz erklären: Die Active Directory-Domänendienste sind beim Übernehmen replizierter Änderungen auf das folgende Objekt auf einen Schreibkonflikt gestoßen. Betreffend Sperrung sag ich jetzt einfach mal nix...
  2. Guten Morgen, leider stehe ich vor einem Problem, bei dem ich anstehe. Ein User hat heute sein Passwort geändert. Seitdem kann er sich nicht mehr einloggen. Im AD bekomme ich EVENT ID 1083 und 1955. Event 1083: Die Active Directory-Domänendienste konnte das folgende Objekt nicht mit Änderungen vom Verzeichnisdienst an der folgenden Netzwerkadresse aktualisieren, weil die Active Directory-Domänendienste mit der Verarbeitung von Informationen ausgelastet war. Betroffen hiervon ist exakt das Userkonto bei dem die Passwortänderung durchgeführt wurde. Das Konto wird auch sofort gesperrt (Wir haben eine Richtlinie per GPO -> 3x Passwort falsch = Kontosperrung). Event 1955: Eine entsperrung hilft nichts, da es sofort wieder gesperrt wird. Es gibt keine Geräte, die sich ggf. mit dem User (mit falschem Passwort) anmelden. Eine Sperrung durch die Eingabe des falschen Passwortes kann ich somit ausschließen. Die Active Directory-Domänendienste sind beim Übernehmen replizierter Änderungen auf das folgende Objekt auf einen Schreibkonflikt gestoßen. Objekt: CN=User,OU=OU_Standardusers,DC=domaene,DC=local Zeit in Sekunden: 0 Ereignisprotokolleinträge vor diesem Eintrag zeigen an, ob die Aktualisierung akzeptiert wurde oder nicht. Ein Schreibkonflikt kann durch simultane Änderungen an demselben Objekt oder durch simultane Änderungen an anderen Objekten, die auf das Objekt verweisende Attribute haben, verursacht werden. Dies tritt in der Regel auf, wenn das Objekt eine große Gruppe mit vielen Mitgliedern darstellt und die Funktionsebene der Gesamtstruktur auf Windows 2000 festgelegt ist. Durch diesen Konflikt werden zusätzliche Aktualisierungsversuche ausgelöst. Wenn das System langsam wirkt, könnte dies daran liegen, dass diese Änderungen repliziert werden. Benutzeraktion Verwenden Sie kleinere Gruppen für diesen Vorgang, oder erhöhen Sie die Gesamtstrukturfunktionsebene auf Windows Server 2003. Repadmin meldet durchwegs erfolgreiche Replikationen. Eine Useranlage funktioniert, die zugehörige Replikation zwischen den 2 DCs auch. Dcdiag meldet auf beiden DCs KEINE Fehler. Eine Passwortänderung bei einem neu angelegten Testuser, zeigt dieses Verhalten nicht. Die Passwortänderung funktioniert, das Konto wird nicht gesperrt. Wo könnte man hier ansetzen? Danke! LG
  3. Hallo, interessanterweise können wir keine Kennwörter ändern, da die Kennwörter lt. Windows 10 / Server 2012 Domäne nicht der geforderten Kennwortkomplexität entsprechen. Selbst wenn wir "komplexere" Kennwörter, wie zum Beispiel !Dace12CC# verwenden, bekommen wir diese Fehlermeldung. Schau ich mir die Anforderungen (GPO) an (und ich hoffe, hier nichts zu übersehen) wüsste ich nicht, woher diese Komplexitätsanforderung kommt. (Sie ist nämlich ganz und gar nicht "scharf" eingestellt. RSOP sagt mir, dass die Kennwortrichtlinie von der Default Domain Policy umgestzt wird. Gibt es hier noch eine Einstellung, die ich übersehe? EDIT: Die 2 Benutzer haben ihr Kennwort gestern Nachmittag geändert. --> Aufgrund der Richtlinie -> Minimales Kennwortalter 1 Tag, hat es dann (logischerweise) nicht funktioniert, dass sie das Kennwort heute Vormittag ändern. *auf den Kopf greif! -- Sorry --
  4. Nach einem Restart des DC1 melden beide DCs, dass AD wieder ordnungsgemäß ausgeführt wird. Replikation auch ok.
  5. exakt! also grundsätzlich kann ich mit vielem leben. Ich konnte die VM (vom def. Datastore) nun "retten". Wurde zuvor ordnungsgemäß heruntergefahren, da der Server ja noch gelaufen ist. Server bootet, meldet das DFS Repl und AD Replikation läuft. repadmin Der DC1 (=physisch) (alle FSMO,GC) meldet auf ein repadmin /showreps --> sämtliche Prüfungen erfolgreich. Der DC2 (=problemDC) (nur GC) meldet auch alles ok. dcdiag DC1 (physisch) OK DC2 (ProblemDC) meckert nach Neustart: Fehler. Ereignis-ID: 0x40000005 Erstellungszeitpunkt: 02/16/2019 08:37:13 Ereigniszeichenfolge: Der Kerberos-Client hat einen KRB_AP_ERR_TKT_NYV-Fehler von Server " rv-dc2$" empfangen. Dies deutet darauf hin, dass das an den Server übergebene T cket noch nicht gültig ist (da Ticket- und Serverzeit nicht übereinstimmen). We den Sie sich an den Systemadministrator, und stellen Sie sicher, dass die Clien zeit mit der Serverzeit synchronisiert ist und dass die Zeit des Schlüsselverte lungscenters (KDC) im Bereich "BRUCKMUR.LOCAL" mit dem KDC im Clientbereich syn hronisiert ist. Warnung. Ereignis-ID: 0x00001796 Erstellungszeitpunkt: 02/16/2019 08:37:19 Ereigniszeichenfolge: Von Microsoft Windows Server wurde festgestellt, dass momentan zwisc en Clients und diesem Server die NTLM-Authentifizierung verwendet wird. Dieses reignis tritt einmal pro Serverstart auf, wenn NTLM von einem Client erstmalig ür den Server verwendet wird. Fehler. Ereignis-ID: 0xC0001B6E Erstellungszeitpunkt: 02/16/2019 08:39:09 Ereigniszeichenfolge: Der Dienst "McAfee ePolicy Orchestrator 5.9.1-Server" wurde nicht ri htig gestartet. Warnung. Ereignis-ID: 0x0000008E Erstellungszeitpunkt: 02/16/2019 08:49:58 Ereigniszeichenfolge: Der Zeitdienst wird nicht mehr als Zeitquelle angekündigt, da die lo ale Systemuhr nicht synchronisiert ist. Fehler. Ereignis-ID: 0x00009007 Erstellungszeitpunkt: 02/16/2019 08:56:41 Ereigniszeichenfolge: Schwerwiegender Fehler beim Erstellen der Anmeldeinformationen Clien für SSL. Der interne Fehlerstatus ist 10013. Fehler. Ereignis-ID: 0x00009007 Erstellungszeitpunkt: 02/16/2019 08:56:55 Ereigniszeichenfolge: Schwerwiegender Fehler beim Erstellen der Anmeldeinformationen Clien für SSL. Der interne Fehlerstatus ist 10013. Fehler. Ereignis-ID: 0x00009007 Erstellungszeitpunkt: 02/16/2019 08:57:24 Ereigniszeichenfolge: Schwerwiegender Fehler beim Erstellen der Anmeldeinformationen Clien für SSL. Der interne Fehlerstatus ist 10013. ......................... Der Test SystemLog für SRV-DC2 ist fehlgeschlagen. Eventlog DC1 meldet dass - da der DC2 offline war - eine temp. Verbindung erstellt wurde und dass die Verbindung wiederhergestellt wird, sobald der Server wieder online ist. DC2 meldet dass AD wieder ordnungsgemäß läuft. Komischerweise macht das der DC1 nicht. (keine derartige Meldung). Könnt ihr mir ggf. sagen, was diese Kerberos-Client-Meldungen bedeuten. Systemuhr läuft synchron....
  6. schön, dass ich euch erstaune Auf dem DC laufen u.a. einige Verwaltungstools / Konsolen, die ich ungern neu aufziehen möchte. Aber seis drum... danke für die Info!
  7. ESXI-Host - defekter Datastore -> Backup des DC (VM) von vorgestern vorhanden.
  8. Hallo, wenn man einen DC von einem älteren Backup (2 Tage alt... VM) wiederherstellt und ein 2ter DC mit allen FSMO-Rollen und GC online bleibt, stellt dies ein Problem dar? Konnte es zB zu AD oder Replikationsproblemen kommen? Der wiederherzustellende DC hat auch den GC (zusätzlich) Danke! LG
  9. Nachsatz: Hab jetzt rein interessehalber nochmals eine 64GB Samsung SSD verbaut (schon etwas älter). Hiermit erhöht sich die Datenrate NAS -> PC auf 400MB/SEC. Die Datenrate von PC -> NAS ist wiederum etwas schlechter. Um die 200MB/SEC. Ich muss aber dazu sagen, dass ich mir nicht die Mühe gemacht habe, die genauen Specs der alten SSD nachzuschlagen. Unterm Strich bin ich nun der Meinung, dass dieses NAS durchaus für den gehobenen "Heimanwender" ausreicht. Ob eine derartige Investition (NAS, Switch, NIC - 10GBIT) dafür steht, lasse ich allerdings im Raum stehen. Danke für euren Support! ...aber mit Sicherheit nicht mit einem derartigen NAS System, sondern mit "etwas Gescheitem"
  10. Hey! Ja ich hatte es zuvor auch mit einer SSD versucht. Es war aber offenbar generell dieses Network Traffic Tool.... JA, ich muss den Tisch verstärken, wenn ich viele Daten drauf schaufel... *lach* @DocData: Naja jetzt ist es zumindest besser wie zuvor!
  11. Konnte jetzt durch das Deaktivieren eines Network Traffic Tools einiges mehr rausholen. Versteh zwar nicht ganz warum es hier zu einem bremsenden Effekt kam (da keine Prioritäten aktiv waren), aber das hat wohl "reingefunkt". Da hab ich ggf. zu früh "geschimpft". PC -> NAS 300mb/sec NAS -> PC 150mb/sec Schon besser... aber allerdings noch immer weit entfernt von 10Gbit.
  12. Das wäre dann ja eigentlich eine Mogelpackung a la carte und eine Frechheit. Was mir gerade vorhin aufgefallen ist, ist, dass die CPU Load auf dem NAS beim kopieren von NAS -> PC auf 100% ansteigt. (allerdings offenbar "nur" ein Kern). Beim Kopieren von PC auf die NAS bleibt die CPU recht "cool". Ein Wahnsinn, wenn die Hardware rund um den 10gbit Controller zu klein dimensioniert wäre. Allerdings würde das den Preis erklären!
  13. Schönen Nachmittag! ich baue mir @Home testhalber gerade ein 10Gbit Netzwerk auf. Hierbei setze ich auf ein 10Gbit NAS (Asustor), Asusswitch (XGU-2008) und eine Intel X550-T2, 10Gb-Ethernet-Netzwerkkarte. Verkabelung CAT5e, Kabellängen max. 1,5 Meter. In der NAS sind 2 WD-RED 3TB HD verbaut, die (testhalber) im Raid0-Mode laufen. Kopiere ich nun vom PC (Samsung SSD) auf das NAS eine größere Datei (2GB), dann erhalte ich nur Datenübertragungsraten von 130MB/sec. Hab schon ein wenig mit den Settings der NIC s) experimentiert. Dennoch bleibt der Transferspeed immer gleich (schlecht). Ein Kopiervorgang vom NAS hin zum PC ist noch viel langsamer: 34 Mb/sec. Der Link wird am PC/NAS mit 10Gbit erkannt. Würden die Kabel das Problem sein, dann wäre der Link wohl nicht mit 10Gbit online. Ich denke dass der Raid 0 Verbund schon eine etwas bessere Leistung bringen sollte? Bin etwas überrascht, dass die Performance so derart mies ist. Teste nachher noch mit einer single SSD. EDIT: SSD verbaut, Kabel auf CAT6 getauscht. Speed exakt gleich "langsam"....
×
×
  • Create New...