tesso

Raus mit dem Haken.

Wenn die GPOs jetzt ankommen markiere bitte den helfenden Post als Lösung und mach bitte einen neuen Thread auf. Dann kümmern wir uns um dein Zeitproblem, Hier wird das unübersichtlich, zumal die Überschrift "GPOs ziehen nicht" lautet. Danke

Jetzt liest den schon geposteten LInk zum Setzen der Zeit GPOs und setzt das um. Dann wird auch alles funktionieren. BTW: gpupdate hast du ausgeführt?

Dann versuche auf einem Client das windows Management zurückzusetzen. Danach gpupdate und schaur was das gpresult sagt.

Geht es etwas ausführlicher? gpresult als welcher NUtzer ausgeführt? mit "ausführen als admin"-Konsole oder nicht? Ihr habt anscheinend etwas mit wmi verbogen. Vielleicht hilft reset von wmi auf einem Client. Die Zeitunterschiede würde ich erstmal hinten anstellen. Löse erst einmal dein GPO Problem. Wenn das wieder funktioniert, dann das Zeitproblem. Reden wir von physischen Clients oder VMs? Sind auch Server betroffen?

Was ist denn der Stand? GPOs kommen an oder nicht? Funktioniert das Report der GPO remote und/oder (nur) lokal? Zeitabgleich funktioniert oder nicht?

Den scp abzufragen findet man bestimmt mit einer Suchmaschine. Ich erwarte einfach etwas Eigeninitiative.

Den SCP bist du weiterhin schuldig. Dann hätten wir das viel eher gefunden. Markiere bitte einen Beitrag als Lösung, damit der Thread als gelöst erscheint. Danke

Danke für die Rückmeldung. Markierst du den Thread noch als gelöst? Geht wohl im ersten Beitrag oder musstest einen Beitrag als Lösung markieren? Ich weiß es nicht.

Und die restlichen Fragen? Kommst du freiwillig mit den Antworten um die Ecke?

Kommst du über owa an das Postfach? Welche URL nutzt du für SCP und MAPI? Steht der/die Namen auch im Zertifikat?

Versionsnummer?

Dort stehen die Serveradressen wo der Client Autodiscover sucht. Hat schon jemand nach der Outlook Version gefragt?

Der Client scheint AD Member zu sein. Schau dir mal den SCP am Exchange an.

Das habe ich gefunden. https://sysadminde.com/questions/871051/doing-dpi-scaling-server-side-rdp-windows-server-2016

Mal eine blöde Frage, biite antworte trotzdem. Was hat der Client als GW eingetragen? Kannst du das Gateway per ping erreichen? Ich hatte mal eine Testumgebung, da musste ich dem Client ein GW verpassen. Das musste einfach nur erreichbar sein, Hatte es dann mit dem DC probiert. Warum auch immer lief es dann.

Da klingelt etwas bei mir. Nagel mich nicht fest, ich meinte das Feature Desktopdarstellung muß am TS installiert sein. Recherchiere das bitte mal selbst.

BTW: Warumn ist die RIchtlinie erzwungen?

Keine freie Adressen mehr? Irgeneinde Firewall/Router zwischen PC und DHCP? Vlans im Einsatz? Die Informationen sind ein bisschen dürftig um den Fehler einzugrenzen.

da fällt mir als erstes ein try catch Konstrukt ein. Im catch dann schreiben der Meldung in ein Log.

Sowas? https://4sysops.com/archives/how-to-find-a-logged-in-user-remotely-using-powershell/

Hast du es mit und ohne Antivirus getestet? Gibt es auf dem NAS evtl. auch einen Virenscanner?

Ist die Access Datenbank von dir? Ansonsten den Entwickler fragen wie er das macht. Ich vermute stark die Verzögerung kommt durch das Arbeiten über das Netzwerk. Da habe ich in der Vergangenheit schon seltsame Effekte mit Access gesehen.

Zu den restlichen Dingen wirst du bei google bestimmt auch fündig. Ich nutze Teams nur für Videokonferenzen.

zu 1: https://docs.microsoft.com/de-de/microsoftteams/presence-admins