olc

Hallo Mike, bei mir funktioniert der Link bzw. wird die Seite korrekt angezeigt- versuche es vielleicht einmal mit einem anderen Browser? Grundsätzlich "kannst" Du die Clients in die neue Domäne aufnehmen - oder wie oben angesprochen es mit der Beta Version versuchen. Aber das sollte dann gut getestet werden, da diese Version sicherlich noch nicht vollkommen ausgereift ist (und MS auch keinen Support bietet), sonst wäre es nicht mehr Beta. ;) Viele Erfolg und viele Grüße olc

Hallo Mike, wie schon richtig von Dir vermutet, unterstützt ADMT 3.0 Vista noch nicht. Dies wird erst ab ADMT 3.1 der Fall sein. Diese Version ist derzeit noch im Beta Stadium. Wenn Du es "riskieren" willst, kannst Du diese Version testen. Active Directory Blog : ADMT and Server 2008 Viele Grüße olc

Hi Andreas, Nein, genau das Gegenteil. ;) Du möchtest, daß der BlackBerry Benutzer BESAdmin in der ACL Deiner Benutzer auftaucht, d.h. z.B. auf dem Benutzer XY das Recht "Send As" besitzt. Wenn dieser Benutzer XY nun direkt oder verschachtelt in einer der geschützten Gruppen liegt, wird die ACL dieses Benutzers XY immer wieder vom AdminSDHolder zurückgesetzt und damit das Recht des Benutzers BESAdmin wieder entfernt. Man muß ein wenig "umdenken" - sobald das Prinzip jedoch klar ist, fällt es einem wie Schuppen von den Augen. ;) Wie oben beschrieben solltest Du Dich nicht auf den BESAdmin Account konzentrieren, sondern auf die Accounts, auf denen der BESAdmin das Recht "Send As" besitzen soll. Dann wirst Du feststellen, daß es auf einigen normalen Domänen-Benutzern klappt, auf anderen Benutzern mit erweiterten Rechten jedoch nicht. Genau das ist der Effekt des AdminSDHolders. :) Quatsch, dafür sind wir hier. :) Hast wohl gleich eine Suchmaschine Deiner Wahl benutzt? :D Viel Spaß dabei - ist eines der besten Bücher, die ich bisher gelesen habe; von einem der interessantesten Schriftsteller, die ich kenne (wenn wir denn das gleiche Buch meinen). :) Viele Grüße olc

Hi Andreas, der Benutzer ist wahrscheinlich Mitglied ist einer "geschützten Gruppe" (z.B. Domänen-Admin, Server-Operator o.ä.). Schau einmal hier hinein, das sollte Dir helfen: Windows Server How-To Guides: Der AdminSDHolder - ServerHowTo.de Anbei noch die Empfehlung (auch wenn es in vielen Umgebungen praxisfern erscheint), administrativen Benutzern kein Postfach oder ähnliches einzurichten bzw. eine strikte Rechtetrennung zwischen Arbeitsaccount und Adminaccount einzusetzen. Das derzeit verbeitetste Einfallstor für Schädlinge ist das Medium "E-Mail" (zumindest solange, bis der "Bundestrojaner" öfters eingesetzt wird :D ). Was also passiert, wenn der Benutzer, der sich per E-Mail einen Schädling einfängt, auch noch Domänen-Admin o.ä. ist, läßt sich schnell ausmalen... Und nebenbei kommt es bei einer korrekten Rechtetrennung erst gar nicht zum oben beschriebenen Problem. ;) Viele Grüße olc

Hi Howard, das war der Grund, warum ich oben nach den Subscriber Objekten im AD SYSTEM-Zweig und nach den Objekten auf dem DC Objekt selbst gefragt habe. ;) Es ist also doch so, daß die Subscriber Objekte zumindest auf dem DC Objekt nicht vorhanden sind. Daher ist es auch kein Wunder, daß die Regsitry Einträge nicht vorhanden sind - der DC weiß schlichtweg nichts von seiner Mitgliedschaft in der SYSVOL Replikationsgruppe. Schau dazu noch einmal in den oben geposteten Link hinein: Recovering missing FRS objects and FRS attributes in Active Directory Im Bereich "Recovering deleted FRS subscriber objects" findest Du ein Vorgehen, die Objekte wiederherzustellen, wenn Du kein Backup hast. Danach den NTFRS Dienst (oder besser gleich den DC) neu starten und Du solltest die Registry Einträge wieder sehen - wenn das Vorgehen korrekt durchgeführt wurde. Danach solltest Du trotzdem in jedem Fall ein D2 / D4 durchführen, nicht nur das D2. Aber wie oben schon angemerkt - wenn Du mit den anderen FRS Sets oder weiteren Diensten keine Probleme siehst, kannst Du auch den DC neu promoten. Wie es Dir lieber ist. ;) Achso, und nein, es reicht nicht den SYSVOL Stamm in der DFS MMC neu anzulegen. ;) Viele Grüße olc

