olc

Hallo und willkommen an Bo(a)rd, gleich zu Beginn der Hinweis, daß Doppelposts nicht so gern gesehen sind. Zumal der Kollege bzw. die Kollegen konkrete Lösungshinweise gegeben haben, worauf Du nicht weiter eingegangen bist. :suspect: Aber gut, was solls. Vielleicht kann man Dir ja trotzdem helfen... Bist Du denn die Lösungsansätze aus dem KB-Artikel Troubleshooting RPC Endpoint Mapper errors using the Windows Server 2003 Support Tools from the product CD durchgegangen? Viele Grüße olc

Hi Pathfinder, ich kenne mich mit dem ISA Server nicht aus - was benötigt der ISA Weblistener denn für ein Zertifikat (soll heißen: Welches Zertifikattemplate wird genutzt)? Normales Server-Authentication Zertifikat? Müssen Daten manuell im Request übergeben werden oder werden alle Daten aus der AD gelesen? Vielleicht bekommst Du das Zertifikat besser mit der MMC "certmgr.msc". Dort den Store für den Computer öffnen und im Personal Store den Certificate-Request Wizard nutzen, um das Zertifikat anzufordern. Viele Grüße olc

Hallo, schau mal in den Credential Manager: Step-By-Step: Maintain your passwords with Credential Manager Viele Grüße olc

Hi Baw, schön, daß es doch noch geklappt hat. :) Whoami /all zeigt auch verschachtelte Gruppenmitgliedschaften an, es werden die Gruppenmitgliedschaften expandiert. Jedoch gibt es bei Verschachtelungen mit Verteilergruppen Probleme (siehe oben). Eine andere Sache, die mir gerade noch eingefallen ist: Wo hast Du den whoami /all Export gezogen? Auf einem Client oder einem DC? Ich bin mir nicht 100% sicher, aber ich habe da so etwas im Hinterkopf, daß nur die dem ausführenden System bekannten Gruppen expandiert werden können. Vielleicht kann es hier Probleme geben, wenn es auf einem Client ausgeführt wird und ggf. nicht alle Gruppen korrekt auflösen kann. Aber wie gesagt, da bin ich mir nicht sicher. Käme auf einen Test an. ;) Viele Grüße olc

Hallo Erazor, um da eine Aussage machen zu können, sind die Informationen von Dir ein wenig spärlich. Ich würde vermuten, daß Du nur einige Minuten gewartet hast, bis Du den "Erfolg" geprüft hast? Ggf. war die Replikation der AD Daten (falls Du über Standortgrenzen hinweg arbeitest) als auch die Synchronisierung des DFS-R Dienstes der DFS-R Server mit der AD noch nicht durch und daher trat eine Verzögerung auf. Läuft es denn nun in der Zwischenzeit korrekt? DFS-R setzt DFS-N nicht voraus, sondern ist gänzlich unabhängig. Du mußt also keinen Namespace anlegen, um Daten über DFS-R zu replizieren. Falls möglich gib uns ein paar mehr Informationen zu Deiner Konfiguration und Deinem Vorgehen, dann kann man vielleicht auch helfen. ;) Viele Grüße olc

Hallo, es gibt eine ganze Menge von Tools oder Built-In Programmen, die das erledigen. Neben den oben genannten Möglichkeiten kannst Du beispielsweise auch "sc query" verwenden oder das PowerShell CMDlet "Get-Service". "Get-Service" halte ich für eine sehr charmante Variante *reim*, weil Dir die PowerShell diverse Möglichkeiten zur Formatierung der Ausgabe als auch zum Export bietet. Weiterhin kannst Du alle Eigenschaften der Dienste ausgeben lassen, wenn Du es denn möchtest (oder auch nur einige, wie von Dir gewünscht). Viele Grüße olc

Hi, ok, an die Doppelpunkte habe ich nicht gedacht. Aber man kann über einige (grausige) Umwege auch die Zeit formatieren. Schneller geht es jedoch zum Beispiel, wenn Du etwa die PowerShell verwendest, um Robocopy aufzurufen. Dann kannst Du mit "Get-Date" arbeiten, was sich recht leicht formatieren läßt: $a = get-date -uformat "%d.%m.%Y_%H.%M" Robocopy C:\logs E:\yourfolderhere\$a /MIR /R:3 /W:1 Es gibt aber sicherlich auch noch andere Lösungen. Viele Grüße olc

Hi, Christian hat nach der CRL im SubCA Zertifikat gefragt, weil dieser Pfad genau der Pfad ist, auf dem die CRL der RootCA veröffentlicht wird. Sperrst Du bei einem Problem mit der SubCA das Zertifikat derselben, kannst Du das nur auf der RootCA durchführen. Danach muß die CRL der RootCA veröffentlicht werden (an dem Verteilungspunkt / den Verteilungspunkten, die im SubCA Zertifikat angegeben wurden). Danach müssen sich die Clients die CRL ziehen. Hierbei wird eine Zeit lang ein CRL-Cache verwendet, so daß dies ein wenig dauern kann - es sei denn, Du löschst den Cache manuell (z.B. mittels certutil). Da ein Client zur Verifizierung der Zertifikatkette (der "certificate chain") alle Zertifikate der ausstellenden Instanzen durchläuft und deren CRLs prüft, wird er irgendwann (nach dem oben angesprochenen Ablauf des lokalen Caches) die aktuelle RootCA CRL bekommen und ab diesem Zeitpunkt ist das zurückgezogene SubCA Zertifikat ungültig - und damit alle Zertifikate, die durch die SubCA ausgestellt wurden. Viele Grüße olc

