olc

Hi, wie genau sind die "Images" angefertigt worden und wie sind diese zurückgesichert worden? Ggf. bist Du in einen USN Rollback gelaufen? How to detect and recover from a USN rollback in Windows Server 2003 Aber wie Du schon schriebst - wahrscheinlich ist es nach den ganzen Aktionen sinnvoll, die Umgebung neu aufzusetzen. Eine Testumgebung würde ich nach diesen vielen Änderungen und Rettungsversuchen nicht mehr als "vertrauenswürdig" einstufen. Viele Grüße olc

Hi, was ich noch merkwürdig finde, ist das folgende: Sag mal - läuft in der Umgebung eine Single Label DNS Domain "SPOX" oder warum fehlt am Ende eine TLD? Außerdem ist sie in beiden Angaben unterschiedlich: 1x "spx-fs" und 1x "spox". Weiter unten schreibst Du dann von "DC=spox,DC=local" - kann es sein, daß diese Angaben schlichtweg beim AuthLDAPBindDN UPN und der Gruppenangabe fehlen oder ist es nur beim Übertragen ins Forum "verloren gegangen"? Falls auch im Original nicht vorhanden, ergänze das "local" einmal und verwende den korrekten UPN. Ansonsten ACK mit Carsten - heftiges "pushen" ist unhöflich. ;) Viele Grüße olc

Hi, kurzer "Schnellschuß": Teste es einmal mit "AuthzLDAPAuthoritative Off". Viele Grüße olc

Hi TL, vielen Dank für Deine Rückmeldung - schön zu hören, daß es nun klappt. Ich wußte zwar nicht, in welche Richtung das Problem noch gehen würde, aber um den IIS bzw. die dazugehörigen Komponenten auszuschließen, sollte die Zertifikatanforderung mit dem certmgr.msc probiert werden. Läuft dieser, hat man das Problem recht schnell eingekreist. Läuft dieser ebenso nicht, muß man weiträumiger schauen. Aber das ist nun ja nicht mehr notwendig. :) Viele Grüße olc

Hi, die letzte Frage von mir noch einmal präzisiert: Wenn Du in dem certmgr.msc über "Eigene Zertifikate" --> ausklappen und Rechtsklick auf "Zertifikate" --> "Alle Aufgaben" (oder so ähnlich auf deutsch) "--> Zertifikat beantragen" gehst, kannst Du dann ein Zertifikat mit dem gewünschten Template beantragen oder bekommst Du den selben bzw. einen anderen Fehler? Ich habe es gerade einmal in einer Testumgebung nachgestellt - ohne Probleme. Der Client hat ansonsten keine Fehler in Bezug auf die Domänenfunktionalität? Irgendwelche Meldungen in den Eventlogs? DNS-Probleme auf dem Client oder der CA? Viele Grüße olc

Hi, Du mußt schon konkret auf die Fragen antworten, wenn wir Dir hier helfen sollen. ;) Also schau doch noch einmal, daß Du schrittweise alle Fragen der letzten Beiträge genau beantwortest - nicht nur mit allgemeinen bzw. allgemein gehaltenen Antworten, sondern konkreten Angaben zu Deiner Umgebung. :) BTW: Was passiert eigentlich, wenn Du eine Zertifikatanfrage via "certmgr.msc" durchführst? Gleicher Fehler? Viele Grüße olc

Hi, soweit alles richtig - nur eine kleine Ergänzung dazu: Man kann die Rechte auch schon auf dem DFS-Namespace bearbeiten, so daß ein Zugriff auf den Namespace ggf. gar nicht möglich ist. Die Freigabeberechtigungen des Ziels (Share) sind davon unabhängig. Viele Grüße olc

Hi, also es wurde weder an den Rechten auf dem Domain NC noch an den Rechten des Configuration NC gedreht? Was sind das für Zertifikate, die Du ausstellen möchtest? Standardmäßig kann eine Windows Server 2003 Std. Version nur V1 Templates ausstellen und auch keine zusätzlichen Templates verwalten. Was sind für Container im Configuration NC --> Services --> Puplic Key Services --> Templates enthalten? Ich habe im Moment keine Standard Installation zum testen parat, sonst würde ich es einmal testweise nachstellen. Aber ich würde vermuten, daß es etwas mit den möglichen Templates einer Std. Version zu tun hat. Viele Grüße olc

