Nachfolge für den SBS

[Photogregor 10]

Hallo Forum,

 

seitdem der SBS mit der aktuellen Server-Technologie nicht mehr fortgeführt wird, es aber zahlreiche SBS-2003-Installationen gibt, die in 2015 ihr Lebensende erreichen, müssen wir uns nach einer Alternatvie umschauen. Eine davon wäre der SBS 2011, der ja noch überall erhältlich ist. Aber ich fühle mich nicht wohl dabei, eine Technik zu verkaufen, die nicht mehr state of the art ist. Also muss man sich mit dem Server 2012 anfreunden. Eine Möglichkeit ist, einen relativ preiswerten 2012 Essentials aufzusetzen und die Exchange Dienste in die Cloud zu bringen (Hosted Exchange und/oder Office 365). Aber ich finde nur noch wenige Kunden, die heutzutage bereit sind, ihre Daten auszulagern.

 

Also denke ich an die "SBS 2012"-Option: Eine Hyper-V-Core-Installation mit einer VM als DC und einer zweiten VM als Exchange Server. Da das für mich Neuland ist würde mich sehr freuen, wenn diejenigen mit Erfahrung mit dieser Konstruktion kurz ihren Senf zu folgenden Fragen geben könnten:

 

1. Ist es ratsam für einen alten SBS-Hasen, aber 2012-Novizen (mit ein wenig ESXI-Erfahrung) sich an eine Hyper-V-Core-Installation mit zwei VMs zu wagen oder gibt es zu viele Stolpersteine?

 

2. Ist diese Hyper-V-Konstruktion genauso verlässlich und stabil wie die alten SBS?

 

Habt Dank für eine Teilhabe an euren Erfahrungen,

Stefano

 

[GuentherH 61]

Eine Hyper-V-Core-Installation mit einer VM als DC und einer zweiten VM als Exchange Server

 

Die Core Version wird in dem Fall nicht benötigt. Mit der aktuellen Lizenzierung von Server 2012 kannst du mit einer Server 2012 Standard Version auf dem "Blech" zwei VMs mit Server 2012 betreiben.

 

Und, Support für den SBS 2011 gibt es bis 2020. Wenn du diesen also noch bekommst, dann ist gibt es kein Problem diesen einzusetzen.

 

LG Günther

[NorbertFe 2.026]

Hat zumindest derzeit den Vorteil, Exchange 2010 statt 2013 einsetzen zu müssen. ;)

[Photogregor 10]

Hi Günther,

 

danke für deinen Kommentar. Dass eine einzelne Lizenz quasi drei Installationen abdeckt, habe ich verstanden. Du hast recht: Der Host muss der Server mit der Hyper-V-Rolle installiert sein, nicht als Core. Dazu kommen dann noch zwei VM mit jeweils einem Server 2012 - und all das ist mit einer Lizenz abgedeckt. Ein solches System ist natürlich deutlich teuer als ein SBS, weil man den Exchange separat kaufen muss. Aber dennoch empfand ich den SBS 2011 immer als zu hoch integriert, zu viel Balast mit Sharepoint, WSUS etc. Und der Server 2012 bringt offensichtlich interessante Neuerungen, insbesondere SMB 3. Insofern würde ich den also bevorzugen, allerdings nur dann, wenn sich die oben genannte "SBS-Ersatzkonfiguration" mit den zwei VM sowohl vom Installations- als auch vom Wartungsaufwand rechtfertigen lässt.

 

Danke nochmal,

Stefano

[GuentherH 61]

Aber dennoch empfand ich den SBS 2011 immer als zu hoch integriert

 

Wenn er korrekt eingesetzt wird, dann nicht.

 

 

zu viel Balast mit Sharepoint, WSUS etc.

 

Und genau dafür eigenen sich die Cloud Produkte wir Office 365 und Intune hervorragend.

 

Wenn du dem Kunden ordentlich beraten willst, dann musst du auch die laufenden Wartungskosten der beiden angedachten Systeme beachten. Erst dann hat der Kunde eine Entscheidungshilfe.

Und den Satz von Norbert sollte du auch auf jeden Fall beachten. Da schwingt viel Erfahrung zwischen den Zeilen mit ;)

 

LG Günther

[CoolBlue 10]

Ich finde das Thema als IT Dienstleister momentan auch sehr sehr schwierig.

 

Technisch gesehen ist HyperV mit 2 V Servern korrekt und ggf. sogar flexibler und mächtiger als ein SBS. Hardwareseitig sehe ich auch nicht so viele Probleme mit den Kosten. Speicher ist billiger geworden. CPU Performance mittlerweile im Überfluss da. Einzig sollte man teurere SAS Platten statt SATA Platten einsetzen, damit man genug I/O hat.. nur hat man dann auch weniger Speicherkapazität. Dies macht es etwas teurer.

 

Die Arbeit jedoch das alles aufzusetzen. Die ist jedoch enorm gestiegen. Das heißt hier ist deutlich mehr Dienstleistung erforderlich. Während das SBS Setup alle Konfigurationen automatisch durchgeführt hat und man später nur noch einen Benutzer angelegt hat, muss man (grade bei Exchange) deutlich mehr Zeit einplanen.

 

