daabm

Ich zitiere mich mal selber.

Wir haben jede Menge offene Stellen... Und wir zahlen gut für die Schmerzen

Kachelmann oder Plöger? SCNR

Muß ja auch so sein, wenn das Ziel immer $Folder2Path ist Da mußt Du dann schon etwas "Pfadmassage" betreiben. Aber über Robocopy wurde genug gesagt, es muß nicht immer ein Skript sein

Es gibt Fehlersituationen bei der GPO-Verarbeitung, in denen keinerlei GPOs mehr verarbeitet werden. Aber Du hast jetzt so viel experimentiert, daß das vermutlich nicht mehr nachzuvollziehen ist. Die DCDIAG-Fehler bei DNS finde ich mindestens eigenartig - AD-integriertes DNS? Wenn ja, was steht denn so im DNS für diese Einträge? (Spoiler: nslookup -type=SRV _ldap._tcp.dc._msdcs.domain.tld)

Ne, Notepad aufgerufen und ein "changelog.txt" erstellt...

GPOs haben ein eigenes Eventlog, da steht ziemlich viel drin. Und dann gibt's noch das gpsvc debug logging. Beides könnte hilfreich sein. Und eine Analyse von AD- und Sysvolreplikation auch. Ich glaube nicht, daß DU ein "Riesen Problem" hast, ich glaube Du gehst momentan zu unstrukturiert an die Diagnose.

