daabm

Naja, das ist immer eine probate Methode, ein System zu zerstören...

...kleiner Nachsatz: Wenn Du Dir dafür ein C#-Programm schreiben kannst - warum machst Du das ganze dann nicht gleich "anständig"? SCNR :cool:

...hilft auf jeden Fall gegen Serverklau und Forensics "von außen". ich kann Deine Ablehnung dagegen grad nicht ganz nachvollziehen...

...oder in eine Datenbank. Ich wollte es dem TO einfach machen - setx /k hat er in seinem Batch schnell implementiert :cool:

Wenn Ihr nicht aktiv etwas einsetzt, das Zertifikate "produktiv" verwendet (z.B. IIS oder WSUS oder eine externe Anwendung, die zwingend LDAPS braucht), dann ist das alles recht streßfrei - Windows "intern" braucht keine CA-ausgestellten Zertifikate. Für gar nix - die für RDP (und HyperV etc.) sind dann halt selbstsignierte.

Entweder deinstallierst Du den KB wieder (was ich empfehlen würde, wenn Du Dir des Risikos bewußt bist), oder Du mußt auf Eigenbau/Drittanbieter ausweichen. Die "Lücke", die MS damit geschlossen haben will, ist eigentlich keine (oder nur eine sehr kleine), wenn die ACLs der relevanten GPOs passend gesetzt werden (Auth. Benutzer raus, Domain Computer rein - oder so, je nach Bedarf).

Nicht jeder hat jeden Server in einem abgesicherten Bereich stehen... Auch wenn er sollte :cool:

Wofür ein Forum da ist, beurteilt jeder anderster :D Für mich ist es eine Anlaufstelle für konkrete Fragen/Probleme. Dein Anliegen ist aber derart genereller Natur, daß Google/Bing Dir erst mal sicher besser helfen - und vor allem preiswerter (wir schreiben hier in unserer Freizeit und unentgeltlich...). Nix für ungut... :cool:

Ich rate mal ein wenig - aber qualifiziert :cool: Ab Vista laufen Tasks als Child von taskeng.exe. Die wiederum läuft als SYSTEM. Ein setx für Änderungen im Benutzerkontext wird also dort niemals ankommen. Und da taskeng.exe nicht neu gestartet wird, behält es seine Umgebung, die es an neue Childs weitervererbt. Das müßtest Du in der Registrierung sogar sehen, wenn Du setx /m verwendest: Unter HKLM\System\CCS\Control\Session Manager\Environment sollte der aktualisierte Wert für Deine Variable stehen... Und dank Session Isolation fällt mir für Deine Methode auch kein praktikabler Weg ein. Ich würde auf Registrierungswerte ausweichen... Die kannst Du mit reg add setzen/ändern und mit SETX in (temporäre) Umgebungsvariablen schreiben. BTW: Dass setx im Explorer Variablen aktualisieren kann, hat in dem Zusammenhang keine Bedeutung - der Explorer kriegt da ein Refresh-Signal. Aber taskeng.exe hat das eher nicht :cool: Schlußwort: Das ist zwar alles geraten, aber so oder so ähnlich ist es auf jeden Fall :D

Aha, 4 Monate später geht es weiter Xperf Boot Trace hast Du gemacht? Und Eventlogs kontrolliert? Hier insbesondere das Gruppenrichtlinien-Log - da steht recht viel zu Zeiten drin...

Wenn ich das so lese... Hm. Lass es...

Schon klar - wollte nur darauf hinweisen, dass RTF oder TXT nix bringen wird :D

Ein DOCX würde ich nach ZIP umbenennen, dann kommst Du zumindest per Explorer problemlos an den RAW-Inhalt ran :cool:

...aber bring den Usern mal bei, dass sie auf ihre Dateien mit \\?\... zugreifen müssen :D

DAS stimmt natürlich :D Ok, bei UNS geht UNC-Pfad immer :cool:

So wie left sagt, isses - die Spalte enthält die MAC-Adresse. Suchen geht leider nicht, aber über das Kontextmenü kannst Du die Liste ggf. auch ganz einfach exportieren - analog netsh dhcp.

Das Problem mit den 256 Zeichen liegt weder in Excel noch in Windows Explorer, sondern im Win32-API. Längere Pfade gehen nur bei direktem Dateisystemzugriff, wie es z.B. der TotalCommander macht, aber auch Robocopy.

Karl, Du sollst nicht ins Eventlog schauen, Du sollst prüfen, ob Deine GPO überhaupt angewendet wird! @Sunny: Das mit dem Netlogon stimmt so nicht - UNC-Pfad geht immer...

So isses: http://gpsearch.azurewebsites.net/#2567

Zum Thema Ping fehlt mir noch eine Aussage: Ping auf IP oder Ping auf Netbios-Name oder Ping auf FQDN? Ping auf Netbios-Name ist schwierig, da die DNS-Suffixe von Client und Server unterschiedlich sind... Und wie sieht's mit Firewalls aus?

Skript per GPO? Warum startest Du da nicht die 123.exe direkt als Logonskript und versiehst statt Deiner "obskuren" ( :cool: ) Abfrage dann die GPO mit einem WMI-Filter ala select * from Win32_OperatingSystem where BuildLevel=2600 ? Und Du hast auf dem betroffenen Client hoffentlich einen RSoP erstellt und geprüft, daß Deine GPO für den aktuellen User auf diesem Client überhaupt angewendet wurde? @Sunny: Im Eventlog findet sich in dem Fall tatsächlich "nichts", wenn er nicht den Pfad falsch angegeben hat. Und UNC-Pfad braucht er eigentlich auch nicht, wenn http://gpsearch.azurewebsites.net/#7978nicht aktiviert wurde (was ich allerdings immer empfehle :thumb1: ).

Hätte Hannelore ein 14stelliges Kennwort verwenden müssen, dann wäre es "Hildegard2Grundgeiger" geworden, oder? Dagegen hilft nix :cool: Ist lang genug, ist komplex (Hildegard2 übrigens auch - Du erinnerst Dich? 3 von 4 - groß/klein/zahl/sonderzeichen - was soll daran komplex sein?) - Kennwörter sind irgendwie halt für'n A***** :D

Der Key ändert sich nicht. Und es geht sogar noch einfacher: http://gpsearch.azurewebsites.net/#2141(Suche einfach nach "Netzschalter"). Hier findest Du die Registrierungswerte, die eine GPO setzen würde. Die kannst Du auch per Skript (im System- oder Adminkontext) setzen. Hätte den Vorteil, daß der heiß geliebte User es nicht mehr ändern kann...

Dann stimmt bei Dir irgendwas mit der Rechtevererbung nicht (mehr)...

Crosspost in Technet - darauf solltest Du hinweisen... Und nachdem im Technet die Info fehlt, daß Du den Desktop umgeleitet hast: Netzwerktrace schon gemacht?