Hi, ist die CA in derselben Domäne wie der Benutzer, der das Zertifikat anfordert? Wurden sonst irgendwelche Standard-Berechtigungen innerhalb der AD (etwa auf dem Domain NC) geändert? Viele Grüße olc

Hi, ergänzend noch der Hinweis, daß Du eine CA nicht "einfach so" neu auf dem neuen Server installieren solltest. Schau einmal hier hinein, dort gibt es einige Hinweise zum Thema: How to move a certification authority to another server . Viele Grüße olc

Hi, Du könntest im UserEnv Log schauen, woher die Verzögerung kommt bzw. wo genau sie einsetzt, siehe How to enable user environment debug logging in retail builds of Windows . Ein ProcMon Trace im Boot Logging Modus kann (gleichzeitig gezogen) ebenfalls einiges an Informationen liefern. Viele Grüße olc

Hi, Password Safe ist für "Einzelplätze" meines Erachtens auch recht gut: Password Safe . Viele Grüße olc

Hi, die Share-Einstellungen sind diejenigen, die Du manuell auf dem Share eingerichtet hast. ;) Soll heißen: Du kannst die Rechte entweder direkt auf dem Namespace setzen oder auf den Shares selbst. Da ein Namespace mehrere Shares umfassen kann, macht das auch Sinn so. Wenn Du also ein Share auf "read only" setzen möchtest, regelst Du das schlichtweg auf den Freigabeberechtigungen des entsprechenden Verzeichnisses. Das hat in diesem Fall im Grunde nichts mit DFSN zu tun. Zu beachten ist dabei jedoch, daß Du voher prüfen solltest, ob auf dem Share gearbeitet wird. Falls ja, kann das "read only" setzen Datenverlust nach sich ziehen. Ggf. also vorher gegenprüfen. Viele Grüße olc

Hi, noch ein Nachtrag: Man kann offensichtlich alle Einträge manuell "anfassen", indem man "DNSCMD /AgeAllRecords" ausführt, siehe How DNS Works: Domain Name System(DNS) Das Löschen aller Einträge ist also nicht notwendig. Schau auch noch einmal in den folgenden Thread (loop ;) ...): https://www.mcseboard.de/windows-forum-ms-backoffice-31/dns-alterung-144293.html#post886352 Viele Grüße olc

N'Abend, genau, das ist auch mein Wissensstand. Konnte gerade leider nichts explizites dazu bei MS finden. Aber ich schaue noch einmal. BTW: Habe noch eine Ergänzung im anderen, verlinkten Thread gemacht. Man kann offensichtlich die vorhandenen Einträge nach dem Aktivieren des Scavengings manuell "altern" lassen und somit den Timestamp Eintrag schreiben, siehe How DNS Works: Domain Name System(DNS) --> "Understanding Aging and Scavenging". [EDIT] Doch noch etwas gefunden: http://support.microsoft.com/kb/296116/en-US Ist zwar für Windows 2000 - aber das hat sich meines Wissens nicht geändert. Heißt also für den TO, daß erst auf der DNS Zone das Scavenging aktiviert und danach einige Zeit gewartet werden sollte (damit die Timestamp Einträge bei dynamischen Updates der Clients geschrieben werden können), um danach auf einem Server (auf Serverebene, nicht Zonenebene) das Scavenging zu aktivieren. Sonst könnten die (einmalig) dynamisch aktualisierten Einträge bei der Aktivierung des Scavengins auf Serverebene schlimmstenfalls gelöscht werden. Man lernt nie aus. :) [/EDIT] Viele Grüße olc

Hi Lukas, wie gesagt - wollte keine Erbsen zählen. :) In der Umgebung des TO macht das sicherlich auch so Sinn, wie Du es geschrieben hast. Ich bin nur immer vorsichtig mit solch "generischen" Aussagen. :) Danke für Deine Rückmeldung. :) Viele Grüße olc