Hi Alphaman, was heißt für Dich "aufbereiten und darstellen"? Neben so einigen Kommandozeilen-Programmen oder VBScripts etc. kannst Du auch Monitoring Programme wie MOM o.ä. einsetzen. Obwohl MOM in diesem konkreten Fall sicherlich oversized und ein wenig teuer wäre. ;) Spontan fallen mir neben VBScripts das schon genannte Eventcomb, PsLoglist oder das PowerShell CMDlet "Get-Eventlog" ein. Alle diese Varianten bringen diverse Filtermöglichkeiten mit. Viele Grüße olc

Hallo, der Test bestätigt also im Grunde, daß kein Fehlverhalten vorliegt. Auch wenn Du scheinbar immer noch nicht überzeugt bist: Die betroffenen Benutzer sind mit Sicherheit Mitglied in einer der im KB-Artikel aufgeführten Gruppen. Ich bin meist eher zurückhaltend mit "definitiven" Statements - aber in diesem Fall bin ich mir recht sicher... ;) EDIT: Achso, eine Sache ist mir noch eingefallen: Unter Umständen laufen irgendwelche Scripts, die die Rechte ändern? Du könntest das zumindest auf die Schnelle im Ansatz gegenprüfen, indem Du in den Metadaten eines betroffenen Objekts nachprüfst, auf welchem System der nTSecurityDescriptor zuletzt geändert wurde. Ist es der PDCe der Domäne ist die Chance immer noch so hoch, daß es sich um Mitglieder geschützter Gruppen handelt. Ansonsten bleibt noch Auditing auf die Objekte, um den Verursacher festzustellen. Ich denke jedoch weiterhin, daß Du bei den Gruppenmitgliedschaften suchen solltest. ;) Viele Grüße olc

Hi Baw, Wie oben geschrieben siehst Du nicht alle Gruppenmitgliedschaften mit "whoami /all", wenn z.B. Verteilergruppen dazwischenliegen. Doch, grundsätzlich kann man dies ändern - wobei Du jedoch nur Accounts ausschließen kannst, nicht neue hinzufügen. Ohne jetzt gleich etwas zu ändern (!), kannst Du einmal das folgende Attribut überprüfen: CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=<domain>,DC=<tld> --> "dsHeuristics". Was für ein Wert hat das Attribut? Interessant ist die 16. Stelle von vorn gezählt. Wenn das Attribut keinen Wert hat ("not set"), ist das ebenfalls in Ordnung - es wurde in diesem Fall nichts geändert. Das weiß ich. ;) Wollte nur sicher gehen, daß das Vererbungsflag von Dir gesetzt wurde und zur Überprüfung der AdminCount auf "0" ist. Was Du auf jeden Fall schnellstmöglich wieder rückgängig machen solltest. ;) Ok, warten wir erst einmal ab. Viele Grüße olc

Hi Stub, das ist normal, denn der Namespaceserver ist ja nach Deinen Aussagen heruntergefahren. ;) Da Du den Namespace zu diesem Zeitpunkt nur auf diesem heruntergefahrenen Server hostest, kann die Konfiguration des Namespaces nicht gelesen werden, ergo RPC-Fehler. Starte den Fileserver 1 wieder und verteile den Namespace auch auf andere Server - danach sollte auch das Herunterfahren des Fileserver 1 keine Probleme mehr bereiten. Zum Thema: Windows Server How-To Guides: Teil 1 - Verteilung von Namespaces auf verschiedene Server - ServerHowTo.de Viele Grüße olc

Hi, vielleicht hilft Dir folgender Ansatz: Aber einmal anders gefragt - was ist der Hintergrund für Dein Anliegen? Vielleicht könnte man das Problem auch anders lösen? Viele Grüße olc

Hallo Baw, aller Wahrscheinlichkeit nach ist der Benutzer bzw. sind die Benutzer doch noch in einer der geschützten Gruppen - unter Umständen verschachtelt, nicht direkt. Wenn die Verschachtelung nicht über Verteilergruppen erfolgt, bekommst Du das - angemeldet als der betroffene Benutzer - mit einem "whoami /all" heraus --> zumindest in welchen Gruppen er Mitglied ist, jedoch nicht über welchen "Verschachtelungspfad". Erfolgt die Verschachtelung über Verteilergruppen wird es schwierig. Laß doch einmal das VB-Script aus Delegated permissions are not available and inheritance is automatically disabled durchlaufen - wenn der AdminCount tatsächlich wieder hochgezählt wird, kannst Du sicher sein, daß es an den Gruppenmitgliedschaften hängt. Das Script setzt übrigens auch gleich das Vererbungsflag zurück, d.h. die Vererbung ist wieder aktiv. Viele Grüße olc