Hi Stefan, Letztendlich regelt das die jeweilige Applikation. Das korrekte Verhalten wäre, ab dem Zeitpunkt einer abgelaufenen CRL keine Authentifizierung oder ähnliches mehr mit den entsprechenden Zertifikaten durchzuführen. Bei den meisten mir bekannten von MS hergestellten Applikationen bzw. bei allen MS Betriebssystemen ist das der Fall. Je nach Einsatzzweck ist das jeweilige Zertifikat dann nicht mehr nutzbar. Dieses Verhalten läßt sich jedoch auch deaktivieren. Aber wie gesagt entscheidet das die Applikation selbst. Die Offline-CA stellt nur die Zertifikate für die direkt untergeordneten Issuing-CAs aus. D.h. die Clients bekommen von der Offline-Root-CA keine Zertifikate, sondern nur von den Issuing-CAs. Diese Issuing-CAs veröffentlichen eigene CRLs, auf die der Client Zugriff haben muß - genauso wie auf die CRL der Root-CA, wenn die Kette komplett sein soll. Du wählst meist recht lange Intervalle zur CRL Veröffentlichung der Root-CA CRLs. Du mußt diese dann in dem Veröffentlichungszeitrahmen wieder temporär in Betrieb nehmen, die CRLs erzeugen und diese dann an einem oder mehreren Orten veröffentlichen, die auch nach dem erneuten Offline-nehmen der CA zugegriffen werden kann, so z.B. LDAP (AD), HTTP, FTP etc. Diese Orte stehen im Zertifikat der Issuing-CA, denn dieses wurde von der Root-CA ausgestellt. Alles in allem heißt das also, daß Du ab und an die Root-CA einschalten und die CRLs an den definierten Stellen veröffentlichen mußt (zusätzlich zu den CRLs der Issuing-CA). Certificate Revocation and Status Checking Viele Grüße olc

Hi, viel kann ich zu dem Thema nicht beitragen - jedoch denke ich, daß es für Deine Frage auch nicht die Antwort geben kann. Letztendlich ist das von viel zu vielen Faktoren abhängig, so z.B. auf welcher Betriebssystemplattform Du entwickeln möchtest bzw. für welche Plattform entwickelt werden soll, ob Du eher eine Scriptingsprache lernen möchtest oder eine hohe Programmiersprache, ob Du hardwarenah programmieren oder eher auf APIs gehen willst etc. pp. Das solltest Du zuerst ein wenig für Dich eingrenzen und dich dann einarbeiten. Die Grundlagen sind bei vielen "Sprachen" ja ähnlich. Grundsätzlich ist es - denke ich - im Moment keine schlechte Idee folgende Sprachen / Scriptssprachen näher in Betracht zu ziehen: - Java - Visual Basic / Visual Basic Script - C# / J# oder C++ bzw. alles rund um .NET im Windows Umfeld (bzw. damit auch Mono unter Linux) - Ruby - Python Einige davon sind OS übergreifend, damit bist Du also gut im Rennen. Konkret in Bezug auf die von Dir angesprochene Dinge wie Prozesse automatisieren / "Webseiten" bzw. Datenbankzugriffe ist das ganze .NET Thema (plus VBScript) sicherlich recht relevant, genauso wie Ruby (on Rails). Viele Grüße olc

Hi Howard, vielen Dank für Deine Rückmeldung. Ich gehe einmal davon aus, daß Du den Server schon einmal neu gestartet hast oder (konkret geht es mir um den NETLOGON und FRS Dienst)? Momentan fällt mir zu den fehlenden Registry Keys nicht viel ein - steht etwas in den Ereignisprotokollen des betroffenen DCs (insbesondere NTFRS Logs)? Es sollte diesbezüglich etwas geloggt werden, denn das FRS Set für den DC scheint ja in der AD vorhanden zu sein. Das sollte der DC bemerken und ggf. Fehler loggen. Ggf. macht auch ein Durchlauf von FRSDIAG Sinn um an weitere Informationen zum Problem zu kommen, siehe Download details: File Replication Service Diagnostics Tool (FRSDiag.exe) . Die Frage nach den zusätzlichen Diensten ging in die Richtung, daß Du unter Umständen am "schnellsten" wärest, wenn Du den DC neu promotest. Das sollte natürlich nur dann passieren, wenn Du keine Probleme mit den installierten Diensten siehst. Gerade mit den zusätzlichen FRS Sets für die Dateireplikation könnte das Probleme geben. Ggf. könntest Du das D2 auf höherem Level durchführen, dann werden jedoch auch die anderen FRS Replica Sets mit den Daten des anderen Server versorgt. Ich weiß nicht, ob das gewünscht ist. Ein Backup mit den korrekten Registry Settings steht nicht zur Verfügung, sonst hättest Du das schon erwähnt oder? Viele Grüße olc

