olc

Hallo, EFS unter Windows 2000 ist tatsächlich aufgrund der genannten Lücke nicht zu empfehlen. Unter Windows Server 2003 / Windows XP wurde diese Lücke gefixt. Es ist nach einer Kennwortänderung durch den Administrator (außerhalb von Domänenumgebungen) nun nicht mehr möglich, auf den Master Key des Benutzers zuzugreifen. Somit ist ist es auch nicht mehr möglich, auf den privaten Schlüssel des Benutzers zuzugreifen, was eine Entschlüsselung der Daten "unmöglich" macht, sind nicht weitere Benutzer oder ein Recovery Agent für diese berechtigt. Viele Grüße olc

Hallo, ich muß ehrlich sagen, daß Deine ganzen Beschreibungen ein wenig "konfus" wirken - ist nicht böse gemeint. Du solltest jedoch nicht unterschiedliche Baustellen miteinander verwechseln: DFS hat rein gar nichts mit dem Logonserver oder auch mit Pings zu tun. Pings wiederum haben nichts mit dem Logonserver zu tun. Du vermengst hier also verschiedene Dinge, die unter Umständen nur in der Wirkung gleich sind, nicht jedoch in der Ursache. 1. Der jeweilige Logonserver wird also nach Deiner Aussage korrekt aus der Client-Site gewählt. Das ist soweit auch erst einmal sehr gut. 2. Nachdem der Cache Timeout bezüglich des DNS-Cachings auf dem Client abgelaufen ist, wird er bei einem Ping auf den Domänennamen das DNS befragen. Da hier bei einem Ping auf den Domänennamen tatsächlich Round Robin stattfindet, ist es verständlich, daß der Client unterschiedliche IP-Adressen von beliebigen DCs erhält. Soweit also auch kein Problem. 3. Greifst Du mit einem Client auf den Domain Namespace der Domäne zu (z.B. SYSVOL / NETLOGON), bekommst Du ein Referral auf einen DC der Domäne zurück. Da auf allen DCs das SYSVOL vorhanden ist, könnte das grundsätzlich erst einmal jeder sein. Da es jedoch die "site awareness" der Server und Clients gibt, sollte das Referral im Normalfall an einen Server der gleichen Site gegeben werden. Hier liegt also ein Problem. Die Frage nach der DFS-Konfiguration sollte also noch einmal geprüft werden. Auch wenn Du die Antwort schon gegeben hast: Ist hier unter Umständen etwas verändert worden (siehe Disabling site awareness for Windows Server 2003 or for Windows 2000 DFS in a Windows NT 4.0 domain )? Was sagt ein dfsutil /sitename:<computer> für einen betroffenen Client und einen nicht gewünschten DC? Sind die "lokalen" DCs im DNS korrekt in der Client-Site registriert (siehe unterhalb von <site_name>._sites.dc._msdcs.domain.tld)? Findest Du dort unterhalb der entsprechenden Site unter Umständen DCs anderer Sites? Ich denke nich, daß es so ist - denn würdest Du auch nicht immer die lokalen Logonserver bekommen. Aber prüfen solltest Du es in jedem Fall. Schau Dir zusätzlich auch einmal folgenden Link an: You may receive DFS referrals that contain a list of random DFS targets, random SYSVOL or NETLOGON referrals, or experience slow performance when you access a shared folder in a DFS namespace on a Windows Server 2003-based computer Interessant ist hierbei (neben dem Hotfix) der Registry Key - standardmäßig ist jedoch die site awareness aktiv. Viele Grüße olc

Hallo, der fachliche Ansatz vom TO ist sicherlich nicht der beste, aber hier geht glaube ich im Moment alles durcheinander... Also vielleicht befassen wir uns einmal mit der Ausgangssituation anstatt ungefähr 12.000 gut gemeinter Ratschläge zu anderen Themen zu geben. ;) Über was für eine Umgebung sprechen wir denn? D.h.: - Handelt es sich um einen Domänenclient bzw. sind die Benutzer Domänenbenutzer? - Wo liegen die Daten - lokal auf einem Client des Benutzers oder zentral im Netzwerk? - Sind die Benutzerprofile lokal oder liegen diese im Netzwerk? - Credential Roaming für die Benutzerzertifikate schließe ich einmal aus oder? Viele Grüße olc