Hi, schau einmal hier hinein, vielleicht hilft Dir das weiter? Unable to Remove Network Connection Created by AT Scheduler Viele Grüße olc

Hi, schon einmal "net use X: /DELETE" versucht, wobei "X:" für das entsprechende Laufwerk steht? Viele Grüße olc

Hi, ergänzend nur der Hinweis, daß spätestens ab 01.01.2009 alle "angefallen Daten" im Zuge der Vorratsdatenspeicherung 6 Monate lang vorgehalten werden müssen. Ab diesem Zeitpunkt wäre das Schreiben obsolet - sollte nicht einmal mehr das Bundesverfassungsgericht dafür sorgen, daß dieses Gesetz wieder gekippt wird. Hoffen wir das beste... :rolleyes: Viele Grüße olc

Hallo, zu der Kennwortsynchronisierung fällt mir leider auch nicht viel ein. Unter Umständen sollte MIIS das drauf haben, aber das ist für diese Anforderung sicherlich oversized. Ansonsten wäre vielleicht noch ein Ansatz den Benutzer nicht in der Domäne B anzulegen, sondern die User mit einer ADAM / AD LDS Instanz als sogenannte Proxy-Objekte einrichten, diese leiten die Anfrage dann an die Domäne A weiter. Gibt es einen bestimmten Grund warum die Benutzer in beiden Domänen vorhanden sind? Viele Grüße olc

Hi Nimo, siehst Du, das ändert gleich alles. ;) Eine gute Problembeschreibung ist "Gold wert"... Die ganzen genannten Datenreplikationslösungen kannst Du damit also vergessen, Du müßtest m.E. also entweder in Richtung Cluster gehen oder eine SQL-Replikationslösung einsetzen. Ist beides nicht so mein Gebiet, aber es wird sicherlich noch jemand antworten, der da kompetent ist. ;) Sollen die Server an einem Standort stehen oder an verschiedenen Standorten? Wird auf beiden Servern gearbeitet oder soll der zweite Server ausschließlich Backup Server sein? Viele Grüße olc

Hallo Thomas, schau einmal in folgenden Artikel: How to remove data in Active Directory after an unsuccessful domain controller demotion In der Boardsuche findest Du unter dem Suchbegriff "metadata cleanup" sicherlich auch eine Menge Beiträge. :) Viele Grüße olc

Hallo Nimo, das Thema ist hier im Board schon oft behandelt worden - letztendlich kommt es ganz auf Deine Anforderungen an, was Du am Ende einsetzen kannst / solltest. Dabei spielen natürlich neben den rein technischen Faktoren auch organisatorische Faktoren (was passiert bei einem Ausfall, wie oder wo soll weitergearbeitet werden etc.) genauso eine wichtige Rolle wie z.B. das Budget oder das vorhandene Know How. Vielleicht kannst Du ja noch einmal ein wenig genauer ausholen, was Du eigentlich genau erreichen willst. Ich denke grundsätzlich kann man sich dann zwischen zwei grundlegenden Techniken entscheiden: Cluster (bzw. Cluster ähnlich) oder Replikation von Daten / Backup Systeme etc. Je nachdem, für welche Richtung man sich dabei entscheidet, gibt es verschiedene Möglichkeiten und Produkte. Viele Grüße olc

...jepp, danke für die Präzisierung. Deshalb kann es durchaus sinnvoll sein, das VB-Script aus KB817433 ab und an mal laufen zu lassen. :D Viele Grüße olc

Hi, Mal abgesehen davon, daß diese Aussage nicht ganz korrekt ist, solltest Du es trotzdem einmal probieren. Aber es soll ja hier niemand zu seinem Glück gezwungen werden. ;) Viele Grüße olc

Hi Christoph, schau mal in die folgende Ergebnisliste: hdd 127 gb bios - Google-Suche Das Problem ist bekannt (über die Boardsuche würdest Du sicherlich auch einiges dazu finden ;) ) und läßt sich entweder mit einem Schalter im BIOS (falls das BIOS nicht allzu alt ist) und / oder ggf. der Anpassung des Registry Keys [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servic es\atapi\Parameters] "EnableBigLBA"=dword:00000001 beheben. Da die korrekte Größe von Deinem BIOS erkannt wird tippe ich auf den Regstry Key. Viele Grüße olc

Hi, ja, das Pendel. :) Mit hoher Wahrscheinlichkeit sind die betroffenen Benutzer in geschützten Gruppen - herausbekommen kannst Du das wie im o.g. Artikel beschrieben in den meisten Fällen mit einem "whoami /all" bzw. dem "Admincount=1". Grundsätzlich kannst Du natürlich (auch im Artikel beschrieben ;) ) die ACLs des AdminSDHolder Containers bearbeiten und somit den BESAdmin Account auch für die administrativen Benutzer einrichten, aber dabei sollte - wie ich im ersten Beitrag oben schrieb - das Sicherheitskonzept geprüft werden. Viele Grüße olc