NilsK

Moin, so ohne Weiteres (leider) erst mal gar nicht. Die administrativen Zugriffe, die dich interessieren, kannst du in der Default Domain Controllers Policy im Computerzweig definieren. Die Protokolleinträge finden sich dann im Security-Eventlog des jeweiligen DC. Wohlgemerkt: Jedes einzelnen DC; um eine Gesamtansicht zu erhalten, musst du also alle DCs überprüfen. Zusätzlich stehst du dann noch vor dem Problem, dass das Security-Eventlog sehr unübersichtlich ist, weil zu einem einzelnen Zugriff oft zahlreiche Einträge gehören. Das musst du dann also auch noch auswerten bzw. filtern. Seit Windows Server 2008 kannst du dann noch das erweiterte Logging aktivieren und so die Detailtiefe erhöhen - du siehst dadurch z.B. bei Änderungen den "alten" und den "neuen" Wert. Auch das richtet man in der DDCP ein, allerdings an etwas anderer Stelle. Lösen musst du dann in jedem Fall das Log Management - also die Datenmenge und die Auswertung. Hierzu gibt es auch kommerzielle Werkzeuge. Gruß, Nils

Moin, mal ganz nebenbei gefragt: Mit was für Lizenzen arbeitest du denn da? Und wer nutzt das Ganze hinterher? Gruß, Nils

Moin, vor allem musst du dich von dem Gedanken verabschieden, dass die virtuellen Netzwerke in Hyper-V so funktionieren würden wie in VMware Workstation. Die Szenarien für beide Produkte sind völlig unterschiedlich. Ein vSwitch in Hyper-V hat auch keine IP-Adresse. Ebenso verteilt er keine IP-Adressen an Gäste und führt keine Adressübersetzung und kein Routing durch. Die Konfiguration, die in dem oben verlinkten Video gezeigt wird, ist für Heim- oder Testnetzwerke machbar, in der professionellen Serverwelt lässt man sowas bleiben. Gruß, Nils

Moin, darüber hinaus erscheint es mir etwas unortrhodox, ausgerechnet Management und Live Migration zu koppeln. Das Management-Netz nutzt du, um die Hosts zu verwalten sowie für deren Anbindung an AD und WSUS. Die Live Migration hingegen findet nur zwischen den Hosts statt, da willst du normalerweise möglichst wenig anderen Traffic. Ohne näher draufgeschaut zu haben, käme mir als Skizze Folgendes in den Sinn: Team 1: VM-Netz, vSwitch drauf, keine Konfig im Management-OS 2 Karten ohne Team, aber mit MPIO für das SAN (vermutlich iSCSI) - i.d.R. alles außer IP abschalten, eigenes iSCSI-Netz, kein Routing, kein DNS/WINS 2 Karten oder ein Team für Cluster, CSV und Live Migration - Protokollbindungen weitgehend belassen, aber ein eigenes Netz und i.d.R. kein Routing, kein DNS/WINS 1 Karte oder Team für Management - normale Konfiguration Das Management-LAN zu separieren, ergibt nur dann Sinn, wenn es auch tatsächlich ein separates Management-LAN gibt. Das ist in vielen mittleren Umgebungen nicht der Fall - dann könnte man das Management über dasselbe Netz laufen lassen wie die VMs. Denkbar wäre auch ein großes Team aus sechs Karten für VM, Cluster und Management mit mehreren vNICs in der Parent Partition und Separation über VLANs und Bandbreiten-Garantien (geht nur per PowerShell). Das iSCSI würde ich auch in dem Fall über zwei separate Karten mit MPIO laufen lassen. Gruß, Nils

Moin, ja, aufnehmen kannst du den Server. Und ja, du kannst ihn hinterher auch hochstufen. Die nötigen Schritte dazu führt der Server-Manager automatisch aus (Schema erweitern, Forest und Domäne anpassen). Den Betriebsmodus kannst du aber erst dann hochsetzen, wenn die 2003-DCs deinstalliert sind. Gruß, Nils

Moin, mal ganz abgesehen davon - wie willst du denn die Daten auf den NAS-Büchsen synchron halten? Mir scheint das doch noch nicht recht durchdacht ... Warum nicht die User zu den Daten holen statt die Daten zu den Usern? Mit einer Terminalserverumgebung lässt sich die Arbeit evtl. über beide Standorte gut zentralisieren. Gruß, Nils

Moin, prima, danke für die Rückmeldung! Gruß, Nils