Hi, Ich möchte keine Erbsen zählen ;) - trotzdem die Frage, woher Du diese Information nimmst. Ich denke das ist in einigen Konstellationen definitiv nicht empfehlenswert. Mag sein, daß man das in kleineren Umgebungen so umsetzen kann - gerade ist größeren Umgebungen macht das jedoch in der Regel keinen Sinn und ist mit Sicherheit auch nicht "best practice". Noch ein Tipp an den TO: Schau einmal auf einem promoteten DC in die Dateien %SYSTEMROOT%\System32\Config --> netlogon.dnb bzw. netlogon.dns. Dort findest Du alle Einträge, die der NETLOGON Dienst auf einem DC beim Dienststart im DNS registriert. Die kannst Du zwar nicht einfach so auf einem anderen DC übernehmen, jedoch gibt es Dir ggf. einen Ansatz. Es gibt im Netz einige Tutorials zu BIND DNS und AD Zonen (z.B. hier). Darin findest Du sicherlich auch einige Hinweise zum Vorgehen. Ich schließe mich jedoch grundsätzlich den Kollegen an - den DNS Dienst auf dem neu zu promotenden DC zu nutzen macht sicherlich in Deiner Konstellation Sinn. Viele Grüße olc

Hi TL, hast Du schon einmal den "/PAE" Schalter angeschaut? The Svchost.exe process may end unexpectedly on a Windows Server 2003-based computer Viele Grüße olc

Hi, wenn ich mich nicht irre, nimmt Dir das File Server Migration Kit diese Arbeiten ab: Download details: File Server Migration Toolkit Ansonsten hier noch ein Link zum Thema: Ask the Directory Services Team : How to Back Up and Restore NTFS and Share Permissions Viele Grüße olc

Guten Abend, Jepp, da hattest Du Recht. :) Meine Aussage bezüglich der "meist vorhandenen" Script bezog sich auf die Speicherung der Adressen im AD. Aber wie gesagt, das hat sich ja erledigt, weil öffentlicher Ordner. Das war mein erstes Argument in meiner Antwort. :wink2: Pauschal läßt sich sicher nicht sagen, ob ADAM / AD LDS eingesetzt werden "sollte" oder Du die Daten einfach im AD speichern kannst. Aber 200 Firmen / Adressen klingt für mich im Moment eher nicht nach starker Abfragelast bzw. Speicherlast - oder greifen ein paar tausend Clients jede Minute auf alle Einträge zu? :) Von daher ist für dieses Szenario ADAM / AD LDS wahrscheinlich eher nicht notwendig. Ansonsten sind die Links von Nils sicherlich als Startpunkt für Dich interessant, sollte es doch in diese Richtung gehen. Viele Grüße olc

Hi Carsten, ich stelle mir gerade die Frage, ob es nicht sinnvoller wäre, die Benutzer als "konstante Größe" im Export zu verwenden, anstatt der Gruppen. Hintergrund für diese Überlegung ist, daß ein Benutzer Mitglied in diversen Gruppen sein kann - also würde ein Benutzer auch immer wieder im Export jeder Gruppe inklusive den Eigenschaften "disabled", "expired" etc. mit angezeigt werden. Du kannst aus "Benutzersicht" eine Aufstellung recht schnell mit den Quest AD PowerShell Addons realisieren: get-qaduser | format-list sAMAccountName, AccountExpires, AccountIsDisabled, AccountIsLockedOut, MemberOf Wenn Du trotzdem die Gruppen inklusive Ihrer Mitglieder und deren Eigenschaften exportieren möchtest, müßte man ein wenig mit der PowerShell scripten. Aber wie gesagt - der "andere" Weg macht meines Erachtens mehr Sinn. Viele Grüße olc

