Weingeist

@Blazilla: Klar. Klingt alles gut. Was Strom leitet, kann auch kaputt gehen. Deshalb bleibt eine einzelne SAN nunmal ein SPOF. Kann man drehen und wenden wie man will. RPO wird bei deren Ausfall kaum erreicht. Wird das nicht kommuniziert, belügt man den Kunden oder muss ein entsprechendes Backup-Storage im Köcher haben (woran man in der Regel sparen muss). Am Rande: Ein Ausfall der Main-Backplane wo die RAID-Controller drauf sitzen verkraften die wenigsten. Auch Zusatz-Shelfs sterben nicht immer sauber weg. Ein Kleinbetrieb kauft zudem selten die Middle- oder Topausführung der Hersteller oder gar gespiegelte Storages. Solche mit Transparentem Failover schon gar nicht. Neben den Investitionskosten sind auch die Wartungskosten hoch. Mir sind daher Server die gegenseitig repliziert werden lieber. Das ist immer Ruckzuck, mit konsistenten DB's wieder oben wenn mal was in die Hose geht. Ohne grossen Aufwand und Komplexität. Je nach Lösung und Datenaufkommen quasi ohne Datenverlust. Bevor mir wieder das Wort im Mund umgedreht wird: Kleinumgebungen mit ein paar Server. Um zum eigentlichen Thema zurück zu kommen: @dieDally: - Bei 80 Desktops eine VDI oder quasi VDI betreiben wenn die Lizenzkosten für RDP schon gescheut werden ist schwierig. Grund: Du kannst sicher keine OEM-Office verwenden sondern brauchst Volumenlizenzen. Office OEM auf konsoldierten System ist ein Lizenzverstoss (ausser Office bis 2003). - Desktops zwischen Hosts verschieben geht nur mit SA oder VDA. Bei beidem bist Du verpflichtet jährlich zu bezahlen damit es geht. Keine Auskaufmöglichkeit. Aktuell besteht aber die Möglichkeit mehrere Lizenzen einem System zuzuweisen. - Du willst auch Linked Clones oder etwas ähnliches. --> Masterimages, das kostet wieder Geld (View, Citrix, ...) sonst ist ein grosser Verwaltungsvorteil weg. (Wobei: HyperV 3 hat dafür auch was neues im Köcher, keine Ahnung wie gut das funktioniert und was es noch braucht) - Bricht dein Storage weg (auch wenn selten), dann hast Du je nach Schaden ein massives Erklärungsproblem wenn du dem Chef zuvor eine teure SAN verkauft hast mit der Begründung, dass eben Ausfälle nur von kurzer Dauer sind und das Geld nicht für ein einigermassen performantes Notsystem reicht. Da hilft es herzlich wenig wenn es normalerweise nicht passiert. Bei der Betrachtung der reinen Lizenkosten wirst die Schlacht aber sowieso verlieren und die RDP-Lizenzen erscheinen im Gesamtkonzept geradezu günstig. Zentrale Verwaltung und gute Anbindung hättest auch mit physischen Maschinen im Serverraum. Deployment und Wartung aufwendiger aber auch vereinfachbar. Günstig wärs mit zbsp. Atom-PC's (soferne ausreichend). Geht dann je nach Konzept wieder mit OEM-Software. Möglichkeiten gibts hier auch einige die einen sinnvoll die anderen weniger, von physisch normal über einer VM pro Maschine, Wartung und Deployment bia IPMI usw. Hast Du viele gleiche Desktops, fährst Du aber vermutlich besser und einfacher mit TS. Wie du siehst, es gibt nix umsonst was das Admin-Leben vereinfacht und die RDP-Lizenzen sind mit Abstand der kleinste Posten. Ich bin happy wenn ich via RDP durchkomme anstelle von VDA. ;)