Hallo, ohne Angabe von Betriebssystem / Versionen sind die meisten Fragen recht schwer zu beantworten. Auch scheint es mir, daß der Begriff nicht korrekt ist: Es wird wahrscheinlich "Windows Management Instrumentation" heißen oder? Obwohl mir in diesem Fall nicht klar wäre, wozu ein webbasierendes Tool die WMI benötigt. Sollte es sich um WMI handeln, so ist diese im Normalfall bei allen neueren / aktuellen Windows Versionen die WMI standardmäßig mit dabei und auch aktiv / installiert. Windows Management Instrumentation (WMI): Häufig gestellte Fragen (FAQ) Viele Grüße olc

Hi Apex, wenn Du konkret diese Richtlinie "deaktivierst", dann wird der Standardwert von 500Kbit/s verwendet. Willst Du die Slow Link Detection so konfigurieren, daß nicht geprüft wird, wie schnell die Verbindung ist, mußt Du nicht "deaktiviert" verwenden, sondern den Wert "0" für die Geschwindigkeit angeben. Ist "0" angegeben, werden die Extensions unabhängig von der Geschwindigkeit immer angewendet. Wie oben schon geschrieben ist das jedoch meist nicht zu empfehlen. Das steht jedoch auch alles in den Artikeln, die ich oben verlinkt habe... ;) Viele Grüße olc

Hi Apex, wenn Du die Slow Link Detection abschaltest, werden die Policies unabhängig von der "Geschwindigkeit" angewendet - wobei gesagt werden muß, daß "Geschwindigkeit" bis XP relativ ist, da die Pingzeiten gemessen werden, nicht die Bandbreite. Das Abschalten ist jedoch nur in den wenigsten Fällen zu empfehlen - besser ist es oftmals, den Schwellwert nach unten zu setzen, also beispielsweise 256KBit/s oder 128Kbit/s. Eine weitere Möglichkeit wäre, nur bestimmte GPO Extensions immer anwenden zu lassen, die anderen jedoch weiterhin von der Link Detection prüfen zu lassen. 1. How a slow link is detected for processing user profiles and Group Policy 2. Microsoft Corporation Viele Grüß olc

Hallo, entschuldige - aber irgendwie ist mir das Problem immer noch nicht ganz klar: Du schreibst zwar, daß die DCs und die Clients im gleichen Subnetz sind, relativierst diese Aussage jedoch wenig später wieder. Scheinbar liegen die Clients also doch in einem anderen Subnetz als die DCs? Sind beide Subnetze (Clients und DCs) der selben Site zugewiesen? Weiterhin schreibst Du, daß sich die Clients immer auf verschiedene DCs verbinden - aber sicherlich doch nur auf verschiedene DCs der lokalen Site, nicht in der gesamten Domäne oder? Das ist das korrekte Verhalten. Der Logonserver hat im übrigen nichts damit zu tun - das DFS-Referral kann auf einen anderen DC verweisen als auf den Logonserver. Sollte es also so sein, daß sich die Clients auf verschiedene DCs des gleichen Subnetzes verbinden: Wo liegt das Problem dabei? Das Netlogon Verzeichnis ist doch Teil der FRS Replikation und somit auf allen DCs der Domäne (und damit auch der Site) vorhanden. Viele Grüße olc

Hi Jan, Du müßtest in diesem Fall ja alle beteiligten *.dll / *.sys Dateien etc. kennen. Außerdem werden oftmals die Libaries in den Speicher geladen, ohne daß Du Handles auf die entsprechenden Dateien hast - das ist ja kein "muß". Von daher denke ich, daß das nicht das Mittel der Wahl ist, um die angesprochenen Probleme einzugrenzen. Besser geeignet sind für solche Szenarien Tools wie der Process Explorer oder der ProcMon: Process Explorer Process Monitor Aber das kommt immer auf den Einzelfall an - ein "Patentrezept" gibt es nicht. Viele Grüße olc

