NilsK

Moin, die Netzwerk-Druckersuche funktioniert leider nicht zuverlässig. Warum das so ist, habe ich mangels Bedarf noch nicht nachverfolgt. Der sinnvollste Weg führt, wie Thorsten schon vorschlug, über den Druckserver. Gruß, Nils

Moin, oder um es ganz deutlich zu sagen: Solche Daten haben in AD nichts verloren, und José ist kein Inventarisierungstool. Gruß, Nils

Moin, welchen Aufwand würde man denn genau bei einem Inplace-Upgrade sparen? Ich sehe den Nutzen gerade nicht ... Gruß, Nils ... der entschieden von allen Pseudo-Sicherheitsmaßnahmen wie "LAN abstöpseln" oder "mal eben vorher virtualisieren" abrät.

Moin, kannst du das Problem vielleicht noch mal so beschreiben, dass man es versteht? Von was für einem Programm redest du? Um was für Dokumente geht es? Gruß, Nils

Moin, ??? AD repliziert ganz von alleine. Du brauchst keine Tools dazu. Welches Problem versuchst du zu lösen? Wo hast du denn das Kommando her? Ein Attribut "now" kennt das replicate-Kommando zumindest laut Syntaxbeschreibung nicht. Im Effekt würde das Kommando nach einem DC namens "now" suchen ... Was würdest du denn überhaupt damit bezwecken wollen? Mir scheint, du hast etwas unscharfe Vorstellungen vom Ablauf der Replikation. Gruß, Nils

Moin, haben die Computerkonten Schreib- und Leserechte auf dem Share? Gruß, Nils

Moin, ja, für mich auf meinem Rechner. Dir ist bekannt, dass es sich um ein kostenloses Tool handelt, das ich in meiner Freizeit entwickle? Dir ist darüber hinaus bekannt, dass es keinen definierten Support gibt, was auch deutlich kommuniziert ist? Wenn es dir wichtig ist, kannst du gern einen Auftrag an meinen Arbeitgeber stellen, damit ich Funktionen nach Wunsch entwickle. Anderenfalls musst du leider warten, bis ich die Zeit finde, meine Liste abzuarbeiten. Oder du bemühst dich selbst, den Code zu erweitern bzw. zu korrigieren. Dann könntest du dir zusätzlich überlegen, deine Code-Ergänzungen der Community verfügbar zu machen, wie es schon mehrere Kontributoren gemacht haben. Danke für dein Verständnis. Gruß, Nils

Moin, Rückmeldung dazu: Der Fehler lag in den Daten im AD. Im konkreten Fall waren in einem Attribut ungültige Zeichen gespeichert, weswegen José auf einen Fehler lief. Nach Korrektur der Daten ging es wie gewünscht. Gruß, Nils

Moin, allgemeine Bitte: Worte wie "kastriert" vermeiden. Danke. Dass José große Gruppen nicht korrekt ausliest, liegt an Mechanismen innerhalb von AD, mit denen das Skript nicht korrekt umgeht. Ich habe selten mit so großen Gruppen zu tun und daher die Behandlung noch nicht angepasst. :) Steht auf der Liste, aber ich kann nichts versprechen. Gruß, Nils

Moin, Internetverbindung zum iSCSI-Target?! Auf Ideen kommen die Leute ... 50 GB ist ja nun nicht besonders groß. Wenn ich es vermeiden könnte, würde ich da nicht mit einem heterogenen Konzept arbeiten. Mein Rat wäre, das Gesamtkonzept zu überdenken. Zu deinem Problem: Warum arbeitest du nicht einfach mit zwei Mediensätzen? Gruß, Nils

Moin, bitte künftig nicht auf uralte Threads antworten, sondern einen neuen erstellen! Das Board warnt nicht umsonst, und deine Frage ist eine völlig andere als die in diesem Thread. Einen DSN braucht man nicht, wenn man den Server so anspricht, wie es im Skript geschieht. DSNs sind in den meisten Situationen eher hinderlich - waren mal gedacht als Abstraktionsebene vom konkreten Servernamen, aber erzeugen selbst sehr viel Umstand. Gruß, Nils

Moin, wofür geeignet? Allgemein zum Backup von AD? Oder um den "neuen" auf den logischen Stand des "alten" zu bringen? Wie schon gesagt: Solange der "alte" DC noch einigermaßen läuft, bringst du den "neuen" einfach zusätzlich in die Domäne, die Replikation macht den Rest. Nur wenn das nicht gehen sollte, nutzt du ein aktuelles (!) Backup des Systemstate vom alten DC, um dies auf dem neuen wiederherzustellen. Dann muss im Moment des Recovery der alte DC aber abgeschaltet sein. faq-o-matic.net » Video-Tutorial: Active Directory Object Recovery Gruß, Nils

