olc

Hi, das Support Statement bezieht sich nur auf replizierte Profile, die per DFSN bereitgestellt werden und gleichzeitig repliziert werden: Distributed File System: Frequently Asked Questions . Heißt also, daß nicht replizierte Profile unterstützt werden würden, auch wenn mehrere Ziele vorhanden sind. Die Replikation ist das Problem. Anbei noch der Link zu DFSR: DFS Replication: Frequently Asked Questions Viele Grüße olc

Hi Martin und willkommen an Board, :) nicht immer gleich mit der Vermutung "Bug" um sich werfen - in wahrsheinlich 99% der Fälle sitzt der Bug vor dem Rechner. :p Scherz beiseite: Du kannst einschränken, wer sich an einem System anmelden darf und auf welche Art und Weise. Prüfe doch einmal mittels GPMC RSOP Group Policy Resulsts Report auf dem SBS mit Ziel Windows 7 Client, welche Security Options festgelegt wurden. Unter Umständen wurde etwas an einer Policy wie "Interaktive Anmeldung verweigern" (muß nicht genau so heißen) gedreht o.ä. Siehe dazu auch: http://technet.microsoft.com/de-de/library/cc756809%28WS.10%29.aspx Viele Grüße olc

Hi Andy, schön, daß Dir die Tipps weiterhelfen konnten und danke für die Rückmeldung. :) Viele Grüße olc

Hi Sabine, AFAIR sollte das Variante 1. sein, also die "normalen" Eigenschaften des Kontos. Was spricht gegen einen Test, wenn Du Dir unsicher bist? ;) Viele Grüße olc

Hi, wenn Du nur direkt über den Servernamen drauf kommst, nicht aber über den Namespace, dann vermute ich, daß Du die Berechtigungen (entweder auf Freigabeebene oder auf NTFS Ebene) des Links nicht korrekt gesetzt hast. Überprüfe die Berechtigungen auf Namespace Ebene noch einmal. Viele Grüße olc

Hi, vielleicht noch der Hinweis, daß DFSN bei Profilen mit mehreren Targets nicht von Microsoft supported ist. Auch die DFSR Replikation von Profilen, so daß über verschiedene DFSN Ziele auf "unterschiedliche" Daten zugegriffen wird, ist nicht supported. Das mag einen stören oder nicht - man sollte es aber auf dem Schirm behalten, denn es hat seinen guten Grund. ;) Viele Grüße olc

Hi, ok - dann war der Begriff "Logonscript" von Dir nicht korrekt. Wie Sunny (indirekt :p) und Dukel schon richtig sagten, werden "Startup" Scripts, also Computer Startskripte, im Systemkontext ausgeführt. Damit solltest Du alle Berechtigungen haben, die Du benötigst. Viele Grüße olc

Jau, es gibt einige Konstellationen, wo das "Sinn" macht (die Anzeige von "Applying Computer Settings" während des Benutzer-Anmeldeprozesses). Das heißt ja nicht, daß tatsächlich die Einstellungen des Computer gezogen werden. Siehe dazu auch: You experience a delay when you use your Windows XP computer to log on to a domain or to connect to a network resource Im Artikel sind dann auch noch Hinweise zum möglichen Troubleshooting. Viele Grüße olc

Hi, mit Standort Policies + WMI Filter hat man dann auch gleich 2 Dinge, die vom Design her nach Möglichkeit vermieden werden sollten - so zumindest meine Meinung, wenn es sich auch anders lösen ließe. Sind die IP-Adressen des Clients denn "fest" oder werden diese per DHCP verteilt? Bei DHCP bekommt der Client eine "lokale" IP-Adresse und per DFS könnte er sich dann auf den lokalen Namespace verbinden. Nur mal so als Idee... [EDIT] Stephan war schneller. :) [/EDIT] Viele Grüße olc

Hi, Das ist nicht ganz richtig - bei der Benutzeranmeldung kann es ebenso wie beim Computerstart zur Übernahme von Richtlinien kommen, die in der GUI als "Computereinstellungen" angezeigt werden. Der Auszug des geposteten UserEnv Logs ist auch recht eindeutig, daß es sich um einen Benutzerteil handelt. Viele Grüße olc

Hi, Ich habe nicht umsonst geschrieben, daß *.exe Dateien o.ä. nicht "sinnvoll" sind bzw. ich es bewußt aus lasse. :wink2: Wenn ein Kennwort übergeben werden muß, muß es im Normalfall eine "zwei-Wege Verschlüsselung" sein - also kann ein Angreifer die Daten einer solchen Datei auch entschlüsseln. Aus Sicherheitsgründen ist von der Nutzung also abzuraten. Viele Grüße olc

Hi Micha, einmal anders gefragt: Warum setzt Du nicht lieber eine USV und redundante Netzteile ein, anstatt Dir solche Fragen zu stellen? ;) Das Schema Upgrade ist bei einem solchen Fall übrigens das geringste Problem - relevanter ist es, daß die AD-Datebank bei einem Stromausfall beschädigt werden kann. Viele Grüße olc

