daabm

Was ist bei Dir "die MailApp"?

So wie Norbert sehe ich das auch. Windows schert sich nicht um eine Sekunde hin oder her, wenn damit nicht ausgerechnet der Sprung von -300 auf -301 einhergeht... :)

Ned ganz - das gabs schon ab Windows 2000 :) Und seit Server 2003 per GPO für den jeweiligen TS-Computer, wie Dir das "Supported on" unter http://gpsearch.azurewebsites.net/#2499 verrät. Aber ok, gut wenn es jetzt funzt.

Dateisystem - "icacls <Pfad>". Beispiel: LocalLow NT-AUTORITÄT\SYSTEM:(OI)(CI)(F) VORDEFINIERT\Administratoren:(OI)(CI)(F) DOMAIN\martin:(OI)(CI)(F) Verbindliche Beschriftung\Niedrige Verbindlichkeitsstufe:(OI)(CI)(NW)

Gehandhabt wird das bei uns so: Builtin Administratoren werden nicht zur Administration von Share- und NTFS-Berechtigungen verwendet. Dafür gibt's ne eigene Gruppe, und dann ist UAC kein Problem mehr und kann auf höchster Stufe an bleiben.

Du hast da einen grundlegenden Verständnisfehler, was "servergespeichertes Profil" bedeutet :) Für TS-Profilumleitungen verwendet man entweder das Benutzerkonto (dsa.msc, Reiter "Remotedesktopdienste-Profil") - ist da bei Deinen Usern was eingetragen? Oder man aktiviert http://gpsearch.azurewebsites.net/#2499 - ist das bei Dir der Fall? Alternativ wäre auch noch http://gpsearch.azurewebsites.net/#2587 möglich, nur beträfe das dann auch den Admin, der sich direkt an der Konsole anmeldet. Wenn Du beide Fragen verneinst, hast Du keine servergespeicherten Profile.

Natürlich geht das mit Bordmitteln. Aktiviere das Auditing für fehlgeschlagene Anmeldeversuche und prüfe dann das Security Eventlog - Event-ID ist glaub 4625.

Prüf mal den Integrity Level.

So wie ich das sehe, ist das Problem nicht der Grafiktreiber von VMWare, sondern das emulierte VGA-BIOS, das natürlich auch ohne Treiber erkannt wird... Da hilft nur hoffen (auf MS oder auf VMWare) :(

Das hätt ich jetzt auch gesagt... Oder als Modul/Skript ins Profil einbinden.

Was irritierenderweise auch eine gültige IP ist :) Gib mal "http://2915183695"im Browser ein... Die Punktschreibweise ist nur für Menschen erfunden worden, damit die mit Subnets und Hosts noch klarkommen und sich die Adressen merken können. 4 Tripel sind einfacher als 11stellige Zahlen :D

Dualcore mit 4 GB RAM und nur 30 User? Das kann nicht sein... Wir lassen in Domänen mit über 1.000 Benutzern gerade mal 2 DCs mit dieser Ausstattung laufen, und das ist noch überdimensioniert. Dein Problem muß meiner Meinung nach andere Ursachen haben :)

Doch, kann man. Er kann es allerdings rückgängig machen - dafür ist er ja Domänen-Admin. Ein Admin kann sich immer über alle Restriktionen hinwegsetzen. Er muß aber wissen, wie es geht. Und wenn Deine Domain Controller physisch gesichert sind, wird es schwieriger :D

Oder man macht es per for-Schleife oder Powershell rekursiv und faßt jeden Ordner einzeln an. Aber "neu machen" ist besser - das klingt nämlich nach dem krassen Gegensatz von "K.I.S.S." :)

Process Monitor hilft fast immer - Filter auf "Access denied".

So ähnlich wie Norbert sehe ich das auch - das ist ein Problem der Subnetzmasken. Wenn die Zieladresse nicht im eigenen Subnetz liegt, wird der Router (das Default GW) bemüht. "tracerte" und "pathping" verraten Dir das ganz schnell, auch ohne Netzmaskenrechner :)

Ok, danke für den Tip - das mit dem Zurückschreiben hatte ich vergessen :)

Du möchtest "Webanmeldeinformationen" ausblenden oder was genau? Wäre mir nicht bekannt, daß das geht - entweder ganz oder gar nicht :)

Die NLA von RDP authentifiziert Dich nicht erst "auf dem Zielcomputer", sondern schon auf dem TS-Client. Das geht also mit "Anmelden an" nicht. Was Du suchst, sind Sicherheiteinstellungen - Zuweisen von Benutzerrechten: "Lokal anmelden zulassen" und "Lokal anmelden verweigern".

