NilsK

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.

Moin, am besten bindest du den Treiber von einem Client aus ein. faq-o-matic.net » Windows-Druckserver: Treiber für 32- und 64-Bit-Clients Gruß, Nils

Moin, Off-Topic: na, mal wieder mit Woody gequatscht? ;) Gruß, Nils

Moin, das solltest du bei Samba-Spezialisten in Erfahrung bringen. Möglich, dass im Fall des Domänenbeitritts das Erzeugen des DNS-Eintrags über einen anderen Mechanismus abläuft als im Normalbetrieb. Vielleicht findet sich hier jemand mit ausreichender Samba-Expertise, aber meist sind wir hier sehr Windows-lastig. ;) Gruß, Nils

Moin Robert, interessante Zusatzinfo - das Problem, das ich meine, ist aber ein anderes als in dem KB-Artikel. Es ist einfach so, dass ohne weitere Symptome öfters mal der Information Store, manchmal auch andere Dienste nicht da sind. Daher hätte ich Interesse an deiner Skriptlösung. Magst du die hier mal posten? Gruß, Nils

Moin, wenn die Situation so ist, wie du sie beschreibst, wirst du mit dem Verkleinern höchstens Zeit gewinnen. Da du drei Datenbanken hast, solltest du die z.B. auf mehrere Disks verteilen. Mittelfristig wäre evtl. eine Verdrängungs-Archivierung sinnvoll. Damit verlagerst du die "Massen" auf einen anderen Speicherbereich, der evtl. weniger kritisch ist. Die Exchange-Archivierung allerdings wäre dafür weniger geeignet, weil sie auch mit EDB-Datenbanken arbeitet, die durch denselben Server verwaltet werden. Gruß, Nils

Moin, ein Neustart an sich ist für einen Exchange-Server kein Problem. Die Dienste vorher zu beenden, ist m.W. nicht erforderlich. Du solltest nur dafür sorgen, dass nicht alle Server gleichzeitig neu starten, wie deine Kollegen schon sagen. Ähnliches gilt auch für Domänencontroller, DNS-Server usw. Ein Abstand von einer Viertelstunde oder so wäre da schon sinnvoll. Vorsicht: Bei Exchange 2010 kommt es immer mal wieder vor, dass nach einem Neustart nicht alle Dienste von selbst wieder starten. Das scheint nach meiner Beobachtung auch zu passieren, wenn der Server eigentlich genug RAM hat. Hier wäre es also sinnvoll, zusätzlich ein Monitoring zu haben und spätestens nach ein paar Minuten die nicht laufenden Dienste nachzustarten. Gruß, Nils

Moin, der DA-Server muss zwei Netzwerkkarten sehen. Ob auf den vSwitches noch weitere virtuelle Netzwerkkarten kommunizieren, ist ihm egal. Sprich: Nein, du musst keine physische Karte nachrüsten. Gruß, Nils

Moin, Linux-Clients sind keine echten Domänenmitglieder. Daher geht das nicht. Gruß, Nils

Moin, wenn du es richtig machst, passiert nichts Negatives. Windows NT konnte selbstverständlich schon TCP/IP. Denk daran, das Service Pack 6a noch mal zu installieren, nachdem du dort TCP/IP nachinstalliert hast. Warum meinst du NetBEUI noch zu brauchen? Gruß, Nils