olc

Hi, was sagt ein "nslookup fihel-dc-02.poyry.com" und "nslookup poyry.com"? Die zurück gelieferte IP-Adresse 151.105.19.45 zum DC "fihel-dc-02.poyry.com" ist korrekt? Steht abgesehen von der lokalen Firewall zwischen den beiden Systemen unter Umständen eine zusätzliche Firewall mit Portbeschränkungen? Siehe dazu auch Aktives Verzeichnis Blog : Windows Server 2008 DCPROMO: 1722 The RPC server is unavailable. Viele Grüße olc

Hi, da es keine Domänenclients sind, könntest Du es "manuell" mit certutil als auch (falls möglich) gescripted importieren. Schau Dir dazu einmal den Befehl "certutil -addstore" und die dazu möglichen Optionen / Schalter an. Viele Grüße olc

Hi, CSVDE kann scheinbar keine "paged queries". Versuche es einmal mit DSQUERY / DSGET in der Windows Server 2008 Version. Unter Umständen ist in 2008 ja auch CSVDE entsprechend erweitert / gefixt - habe es in der Version noch nicht eingesetzt. Viele Grüße olc

Hallo, was genau meinst Du mit "an bestimmten Stellen"? Einen bestimmten Speicherort (z.B. Trusted Root oder Personal)? Beim Autoenrollment einer Enterprise PKI legt im Grunde das Template den Speicherort fest - so einfach läßt sich das nicht beeinflussen. Geht es nicht um das Autoenrollment wären beispielsweise Gruppenrichtlinien oder Scripts eine Möglichkeit, je nachdem ob die Zertifikate erst angefordert werden müssen oder ob diese schon vorliegen. Es gibt diverse Alternativen, je nach Anforderung. Was genau möchtest Du denn erreichen bzw. was ist der konkrete Hintergrund für die Frage? Dann lassen sich Lösungsansätze besser fokussieren. Viele Grüße olc

Hi, was sagt denn nun ein erneutes nslookup auf die Domäne, von einem Problemclient ausgeführt? Auf den Servern ist nicht zufällig auch eine Firewall aktiviert (und nicht nur auf den Clients)? In dem oben genannten KB-Artikel sind einige Punkte aufgeführt, hast Du die alle geprüft? Viele Grüße olc

Hi, es gibt ein, zwei Tools, die die Tokensize auslesen können, so etwa http://www.microsoft.com/downloads/details.aspx?familyid=4A303FA5-CF20-43FB-9483-0F0B0DAE265C . Im Grunde reicht jedoch auch ein schlichtes "whoami /all". Dann kannst Du die Gruppen einfach "zählen". Bedenke dabei, daß es schon ab einer geringeren Menge an Gruppenmitgliedschaften als 1.024 Probleme geben kann. Daher erklären sich auch ggf. die Probleme mit 140 Gruppen (BTW: direkte Gruppenmitgliedschaften oder verschachtelt weitere?). Wie gesagt, schau Dir einmal ein "whoami /all" an. Viele Grüße olc

Hi, einige Attribute kannst Du problemlos ändern, den CN jedoch nicht so einfach, siehe: Den CN zu ändern würde auf einen kleinen "Hack" hinaus laufen, den man nicht in einer produktiven Umgebung einsetzen sollte. Zumal es ein, zwei Folgeprobleme bei so einer Änderung geben kann. Viele Grüße olc

Hi, einfach den von mir oben angegegeben Link anklicken, dort steht, wie es aktiviert wird. ;) Viele Grüße olc

Hi Kweldulf, beide Aufgabn sollten sich im Normalfall auch mit dem Taskplaner gut einrichten lassen. Ab Vista / 2008 ist das builtin sogar sehr komfortabel mit bestimmten Triggern möglich, so auch beispielsweise eine Aktion bei Abmeldung. Ich würde wahrscheinlich diesen Weg gehen - damit umgehst Du die Script-Probleme bei "offline Anmeldung" komplett. Viele Grüße olc