Wie bereits gesagt, das geschieht, wenn Du auf einem SBS 2008 die WSUS Rolle aktualisierst. Da wird standardmässig eine veraltete installiert, 2008 ist ja schon ein paar Jahre alt. Dazu wird der alte WSUS normalerweise deinstalliert. Die alte Seite auf dem ISS bleibt aber erhalten. Allgemein zum SBS: Man weiss nie so richtig, was genau miteinander verhängt wurde oder was von Update-Rollups speziell für SBS für ein Zustand erwartet wird. Manchmal schlugen die Updates in der Vergangenheit (Pre 2008) wegen banalen Veränderungen fehl. Deshalb halte ich mich - nach einigen leidigen Erfahrungen unter NT, 2003 - generell an die Devise: Nichts am Standardverhalten des SBS ändern oder löschen was nicht zwingend nötig ist oder in einer HowTo von MS beschrieben worden ist. Und wenn, sehr sauber dokumentieren, damit man es für Updates rückgängig machen könnte. Erspart einem unter Umständen sehr viel Ärger. Glaube zwar ehrlich gesagt auch nicht, dass das löschen einen Einfluss hat, aber stören tut die deaktivierte Seite auch nicht. ;) Bei einem Update von SBS auf einen neuen Server und eine aktuelle Version ist das nicht von Belang, da ja der Server neu installiert wird. InPlace Update gibt es sowieso nicht.

@StefanWe: Die Backplane einer SAN ist auch eine Elektronisches Teil und kann im Prinzip genauso kaputt gehen wie jedes andere Elektronik-Teil auch. Die gibts nur einmal. ;) Nichts desto trotz mit einem Shared Storage hat man es von der Verwaltbarkeit einfacher. Wenn man aber nur eine hat, muss bei einem Ausfall unter Umständen ne Menge repariert oder frisch aufgesetzt werden. Alternative: Du nimmst local Storage und replizierst jeweils auf einen anderen Server. Stirbt einer weg, kannst die Replikate nehmen. Klappt mit Veaam zbsp. gut unter VmWare. Das neueste Hyper V kann aber auch selbständig replizieren. Wie gut und zuverlässig kann ich nicht sagen.

Das geschieht - soweit ich mich richtig erinnere - wenn der WSUS upgedated wurde. Sprich hast du einen etwäs älteren SBS und nachher ServicePacks und das neuere WSUS eingespielt, dann erstellt er Dir die Administrations-Seite. Ich hatte jeweils einfach die Seite "WSUS-Verwaltung deaktiviert". Unter Einstellungen Autostart zusätzlich auf False stellen. Ports musste man glaub keine mehr ändern, bin ich aber nicht mehr 100% sicher.

