-
Gesamte Inhalte
3.978 -
Registriert seit
-
Letzter Besuch
Beiträge erstellt von olc
-
-
Hi Thomas,
dann könntest Du versuchen, es mittels certreq.exe und einer entsprechenden *.inf Datei zu lösen: Appendix 3: Certreq.exe Syntax
Wenn Du nur das Zertifikat erneuern und nicht den privaten Schlüssel neu erstellen möchtest, dann könntest Du die Option "UseExistingKeySet" nutzen. Die Syntax der *.inf Datei ist jedoch recht komplex.
Wenn Du ein neues Keyset nutzen möchtest, kannst Du einfach ein neues Zertifikat beantragen - oder ist das preislich ein Unterschied?
Viele Grüße
olc
-
Hi,
ist der Benutzer denn lokaler Administrator oder Domänen-Admin (RID = 500)?
Hast Du das System schon einmal neu gestartet, um danach remote den Löschvorgang durchzuführen?
Wie stellt sich eigentlich der Zusammenhang zwischen Netzwerkverbindung = nicht anmelden und "Profil neu erstellen" dar? Das ist mir nicht ganz klar.
Viele Grüße
olc
-
Optimal, daß es nun geklappt hat. :)
Danke für die Rückmeldung und Gruß
olc
-
Hi Daim,
*pling* - haste natürlich vollkommen Recht. Ich hatte mich daran erinnert, daß das irgendwann einmal ein Dokumentationsfehler war, der gefixt wurde.
Nur hatte ich die Änderung genau anders herum im Kopf. :D
Besten Dank für den Hinweis und Gruß
olc
-
Hi,
was passiert, wenn Du ein "+" anstatt des "-" verwendest, also "+SETUP_DCOM_SECURITY_UPDATED_FLAG" (nur testweise)? Gleiche Fehlermeldung?
Certutil selbst ist auf dem System aber installiert, korrekt? Das heißt Du kannst "certutil -?" aufrufen?
Wie sieht es mit der Eingabe aus - hast Du das Kommando aus der Webseite per Copy & Paste übernommen? Falls ja gib es einmal manuell ein.
Viele Grüße
olc
-
Hi,
es gibt Richtlinien die vorgeben, wie oft ein Benutzer sich offline anmelden darf, ohne daß er eine Netzwerkverbindung zum DC hat. Dummerweise finde ich den Pfad gerade nicht - vielleicht hilft jemand anderes aus? ;)
Ggf. kannst Du also einmal checken, wie dieser Wert gesetzt ist und ob er ggf. erhöht werden kann / muß. Was jedoch je nach Umgebung aus Sicherheitsgründen auch eher nicht sinnvoll sein kann.
Viele Grüße
olc
-
Hi,
die Richtlinie findest Du hier: "Always wait for the network at computer startup and logon" --> Computer Configuration\Administrative Templates\System\Logon .
Viele Grüße
olc
-
Hi,
der Process Explorer sollte Dir eine ganze Menge Informationen dazu liefern: Process Explorer
Dort gibt es oben in der Leiste ein "Fadenkreuz", mit dem Du den entsprechenden Dialog ansteuern kannst und in den Eigenschaften des dazugehörigen Prozesses die Threads etc. anschauen kannst.
Für die Funktionen benötigst Du die Symbole der jeweiligen Applikation / des Systems.
Viele Grüße
olc
-
Hi,
Du kannst so ein Zertifikat grundsätzlich auch über die Zertifikate MMC oder Webenrollment beantragen und in den Maschinenspeicher importieren. Dann läßt sich das aktuelle Zertifikat durch das neue Zertifikat ersetzen. Ist vielleicht einfach als die doch sehr limitierten IIS Dialoge. :)
Viele Grüße
olc
-
Hi,
für Vista gibt es mittlerweile noch einen zusätzlichen Rollup: Group Policy preferences client-side extension hotfix rollup for Windows Vista .
Für XP ist dieser nicht mehr verfügbar - hier wird auf normalen Wegen nichts mehr in dieser Richtung bereitgestellt werden. Also ein Grund mehr, sich über eine potentielle Migration weg von XP Gedanken zu machen.
Viele Grüße
olc
-
Hi Steven,
es gibt builtin kein ADM / ADMX, aber hier findest Du ein selbst erstelltes ADM dafür: http://www.gruppenrichtlinien.de/adm/gpolog.txt
Viele Grüße
olc
-
Hi Steven,
das Problem kann an sehr vielen Stellen liegen; DNS ist nur eine Baustelle, die Timeouts können von fehlerhaften Treibern kommen, Netzwerkkomponenten etc.
Schau DIr doch einmal ein UserEnv Debug Log an, vielleicht findet sich dort ein Ansatz. Das ist meiner Erfahrung nach bei Logonverzögerungen ein recht guter Startpunkt.
Ask the Directory Services Team : Understanding How to Read a Userenv Log ? Part 1
Ein Netzwerktrace kann auch wertvolle Informationen liefern.
Viele Grüße
olc
-
Hallo Daniel, willkommen an Board, :)
vielen Dank für die Auflösung des Problems, das hilft sicherlich auch anderen Forenteilnehmern weiter. :)
Viele Grüße
olc
-
Hallo Timmy und willkommen an Board, :)
auch wenn es immer Konstellationen geben kann, wo es Abhängigkeiten gibt, sollte im Normalfall das Administrator Kennwort eines Domänen-Admins nichts mit der Abarbeitung von Policies zu tun haben.
Beschreib doch noch einmal etwas genauer, was Du genau versuchst (hast Du neue Policies angelegt, wo sind diese verlinkt, wer hat Lese- und Anwenungsberechtigungen auf den Policies) und ob es Fehlermeldungen in den Eventlogs der Server oder Clients gibt.
Dann schauen wir, ob sich ein Bild zum Problem ergibt. ;)
Viele Grüße
olc
-
Hi,
sprechen wir hier von einer "produktiven" Maschine in Bezug auf eine Firmenmaschine oder ein privat genutztes NAS?
Viele Grüße
olc
-
Hi,
genau solche Probleme sind der Grund, eine CA erst gar nicht auf einem DC zu installieren... ;)
Wenn Du den Alias Weg gehen möchtest, muß der Name des DCs geändert werden.
Alternativ kannst Du bestehende Zertifikate austauschen, um so neue CRL Lokationen einfließen zu lassen.
Je nachdem, wie groß die Umgebung ist bzw. wie viele Zertifikate für bestimmte Zwecke ausgestellt wurden, kann der eine oder der andere Weg schmerzfreier sein.
Viele Grüße
olc
-
Hi,
die NETLOGON Einträge sind an der unteren Stelle interessant, denke ich. Wo hast Du das NETLOGON Log aktiviert? Auf dem Client oder auf dem DC / DNS Server?
Ist der DNS Server an alle Interfaces gebunden oder nur an ein bestimmtes?
Schneide doch mal ein GPUPDATE von einem Client (auf das ein 1054 USERENV Event folgen sollte nach Deinen Angaben) mittels Netzwerktrace mit. An wen wendet sich der Client, welche IP-Adressen werden von welchem Systen (nicht) zurück geliefert bzw. ist "nur" RPC nicht ansprechbar etc.?
Viele Grüße
olc
1355
-
Hi,
ansonsten kannst Du ab der PowerShell V2 bzw. WinRM auch remote Sessions mit anderen Benutzerrechten starten. Siehe dazu auch: Windows PowerShell Blog : Managing Remote Sessions
Viele Grüße
olc
-
Hi,
ich hoffe auch, daß ich mir darüber bewußt bin :D ;).
Noch ergänzend zu dem Hinweis von Carsten: Wenn ich mich nicht irre, sind bei FRS maximal 7 Tage "Server offline Zeit" möglich. Danach sind die Outlogs überschrieben und der "offline" Server geht durch einen nicht autorativen resync. Im Prinzip also ein D2 für den "offline Server".
Siehe dazu auch: http://technet.microsoft.com/en-us/library/cc758169%28WS.10%29.aspx
Daher sollte es in Deinem Szenario keine Probleme geben. Aber wie Carsten schon schrieb: Backup anfertigen, für alle Fälle (!).
Viele Grüße
olc
-
Hi,
die Funktion, die Du suchst, nennt sich ABE ;) : Marc Grote Blog Blogarchiv ABE und ABECMD in Windows Server 2008
Viele Grüße
olc
-
Hi,
Du definierst im DNS einen ALIAS für den neuen DNS Eintrag des neuen Servers. Der Alias zeigt dann auf eine neue Lokation, aber mit dem neuen Namen.
Viele Grüße
olc
-
Hi,
das Deaktivieren der Komponente kann Dich früher oder später in andere Probleme hinein laufen lassen. Muß nicht sein, kann aber.
Von daher ist es eher sinnvoll, die Root Zertifikate per WSUS oder SCCM zu verteilen: Windows root certificate program members
Im Feburar müßte ein neues Update heraus kommen.
Viele Grüße
olc
-
Hi,
schau einmal in die Datei %systemroot%\security\logs\winlogon.log : Interpreting Security Settings log files: Group Policy
Dort solltest Du die Ursache erkennen - ob man den Fehler dann einfach ignorieren kann, mußt Du selbst entscheiden. Ich persönlich behebe Fehler eher. ;)
Viele Grüße
olc
-
Hi,
Gegenfrage ;) : Hast Du die Hinweise oben in den letzten Posts denn geprüft?
Viele Grüße
olc
User kann sich nicht anmelden
in Windows 7 Forum
Geschrieben
Hi,
wenn es kein Admin ist, dann ist der oben genannte Registry Key nicht relevant. Das ist der falsche Benutzer.
Du solltest in Zukunft gleich bessere Fehlerbeschreibungen geben, denn erst jetzt wird das Bild klarer ;) :
Das Temp Profil wird geladen, weil Du nach dem Löschvorgang des Profils den nicht mehr vorhandenen Zeiger auf das Benutzerprofil in der Registry liegen hast. Navigiere zu HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList und entferne dort die korrekte SID bzw. den entsprechenden Schlüssel inkl. Unterschlüssel, also die SID des betroffenen Benutzers. Wenn Du die SID nicht kennst, dann schau einfach in der ProfileList unterhalb der SID Schlüssel - Du findest dort den Benutzernamen als auch den alten Profilpfad in den Unterschlüsseln.
Viele Grüße
olc