olc

Hallo Frank, soweit ich weiß gibt es keine andere Möglichkeit. Remote könntest Du Dich mit der Registrierung der Zielclients verbinden, sofern diese eingeschaltet sind und dann den Schlüssel löschen. Viele Grüße olc

Hi Frank, schau einmal hier hinein, das sollte das Problem erklären bzw. lösen: Aktives Verzeichnis Blog : Windows cannot find the local profile ? using temporary profile War übrigens Platz 1 der Suchmaschine meiner Wahl... ;) Platz 2 war dann: A temporary profile is loaded after you log on to a Windows Vista-based system Viele Grüße olc

Hi, Ich dachte, genau das hätte ich geschrieben... ;) Aber es freut mich, daß es geklappt hat. :) Viele Grüße olc

Hallo Anne, könntest Du noch eine Ausgabe von IPCONFIG /ALL eines anderen Clients posten, der korrekt aufgenommen werden konnte? Und das NSLOOKUP nach der Domäne, das den Timeout liefert. :) Viele Grüße olc

Hallo, mir ist nicht ganz klar, warum Du Dich hier scheinbar angegriffen fühlst (oder es mir zumindest so vorkommt), daher belasse ich es nun bei der folgenden abschließenden Bemerkung in diesem Thread: Es ist durchaus üblich, sich eine Lizenz nicht für eine konkrete Hardware zu kaufen, sondern diese auch nach der Anschaffung neuer Hardware erneut zu verwenden (sofern das alte System nicht mehr in Betrieb ist). Wenn Du es persönlich anders handhabst, ist das in Ordnung - jedoch sollte man diesen Weitblick durchaus in eine entsprechende Überlegung einbeziehen. So funktionieren wirtschaftlich sinnvolle und nachhaltige Anschaffungen nun einmal. Ansonsten sind 250 MB = 250 MB. Das mag bei 4 GB RAM nicht die Welt sein, ist aber in anderer Sichtweise der Shared Memory für die Grafikkarte, den man also "verschenkt", wenn man 32-Bit Systeme verwendet. Fassen wir also zusammen: Deine bisherige Argumentation beschränkt sich darauf, auf die nicht vorhandene Kompatibilität von Programmen zu zielen, was nicht ganz korrekt ist. Der "RAM Verlust" durch 64-Bit ist wie angesprochen nicht wirklich relevant, denn man kann in jedem Fall bei x64 Systemen noch immer mehr RAM nutzen als bei x86, falls dies notwendig wird. Weiterhin sind zukunftssichere Entscheidungen nicht durch kurfristiges Handeln geprägt - also auch kein Gegenargument. Bleibt die Frage nach den Treibern - und die hatte ich aufgeworfen. Nichts für ungut, aber ich denke, daß damit die Antworten zusammengefaßt sein sollten, meine Meinung ist denke ich auch klar geworden und der TO kann nun entscheiden, welcher Argumentation er folgt. Viele Grüße olc

Hi, da hast Du zwar grundsätzlich Recht, jedoch ist dieser Teil der Speicherauslastung weit geringer, als daß es zu einem "Auffressen" der 500MB mehr kommen würde. Weiterhin entkräftet es auch nicht meine anderen Argumente. Und "zukunftssicher" hat nicht nur etwas mit der aktuell eingesetzten Hardware zu tun, daher kommt das Wort "Zukunft" darin vor. ;) Viele Grüße olc

Hallo, grundsätzlich ist es korrekt, daß nur einige Programme von x64 profitieren sofern sie eben recht viel RAM benötigen (z.B. mehr als 3GB für einen Prozess). Ansonsten ist es aber nicht korrekt, daß x64 grundsätzlich "schneller" ist als x86. Es ist nicht korrekt, daß mehr Programme auf x86 laufen, denn wenn x86 Programme auf x64 Systemen installiert werden, dann laufen diese schlichtweg im 32-Bit Modus. Der einzige "Vorteil", den Du von 32-Bit haben kannst, ist eine derzeit teilweise bessere Versorgung mit Treibern von 32-Bit Betriebssystemen. Insbesondere ältere Hardware bringt häufig keine x64 Treiber mit. Das kann dann mit einem x64 System zum Problem werden. Wenn Du die kompletten 4GB RAM nutzen möchtest, dann mußt Du zwangsweise auf x64 setzen, x86 kann mit Boardmitteln höchstens ca. 3 1/2 GB RAM ansprechen. Die Wahl ist also eher anhand der zu unterstützenden Hardware zu treffen, als an der Software. Ich persönlich würde heutzutage auf x64 setzen, obwohl ich das vor einiger Zeit auch noch mit "Schmerzen" verbunden habe mußte ich feststellen, daß es weit unproblematischer ist als gedacht. Und vor allen Dingen "zukunftssicherer". Viele Grüß olc

