Rumak18

Lag am Bitdefender Client. Warum genau kann ich nicht sagen, aber in dem Moment als er deinstalliert worden ist, funktionierte das Drucken.

@Nobbyaushb: TCP Port 9100 geht erfolgreich zur Drucker-IP. @MurdocX: Die Clients prüfe ich gar nicht. Solange der Server nicht durcken kann, brauche ich die Clients nicht prüfen. @daabm: Ich finde leider keine Fehler im Event Logs.

@M4rt1n: Verstehe ich nicht ganz. Du hast die GPO nun einfach deaktiviert oder auf "nicht konfiguriert" gesetzt? @Nobbyaushb: Also angenommen der UNC Pfad würde gehen und der Netzlaufwekrbuchstabe nicht...was dann? Die User benötigen ja was "logisches" zum Arbeiten.

Hi, kann das aktuell nicht gegenprüfen, da die zwei User, die das Problem noch haben, nicht bzw. nie über VPN arbeiten. Allerdings müsstest du das ja dann im Büro gegenprüfen, wenn du ein Excel Dokument lokal, also beispielsweise von C:\temp aufmachst oder? Ich werde Freitag oder Montag versuchen den Weg abkzukürzen, in dem ich nur das lokale Profil (Ohne das AD Profil). VIelleicht hilft es ja. Ich melde mich natürlich.

Hallo Zusammen, installiere gerade einen Printserver auf einem Windows Server 2022 Standard Server. Egal welchen Drucker ich über das Netzwerk , egal mit welchem Treiber installiere, der Druckauftrag läuft ins Leere und endet mit "Fehler" (Daher habe ich keine konkrete Fehlermeldung). In der Druckerwarteschlange steht dann einfach "Fehler - Wird gedruckt" und verbleibt unendlich lang. Druckerdienst läuft natürlich. Drucken über andere Netzwerkddrucker von diesem Server aus funktioniert auch. Die Drucker installiere ich über TCP-IP. Drucker ist pingbar und über WEB erreichbar.

Bei mir funktioniert das "excel /e" nicht. Bzw. es hilft nicht. Excel stürzt irgendwann dennoch ab. Wie gesagt half bei mir das Löschen des Profiles (Siehe Beitrag oben). Allerdgins ist das für viele User viel zu aufwändig.

Kann es an der Stelle nur bestätigen. Seit ca. knapp einer Woche stürzt Excel direkt nach dem Start ab. Versucht in den abgesicherten Modus zu gehen. Muss wohl wieder an irgendeinem Microsoft Update liegen. @schlingo Deine Lösung bezieht sich ja klar auf Outlook mit E-Mail Adressen. Das hilft nicht. Was bei mir geholfen, allerdings für viele User nicht gerade effizient ist, ist das Löschen des lokalen und AD Profiles des Benutzers. Lokal muss dann noch die alte SID in der Registry unter Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList gelöscht werden. Eine schnellere Lösung wäre von Vorteil...

Sorry, will nicht pingelig, aber ich bin es nun mal Die Einstellungen der GPO Settings für NTP werden unter HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\W32Time\Parameters und HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders angewendet. Nicht unter "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\W32Time\Parameters", wo man anscheinend die Default Werte sieht. Nur der Vollständigkeit halber.

OK. Ich glaube ich hab den Grund gefunden. Der Hyper-V Host hat die INtegrationsdienste "Zeitsynchronisierung" aktiv gehabt. Ich habe den Haken entfernt. Der vorherige Fehler mit "Local CMOS Clock" war eine Folge meiner Ungeduld. Nach einem "w32tm /resync" erhalte ich nun den korrekten Server. Das ging eigentlich aus der ersten Nachricht von dir nicht hervor. Zumindest nicht für mich. Sorry. Und WO schreibt dann die GPO diese Einstellungen in der Registry?

Hi, nein, habe gerade die DGPOs nochmals überprüft. Sie werden laut "gpresult /r" übernommen. Auf dem DC01 (PDC) wird mit "w32tm /monitor" weiterhin die Anzeige wie oben beschrieben gezeigt. Nicht der tatsächlich konfiguriert NTP. Für die Clients sind gar keine GPOs konfiguriert, was die Zeit anbelangt. Ich könnte das Ganze natürlich per Registry manuell anpassen, aber dann halte ich die GPOs für überflüssig. Der PDC hat seiner Registry immer noch den von Windows Server verwendeten "time.windows.com,0x8", trotz GPO. Auffällig nun: "w32tm /query /source" liefert: Local CMOS Clock Das sollte wohl was anderes sein.

Hmmm... aber genau an der Stelle weiß ich nicht weiter...

