olc

Hi Nizo, zuallererst einmal hast Du eine etwas falsche Erwartungshaltung: Wie viele andere hier auch, liefere ich keinen Support per PN oder auf anderen Wegen. Ein Forum lebt von den öffentlichen Beiträgen und ist nicht für die persönlichen Belange eines Einzelnen da. Wie die anderen hier im Forum bin ich auch in meiner Freizeit hier, d.h. meine Reaktionszeit usw. läßt sich nicht durch mehrere PNs, Freundschaftsanfragen usw. erhöhen. Wenn ich keine Lust oder Zeit zum Antworten habe, dann mache ich es nicht. Wenn Du eine Antwort auf Deine PNs erwartest, dann darfst Du keine Blockade für PNs einschalten - das ist bei Dir nämlich der Fall. Ich hätte Dir schlichtweg nicht einmal absagen können. Ich empfehle Dir dringend einen Dienstleister einzuschalten. Bevor Eurer System in nächster Zeit vollkommen steht ist das gut investiertes Geld. Zum Thema: Gibt es tatsächlich einen Container mit dem Namen "cn=groups,dc=KU,dc=local" in Deinem AD? Oder ist es eher: - "cn=users,dc=KU,dc=local" - "cn=builtin,dc=KU,dc=local" - oder "OU=groups,dc=KU,dc=local" Unter Umständen ist das schon Dein Problem. Obwohl mich dann wundern würde, wieso es unter Windows Server 2003 oder Deiner Testumgebung funktioniert hat und erst nach der Installation von Updates nicht mehr geht. Wie gesagt - ich meine es nicht böse, aber mit dem vorhandenen (oder nicht vorhandenen) Kenntnissen im AD Bereich wird es über ein FOrum kaum möglich sein, Dein Problem zu lösen. Denk noch einmal über einen Softwarewechsel nach, der Anbieter der Lösung sollte in der Lage sein zu helfen. Wenn er das nicht kann, würde ich ihn wechseln. Zusätzlich solltest Du wie angesprochen einen Dienstleister hinzuziehen. Viele Grüße olc

Hi nizo, nein, Du verstehst nicht was ich sage. ;) Du *benötigst* einen Account für den Zugriff, sonst wird der LDAP bind anonym ausgeführt und es kann nicht klappen. Also prüfe noch einmal, was genau in Kerio eingestellt ist, hast Du dazu eine Dokumentation? Außerdem hast Du oben geschrieben, daß der LDAP/S Zugriff der LDP.exe auch nicht funktioniert. Das war der Ausgangspunkt des Threads. Aus Deiner Antwort entnehme ich nun, daß Du es derzeit mit LDAP und nicht mit LDAP/S versuchst? Welche Updates hast Du denn bei Kerio und beim Windows Server installiert? Falls es zeitlich problematisch ist, ziehe einen Dienstleister hinzu. Hier im Forum ist es schwer bei solchen spezifischen Fragestellungen zu helfen, wenn die Ausgangslage nicht ganz sauber beschrieben wird. Viele Grüße olc

Hi, was ich meine ist: Um Dich am AD zu authentifizieren (um zu browsen), mußt Du einen Account für den sogenannten LDAP bind nutzen. Dieser Account stellt die Verbindung zum AD her und authentifiziert Kerio. Ohne den Account kann Kerio sich nicht authentifizieren und er im Trace angesprochene LDAP bind schlägt fehl. Hast Du diesen Account in Kerio hinterlegt? Wenn ja, kannst Du diesen Account für ein LDAP bind mittels LDP.exe nutzen? Oder geht es, wenn Du in Kerio testweise anstatt LDAP/S nur LDAP ohne SSL nutzt? Ok, Deine Firma möchte nicht wechseln. Aber dann gibt es auch keine Garantie, daß es schnell wieder läuft. ;) Habt Ihr ggf. einen Dienstleister, den Ihr Vor-Ort involvieren könnt? Oder übernimmst Du diesen Teil komplett? Viele Grüße olc

