saftnase

Seit 2008 ist die integrierte Serversicherung dazu in der Lage. (VSS Sicherung) Habe es seither mehrfach im Einsatz (auch schon mehrfach mit erfolgreichem Restore :-) )

1 TB SSD kann man machen, muss es aber nicht :-) Nee, ernsthaft jetze. SSDs bringen dir hauptsächlich einen Geschwindigkeitsbonus beim lesenden Zugriff, schreibend relativiert sich das Verhältnis Performance/Euro recht ernüchternd. Aber in deinem Einsatzszenario sehe ich kein Kriterium, bei dem du mit deiner Konfiguration gegen die Decke schlägst. A) Du hast nur 2 User auf dem TS, also ist RAM kein Problem B) Du setzt vermutlich Datev für ein Steuerberatungsbüro ein. Das ist auch nicht unbedingt eine Killer Applikation für den SQL Server bei 2 Usern. C) Mach dir ernsthaft Gedanken um deinen Recoveryplan. Wiederherstellung aus Snapshot ist bei einer VM eine Sache von Sekunden/Minuten, aber wenn die Hardware Schrott ist, muss erstmal Ersatz her. Und wenn der Snapshot auf der HDD lag isser eh Geschichte. Dann lieber spiegeln und darauf vertrauen, dass nicht beide Platten auf einmal über den Jordan gehen. Mein Vorschlag wäre: - Deinen Datastore für die VMs im Server auf einem gespiegelten Volume, Snapshots ebenfalls auf diesem Volume. Wie oft kannst du selbst am Besten beurteilen. - Backup der SQL DB und Logs auf einer externen Platte (USB oder eSATA) am Server oder auf ein NAS - Täglich ein Image Backup des SQL-Servers (ohne Datenbereich) auch auf den externen Bereich. Für n TS reicht ein Backup pro Woche, bzw. vor jeder Softwareinstallation.

Wäre schon seit Jahren mein Wunschtraum wenn das gehen würde. Citrix/XENAPP kanns auch in der aktuellen 7.6 nicht.

Frag mal Tante Google nach Robocopy GUI Die jungen Hüpfer wissen eine Commandozeile einfach nicht mehr zu schätzen. :D

Ein Archivsystem mit Robocopy zu bauen ist sicher keine gute Idee, aber so wie ich es verstanden habe, will er ja nur die Files aus einem aktuellen Zugriffsbereich in eine Art Historie überführen. Ich hatte auch mal so eine Anforderung und bin damals bei Robocopy hängen geblieben, weil es am zuverlässigsten funktioniert hat und viele Optionen bot. Dabei sollten die Einzelbilder einer Webcam gesichert/archiviert werden, so dass immer nur die letzten 24 Stunden im Webcam Verzeichnis waren und der Rest in die History wandert. Eine Alternative wäre auch Personal Backup http://personal-backup.rathlev-home.de/ Das kann die Files wenn nötig auch gleich zippen und nach dem Backup ein externes Programm ausführen. Aber das alles ist natürlich von einer richtigen Archivierung meilenweit entfernt.

Maaaaaaaaaahlzeit, das klingt nach einem Job für das gute alte Robocopy :D Kost nix und hat nicht nur viele Möglichkeiten verschiedene Selektionskriterien zu verwenden, sondern auch noch einen Monitormodus der automatisch im Hintergrund läuft. Nur die Sache mit den Links müsstest du mit einem eigenen Skript lösen in dem du auf die ausführlichen Logs von Robocopy zugreifst.

Ein sogenanntes Cold Backup ist nicht lizenzpflichtig, da es ja nicht gleichzeitig zu dem lizensierten System genutzt wird. Erst wenn du es z.B. in einem Replikationsverbund laufen lässt, musst du eine zusätzliche Lizenz opfern. Aber wenn du eine offline Kopie anfertigst, die nur im Fehlerfall hochgefahren wird, ist das ok. Ein Backup auf Band wäre damit vergleichbar. Der Nachteil ist halt der Datenverlust zwischen Livesystem und dem Stand des letzten Backup Eine Möglichkeit zur Livemigration (z.B. vMotion) also das verschieben des laufenden Systems auf einen anderen Host, benötigt eine volle Lizenz für jeden Host in deinem Cluster der fähig ist das System auszuführen. Find ich zwar unverständlich (weil ja trotzdem nur eine Instanz ausgeführt und genutzt wird) und unfair, aber so stehts in deiner Lizenzvereinbarung. Ich hatte dieses Jahr schon das Vergnügen eines Lizenzaudits :nene: Daher ist mir das alles noch ganz frisch im Gedächtnis :D @Nils In der Variante mit 3 Hosts waren alle Lizenzsierungsformen finanziell gesehen nur knapp einen Tausender auseinander. Und witzigerweise war die Variante Runtime mit SA (also die verkrüppeltste von allen) sogar die teuerste.

Jupp, war aber schon Funktionslevel 2008.

Maaaahlzeit Nils, ich habe die ganze Prozedur, wie oben beschrieben, schon mal durch geführt (eigentlich sogar 3 mal). Nur eben jedesmal auf den W2K8 DCs. Dabei wurden dc, gc und Domains zwar in der neuen Zone _msdcs.example.com angelegt, aber der pdc Eintrag erstand immer wieder unter example.com_msdcs auf. Erst als ich die Prozedur auf dem W2012R2 durchgeführt hatte wurden alle Einträge korrekt angelegt. Und soweit ich mich beim flüchtigen googeln erinnere, hieß es dass der Speicherort für die _msdcs Einträge mit Windows 2008 oder 2008R2 geändert wurde.

