NilsK

Moin, schön - aber kein überbordendes Budget ... Ähh ... wie meinen? Sollen das VMs sein? Oder willst du all diese Funktionen auf einem Server betreiben? Falls Letzteres: Bitte noch mal neu planen. Außerdem ist 1 DC zu wenig. Auch schwer verständlich. Redest du hier von VMs? Aha. Deutet darauf hin, dass Obiges VMs sein sollen. In dem Fall: Wenn Exchange "bei Ausfall übernommen" werden soll, brauchst du einen Cluster für die Virtualisierungs-Hosts. Dann fehlt hier das Storage-System. Dann sind 13.000 EUR sehr knapp. Wenn es ein Cluster werden soll, wäre es besser, wenn die CPUs gleich sind. Nicht nötig, aber beim Neuaufbau auf jeden Fall sinnvoll. Unterhalb von 64 GB würde ich bei Virtualisierung gar nicht nachdenken. Vor allem, wenn es ein Cluster sein soll (wo aus meiner Sicht kein Weg vorbeigeht) - dann stehen nämlich effektiv pro Server nur 28-30 GB für die VMs zur Verfügung (denn beim Failover müssen alle VMs ja auf einer Maschine laufen). Wie oben: Beim Cluster sieht man gleichartige Ressourcen vor. Was meinst du mit "VM-Lizenz"? Sowas gibt es nicht. Ich würde vorschlagen, das Konzept noch mal in Ruhe zu überarbeiten. So wird aus meiner Sicht nur - mit Verlaub - Murks daraus. Gruß, Nils

Moin, ich würde die Finger davon lassen. Gruß, Nils

Moin, das heißt konkret was? Welche Standorte und welche Subnets gibt es und welche sind im AD konfiguriert? Wie sieht das Routing zwischen den Standorten aus? Melden sich an den Standorten nur Clients des jeweiligen Standorts an, oder habt ihr Roaming Users? Wie werden die Clients mit IP-Adressen versorgt? Ich nehme mal an, dass ihr die DCs nachträglich an die AD-Standorte verschoben habt. In solchen Fällen verbleiben meist die DNS-Einträge am Hauptstandort, sodass die Standort-DCs über DNS auch am Hauptstandort gefunden werden. Prüf das mal. Gruß, Nils

Moin, ähhh ... mit "Root-Server" meinst du separate Server bei einem Hoster? Und noch dazu hängen die direkt am Internet? Welchen Grund gibt es, so etwas einzurichten? Das hört sich an, als sei es weit entfernt von jeder Best Practice. Gruß, Nils

Moin, naja, was soll man sagen - du hast zwei Domänen, die einander nicht vertrauen. Jede Domäne lässt dann nur User aus ihrem eigenen Hoheitsbereich zu. Stell es dir wie zwei Länder vor, zwischen denen die Grenzen geschlossen sind. Gruß, Nils

Moin, aber Domänen-Benutzer sind ja auch alle User ... Die obige Angabe ist übrigens nicht ganz richtig. Freigabeberechtigungen haben keine höhere Priorität. Tatsächlich ist es so, dass Freigabeberechtigungen und NTFS-Berechtigungen unabhängig voneinander evaluiert werden (weil verschiedene OS-Komponenten dafür zuständig sind). Von beiden gilt dann das Restriktivere. Beispiel: Freigabe effektiv Ändern, NTFS effektiv lesen --> User darf nur lesen Freigabe effektiv lesen, NTFS effektiv Vollzugriff --> User darf nur lesen In fast allen Situationen ist es am besten, auf Freigabeebene "Jeder: Vollzugriff" zu setzen (sog. Null-ACL), weil dann die NTFS-Berechtigungen immer 1:1 gelten. Spart erheblich Komplexität. Zum Rest ist vielleicht dies von Interesse: faq-o-matic.net » Windows-Gruppen richtig nutzen Gruß, Nils

Moin, dann hoffe ich nur, dass Acronis die Snapshots dann auch wieder mit der VM zusammenführt - da das in Hyper-V 2.0 aber ein Herunterfahren (nicht Neustarten) der VM erfordert, wage ich das zu bezweifeln. Nicht zuletzt aus diesem Grund sehe ich Host-basierte Backups als problematisch an. Aber gut, dass dein Zugriffsproblem gelöst ist. Gruß, Nils

Moin, in solchen Fällen ist es meist am besten, den Importprozess vorzubereiten: Erst Datei lokal kopieren, dann die lokale Kopie importieren. Damit umgehst du auch Netzwerkprobleme während des Imports. Gruß, Nils

Moin, von welcher Anzahl Empfänger reden wir denn? Gruß, Nils

Moin, das liegt vermutlich daran, dass der Dienstaccount des SQL Server keine Zugriffsrechte auf den Share hat. In dem Moment, wo du das lokal am Server machst, existiert eine Session zwischen SQL Server und File Server im Kontext deines Admin-Kontos. Machst du das remote, besteht keine solche Session, und dann geht es nur über den Dienstaccount des SQL Server. Gruß, Nils

Moin, indem du die Reihenfolge in deinem Batch änderst und erst die abhängigen Dienste beendest. Gruß, Nils