@Zahni: Wartung: Logisch, hier können aber Third-Party Erweiterungen wie es auch sonst für Windows gibt hinzukommen. Dafür gibt es API's, Schnittstellen und dergleichen. Für kleine und mittlere Umgebung reicht Benachrichtigung und auto Hotspare-verwendung völlig aus. Zu High-Performance: Schau dir mal die neuen Scale-Out-Features aus. Da sind nur die IOPS des Datenträgersystem die Limitierung. Ansonsten geschehen Reads über alle ClusterNodes gemeinsam. Quasi Out Of the Box. Aktuell extra für VHD's und SQL-Datenbanken. Zu den Pools: Da Windows es total egal ist wie gross die Platten sind, kann man einfach alles reinhängen was 'rumsteht'. Der Rest erledigt es selber aufgrund der Definition welche man für die virtuellen Datenträger angegeben hat. Die jeweiligen Platten sucht er sich selber aus. Es steht einem natürlich nichts im Wege - sofern man Windows nicht richtig traut oder als zusätzliche Sicherheit - erstmal RAID-Volumes als Basis für den Aufbau zu nehmen. Und noch eine gute Nachricht: Bei Pools funktioniert Trim trotzdem! sowohl mit NTFS als auch mit dem neuen. Habe da einen kleinen Fehler gemacht (leicht zu kleines Files für den Trim-Test verwendet). Zum ZFS: Das ist eigentlich richtig nett. In der höchsten Ausbaustufe, die allerdings auch nicht günstig zu haben ist, sogar mit transparentem Failover über mehrere Nodes. Dazu extrem gutes Dedup, übelste Performance (trotz verwendung von SATA Platten, weil Read und WriteCaching machbar, sowohl mit SSD's als auch mit RAM). Da kannst zbsp. auch pro Block jeweils Doppel, Dreier, Viererpakete von HDD's oder soviel Du willst machen. Die DiskBlocks hängst dann zusammen. Speichererweiterung in dem du einfach einen identischen Block wieder dazufügst. Windows geht da aber weiter, da hängst einfach Platten rein und definierst in der virtuellen HD, was für Voraussetzungen sie erfüllen muss. Entweder mit JPOD's auf welche mehrere Server gemeinsam Zugriff haben oder eben auch direkt mit lokalen Discs oder iSCSI/FC Zielen. @ChristianZ: Die HostCPU muss Paritäten berechnen, das braucht sicher etwas mehr Leistung als Mirror-Lösungen. Da habe ich noch keine Tests gefahren, ist aber auch nicht meine Priorität. Ich verwende "nur" Mehrfachspiegel. Aber wie gesagt, bei den Leistungen welche heutige CPU's bringen, zusammen mit dem RAM-Cache, ich glaube da muss sich Windows den wenigsten Einsteiger oder Mittel SAN's geschlagen geben in Sachen Performance und mit den neuen Features sicher auch in Sachen Flexibilität. Ich kann von den IOPS-Werten in meinem TestLab auf meiner (für meine Verhältnisse) teuren SAN mit minimalen Features nur Träumen. ;)

@Zahni: Wartung: Logisch, hier können aber Third-Party Erweiterungen wie es auch sonst für Windows gibt hinzukommen. Dafür gibt es API's, Schnittstellen und dergleichen. Für kleine und mittlere Umgebung reicht Benachrichtigung und auto Hotspare-verwendung völlig aus. Zu High-Performance: Schau dir mal die neuen Scale-Out-Features aus. Da sind nur die IOPS des Datenträgersystem die Limitierung. Ansonsten geschehen Reads über alle ClusterNodes gemeinsam. Quasi Out Of the Box. Aktuell extra für VHD's und SQL-Datenbanken. Zu den Pools: Da Windows es total egal ist wie gross die Platten sind, kann man einfach alles reinhängen was 'rumsteht'. Der Rest erledigt es selber aufgrund der Definition welche man für die virtuellen Datenträger angegeben hat. Die jeweiligen Platten sucht er sich selber aus. Es steht einem natürlich nichts im Wege - sofern man Windows nicht richtig traut oder als zusätzliche Sicherheit - erstmal RAID-Volumes als Basis für den Aufbau zu nehmen. Und noch eine gute Nachricht: Bei Pools funktioniert Trim trotzdem! sowohl mit NTFS als auch mit dem neuen. Habe da einen kleinen Fehler gemacht (leicht zu kleines Files für den Trim-Test verwendet). Zum ZFS: Das ist eigentlich richtig nett. In der höchsten Ausbaustufe, die allerdings auch nicht günstig zu haben ist, sogar mit transparentem Failover über mehrere Nodes. Dazu extrem gutes Dedup, übelste Performance (trotz verwendung von SATA Platten, weil Read und WriteCaching machbar, sowohl mit SSD's als auch mit RAM). Da kannst zbsp. auch pro Block jeweils Doppel, Dreier, Viererpakete von HDD's oder soviel Du willst machen. Die DiskBlocks hängst dann zusammen. Speichererweiterung in dem du einfach einen identischen Block wieder dazufügst. Windows geht da aber weiter, da hängst einfach Platten rein und definierst in der virtuellen HD, was für Voraussetzungen sie erfüllen muss. Entweder mit JPOD's auf welche mehrere Server gemeinsam Zugriff haben oder eben auch direkt mit lokalen Discs. @ChristianZ: Die HostCPU muss Paritäten berechnen, das braucht sicher etwas mehr Leistung als Mirror-Lösungen. Da habe ich noch keine Tests gefahren, ist aber auch nicht meine Priorität. Ich verwende "nur" Mehrfachspiegel. Aber wie gesagt, bei den Leistungen welche heutige CPU's bringen, zusammen mit dem RAM-Cache, ich glaube da müssen sie sich den wenigsten Einsteiger oder Mittel SAN's geschlagen geben in Sachen Performance und mit den neuen Features sicher auch in Sachen Flexibilität. ;)

Anhang: Wie gesagt, der einzige Unsicherheitsfaktor den ich aktuell sehe - und auch schon genannt habe - ist was passiert wenn eine Disc sich langsam verabschiedet. Wie entscheidet Windows welche Disc nun der Übeltäter ist und teilweise falsche Sektoren liefert. Bei Dreifachspiegel wird er wohl sinnvollerweise jene behalten, welche die gleichen Ergebnisse liefern und die falschen nach zu vielem Vorkommen und selbstreperatur kappen. Werde ich bei Gelegenheit mal testen indem ich mutwillig manuell Müll auf die Sektoren schreibe. Wenn das funktionieren würde und er die zwei "guten" als Referenz nimmt und die "schlechte" selber repariert und nach zuvielem Vorkommen abhängt, Hut ab. Theoretisch sollte das SMART bei Enterprise-Laufwerken aber eh zuverlässig selber ankündigen. Zusammen mit iSCSI (was dankbarerweise auch endlich legal verwendet werden darf und nicht nur in Testlabs oder bei kauf des Storage-Servers) würde sich das ganze sogar komplett über mehrere Gebäude/Brandabschnitte zusätzlich gespiegelt erstellen lassen. Hochverfügbarkeit mit Standard-Server-Hardware und Transparentem Failover sowie teilweise Scale Out (also lesen von allen Nodes). Für die absolute Paranoia ;) Zu guter Letzt: Trim funktioniert bei der Nutzung von Pools leider nicht... Eventuell aber auch mit manuellem Killen von Sektoren Script/Anstossbar.

@zahni: Danke für die Anregungen. Die Anmerkungen die Du nennst habe ich vorher selber bereits angeführt (HotSwap, Systemlaufwerk etc.) und auch entkräftet. Siehe auch weiter unten, etwas ausführlicher. ;) Systemlaufwerk : darum ging es zwar nicht sondern um Datenplatten für VM's aber habe ich jetzt nicht extra getestet. Gehe davon aus, dass sich da nichts geändert hat (Diskbootsektoren). Dem kann man schon frühzeitig beikommen indem man sie direkt nach Erstellung des RAID's manuell auf den Spiegel schreibt oder die entsprechenden Werkzeuge bereit hält um es im Schadenfall zu tun. Ging früher schon. Aufwand ist für ersteres ist minimal. Zweiteres auch kein Hexenwerk wenn man wusste wie HotSwap : War das absolue KO-Kriterium für diese Funktion Sah aber früher auch ATA-Hotswap Systeme wo sogar das funktioniert hat, auch wenn ich es auch nicht glauben wollte. Genau das Funktioniet jetzt aber absolut tadellos. Habe während der ganzen Tests diverse unterschiedliche Workloads parallel laufen lassen Zugriff war nie unterbrochen.Auch nicht bei einem Benchmark I/O Test. Nicht beim Crashen, Entfernen der Offline Disk, Wieder spiegeln auf neue Disc usw. Sonst hätte ich den Thread sicher nicht eröffnet und das ganze nur als Lab-Spielerei abgetan. ;) Was mich überhaupt auf die Idee gebracht hatte, waren die neuen Features von Server 2012. MS wird kaum solche Funktionen ankündigen, wenn es nicht auch zuverlässig wäre. Also muss Hotswap funktionieren. Tut das, sollte es auch mit dynamischen Discs. Performance-GAU: Der ist minimalst mit aktuellen CPU's und beträgt unter Vollast 2-3% der CPU Auslastung, welche auch ohne Spiegel schon fast erreicht ist. Write IOPS gehen kaum feststellbar verloren im Vergleich zu einzelnen Discs, die Differenzen hatte ich auch bei Single-Discs. @Blazilla: Datacore und ZFS war wegen der Pauschalisierung, dass Software-RAID nix ist aufgeführt, nicht wegen SSD, Trim oder so. Das man auf nem einzelnen Node ein RAID als Untergrund hat, macht sicher auch bei Datacore Sinn. Was ich da meinte war ein Software-Spiegel über mehrer Nodes, welches den Guests präsentiert wird. ;) Bemerkung zum Server 2012: Der ist der Knaller wie ich finde. Bei der Verwendung der neuen Speicher-Features von Windows Server 2012. Speicherpools, welche quasi eine Erweiterung der dynamischen Datenträger sind, aber keinen Zusammenhang mit den beteiligten Festplatten haben. Windows macht Daten einfach irgendwo drauf wos Platz hat und schaut dass die Daten mindestens zwei oder auf Wunsch auf drei verschiedene physische Datenträger sind. Funktioniert astrein. Konnte das Dateisystem nicht korrumpieren. Nicht NTFS und das neue ReFs schon gar nicht (soll sich ja selbstheilen wens trotzdem vorkommt) Analysiert man die Daten auf den physischen Datenträger und den virtuellen Datenträger (die Datenrettungstools unter Windows erkennen alle, Windows Datenträgermanager nur noch die virtuellen) werden die Daten 1:1 abgelegt wie auf der virtuellen. Windows muss das intern irgendwie verlinken. Ist mit Datenrettungstools daher möglich trotz der Speichervirtualisierung die Daten wieder von den Festplatten zu holen bei einem absoluten Totalausfall. Brauche ich mehr Platz, hänge ich einfach Festplatten beliebiger Grösse rein, fügt sie dem Pool hinzu und habe wieder Platz. Bei Ausfällen: Hier macht Windows den Job gleich selber und stellt den Krempel einfach auf einer anderen Platte wieder her. Man kann man sogar extra HotSpares-Drives definieren. Ganz wie in physischen Speichersystemen. Kombiniert man das nun alles mit den neuen Transparenten Failover-Funktionen bekommt man für SMB 3.0 fähige OS für wenig Geld Enterprise-Features von sauteuren Storage-Lösungen. Dann noch der ReadCache im RAM (Bis 20%) und das Zeug rennt wie Hölle. Soweit die Theorie. Praxis wird sich zeigen. ;)