Hallo Anne und willkommen an Board, :) hier stimmt am Client etwas nicht: Netzwerkkabel etc. steckte im Moment des Exports? Viele Grüße olc

Moin, nicht böse gemeint, aber wenn man Dir nicht jede Information aus der Nase ziehen müßte, dann wäre man schneller dabei, Dir zu helfen. ;) Im Moment wissen wir noch nicht einmal das Betriebssystem... Sonst hätte ich Dir einen Link zur letzten DFSR.exe bzw. DFSRS.exe gepostet. Daher müßtest Du diese selber heraussuchen und auf beiden Servern installieren. Ich nehme nicht an, daß es ein Problem der DFSR Version ist, aber ich würde es zumindest ausschließen. Zusätzlich wäre eine Liste der gesamten auf dem System installierten Software sinnvoll. Wenn auf dem einen Server wie Du sagst nicht einmal geloggt wird, daß die Kommunikation eingestellt ist, dann kann dafür eigentlich nur ein Deadlock des DFSR Dienstes oder eben ein Filtertreiber verantwortlich sein. Du könntest einmal die DFSR Debug Logs prüfen, ob Du irgendwelche Fehler findest, die auf ein Problem hindeuten. Achso: Und bitte sage mir, daß wir hier nicht über dieselben Systeme sprechen: https://www.mcseboard.de/windows-forum-ms-backoffice-31/upgrade-2008r2-4-160185.html :shock: Viele Grüße olc

Hi, dann würde ich einmal ggf. das NIC-Teaming auf beiden Systemen auflösen (falls vorhanden), die Netzwerkkartentreiber aktualisieren und ggf. auch noch einmal prüfen, ob eine Firewall installiert ist. Dann die Server neu starten und schauen was passiert. Stehen die Systeme am gleichen Standort / Netzwerksegment oder liegen Router und eventuell ein VPN dazwischen? Viele Grüße olc

Ok, dachte ich mir fast schon, daher meine Einschränkung. ;)

Hi, DFSN hat nichts mit dem Problem zu tun, DFSR und DFSN sind vollkommen unabhängig. Ist ein Virenscanner installiert? Falls ja, würde ich diese testweise einmal deinstallieren (auf beiden Systemen) und schauen, ob das Problem dann immer noch auftritt. Viele Grüße olc

Hi, schön, daß es remote klappt. :) Installiere testweise doch auf dem problematischen System einmal die GPMC neu - vielleicht hilft das ja schon. Viele Grüße olc

Hi, ich weiß nicht, ob das Script oben in den Links genannt wurde, aber falls nicht: Mach es am besten über das folgende VBScript, das ist recht "fehlertolerant": Error message when you run the "Adprep /rodcprep" command in Windows Server 2008: "Adprep could not contact a replica for partition DC=DomainDnsZones,DC=Contoso,DC=com" Viele Grüße olc

Hi, versuche es einmal mit: - NIC Teaming ggf. auflösen - der neue Netzwerkkartentreiber ist von welchem Datum? - testweise TCP / Chimney / Offloading RSS deaktivieren - Virenscanner deinstallieren Viele Grüße olc

Hi, es gibt diverse Methoden, das Thema rein technisch zu erschlagen. Mittlerweile gibt es neben den Fingerabruck-Scannern auch Iris-Scanner oder Venen-Scanner, die die Venen in der Hand als "Secret" nutzen. Aber einmal ganz ehrlich: Ihr versucht hier ganz offensichtlich ein rein menschliches Problem ausschließlich mit Technik zu lösen. Meiner persönlichen Erfahrung nach gelingt das nie (und damit meine ich wörtlich "nie", also 100% nicht). Aus den oben von den Kollegen schon angesprochenen Punkten hast Du zumindest in Bezug auf Deine konkrete Fragestellung kaum Vorteile zwischen einer Smart Card Implementierung oder der Implementierung von Biometrie. Es gibt Gründe, die Kohle für Biometrie einzusetzen, aber die würde ich bei Deinem genannten Hintergrund für das Vorhaben nicht sehen. Es sei denn, Ihr habt zu viel Geld. ;) Viele Grüße olc