Hi Jan, für Treiberprobleme ist das Tool im Regelfall eher nicht geeignet. Oder was für ein Szenario meinst Du genau? Viele Grüße olc

Hallo, na dann schauen wir einmal, ob Dir das Script zusagt. ;) Eine komplette Referenz kenne ich leider nicht - jedoch ist folgendes Dokument ein guter Startpunkt: Windows PowerShell Quick Reference Weiterhin bietet Technet einen eigenen PowerShell Bereich und es gibt massenweise Blogs etc. Die PowerShell CMDlets "Get-Help" und "Get-Command" sind auch recht hilfreich. ;) Viele Grüße olc

Hallo, hast Du Dich denn einmal mit dem oben von mir angesprochenen SNMP-Walker durch die Namespaces geklickt? Werden Dir die Namespaces dann angezeigt? Ich habe leider keine OIDs mehr parat - ist zu lange her. Aber die Nagios-Plugins sollten Dir einige bieten. Es werden standardmäßig nicht unbedingt alle Eigenschaften von Windows zur Abfrage mittels OID mitgeliefert - daher gibt es einige Drittprodukte, die das dann ergänzen. Viele Grüße olc

Hi, schau Dir einmal ImageShack® - Image Hosting an. Viele Grüße olc

Hallo, das Round Robin solltest Du nicht ausschalten. Grundsätzlich nutzt DFS die sogenannte "Site-Awareness" seit Windows 2000, die jedoch in jeder Version des Windows Servers danach erweitert / verbessert wurde. Wenn Ihr also die Standardeinstellungen nutzt, sollten sich die Clients auf einen Server Verbinden, der sich im lokalen Subnetz des Clients befindet. Ist dort kein entsprechendes Ziel vorhanden, wird je nach Betriebssystem ein Ziel ausgewählt, welches am "billigsten" außerhalb der eigenen Site liegt. Dementsprechend folgende Fragen: - Sind die Clients den gleichen Sites zugeordnet wie die DCs derselben Site? - Sind die Subnetze den korrekten Sites zugeordnet? - Sind die DCs im DNS korrekt registriert? - Wurden die standard DFS Einstellungen für die Targets von jemandem bearbeitet? - Um welche Client- und Serverbetriebssysteme handelt es sich genau? Ggf. solltest Du einmal einen Netzwerktrace vom Anmeldevorgang eines Clients ziehen bzw. dem Verbinden zu einem DFS-Namespace, nachdem Du per dfsutil /pktflush den Cache gelöscht hast. Danach zeigt Dir ein dfsutil /pktinfo wohin der Client "geschickt" wurde bzw. mit welchem Server er verbunden ist. Viele Grüße olc

Hi Teddy-x, so, wie ich die Sache im Moment sehe, handelt es sich bei den Dateien um die Systemwiederherstellungspunkte von XP / Vista. Am Anfang fehlt scheinbar nur das "System Volume" für "System Volume Information" (wegen der Leerzeichen im Pfad). Ich denke, daß Du Dir also keine Sorgen machen brauchst - da die Wiederherstellungspunkte im Normalfall tatsächlich sehr groß sind, macht das Abbrechen des Scans für diese Dateien Sinn. Wenn Du ganz sicher gehen willst, löschst Du im entsprechenden Menü (im gestarteten Zustand Deiner XP / Vista Installation) die vorhandenen Systemwiederherstellungspunkte und startest den Scan dann erneut - es sollten dann keine dieser Dateien mehr bemängelt werden. Beachte jedoch dabei, daß es dann ggf. kein "Zurück" zu einem der alten Systemzustände gibt. Viele Grüße olc