@Dr: Ich weiss schon das es Dir unheimlich schwer fällt jeweils eine Begründung für Deine Aussagen zu liefern, daher nochmals, kannst Du das begründen? Nur einfach sagen es ist nonsens kann jeder. ;) Ich versuche es Dir noch einfacher zu machen: Zum Beispiel: Ob Du Erfahrung mit dem Feature gemacht hast oder welche kennst die es - in der Neuzeit mit Serverhardware (2k8/2012, SSD) - haben. ODER Dein (mein) Punkt 1 oder 2 Argument genug sind ... @Zahni: Auf alle Fälle Danke, das war immerhin etwas zum Thema. :)

Solche Produkte sind mir auch bekannt, das ist aber nicht sehr realisitisch für kleinere Betriebe. Der zweite Link klingt schon eher nach 'Otto-Normal-Betrieb' finanzierbar. Allerdings konnte ich auf die schnelle nicht wirklich etwas finden ob Trim in einem RAID-Verbund tatsächlich funktioniert. Zurück zum Windows-Software-RAID: Mir sind die Probleme von früher durchaus bekannt, habe als das aufkam auch diverse Tests gefahren und für untauglich befunden. Dazu dann diverse Restores und Rettungen Durchgeführt welche andere aufgesezt hatten. Lag aber meistens an nicht 100%ig funktionierender HotSwapTechnik, Anwendung auf Systemlaufwerke (Probleme beim Reboot, Bootsektoren) und instabile Systeme, Windwos das sich daher aufhängte etc. Die Probleme von damals konnte ich aber nicht reproduzieren (Systemlaufwerk ausgenommen). Einfach pauschal das ist nix weil das Feature mit früheren Hardwaregenerationen zu Problemen führte finde ich etwas naja. Eine Begründung würde mich daher brennend interessieren. Ich sehe Aktuell zwei Probleme: 1. Wie reagiert Windows wenn ein Laufwerk langsam stirbt, also einfach sektoren mit müll raus lässt anstelle sich ganz auszuklinken. Bis dato habe ich aber nur letzteres bei SSD's gesehen/gehört. 2. Was passiert wenn der Host stirbt. Das Problem mit Filesystem-Sauereien kann man da immer haben, sollte aber mit einem Batteriegestützten Controller kleiner sein. Waren noch nicht alle Infos beim Controller, nützt es auch da nix. Die Überwachung ist wieder eine andere Sache. Müsste man dann logischerweise einen Trigger bauen. Tut aber nichts zur Sache ob das RAID an sich tauglich ist oder nicht. Von daher, wenn sich ein paar Profis mit Erfahrungen mit Systemen von Heute diesbezüglich melden würden wäre das Klasse.

