olc

Hi, soweit ich weiß, kannst Du bei Multicasts die TTL konfigurieren. Ändere doch einfach die möglichen Hops auf 1 oder 2, dann kommt das Paket hinter einem Router nicht mehr weit. :) Viele Grüße olc

Hi, ja, das Einrichten des SPNs für den CNAME sollte (eigentlich) funktionieren. Da Du jedoch nicht nur den Host selbst auflösen möchtest, sondern auch den Server als Fileserver nutzen möchtest, müßtest Du zusätzlich auch noch "CIFS" SPNs registrieren. Dafür kannst Du wie schon von Dir angesprochen ADSIEdit.msc oder SETSPN nutzen. Die Frage ist jedoch, warum Du den alten Eintrag überhaupt weiter betreiben möchtest. Wäre es nicht sinnvoller, die alten Verweise zu entfernen bzw. die Einträge für den alten Fileserver auf den "betroffenen" Systemen zu ändern? Viele Grüße olc

Hi Martin, oben hast Du bisher von FRS gesprochen, im letzten Post von DFSR. Was genau nutzt Du? In Bezug auf die Grundthematik: Sicherlich läßt sich FRS / DFSR für ein solches Szenario einsetzen, nur ist die Frage, ob das wirklich so sinnvoll ist. Ein entsprechendes Storage-System, welches direkt auf Filesystembasis die Daten repliziert ist unter Umständen besser für dieses Vorhaben geeignet, als ein dateibasiertes Replikationssystem wie FRS oder DFSR (wobei letzterem definitiv der Vorzug gegeben werden sollte). ;) Viele Grüße olc

Hi ottscho, herzlich willkommen im Forum. :) Wie genau hast Du die initial sync abgebrochen? Soll heißen - welche Aktionen hast Du genau durchgeführt? Was meinst Du mit "neu versuchen"? Welche Schritte hast Du durchgeführt? Dann hat der Zielserver (ohne DfsrPrivate) noch keine Kenntnis von seiner Zugehörigkeit zur Replikationsgruppe bzw. dem zu replizierenden Ordner. Die Namespaces stehen grundsätzlich erst einmal nicht im Zusammenhang mit der Ordnerreplikation. Von daher brauchst Du die nicht anfassen. :) Wie lange hast Du zwischen den Versuchen gewartet? Die AD-Replikation muß zwischen den Systemen stattgefunden haben, von denen sich DFSR die Konfigurationsdaten zieht. Danach kann es noch bis zu 60 Minuten dauern, bis sich der DFSR-Dienst selbst die Konfigurationsdaten zieht. Also vielleicht warst Du nur zu ungeduldig. ;) Je nachdem, wie Du den initial sync Vorgang unterbrichen hast, kannst Du nun in einem Status hängen, bei dem der "Primary Member" nicht definiert ist. Das läßt sich nachholen - aber vorher solltest Du noch einmal genau schreiben, wie Dein Vorgehen war. In jedem Fall ist ein back der Daten sinnvoll, so daß Du nicht in einen Datenverlust läuft, wenn die Replikation unter Umständen "in die falsche Richtung" los läuft... "RC2" ist "Release Candidate" - den solltest Du lieber nicht nutzen. ;) Ich vermute, Du meinst den "R2". Es sollte keine Probleme zwischen einen 2008er und 2003er System geben. Kann wie angesprochen an der Verzögerung liegen, die die Einrichtung von DFSR aufgrund der AD-Replikationslatenz und dem polling Intervall des DFSR Dienstes verzögert. Schau jetzt noch einmal nach, ob sich etwas getan hat. Viele Grüße olc

