olc

Hallo Johannes, Du findest den Hinweis zum Kerberos SPN bei MS überall dort, wo es Sinn macht einen SPN zu setzen. In Deinem Fall jedoch ist die von Frank vorgeschlagene DFSN-Lösung mit Sicherheit die sinnvollere und vorgesehene Lösung, nicht Dein "Workaround". Von daher finde ich es persönlich schon verständlich, daß Du nichts dazu findest - warum sollte MS (oder jemand anderes) nicht sinnvolle und fehlerträchtige Wege dokumentieren, wo es vorgesehene andere Wege gibt? ;) Viele Grüße olc

Hi, Du kannst auch einen Explorer-Prozess als Benutzer oder "nicht-previligierter Admin" angemeldet mit Admin-Rechten / Token starten. Dazu setzt Du in den Folder Options die Einstellung, daß jedes Explorer Fenster in einem eigenen Prozess gestartet wird ("Launch folder windows in a separate process"). Danach solltest Du per Rechtsklick "Run as Administrator" auch den Explorer.exe mit verschiedenen Tokens nutzen können. Der Eintrag in die ACL entfällt somit, wenn Du im Explorer mit Admin-Token den Ordner öffnest. Viele Grüße olc

Hi Sascha, füge einmal den 2. Server als Namespaceserver hinzu, dann sollte das wieder passen. Siehe dazu Windows Server How-To Guides: Teil 1 - Verteilung von Namespaces auf verschiedene Server - ServerHowTo.de (gilt auch für Windows Server 2008). Viele Grüße olc

Hi, das neu konfigurieren ist nicht das Problem - problematisch dabei ist jedoch, daß die alten, ausgestellten Zertifikate damit unbrauchbar werden. Das hat also durchaus Folgen für Deine Gesamtumgebung. Beschreibe doch noch einmal etwas genauer von welchem Betriebssystem zu welchem BS Du gewechselt hast, wie die Pfade der alten und neuen CA Installation sind etc. Der IIS usw. ist korrekt auf der neuen Maschine installiert? Was passiert, wenn Du die Daten direkt in den "C:\Windows\system32\certlog" Ordner kopierst und von dort die Wiederherstellung versuchst? Viele Grüße olc

Hi chucki, Du schreibst, daß ein Fehler bei der Synchronisation auftritt. Eine etwas präzisere Fehlermeldung macht sich meist zur Fehlersuche etwas besser, vielleicht kannst Du das ja noch nach reichen. ;) Die "objectCategory=person" gibt es auf Benutzerobjekten nach dem Löschen nicht mehr. Daher kann der LDAP-Filter die Benutzerobjekte nicht mehr finden. Siehe dazu: Du mußt also den Suchfilter anpassen und beispielsweise eine "objectClass=user" einfügen (oder den Workaround des KB-Artikels umsetzen). Bitte teste das ganze vorher in Deiner Testumgebung - je nach Größe der Umgebung kann sich die Last auf den DCs und der ADAM-Instanz dramatisch verändern, wenn Du den Filter in der Art änderst. Viele Grüße olc

Hi, dann sind die Rechte verbogen - Du solltest eher das Problem anschauen, anstatt die UAC abzuschalten. ;) Wie oben schon gesagt - die UAC ist nicht das Problem, sondern nur das Symptom. Viele Grüße olc

Hi, Du hast auf jeden Fall mindestens eine Malware auf dem System: Siehe dazu: ThreatExpert Report: Mal/Heuri-D bzw. Mal/Heuri-D [sophos] | ThreatExpert Statistics Ich persönlich würde die Maschine neu installieren, solltest Du eine gute Datensicherung haben. Ansonsten kannst Du wie oben angesprochen mit diversen Produkten versuchen, das System zu "reinigen". Jedoch ist das meist nicht wirklich von Erfolg gekrönt bzw. kannst Du dem System schlichtweg nicht mehr trauen. Also mach es lieber neu. ;) Viele Grüße olc

Hi, Du könntest beispielsweise auch mit dem Process Explorer prüfen, welche Dateien und DLLs von den Prozessen genutzt werden. Aber es klingt im ersten Moment schon ein wenig nach Malware, wie Daniel schon sagte. Ggf. also einmal Knoppicillin Download-Edition 6.0.2 Deutsch, Download bei heise drüberlaufen lassen und über eine Neuinstallation nachdenken, sollte dort Schadsoftware gefunden werden. Viele Grüße olc

Hi, der Neustart sollte m.E. nach nichts bringen - die Benutzerkontensteuerung hat nur bedingt etwas damit zu tun. Interessant wäre ja, wie die Berechtigungen aussehen, die Du als SYSTEM in der CMD auslesen kannst (z.B. mit xcacls oder icacls). Was ist denn der Inhalt vom Laufwerk D: ? Kannst Du irgend welche "besonderen" Daten erkennen? Viele Grüße olc

Hi Oliver, kann es sein, daß sich der Installationspfad von %SYSTEMROOT% verändert hat (beispielsweise von C:\WINNT auf C:\WINDOWS)? Falls ja ist folgender Absatz in dem o.g. KB-Artikel relevant, der den Fehler in diesem Zusammenhang beschreibt: Viele Grüße olc

Hi Christian, hat sich da etwas ergeben? Bin noch auf folgenden Hinweis im "Umzugs-KB-Artikel" gestoßen, der durchaus relevant sein kann: Wäre interessant zu sehen, ob das auch für 2008 R2 zutrifft. Viele Grüße olc