Hi whiggy, bestens, vielen Dank für die Rückmeldung. :) Viele Grüße olc

Hi Soapp, vertrauenswürdig sind erst einmal nur die Root CA Zertifikate, die Du in Deinem lokalen Trusted Root CA Speicher hast. Es gibt da Ausnahmen, aber das führt hier zu weit. Die Intermediate CAs müssen theoretisch nicht im lokalen Intermediate CA Speicher liegen - solange bei der "certificate chain" Überprüfung am Ende eine vertraute Root CA steht und die AIAs der Intermediate / Sub CAs erreichbar sind. Als Best Practice bei internen CAs sollten jedoch beide internen Zertifikate (Root als auch Sub / Issuing CA) in den entsprechenden lokalen Speichern liegen - das verkürzt die Abfragen und ist "ausfallsicherer", denn es müssen dann nicht bei jeder Validierung, die nicht aus dem Cache stattfindet, die AIA URLs geprüft werden. Der Import der internen Root und Sub / Issung CA Zertifikate passiert übrigens automatisch, wenn Du die Zertifikate wie in den meisten Domänenumgebungen üblich in den Configuration NC (Services --> Public Key Services --> "Certification Authorities" bzw. "AIA" Container) importierst, denn von dort werden die Zertifikate über die GPO-Engine in den lokalen Speicher des Clients gezogen. Hierbei ist "Certification Authorities" die Root CA und im AIA Container liegen die Root CA als auch Sub / Issung CA Zertifikate. Zumindest dann, wenn es sich um Enterprise CAs handelt (dann passiert das automatisch) oder Du den Import manuell durchgeführt hast. Relationship of the Configuration Container and Certificate Store Viele Grüße olc

Hi, ist irgend ein Filtertreiber installiert, z.B. Virenscanner oder Firewall? Wie sieht es aus, wenn Du das ganze Remote von einem anderen System aus versuchst - etwa Windows XP mit installiertem Adminpak.msi + GPMC 1.0.2? Viele Grüße olc

Glückwunsch. :)

Hi Jörg, absolut korrekt - da gebe ich Dir Recht. "Entdeckerdrang" hat die Menschheit groß gemacht :D . Wichtig ist halt nur abzugrenzen, was in Testszenarien gut ist und was in der Produktionsumgebung damit jedoch schief gehen kann. Denn die Dateisystemberechtigungen sind ja nicht alles - vielmehr geht es um den Inhalt von Konfigurationsdateien oder auch des Inhalts der userspezifischen Registrierung (HKCU - ntuser.dat) - die hat nämlich intern eigene Berechtigungen / ACLs und auch Einstellungen, die ggf. benutzerspezifisch sind. Von daher also nur mein Hinweis darauf, daß man damit sehr vorsichtig sein sollte und nicht unbedingt in einer größeren Umgebung auszurollen. :) Viele Grüße olc

Hi Jörg und willkommen an Board, :) dieser von Dir beschriebene Weg ist nicht umsonst nicht von MS supported. Nur weil eine Sache "funktioniert" heißt das nicht, daß man es so einsetzen sollte. ;) Du kannst bei diesem Vorgehen später in diverse Probleme mit Berechtigungen o.ä. laufen. Es stellt sich eh die Frage, warum immer wieder versucht wird, die Profile manuell zu bearbeiten. Spätestens seit den GPP gibt es neben den normalen GPOs alle möglichen Optionen, das ganze zentral zu erledigen. Also nichts für ungut: Wenn man es richtig machen möchte, dann nutzt man den SYSPREP- bzw. Unattend-Weg, der auch von MS vorgesehen ist. Viele Grüße olc

Hi, schalte den Dienst einmal auf den Startmodus "Automatisch (verzoegert)" - tritt das Problem dann immer noch auf? Viele Grüße olc

Hi, ich vermute das liegt am CRLCache, der erst erneuert wird, wenn die CRL nicht mehr aktuell ist. Unter Vista kannst Du den Cache leeren, unter XP geht das nicht offiziell. Viele Grüße olc

...was frißt die kleine Maschine so an Watt? :)