daabm

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?

Wäre noch interessant, ob im REMINST-Share evtl. noch mit ACLs was gefuschelt wurde Nicht daß der "fehlerhafte" Account keine Leserechte auf das ImageUnattend.xml hätte oder so ein Kram. Aber ansonsten bin ich bei Nils und Jan - "kann eigentlich nicht sein".

Hat nicht geklappt. Ich versteh's überhaupt nicht. Was meinst Du genau mit Was genau schaust Du da an und welche genauen Schlüsse ziehst Du woraus?

Klar, Bars***e helfen. Skalare auch @Norbert auch mir - ich warte drauf, daß sie wieder alles zumachen...

Stimmt. Man könnte auch sagen "wenn man sie mal hat, wird man sie nie wieder los" Hier sitzt ein Bestand drin, der vor fast 30 Jahren gegründet wurde... Die werden nicht krank (bei mir zumindest bisher nicht), die verhungern nicht, die vertragen zu warmes/kaltes Wasser genauso wie zu weiches/hartes oder zu saures/basisches..

Edit: Ditto für TCP/IP Printer - der "Printer Path" ist ein Muss-Feld.

Du warst auch zu oft auf der Powershell Conf EU

@cj_berlin Weil die GPPs für diesen "Local Printer" auch einen freigegebenen Drucker brauchen, von dem sie den Treiber per Point'n'Print ziehen können. Wenn man nicht ganz viel skripten will, bleibt nur PrintBRM. PS Wir haben's geskriptet (also ich damals), aber da ist (c) von der Firma drauf. Das Skript hat etwa 200k... Und es braucht ne Verwaltungsoberfläche (welcher Client kriegt welche Drucker mit welchen Settings) und ne Schemaerweiterung.

Dann prüfe die Session Timeouts auf dem Host. "MaxConnectionTime" ist nicht der Session Timeout, sondern der Verbindungs-Timeout.

Gute Nacht, lieber Nobby

Gibt auch noch SRPv2.

Schau mal hier: https://schneegans.de/windows/safer/ Entsorge die SAFER Reg-Keys, gibt es auch in HKCU.