olc

Hi, "control keymgr.dll". :) Viele Grüße olc

Hi, dann nimmst Du halt das VBScipt des o.g. Links. ;) Die Ausgabe läßt sich entsprechend anpassen, so daß Du auch in VBScript die WMI-Klasse nutzen kannst. Viele Grüße olc

Hi, vielleicht ist die WMI-Klasse "Win32_PingStatus" ein Ansatz: WMI Tasks: Networking (Windows) Die Klasse kannst Du mit diversen Methoden ansprechen, so etwa auch mit der PowerShell, die Dir alle zurückgelieferten Informationen recht übersichtlich anzeigen kann: PS C:\> Get-WmiObject -Query "Select * From Win32_PingStatus where Address = '192.168.1.1'" | Export-CSV C:\TEMP\ping.csv Viele Grüße olc

Hi, wenn Du über die IP-Adresse zugreifst, wird kein Kerberos verwendet. Daher erfolgt eine NTLM-Anmeldung. Versuche es einmal mit dem DNS-Servernamen, dann sollte keine zweite Anmeldung nötig sein - zumindest solange der Benutzer die entsprechenden Berechtigungen hat und sein Kennwort auf dem "Offline" angemeldeten Client noch aktuell ist. Viele Grüße olc

Hi, prüfe einmal, welche NTLM Versionen zugelassen sind - standardmäßig ist bei 2008 keine NTLMv1 Authentifizierung mehr möglich. Das müßtest Du also ändern, wenn es unbedingt NT-Clients sein müssen. Ich hoffe die Risiken sind Deinem Auftraggeber bewußt... :wink2: Ansonsten wäre eine genaue Fehlermeldung und eventuell der Blick in die NT und 2008er Eventlogs sinnvoll. Mit der Aussage "allerdings findet der NT4 Client dann die Domäne bei der Anmeldung nicht." kann man nicht so viel anfangen. ;) Viele Grüße olc

Hi Wolfgang, die Suchmaschine meiner Wahl sagt dazu: Dokuwiki Authentifizierung an LDAP Verzeichnis [AMRILA | WIKI] no sq - LDAP, ActiveDirectory, and DokuWiki Active Directory and Dokuwiki - DokuWiki User Forum Viele Grüße olc

Hi, wenn die Laufwerke auf P: gemappt sind, warum änderst Du das Ziel für P: nicht einfach per Loginscript? NET USE P: /DELETE NET USE P: \\dfs\Abt\Finanz Viele Grüße olc

Hi, was genau ist denn nun eigentlich das Problem? Der fehlschlagende Report, der sicher nur auf fehlende "elevation" der CMD zurückzuführen ist, der Modeling Wizard oder Kontosperrungen? Wenn man Probleme lösen möchte ist es meist sinnvoll, entweder ein Problem nach dem anderen zu behandeln oder aber eine korrekte Abgrenzung vorzunehmen. Vielleicht öffnest Du für Deine verschiedenen Probleme auch einfach verschiedene Threads, das wird dann sicher auch zu mehr Beteiligung führen, da man überhaupt erst einmal versteht, worum es geht. Sich strukturiert einer Fragestellung zu nähern macht meiner Meinung nach in den allermeisten Fällen über 50% der Problemlösung aus. :wink2: Viele Grüße olc

Hi, es ist meist sinnvoll, eigene Threads zu verschiedenen Problemen zu öffnen. Hier in diesem Thread sieht sicherlich kaum einer mehr durch. :wink2: PST-Dateien auf Netzlaufwerken sind von MS nicht supported, soweit ich weiß. Außerdem ist die Profilsynchronisation mit mehr als einem DFSN-Target nicht supported. Dafür gibt es (wie Du oben ja siehst) offensichtlich auch gewichtige Gründe. ;) Sollte das Locking nicht durch die Benutzer selbst erfolgen (ich würde vermuten, daß der Benutzer noch irgendwo angemeldet ist und die Datei sperrt, das sollte sich zum Beispiel per "net files" auf den Share-Servern herausfinden lassen), können auch Virenscanner oder ähnliche Programme Sharing Violations hervorrufen. Zu dem "Datenverlust beim Schreiben": Es sieht tatsächlich nach einem HDD-Fehler aus, wo immer der auch liegt (Controller, Platten etc.). Das würde auch die anfänglichen probleme mit dem WMI-Repository / DB erklären. Ggf. also einmal einen Hardware-Check laufen lassen + Checkdisk. Vorher solltest Du die Daten gesichert haben. Ggf. solltet Ihr noch einmal das DFSR Gesamtkonzept überdenken - scheinbar gibt es da einige Komponenten, die hohes Fehlerpotential bergen. Viele Grüße olc