Hi, inwieweit spielt hier "Datensicherheit" (k)eine Rolle? Es gibt (eher im privatbereich) diverse Möglichkeiten, jedoch meist ohne besondere Verschlüsselung / Absicherung der Daten. Davon würde ich eher abraten. Natürlich kann man das _irgendwie_ hinbekommen; ob es ratsam ist, ist dabei jedoch eine andere Frage. Ich persönlich würde in jedem Fall ein VPN aufbauen, in dem Du dann problemlos und recht sicher die Daten austauschen kannst. Wenn das - wie oben angesprochen - keine Option ist, wird es wohl in die kostenpflichtige Richtung gehen. Wie viel Geld darf ausgegeben werden? Viele Grüße olc

Hi, hast Du Dir die Widgets / Gadgets angeschaut? Wie oben schon angesprochen sollte sich dort genau das richtige für Dich finden. Viele Grüße olc

Hi eras, im Grunde ändern Deine Angaben die Ausgangssituation vollkommen. SSL / TLS ist "hinreichend" sicher, was die Verschlüsselung als solches angeht. Die Verschlüsselung ist (egal ob bei einer Bank oder anderen Unternehmen) also in diesem Fall schlichtweg nicht das Problem. Auch kann ein Nutzer von UMTS und Konsorten nichts mit dem HTTPS-Datenstrom anfangen (mal abgesehen von Organisationen mit größeren Rechenzentren :D ;) ). Womit ich explizit nicht sagen möchte, daß ich SSL / TLS "VPNs" den IPSec VPNs vorziehen würde. An diesem Punkt liegt jedoch nicht das Problem, denn ab hier greift die Client-Security, weshalb die meisten Anbieter von SSL / TLS Verschlüsselungslösungen (die als VPN angepreist bzw. genutzt werden) auch gleich noch eine Art von Client-Überprüfungen mitliefern. Hier wird das Betriebssystem auf aktuelle Sicherheitsupdates, aktuellen Virenscanner etc. überprüft, um erst dann einen Zugriff zuzulassen. Das ganze nützt natürlich nichts, wenn die Benutzerkennwörter über Keylogger etc. mitgeschnitten werden. Das ganze hier im Detail auseinander zu nehmen, wird kaum gelingen. Sicherheitskonzepte von Unternehmen füllen streckenweise ganze Bücher. Ich könnte mir aber vorstellen, daß sich hier der ein oder andere Expert / Mod einschalten wird. :D ;) Viele Grüße olc

Hi, nichts, ich wiederhole, nichts ist "fast 100% abhörsicher". Mag sein, daß ein VPN sicherer ist, jedoch bietet das Clientsystem selbst immer noch genügend Angriffsfläche. Von daher die Frage: Worum geht es Dir genau? Das "im Internet surfen" wird in den vielen Fällen erst einmal kein Staatsgeheimnis sein - zumal der Traffic ja an anderer Stelle sowieso entschlüsselt vorliegt. Daher ist die Diskussion im Grunde wenig fruchtbar, wenn Du nicht vorher ein wenig spezifizierst, welche "Sicherheitsstufe" Du überhaupt erreichen willst. :) Viele Grüße olc

Hi Norbert, gebe Dir da absolut Recht - deshalb habe ich das auch ein wenig "betonter" geschrieben. Aber bestimmte Policies lassen sich nicht so einfach exportieren / importieren (etwa Softwareverteilungs-Policies), wenn man einmal von aufwendigen und fehleranfälligen "Hacks" absieht. Ein Grund mehr, die Builtin-Softwareverteilung nicht zu nutzen. :D Aber daher kann es in speziellen Fällen schon Sinn machen, die GPOs über Domänengrenzen hinweg zu verlinken. Ist aber sicherlich recht selten. :) Viele Grüße olc

Hi, einmal vollkommen abgesehen davon, daß das nur das letzte Mittel der Wahl sein sollte: Grundsätzlich kannst Du auch GPOs einer Domäne auf andere Domänen des selben Forests verlinken (neben der von Norbert genannten Variante der Site-Zuordnung). Im Normalfall würde ich persönlich zwar eher davon abraten, jedoch ist es in einigen speziellen Situationen sicherlich nützlich. Schau Dir einmal die GPMC an, damit hast Du einige Möglichkeiten in Bezug auf GPOs: Downloaddetails: Gruppenrichtlinien-Verwaltungskonsole (GPMC) . Viele Grüße olc

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

