olc

Hi, vermutlich wird es sich schlichtweg um ein NetBIOS oder DNS Problem handeln. Schau einmal, ob sich das FreeeNAS als WINS 1B (oder eher unwahrscheinlich als 1C) Eintrag auf den WINS Servern registriert hat bzw. prüfe Dein AD DNS. Ggf. müssen die Einträge entfernt werden. Viele Grüße olc

Hi, schau einmal hier hinein: Download: Planning Active Directory Forest Recovery - Microsoft Download Center - Download Details Das Dokument umfaßt alle Schritte und enthält meiner Erinnerung nach auch Checklisten. Viele Grüße olc

Hi Stephan, schreib die Ausgabe des Befehls doch einmal in Textdateien um zu prüfen, was eventuell schief geht: ntdsutil "active instance ntds" snapshot create q q > C:\TEMP\result.log 2> C:\TEMP\error.log "C:\TEMP" muß dafür schon existieren. :) Viele Grüß olc

Siehe dazu auch: Hinweise zur Einführung bzw. Aktivierung von Kennwortrichtlinien - Aktives Verzeichnis Blog - Site Home - TechNet Blogs Viele Grüße olc

Hi, das Verschieben ist von Microsoft "supported", aber *explizit* nicht empfohlen. Offensichtlich sind nicht alle TechNet Artikel in Bezug auf diese Aussage aktualisiert worden. Hintergrund die potentielle Probleme mit den verlinkten GPOs, Monitoring Lösungen, diverser "Drittsoftware" als auch u.U. problematischen Auswirkungen, wenn etwa DC-Zertifikate eingesetzt werden (PKI). Die ausgestellten Zertifikate können den DN der DCs zum Ausstellungszeitpunkt der Zertifikate enthalten, was Probleme bereiteten kann, wenn die Objekte verschoben werden. Das "zurück Verschieben" ist also grundsätzlich empfehlenswert, kann jedoch (siehe Zertifikatbeispiel) auch zu Problemen führen. Vermutlich hast Du keine Testumgebung, die der Produktionsumgebung entspricht? BTW: Nur ein DC in einer Domäne / einem Forest ist nicht zu empfehlen. Bestenfalls sind es mindestens zwei DCs pro Domäne. Viele Grüße olc

Hi, schön zu hören, daß Dir die Hinweise weiterhelfen konnten. ;) Häufig laufen die Scanner beim Computerstart an und prüfen diverse Abhängigkeiten, ggf. auch mittels WMI-Abfragen. Frag einmal bei Sophos an, ob das Problem bekannt ist - vielleicht behebt ja eine aktuelle Version das Problem. Dann nicht vergessen, den Ursprungszustand wieder herzustellen. ;) Viele Grüße olc

Hi, schau einmal hier hinein zu "sinnvollen" Performance Countern: adminfoo.net: Windows Perfmon: The Top Ten Counters Zum Alarm per E-Mail: http://www.mcseboard.de/windows-server-forum-78/perfmon-per-email-102088.html Viele Grüße olc