Hallo, ich habe das oben aufgeführte Script nach meinem Post einmal getestet: Es läuft leider nicht korrekt. Offensichtlich hat die PowerShell ein Problem damit, daß der Übergabewert für das WMI-Query "-Computer" kein Objekt, sondern ein String ist. Es wird jedenfall nicht korrekt verarbeitet. Aber was solls - ich bin zwar überhaupt kein "Scripting Guy", aber eine Lösung sollte schon her. Daher nach einigen Tests folgender Vorschlag: $category = "(objectcategory=computer)" $AD = [ADSI]"LDAP://DC=testdom,DC=intern" $properties = "name" $search = New-Object System.DirectoryServices.DirectorySearcher($AD,$category) $search.PageSize = 1000 $search.PropertiesToLoad.Add($properties) $result = $search.Findall() foreach ($res in $result) { $computername = $res.properties.name write-host write-host write-host $computername write-host ======================================== Get-WMIObject win32_service -computer $Computername -errorAction SilentlyContinue | Format-Table -auto } Bin für jeden Verbesserungsvorschlag offen. ;) Viele Grüße olc

Hallo, ja, das sollte so funktionieren, wenn Du bei "win32_services" das "s" wegläßt. ;). Außerdem mußt Du die Syntax an die PowerShell anpassen und nicht VBScript nutzen. ;) Probiere einmal (ungetestet): $domComputers = dsquery computer -name test* -o rdn ForEach ($variable in $domComputers) { Get-WMIObject win32_service -computer $variable } Der "saubere" Weg wäre in diesem Fall jedoch, die Objekte direkt per LDAP / ADSI aus der AD zu lesen, da sie dem Array dann nicht als normale Strings, sondern als Objekte zurückgegeben werden würden. Aber Du schriebst, daß Du das später testen möchtest. :) Viele Grüße olc

Hallo, ich habe momentan leide keine CA zum Nachschauen da um die Werte einmal abzugleichen, aber versuche doch bitte einmal folgendes: 1. Gib den "Domain Controllers" -> Enroll/Autoenroll - Allow zusätzlich "Read"-Rechte und den "Enterprise Domain Contrl." -> Enroll/Autoenroll - Allow zusätzlich ebenfalls "Read"-Rechte. Bin mir gerade nicht sicher, ob diese ebenfall benötigt werden, denke jedoch schon. 2. Mit welchem Benutzer bist Du angemeldet, wenn Du eine Security Änderung an der CA vornimmst? Wenn dieser z.B. Mitglied der Domain-Admins oder Enterprise-Admins ist prüfe bitte, welche Rechte er auf der CA selbst hat. Fehlt hier vielleicht ein entsprechendes Management-Recht bzw. besser gesagt wurde dies vielleicht entfernt? Viele Grüße olc

Hallo, Du solltest die Dateien nicht einfach löschen. Wie schon korrekt übersetzt, sind die Archive für das Scannen schlichtweg zu groß. Der Virenscanner loggt dies und übergeht diese Datei beim Scan. Viren o.ä. machen sich diese Eigenschaft ab und an zunutze, indem Sie Archive bewußt so manipulieren, daß Virenscanner sie für zu groß halten oder zu viele Verschachtelungen vermuten. Gib die Dateinamen einmal in der Suchmaschine Deiner Wahl ein - findest Du entsprechende Treffer ist die Chance groß, daß es sich tatsächlich um Problemdateien handelt. Anderfalls solltest Du noch einmal prüfen, ob Du sie nicht selbst zuordnen kannst. Viele Grüße olc

Hallo Tobias, dazu mußt Du einen LDAP-Filter verwenden: dsquery * -filter "&((objectClass=contact)(!memberOf=*))" Dabei ist (die meines Erachtens wirklich ärgerliche Eigenschaft) zu beachten, daß beim DSQUERY-Filter das "&" tatsächlich vor den Klammern stehen muß und nicht wie im Normalfall in der ersten Klammer. Viele Grüße olc

