Nachfolge für den SBS

[Photogregor 10]

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. 

 

Wenn ich 50 Clients hätte, würde ich nicht den SBS einsetzen. Und um die Office-Servicepacks habe ich mich nie kümmern müssen, die hat der Client-Update-Automatismus bei meinen Kunden einfach installiert. Ich strebe für den Kunden und mich kostengünstige, will heißen: wartungsarme Lösungen an. Die Entscheidung, den WSUS links liegen zu lassen, war (neben der, den Servern die üblichen Antiviren-Software-Katastrophen zu ersparen) der Hauptgrund, dass mich meine Kunden zum Meister eines geräuschlosen und sicheren Netzwerkbetriebes gekürt haben.

 

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.

 

Wozu ein Script installieren, wenn doch keine Ressourcen verbraucht werden? Und wozu überhaupt etwas tun, wo es doch auch ohne jeglichen Eingriff geht? Du hast da etwas falsch verstanden: Es ist zwar schön und durchaus ehrenhaft, ein System beherrschen zu lernen, aber mit Blick auf den Kunden ist das falsch, es ist Frickelei, es kostet Geld und Zeit, es ist l'art pour l'art. Sich die Frage nach dem Verhältnis von Aufwand und Ertrag nicht zu stellen ist das traditionellste und größte Manko in der IT. Wenn sich die Clients alle selbst über das Internet betanken können und der entsprechende Mechanismus so überaus zuverlässig wie bei den MS-Betriebssystemen der letzten Jahre, dann Finger weg von Zusatz-Software, die lediglich ein funktionierendes System durch ein zu verwaltendes System ersetzt.

 

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.

 

Als WSUS-Nichtbenutzer muss ich nichts anfassen, skripten, verschieben. Ich will das auch nicht. Sonst könnte ich mir ja eine Linux-Maschine hinstellen - da sagen die Leute auch immer "Wenn das nicht funktioniert liegt das nur daran, dass du dies und das und jenes nicht verstanden oder falsch konfiguriert hast". Ich lasse es einfach und meine SBS-Clients sind allesamt und ohne jeglichen Eingriff immer uptodate.

 

Der WSUS macht auch hier und jetzt wieder Ärger, er verstellt den Blick auf Wichtiges, nämlich die Ablösung des SBS durch schlankere Nachfolgesysteme. Die Frage, die auch für euch entscheidend ist, lautet: Was machen wir in der Nach-SBS-Ära?

bearbeitet 20. Februar 2014 von Photogregor

[Weingeist 157]

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.

Ich betreue ja auch ein paar solcher Umgebungen und habe mittlerweile ein paar auf 2012 geswitcht. Meiner Meinung nach gibt es eigentlich nix bequemeres als nen SBS zu administrieren wenn man sich an ein paar Regeln hält sowie ein gscheites, mehrstufiges Backup/Recovery-Konzept hat. Hauptaufgabe ist unter WSUS die ganzen Updates zu checken/freigeben/kontrollieren. Der Rest ist ja ein ziemlicher Selbstläufer.

 

Bis auf wenige Einrichtungs-Wizards oder Datenverschiebungs-Wizards habe ich wenig genutzt. Insbesondere die ganzen Logging-Funktionen habe ich jeweils möglichst abgedreht, weil der Ressourcenverbrauch in jeder Hinsicht jeweils ins unermessliche stieg. Das ist vor allem in VM's deutlich spürbar.

 

Bis und mit 2003 war das Patchmanagement mitunter etwas "trickreich" wenn man zu den ersten gehörte. Seit 2008, VM's, Snapshots, VSS etc. ist das aber auch kein Thema mehr.

 

 

Meine eher negativen Erfahrungen bis jetzt beim Wechsel

- Das Patchmanagement hat deutlich an Aufwand zugenommen wenn Auto-Updated unerwünscht ist --> Mehrere Server

- Die Gesamtkomplexität steigt