Hi, und derselbe Call funktioniert mit LDAP anstatt LDAP/S? Kann es sein, daß Du derzeit keinen AD Account für den LDAP-bind verwendest? Was für ein Dienstkonto stellt denn die Verbindung zum LDAP Server her? Ist da irgend etwas auf dem Kerio Server definiert? P.S.: Wenn Dir der Hersteller Deiner Lösung im Support Fall keine Auskunft darüber gibt,l was hier ggf. nicht funktioniert, dann würde ich schnellstmöglich den Anbieter wechseln. Viele Grüße olc

Hi, ich muß noch einmal fragen: Warum übergibst Du die IP-Adresse anstatt des DNS-Namens? Wenn ich die Fehlermeldung sehe, dann sieht es danach aus: [11/Jan/2011 12:18:35] LDAPS: Schema extensions have not found on LDAP server 192.168.0.xx2: Operations error Oder hast Du den DNS-Namen angegeben und dennoch wird die IP-Adresse im Log von Kerio angezeigt? Was hat der Netzwerktrace ergeben, den die Kerio Supporter angeschaut haben? Viele Grüße olc

Hi, nur, um auch einmal eine Lanze *für* die Fotos im AD zu brechen: In meinem Unternehmen wird dieses Feature schon recht lange genutzt - und ich möchte es nicht mehr missen. Es gibt wenige Outlook / collaboration Features, die ich in einem größeren Unternehmen als noch sinnvoller erachte, als das "Foto Feature". Es fördert m.E. die Unternehmens- als auch Kommunikationskultur und sorgt für die ein oder andere nettere E-Mail, als ich oder andere sie ohne Bild schreiben würden. Die AD ist kein "Datenspeicher" - korrekt. Es wird in Zukunft sicher auch andere Entwicklungen geben, die eine zusätzliche "Ebene" als Datenspeicher bzw. Abstraktion einziehen, auch korrekt. Aber die 100MB ist es mir selbst in der AD DB wert. Und damit möchte ich jetzt *nicht* die Diskussion aufmachen, welche anderen 100MB da noch Platz hätten usw. usf. ;) Viele Grüße olc

Hi, ich verstehe Dein Problem nicht - Du hast die Antwort doch schon selbst gefunden: Greife per DNS-Namen auf den 2008er DC zu und es funktioniert. Das hattest Du ja oben selbst so angegeben. Wenn Dir darüber hinaus jemand helfen soll, macht eine nachvollziehbare Beschreibung des Problems Sinn. Im Moment werde zumindest ich aus der Beschreibung nicht wirklich schlau. Viele Grüße olc

...und wenn es doch ein wenig tiefer gehen bzw. Bezug auf den Kernel u.v.m. nehmen soll (meiner Meinung nach nicht für "Windows Anfänger" geeignet): Windows Internals Book BTW: Willkommen an Bo(a)rd. :) Viele Grüße olc

Hi Thomas, der "root\CIMv2" Namespace ist korrekt. Using WMI Filters to apply Group Policy to a target operating system - Spiceworks Community Viele Grüße olc

Hi, nein, Du setzt den WMI Filter auf die Startup-Script GPO. Dann wird diese nur auf Windows 7 Systemen angewendet. Viele Grüße olc

Hi, zum Beispiel über einen WMI-Filter (in dem Beispiel alles Windows 7 und höher): SELECT version, producttype FROM Win32_OperatingSystem WHERE version >= "6.1" and producttype = "1" Viele Grüße olc

Hier geht es dann los mit dem Benutzer: USERENV(46c.470) 08:50:12:132 LoadUserProfile: lpProfileInfo->lpUserName = <Jansen>CODE] Das Anwenden der Gruppenrichtlinien ist in zwei Minuten durch: [code]USERENV(46c.e60) 08:52:43:207 ApplyGroupPolicy: Leaving successfully. Der Explorer wird jedoch erst vier weitere Minuten später geladen, das ist das, was DU mit Logon-Verzögerung meinst: USERENV(180.1c8) 08:56:47:382 LibMain: Process Name: C:\WINDOWS\Explorer.EXE Mach es so, wie ich oben vorgeschlagen habe (Dienste, Citrix Client usw.), prüfe ob es noch immer zu den Verzögerungen kommt und wenn ja dann schauen wir weiter. Viele Grüße olc