Ich traue den SSD's ned mehr oder weniger als einer Enterprise SAS-Disc. ;) RAID-Controller mit Trim-Unterstützung als normale PCI-Express-Karte dazu mit gutem IO Durchsatz? Bitte melden. ;) Software-RAID: Auch ZFS ist ein Software-RAID und funktioniert prächtig und extrem performant. Ebenso Datacore, welches sogar auf Windows-Server-Basis läuft. Alos pauschalisieren kann man es nicht. Auch MS geht mit Ihrer Entwicklung im Storage-Bereich in diese Richtung. ;) Das Standard-Software-RAID von Windows ist bei entsprechender Hardware ziemlich robust. W-Server sowieso. BlueScreens hatte ich im Betrieb schon ewig nimmer. Da es aktuell nichts vernünftiges und bezahlbares für SSD's mit Trim auf PCI Basis gibt (mir ist zumindest nichts bekannt, lasse mich gerne belehren), finde ich das eine gute Lösung bzw. besser als eine Single Disc. Abhängen tut Windows ein Volume auch nicht mehr wenn wenn ein Spiegelpartner weg ist. War früher - soweit ich mich erinnere - ein Problem. Zumindest konnte ich problemlos eine Disc herausziehen und Volume war immer noch verfügbar. Neuen Datenträger rein und wieder syncro. Sehe das ganze für VDI, da geht der Trend richtung Local-Disc Storage auch bei grösseren Installationen, weil die IOPS halt extrem günstig sind. ESX und Trim: Sofern es nicht mit 5.1 gekommen ist. Ja. Aber auch da bin ich der Meinung das es noch nicht geht. Angeblich auch eher schwierig, weil das Hostsystem mit dem aktuellen Format nicht mit dem Guest-System kommunizieren kann und ein Datestore meines Wissens auch nicht. Wäre also wenn dann nur via wachsenden Discs, NFS und regelmässigem Shrinken zu erreichen. Den Komfort wie in HyperV hat man nicht.

