daabm

Hm - eigentlich gibt es selten so ausführliche Fehlermeldungen. Ist doch schön, wenn da komplett im Klartext steht, was das Problem ist

"Für die nächsten Patchdays" ist gut... Symantec hat heute vormittag Pattern-Updates für bekannte Exploits ausgeliefert, der Workaround geht morgen bei uns in die Fläche (heute pilotiert...).

Geraten: Die Sandbox läuft mit nem technischen Account, und Du hast die Benutzerrechte modifiziert (seServiceLogonRight oder seDenyServiceLogonRight). Der Rest sollte dann in den diversen Eventlogs zu finden sein, zuvorderst Security.

Such mal nach "ncsi.txt" - das ist so ein Dummy-File, das zur Erkennung von "Internet" heruntergeladen wird. Ich müßte selber auch wieder danach suchen... Und für O365 fällt mir EnableActiveProbing = 0 ein, aber auch da mußt dann noch dazu recherchieren. Ist halt beides "aus der Erinnerung", konkret liegt's im Büro rum.

Olaf, es gibt viel zu viel Code, der viel zu oft läuft und viel zu viele Daten abruft. AD dürfte eines der häufigsten Opfer sein, SQL kommt vermutlich kurz danach oder davor... "Egal" gibt es bei gutem Coding nicht. Get it right in the first place... Warum ich da so hinterher bin? Weil ich schon zu viele unheimliche Begegnungen der dritten Art mit den Auswirkungen von schlechtem Skripting hatte. Und das hatte mit dem Sizing der Infrastruktur nichts zu tun, nur mit der Qualität und Logik der Skripts.

Jo, Exchange ist bei mir halt "out of Scope" - ich wußte nicht mal, daß "mail" ein eigenes Attribut ist, ich dachte bisher immer, daß in "mail" das steht, was in proxyAddresses groß geschrieben ist (was ich schon immer eigenartig fand für die Festlegung der primären Mailadresse...)

Benutzerkontensteuerung: Bei Eingabeaufforderung für erhöhte Rechte zum sicheren Desktop wechseln Benutzerkontensteuerung: UIAccess-Anwendungen das Anfordern erhöhter Rechte ohne Verwendung des sicheren Desktop erlauben. Entweder ersteres deaktivieren oder zweiteres aktivieren, dann klappts mit dem Nachbarn

Die schlechteste aller Skripting-Code Varianten - sorry... Filtern immer so weit links wie möglich, und Get-ADUser hat nen -LDAPFilter, dann filtert schon der DC und liefert nicht sinnloserweise alle User zurück... get-aduser -ldapfilter "(!(proxyAddress=*))" (LDAP-Attribut müßte proxyAddress sein, da kann ich mich täuschen.) Und dann noch - bei allen AD-Cmdlets - immer ein "| Select *" dahinter - warum, dazu muß ich noch nen Blogpost schreiben. Performance ist das Stichwort... (Faktor 100 etwa bei nachfolgenden Foreach-Durchläufen!) PS: Der -Filter Parameter von Get-ADUser filtert auf Client-Seite, da ist das Elend schon passiert. -LDAPFilter filtert auf der Server-Seite.

Ich werf meine 2 Cent denen von Nils noch dazu: Auch ich kenne kein Szenario, in dem ein RODC wirklich sinnvoll wäre. Auch wenn das (wurde ja schon geschrieben) zum eigentlichen Thema nichts beiträgt Aber vielleicht hilft's bei der Überdenkung der Strategie.

Ja hast Du. Und wie soll der Benutzer jetzt zu "seinem" Ordner finden, wenn er die Ordner darüber nicht sehen kann? ABE blockt ihn dann auf der Ebene, tiefer kommt er nicht...

Kann denn jeder User auch den Stammordner und die darin enthaltenen Ordner sehen?

Kein Thema - "Brett vor dem Kopf" kenn ich gut

Und wo ist jetzt die Frage? Das Ding nennt sich ADAC, der Weg steht oben. "Verwalten" heißt das erste auf deutsch...