Hi schmitty, öhm - das ist jetzt nicht böse gemeint, aber was soll uns Dein Post jetzt sagen? Daß Du einen Delay von 1x ca. 40 Sekunden und einen von ca. 30 Sekunden hast, ist sichtbar. Daß es sich höchstwahrscheinlich um ein Windows XP System handelt könnten wir uns vielleicht auch noch gerade so aus den Daten herausziehen. Seit wann das Problem existiert, ob es tatsächlich nur im Offline-Betrieb auftritt, ob die Ereignisprotokolle Fehler auswerfen, ob Du schon einmal ein WMI Logging gemacht hast (siehe Prozess C:\WINDOWS\system32\wbem\wmiprvse.exe), ob die Treiber des Systems aktuell und korrekt sind usw. usf. können wir nur schwer erraten. Weiterhin sind die Ausschnitte des UserEnv Logs (welche Du zeitlich gesehen auch noch verkehrt herum gepostet hast) nur bedingt aussagekräftig. Meist ist das ganze Log notwendig, um sich dem Problem zu nähern. How to ask a question Viele Grüße olc

Hi vadda, im verlinkten Hotfix Artikel sind zwei Sektionen recht interessant: Ich würde vermuten, daß die Disk Performance beim Schreiben der Daten schlichtweg nicht ausreicht. Wie alt ist der Server / der RAID Controller / die Platten? Vielleicht kannst Du eine Performance Messung in Bezug auf die Platten durchführen (z.B. perfmon auf die Disk Queue Length oder den SPA laufen lassen, siehe Download details: Server Performance Advisor). Viele Grüße olc

Hi Charity, die ADMX / ADML Dateien haben nichts mit den Security Templates zu tun. Das ist eine andere Baustelle. ;) Viele Grüße olc

Hi Flatlander, Access Based Enumeration (ABE) ist Dein Stichwort, siehe Windows Server 2003 Access-based Enumeration . Viele Grüße olc

Ah, ok - verstehe. Entschuldige, das hatte ich irgendwie nicht "wahrgenommen". Sind denn im AD die entsprechenden Subscriber Objekte überhaupt noch vorhanden (auf dem DC selbst als auch unterhalb von cn=domain system volume (sysvol share),cn=file replication service,cn=system,dc=a,dc=com)? Siehe Recovering missing FRS objects and FRS attributes in Active Directory Wenn nicht, ist das Problem ein wenig größer. Ggf. bist du mit einem DCPROMO des DCs schneller als mit dem manuellen neu anlegen der Objekte? Laufen noch weitere Dienste auf dem betroffenen DC? Viele Grüße olc

Hi Lukas, ich habe diesen Satz jetzt hier schon öfters von Dir gelesen ("bei uns ist das so"). Daß es bei "Euch" so ist sagt weder etwas darüber aus, ob es sinnvoll ist das so zu tun, noch sagt es etwas darüber aus, wie es der TO machen sollte. ;) Soll heißen: Technisch sollte man das schon sehr genau auseinanderhalten und prüfen, welche Konfiguration in welcher Umgebung Sinn macht. Oder heißt Deine Firma zufällig "Contoso"? :p BTW: Vor Windows Server 2008 kann es gerade in Umgebungen mit vielen Zielen und Namespaces durchaus ratsam sein, die Namespaces gerade eben nicht AD-integriert zu fahren (auch wenn das für den TO sicherlich eher nicht zum Problem wird, bei der Größenordnung). Viele Grüße olc

Hi, dann versuche es einmal mit dem D2 / D4. Damit sollte alles auf dem entsprechenden System neu aufgebaut werden. Viele Grüße olc