Hi, neben dem Hinweis von Sunny: Die Verarbeitung von Gruppenrichtlinien im Computerkontext scheint aus meiner Sicht nicht das Problem zu sein: Start ist hier: USERENV(208.e50) 11:51:50:921 ProcessGPOs: Starting computer Group Policy (Background) processing... Und hier sind die GPOs für den Computer durch: USERENV(208.e50) 11:52:26:025 ProcessGPOs: Computer Group Policy has been applied. USERENV(208.e50) 11:52:26:025 ProcessGPOs: Leaving with 1. USERENV(208.e50) 11:52:26:025 ApplyGroupPolicy: Leaving successfully. Das sind also ca. 36 Sekunden. Was dagegen interessanter erscheint ist die Zeit direkt vor dem Logon des Administrators: USERENV(d5c.d74) 11:52:32:309 LibMain: Process Name: C:\WINDOWS\System32\alg.exe USERENV(dc4.dd0) 11:52:34:185 LibMain: Process Name: C:\WINDOWS\system32\wbem\wmiprvse.exe USERENV(b20.1d4) 11:52:37:656 LibMain: Process Name: C:\WINDOWS\system32\reg.exe USERENV(4ec.808) 11:52:40:063 GetProfileType: Profile already loaded. USERENV(4ec.808) 11:52:40:142 LoadProfileInfo: Failed to query central profile with error 2 USERENV(4ec.808) 11:52:40:157 GetProfileType: ProfileFlags is 0 USERENV(d08.22c) 11:52:40:345 LibMain: Process Name: C:\WINDOWS\system32\userinit.exe USERENV(fc0.fc4) 11:52:41:470 LibMain: Process Name: C:\WINDOWS\system32\wbem\wmiprvse.exe USERENV(208.be4) 11:53:46:005 IsSyncForegroundPolicyRefresh: Synchronous, Reason: policy set to SYNC USERENV(d14.bb4) 11:53:47:646 LibMain: Process Name: C:\Programme\Novell\ZENworks\esm\ZESService.exe Was läuft auf dem System als Virenscanner, Host-Intrusion, Inventarisierung, Softwareverteilung usw. usf. und was für Computer Startup-Scripts sind zugewiesen? Deaktiviere einmal Zenworks und ggf. die o.g. Komponenten und prüfe, ob die Verzögerung dann immer noch auftritt. Aus meiner Sicht ist die Minute Wartezeit auf die WMI-Rückmeldung hier Dein Problem: USERENV(fc0.fc4) [b]11:52:41:470 [/b]LibMain: Process Name: C:\WINDOWS\system32\wbem\wmiprvse.exe USERENV(208.be4) [b]11:53:46:005 [/b]IsSyncForegroundPolicyRefresh: Synchronous, Reason: policy set to SYNC USERENV(d14.bb4) 11:53:47:646 LibMain: Process Name: C:\Programme\Novell\ZENworks\esm\ZESService.exe Und der WMI-Aufruf wird vermutlich über einen zuvor gestarteten Dienst oder aber ein Startup-Script hervorgerufen. Viele Grüße olc

Siehste? ;) Einen Link dazu habe ich oben gepostet. Mittels PowerShell kannst Du die Eventlogs verschiedener DCs abgrasen. Get-EventLog Use PowerShell Cmdlet to Filter Event Log for Easy Parsing - Hey, Scripting Guy! Blog - Site Home - TechNet Blogs Der "-UserName" Parameter könnte passen, bin mir gerade nicht sicher. Schau Dir das einmal an. Mit XPath: Get-WinEvent Viele Grüße olc

Hi, Das ist schade - denn ohne diese Information können wir Dir hier nicht weiterhelfen. Aus meiner Sicht verfolgst Du den falschen Ansatz - und nicht sinnvolle Ansätze unterstützen wir hier in der Regel nicht. Die Antwort hatte Dir Dukel schon gegeben: Windows PowerShell Remoting Viele Grüße olc

Hi, Doch, diese Information wird im entsprechenden Event auf dem DC geloggt, auf dem der Anmeldeversuch stattgefunden hat. Zusätzlich wird die Information zum PDCe übertragen, sofern "AvoidPdcOnWan" nicht aktiviert wurde. Auf dem PDCe wird dann jedoch nur der DC geloggt, der ursprünglich den Anmeldeversuch "abgefangen" hat. Diesen DC muß man sich dann also anschauen. Ich persönlich finde "Vermutungen" immer schwierig. ;) Wie angesprochen: Wie hoch ist die Kontensperrungsschwelle? Viele Grüße olc

Hi Stefan, ah - ok. Also genau anders herum. Umso besser. :D Schön, daß es geklappt hat und danke für Deine Rückmeldung. :) P.S.: Nein, ein "gelöst" gibt es nicht. Viele Grüße olc

Hi, schau einmal hier hinein: https://blogs.technet.com/b/askds/archive/2011/09/26/advanced-xml-filtering-in-the-windows-event-viewer.aspx?Redirected=true Welche Lockout-Schwelle hast Du bei Dir in Betrieb? Alles unter "10" rechtfertigt vermutlich noch nicht einmal ein Troubleshooting - erst, wenn ein Benutzer trotz 10-50 ungültigen Anmeldeversuchen gesperrt wird, hat es aus meiner Sicht Sinn, das gegenzuprüfen. Viele Grüße olc

Hi, warum genau möchtest Du das machen - was ist der Hintergrund der Anforderung? Viele Grüße olc