Hi, mir ist die Anforderung noch nicht ganz klar - was genau soll auf welcher Seite des Tunnels eingesetzt werden? Grundsätzlich bietet Windows Server 2003 ja die von Dir angesprochenen VPN Funktionen - wenn das nicht funktioniert, gibt es unter Umständen eine Menge Alternativen, die nichts kosten (so etwa OpenVPN oder IPCop mit IPSec OpenSwan Implementierung, M0n0wall etc.). An "kostenfreier" VPN Software mangelt es also nicht, relevanter sind die konkreten Anforderungen. Daraus ergibt sich, ob eine der Lösungen für Euch paßt. Vielleicht kannst Du das Vorhaben / die Anforderungen noch einmal etwas genauer beschreiben? Viele Grüße olc

Hi, ein "Caching" ist meines Wissens nicht möglich. Alternativ könnten die Scripts in der lokalen Gruppenrichtlinie definiert werden - obwohl ich mir das aus Gründen der Verwaltung sehr genau überlegen würde. Was genau tun die Scripts denn? Vielleicht gibt es ja eine andere Lösung. Viele Grüße olc

Hi, weißt Du zufällig noch, welche Einstellungen in der Policy eingestellt waren? Kann es sein, daß in der Policy Dateien fehlen, so z.B. die Datei "Registry.pol", falls Administrative Templates für Registry Settings genutzt wurden? Schalte doch einmal das GPEDIT.MSC Logging ein und reproduziere das Problem. Dann sieht man im GPEdit Logfile, was der genaue Fehlercode ist. Die Meldung muß nicht unbedingt auf die tatsächliche Fehlerursache hindeuten: Enabling Logging for Group Policy Editor Viele Grüße olc

Hi, jepp - da hast Du natürlich Recht. Wenn tatsächlich das Benutzerprofil ausgetauscht wurde, ist die NTUSER.DAT und damit der Benutzerteil der Registrierung auch neu. Nichtsdestotrotz können die Einstellungen zum Beispiel über Logon-Scripts etc. wieder herein kommen, daher würde ich es in jedem Fall trotzdem prüfen. Viele Grüße olc

Hi, wie gesagt, schau beispielsweise wie oben erwähnt auf Technet vorbei oder etwa direkt in die ADM bzw. ADMX Dateien. Dort findest Du den Schlüssel, der beim Setzen des entsprechenden Settings geschrieben wird. Viele Grüße olc

Hi, höchstwahrscheinlich paßt die inetres.ADML Datei nicht zur ADMX Datei. Wenn Du Versionen der ADMX Dateien änderst, dann solltest Du auch gleich die ADML Dateien in gleicher Version einsetzen. Im allerbesten Fall ersetzt Du gleich alle ADMX und ADML Dateien im central store, anstatt einen Mix aus unterschiedlichen Versionen dort zu speichern. Das macht die Administration weit übersichtlicher und ggf. auch weniger fehleranfällig. Die letzten ADMX / ADML Dateien kamen von Windows Server 2008 (SP2). Die W7 / 2008 R2 Templates sind noch nicht RTM, ich persönlich würde sie also noch nicht einsetzen. Viele Grüße olc

Hi, unter Umständen ist direkt in der Benutzerregistrierung / HKEY_USER die Einstellung festgelegt. Schau doch einmal auf Technet oder über die ADM / ADMX Dateien, wohin die Einstellungen geschrieben werden (ggf. einmal den Policy Zweig "nicht beachten", sondern den normalen Registry-Zweig einsetzen). Vielleicht findest Du dort ein "fest verdrahtetes" Setting. Viele Grüße olc

Hallo, die Hälfte Deiner vermeintlichen Probleme sind nachvollziehbar, denn Du führst die Aktionen in unterschiedlichen Kontexten aus. Bisher konnte ich das Problem mit dem langsamen Kopieren nicht nachvollziehen, bei mir laufen über den Taskplaner ausgeführte Script wunderbar. Aber so ein wenig scheint es mir auch, als ob Du hier eher Deinen persönlichen Frust loswerden möchtest, anstatt eine konkrete Problemlösung dabei herüber kommt. ;) Von daher läßt sich kaum etwas dazu sagen außer, daß das von Dir beobachtete Verhalten eher nicht der "Normalfall" in einer Windows Server 2008 Umgebung ist. Viele Grüße olc