Hi, @caputo: Wie LukasB schon schrieb, werden lediglich die Ziele von dem / von den Namespaceservern ausgelesen, nicht etwa die Daten "umgeleitet". Sehr schön nachvollziehen kannst Du das, indem Du nach einem Zugriff auf das Netzlaufwerk ein "dfsutil /pktinfo" auf der Kommandozeile absetzt. Du bekommst dann alle theoretisch möglichen Ziele ausgegeben (in Deinem Fall pro Target / Share ja nur eines) mit ein paar Zusatzinformationen. @LukasB: Da es einen Timeout bis zum Refresh des Targets gibt, muß es nicht unbedingt ein Problem sein, wenn der WAN Link für einen bestimmten Zeitraum einbricht. Problematisch wird es erst nach einiger Zeit oder z.B. beim Neustart eines Clients. Weiterhin ist es eine weit verbeitete falsche Annahme, daß die Integration des Namespaces in die AD die Namespaceserver ablöst. Das ist nicht der Fall. Steht (um bei Deinem Beispiel zu bleiben) am entsprechenden Standort ein DC jedoch kein Namespaceserver, ist bei einem Ausfall des WAN Links und z.B. einem Neustart eines Clients kein Zugriff mehr auf den Namespace möglich. Da nützt der DC nichts, denn dieser liefert dem Client nur die Namespaceserver. Das ist zwar oftmals trotzdem sinnvoll, um die Last nicht auf einen einzelnben Namespaceserver zu schicken, hat jedoch nicht unbedingt etwas mit der von Dir angesprochenen Ausfallsicherheit zu tun. Erst wenn es mehrere Namespaceserver in der Umgebung gibt, die den selben Namespace hosten, ist Ausfallsicherheit für die Namespaces gegeben. Windows Server How-To Guides: Teil 1 - Verteilung von Namespaces auf verschiedene Server - ServerHowTo.de Viele Grüße olc

...na mal schauen ob es gut funktioniert. Ich kenne diese Ruhelosigkeit. ;) Die Frage ist, warum die Vererbung deaktiviert war? Meines Wissens sollte diese standardmäßig aktiviert sein. Wurde da manuell etwas geändert? Unter Umständen ist dieses Verhalten ja gewünscht? Viele Grüße olc

Hi Edgar, versuche es einmal in der Art (ungetestet): '******************************************************************** '* '* File: ResetAccountsadminSDHolder.vbs '* Created: November 2003 '* Version: 1.0 '* '* Main Function: Resets all accounts that have adminCount = 1 back '* to 0 and enables the inheritance flag '* '* ResetAccountsadminSDHolder.vbs '* '* Copyright (C) 2003 Microsoft Corporation '* '******************************************************************** Const SE_DACL_PROTECTED = 4096 On Error Resume Next Dim sDomain Dim sADsPath Dim sPDC Dim oCon Dim oCmd Dim oRst Set oRst = CreateObject("ADODB.Recordset") Set oCmd = CreateObject("ADODB.Command") Set oCon = CreateObject("ADODB.Connection") Dim oRoot Dim oDomain Dim oADInfo Dim oInfo Set oADInfo = CreateObject("ADSystemInfo") Set oInfo = CreateObject("WinNTSystemInfo") sPDC = oInfo.PDC & "." & oADInfo.DomainDNSName oCon.Provider = "ADSDSOObject" oCon.Open "Active Directory Provider" oCmd.ActiveConnection = oCon Set oRoot = GetObject("LDAP://rootDSE") sDomain = oRoot.Get("defaultNamingContext") Set oDomain = GetObject("LDAP://" & sDomain) sADsPath = "<" & oDomain.ADsPath & ">" [b][color="Red"]oCmd.CommandText = "SELECT ADsPath FROM 'LDAP://" & sPDC & "/" & sDomain & "' WHERE objectCategory='computer' and objectClass = 'computer'" [/color][/b]Set oRst = oCmd.Execute [b][color="Red"]WScript.Echo "searching for computer objects in " & sDomain[/color][/b] If oRst.RecordCount = 0 Then WScript.Echo "no accounts found" WScript.Quit End If Do While Not oRst.EOF WScript.Echo "found object " & oRst.Fields("ADsPath") If SetInheritanceFlag(oRst.Fields("ADsPath")) = 0 Then WScript.Echo "Inheritance flag set" [b][color="Red"]'* entfernt If SetAdminCount(oRst.Fields("ADsPath"), 0) = 0 Then WScript.Echo "adminCount set to 0"[/color][/b] WScript.Echo "==========================================" oRst.MoveNext Loop Private Function SetInheritanceFlag(DSObjectPath) Dim oSD Dim oDACL Dim lFlag Dim oIADs Set oIADs = GetObject(DSObjectPath) Set oSD = oIADs.Get("nTSecurityDescriptor") If oSD.Control And SE_DACL_PROTECTED Then oSD.Control = oSD.Control - SE_DACL_PROTECTED End If oIADs.Put "nTSecurityDescriptor", oSD oIADs.SetInfo If Err.Number <> 0 Then SetInheritanceFlag = Err.Number Else SetInheritanceFlag = 0 End If End Function [b][color="Red"]'* entfernt Private Function SetAdminCount(DSObjectPath, AdminCount) '* '* Dim oIADs '* Dim iAdminCount '* '* Set oIADs = GetObject(DSObjectPath) '* '* iAdminCount = oIADs.Get("adminCount") '* '* If iAdminCount = 1 Then iAdminCount = 0 '* '* oIADs.Put "adminCount", iAdminCount '* oIADs.SetInfo '* If Err.Number <> 0 Then '* SetAdminCount = Err.Number '* Else '* SetAdminCount = 0 '* End If '* End Function [/color][/b] Das sollte bei allen in der Domäne vorhandenen Computer Objekten das "Inheritance Flag" setzen. Viele Grüße olc