Moin, der Hinweis ist unnötig kompliziert geraten. Eigentlich sagt er nur: Dieser Server nutzt sich selbst als DNS-Server. Wenn du jetzt das AD entfernst, hat er keine DNS-Daten mehr und kann damit auch nicht mehr als DNS-Server antworten. Du musst daher die lokale IP-Konfiguration so ändern, dass der Server einen anderen DNS-Server fragt. Also alles sicher an der Stelle. Aber warum willst du /forceremoval machen? Reicht dcpromo nicht aus? Gruß, Nils

Moin, da fängt es schon mal ganz schlecht an, wenn du in Exchange kein Profi bist. Wenn ihr tatsächlich sowas aufbauen wollt, braucht ihr Profis. Glaub mir. Gruß, Nils

Moin, sehr hübsch in diesem Zusammenhang der Titel dieses Threads: Microsoft beschlagnahmt?! Ich glaub auch. Gruß, Nils

Moin, vielleicht ist der File Server Resource Manager hier hilfreich. [Generieren von Speicherberichten] http://technet.microsoft.com/de-de/library/cc731206%28v=ws.10%29.aspx Einfache Lösungen dürften bei dem angegebenen Volumen zu viel Last erzeugen. Gruß, Nils

Moin, Dukel hat völlig Recht: Dein Skript wird von oben bis unten abgearbeitet (es gibt darin ja keine Verzweigungen). Da du insgesamt elf Insert- bzw. Update-Statements hast, von denen jedes eine Ergebniszeile erzeugt, bekommst du auch elf Meldungen zurück. Die Meldung "1 Zeile betroffen" heißt, dass das betreffende Statement in der Tabelle, auf die es sich bezieht, eine Tabellenzeile hinzugefügt bzw. geändert hat. In Dukels Beispiel ist die Tabelle oder View "dbo.tm_stueckliste_pos" um eine neue Zeile erweitert worden. Das ist hier also relativ einfach zuzuordnen, indem du durchzählst. Gruß, Nils

Moin, lizenzrechtlich ist es egal, wie viele Accounts oder Mailboxen man anlegt - es zählt ohnehin die Anzahl der User (= natürliche Personen) oder der Endgeräte, je nach CAL-Zuweisungsmodell. Technisch ist es auch kein Problem, denselben Account durch mehrere User zu verwenden. Das sollte auch bei gleichzeitiger Nutzung eigentlich kein Problem sein (hier korrigiere man mich, falls das bei einer Exchange-Mailbox doch problematisch sein sollte). Bleibt also nur die organisatorische Ebene. Gruß, Nils

Moin, okay, und was genau ist jetzt deine Frage? Das Skript enthält ja eine ganze Reihe von Update- und Insert-Anweisungen. Jeweils hinter dem Kommando siehst du, welche Tabelle (oder View) dadurch bearbeitet wird. Wenn das ganze Skript ausgeführt wird, solltest du pro Statement eine Ergebniszeile ("47 rows affected") sehen. Da du von zwei Ergebniszeilen sprichst, ist wohl nicht das ganze Skript ausgeführt worden. Die Ausgabe, welche Tabelle betroffen ist, ist nicht vorgesehen. Wenn du das für Debuggingzwecke brauchst, müsstest du selbst Textausgaben in das Skript einbauen. Gruß, Nils

Moin, die Definition von "unternehmenskritisch" ist bei dem Supportangebot, das wir hier diskutieren (und das nur für Partner gilt - es geht hier übrigens um kostenlosen Support) ziemlich eindeutig festgelegt. Ich finde die Definition auch sehr nachvollziehbar und völlig legitim. Wenn bei einem Kunden "der Betrieb steht", weil ein Microsoft-Produkt ausgefallen ist, kann der Partner kostenlosen Support bekommen. Ein Backup, das anscheinend schon seit Wochen nicht funktioniert, fällt ausgesprochen deutlich nicht in diese Kategorie. Dafür muss man dann eben den normalen, kostenpflichtigen Support in Anspruch nehmen. Diese Diskussion führt zu nichts mehr. Wir können das hier beenden. Gruß, Nils PS. In was für einer Gegend lebst du, dass dort 500 EUR Stundensatz verlangt werden?!

Moin, unterbrochen wird die Produktion durch den Crash, nicht durch die fehlende Vorsorge. Anscheinend lässt sich der Kunde ja auch nicht am Weiterproduzieren hindern. Aber das ist eine Diskussion, die dann andere führen müssen. :D Gruß, Nils