Hinzu kommen die Mehrkosten der Lizenzen. Kostet ja mit seperatem Exchange gleich das doppelte an Lizenzkosten.

Ach und Backupsoftware gibs auch kaum noch für SBS als Bundles. Nen BackupExec OEM SBS hat früher mal 150 € gekostet. Nun brauch man den Server auf dem Hyper-V Host (min 800 €) + 2 BackupExec Clients (2x 600 €) + Exchange Lizenz (600 €). + Maintenance Kosten.

 

Als ich das alles mal samt USV usw zusammen gerechnet habe, wäre ich beinahe hinten rüber gefallen.

 

Ich mach das jetzt so das ich Kunden eine private Cloud in einem deutschen Rechenzentrum anbiete mit eigener via VPN verbundenen Infrastruktur auf monatlicher Mietbasis. Ist leider immernoch teurer als Office 365, aber die Daten bleiben beim Kunden und die VMs kann ich jeder Zeit auf ne Festplatte kopieren und zum Kunden tragen und dort wieder hochfahren.

 

Server Hardware wird geshared und Lizenzen kommen günstig über SPLA rein.

[Photogregor 10]

Wenn er korrekt eingesetzt wird, dann nicht.

 

Soll heißen immer und ausschließlich gemäß Standard- bzw. Wizard-Setup, nicht wahr? Da ich meine ersten SBS nie mehr richtig hinbekommen habe, wenn ich mich mal nicht an die Wizards hielt, war das für mich immer Grundgesetz. :-)

 

Wenn du dem Kunden ordentlich beraten willst, dann musst du auch die laufenden Wartungskosten der beiden angedachten Systeme beachten.

 

Der SBS ist ja nicht gerade nebenher administriert und die nicht so hoch integrierte 2012er-Lösung potentiell wartungsärmer. Aber damit habe ich, wie gesagt, noch keine Erfahrung, insbesondere mit der Frage, ob das Zusammenspiel zwischen 1 x Host und 2 x VM den "Komplexitätsgewinn" gegenüber dem SBS nicht wieder aufhebt.

 

Und den Satz von Norbert sollte du auch auf jeden Fall beachten. Da schwingt viel Erfahrung zwischen den Zeilen mit. 

 

@Norbert

 

Du spielst wohl auf die Probleme des Exchange 2013 auf Server 2012 an. Aber der Exchange 2010 wäre doch auch keine schlechte Option für den Server 2012 (R2), oder siehst du das anders?

 

LG,

Stefano

[PathFinder 10]

Hallo,

 

warum ist der SBS2011 nicht State of the Art?

 

Produktlebenszyklus ist doch wie bei Windows 7 -> 2020

 

Bis dahin ist das sehr wohl noch aktuell und voll supported.

 

MS versucht uns ja mit im bestenfall plumper Gehirnwäsche zu erzählen wie toll es ist den Kunden in die 365 Cloud zu bringen so das dieser jeden Monat zahlen darf. Wenn man das oft genug gehört hat, glaubt man vielleicht auch das dies eine supidupidolle Lösung ist, die uns ja erst richtig am IT Leben teilhaben lässt.

 

Das ist vielleicht State of the Art, aber da bin ich doch lieber noch etwas konservativer.

 

Wenn du ein Cloud System brauchst das Privacy großschreibt, dann schau dir mal das Terra Wortmann Rechenzentrum an, da kann man weningstens was mit anfangen.

 

Bis dahin fahren wir den SBS2011 und hoffen mal das MS sich wieder eines besseren besinnen wird, aber das ist wohl eher trauriges Wunschdenken.

 

lg der Path

bearbeitet 19. Februar 2014 von PathFinder

[Photogregor 10]

Hi CoolBlue,

 

Hinzu kommen die Mehrkosten der Lizenzen...

 

Ja, die Lizenzkosten sind enorm und das Backup/Restore/Disaster Recovery ist auch nicht trivial. Aber MS hatte ja auch geplant, die Unternehmen in die Cloud zu dirigieren und nicht, teure Onpremise-Lizenzen zu kaufen. Nachdem das Cloud-Thema seine Akzeptanz eingebüßt hat müssen jetzt Alternativlösungen her.

 

Ich mach das jetzt so das ich Kunden eine private Cloud in einem deutschen Rechenzentrum anbiete...

 

Kannst du das näher ausführen? Ich wäre ja froh, wenn ich das Cloud-Thema noch verkauft bekäme. Was steht in diesem Modell beim Provider und was beim Kunden?

 

Regards,

S.

Hi Path,

 

warum ist der SBS2011 nicht State of the Art? Produktlebenszyklus ist doch wie bei Windows 7 -> 2020

 

Der Server 2012 hat halt schon ein paar interessante Features und EOL ist halt noch ein paar Jahre später. Außerdem habe ich den SBS 2011, wie gesagt, als Feature-Monster und träge betrachtet. Ich habe keinen Kunden, der Sharepoint benutzt, ich habe keinen Kunden, der den WSUS benutzt (die Clients machen das selbst), aber alles läuft mit und ist ineinander verflochten. Ich bevorzuge schlankere Systeme. Beim 2011 warte ich nach einem Doppelklick auf eines der Verwaltungs-GUIs nicht selten eine Minute, bis es gestartet und bereit ist.

 