Hi Mutwa, Du kannst beispielsweise einen Performance Counter mit Schwellwert definieren und bei dem Überschreiten des Schwellwertes eine E-Mail auslösen: Alert Notifications Performance Counters tab Nur nützt Dir das unter Umständen nicht mehr viel, wenn das Backup gerade läuft. Daher sollten die Daten (mal abgesehen davon, daß die Daten auf dem selben Laufwerk als Backup keinen Sinn machen) auf jeden Fall im Netzwerk oder auf Band abgelegt werden (oder beides). Viele Grüße olc

Hi, ok - das heißt also, daß Du direkt auf D: nicht mehr zugreifen kannst. Dann versucht doch einmal in den Sicherheitsoptionen von D: den Besitz zu übernehmen. Jedoch solltest Du dir darüber im Klaren sein, daß Du ggf. Probleme technischer Natur bekommen kannst, wenn Du damit an den Rechten etwas verbiegst, was vorher bewußt so eingestellt worden ist. Darüber können wir im Moment nur mutmaßen. Alternativ kannst Du es im SYSTEM-Kontext versuchen, beispielsweise mittels C:\> PsExec \\localhost -s cmd und dann ggf. die weiteren Befehle (siehe oben). PsExec: http://technet.microsoft.com/de-de/sysinternals/bb897553.aspx Viele Grüße olc

Hi Oliver, hast Du als Pfad einmal "C:\temp\database" eingegeben? Viele Grüße olc

...neben dem Hinweis von Dukel auf das Posten des gpresult-Schnipsels: Ist die nicht angezeigte GPO auf der zweiten OU überhaupt verlinkt? Viele Grüße olc

Hallo Hampek, schön, daß es geklappt hat. :) Das Verteilen der Änderung ließe sich beispielsweise mit Logon-Scripts erledigen. Dafür müssen die Clients natürlich eine Verbindung mit dem SYSVOL herstellen können, ohne die Dial-in Benutzerdaten zu verwenden. :D Ein Teufelskreis. ;) Viele Grüße olc

Hi Holger und willkommen an Board, :) haben die Linksys Systeme unter Umständen noch einen Packetfilter für die VPN-Verbindungen? Kannst Du von einem Client aus über das VPN auf das SYSVOL des SBS zugreifen? net use * "\\jedi.xxx.local\SYSVOL" -u USERNAME -p * Wie lautet der Standard-Gateway und DNS-Server auf Server und Client? Poste am besten einmal ein ipconfig /all ausgeführt auf dem Server und auf dem Client. Viele Grüße olc

Hi Thomas, willkommen an Board, :) gibt es unter Umständen Fehler im Ereignisprotokoll der Server? Was ist die genaue Fehlermeldung bei der fehlschlagenden Einwahl? Hat sich irgend etwas an den Servern verändert (oder an der Leitung zwischen den Systemen)? Viele Grüße olc

Hi, kommst Du denn noch auf das Stammlaufwerk D: oder nur nicht in Unterordner? Grundsätzlich legt DFSN junction points bzw. sparse points an, auf die Du auch als Admin im Normalfall nicht zugreifen kannst. Jedoch würde dies normalerweise nicht für ein komplettes Laufwerk gelten, sondern nur für die DFSN Namespaces (als Ordner auf dem System). Was sagt denn ein simples C:\> dir d: oder C:\> dir d: /AHS auf dem System? Viele Grüße olc

Hi faecher, im Normalfall stellt nicht der Absender ein Zertifikat aus, sondern der Empfänger. Dann sendet er (falls kein technisches "Unternehmensvertrauen" definiert ist) den öffentlichen Schlüssel an seine Partner bzw. stellt diese bereit. Dann können E-Mails mit dem öffentlichen Schlüssel verschlüsselt werden, der private Schlüssel bleibt beim Empfänger. Alles andere macht keinen Sinn, es sei denn, es wird eine eigene symmetrische Lösung eingesetzt. Vielleicht kannst Du noch einmal etwas genauer beschrieben, was genau Du für ein Zertifikat bekommen hast, welches Format es hat (z.B. CER, PFX o.ä.). Dann kann man schauen, in welche Richtung es vielleicht geht. Viele Grüße olc

Hallo Hampek und willkommen an Board, :) schau einmal, ob die Zugangsdaten im Credential Manager falsch eingetragen werden: Start --> Ausführen --> "control keymgr.dll". Falls ja, lösche diese einmal und starte den Rechner neu. Tritt das Problem dann immer noch auf? Wenn ja, kann man den Credential Manager auch komplett deaktivieren - das hat jedoch auch an anderen Stellen Auswirkungen in Bezug auf das Speichern von Benutzerkennwörtern. Ich meine mich zu erinnern, daß man die Registrierung der Dialin-Daten auch abschalten kann (in irgend einer Datei im Benutzerprofil), aber es fällt mir gerade nicht mehr genauer ein. Vielleicht erinnert sich jemand anderes oder ich mich später noch. ;) EDIT: Ah, hier ist es: http://support.microsoft.com/kb/822707/en-US. :) Viele Grüße olc

...werden dort die Freigabeberechtigungen mit "einberechnet"? Ich hatte im Hinterkopf, daß das nicht der Fall ist. Aber vielleicht irre ich mich diesbezüglich auch. Viele Grüße olc

Hi, gerne. Freut mich, daß es nun funktioniert. :) Viele Grüße olc

Hi, Du kannst zum "SYSTEM" werden (und damit zum Rechner), indem Du beispielsweise PsExec verwendest: C:\> PsExec \\localhost -s cmd Dort schafft ein einfaches C:\> NET USE * \\w2k8-Domänenname\Stammname oder C:\> dir \\w2k8-Domänenname\Stammname Klarheit. Download: PsExec Viele Grüße olc

Hi Thyral, dann hast Du die wahrscheinlich für Dich perfekte Lösung im oben von Frank geposteten Link. :) Viele Grüße olc