Moin, poste doch bitte mal dein Kommando. Normalerweise wirkt ein INSERT exakt auf die angegebene Tabelle. Zwar gibt es die Möglichkeit, abhängige Datensätze zu manipulieren (z.B. Löschweitergabe), bei einem INSERT wäre das aber sehr unüblich. Das würde dann i.d.R. per Trigger gesteuert. Allgemein ist es aber, wenn du auf Datenbankebene manipulierst, durchaus sinnvoll und je nach Situation erforderlich, sich ausgiebig mit der Datenbank selbst und mit der dahinterliegenden Geschäftslogik zu befassen. Das kann auch schon mal sehr viel Zeit in Anspruch nehmen. Gruß, Nils

Moin, ah, OK, danke für die Info. Das ist in diesem Fall dann aber wohl nicht anwendbar, denn eine nicht funktionierende Datensicherung dürfte nicht als "unternehmenskritisch" gelten. Das gilt nur für Fälle, in denen die Arbeitsfähigkeit des Unternehmens unterbrochen ist. Da das Problem ja schon eine längere Zeit besteht, ist das nicht gegeben. Gruß, Nils

Moin, ich kann nicht für Microsoft sprechen, aber ich würde vermuten, dass man in dem Fall das Ziel so formulieren könnte: "Es soll mit Windows Server Backup eine regelmäßige Sicherung der Exchange-Daten auf dem System XYZ erzeugt werden." Der Start-URL, den du gefunden hast, dürfte der richtige sein. Gruß, Nils

Moin, du kannst bei Microsoft Einzelcalls eröffnen oder einen Supportvertrag abschließen. Für Ad-hoc-Unterstützung sind Einzelcalls die einfachste und günstigste Variante. In einem Action Pack sind, glaube ich, keine Calls enthalten. Der einzelne Call kostet ca. 300 Euro. Dafür gibt es einen Vertrag zu Beginn, mit dem man sich zur Bezahlung verpflichtet. Bei der Eröffnung legst du mit dem Supporter das Ziel der Unterstützung fest - es muss sich um ein einzelnes, abgrenzbares Problem bzw. Ziel handeln. Das wird dann gemeinsam gelöst. Die Kosten sind pauschal. Sollte das Problem auf einen Fehler in der Software zurückzuführen sein, bekommt man das Geld zurück. Der Call bekommt eine eindeutige ID und kann so nachverfolgt werden. Du bekommst einen festen Ansprechpartner und vereinbarst mit diesem das Vorgehen und die jeweiligen Termine. Gruß, Nils

Moin, naja, ein Komplettrestore beinhaltet das Zurückspielen einer vollständigen Datensicherung. Wie das geht, hängt von deiner Backupsoftware und von dem Sicherungsverfahren ab. Jedenfalls würde ich der vorhandenen Installation nicht mehr trauen. Wer weiß, was da noch im Argen ist. Gruß, Nils

Moin, aha. Und wie hast du dich angemeldet, um das festzustellen? Ich würde jedenfalls keinen Teil-Restore machen, sondern einen Komplettrestore. Gruß, Nils

Moin, wir verlassen hier aber gerade das Thema (und sollten auch nicht die 4711. vSphere-gegen-Hyper-V-Diskussion aufmachen). Gruß, Nils

Moin, und erwartet, dass es da anders ist? ROTFLBTC ... Dann viel Erfolg bei dem Versuch, Windows Server 2012 R2 auf einer fünf Jahre alten Version von ESX zu betreiben (denn genau das wäre das technische Pendant zum hier diskutierten Szenario). Gruß, Nils PS. Ich selbst könnte auch nicht nachvollziehen, warum man Hyper-V 2008 R2 einsetzen will, wenn man 2012 R2 besitzt ... wirklich nicht.

Moin, ich stimme Norbert zu, dass das AD für so einen Zweck nicht gut geeignet ist. Gleichzeitig verstehe ich den Gedanken, die Kontakte an einer einfacher zugänglichen Stelle zu halten. Zwei Ideen dazu: Umstellen auf Sharepoint: Sharepoint-Ordner kann man in Outlook ebenso gut einbinden, gleichzeitig sind sie ohne Exchange-Mailbox nutzbar Import in ein separates LDAP-System: man könnte die Kontakte z.B. in eine ADLDS-Instanz importieren und diese als LDAP-Server nutzen In beiden Fällen wird man weiterhin eine eigene Einbindung bei den Clients vornehmen müssen. Da aber, wie gesagt, externe Kontakte zur allgemeinen Nutzung in AD nicht sinnvoll unterzubringen sind (GAL wird sehr groß, Pflege der Kontakte ist heikel usw.), rate ich in solchen Fällen stets zu einer separaten Ablage. Gruß, Nils