Windows - ebenso wie DNS, die FB ist nur Forwarder. Hat ja alles bis zu einem Zeitpunkt X funktioniert, an dem sich Y geändert hat. Und weil ich das nicht rechtzeitig mitbekommen hab, weiß ich blöderweise weder wann X noch was Y ist :-( (Und nein, ein Change Log gibt's hier privat - noch - nicht, das werd ich wohl jetzt anfangen...)

Die meisten Browser legen eine 0 kb-Datei an und laden währenddessen in eine .part-Datei herunter (oder wie auch immer die je Browser heißen mag und wo auch immer die je Browser liegt). Ich würd mal Sysinternals Process Monitor anschmeißen während eines Downloads und filtern auf den Dateinamen ohne Endung. Dann weißt Du, was genau passiert.

Nicht erkennbar. Die Clients hüpfen ja frei hin und her, manchmal 2,4 manchmal 5. Und die Repeater sind Crossband. Beim Surface Laptop (Qualcomm Atheros QCA61x4A Wireless Network Adapter - 12.0.0.926) kann ich das nicht mal konfigurieren, der Treiber hat nur 4 Einstellungen. Edit: Eine neuere Version hab ich nur auf einer obskuren Seite gefunden (https://www.ath-drivers.eu/download-driver-for-Atheros-chipset-with-id-129-and-Windows10-64bit.html), den werde ich eher nicht installieren...

Eigentlich kann's ja nur was in der FB sein. Aber es ist halt völlig erratisch... Kurz zu 2 Tests, die ich gemacht hab: 1. Ein WLAN-Client (Surface Go2) funktioniert ohne Probleme. Der kommt über einen Repeater (Fritz 1200) rein. Ich lege einen der nicht funktionierenden daneben, der laut FB dann über den gleichen Repeater verbunden ist - geht nicht. 2. Im Keller ist ein 1260 Powerline Adapter mit WLAN. An dem hängt ein Desktop ohne WLAN. Da hab ich gestern den WLAN Stick angestöpselt und LAN deaktiviert - funktioniert weiterhin. Daneben liegt der Surface Laptop. Da den gleichen WLAN-Stick eingesteckt - geht nicht. Wie soll ich bei AVM mit der wirren Situation den Support anfragen? Also "wie beschreibe ich den Fehler" so, daß AVM mich nicht direkt auslacht? Das mit dem alternativen AP probiere ich, sobald ich dazu komme. Die alte 7490 liegt noch im Regal. Edit: PiHole gibt es nicht, alles straight forward. Windows-integriertes DNS - und alle Tests in diese Richtung waren immer erfolgreich. Namensauflösung klappt korrekt round-robin, Port Queries immer erfolgreich. Nur "NO SUCH DOMAIN" über WLAN... Edit2: etc\hosts grad sicherheitshalber auch noch angeschaut - steht nichts drin.

Wenn sich Skript und GPP gleich verhalten, würde ich jetzt über Logging im Skript nachdenken

Ne hab ich nicht "net view \\192.168.100.111" funktioniert, "net view \\dc01" bringt access denied - Kerberos-Tickets hab ich in dem Moment keine. Schalte ich WLAN aus und LAN ein, geht es sofort und ich hab meine Kerberos-Tickets. Welche sollte ich probieren? Betroffen sind verschiedene Laptops, einer mit Intel, einer mit Realtek, einer mit Qualcom. Kann das ein Treiberproblem sein?

That said. Am berühmten Ende des Tages wird mit dem Handy der Monitor fotografiert. Technik hat Grenzen...

Grad geschaut, ist aus. Nein, aber das Problem war schon vorher da. Das zieht sich schon ein paar Wochen, bis ich irgenwann beschlossen habe, daß ich mehr Expertise brauche als ich alleine habe Was mich dabei wahnsinnig macht: LAN kein Problem, WLAN geht/geht nicht je nach Rechner. Aber alle Ports sind erreichbar, LDP mit User/PW/Domain geht. Und daß es einen (!) WLAN-Client gibt, der überhaupt keine Probleme hat, irritiert mich am meisten. Ich bin echt planlos...

netsh int ipv4 reset netsh int udp reset Alles nix geholfen... Hm - MTU - wie könnte ich das prüfen? Wie oben geschrieben, hab UDP bis 5k Payload geprüft, kam korrekt an. Und Routing ist nicht im Spiel, das ist alles im gleichen IP-Netz. Natürlich über den internen Switch der Fritte, aber ich hab die nicht gerootet oder so

Ein Fass ohne Boden heißt Rohr

7.29 ist seit 2 Stunden installiert. Hat nichts geändert. Und es wird noch komischer - heute kam auch ein WLAN-Stick für weitere Diagnosen... 1. Stick eingesteckt an einem W10-Rechner, der noch nie WLAN hatte: Geht problemlos. 2. Gleichen Stick eingesteckt in einen der Clients, die nicht gehen: Geht immer noch nicht. WTF?!?

GPP Debug logging aktivieren und nachschauen, was passiert. https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/enabling-group-policy-preferences-debug-logging-using-the-rsat/ba-p/395555

Hallo zusammen. TL;DR: Seit einiger Zeit (genauer Zeitpunkt unbekannt) habe ich bei meinen WLAN-Clients keine Verbindung mehr zur AD-Domäne und damit auch keinen Zugriff mehr auf Shares. Bei allen LAN-Clients gibt es kein Problem. Wenn ich im laufenden Betrieb von WLAN auf LAN umschalte, funktioniert sofort alles. Und ich habe keine Idee mehr, woran das liegen könnte... Switch/AccessPoint ist eine FB7530ax. Clients sind verschieden, mal Intel-Wifi, mal Realtek. Mal Win11 RTM, mal Insider Dev, einer bis gestern auch Win10 RTM 21H2. Firewall auf den Servern ist aus, auf einem Client testhalber auch mal, keine Änderung. Mehr Details zur Infrastruktur gerne, wenn's zielführend ist. Zugriffe auf Shares enden so: Test mit "nltest /dsgetdc:" endet mit 0x54b ERROR_NO_SUCH_DOMAIN. Ein parallel laufender Trace auf dem Client liefert das als Ergebnis: (Die ICMP-Pakete sind nur der Marker für Beginn und Ende) Der Client bekommt also Antworten, aber er macht danach nichts mehr?!? Nach der Antwort auf die 2 LDAP-Pings sendet der Client keine weiteren Pakete mehr zu den Domain Controllern... Was ich auch nicht verstehe: In der LDAPMessage ist das als Searchfilter drin: (&(DnsDomain=domain.binder.local.)(Host=ZENBOOK-UX360)(DomainGuid={B3CF0610-DE22-F841-AACD-DD3F547A32DD})(NtVer=16:00:00:00)(DnsHostName=ZENBOOK-UX360.domain.binder.local)). Die Suche liefert natürlich keinen Treffer: SearchResultDone: Status: Success, MatchedDN: NULL, ErrorMessage: NULL. Aber vielleicht ist das ja korrekt so und dient nur dazu, dem DC ein paar Daten über den Client zu liefern? Die "üblichen" DC-Ports (88,135,389,445,464,3268) sind alle erreichbar. Die DynRPC-Ports auch (https://devblogs.microsoft.com/scripting/testing-rpc-ports-with-powershell-and-yes-its-as-much-fun-as-it-sounds/). Die Security Eventlogs der DCs enthalten nichts, was mir irgendwie weiterhilft (ja, Auditing ist aktiv). Ich hatte schon den Verdacht, daß die Fritte UDP-Pakete kaputt macht. Also kurz mit https://cloudbrothers.info/en/test-udp-connection-powershell/ geprüft, die vom Client gesendete Payload kommt bis 5.000 Byte am Server korrekt an und umgekehrt. Internet, Browser-Zugriffe im internen Netz, RDP kreuz und quer - funktioniert alles. Nur domänenauthentifizierte Zugriffe von WLAN-Clients auf egal was gehen nicht. AD-Zugriff per ldp.exe geht auch, Bind als angemeldeter Benutzer aber nicht (klar, kann mich ja nicht authentifizieren). Bind mit User/Kennwort/Domäne geht sofort. Den Win10-Client habe ich gestern komplett neu aufgezogen mit Win11 vom ISO - gleicher Fehler. Und noch komischer: Ich hab einen einzigen WLAN-Client (Surface Go 2, das sich über einen Fritz Repeater 1200 mit der Fritte verbindet), der keinerlei Probleme erkennen läßt. Lege ich einen nicht funktionierenden daneben und gehe über den gleichen Repeater, funktioniert der aber weiterhin nicht. Hat noch jemand eine spritzige Idee? Oder könnte nach Lieferung weiterer Informationen eine Idee haben?

Defined. Ist klein

Ich bin bei Nils. Unsere Samaccountnamen basieren auf kryptischen Codes, die aus der Personalverwaltung kommen und damit automatisch konzernweit eindeutig sind. Mailadressen werden aus Vorname.Nachname@Firma und bei Kollisionen mit ner fortlaufenden Zahl am Nachnamen gebildet. Der UPN ist nie die Mailadresse, sondern immer der Samaccountname+interner Domänenname. Das mit "Samaccount aus Vorname/Nachname ableiten" funktioniert nur in kleinen Umgebungen und auch da oft nur leidlich. Die M365-Anmeldung passiert nicht mit der Mailadresse, sondern mit dem UPN. Der ist auch ein Mailalias, aber halt nur ein Alias. Glaub ich wenigstens - das ist nicht meine Baustelle

Kaffeemaschine hab ich mal ausgeschaltet, braucht glaub keiner mehr. @Nobbyaushb die braucht ne Zeitschaltuhr

Da bin ich split brain - WDS ist KISS, MDT ist "ich mach alles automatisch". Beides hat Vorteile. Privat WDS, weil mir da der Aufwand für MDT zu groß ist Hilft dem TO aber alles nix. Und bevor er sich wieder meldet, brauchen wir auch nicht weiter philosophieren...

War das Send As und Send on behalf?