Danke für die Blumen. Das sollte aus dem Text und Titel zwar klar ersichtlich sein, aber für Dich lasse ich natürlich gerne eine Erklärung folgen. ;) Trim funktioniert in der Regel nicht mit SSD die in einem RAID-Verbund sind. Weder im Hardware noch Software-RAID. SSD wird mit der Zeit extrem lahm. Sucht man im Netzt danach findet man auf die Frage nur die Antwort, dass man die Trim-Funktionalität verliert sobald RAID eingesetzt wird. Da man je nach Situation vielleicht mit Local-Storage arbeiten möchte/muss (Ja das gibt es bei Kleinumgebungen) kann man so trotzem ein sehr schnelles System, mit Trim-Funktionialität und RAID bewirtschaften. Nicht jeder kann und will 10'000 Euro für ne SAN-SSD ausgeben, dessen Performance aber vielleicht trotzdem haben. Zusammen mit RAID. Des weiteren: Wenn die Hyper-V-Guest ihrem Host mitteilen welche Sektoren frei sind und dies gleichzeitig auf den SSD's geschieht ist das ein ziemlich hilfreich für die SSD. Weil so die SSD eben nicht ganz zugemüllt wird, obwohl von der virtuellen Disc allokiert. Zumindest wenn MS da keinen Schmarrn erzählt. Ist gegenüber VmWare aktuell ein Vorteil.

