daabm

vor 9 Stunden schrieb Squire:

ich wüsste jetzt nicht, dass es auf einem Terminal Server einen Papierkorb pro Benutzer gibt.

Der Papierkorb ist ja im Dateisystem ein einzelnes Verzeichnis

...hat aber "eigentlich" pro SID ein Unterverzeichnis. Und damit sind meine Kenntnisse zum Papierkorb auch schon erschöpft - ich bin auf der Commandline unterwegs, da gibt es eh keinen

Relevante Daten des Benutzers kopieren ist i.d.R. die beste Lösung. Wenn man da ein halbwegs klares Prinzip hat, was und wo gespeichert wird, ist die Sicherung dieser "relevanten" Daten eine Sache von Minuten. Und dann platt und neu machen. Das ist fast immer (>99%) die für alle günstigste und beste Lösung. Ok, ich hab mich jetzt ein paar Mal wiederholt

Hinter den Profilordnern steckt die SID des Users. Wenn zur aktuellen SID schon ein Ordner existiert, der zu einer anderen SID gehört, wird die Domain angehängt. Alternativ und/oder zusäzlich laufende Nummern.

Schau auf den Clients mal in HKLM\Software\Microsoft\Windows NT\CurrentVersion\ProfileList...

Ich bin kein Netzer - aber ich habe bittere Erfahrungen mit erratischem Verhalten der Netzwerk-Infrastruktur inkl. VPN, Routing und Firewalls. "Immer identisch" wäre wünschenswert, entspricht aber nicht dieser Erfahrung...

Das Konstrukt ist mindestens fragwürdig - und ohne "ping-success" erübrigt sich jede weitere Analyse. Da wirst Du per Forum auch kaum Unterstützung kriegen - das ist so low-level, daß das remote nicht zu unterstützen ist. IP-Netzmaske, IP-Adresse, Firewalls.

@MurdocX Bidi oder nicht ist egal, da geht's nur drum, wo User und Service (=Zielserver) zuhause sind (und nein, es gibt keine Ausnahmen - es geht bei den Trust Directions ausschließlich darum, wer wofür ein TGS haben will). Und wenn die Netzwerk-Firewalls (wie fast alle) die Pakete einfach droppen, dauert es natürlich einige Zeit bis zum Timeout und NTLM-Fallback. Das Paket wird ja verschickt, aber es kommt halt KEINE Antwort ala "no route" oder "destination unreachable", sondern einfach "nichts".

Soweit ich weiß - aber ohne Garantie - müßte 88 reichen. 464 ist Passwort Änderung, das wird da eher selten vorkommen. Und 389/3268 sollte nicht benötigt werden. Aber das unterschreibe ich niemals

Du kannst mal testhalber HKLM\Software\Policies und HKLM\Software\Microsoft\Windows\CurrentVersion\Policies einfach komplett löschen, dann gpupdate /force. Mit Glück hat sich da nur was verhakt. Mit Pech fährt MSFT grad GPOs an die Wand... Rein "technisch" hast Du alles richtig gemacht.

Mit mir hat noch nie einer was geteilt, das mach immer nur ich

Nein, ist nicht so und war auch nie so. DCs sind keine "Kerberos-Proxies", sondern sagen Dir nur, wo Du hingehen sollst ("Referral").

Immer lesenswert dazu: http://technet.microsoft.com/en-us/library/bb742433.aspx

Würde mich interessieren, wo im Netz Du das gefunden hast

Kerberos über Firewalls ist etwas "zickig", wenn da restriktiv geblockt wird. In Deinem Fall müssen wohl die RDS-Server von A die DCs aus B erreichen, weil der User ja aus B kommt. Grundsätzlich muß jeder Computer mit interaktivem Logon alle DCs erreichen, die
a) zu seiner eigenen Domain gehören
b) zu jeder Domain gehören, aus der ein trusted User kommen könnte

wenn Du keine Non-Windows-Geräte damit verwalten willst, würde ich das Stand heute noch nicht machen. Da kommt zu oft ein Stopschild, wenn man OS-nahe Komponenten verwalten will, und zwingend ist meist ganz vorne auch eine OS-Weiche

URL ist alles von http bis zum letzten Zeichen. Host ist der Teil zwischen :// und dem nächsten / (vereinfacht - ein Port wird natürlich ggf. herausgefiltert, genauso die obskure EInbettung von User:Password@Host).

Heute war alles ruhig, Workaround geht fröhlich in den Breiteneinsatz - und der restliche Patchday ist am Montag auch fertig verteilt. Läuft bei uns (Also nicht alles läuft, aber das läuft wirklich gut und schnell...)

Gerade eben schrieb Nobbyaushb:

Layer-8 Problem?

AKA PEBKAC SCNR...

Der TO hat schon recht - Server gehören in das eine VLAN, Clients und Drucker in ein anderes. Wenn man genug Luft hat, auch Drucker und Clients getrennt... Stichwort "Tier Trennung"...

@Nobbyaushb Lokaler Admin ist komplett überbewertet Und in der Tat spricht das geschilderte Szenario nicht wirlich für eine "nicht gewerbliche Nutzung".

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

vor 11 Stunden schrieb BOfH_666:

Ich würd' eher eine CSV-Datei empfehlen. Die eignet sich besser für strukturierte Daten:

Get-ADUser -Filter "enabled -eq '$true'" -Properties Mail -SearchBase 'OU=Verwaltung,OU=Anwender,DC=contoso,DC=com' | 
    Where-Object {$null -eq $_.Mail}  | 
        Select-Object -Property *Name*,Mail |
            Export-Csv -Path 'Pfad zur CSV-Datei.csv' -NoTypeInformation

Wenn Du unbedingt eine Text-Datei haben möchtest, pickst Du Dir einfach mit dem Select-Object den Namen raus, den Du exportieren möchtest und nimmst Out-File anstatt Export-CSV. (Ich habe hier das Attribut "Mail" nochmal mit in die Ausgabe eingeschlossen, um eine "visuelle Bestätigung des Fehlens" zu erhalten)

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.