Hi, kann, vielleicht, unter Umständen ;) - das bringt Dich nicht weiter. :) Du solltest auf die Netzwerkabteilung zugehen und nach der Portfast Option Fragen oder ob es "auf der Leitung" Probleme gibt. Das sollte sich Port-bezogen nachvollziehen lassen. Erst danach hat es Sinn weiter zu suchen - denn Dein Test mit dem "billig-Switch" zeigt ja recht deutlich, daß es in diese Richtung zu gehen scheint. Viele Grüße olc

Hi, ich hoffe nicht, daß das *.PFX an das iOS Gerät übertragen wird? Bevor Du da irgend welche privaten Schlüssel durch die Gegend transferierst, solltest Du noch einmal genau fragen, was da eigentlich passiert. Mittels NDES o.ä. lassen sich die iOS Geräte mit Zertifikaten versorgen und sollten maximal das Zertifikat (ohne privaten Schlüssel) der CAs bzw. des Barracuda Geräts bekommen. Aber ohne weitere Infos ist es schwer hier weitere Hinweise zu geben. Viele Grüße olc

Moin, :) Also wenn ich die Frage nicht falsch verstanden habe, sind normale Kennwortänderungen gemeint. Die waren auch unter XP bei aufgebautem VPN möglich. Ja, der NLA erkennt die Verbindung zur Domäne und die GP-Engine "hört" auf den Systemcall dazu. Wie die Verbindung hergestellt wurde ist dabei egal. Viele Grüße olc

Hi, schau einmal hier hinein: Creating the Personal Information Exchange (PFX) Certificate Du meinst "PKCS#12", welches Du in einem *.PFX bereitstellen kannst. Aber einmal genauer nachgefragt: Wozu dient diese Art des Austauschs? Was ist der Hintergrund für die Anforderung? Viele Grüße olc

Hi, Das geht auch, nachdem der Benutzer angemeldet wurde und das VPN hergestellt wurde. Oder verstehe ich die Frage falsch? Ab Vista werden die GPOs (keine Anmeldescripts o.ä.) direkt nach Aufbau der (Domänen-) VPN Verbindung abgearbeitet, sofern die standardmäßig eingestellten 90 Minuten nach der letzten GPO Aktualisierung abgelaufen sind. Viele Grüße olc

Hi, muß es per Script sein oder könnten die GPP eine Alternative sein ( http://support.microsoft.com/kb/2001454)? Viele Grüße olc

Hi, Du mußt den %PATH% zum Programm definieren, siehe dazu: How to set the path in Microsoft Windows Viele Grüße olc

Hi, ich kenne mich mit iOS nicht aus, aber es gibt ganz sicher auch einen lokalen "Zertifikatmanager". Schau dort einmal hinein. "Einwände" habe ich keine, zumindest aufgrund der bekannten Informationen. ;) Viele Grüße olc

Hi, ja, der private Schlüssel wird in diesem Fall wie angesprochen auf dem Gerät erstellt. Der NDES Server vermittelt im Kern nur den Request an die entsprechende CA und diese stellt auf Basis des Requests ein Zertifikat aus. In dieser konkreten Konstellation verläßt der private Schlüssel das mobile Gerät nicht. Wenn Du das Vorhaben in größerem Maßstab durchführen möchtest und nicht nur auf einem mobilen Gerät, kommst Du im Moment an Managementsoftware von Drittherstellern (egal ob für iOS, Andoid oder Windows Phone) nicht vorbei - die Standardmethoden der Telefone zur zentralen Schlüsselverwaltung sind nur sehr rudimentär oder aber schlichtweg nicht vorhanden. Von welchem OS reden wir denn auf dem mobilen Gerät? Viele Grüße olc

Hi, von Zonenübertragungen hast Du bisher nicht geredet, daß es in eine Richtung klappt hast Du auch nicht erwähnt. Sofern Du die Informationen weiter zur scheibchenweise zum Besten gibst, kommen wir nur mühsam weiter. ;) Nimm wie angesprochen einen Netzwerktrace und filtere auf DNS Anfragen, während Du den Fehler reproduzierst - was siehst Du? Firewall Einstellungen (insbesondere RPC + dynamisches RPC / DNS / Kerberos) sind in beide Richtungen korrekt? Viele Grüße olc

Hi, Du kannst das jeweils verwendete Template anpassen, siehe dazu AD CS: Network Device Enrollment Service Viele Grüße olc