Hi Andreas und willkommen an Board, ist der Ausschnitt des UserEnvs von einem Fehlerfall, also einer Anmeldung mit der Dauer 1 Stunde? Was steht im Ereignisprotokoll zu diesem Zeitpunkt? Ist nur ein Client betroffen oder sind es mehrere? Da der "RefCount" nicht "0" ist, greift offensichtlich ein anderer Prozess auf die Einstellungen des Benutzers zu - daher kann dieser die Einstellungen unter Umständen nicht laden. Das bestätigt sich auch hier: USERENV(440.444) 10:41:36:727 DumpOpenRegistryHandle: 2 user registry Handles leaked from \Registry\User\S-1-5-21-201809096-736436488-1640847306-500 In Deinem Fall war der Benutzer hier scheinbar der erste lokale oder Domänen-Admin, korrekt? Gute Kandidaten für solche Dinge sind Virenscanner oder andere Filtertreiber wie Verschlüsselungslösungen, Firewalls etc. Deinstalliere einmal testweise solche Dienste vom Client und prüfe, ob der Fehler dann auch weiterhin auftritt. Die lokale Gruppenrichtlinie (Local GPO's gpt.ini) sollte hier nicht relevant sein - es ist nur die Rückmeldung, daß da nichts ist. Achso, bevor es damit wieder losgeht: Nein, UPHClean ist nicht die Lösung für die Probleme, es ist ein Troubleshooting Werkzeug. ;) Wenn die Deinstallation der Dienste nicht hilft, könnte UPHClean im Callstack Logging weiterhelfen, den Prozess zu identifizieren, der Probleme bereitet. Der ProcMon könnte ebenso gute Dienste leisten, indem Du prüfst, welcher Prozess auf die NTUSER.DAT zugreift. Viele Grüße olc

Hi Raptor, nein, als Logonscript ist das in der Form nicht möglich. Ich lasse jetzt einmal bewußt Aktionen wie "Klartext Kennwort" oder "EXE-Datei mit Admin-Kennwort" raus. Was genau macht denn das Programm bzw. wozu werden Administrator Rechte im Logon-Script benötigt? Vielleicht läßt sich das Vorhaben ja auch anders lösen. Viele Grüße olc

Hi UsualSuspect und willkommen an Board, :) wie sehen denn die Berechtigungen auf dem Namespace Share aus? Sind die Authentifizierten Benutzer berechtigt (Share als auch NTFS)? Was passiert, wenn Du aus Domäne B auf \\A.local zugreifst - bekommst Du dann eine Anzeige der möglichen Ziele (ggf. nur das SYSVOL) oder scheitert dieser Zugriff schon? Viele Grüße olc

Hi, was steht denn im Ereignisprotokoll und im UserEnv Log. Wie bist Du bei der Analyse des User Env Logs vorgegangen? Sind eventuell veraltete NIC-Treiber im Spiel oder NIC-Teaming auf den DCs? Hast Du einmal einen Netzwerktrace gezogen und geprüft, was so über die Leitung geht? Viele Grüße olc

Hi, das Hinzufügen von Security Gruppen Mitgliedschaften ließe sich auch automatisieren. Beispielsweise, wenn die Rechner ein bestimmtes Namensformat hätten oder einen bestimmten Managementbereich etc. Ansonsten könntest Du versuchen, mittels eigener MOF Datei auf Registry Schlüssel zu prüfen: grouppolicy - WMI Filters Viele Grüße olc

Hi pastors, womit schaust Du Dir das Benutzerobjekt an? Untergeordnete Knoten / Container sind kein Attribut im AD (auch kein Dateiattribut), sondern Sub-Container. Nutzt Du beispielsweise ADSIEdit.msc, kannst Du Dir die Sub-Container recht einfach anzeigen lassen. Probiere es also einmal damit. Viele Grüße olc

Hi, wenn nur die benötigten Ports freigegeben sind, dann geschieht dies über die Board-eigene Firewall? Da in Deinem Log auch SMB angesprochen wird vermute ich, daß keine zusätzliche Firewall davor steht? Ich kann zahni nur zustimmen - wenn Du dieses "Hintergrundrauschen" nicht möchtest, schalte ein IDS / IPS davor. Dann kannst Du gleich auch inhaltlich gegenprüfen, was da über die Leitung geht, zum Beispiel mit dem ISA als Reverse Proxy o.ä. Produkten. Viele Grüße olc

Hi wiwa, schau einmal hier hinein: http://www.microsoft.com/windowsserver2003/techinfo/overview/abe.mspx Viele Grüße olc

Hi, Zertifizierungsstelle und DC auf einer Maschine ist sicherheitstechnisch nicht optimal. Aber davon abgesehen: Was hältst Du von einer Sicherung der CA (Datenbank und Logs, private Schlüssel plus Zertifikate der CA selbst und Sicherung der Dienst-Registry Keys), danach einer Deinstallation der CA + erneuter Installation (bestenfalls auf einer anderen Maschine)? Geht vielleicht "schneller" als jetzt zu versuchen, den Fehler _irgendwie_ einzugrenzen. Ansonsten sind Deine Ausführungen zur "Migration" recht gering, daher läßt sich schwer einschätzen, was genau nicht in Ordnung gegangen ist. Viele Grüße olc

Hi, vermutlich hat sich die ID des Laufwerks geändert - unter Umständen habt Ihr es neu eingebunden, es gab eine Änderung am SAN oder ähnliches? Die Volume ID muß bei DFSR gleich bleiben, sonst kommt es zu Problemen. Viele Grüße olc

Hi, Du kannst seit Windows Vista die lokalen Gruppenrichtlinien auch für einzelne Benutzer festlegen. Dazu rufst Du nicht gpedit.msc auf, sondern eine MMC, der Du dann mittels Snap-in die Gruppenrichtlinienverwaltung hinzufügst. Dort kannst Du dann auch einzelne lokale Benutzer auswählen, für die die Richtlinien greifen sollen. Viele Grüße olc

Hi, mit einer etwas genaueren Fehlerbeschreibung könnte man versuchen, Dir zu helfen. Mit der Aussage, daß eine Seite nicht mehr angezeigt wird, kann man leider nicht viel anfangen. Viele Grüße olc

Hi, ergänzend zum Hinweis von zahni: Wie kommen die Anfragen eigentlich über "RPC" an? Was ist nach außen auf dem WebServer freigegeben? Viele Grüße olc