N'Abend, nett - also darauf wäre ich nicht gekommen. :D Danke für die Rückmeldung und Gruß olc

Hi, im Eventlog steht die Quelle, also die Maschine, auf dem die Sperrung ausgelöst wurde. Damit hast Du den ersten Ansatz. Wenn es die Proxy-Maschine ist, dann schalte dort das entsprechende Logging ein. Es sollte zu prüfen sein, wann falsche Benutzerdaten eingegeben wurden. Viele Grüße olc

Hi, die GPP-Einstellungen mußt Du auf einem Vista / 2008 oder W7 / 2008 R2 System verwalten - von einem 2003er Server mit GPMC aus kannst Du diese nicht verwalten, nur anwenden. Bezüglich der Verzögerung: Ich glaube Dir gern, daß es Verzögerungen gibt - jedoch liegen diese mit hoher Wahrscheinlichkeit eben nicht an fehlenden Logon-Scripts. ;) Oder hast Du die Script einmal aus den entsprechenden Gruppenrichtlinien entfernt, dann ein GPUPDATE auf dem Client durchgeführt, den Client danach "offline" genommen und festgestellt, daß es danach schneller geht? Wenn Du genau wissen möchtest, was da so lange dauert, dann aktiviere das UserEnv Debug Logging und prüfe darin, was so vor sich geht, wenn es zu den Verzögerungen kommt. Außerdem könntest Du noch einen Netzwerktrace auswerten. Ask the Directory Services Team : Understanding How to Read a Userenv Log ? Part 1 Viele Grüße olc

Hi Andi, schau einmal in die Datei "PreExistingManifest.xml" hinein - dort wirst Du sehen, daß die Pfade der Dateien "komplett" sind, d.h. nicht relativ. Somit kannst Du nicht einfach die Dateien nach "C:\Temp\DFSRRestore\PreExisting\" kopieren und das Script von dort aus ausführen - es wird dann schlichtweg keine Referenz gefunden, weil der Pfad falsch ist. Entweder Du führst das Script aus dem Originalpfad aus (Quelle) und gibst nur ein neues Ziel an, damit Du nicht vorhandene Dateien überschreibst, oder Du nutzt "Copy and Replace", um in der XML-Datei die Dateipfade auf "C:\Temp\DFSRRestore\PreExisting\" zu ändern. Viele Grüße olc

Hi Moped, reden wir hier von Windows 2000 Servern? Falls ja, dann schau einmal hier hinein: Files are not synchronized when you use the File Replication service to replicate Distributed File System shares in Windows 2000 Server Viele Grüße olc

Hi, ich denke nicht, daß es da einen Unterschied zwischen XP / Vista und Windows 7 gibt. Ist die CRL nicht erreichbar, dann scheitert die Validierung auf allen Systemen. Es gibt durchaus Möglichkeiten, das ganze zu deaktivieren. Dann ist auch weiterhin ein Zugriff möglich, nachdem die CRL abgelaufen ist und keine neue CRL verfügbar ist. Aber ich führe die entsprechenden Schlüssel einmal bewußt nicht auf, denn damit kannst Du im Grunde auch gleich die CA-Implementierung bleiben lassen, denn Sicherheit bietet die PKI dann im Grunde keine mehr. Alternativ könntest Du die jeweils aktuelle CRL direkt auf den betroffenen Clients importieren. Dann sollte es auch wieder mit den derzeit betroffenen Clients klappen - zumindest bis zur nächsten CRL-Ausstellung / Datum. Viele Grüße olc