- Für eine zackige Single-Host Umgebung mit schnellem Recovery muss einiges an Hardware aufgefahren werden --> Deutlich mehr OS Daten

- Es braucht umfangreichere Reihenfolgen für Shutdowns und Starts (USV) sowie Überprüfungen

- Um wirklich Vorteile und nicht nur Nachteile aus der Separierung der Dienste zu ziehen, braucht es eigentlich mehrere Hosts und VM's. -> Kostentreiber, SA etc.

- Der Installationsaufwand ist deutlich höher

- Desaster-Recovery-Aufwand bzw. die Zeit bis alles wieder oben ist, ist länger (ein paar neuere Backupkonzepte ausgenommen, wo direkt anstarten möglich ist)

- Die Kosten sind deutlich höher

 

 

Es hat natürlich auch einige Vorteile

- Fehlersuche mitunter einfacher

- Sicherheit sicher deutlich höher

- Misratene Patches / Fehlkonfigurationen haben ned zwingend Aufwirkungen auf alles

- Man kann nen Dienst einfacher entfernen und neu aufsetzen

- Grössere Auswahl an Backupsoftware (Dafür auch deutlich teurer)

 

 

Fazit: Ich arbeite nicht unbedingt weniger gerne so, eher im Gegenteil. Aber dieser Vorteil muss sich eben ziemlich teuer erkauft werden.

[Photogregor 10]

Hi Weingeist,

 

ein interessanter Beitrag. Du meinst:

 

Bis und mit 2003 war das Patchmanagement mitunter etwas "trickreich" wenn man zu den ersten gehörte. Seit 2008, VM's, Snapshots, VSS etc. ist das aber auch kein Thema mehr.

 

Dazu hätte ich folgende Frage: Inwiefern ist ein Patchmanagement erforderlich - ich lebe seit Jahren wie gesagt bei meinen kleinen / SBS-Netzen ohne - und wieso wäre ein Patchmanagement mit VM, VSS etc. kein Thema mehr? Verstehe hier nicht so ganz den Zusammenhang...

 

 

- Für eine zackige Single-Host Umgebung mit schnellem Recovery muss einiges an Hardware aufgefahren werden --> Deutlich mehr OS Daten

 

Man hat bei der von mir skizzierten 2-VM-Lösung drei Betriebssysteme (inkl. Host), aber mengenmäßig machen die 100 - 200GB an OS-Daten ja nicht soviel aus. Ansonsten ist allerdings das Backup-Thema deutlich komplexer als beim SBS. Bei letzterem habe ich einfach eine Lizenz vom Backup Exec 2010 und sichere Daten und OS auf ein Band und bin für ein Disaster Recovery gerüstet. Meine Recherchen zum "SBS 2012" mit den VMs haben ergeben, dass es da nichts Vergleichbares gibt. Systembedingt, weil man ja die Backup-Software auf dem Host installieren und dann in die VM "hineinschauen" muss. Und man kommt anscheinend nicht ohne ein zusätzliches Plattensubsystem für die Sicherung aus, die also auch noch im Server Platz finden müssten (alte SBS sind ja oft Single-Server mit internem Tape Drive, die in kleinen Büros stehen), weil sich Nutzerdaten und VMs nicht einfach auf ein Tape schreiben lassen.

 

 

- Um wirklich Vorteile und nicht nur Nachteile aus der Separierung der Dienste zu ziehen, braucht es eigentlich mehrere Hosts und VM's. -> Kostentreiber, SA etc.

 

Warum? Wenn beim SBS nur eine Box erforderlich war für DC, Exchange etc. und wenn Hardware-Redundanz in einem kleinen Unternehmen aus Kosten- und Platzgründen nicht geht, dann sollte die 2-VM-Lösung auf Basis des Server 2012 R2 doch auch ausreichen, es sei denn, Hyper-V wäre instabiler als ein alter SBS.

 

 