Hi Rolf, mit dem UserEnv2.txt ist leider nichts zu machen, das UserEnv3.txt ist interessanter: Zuallererst zeigt sich, daß eine Menge Dienste starten, auch von Drittherstellern. Die lauen teilweise im System Kontext und die Auflösung der Domäne läuft falsch (gegen die "NT Authority"), was zu folgenden Fehlern im Log führt: USERENV(4a4.4f4) 08:45:53:687 GetUserDNSDomainName: Domain name is NT Authority. No DNS domain name available. An dienster Stelle also noch einmal der Hinweis, am besten alle "nicht-Microsoft" Dienste als auch Autostarts zu deaktivieren. Für die Dienste kannst Du das mit "msconfig" recht schnell erledigen (Option "alle Microsoft Dienste ausblenden, danach alles andere testweise abstellen). Zum Beispiel wären da: C:\Programme\Application Updater\ApplicationUpdater.exe C:\Programme\Kaspersky Lab\Kaspersky Anti-Virus 6.0 for Windows Workstations MP4\avp.exe C:\Programme\Egonon GmbH\Egonon Tools\EgononAgent.exe C:\Programme\Kaspersky Lab\NetworkAgent 8\klnagent.exe C:\Programme\Citrix\ICA Client\ssonsvr.exe C:\Programme\pdfforge Toolbar\SearchSettings.exe C:\PROGRA~1\Citrix\ICACLI~1\WFICA32.EXE Die Autostarts mit "Autoruns" von Sysinternals deaktivieren, ist als Komfortablesten. Übrigens gibt es zum Citrix Client ein bekanntes Problem, welches sich unter anderem in langen Logon-Zeiten äußert: When you log on to a Windows XP-based computer that is running version 10.200 of the Citrix ICA client, Windows XP may create a user profile instead of loading your cached profile Und wenn ich die Einträge hier sehe, dann sieht es für mich stark nach dem Problem aus: USERENV(46c.470) 08:50:12:289 MyRegLoadKey: Failed to load subkey <S-1-5-21-366635727-893605893-1990678075-3335_Classes>, error =32 USERENV(46c.470) 08:50:12:289 MyRegLoadKey: Returning 00000020 Erst nach dem Deaktivieren der Autostarts, der Dienste als auch dem testweisen Deaktivieren des Prefetchings (oder Aktualisierung des Citrix Clients) solltest Du überhaupt weiter machen... Das Log zeigt einen Computerneustart - und auch in diesem Beispiel wird ein PING zur Überprüfung der Linkgeschwindigkeit geblockt: USERENV(46c.3dc) 08:46:00:390 PingComputer: Second send failed with 11010 USERENV(46c.3dc) 08:46:00:406 PingComputer: First time: 27 USERENV(46c.3dc) 08:46:05:890 PingComputer: Second send failed with 11010 USERENV(46c.3dc) 08:46:05:906 PingComputer: First time: 27 USERENV(46c.3dc) 08:46:11:390 PingComputer: Second send failed with 11010 USERENV(46c.3dc) 08:46:11:390 PingComputer: No data available USERENV(46c.3dc) 08:46:11:531 PingComputer: PingBufferSize set as 2048 USERENV(46c.3dc) 08:46:11:531 PingComputer: Adapter speed 100000000 bps USERENV(46c.3dc) 08:46:11:546 PingComputer: First time: 27 USERENV(46c.3dc) 08:46:16:887 PingComputer: Second send failed with 11010 USERENV(46c.3dc) 08:46:16:903 PingComputer: First time: 27 USERENV(46c.3dc) 08:46:22:384 PingComputer: Second send failed with 11010 USERENV(46c.3dc) 08:46:22:400 PingComputer: First time: 27 USERENV(46c.3dc) 08:46:27:881 PingComputer: Second send failed with 11010 USERENV(46c.3dc) 08:46:27:881 PingComputer: No data available USERENV(46c.3dc) 08:46:27:881 ProcessGPOs: DSGetDCName failed with 59. USERENV(46c.3dc) 08:46:27:881 ProcessGPOs: No WMI logging done in this policy cycle. USERENV(46c.3dc) 08:46:27:881 ProcessGPOs: Processing failed with error 59. USERENV(46c.3dc) 08:46:27:881 LeaveCriticalPolicySection: Critical section 0x5a4 has been released. Ping ist also immer noch nicht frei, ggf. solltest Du in einem Netzwerktrace oder simpel mit "tracert.exe"prüfen, wo es hakt. ...geht gleich weiter...

Hi, Du gehst hier von einem vollkommen "falschen" Ansatz aus: Generell hast Du als Admin erst einmal gar kein "Recht" auf das Benutzerzertifikat. Das ist wie ein Kennwort zugehörig zum Benutzer und Du solltest - auch im Kontext des Datenschutzes - die Finger davon lassen. Sonst kannst Du auch gleich die Verschlüsselung sein lassen. Das DRA Zertifikat ist genau für den von Dir beschriebenen Fall gedacht: Der Benutzer kann seine Dateien nicht mehr entschlüsseln, weil etwa das Schlüsselmatierial weg oder der Benutzer nicht mehr im Unternehmen ist. Nun greifst Du auf den DRA Account zurück, der die Daten wieder entschlüsseln kann, ohne Zugriff auf das Schlüsselmaterial des Bneutzers zu haben. Genau aus diesem Grund ist der oben genannte Artikel auf ServerHowTo.de der richtige für Dich. Wie Dunkelmann schon schrieb: Schau Dir einmal den genannten Literaturvorschlag an - dann entzerrt sich vielleicht einiges. Bevor Du mit der Verschlüsselung von Daten anfängst empfehle ich dringend, sich mit der PKI Thematik als solches zu beschäftigen. Sonst läuft Du ggf. schnell in wirklich große Probleme. P.S.: Bitte nicht falsch verstehen, ich meine es nur gut. :) Viele Grüße olc