Hi Edgar, vielleicht hilft Dir der folgende Link weiter? Jorge 's Quest For Knowledge! : Script to set/clear INHERITANCE flag on AD objects Als Grundlage kannst Du auch das folgende AdminSDHolder VBScript verwenden. "Einfach" die Objekttypen ändern und die Bedingung "Admincount=1" entfernen etc.: Delegated permissions are not available and inheritance is automatically disabled Vorher testen. :p Viele Grüße olc

Hi Edgar, ohne an dieser Stelle auf die Sicherheitsbedenken einzugehen kannst Du verschiedene Wege gehen. Es stehen mehrere GUI Möglichkeiten als auch einige Scripting Möglichkeiten offen. Exemplarisch zwei mögliche Wege: Ich gehe davon aus, daß die Computer Objekte verteilt in der Struktur liegen? Entweder auf CN / OU Level oder falls nötig auf dem Domain Level in der AD User & Computer MMC Rechtsklick --> "Eigenschaften" --> "Sicherheit" Tab --> "Erweitert" --> "Hinzufügen" --> in Deinem Fall dann "Domänen-Computer", "Domänen-Benutzer" und ggf. "Domänen-Admins" etc. hinzufügen (oder welche Sicherheitsprinzipale auch immer) --> dann im folgenden Dialog den Tab "Eigenschaften" wählen, "Computer"-Objekte als Objekttypen auswählen und die Lese- / Schreibberechtigung für die "Eigenschaften" hinzufügen. Auf der Kommandozeile: dsacls "DC=domain,DC=tld" /I:S /G "DOMAIN\Domänen-Benutzer":WPRP;description;computer Ggf. Gruppennamen noch anpassen (deutsch / englisch) und die weiteren gewünschten Gruppen neben den Domänen-Benutzern hinzufügen. [EDIT] Daim war schneller... :) [/EDIT] Viele Grüße olc

Hi Canni, hast Du denn vorher die Quest AddOns installiert? Siehe PowerShell Commands for Active Directory Quest Software Viele Grüße olc

Hi, sollten die Server dicht beieinander stehen und Ihr problemlos in den Serverraum kommen (räumlich gesehen), kannst Du auch die "Hardware Variante" verwenden: Einfach die beiden Fileserver vom Netzwerk trennen und direkt miteinander per Netzwerkkabel verbinden. Viele Grüße olc

Hi, wenn es Dir nur um das Startmenü geht, kannst Du auch die Tastenkombination <Ctrl> + <Esc> verwenden. Ansonsten ist der Tipp von ITHome Gold wert. ;) Viele Grüße olc

Hallo, die Priorität der DNS Einträge würde alle Clients / Benutzer der Site betreffen. Du kannst keinen Logon-DC erzwingen. Du könntest jedoch den DC beispielsweise mit einem Client in ein eigenes Subnetz packen. Dann wird sich der Benutzer (der sich am entsprechenden Client anmelden muß) standardmäßig bevorzugt am DC der eigenen Site anmelden. Anders gefragt: Was genau ist das Problem? Die Intra-Site Replikation sollte im Normalfall doch recht schnell durch sein oder? Über was für eine Umgebung sprechen wir? Viele Grüße olc

Hallo, was meinst Du genau mit "Netzwerk fällt aus"? Haben die ausfallenden Clients Gemeinsamkeiten (Konfiguration, Aufstellungsort etc.)? Sind Fehlermeldungen in den Eventlogs zu finden? Etc. pp. - hol mal ein wenig in Bezug auf die Situationsbeschreibung aus. ;) Viele Grüße olc