- Desaster-Recovery-Aufwand bzw. die Zeit bis alles wieder oben ist, ist länger (ein paar neuere Backupkonzepte ausgenommen, wo direkt anstarten möglich ist)

 

Hast du ein Beispiel für eine solches Backupkonzept?

 

 

- Die Kosten sind deutlich höher

 

Definitiv. Man will das On-Premise-Modell unattraktiv machen.

 

 

Es hat natürlich auch einige Vorteile

[...]

- Man kann nen Dienst einfacher entfernen und neu aufsetzen

 

Was meinst du hier mit Dienst? Eine komplette VM?

 

Besten Dank und Gruß,

Stefano

[monstermania 53]

Moin,

natürlich wird es im Bereich der typischen SBS-Kunden durch den Einsatz von Virtualisierung grundsätzlich komplexer. Früher hat man den Kunden ein Blech hingestellt und gut war's.

Allerdings habe ich in den letzten Jahren (ich denke mal so seit 2009) bei keinem Kunden mehr einen SBS direkt auf's Blech installiert (VM-Ware). Allein schon wegen der Vorteile bei Backup/Restore möchte ich VM-Ware nicht mehr missen. Auch haben viele Kunden heute auch höhere Anforderungen (TS, SQL, usw.), so dass ohnehin der Einsatz eines weiteren Servers erforderlich ist.

Mit Veeam und einer vernünftigen QNAP (PRO) bekommt man schon eine extrem gute Backuplösung für relativ wenig Geld.

 

Gruß

Dirk

[Weingeist 157]

Dazu hätte ich folgende Frage: Inwiefern ist ein Patchmanagement erforderlich - ich lebe seit Jahren wie gesagt bei meinen kleinen / SBS-Netzen ohne - und wieso wäre ein Patchmanagement mit VM, VSS etc. kein Thema mehr? Verstehe hier nicht so ganz den Zusammenhang...

Es ist einfach viel entspannter. Keine Ahnung wie man es sich antun kann, jeden Client einzeln zu beglücken. Vor allem in Hinblick auf Updates die nicht erwünscht sind. Silverlight, Windows Desktop Search, Search 4.0 und ne Menge anderer Dinge die mehr oder weniger sinnvoll sind aber nicht zwingend gewünscht ist, dass diese generell ausgerollt werden. Nebst dem, dass man dann nie eine Ahnung hat, was genau auf den Clients installiert ist, wie sein Patchlevel ist usw. In WSUS hat man immer direkt den Überblick über alle Clients und Server. Zudem kann pro Computer-Gruppe definiert werden welche Updates sie erhalten sollen.

 

 

Man hat bei der von mir skizzierten 2-VM-Lösung drei Betriebssysteme (inkl. Host), aber mengenmäßig machen die 100 - 200GB an OS-Daten ja nicht soviel aus. Ansonsten ist allerdings das Backup-Thema deutlich komplexer als beim SBS. Bei letzterem habe ich einfach eine Lizenz vom Backup Exec 2010 und sichere Daten und OS auf ein Band und bin für ein Disaster Recovery gerüstet. Meine Recherchen zum "SBS 2012" mit den VMs haben ergeben, dass es da nichts Vergleichbares gibt. Systembedingt, weil man ja die Backup-Software auf dem Host installieren und dann in die VM "hineinschauen" muss. Und man kommt anscheinend nicht ohne ein zusätzliches Plattensubsystem für die Sicherung aus, die also auch noch im Server Platz finden müssten (alte SBS sind ja oft Single-Server mit internem Tape Drive, die in kleinen Büros stehen), weil sich Nutzerdaten und VMs nicht einfach auf ein Tape schreiben lassen.

Fragt sich halt, ob du mit 2 VM's tatsächlich bereits glücklich bist. Ich würde eher sagen nein. Folgende Dienste habe ich mittlerweile gerne getrennt:

- WSUS