Hi, das ist "by design". Du kannst nicht über die IP-Adresse auf den SSL Port zugreifen, da die IP-Adresse nicht als "Subject" bzw. "SAN" im DC Zertifikat steht. Da jedoch ein "match" erfolgen muß, damit Du weißt, daß es auch wirklich das korrekte Zielsystem ist, auf welches Du SSL-verschlüsselt zugreifst, funktioniert nur der DNS Name des DCs, der auch im Zertifikat steht. Warum möchtest Du überhaupt per IP-Adresse zugreifen - das ist doch im Normalfall gar nicht notwendig...? Viele Grüße olc

Hi, in einer Batch-Datei mußt Du die "%" als doppeltes Prozentzeichen markieren, also "%%1" anstatt "%1". Aber mach es wie Dukel schon sagte und nimm das von ihm angegebene PS Beispiel. Leite die Ausgabe in eine Textdatei um, um zu dokumentieren, was gelöscht wurde. Viele Grüße olc

...wobei es in dem Beispiel von Dukel egal ist, ob PS 1.0 oder PS 2.0. Bei Angabe des UNC Pfades für die Löschung werden die remote Funktionen der PS nicht aktiviert. Das ist ein simpler SMB/CIFS Zugriff... Viele Grüße olc

Hi, für mich sieht es so aus, als sei das "call" das Problem - dabei wird eine neue Session gestartet, in der die Variable nicht definiert ist. Versuche es einmal in einer Batch-Datei wie folgt (ggf. das RMDIR durch ein simples DEL ersetzen): for /f "delims=" %%a IN ('dir D: /b /s *.ost') do rmdir /S /Q %%a Natürlich geht PowerShell ebenso. Viele Grüße olc