Moin, der Haken bedeutet, dass bei erfolgreicher SMTP-Anmeldung an Exchange das Relay erlaubt wird. Normalerweise brauchst du den nicht. "Normale" interne oder externe Server authentifizieren sich nicht und können daher über das Häkchen nicht an der Relayliste vorbei. MSXFAQ.DE - Relay mit Exchange 200x MSXFAQ.DE - Sicheres Relay für Clients im Internet Gruß, Nils

Moin, ja. faq-o-matic.net » Warum der Hyper-V-Host keine (!) weiteren Dienste ausführen sollte Und wenn du es noch besser machen willst, betreibst du den DC nur als DC (und DNS) und legst die anderen Dienste noch mal auf ein separates System. Das ist nicht zwingend, aber spätestens beim Recovery sinnvoll. Gruß, Nils

Moin, ist das ein Produktions- oder ein Testsystem? Auf einem DC richtet man keinen Terminalserver ein. Wenn ich nicht falschliege, ist die Einstellung, die du im oberen Teil erwähnst, nur für die Remote-Administration - kann aber auch sein, dass ich mich da grad irre. Ist der User denn in der Gruppe Builtin\Remotedesktopbenutzer? Möglich auch, dass der User auf einem DC trotzdem das Recht der lokalen Anmeldung braucht. Da man das normalerweise auf einem DC nicht macht, hab ich das nicht im Kopf. Gruß, Nils

Moin, in den Gruppenrichtlinien unter Computer/Sicherheit/Lokal/Benutzerrechte. Mitgliedschaft in der Gruppe "Remotedesktopbenutzer" auf dem jeweiligen Rechner. Meistens ist er in solchen Fällen in der falschen Gruppe, nämlich im AD im Ordner Builtin. Die gilt aber nur für die DCs, nicht für die Terminalserver. Es muss sich um die lokale Gruppe des jeweiligen Servers handeln. Gruß, Nils Hat jemand einen Tipp für mich? Danke bereits im Voraus und viele Grüße! cargu

Moin, komisch, warum habe ich das erwartet? ;) Die "Isolation" bezöge sich in dem Szenario ja nur auf den Speicherort der Gruppen, Accounts bzw. DC-Rollen in der Root-Domäne. Wenn das das Ziel ist - okay. (Weitergehende Fragen, wann das warum sinnvoll sein könnte, sind dann Teil des Gesamtdesigns, das immer individuell ist.) Eine Sicherheitstrennung besteht in dem Fall nicht, weil zwischen den Domänen eines Forests keine echten Sicherheitsgrenzen bestehen. Sie zu überwinden, ist zwar nicht immer trivial, aber prinzipbedingt möglich. Daher sehe ich in der Hinsicht keinen Vorteil. Gruß, Nils ... der ein Anhänger des Single-Domain-Designs ist.

Moin, dem wage ich leise zu widersprechen. ;) Diese "Isolation" ist weitgehend wirkungslos, weil die Domäne keine Sicherheitsgrenze ist. Gruß, Nils

Moin, niemals mehr als 15 User im Netz ... die Firma darf also nicht wachsen, oder sie muss dann ein "echtes" OS komplett neu lizenzieren. Gruß, Nils

Moin, als Ergänzung: In einem Forest kann es nicht mehr als eine Org geben. Du bleibst also bei der bestehenden Organisation und erzeugst keine neue. Gruß, Nils

Moin, kannst du innerhalb des SSMS auf die Datenbank zugreifen? Wenn nein: Hast du evtl. die Option gewählt, die Datenbank nach dem Restore nicht online zu schalten? Gruß, Nils

Moin, rein vorsorglich weise ich darauf hin, dass ihr damit ein Datenschutzproblem erzeugt. Sichert euch da ab. Alles Weitere dazu bitte mit einem Anwalt besprechen. Gruß, Nils

Moin, wenn es sich um Exchange-Clusterknoten handelt, würde ich einen größeren Abstand als 15 Minuten empfehlen. Es ist zwar nicht zwingend mit Problemen zu rechnen, aber die DAG sollte sich erst mal wieder "beruhigen", bevor sie ein zweites Failover machen muss. Im Fall der DAG-Clusterknoten wäre - abweichend vom oben gesagten - auch denkbar, vor dem Neustart eines der Knoten ausdrücklich ein Takeover der Datenbanken auf einen anderen Knoten zu machen, etwa per PowerShell. Gruß, Nils

Moin, du musst die User zu mail-aktivierten Benutzern machen. Gruß, Nils

Moin, da Windows Server "8" noch nicht mal in der Beta ist, kann man dazu noch gar nichts sagen. Das neue Server-Windows wird sicher erst in der zweiten Jahreshälfte 2012 kommen, aber auch das ist nur Spekulation. Früher würde ich jedenfalls nicht damit rechnen. Gruß, Nils PS. Bitte Groß- und Kleinschreibung nutzen, danke.