- Printer - Kann eine Menge Ärger ersparen wenn mal nen Treiber spinnt und die VM einfach zurück gesetzt werden kann. Habe ich mir auch mit dem SBS angewöhnt da möglichst eine separate Instanz zu haben.

- DC

- Exchange

- Datenbank Betriebssoftware

 

 

Warum? Wenn beim SBS nur eine Box erforderlich war für DC, Exchange etc. und wenn Hardware-Redundanz in einem kleinen Unternehmen aus Kosten- und Platzgründen nicht geht, dann sollte die 2-VM-Lösung auf Basis des Server 2012 R2 doch auch

 

ausreichen, es sei denn, Hyper-V wäre instabiler als ein alter SBS.

Geht eigentlich mehr darum, dass beim SBS das als ganzes so verkauft wurde und man auch Support erhielt wenn was schief ging. Gewisse Dienste dürfen oder sollten heute nicht zusammen installiert werden. SBS war ein Konstrukt das super funktioniert hat weil sich eben MS die Mühe gemacht hat, alles so zu (ver)konfigurieren, dass es sich nicht oder möglichst wenig gegenseitig beisst. Das hat meiner Meinung nach sehr gut funktioniert.

 

Hast du ein Beispiel für eine solches Backupkonzept?

Zum Beispiel Veaam. Das sichert in einen Backup-Server und daraus kann man die Backup-VM grad anstarten wenn man möchte.

 

 

Mir gefällt die Variante am besten, dass eine virtuelle Platte auf einem iSCSI, NFS oder ... in den Host eingebunden wird auf welchem dann per Hostsicherung oder mit einer zusätzlichen virtuellen Platte direkt aus dem Gast konventionell gesichert wird.

- Mit Windows-Boardmitteln möglich

- Die Storage Einheit kann bzw. sollte in einem anderen Brandabschnitt stehen

- Recovery kann man z.B. nen Restore des Basis-Images machen, z.B. eine Kopie der Backupplatte einbinden und anschliessend den gewünschten Stand zurückspielen

- Files halte ich jeweils gleich auf einer anderen Maschine vor was regelmässig Repliziert/Gebackupupt wird (DFS/Robocopy), im Desasterfall kann sobald der DC oben ist, einfach im DFS der Mirror-Pfad eingegeben werden und man hat mal alle Files wieder. --> Sind ja meist viele Daten und nicht so schnell restored

 

Das ist verhältnismässig günstig, gut und die Komplexität ist überschaubar

 

Was meinst du hier mit Dienst? Eine komplette VM?

SQL-Server, Exchange, DC, Printserver.

 

Besten Dank und Gruß,

Stefano

Gern geschehen

[CoolBlue 10]

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?

Hi Photogregor,

im RZ steht meine eigene VMware Umgebung, darauf laufen im Minimal-Fall zwei VMs. Einmal AD mit Fileserver, Printserver, usw. und einmal ne VM mit Exchange.

 

Argumente die ich dem Kunden gebe:

- Monatliche Mietgebühr mit der man planen kann

- Automatisch Hardware Upgrade

- Keine Dienstleistungskosten für Wartung der grundlegenden Infrastruktur

- Ausfallsicherheit durch mehrere phsyikalische Maschinen

- Die "VMs" gehören *dir*. Das heißt, wenn du dir lokal wieder Hardware kaufen willst, fahre ich ins RZ kopiere deine VMs auf Festplatte und bring sie dir vorbei.

 

Die VMs sind in einem eigenen VLAN und werden via VPN einfach verbunden.

 

Ich hüte mich auch mittlerweile vor dem Wort Cloud. Da reagieren einigen Kunden ja richtig allergisch drauf :-)

Ich sage immer das ist eine virtuelle Umgebung im Rechenzentrum am Standort xy in Deutschland. Dies entspricht sowieso der Wahrheit, denn der ursprüngliche Cloud Gedanke war eh ein ganz anderer als wie der Begriff mittlerweile verbracht wird, für alles möglich, was nicht lokal ist.