Hi simmrein, warum möchtest Du das tun? Es hat in bestimmten Fällen je nach Konstellation Sinn, daß auch abgelaufene Zertifikate dort zu finden sind - um beispielsweise auch nach längerer Zeit die (alten) Signaturen der Nutzer prüfen zu können. Erläutere doch ein wenig genauer die Anforderung, dann können vielleicht ein paar Tipps gegeben werden. Generell ist ein Aufräumvorgang sicher auch automatisierbar, etwa mittels VBScript / PowerShell etc. (das in http://www.microsoft.com/downloads/en/details.aspx?familyid=2305405C-FAF1-488A-A856-AD467BB59B26&displaylang=en enthaltene Script etwa könnte nach ein paar Anpassungen ein Ansatz sein). Aber eben nur, wenn man weiß, was man dort eigentlich tut. ;) Viele Grüße olc

...lest Euch einfach noch einmal den von dmetzger geposteten Artikel durch. Dann wird klar, warum das distributed locking nicht immer eine gute Idee ist und warum Microsoft sich zumindest für den Moment gegen diesen Ansatz entschieden hat. Um es nochmal zu sagen: Für solche Szenarien sind Replikationslösungen in vielen Fällen nicht optimal. SharePoint wurde als Alternative schon genannt. P.S.: Auch, wenn man ein schwarzes Blatt Papier zwei mal wendet, ist es immer noch nicht weiß. Viele Grüße olc

Hi, ganz ohne Gegenfragen ;) : Nein, im "Freeware" Bereich ist da eher nichts zu finden. Aber wenn Eure Umgebung so groß ist, daß das normale Auditing von Windows nicht ausreichend ist und man es nicht anders nachvollziehen kann als über ein erweitertes Logging, dann sollte das Kleingeld für eine solch ausgewachsene Lösung schon drin bzw. gut investiertes Geld sein oder? ;) :p BTW: Willkommen an Bo(a)rd. :) Viele Grüße olc

Hi, wie oben schon gefragt: Prüf einmal, ob die Computerkonten überhaupt noch da sind oder ob vielleicht ein anderer Computer das Konto "übernommen" hat. Das kannst Du mit dem Repadmin Befehl herausfinden - sofern repadmin.exe auf dem System vorhanden ist. Am besten auf einem DC probieren. Ansonsten prüfe wie angesprochen, ob Images eingesetzt werden, um die Clients entweder zu installieren oder aber "rückzusichern". Viele Grüße olc

Hi, bitte poste einmal den gesamten Event-Text. Ansonsten ein Schuß ins Blaue: Kann es sein, daß die Computerkonten der Clients zentral gelöscht werden? Prüf einmal, ob zum Zeitpunkt des Fehlers das jeweilige Computerkonto in der AD zu finden ist. Falls ja, prüfe mit einem "repadmin /showobjmeta <DC_NAME> "CN=computer,OU=deine_ou,DC=domain,DC=tld", wann das Computerkennwort zuletzt geändert wurde. Werden die Clients regelmäßig über Images oder ähnliche Mechanismen "zurück gesichert"? Viele Grüße olc

Hi zusammen, Genau, ich (wie ich auch schrieb) nämlich auch nicht. Und genau das ist der Punkt: Weder Fehler noch eine Zeitverzögerung. Ich denke also nicht, daß wir hier einen "Schlecht-Fall" sehen. Korrekt, ich habe auch nichts gegenteiliges behauptet. Das kann sein, muß aber nicht. Je nach Konstellation kann es ein Hinweis auf ein Problem sein. Und da es sich hier um eine VPN Fragestellung handelt, ist nicht auzuschließen, daß der DsgetDc Call fehlschlägt, weil kein Domänen-Netz vorhanden ist. Also prüfen. Welche Gruppenrichtlinie meinst Du genau? Wenn sich ein Benutzer anmeldet, dann ist das "Foreground processing". Zyklische Hintergrundaktualisierungen können zu diesem Zeitpunkt nicht stattfinden. Das ist jedoch das, was im Anschluß an das Laden des Profils passiert. Oder verstehe ich Dich da falsch? Kein Widerspruch, so wie ich es auch oben geschrieben habe. ;) Ok, und die Anmeldung hat in diesem konkreten Log-Fall tatsächlich lange gedauert? Das sind alles unterschiedliche Prozesse, was Du an den in Klammern stehenden HEX-Werten siehst (inkl. Threads nach dem Punkt). Zu diesem Zeitpunkt ist jedoch aus meiner Sicht des letzten Logfiles die Anmeldung schon abgeschlossen. D.h. die Prozesse werden im Autostart des Benutzers abgearbeitet. Der startet jedoch erst mit dem Explorer, das heißt es müßten schon Icons auf dem Desktop langsam angezeigt werden. Wie oben schon geschrieben solltest Du die Autostart Einträge des Benutzers einmal prüfen und ggf. alle nicht-Microsoft Starts und Dienste testweise deaktivieren. Der Virenscanner ist in jedem Fall ein heißer Kandidat. Ganz sicher? Bitte noch einmal generieren und zusätzlich die Ereignisprotokolleinträge zu diesem Zeitpunkt mit posten (Application, System) P.S.: Wobei mir gerade auffällt, daß der Explorer tatsächlich erst sehr spät geladen wird... Check einmal wie beschrieben die Autostarts und deaktiviere alles, was als Autostart und als Dienst "nicht-Microsoft" ist. Viele Grüße olc

