daabm

Ist möglicherweise ein Bug im MSI - das muß die administrative Bereitstellung unterstützen.

Wie gesagt: In einem Netzwerktrace kannst Du den SSL-Handshake nachvollziehen und da siehst Du auch, was schiefgeht. Und daß das "lokal auf der CA" läuft, bedeutet erst mal nichts. Das Windows-OS muß dieser CA ja auch erst mal vertrauen.

Das ist dann aber Security by Obscurity... Man könnte das über die Windows-Firewall lösen, outbound per Default blocken und nur Richtung Proxy alles zulassen (oder auch nur 80/443). In der Annahme, daß der Kiosk-User kein lokaler Admin ist.

Ja ok, manchmal vergesse ich wie meine Parameter heißen Wenn da überal N/A steht, klappt der SSL-Handshake nicht. Netzwerktrace sagt Dir, was genau schiefgeht. CA-Kette nicht vertrauenswürdig vermutlich, obwohl ich das eigentlich ignoriere (extra einen Verificaction Callback eingebaut, der immer $True liefert). Oder falsche Namen/SAN im Zertifikat.

Spaß beiseite, für große ADs ist das ein Thema. Weniger VM-DCs mit mehr Cores. Für mich wäre es nice, wenn wir mit 1-2 pro Primärsite auskämen. Geht aber derzeit nicht, zu viel Logontraffic. Ok, geht schon, führt aber zu negativer "User Experience"... Gibts doch mit den FGPP/PSO schon ewig. Unter welchem Baum hast Du die letzten 15 Jahre geschlafen? SCNR...

So einfach ist das jetzt leider nicht. Bei LDAPS kannst Du nicht festlegen, welches Zertifikat verwendet wird... Da mußt dann "remote" schauen, welches im SSL-Handshake präsentiert wird. Soweit ich weiß, wird von allen, die "Server-Auth" haben, das neueste genommen. Test: https://github.com/daabm/PowerShell/blob/master/Scripts/Test-TcpPorts.ps1 Aufrufen mit -Ports 636 -IncludeSSL -SSLPorts 636, dann siehst zumindest mal welche SAN und so im Cert stehen. Wenn Du's genauer weissen willst: -PassThru anhängen und das Ergebnis speichern, dann hast ein Objekt, in dem das Cert drinsteckt inkl. .Save( "Dateiname" ) Methode. Aber jetzt wird's zu esoterisch Das mit "muß der CA-Kette vertrauen" steht oben ja schon. Ich weiß übrigens nicht, ob LDAPS mit SelfSigned überhaupt funktioniert, nie probiert mangels Umgebung ohne CA

Hilft immer, wenn man sich diese dämlichen Auto-Übersetzungen mal auf englisch anschaut... Falsche Syntax Dir fehlt das file: Präfix. Local network file:\\network\shares\sites.xml Und nachdem sie bei dem local File "/" verwenden statt "\", kann auch das noch falsch sein.

Ja, hat er. Sieht man in der Fußleiste des Explorer

Wenn Du noch mal genau drüber nachdenkst, kannst Du es vermutlich selbst beantworten Alle GPOs haben eine Versionsnummer. Ist bei einer davon die Version beim nächsten GPUpdate (Start/Logon/Background) anders, wird alles, was darin an CSEs enthalten ist, erneut verarbeitet (Registry, Security, Ordnerumleitung, Applocker, xyz - gibt glaub 45 Stück). Ist sie überall gleich wie beim letzten GPUpdate, werden nur die CSEs verarbeitet, bei denen "auch ohne Änderungen" aktiv ist. Ausnahme ist Security, das wird alle (weiß nicht mehr genau) x Stunden auch ohne Änderungen zwangsweise angewendet. Und Deine Idee zur Konfiguration ist ok.

Weekend sundowner... 🍹

Wenns komplizierter sein darf, kann hinter Where-Object auch ein Skriptblock kommen

Wenn ich im privaten Umfeld detailliert erzähle, was ich beruflich mache, kommen nach 15 Sekunden Fragezeichen und nach spätestens ner Minute hört keiner mehr zu 🙈😂😂

Dann habt Ihr für Registry "auch ohne Änderungen übernehmen" nicht aktiviert: https://gpsearch.azurewebsites.net/#327 Wenn das nicht aktiviert ist, werden unveränderte GPO-Inhalte nur mit /force erneut verarbeitet.

Papp bei Set-ACL mal "-verbose -passthru" dran, viellieicht siehst Du dann mehr. Edit: Es könnte auch was mit Vererbung zu tun haben, möglicherweise mußt Du aus der ACL erst alles rauswerfen, was geerbt wurde: Get-Acl -Path HKLM:SYSTEM\CurrentControlSet\Services\SharedAccess\Epoch -Verbose | select -expand Access | where { -not $_.IsInherited } So aufgedröselt mußt Du aber die Ziel-ACL ebenfalls auslesen und das eine AccessRight aus der Quell-ACL hinzufügen, bevor Du es schreiben kannst. Die Frage wäre im Skripting-Unterforum besser aufgehoben

So würde ich das auch machen - einfach die FSMO-Rollen "wandern" lassen. DCs migriert man normalerweise nicht, man baut neue, wie man's braucht und demotet dann die alten. Das ist das Schöne, wenn man sich an die goldene Regel hält: Ein DC ist ein DC ist ein DC - und sonst nichts

Gar nichts - es ist ja schon ein PDF, warum sollte man das an einen "virtuellen" PDF-Drucker schicken? Vielleicht beschreibst Du mal etwas umfassender, was Du eigentlich machst und erreichen willst? Ansonsten steht ja oben schon viel dazu. PDF ist leider ziemlich kompliziert geworden...

Ja klar - denk an die Arche Noah, biblisches Unwetter, jede Menge Cloud... 🙈

$error[0].Exception | Select * oder $error[0].InnerException | Select * könnte weiterhelfen. Aber vermutlich ist das das alte Problem - "offene Netzwerkverbindung mit Credential A und Windows verweigert jetzt weitere Verbindung mit Credential B".

Kollege aus der Gegend von Münster hatte heute auch Durchzug schwerer Gewitter - hier hat's 30 Grad... 🥵

Jan hat nicht gesagt, daß Ihr das per Gruppenrichtlinie machen sollt (das ist glaub auch die schlechteste aller Varianten). Er hat gesagt, daß sogar Gruppenrichtlinien.de sagt "mach es einfach nicht. Gib dem User ne Kurzanleitung, wie es geht, und laß es ihn selber machen."

# for hex 0xbc4 / decimal 3012 : ERROR_PRINTER_NOT_FOUND winerror.h # No printers were found. passt für mich irgendwie nicht zur Fehlerbeschreibung, aber vielleicht liefert es Dir Denk-/Rechercheanstöße. BTW - wie verbindet Ihr denn die Drucker?

Wenns am NTLM-Block liegt, steht das doch im Eventlog auf den DCs - schon mal nachgeschaut?

Danke, sieht wieder ansehnlich aus Bergfest - gönnt Euch 🍺

Und ich vermute, daß deine Forwarder-/Secondary Konfig entweder kaputt ist oder Du ein Firewall-Problem hast.

Wenn Du mal rauslassen würdest, was genau Du eintippst...