In ADUC: Rechtsklick auf den obersten Node "Change Domain". Im Server Manager wüßte ich nicht, wo man da AD verwaltet. Im AD AC: Manage - Add Navigation Nodes - Connect to other domains. Ansonsten wäre ein Screenshot jetzt glaub echt hilfreich.

Die Irritation kommt daher, daß der Dateiname kein "31" enthält. Und bei mir matcht das auch nicht: PS C:\WINDOWS\system32> "TEST.BARN.G9T3F.02981185.B200225.T014508.X02.CSV" -match "31" False Da fehlt irgendeine Info für uns.

Invoke-Expression kann das lösen, hast ja selber schon gefunden. Da mußt Du halt passend mit Anführungszeichen arbeiten, dann geht das. Dazu mußt den CSV-Wert dann erst mal auf $ prüfen, wenn nein direkt verarbeiten, wenn ja mit Invoke-Expression den Variableninhalt reinschummeln. Und wenn Du in EINEM Feld gleich mehrere Variablen verwursteln willst, dann mußt Du das vorher in eine Standalone-Variable stecken und dann erst Invoke-Expression mit dieser Standalone-Variablen aufrufen. "Schön" ist aber anders. Ich kann nicht wirklich nachvollziehen, warum ein Input-Datensatz Variablen enthält, die unabhängig vom Input vorher per Skript definiert wurden...

Was Nils meinte: In welcher Verwaltungsoberfläche treibst Du Dich rum? dsa.msc oder ADUC oder xyz?

Definiere erst mal die ursprüngliche Anforderung. Was du oben schreibst, klingt etwas unplausibel... Man "könnte" mit "Deny acces to this computer from the network" arbeiten, aber das kann leicht nach hinten losgehen.

Îch lese bisher nur, daß der Anmeldedienst abstürzt - wenn damit Netlogon gemeint ist: Der ist für die Anmeldung auf einem Member Server mit einem Domain Account irrelevant, das funktioniert auch ohne. Wie sieht es denn "insgesamt" so in den Eventlogs aus?

"View Log" ist ein klickbarer Link - hast da mal reingeschaut? Im GPO-Eventlog steht recht detailiert, was genau wann genau passiert ist... Und da siehst dann auch sehr gut, wo die Zeiten verbraten werden.

...oder Credential-Objekte bauen für jeden benötigten Share und mit New-PSDrive arbeiten. Viele Wege führen nach Redmond

"Not enforced" ist genauso Standard wie "gpupdate" ohne /force... Edit: Da werden gerne auch mal alle GPOs erzwungen, und dann wundert man sich über die umgedrehte Vererbungsreihenfolge...

GPOs unwirksam zu machen ist das eine. Die zugehörigen Reg-Keys zu überprüfen ist das andere - wenn die nicht per GPO gesetzt wurden, verschwinden sie durch das Entfernen der GPO auch nicht wieder... Da ist Forensik angesagt, und da kann ich per Forum nicht wirklich helfen. Dein Event hat damit eher nichts zu tun.

Der Explorer verhält sich da nicht hanebüchen, sondern "as designed". Kann man umgehen mit der Elevated-unelevated-factory (dann läuft er fröhlich durchaus als Admin), aber das ist dann eine Support-Grauzone. Oder man verwendet generell nicht die Builtin-Admins, sondern erstellt passende Delegationsgruppen mit entsprechenden Rechten - dann ist UAC auch raus. UAC ist eh kein Security Feature, sondern nur "Convenience" (behauptet MSFT)...

Ich würde das nie per Batch machen - zu unflexibel Wir haben mal ein Skriptframework gebaut, das über firmeneigene AD-Attribute und Kontaktobjekte im AD IP- und Netzwerkdrucker konfiguriert (in jede erdenkliche Richtung - inkl. benutzerdefinierter Templates für Standarddruckeinstellungen bei IP-Direktdruck). Mit WMI geht das alles recht problemlos. Nur ist das Verarbeiten der WMI-Ausgaben in Batch eher "Krampf", das geht besser in VBS und noch besser in Powershell. Und wenn Du nicht so viel selbst skripten willst, lohnt sich vielleicht mal ein Blick in C:\WINDOWS\System32\Printing_Admin_Scripts - kann man auch kopieren und adaptieren.