Die Adobe Cloud ist z.b. auch keine Cloud... Eher ein HTTP Zugang um sich Anwendungen runterzuladen um sie zu installieren.. totaler Kappes der da am Markt läuft.

 

Hauptproblem Warenwirtschaft:

Eine dateibasierte Datenbank kann man heutzutage auch auf eine NAS installieren.. die haben ja mittlerweile endlich Gigabit Performance erreicht.

MS SQL / MySQL muss man je nach Anwendung ausprobieren obs über VPN nutzbar ist.

 

Ansonten wird hier das Thema des Terminal Servers wieder richtig interessant oder direkt XenApp. Allerdings ist es beschäment das MS zum Anfang Januar die RDS CAL Preise drastisch erhöht hat...

 

 

Es ist wirklicih nicht leicht, was man Kunden im SB Bereich anbieten soll/kann.

 

 

Hat hier mal jemand über den Foundation Server mit MDaemon nachgedacht? Oder mit Tobit? oder einem anderen Exchange Ersatz der mit Outlook funzt? Bringt dem Kleinkunden Exchange überhaupt vorteile? Outlook macht doch die ganze Arbeit.

 

 

Ach übrigens lasst die Diskussion in diesem Thread doch mit dem WSUS sein und weiterhin besinnt euch mal wieder dem eigentlichen Thema.. KLEINE Kunden mit wenig Arbeitsplätzen (<15).

Niemand baut 6 VMs für einen deartigen Kunden nur um Print, File, SQL, usw Dienste zu trennen. Allein die dafür zusätzlichen MS Lizenzen (2-3x Server Standard oder gar 1x Datacenter) sind doch schon absurd.

 

 

Das Exchange einen Server für sich alleine haben will, ist nicht schön, aber akzeptabel. Alle anderen Dienste kann man Problemlos auf den Active Directory Server installieren. Wobei "MDaemon" kannste auch einfach mit auf den AD schieben. Ist ein Dienst im Taskmanager.. das wars. Braucht auch keine 8-12gig RAM.. kommt mit 1-2 aus.

 

Habe selber jedoch noch keine Erfahrung damit. Dachte ich spreche das Thema mal an, weil es heir ja um einen SBS Ersatz geht und ich denke Bedingung dazu ist Windows als OS und Outlook als Client.

[Daniel -MSFT- 129]

Wie lizenzierst Du eigentlich die Kunden in Deinem RZ, wenn das deren VMs sind?

[NorbertFe 1.812]

Dazu hätte ich folgende Frage: Inwiefern ist ein Patchmanagement erforderlich - ich lebe seit Jahren wie gesagt bei meinen kleinen / SBS-Netzen ohne

Wer sagt, dass es erforderlich wäre? Es ist nur meiner Meinung nach sinnfrei ohne zu fahren. Es sei denn, wir reden hier wirklich über kleine Netzwerke, und das wären dann maximal 5 Geräte. Aber da der WSUS eben beim SBS sowieso dabei ist, und mit wenig Einrichtung problemlos läuft, ist das Abschalten wahrscheinlich anstrengender, als ihn einfach zu nutzen und sogar ein sinnvolles "Monitoring" über die PCs zu haben. Aber mach wie du denkst, man kann die Leute nicht zwingen. ;)

 

 

Bye

Norbert

 

der Hauptgrund, dass mich meine Kunden zum Meister eines geräuschlosen und sicheren Netzwerkbetriebes gekürt haben.

Wenn das Weglassen des WSUS und des Virenschutzes auf Servern der Grund dafür ist, dann kann man nur staunen, mit wie wenig sich manche Kunden zufrieden geben. ;)

 

 

Wozu ein Script installieren, wenn doch keine Ressourcen verbraucht werden? Und wozu überhaupt etwas tun, wo es doch auch ohne jeglichen Eingriff geht? Du hast da etwas falsch verstanden: Es ist zwar schön und durchaus ehrenhaft, ein System beherrschen zu lernen, aber mit Blick auf den Kunden ist das falsch, es ist Frickelei, es kostet Geld und Zeit, es ist l'art pour l'art.