Hallo Leute, Habe ein paar Tests gefahren weil ich dazu keine befriedigende Antwort im Netz gefunden habe. Kann definitiv sagen, dass es mit einem E5, C600 Chipsatz, Windows 7, Intel SSD 520 funktioniert. Überprüft wurde das ganze mit einem HexEditor auf Datenträger-Ebene. Ist Trim in Windows deaktiviert, bleiben die Sektoren nach dem löschen einer Datei gefüllt. Wird Trim aktiviert, werden Sie gelöscht, auf beiden Datenträger. Nachträgliches aktivieren von Trim bewirkt nicht, dass die Sektoren gelöscht werden. Jedoch hat Windows diese Sektoren jeweils prioritär wieder überschrieben wenn neue Daten hinzukamen. Das gibt ein paar schicke neue Möglichkeiten für Local Storage für HyperV VM's (Angeblich weitergabe von gelöschten Sektoren mit SMB 3 und HyperV3) und evtl. Sogar Hochverfügbarkeit mit Boardmitteln (iSCSI, Cluster). Jedoch noch nicht getestet. Hoffe das hilft dem ein oder anderen. Mir war das immer ein Dorn im Auge mit den SSD's und der Ungewissheit wenn mir eine wegstirbt. Was allerdings Windows macht, wenn eine aus dem Spiegel stirbt, weiss ich auch nicht so genau. ;)

Das ist doch Quatsch mit den drei Lizenzen?!? Also Du hast korrekte Lizenzen für 2008 und für den SBS. Was du brauchst ist eine einzige 2012 Standard Lizenz damit Du einen Hyper-V Host hast, welcher eine GUI hat. Du dürftest imho in dieser Konstellation sogar 2 zusätzliche virtuelle 2012er laufen lassen, da die anderen ja vollständig lizenziert sind. Sollte MS sich wirklich querstellen und behaupten man brauche zusätzlich 2012er Lizenzen für alle 2008er Server instanzen (welche über eine Lizenz verfügen), ist das rechtlich eher schwierig. Die müssten sich darauf berufen, dass die Virtualisierungstechnologie 2012er Technolgien sind und somit alle Clients mit der neuen Technologie lizenziert werden müssen. Allerdings auch schwer haltbar, wenn man gleichzeitig die Technolgie umsonst anbietet (ohne GUI). Insofern würde ich mir keine grossen Sorgen mochen. Zur Sicherheit - wenn Du keine vernünftige Antwort bekommst -, nimmst eben einfach VmWare Essentials wenn sie sich querstellen. Da benutzt du dann keine Sever 2012 Technolgie für die Virtualisierung und somit gelten auch die Einschränkungen nicht.

Würde sich aber MS ins eigene Fleisch schneiden, spielt ja dann VmWare in die Schuhe. Klar dass man nicht zusätzliche 2012er VM's erhält, aber zusätzliche 2008er müsste doch gehen.

Darum meine ich ja, allgemeine Infrastrukturnutzung, nicht explizit Server bzw. Cals vermieten. ;)

Dann soll halt die Tochter dem Mutterhaus die Lizenzen verkaufen und das Mutterhaus der Tochter Verwaltungsgebühren für die Infrastruktur verrechnen. Müsste gehen oder? Wäre eigentlich nichts wie fair oder? Man kauft Nutzungsrechte für den Zugriff auf ein bestimmtes Programm. Das Programm an sich wird ja separat lizenziert. Ob das Rechtlich auch so gesehen wid steht auf einem anderen Blatt. ;) Allerdings ist die Verdunkelungsgefahr dann ziemlich gross und MS würde Mühe haben das ganze zu kontrollieren. Insofern verstehe ich deren Standpunkt schon.

TMG: Huch, da ist aber nicht eine Einstellung geplant oder? Ansonsten: MS macht das in der Regel korrekt. Schenken kann man nicht so direkt sagen, sie erfüllen einfach auch Ihren SA-Vertrag und stellen sicher, dass man keine Abstriche in der Funktion machen muss mit den Nachfolge-Produkten, im Zweifel eher für den Kunden. In Extremis gilt das beim SBS: Windows SBS 2003R2 Premium (Exchange, SQL, ISA alles auf der gleichen Maschine) Man erhält heute mit SA hatte (ohne halt etwas ältere): - 2x Server Standard 2012 (Vorher Enterprise 2008R2) - 1x Exchange Standard 2010 (Vielleicht sogar noch 2012, da SA noch läuft) - 1x TMG 2010 (erst ISA 2006 + Serverlizenz) - 1x SQL Server Standard (Vorher Workgroup) - ServerCals, Exchange Cals, SQL-Cals für die anz. Cals die man hatte - Dazu erhielt man pro Cal auch noch Outlook 2007, Sharepoint Designer usw. Ich finde man kann da überhaupt nicht meckern. Klar, man hat auch Anspruch drauf und kann nix dafür, dass MS das Produkt eingestampft und einem SA angeboten hat. Aber die Lösung ist sehr fair. Single- oder Duaserver-Prinzip mit 4 virtuellen Server machbar. Für Neukunden ist die Zukunft als Kleinkunde welche Exchange etc. selber betreiben möchten allerdings alles andere als rosig. Die SA-Kosten für diese neuen Produkte für Altkunden ist im Vergleich zur alten Lösung auch extrem.