Hi, Du könntest Dir auch eine Widget / Gadget Engine wie Yahoo! Widgets: useful, fun, beautiful little apps for Mac and Windows installieren - fast alle (egal ob Yahoo, Opera, Microsoft) bieten hier Gadgets mit der von Dir angesprochenen Funktion. Kostet halt Arbeitsspeicher... Alternativ könntest Du Dir auch einfach in paar Verknüpfungen (auf Shutdown.exe und Konsorten) anlegen und nach Bedarf anklicken. Aber mal ehrlich - ist das den Aufwand wirklich wert? Die meisten Funktionen bieten Shortcuts für diesen Zweck (mal abgesehen von den vom Doc genannten drei Standard-Klicks)... ;) Viele Grüße olc

Hi, nein, es ist auch für Windows Server 2003 SP2 verfügbar: The Icacls.exe utility is available for Windows Server 2003 with Service Pack 2 . Unter 2008 gibt es keine Ressource Kit Tools (zumindest bis heute). Sicherlich gibt es einige Möglichkeiten, so auch VBScript, PowerShell etc. Was spricht jedoch gegen icacls? Viele Grüße olc

Hi, noch einmal der Hinweis auf die Group Policy Preferences. Damit kann man das recht elegant lösen. So lassen sich auch in Abhängigkeit der Gruppenmitgliedschaften Laufwerke mappen. :) Dazu müssen die Clients jedoch auf XP / 2003 und höher laufen. Viele Grüße olc

Hi, schau Dir einmal icacls an. Wenn ich mich nicht täusche, sollte Dein Vorhaben mit dem Schalter /RESET oder ggf. anderen Kombinationen möglich sein. Viele Grüße olc

Hi Mull, wie ich oben schon schrieb - einen gewissen Aufwand mußt Du in diesem Szenario auf jeden Fall investieren. Sei es, indem Du eine PKI aufbaust bzw. nutzt, oder indem Du auf den Zielsystemen Plugins oder Programme installierst. Es gibt hier sicherlich recht "wartungsarme" Software, die teilweise als Addon für Outlook etc. arbeitet und keinerlei Konfiguration auf dem Zielsystem benötigt - aber installiert werden müßte sie trotzdem. Abgesehen davon benötigst Du Anwenderschulungen. Nutzt Du eine "öffentliche" PKI, kostet das weniger Aufwand - dafür aber eine Menge mehr Geld. Viele Grüße olc

N'Abend, Na ja, ein Mailclient ist jedoch auch ein Programm: Mir würden da also nur Alternativen wie Rauchzeichen (in Verbindung mit dem oben genannten Rot13 / Rot26 oder ähnlichem) einfallen. :D :p Nein, mal im Ernst: Sicherlich beherrschen einige E-Mail Clients Verschlüsselungs- oder Signierungstechniken mittels S/MIME / X.509 Zertifikaten. In jedem Fall benötigst Du dafür jedoch mindestens eine verfügbare PKI (egal ob eine eigene oder eine gehostete wie etwa von Verisign). Wenn ich das Anliegen richtig einschätze, ist das nicht vorhanden - es sollen schlichtweg Kunden o.ä. in den genuß "sicherer" Kommunikation kommen, ohne daß auf den Zielsystemen Aufwand betrieben werden soll. Das geht naturgemäß meist nicht. ;) Vielleicht kann ja "mullfreak" noch einmal ein wenig genauer beschreiben, was das Szenario ist. Vielleicht gibt es ja Alternativen. Viele Grüße olc

Hi, diverse erhoffte CMDlets wird es nach derzeitigem Kenntnisstand auch geben :): PowerShell Team Blog : 574 Reasons Why We Are So Proud and Optimistic About W7 and WS08R2 Viele Grüße olc