Hi, sorry, hab den Thread übersehen. Zahni sagte schon richtig, daß Du wegen der fehlenden ICMP Pakete immer einen "fast link" bekommst, dadurch werden Scripts, Orderumleitung usw. ausgeführt, was über eine langsame Leitung ggf. zu Problemen führen kann. Aus dem UserEnv Log geht jedoch nicht wirklich etwas "sinnvolles" hervor. Zuerst findet eine Abmeldung statt, die um 13:51:14 beendet ist: USERENV(46c.470) 13:51:14:205 UnloadUserProfile: returning 1 Es folgt nun folgerichtig die Anmeldung des Benutzers: USERENV(46c.470) 13:53:13:590 LoadUserProfile: Yes, we can impersonate the user. Running as self USERENV(46c.470) 13:53:13:590 ========================================================= USERENV(46c.470) 13:53:13:590 LoadUserProfile: Entering, hToken = <0x7d8>, lpProfileInfo = 0x6e3e0 USERENV(46c.470) 13:53:13:590 LoadUserProfile: lpProfileInfo->dwFlags = <0x0> USERENV(46c.470) 13:53:13:590 LoadUserProfile: lpProfileInfo->lpUserName = <Jansen> Das Laden des Profils ist dann jedoch innerhalb kürzester Zeit beendet (es liegt lokal schon ein Profil vor): USERENV(46c.470) 13:53:13:699 LoadUserProfile: Leaving with a value of 1. USERENV(46c.470) 13:53:13:699 ========================================================= USERENV(46c.470) 13:53:13:699 LoadUserProfile: LoadUserProfileP succeeded USERENV(46c.470) 13:53:13:699 LoadUserProfile: Returning success. Final Information follows: USERENV(46c.470) 13:53:13:699 lpProfileInfo->UserName = <Jansen> USERENV(46c.470) 13:53:13:699 lpProfileInfo->lpProfilePath = <> USERENV(46c.470) 13:53:13:699 lpProfileInfo->dwFlags = 0x0 USERENV(46c.470) 13:53:13:699 LoadUserProfile: Returning TRUE. hProfile = <0x240> Hier sehe ich also keine Verzögerung. Danach erfolgt nur noch ein "background processing": USERENV(46c.cdc) 13:53:13:762 IsSyncForegroundPolicyRefresh: Synchronous, Reason: policy set to SYNC USERENV(46c.cdc) 13:53:13:762 ApplyGroupPolicy: Entering. Flags = 6 USERENV(46c.cdc) 13:53:13:762 ProcessGPOs: USERENV(46c.cdc) 13:53:13:762 ProcessGPOs: USERENV(46c.cdc) 13:53:13:762 ProcessGPOs: Starting user Group Policy (Background) processing... --> Kann es sein, daß Ihr dort im Autostart des Benutzers ein lokales Script liegen habt, welches ein "GPUPDATE" durchführt? Prüfe das doch einmal mittels "Autoruns": AutoRuns for Windows Wenn ich dann das hier sehe, ist zu vermuten, daß die DNS Auflösung der Domäne zu diesem Zeitpunkt auch gar nicht funktioniert: USERENV(46c.cdc) 13:53:46:749 ProcessGPOs: DSGetDCName failed with 59. --> Daraus ergibt sich die Frage, ob Du hier wirklich den Fehlerfall gepostet hast? War zum Zeitpunkt der mit dem UserEnv Log mitgeschnittenen Anmeldung tatsächlich das VPN hergestellt und kam es zu einer Logon-Verzögerung? Aus meiner Perspektive müssen beide Fragen mit "nein" beantwortet werden. ;) Also schneide es noch einmal im Fehlerfall mit und poste es erneut. Viele Grüße olc