Jump to content

igwadmin

Members
  • Gesamte Inhalte

    111
  • Registriert seit

  • Letzter Besuch

Alle erstellten Inhalte von igwadmin

  1. Hallo, ich hätte einmal folgende Frage, wenn sich Benutzer an einen Client anmelden (keine Domäne) und dann auf ein Netz Laufwerk zugreifen, werden ja die Anmeldedaten des Users auch zur Anmeldung auf die Netzwerkfreigabe genutzt. Gibt es das Konto auf dem remote PC ist alles Ok, andernfalls erfolgt die Passwortabfrage. Jetzt wählt sich der Client aber per VPN in ein anderes Netzwerk, so werden dann immer die VPN-Anmeldedaten genommen (diese stehen dann auch im Windows Tresor). Kann man das beeinflussen das hier die Windowsanmeldedaten genommen werden , bzw. kann ich einstellen das immer nach Zugangsdaten gefragt wird (evtl. per gpo)? Ich hoffe einer weis eine Antwort. Grüße
  2. Hallo, ich muss nochmal dieses Thema aufgreifen, weis einer weshalb trotz der verzögerten Zeit auf den Client die Verbindung zu den Controllern noch funktioniert (also Netzlaufwerke , Anmelden usw.)? Dachte das wegen der Zeit die Tickets ablaufen? Das einzige was ich festgestellt habe ist das remote Verbindungen nicht mehr funktionieren. Grüße
  3. OK, fragen wir anders, was ist der Unterschied der drei befehle W32tm /Monitor w32tm /query /status w32tm /query /peers
  4. Moin, ich wollte nochmal das Thema der Zeit aufgreifen, bei dem einen Client wie oben geschrieben lag es wohl an einer leeren Batterie nachdem ich diese getauscht hatte (Bios Zeit richtig eingestellt) hatte war der Spuck vorbei. Jetzt aber die Frage wieso stellt das Bios im laufenden Betrieb die Zeit von Windows um? Ein weiteres Thema, heute sind bei unseren Zeichnern die Netzlaufwerke verschwunden ( kein Zugriff Zeitprobleme usw...) . Auf unserm CAD Server (winserver2008R2) war es 17:07 (eig. aber 15:10), ein Aufruf von w32tm /peers zeigt als Abrufserver was mit ptbtime1.btp.de. W32tm /Monitor zeigte aber die beiden Domain Controller an w32tm /query /status zeigte als Quelle free running System clock ich habe das ganze jetzt mit w32tm /config /syncromflags:domhier /update korregiert, w32tm /peers zeigt jetzt den DomainControler an. Meine Frage was ist der Unterschied zu den befehlen, zeigt Monitor nur die Server in der Domäne an Monitor nur die Quelle und peers den tatsächlichen sync Server? Für eure Hilfe schonmal Danke
  5. das ist eine sichtbare reale Kiste :-) Wir haben Sophos als Management Version, da ist alles Safe
  6. in, also als Logonserver ist der pdcsrv01 in unserer Firma, ich habe den Client aus allen GPOS genommen und die Zeit steht in der Vergangenheit. Der Eventviewer von gestern Abend log folgendes Der Zeitdienst hat festgestellt, dass die Systemzeit um 861605 Sekunden geändert werden muss. Die Systemzeit kann durch den Zeitdienst um maximal 4294967295 Sekunden geändert werden. Stellen Sie sicher, dass die Uhrzeit und Zeitzone richtig sind und dass die Zeitquelle BACKUPSRV01.igw.local (ntp.d|0.0.0.0:123->192.168.0.152:123) ordnungsgemäß ausgeführt wird. Die Meldung ist eig. unlogisch, was geändert werden muss ist doch kleiner als das was er max. ändern kann.... Mir ist das ein Rätsel, am Anfang beim Anmelden stimmt die Zeit und ca. 10 min später steht alles in der Vergangenheit. Ich verstehe auch nicht weshalb die Netz Zugriffe funktionieren wenn doch irgendwann die Authentifizierung wegen des Zeitunterschiedes zum DC nicht mehr funktionieren sollte. Grüße und Danke
  7. Also im Anhang mal ein Client wo es gerade eben abgerufen (11:06 ,14.3.16)16:05 am 4.3.2016 ist. Was mir komisch scheint ist der Abrufintervall, wie oft fragt man eig.die Server ab, das ist bei allen Clients immer so lange. Letzte erfolgr. Synchronisierungszeit: 14.03.2016 07:25:36 Quelle: pdcsrv01.igw.local Abrufintervall: 10 (1024s) \Users\hf>nltest /dsgetdc:xyz.local Domänencontroller: \\pdcsrv01.xyz.local Adresse: \\192.168.0.120 Domänen-GUID: 5d6039e3-92e2-4223-87ec-17ea189fceca Domänenname: xyz.local Gesamtstrukturname: xyz.local DC-Standortname: Standardname-des-ersten-Standorts Unserer Standortname: Standardname-des-ersten-Standorts Kennzeichen: PDC GC DS LDAP KDC TIMESERV GTIMESERV BESCHREIBBAR DNS_DC DNS_DOMAIN DNS_FOREST CLOSE_SITE FULL_SECRET WS DS_8 DS_9 Der Befehl wurde ausgeführt. C:\Users\hf>w32tm /monitor pdcsrv01.igw.local *** PDC ***[192.168.0.120:123]: ICMP: 0ms Verzögerung NTP: +0.0000000s Offset von pdcsrv01.xyz.local RefID: ptbtime1.ptb.de [192.53.103.108] Stratum: 2 BACKUPSRV01.igw.local[192.168.0.152:123]: ICMP: 0ms Verzögerung NTP: +0.0006668s Offset von pdcsrv01.xyz.local RefID: pdcsrv01.xyz.local [192.168.0.120] Stratum: 3 [Warnung] Die Reversenamenauflösung ist die beste Möglichkeit. Sie ist ggf. nicht korrekt, da sich das Ref-ID-Feld in Zeitpaketen im Bereich von NTP-Implementierungen unterscheidet und ggf. keine IP-Adressen verwendet. C:\Users\hf>w32tm /query /status Sprungindikator: 3(die letzte Minute umfasst 61 Sekunden) Stratum: 0 (nicht angegeben) Präzision: -6 (15.625ms pro Tick) Stammverzögerung: 0.0625000s Stammabweichung: 7.8377789s Referenz-ID: 0x00000000 (nicht angegeben) Letzte erfolgr. Synchronisierungszeit: 14.03.2016 07:25:36 Quelle: pdcsrv01.xyz.local Abrufintervall: 10 (1024s)
  8. nicht allen aber bei vielen clients ca. 30 von 70. Die Zeit stimmt beim Hochfahren und anmelden und plötzlich aus dem nix steht da 9 September 2016 um 14:09. Wenn ich dann w32TM /query /status ausführe steht der DC als Zeitquelle (der DC hat aber die korrekte Zeit). Ein w32tm /resync geht net da der Zeitunterschied zu groß ist. Was ich aber auch nicht verstehe warum die Clients die Netzlaufwerksverbindunge nicht verlieren, die Kerberos Tickets dürften doch gar nicht mehr stimmen (Remote Desktop geht z.b. net mehr, Fehler mit der zeit....) Nach einem Restart steht wieder die richtige DC Zeit. Wieso bzw. woher kommt der Zeitsprung so plötzlich? Wie funktioniert das mit der zeitsyncronisation erst Bios und beim Anmelden dann vom DC worauf dann wieder die Bios Zeit so eingestellt wird??? Danke schon mal im voraus Sie geht falsch das ist fakt , falsch ausgedrückt, sorry
  9. Hallo, ich hoffe einer von euch kann mir bei folgenden Problem helfen. Ich habe das Gefühl das seit der Umstellung in unserer Firma der Clients auf von Win 7 auf win 10 die Uhren bei manchen Clients falsch geht. Die beiden Domain Controller (WinServer 2012R2) haben die richtige Zeit, das passt auch soweit aber die Clients ändern im Betrieb plötzlich Zeit und Datum, komischerweise ist dann auch im Bios die Zeit plötzlich geändert. Ein Test mit w32tm /query /status zeigt an das die zeit mit dem DC gesynct wurde (was heist Abrufintervall 15?). Auch der Aufruf von w32tm /monitor zeigt an das die DC als zeitquelle dienen. Das Problem haben nicht alle Clients. Kann eig. Windows die Bios Zeit ändern oder wie funktioniert das, was hat eig. Vorrang Windows oder Bios zeit? Für einen Tipp wäre ich euch echt dankbar!! Grüße
  10. Hi, wie erkenne ich den ein USN Rollback? ich dachte ehre an Tompstone Lifetime usw. es wurde je der Server so gestartet wie er abgeschaltet wurde also alle USN sollten ja so geblieben sein. der Server wurde ja nicht von einer früheren Sicherung wiederhergestellt, lediglich das Datum nach dem Start war in der Zukunft. Der DC hat alle FSMO Rollen und die Zeit war mit Bios Sync in w32tm hinterlegt. Nur der ESXI host synct die Bios Zeit der VM mit der Physischen Hardware, ich habe die Zeit natürlich auf dem ESXI host korregiert. Die Zeit sync des DC (alle FSMO) habe ich auf Internet abgeändert. warum geht aber die DNS Replikation und der Rest nicht bzw. warum zeigen die anderen DC einen Fehler mit repadmin aber der betroffene DC es sei alles OK?
  11. Hallo bin neu um Forum und wende mich an euch weil ich ein Problem habe und nicht mehr ganz weiter weis. Wir haben in unserer Firma mehrere Server über VM auf mehreren Hosts laufen, jetzt habe ich einen Server die VM (DC win 2008R2 mit allen Rollen) heruntergefahren und auf einen anderen Host kopiert. Dort die Maschine wieder gestartet und die alte gelöscht ( die Maschine war also während der Kopieraktion aus , USN Rollback usw....). Nun nachdem das ganze lief musste ich feststellen das auf einmal die Uhrzeit und Datum des DC auf Mai 15 stand, es war ja aber Februar 16. Natürlich hagelte as Anmeldefehler der Clients beim Anmelden an der Domäne aber nicht bei allen (ich vermute nur die welche diesen DC als anmelde Server hatten), die anderen DCs hatten noch Februar und die korrekte Uhrzeit. Also habe ich den Problem DC abgeschaltet und gesehen dass die Zeit des ESXI falsch war nachdem ich es korrigiert hatte, den DC wieder gestartet und Zeit war wieder korrekt (der DC Synct mit der Bios Zeit und die wird vom Physischen ESXI genommen). Jetzt habe ich gemerkt das beim Anmelden der Clients Laufwerk Mapping zu freigeben des DC nicht mehr funktionieren (Zielprinzipalname falsch, über IP funktioniert es aber). Nachdem ich auf besagten Controller einmal dcdiag als auch adprep laufen lassen habe wäre alles OK keine Fehler. Das Ganze aber auf einen der beiden anderen DC ausgeführt bringt Fehler in der Replikation Zielprinzipialname falsch usw. Komischerweise funktioniert aber die DNS Replikation wenn ich auf dem einen DC einen Eintrag anlege ist dieser kurze Zeit später auf dem Problem DC. Meine Fragen wären jetzt Was ist hier eigentlich das genaue Problem (kerberos SPN)??? Thema Tompstone Lifetime, wie erkenne ich das diese eingetreten, abgelaufen ist? Warum funktioniert das Mapping über FQDN Name zum DC nicht, was ist da der Grund? Warum geht die DNS Replikation aber der Rest nicht? Wieso zeigt der Problem DC keine Fehler mit repadmin und Dcdiag an aber die anderen ja? ich hoffe ihr könnt mir helfen, das Problem ist das auf dem Problem DC, Autocad und und der Plancal Projektserver laufen für unsere Zeichner. ich weis das auf einen DC keine anderen Produktiven Dinge laufen sollen, dass wird auch unverzüglich behoben wenn es wieder läuft. Danke schon mal an alle :-)
×
×
  • Neu erstellen...