Nein, mußt Du nicht. Du mußt nur "Deine" Policy über die Default Domain Policy schieben. Sonst wird sie nämlich wieder überschrieben - die Verarbeitung erfolgt von unten nach oben.Steht bestimmt irgendwo in den beiden Links, die Sunny schon gepostet hat. Oder in einem der anderen Howtos von Mark. @Zahni: In die DDP und DDCP packe ich zumindest gar nix - ich mach mir eine eigene (ggf. halt als Kopie davon), schiebt die drüber und ändere dann da. Motivation dafür sind die statischen GUIDs der beiden und DCGPOFIX. Aber das ist natürlich keine in Stein gemeißelte Regel, sondern nur ein Erfahrungswert :)

Du läßt "wünsch Dir was" mit Dir spielen. Das funktioniert nicht - zumindest nicht bei Euch, da Ihr offensichtlich keinen Security-Beauftragten und vermutlich auch keine interne Revision habt. In dem Fall heißt es dann nämlich "So isses"... Soll heißen: Entweder Du hast die Cojones und stellst die Fakten klar. Oder halt nicht. Voraussetzung dafür ist natürlich, daß Du einen klaren Plan und eine strukturierte Administrationsweise hast. Also zurück zum Thema - such nach "Pass the hash" in Verbindung mit Cached Credentials. Domain Admins melden sich auf Domain Controllern an, sonst nirgends. Server-Admins melden sich auf Member Servern an, sonst nirgends. Client Admins melden sich auf Clients an, sonst nirgends. Und als Info aus der Praxis: Auf allen unseren Servern gibt es keine lokalen Benutzer (jepp - nirgends). Domain Admins können sich nur auf Servern anmelden, nicht auf Clients ("nur auf DCs" kommt demnächst). Für alle Serverfunktionen gibt es entsprechende Domänengruppen, die auf dieser Serverfunktion lokaler Admin sind. Für Clients ebenso. Nicht-"Server-Admins" können sich an Servern nicht anmelden (Ausnahme natürlich RDS). Auf Servern ist Cached Credentials = 0, auf Clients (wegen Offline-Anmeldung) = 1. Für Dich kann ich nicht sprechen. Ich hab vor 20 Jahren mein Hobby zum Beruf gemacht und es nie bereut. Engagement war dabei nie fehl am Platz und hat sich langfristig immer ausgezahlt. Du solltest darüber vielleicht noch mal nachdenken... Siehe Norbert :( Viele Anteile Deiner Beiträge gehören eigentlich ins OT.

Für mich tut's das hier ganz prima: https://gallery.technet.microsoft.com/scriptcenter/Enhanced-Script-Logging-27615f85

Irrtum. Der soll die Domäne (= das AD) administrieren können. Sonst gar nix. Vor allem hat er auf Membern (Server und Workstations) nix verloren - such mal ein wenig nach "Pass the hash", in Verbindung mit Cached Credentials ist das eine ernst zu nehmende Bedrohung! Irrtum. Was ist, wenn Dir was passiert? Liegt irgendwo in einem Tresor ein Umschlag mit User und Kennwort? Oder gibt es zwei vertrauenswürdige Instanzen, die jeweils die Hälfte davon kennen? Wenn Du beides mit "Nein" beantwortest, sitzt Deine Firma auf einer tickenden Zeitbombe. BTW: Die Formulierung klingt für mich ein wenig nach "Security by obscurity" :) Irrtum. In einem gut verwalteten AD gibt es außer "Guest" und "Administrator" keine lokalen Konten. Und ein SQL-Server nutzt niemals nur die SQL-Authentifizierung (idealerweise nutzt er sie gar nicht). Das ist zwar möglicherweise die Schuld der Dienstleister, aber Ihr habt es ihnen ermöglicht.

Ok, soweit so gut. Dann behebe den Fehler - und nutze SYSVOL und NETLOGON nicht mehr als Softwareverteilpunkt. Dafür ist es nicht gedacht und nicht geeignet. Wird Dir bei Deinem dcpromo-Problem aber auch nicht helfen. So aus dem Bauch: Ein Experte von außen wäre nicht die schlechteste Wahl...

Das einzige, was mir in dem Zusammenhang einfällt, ist diese Sicherheitseinstellung: Geräte: Zugriff auf Diskettenlaufwerke auf lokal angemeldete Benutzer beschränken Aber wenn es mit einem "aktuellen" RDP-CLient geht, würde ich eher die Thin Clients aktualisieren/austauschen.