Achso, nach der Logik frickeln also die, die das System verstanden haben, und die für viele Kunden sinnvollste Lösung implementieren? Na ich sag ja, deine Kunden...

Sich die Frage nach dem Verhältnis von Aufwand und Ertrag nicht zu stellen ist das traditionellste und größte Manko in der IT. Wenn sich die Clients alle selbst über das Internet betanken können und der entsprechende Mechanismus so überaus zuverlässig wie bei den MS-Betriebssystemen der letzten Jahre, dann Finger weg von Zusatz-Software, die lediglich ein funktionierendes System durch ein zu verwaltendes System ersetzt.

Wie ich schon oben erwähnte, welchen Aufwand generiert ein WSUS, der keinerlei Patches lokal ablegt aber trotzdem die Reports der Clients bekommt? Aber stimmt, dazu müßte man dann ja da "System verstehen und frickeln". ;)

 

 

 

Der WSUS macht auch hier und jetzt wieder Ärger, er verstellt den Blick auf Wichtiges, nämlich die Ablösung des SBS durch schlankere Nachfolgesysteme. Die Frage, die auch für euch entscheidend ist, lautet: Was machen wir in der Nach-SBS-Ära?

Was so einfach verstellt sich dein Blick? Keep focused. Und das Thema nach Lösungen für SBS Kunden ohne SBS, wurden hier mehrfach durchgekaut. Im Allgemeinen gehen die Tendenzen zu entweder Standard Lizenzen von Windows und Exchange und dann meist 2 VMs, oder eine Hybridlösung mit Office 365. Letzeres, aber sehr viel seltener hier im Forum hab ich den Eindruck.

 

Bye

Norbert

[CoolBlue 10]

Wie lizenzierst Du eigentlich die Kunden in Deinem RZ, wenn das deren VMs sind?

Über Microsoft SPLA. Es läuft ja auf meiner Hardware. Solange sind es natürlich aus lizenzrechtlicher Sicht meine VMs. Aber wenn der Kunde die haben will, kann er ja jeder Zeit davon eine Kopie bekommen. Nur muss er dann die erforderlichen Lizenzen über einen Open-Vertrag selber nach kaufen.

 

Das installierte Windows (und Exchange, etc) ist technisch 1:1 identisch zwischen SPLA und Open Lizenzen.

[Daniel -MSFT- 129]

Über Microsoft SPLA. Es läuft ja auf meiner Hardware. Solange sind es natürlich aus lizenzrechtlicher Sicht meine VMs. Aber wenn der Kunde die haben will, kann er ja jeder Zeit davon eine Kopie bekommen. Nur muss er dann die erforderlichen Lizenzen über einen Open-Vertrag selber nach kaufen.

 

Wenn Du Lust hast, dann melde Dich mal per pm. Ich hätte Interesse an Feedback über SBS-Kunden und daran, Dein Szenario besser zu verstehen.

 

Have fun!

Daniel

[monstermania 53]

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.

 

Moin,

beim Einsatz von Virtualisierung sollte man sich auch mal über das Backupkonzept Gedanken machen. BE ist in virtuellen Umgebungen schlecht! Im VM-Ware Bereich ist Veeam einer der Marktführer wenn es um Backuplösungen geht (gibt es auch für Hyper-V).

BE war ja mal ganz schön wenn man viele Blechkisten hatte aber im virtuellen Umfeld ist BE suboptimal, ja m.E. sogar überflüssig. Seit Veeam jetzt auch noch Tape-Librarys unterstützt sehe ich keinen Grund mehr BE einzusetzen.

 

Gruß

Dirk

[CoolBlue 10]

BE kann doch auch via VMware vCenter backuppen und auch Hyper-V ?!?

Läuft hier jedenfalls so