Hi, da hast Du natürlich Recht, habe beim Schreiben nicht darüber nachgedacht. Vielen Dank für den Hinweis. Um vorzubeugen: Man benötigt natürlich "READ" und "APPLY" Rechte auf die Group Policy. Ich hoffe damit sind alle Ungenauigkeiten beseitigt. ;) Vielen Dank und viele Grüße olc

Hi, Schau doch einmal, wo die Datei "MSVCR80.dll" im Dateisystem liegt, um auf die verursachende Applikation zu schließen. Siehe auch MSVCR80.dll Windows Prozess - Was ist das? C:\>err 0xc000000d # for hex 0xc000000d / decimal -1073741811 : [b]STATUS_INVALID_PARAMETER[/b] ntstatus.h # An invalid parameter was passed to a service or function. [b]USBD_STATUS_BUFFER_UNDERRUN [/b] usb.h # 2 matches found for "0xc000000d" Aktives Verzeichnis Blog : Fehlercodes mit ERR.EXE auslesen bzw. Fehlertexten zuordnen Viele Grüße olc

Hi, ein "NETDOM TRUST /?" gibt zu "quarantine" folgendes aus: Damit ist es für Dein Kommando wohl hinfällig bzw. Du kannst es weg lassen oder? :) Viele Grüße olc

Hi, Du kannst eine neue Gruppenrichtlinie in der Domäne für den DC erstellen - nach Möglichkeit solltest Du per Sicherheitsfilterung nur dem DC das "APPLY" Recht geben. Darin änderst Du die Einstellung wieder - da Domänen-GPOs lokale Sicherheitsrichtlinien überscheiben, solltest Du nach dem Übernehmen der Policy durch den DC (wenn nicht manuell getriggert oder durch Neustart angewendet dauert das etwa 90 Minuten) wieder Zugriff haben. Dann entfernst Du die lokale Einstellung wieder. Alternativ kannst Du auch die secedit.sdb + dazugehörige Logfiles im Recovery Modus löschen (siehe unterer Bereich von Gruppenrichtlinien – Handbuch für die Problembehebung (Beheben von Problemen bei Sicherheitseinstellungen)). Diese enthält die Sicherheitseinstellungen. Jedoch sind dann auch alle anderen lokal gesetzten Einstellungen verloren. Soviel übrigens zur "Sicherheit" Deines Anliegens in Bezug auf lokale Policies (mal abgesehen von Domänenpolicies). ;) Viele Grüße olc

Hi, rein theoretisch kannst Du Dir die Registry Dateien über "regedit" in Dein System einbinden, die gewünschten Schlüssel der jeweiligen Applikation dann exportieren und diese wieder auf dem neuen System importieren: Zum einen die NTUSER.DAT für Dein Benutzerprofil, zum anderen den z.B. HKLM\Software Registrierungszweig unter %SYSTEMROOT%\system32\config. Aber ganz ehrlich - die Fehlerquellen sind enorm hoch, daher solltest Du das meiner Meinung nach eher lassen. Viele Grüße olc

Hi, leider finde ich gerade keinen entsprechenden Link dazu - aber ich meine mich zu erinnern, daß IFMEMBER tatsächlich Probleme ab einer gewissen Anzahl an Gruppenmitgliedschaften hat. Verwundern würde mich in diesem Zusammenhang nur die Aussage, daß es nach dem Entfernern der Gruppenmitgliedschaften immer noch Probleme gibt. Aber hey - IFMEMBER ist eh nicht mehr empfohlen und stammt aus dem Windows 2000 Resource Kit. Zeit, sich etwas neues zu suchen... Habt Ihr schon einmal darüber nachgedacht die IFMEMBER Funktion anders zu lösen? Etwa Group Policy Preferences o.ä.? Viele Grüße olc

Off-Topic: Jepp, sorry. Hatte wohl nur den ersten Satz + Link danach gelesen und das "Dazwischen" überlesen. Gruß olc