Moin, nein. Der übliche Weg geht über einen separaten Backupserver, an dem das Band hängt und wo die zentrale Instanz der Backupsoftware läuft. Die VMs nutzen dann Agenten, wenn sie auf Applikationsebene gesichert werden sollen. Typisches Missverständnis. Mit der Standard-Edition darfst du genau eine Lizenz produktiv verwenden - entweder auf dem physischen Server (wenn dort produktive Dienste laufen) oder in einer VM (wenn auf dem Host nur Hyper-V und keinerlei produktive Dienste laufen). Sobald dein Host noch andere Dienste ausführt (wie etwa den zentralen Backupserver), belegt er die Lizenz, und du musst jede VM einzeln lizenzieren. Windows-Lizenzen in VM-Umgebungen Gruß, Nils

Moin, das ist eine nicht empfohlene Konfiguration: faq-o-matic.net » Warum der Hyper-V-Host keine (!) weiteren Dienste ausführen sollte Abgesehen davon, dürfte die Konfiguration eine zusätzliche Lizenz für den Host erfordern. Die Sicherung auf Applikationsebene erfolg in deiner Konstruktion über Agenten der Backup-Software für die jeweilige Applikation. Gruß, Nils

Moin, die Antwort hängt natürlich entscheidend von der Monitoring-Software ab, die du einsetzt ... Gruß, Nils

Moin, ach nee, plötzlich doch? Und warum sagst du das nicht gleich und auch auf Nachfrage nicht? Jetzt mal Butter bei die Fische: Was genau hast du am Ende vor? Es bringt doch nichts, wenn wir dir hier -zig Lösungen vorschlagen und am Ende kommt immer noch was. Sag gleich, was du vorhast, dann können wir dir einen geeigneten Weg vorschlagen, das eigentliche Ziel zu erreichen. Welche Daten brauchst du genau? Welche Applikation soll das verarbeiten? Was soll die Applikation mit den Daten machen? usw. usf. http://support.microsoft.com/kb/555375/en-us Gruß, Nils

Moin, "seit den letzten Snapshots" ... du weißt, dass Snapshots für Produktion nicht gedacht, nicht empfohlen und je nach Applikation auch nicht supported sind? Du kennst darüber hinaus die Auswirkungen von Snapshots auf Speichervolumen und Performance? faq-o-matic.net » Hyper-V: Vorsicht mit Snapshots! In dem Zusammenhang würde ich nicht ausschließen, dass das Dateisystem stark fragmentiert ist und der Fehler daher rührt. Gerade beim Hantieren mit vielen Snapshots passiert sowas leicht. Gruß, Nils

Moin, aha. Dann ist "net user /domain > meineDatei.txt" im CMD-Fenster die einfachste Variante. Dafür braucht man nun wirklich kein VBS. Du willst doch was anderes? Dann wäre jetzt eine gute Gelegenheit, dich zu erklären. Gruß, Nils

Moin, was soll denn am Ende dabei herauskommen? Oder anders gefragt: Welche Aufgabe bzw. welches Problem möchtest du am Ende mit deinem Skript lösen? Gruß, Nils

Moin, das FSMT macht ganz was anderes, was du durch Lesen der Beschreibung und etwas Googeln sicher auch schon herausgefunden hast. Anderswo wurde gerade dies hier empfohlen, ich habs mir noch nicht selbst angesehen: Free NTFS Permissions Analyzer Tool for Active Directory Gruß, Nils PS. Bitte nutze die Shift-Taste, deine Tastatur hat extra zwei davon.

Moin, da ich den Code eurer Vorlage nicht kenne und darüber hinaus auch kein Office-Entwickler bin, kann ich dir das leider nicht sagen. Allgemein wirst du hier aber auch keine fertigen Lösungen serviert bekommen, sondern Hinweise bei konkreten Fehler- oder Problemsituationen. Hinweise zum Auslesen von Werten aus dem AD findest du im Internet einige, z.B. hier: faq-o-matic.net » Ein AD-Attribut zu einem Logon-Namen herausfinden Gruß, Nils Gruß, Nils

Moin, ja, natürlich, das geht. Ihr müsstet also die Formeln in eurer Vorlage so ändern, dass sie die lokal gespeicherte Datei auswerten, statt eine Verbindung ins AD aufzubauen. Die Daten selbst kann man, wie du vorschlägst, z.B. mit einem VBS-Skript beim Logon aus dem AD lesen und in eine Datei schreiben. Falls kein Connect zum AD besteht, bleibt die Datei unangetastet. Gruß, Nils

Moin, wenn überhaupt, einen A-Record, und natürlich keinen Wildcard, sondern den Eintrag für www. Gruß, Nils

Moin, das scheint (leider) Standard bei lokalen Konten zu sein. Ist aber wirkungslos, solange es eine Kennwortrichtlinie gibt, die keine leeren Kennwörter zulässt. Noch eine Möglichkeit, warum es scheitern kann: Im Kennwort darf nicht der Anmeldename und auch kein "Token" daraus auftauchen (wenn der User etwa "Admin-Horst" heißt, darf weder der ganze Name noch "Admin" noch "Horst" im Kennwort enthalten sein). Gruß, Nils

Moin, erzeuge dir eine Benutzerdefinierte Ansicht nach deinen Anforderungen und speichere die Events von dort. Du kannst dabei das EVTX-Format auswählen, das man mit Vista/7/2008/R2 lesen können sollte. Vom Kürzen des Eventlogs rate ich grundsätzlich ab. Gruß, Nils

Moin, nein. Das Grundverhalten kommt vom Server. Alles Spezielle muss man in der Applikation regeln. Der Treiber stellt i.W. nur die Verbindung her. Gruß, Nils