Hi Thomas, Du kannst das Zertifikat nach dem gleichen Prinzip wie in dem Thread angegeben verteilen, es wird kein Root-Zertifikat benötigt: Computereinstellungen\Windows Eisntellungen\Sicherheitseinstellungen\Richtlinien öffentlicher Schlüssel\Vertrauenswürdige Stammzertifizierungsstellen Ggf. würde es sogar ausreichen, das Zertifikat in die "Trusted Publisher" zu importieren - aber das solltest Du einfach einmal testen. Viele Grüße olc

Hi Andi, Im Normalfall treten keine Probleme zwischen x86 und x64 Maschinen auf. Du kannst diese problemlos "mischen". D.h. danach werden keine Daten mehr repliziert, d.h. das System geht nicht mehr in den "Normalzustand" über? Was sagen die Health Reports? Ich würde auf den Systemen das NIC-Teaming deaktivieren (falls aktiv) und die Netzwerkkartentreiber aktualisieren. Zusätzlich macht es Sinn, testweise die AV-Applikationen und Firewalls auf den Systemen zu deinstallieren, sofern vorhanden. Das neuste Windows Server 2008 DFSR Hotfix Level schadet natürlich auch nie. ;) Danach schaust Du, ob der Fehler weiterhin auftritt. Im Normalfall schon, ein Dienststart zieht keinen "Datenverlust" nach sich. Jedoch können natürlich immer irgendwelche unerwarteten Probleme auftreten, weshalb wie immer ein Backup von allen Systemen vorliegen sollte. Aber wie gesagt: Im Normalfall ist ein Dienstneustart unkritisch. Viele Grüße olc

Hi, ABE wird hier nicht weiterhelfen. Ich denke auch nicht, daß es eine solche Lösung "builtin" gibt (außer Backups / Schattenkopien vielleicht :D). Aber mal anders gefragt: Was genau soll damit erreicht werden bzw. was ist der Hintergrund für das Anliegen? Viele Grüße olc

Hi, Es findet kein Caching statt. Wenn die Domäne nicht verfügbar ist, sollte es auch zu keinen Verzögerungen beim "Abruf" der (nicht verfügbaren) Scripts kommen. Das Core Processing bzw. die CSEs sind da schlau genug. Auf den Clients (ab XP / 2003 aufwärts) müssen die GPP Client Side Extensions (CSEs) installiert sein. Dann können die auch mit den Einstellungen umgehen. Das würde ich persönlich am leichtesten mit dem WSUS erledigen (Updates + XML Lite): Gruppenrichtlinien - Übersicht, FAQ und Tutorials Viele Grüße olc

Hi, ab Vista gibt es 32-Bit und x64, unter Windows XP nur 32-Bit. Viele Grüße olc

Hi, setze die Kennwörter der Benutzer doch einfach zurück. Du solltest auf dem DC ja Domänen-Admin Rechte haben. :) Viele Grüße olc

Hi, oft ist bei einem Upgrade auf 2008 NTLMv2 oder SMB Signing ein Problem. Ggf. müßtest Du hier also prüfen, ob das aktiviert ist (also nur NTLMv2 Antworten gesendet werden und / oder SMB Signing aktiviert ist) und schauen, ob der SuSE Client damit umgehen kann. Bei einigen älteren SAMBA Versionen gab es da Probleme. Ansonsten sollte die Authentifizierung durchaus funktionieren. Erst ab 2008 R2 ändert sich da noch etwas in Bezug auf die Verschlüsselung, aber soweit ich weiß ist das bei 2008 noch kein Thema. Viele Grüße olc

Hi, Du kannst das Zertifikat in den Trusted Root Auth. Store oder Intermediate CA Store des TS importieren. Sollte es sich um mehrere TS handeln, kannst Du das auch bequem per Gruppenrichtlinie erledigen. Viele Grüße olc

Hi Andi, schwer zu sagen, woran der Fehler oben lag. Hauptsache es läuft jetzt und Du kannst die gewünschten Daten problemlos per Script wiederherstellen. :) Viele Grüße olc

Hi, wenn keine weiteren Meldungen im Eventlog stehen, dann wird es schwierig. Vielleicht ein Filtertreiber (AV, Firewall etc.) oder eine beliebige andere Applikation, die auf die Crypto Funktionen zugreift. Installiere doch schrittweise einmal die Applikationen und prüfe das Autoenrollment - irgendwann muß es ja stoppen. Viele Grüße olc