Hi, Wenn die Clients (also Drucker etc.) LDAP Clients sind, warum fragst Du nicht direkt die AD ab (die im Kern ja ein LDAP-Verzeichnis ist)? Installieren solltest Du ADAM (wie auch andere Dienste) eher auf einem eigenen System. "Ein Dienst pro Server" macht meistens Sinn. ;) Wenn Du sehr viele Kontakte hast, die Du über LDAP bereitstellen mußt, kann ADAM / AD LDS Sinn machen. Bei 200 Kontakten wäre aber wahrscheinlich die Anbindung an die AD sinnvoller, es sei denn, Du mußt an den Objekten Änderungen vornehmen bzw. ein eigenes Schema einsetzen. Das ist grundsätzlich richtig - obwohl ein "größeres" Script meist nicht notwendig ist, weil man oftmals "normale" und vorhandene AD Scripts verwenden kann. Wenn es sich nicht um öffentliche Ordner handelt, sondern um normale (AD-)Kontakte, lassen sich diese schmerzfrei mittels ADAMSync aus der AD in die ADAM / AD LDS Instanz synchronisieren. Viele Grüße olc

Hi Silver, DFSR in Version 2003 R2 und Windows Server 2008 bietet kein "distributed file locking". Schau einmal in die folgenden Beiträge, dort war es ab und an schon Thema: https://www.mcseboard.de/windows-forum-ms-backoffice-31/file-locking-fehlt-dfs-141871.html https://www.mcseboard.de/windows-forum-ms-backoffice-31/dfs-140762.html https://www.mcseboard.de/windows-forum-ms-backoffice-31/dfs-r-officedokumente-mehreren-usern-benutzen-127469.html Viele Grüße olc

N'Abend, Ok, dann ist der Gedanke mit dem Infrastructure Master hiermit offiziell verworfen. ;) Ok. Also neuer Benutzer in neuer OU geht zu kopieren? Kannst Du auch einen alten Benutzer einer alten OU in eine neue OU kopieren? Dann wäre eher auszuschließen, daß es ein Problem mit dem Schema bzw. den Schemaklassen gibt. Ich persönlich würde aufgrund dessen erst einmal auf ein Rechteproblem tippen, welches das Kopieren verhindert. Vergleiche doch einmal die mittels DSACLS exportierten Berechtigungen der alten OUs mit der neuen. Ist hier vielleicht etwas falsch "delegiert" worden? Ansonsten vergleiche weiterhin die LDIFDE Exporte der alten OUs mit dem der neuen OU - gibt es hier signifikante Unterschiede? Viele Grüße olc

Hi, hast Du das selbe Problem auch, wenn Du zwei neue OUs anlegst und Benutzer a) von einer alten OU in einer der neuen OUs kopieren möchtest b) einen vollkommen neuen Benutzer von einer der neuen OUs in die andere neue OU kopierst? Solltest Du keine Bedenken in Bezug auf die (Daten-)Sicherheit haben(!), exportiere doch einmal den Inhalt der Quell-OU und der Ziel-OU mittels LDIFDE und poste den Export im besten Fall auf einem "externen" Webserver und verlinke das dann hier: C:\> ldifde -d "OU=Deine_Quell_OU,DC=domain,DC=tld" -f C:\OU_export.ldf C:\> ldifde -d "OU=Deine_Ziel_OU,DC=domain,DC=tld" -f C:\OU_export.ldf Zusätzlich die ACL von einem Beispielobjekt: C:\> dsacls "CN=Dein_Benutzer,OU=Deine_Quell_OU,DC=domain,DC=tld" > C:\benutzer_ACL.txt Interessant wäre auch, ob Du die Probleme mittels AdInsight nachvollziehen kannst bzw. was genau auf dem entsprechenden DC in ADInsight "geloggt" wird, wenn Du die Operation durchführst. [EDIT] Achso, was mir gerade noch eingefallen ist: Du sagtest, daß es keine Probleme in den Eventlogs gibt. Ist das auf allen DCs der Fall? Was sagt ein DCDIAG? Konkret geht es mir um den Infrastructure Master - ist diese FSMO Rolle korrekt "online"? Geht es um einen Forest mit mehreren Domänen oder handelt es sich um einen Forest mit nur einer Domäne? [/EDIT] Viele Grüße olc