Hi, wie der Betreff schon sagt...die Zeit in meiner Domäne war von anderen Admins wohl konfiguriert worden mit GPOs, die es teils nicht mehr gibt. Nach einem ordnetlichen Aufräumvorgang habe ich zwar keine Probleme, aber irgendwie habe ich das Gefühl ,dass die Zeit nicht das tut , was sie machen soll. In meiner Domain existieren zwei DCs (PDC: 192.168.168.20 ; DC2: 192.168.168.30) und ich möchte die Sophos Firewall (192.168.168.10) als DNS Server für den PDC konfigurieren. Ich habe gemäß Microsoft Empfehlungen eine GPO für meinen PDC erstellt (WMI Filter etc.) Für den zweiten DC und Clients wurde nichts konfiguriert. Der PDC hat in seiner GPO die folgenden Einstellungen: Computer Configuration > Administrative Templates > System > Windows Time Service > Time Providers -> Windows-NTP-Client konfigurieren: NTPSERVER: 192.168.168.10 // Bei dieser Einstellung bin ich nicht sicher, ob und welches FLAG gesetzt werden muss (Es gibt ja 0x1,0x2 aber auch 0x01 , 0x02, 0x09 etc) Type: NTP CrossSiteSyncFlags:2 ResolvePeerBackoffMinutes:15 ResolvePeerBackOffMaxtimes: 7 SpecialPollInterval:3600 EventLogFlags: 0 Computer Configuration > Administrative Templates > System > Windows Time Service > Time Providers -> Windows-NTP-Client aktivieren: Aktiv Computer Configuration > Administrative Templates > System > Windows Time Service > Globale Konfigurationseinstellungen: FrequencyCorrectRate 4 HoldPeriod 5 LargePhaseOffset 50000000 MaxAllowedPhaseOffset 300 MaxNegPhaseCorrection 172800 MaxPosPhaseCorrection 172800 PhaseCorrectRate 1 PollAdjustFactor 5 SpikeWatchPeriod 900 UpdateInterval 100 Allgemeine Parameter AnnounceFlags 5 EventLogFlags 2 LocalClockDispersion 10 MaxPollInterval 10 MinPollInterval 6 RequireSecureTimeSyncRequests 0 UtilizeSslTimeData 1 ChainEntryTimeout 16 ChainMaxEntries 128 ChainMaxHostEntries 4 ChainDisable 0 ChainLoggingRate 30 Das Problem mit PDC: Registry: Unter dem Registry Pfad "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters" des PDCS sehe ich auf dem unter dem Registry Schüssel "NTPServer" immer noch "time.windows.com,0x8", obwohl ich durch die GPO ja "192.168.168.10" eingegeben habe. Auch der "Type" steht anstatt auf "NTP" auf "NT5DS". Die GPO für den PDC selber wird aber angewendet, zumindest sagt das "gpresult /r". Werden die Registry Schlüssel per GPO denn nicht aktualisiert? Das Problem auf den Clients oder Mitgliedsservern: Nun habe ich das Problem, dass die "Clients" (Der zweite DC, Server und Desktops) nicht die exakte Zeit haben wie der PDC. Selbst nach einem "w32tm /resync" Befehl nicht. Es sind immer ca. 30 Sekunden Unterschied. Nichts schlimmes, aber das suggeriert mir, dass es nicht funktioniert. Ausserdem erhalte ich auf einem Client mit dem Befehl "w32tm /query /configuration" folgendes: [Konfiguration] EventLogFlags: 2 (Lokal) AnnounceFlags: 10 (Lokal) TimeJumpAuditOffset: 28800 (Lokal) MinPollInterval: 6 (Lokal) MaxPollInterval: 10 (Lokal) MaxNegPhaseCorrection: 4294967295 (Lokal) MaxPosPhaseCorrection: 4294967295 (Lokal) MaxAllowedPhaseOffset: 300 (Lokal) FrequencyCorrectRate: 4 (Lokal) PollAdjustFactor: 5 (Lokal) LargePhaseOffset: 50000000 (Lokal) SpikeWatchPeriod: 900 (Lokal) LocalClockDispersion: 10 (Lokal) HoldPeriod: 5 (Lokal) PhaseCorrectRate: 1 (Lokal) UpdateInterval: 100 (Lokal) [Zeitanbieter] NtpClient (Lokal) DllName: C:\Windows\system32\w32time.dll (Lokal) Enabled: 1 (Lokal) InputProvider: 1 (Lokal) CrossSiteSyncFlags: 2 (Richtlinie) AllowNonstandardModeCombinations: 1 (Lokal) ResolvePeerBackoffMinutes: 15 (Richtlinie) ResolvePeerBackoffMaxTimes: 7 (Richtlinie) CompatibilityFlags: 2147483648 (Lokal) EventLogFlags: 0 (Richtlinie) LargeSampleSkew: 3 (Lokal) SpecialPollInterval: 7200 (Richtlinie) Type: NT5DS (Richtlinie) VMICTimeProvider (Lokal) DllName: C:\Windows\System32\vmictimeprovider.dll (Lokal) Enabled: 1 (Lokal) InputProvider: 1 (Lokal) NtpServer (Lokal) DllName: C:\Windows\system32\w32time.dll (Lokal) Enabled: 0 (Lokal) InputProvider: 0 (Lokal) während mir "w32tm /monitor" auf dem selben Client andere Einstellungen liefert: DC01.int.local *** PDC ***[192.168.168.20:123]: ICMP: 1ms Verzögerung NTP: +0.0000000s Offset von DC01.int.local RefID: 80.84.77.86.rev.sfr.net [86.77.84.80] Stratum: 2 DC02.int.local[192.168.168.30:123]: ICMP: 0ms Verzögerung NTP: -21.1807467s Offset von DC01.int.local RefID: 'VMTP' [0x50544D56] Stratum: 1 [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. Danke für euere Hilfe!

Ok. Hat so wunderbar geklappt. Computer hinzugefügt und es funktioniert...Danke!

Danke tesso und testperson. Ich gebe Morgen Bescheid , ob es geklappt hat.

Danke. Werde es versuchen. Zur Klarstellung: Es soll der/die betroffene(r) Computer zur Delegierung hinzugefügt werden, obwohl sich der/die Computer nicht in der selben OU befinden wie die GPO?