Hallo blurrrr, ich habe schon mehr als einmal eine CA in Betrieb genommen - bisher hatte ich noch keine Probleme mit den Authentifizierungsmethoden nach einer standardmäßig durchgeführten Installation. Bevor man also alles auf den Dienst schiebt, sollte man eventuell auch eigene Fehler in Betracht ziehen oder? ;) Vielen Dank für Deine Rückmeldung und viele Grüße olc

Hi, oft frage ich mich, ob ich mich einfach schlecht ausdrücke oder ob einige meiner Beiträge einfach nicht korrekt gelesen werden. So auch in diesem Fall - das, was Du schreibst, nimmt nicht wirklich Bezug auf meine Argumente. Die Binaries haben beispielsweise nicht unbedingt etwas mit dem Eintrag in der MSI-Datenbank zu tun. Zusätzlich war "das Verpennen" gemünzt auf den vermeintlichen Workaround, nicht auf das Updatepaket. Weiterhin ist mir der Inhalt des neuen Installationspaketes bekannt. Ok, ich denke alles Notwendige ist nun schon mehr als einmal gesagt worden. Falls ich mich auch diesmal undeutlich ausgedrückt haben sollte, dann gebt mir bitte einen kurzen Hinweis per PN. Danke und Gruß olc

Hi, ich denke nicht, daß das "verschlafen" wurde - vielmehr werden wahrscheinlich keine "Workarounds" angeboten, die später zu Problemen führen können. Die von mir oben angesprochenen Probleme kannst Du zum jetzigen Zeitpunkt auch nicht feststellen, denn es gibt noch kein "Nachfolge-Update". Aus diesem Grund mein Hinweis, daß man sich das genau überlegen sollte. Was, wenn der neue Hotfix mit andere KB-Nummer veröffentlicht wird? Was, wenn es einmal eine Aktualisierung des Updates gibt? Wie gesagt, jeder kann und muß selbst entscheiden, ob er dieses "Risiko" eingeht. Es muß jedoch klar sein, daß eben ein Risiko besteht und nicht unreflektiert nur der Hinweis auf einen möglichen Workaround gegeben wird. Daher mein Einwand. Viele Grüße olc

...wobei zu klären wäre, wie sich ein auf diesem Wege installiertes Update verhält, wenn beispielsweise das aktualisierte KB943729 Paket (oder ein neuer KB / neues Update für die CSEs) zur Verfügung gestellt wurde. Ich vermute es gibt einen Grund, warum dieser Umweg nicht als "offizieller Workaround" von MS geliefert wurde. Von daher sollte man sich schon überlegen, ob man diesen Weg geht. Viele Grüße olc

Hi, danke für Deine Rückmeldung. Schön, daß es geklappt hat. :) Viele Grüße olc

Hi, ist doch genau das, was ich oben geschrieben habe... ;) Sind unter Umständen Gruppenrichtlinien auf dem CA-Server aktiv, die die Netzwerkschnittstellen "einschränken"? Kandidaten wie "Zugriff vom Netzwerk auf diesen Computer verweigern: [...] ANONYME ANMELDUNG [...]"? Das kann beispielsweise beim IIS zu Problemen führen. Viele Grüße olc

Hi, schau einmal in den Credential Manager: Start --> Ausführen --> "control keymgr.dll". Sind dort unter Umständen die Kennwörter (falsch) gespeichert? Viele Grüße olc

Hi, neben DFSR können auch kleinere Tools funktionieren. So etwa ROBOCOPY o.ä. Soll die Datenübertragung regelmäßig / zyklisch stattfinden oder einmalig? Über welche Betriebssysteme sprechen wir hier? Viele Grüße olc