Der SBS macht manchmal ewig mit den Neustarts. Ich würde fast behaupten er hat in manchen Situationen so lange bis die Timing-Limits erreicht sind und er ein paar Dienste einfach abschiesst. Manchmal hilfts, wenn man sätmliche Clients komplett herunterfährt. Wens nix hilft würde ich vor Kaltstart evtl. auch die Netzwerkverbindung kappen. Halt alles tun, damit er möglichst nix auf seiner ToDo-Liste hat, dann ist die Chance auch ziemlich gross, dass er es schadlos übersteht.

So siehts aus, wie bereit in #8 gesagt. ;)

Es ist überall von 2008 die Rede.

@Dr. Melzer: Das stimmt so definitiv nicht. Zumindest verstehe ich deine Aussage so, dass sowohl der SBS als auch das Premium auf die gleiche Maschine muss. Man erhält mit dem SBS Premium eine zusätzliche, vollwertige Serverlizenz + den SQL als Applikation. Diese darf auf einem anderen physischen System als der eigentliche SBS installiert werden, ist ein eigenes lizenziertes System. Einschränkung ist lediglich, dass die Lizenz innerhalb einer SBS-Domäne betrieben wird. Man darf - nicht muss - die Lizenz aus dem Addon nutzen um den SBS virtuell zu betreiben. Also das Addon bzw. dessen Serverlizenz sowohl als virtuelle Instanz als vollwertiges OS sowie als Hyper-V Host mit grafischer Oberfläche und mit den üblichen Rechten einer Standardlizenz nutzen (Software für Verwaltung der virtuellen Umgebung, Backup etc.), das bringt der SBS an sich nicht mit.

Klingt ja eigentlich nicht soo schlecht. Wurden die DB's mal komprimiert? Eventuell sogar nen Decompile drüber laufen lassen, obwohl das bei reinen DatenDB's nicht nötig sein sollte. Netzwerkstabilität kommt schon etwas drauf an wie die Frontend programmiert wurde. Habe jedenfalls schon seit Jahren keine korrupte Backend mehr gehabt, auch wenn Netz nicht stabil war. Allerdings sowieso von Vorteil, wenn das Netz stabil ist.

Imho nicht zwingend ein Netzwerkproblem. Meist ist das ein Accessproblem. Access DB's gehen vor allem kaputt, wenn gleichzeitig Backend als auch Frontend sind und von mehreren Benutzern verwendet werden. Dafür ist Access nicht wirklich gemacht. Kommen Netzwerkaussetzer hinzu, ist die Chance natürlich höher, dass was kaputt geht, allerdings normalerweise nur wen eben Backend und Frontend nicht getrennt sind. Reine Backend-DB's sind ziemlich robust. Das heisst nach meiner Erfahrung: - Saubere Trennung von Code und Daten - Code-DB auf jedem Rechner eine eigene - Backend DB am besten neu erstellen ohne jegliche Altlasten bzw. Tabellen von der altne DB importieren - Code DB über den Decompile Flag öffnen, komprimieren, kompilieren, komprimieren und du hast wieder ein sauberen Start. --> Muss in grossen und komplexen Frontends öfter mal gemacht werden. - Backend-DB in Mehrbenutzerumgebungen evtl. entlasten, dass nicht alle Zugriffe Datengebunden sind

MS war schon immer fair mit den Kunden die SA hatten. Glaube kaum, dass sich daran was ändern wird. Und gemäss den SBS-Spezialisten erhält man Exchange 'umsonst'. Sharepoint weiss ich nicht. Den ISA und sogar den Nachfolger TMG erhielt man ebenfalls umsonst als Einzelprodukt, nachdem dieser aus dem Paket entfernt worden war. Gleiches galt für das SQL-Addin.