Das ist vielleicht State of the Art, aber da bin ich doch lieber noch etwas konservativer.

 

Die Cloud sehe ich (bzw. meine Kunden) auch nicht mehr als state of the art, aber die Technik des Servers 2012 doch schon. Ich würde mich ungerne für die nächsten 6 Jahre von neuen Features wie SMB 3 und dem erneuerten Direct Access ausschließen.

 

Auf der anderen Seite hast du aber insofern vielleicht recht, dass, wenn der Zug in die Cloud tatsächlich nicht so läuft, wie MS das plant, vielleicht doch wieder On-Premise-Features auf Basis des Server 2012 entwickelt werden.

 

LG,

Stefano

 

bearbeitet 19. Februar 2014 von Photogregor

[NorbertFe 2.026]

Ich habe keinen Kunden der keinen wsus hat. Was soll der Arme wsus dem SBS denn tun, dass du auf zentrales reporting verzichtest?

[Photogregor 10]

Ich habe keinen Kunden der keinen wsus hat. Was soll der Arme wsus dem SBS denn tun, dass du auf zentrales reporting verzichtest?

 

Ich habe das meinen Kunden einfach erspart. Der WSUS ist halt ressourcenintensiv, man muss dann schon mal die Systempartition von zig Gigabyte befreien. Es ist auch spaßig dem WSUS mal mittels Taskmanager bei der Arbeit zuzuschauen. Meines Erachtens ist es sinnfrei, für Updates den simplen und bombensicheren Client-Automatismus zugunsten einer unergonomischen Verwaltungslösung abzulösen. Das Internet quillt über mit WSUS-Problemen.

[GuentherH 61]

Meines Erachtens ist es sinnfrei, für Updates den simplen und bombensicheren Client-Automatismus zugunsten einer unergonomischen Verwaltungslösung abzulösen

 

Ja, es hat schon etwas für sich, bei angenommen 50 Clients, 50 x das Office Servicepack herunterzuladen und darauf zu hoffen, dass es installiert wird :cry:

 

LG Günther

[Sunny61 806]

Ich habe das meinen Kunden einfach erspart. Der WSUS ist halt ressourcenintensiv, man muss dann schon mal die Systempartition von zig Gigabyte befreien.

Wieso sollte eine SQL Datenbank, die einfach nur da liegt Ressourcen verbrauchen? Installiere dieses Powershell Script, konfiguriere es für die Umgebung und lass es täglich per Taskplaner laufen. http://www.wsus.de/serverbereinigung2 Schon wird täglich freigeschaufelt.

Es ist auch spaßig dem WSUS mal mittels Taskmanager bei der Arbeit zuzuschauen. Meines Erachtens ist es sinnfrei, für Updates den simplen und bombensicheren Client-Automatismus zugunsten einer unergonomischen Verwaltungslösung abzulösen.

Und jetzt überleg einfach mal ganz genau, welcher Dienst sich vom Client aus die Updates beim WSUS holt, genau, der bombensichere Client-Automatismus.

Das Internet quillt über mit WSUS-Problemen.

Natürlich liest Du nichts davon, dass bei Millionen von Admins der WSUS täglich einwandfrei läuft. Und 99% der sog. WSUS-Probleme sind Probleme der Clients, Probleme der Admins die mit dem WSUS nicht klarkommen und Admins die einfach alles sinnfrei verkonfiguriert haben.

 

Mittlerweile kann man Anwendungen über den WSUS im Unternehmen zur Verfügung stellen. Und ja, es wird der bombensichere Client-Automatismus benutzt. http://www.wsus.de/lup Aber auch dazu findest Du nur Probleme, Probleme und nochmal Probleme.

[Dukel 451]

Ich habe das meinen Kunden einfach erspart. Der WSUS ist halt ressourcenintensiv, man muss dann schon mal die Systempartition von zig Gigabyte befreien. Es ist auch spaßig dem WSUS mal mittels Taskmanager bei der Arbeit zuzuschauen. Meines Erachtens ist es sinnfrei, für Updates den simplen und bombensicheren Client-Automatismus zugunsten einer unergonomischen Verwaltungslösung abzulösen. Das Internet quillt über mit WSUS-Problemen.

 

Das ist doch das erste, was man auf einem SBS macht. Die Daten von der Systempartition (Wsus, Sharepoint, Exchange, Shares) auf eine andere Disk verschieben.

Ich würde nicht wollen, dass entweder der Anwender entscheidet welche Updates eingespielt und nicht eingespielt werden sollen oder an jeden Client gehen und dieses manuell machen.

[NorbertFe 2.026]

Mal davon abgesehen, dass man den WSUS auch nur fürs Reporting und die Verwaltung verwenden kann und man die Clients die Updates einfach aus dem Netz ziehen lassen könnte. Verbraucht also auf dem SBS keinerlei Platz. Aber so werden halt Vorurteile gepflegt. ;)

 

Bye

Norbert