Wenns am Geld klemmt kannst du dich auch mal im Renew Bereich umschauen. Meist gibt es Geräte aus Democentern oder Rückläufer zu guten Konditionen und sogar mit neuer 3 Jahres Garantie. Ich hab 2/3 meiner Infrastruktur aus Renew Komponenten und keine Probleme.

Naja denk mal an den AdminSDHolder. Wenn man alles löscht und die Einträge immer wie von Zauberhand an der falschen Stelle zurückkehren. Und das obwohl DCDiag keinen Fehler meldet, dann kommt man schon ins zweifeln. Aber ich habs mittlerweile selbst gelöst. Musste nur meine Domäne in example.com umbenennen und schon klappts. :D OK, Spaß beiseite ;) Lag daran, dass sich W2K8 DCs eher wie 2003 verhalten und den PDC unterhalb der Domäne anlegen. Komischerweise aber nur den. Alle anderen (gc, dc und Domains) wandern brav in die Primäre Zone _msdcs.EXAMPLE.COM Erst ab W2K8R2 verhält sich das AD korrekt. Falls jemand in Zukunft mal das Problem hat, hier der Lösungsweg: 1. Auf allen DCs den fehlerhaften Eintrag _msdcs unterhalb der Domäne löschen. 2. Auf dem neuen W2012R2 DC nur die eigene IP als Nameserver eintragen. 3. Auf dem W2012R2 DC den Anmeldedienst neu starten um den Eintrag neu zu erzeugen 4. Warten bis die Änderung auf dem alten W2K8 DCs angekommen ist 5. Auf den Erfolg anstoßen :D Habe die Ehre

Na dann danke ich mal für die erhellenden Kommentare und verabschiede mich. :jau:

Na Geduldiger als 2 Tage muss man im AD eigentlich ned sein. Hab sogar den 2012R2 Server zum PDC gemacht. Die Änderung war sofort auf allen 3 Servern im DNS eingetragen. Nur leider am falschen Ort. Ich tippe eher auf ein Problem/Fehler im AD Schema. Aber wo ? @magheinz Echt jetzt ? Mich stört eher, wenn man eine sachliche Frage zu einem komplizierten Thema stellt und statt einer fachlichen Meinung eine Grundsatzdiskussion über ein völlig anderes Thema geführt wird. Ersetz einfach mydomain.de mit contoso.com Ich bitte meinen Mangel an Kreativität zu entschuldigen. Bin einfach kein I-Typ. :-)

Maaaaahlzeit zusammen, ich knusper grad (außer an den Adventskeksen) an einem Problem mit meinem AD DNS. Meine Domäne (ich nenn sie mal mydomain.de) ist aus dem Jahr 2002 und wurde unter W2K installiert. Damals wurde die Zone _msdcs noch unterhalb der Primären Zone mydomain.de eingerichtet. Über die Jahre wurde die Domäne zuerst auf 2003, dann auf 2008 raufgestuft. Nun möchte ich die Domäne wieder auf ein aktuelles Level 2012R2 hieven. Die Installation eines neuen DC 2012R2 mit DNS Server hat funktioniert und ich habe den BPA angeworfen. Dieser kritisierte natürlich sofort, dass er die AD integrierte Zone _msdcs.mydomain.de nicht finden kann. Eine kurze Googleminute später fand ich den Hinweis, dass diese Zone nun ebenfalls eine primäre Zone sein muss (auf gleicher Höhe wie meine Domäne). Also Zone unterhalb der mydomain.de gelöscht, Zone im DNS manuell angelegt, Anmeldedienst und DNS Dienst neu gestartet. Soweit alles ganz schick. Die Zone _msdcs.mydomain.de enthält die Zweige dc, Domains, und gc Nur der pdc fehlt, bzw. wird wieder unterhalb der Domäne am alten Platz angelegt. Und der BPA meckert jetzt natürlich wieder dass er _ldap._tcp.pdc._msdcs.mydomain.de nicht auflösen kann. Hat einer ne Idee woran es liegen könnte ?

Maaaaaahlzeit, so wie du das Problem beschreibst, liegt die Ursache entweder im Storage oder (mein Favorit) softwareseitig am SQL Server (RAM, Cachenutzung, ...) Prüf als erstes die physikalische Anbindung (FC oder SAS Kabel, bzw. iSCSI Konfig und Netzwerkadapter) deines Storage und kontrollier die Logs. Oder kopier die ganze Datenbank von einem Volume auf ein anderes. (DB natürlich vorher beenden) Dann bekommst du schon mal einen Eindruck wie schnell dein System Storagezugriffe abarbeitet. Für die Prüfung bzw. der Beurteilung der Performance deines SQL Servers solltest du dich an jemanden mit Erfahrung in der SQL-Administration wenden. Den SQL-Server auf dem TS auszuführen ist wirklich keine gute Idee. Du solltest dir die Frage stellen, ob deine IT nicht eine Größe angenommen hat, in der es sich empfiehlt die Rollen und Dienste zu trennen.