Hi paddy82, ok, ich verstehe was Du machen möchtest. Dafür brauchst Du das "Invoke-Expression" nicht. Du kannst theoretisch die Abfrage einfach an eine Variable übergeben - diese führt die Abfrage dann aus und übergibt die entsprechenden Werte dann der gewünschten Funktion bzw. dem gewünschten CMDlet. Also in der Form: $meine_variable = dsquery computer -name Test* ABER: Leider geht es nicht so, wie Du Dir das vorgestellt hast. ;) Das Problem ist, daß die WMI-Abfrage ein anderes Format erwartet, als Du es über dsquery bekommst. Dort wird nämlich der DN der Computerkonten zurückgegeben. Eine Weiterleitung an DSGET bringt Dich auch nur einen Schritt weiter, da Du bei einer Abfrage nach SAMIDs die Computernamen mit "$" angezeigt bekommst. Das müßte dann noch gefiltert werden. Daher die Frage: Willst Du das Problem an sich lösen oder willst Du PowerShell lernen? :) Je nachdem sieht die Antwort auf die Fragestellung nämlich unter Umständen vollkommen anders aus. ;) Viele Grüße olc

Hallo, von einer Funktion, die sozusagen als "Countdown" die Zeit herunterzählt, bis die Datei automatisch entschlüsselt wird, habe ich im Zusammenhang mit "cipher.exe" noch nie gehört. Würde mich im Grunde auch sehr verwundern, da es meiner Meinung nach ein hohes Sicherheitsrisiko wäre. Aber mal anders herum gefragt: Was ist denn eigentlich das Szenario, über das wir hier sprechen? Was genau willst Du erreichen bzw. was ist die Ausgangssituation? Off-Topic:Bei "James Bond" oder "Mission Impossible" zerstören sich die CDs immer automatisch - vielleicht kann man ja beim MI5 mal nachfragen. :D Viele Grüße olc

Hallo, da nicht wirklich viele Informationen zu Deinem Setup aus dem Post hervorgeht, anbei einmal ein paar Links dazu: Microsoft Corporation Microsoft TechNet: Deploying Smart Cards Smart Card Enrollment Control Usage Scenario (Windows) Microsoft Corporation http://support.microsoft.com/kb/257480/en-US Microsoft Corporation Die hast Du durchgearbeitet und es geht immer noch nicht? ;) Viele Grüße olc

Guten Abend, Ist der angegebene DC "DC02" der neue DC oder ein anderer? Scheinbar ist es dem DC nicht erlaubt, das Domain Controller Zertifikat zu beantragen bzw. wird das Autoenrollment verweigert. Schau doch bitte einmal in den veröffentlichten Templates, welche Benutzer / Computer das Recht haben, das Domain Controller Authentication Template zu benutzen bzw. besser gesagt Zertifikate dieses Templates beantragen zu dürfen. Poste bitte einmal von allen für das Template aufgeführten Sicherheitsprinzipalen die Rechte. "Diverse Templates" ist leider nicht sehr aussagekräftig. ;) Die Frage ist, ob sich in der letzten Zeit an der CA irgendetwas geändert hat bzw. ob etwas geändert wurde. Kannst Du irgendetwas in den Eventlogs nachvollziehen oder in Euren Changelogs? Dazu fällt mir gerade nichts ein - aber auf der CA selbst kannst Du das Management delegieren. Mit was für einem Account bist Du denn an der CA angemeldet, wenn Du die Änderung vornimmst? Viele Grüße olc

Hi Jan, File Handles sind Zugriffe von Applikationen / Diensten / Prozessen etc. auf Dateien, die oftmals die Datei "locken", also für den Zugriff von anderen Applikationen / Diensten / Prozessen sperren. Wenn ein Prozess auf eine Datei zugreift, soll diese während des Zugriffs konsistent bleiben - sonst könnte es beispielsweise bei Änderungen zu Instabilitäten der Applikationen kommen. Das Handle ist ein Zeiger auf die entsprechende Datei irgendwo im Hauptspeicher - ist das Handle exklusiv, kann kein anderer Prozess die Datei bearbeiten. Um beispielsweise zu prüfen, welcher Prozess eine Datei unter Windows gerade sperrt (bzw. besser gesagt ein Handle darauf hat), kannst Du u.a. Handle v3.30 nutzen. Viele Grüße olc

Hallo Janta66, viel gibt es im Grunde zum "PATH" bzw. Umgebungsvariablen auch nicht zu sagen - was interessiert Dich denn konkret? site:microsoft.com environment variable - Google-Suche Gruß olc