Weingeist

Hyper-V und kostenlos, das ist doch immer wieder amüsant zu lesen. Es ist eher so, dass man die Features mit dem OS bezahlt. Kostenlos wurde durch immer neue Lizenzbeschränkungen, den Wegfall von inklusiven CAL's und einem etwas höheren Produktpreis erzielt. Kein Mensch wird HyperV ohne ein Windows Server OS betreiben. Irgendwie wird eine Funktionalität immer bezahlt, sonst verdient ein Unternehmen kein Geld. Und weil man der Konkurrenz (v.a. VmWare) eins auswischen will, muss man das auch bezahlen wenn man die Technologien gar nicht von MS braucht. Gäbe es VmWare nicht, gäbe es garantiert CAL's für HyperV, ein eigenes Produkt oder gar kein HyperV ;) VmWare wird deshalb von den Anschaffungskosten her immer teurer sein als Windows. Günstig (nicht günstiger) bleibts bei VmWare nur, wenn man mit Essentials oder dem free ESXi zurecht kommt. Letzteres geht nur, wenn man eine Backuplösung anpeilt welche nicht auf die HyperVisor-Funktionen zurückgreift, sondern sich an den Methoden von physischen Maschinn orientiert. --> Basis Image im abgeschalteten Zustand ziehen, mit konventionellen Backupmethoden (OS-Features, normaler Backupanbieter, Scripts mit Robocopy + VSS etc.) Zwischenstände sichern, ab und an das Basis-Image erneut wegsichern. Je nach Umgebung und Bequemlichkeitsanspruch sinnvoll oder nicht. Was mir an VmWare und seinen Essentials eigentlich noch sympathisch ist: Die ganzen fehlenden Features der höheren Versionen von VmWare sind ein gutes Argument in der Lizenzierung von Windows Server. Hat man technisch kein vMotion, HA und sonstige Spässe, verliert man zwar an Flexibilität, dafür benötigt man aber auch deutlich weniger Lizenzen (1*) und auch kein SA auf Applikationslizenzen wie SQL und Exchange. Klar, auch das nicht in jedem Fall sinnvoll, muss man halt abwägen. Zu 1*: Keine Lizenzmobilität, weil man nicht einfach eine produktive, laufende Instanz zahlt, wie es fair wäre, sondern jeden Host auf dem die Instanz laufen kann muss über eine Lizenz verfügen. Sprich bei zwei Hosts mindestens die doppelten Kosten, das dreifache bei 3 Hosts. So landet man selbst in einer kleinen Umgebung sehr schnell bei Datacenter-Lizenzenzen und exorbitanten Kosten. MS könnte es total egal sein worauf eine Instanz läuft, Hauptsache diese produktiv genutzte Instanz wird bezahlt. Die zusätzliche Flexibilität ist bei der Verwendung eines HyperVisors weder MS zu verdanken, noch haben sie Leistungen dafür erbracht. Also reine Geldmacherei. Genau wie bei Verwendung von Remote-Technologien. Man bezahlt eine zusätzliche Lizenz für RDS, auch wenn man einen fremden Anbieter nutzt.

@Norbert: :p Der SBS 2003 und vor allem der R2 Premium war und ist auch heute noch punkto Preis-Leistungsverhältnis absolut ungeschlagen. Performance auf neuen Computer excellent. Die Suche im Gegensatz zum neuen Krampf extrem schnell und vor allem zielführend und für jedermann verständlich. Als VM zudem absolut problemlos, auch wenn nicht supported, weil die Hardware auch bei einem Restore identisch ist. Aber ein Produkt ins Internet zu hängen ohne Sicherheitsupdates halte ich schon für sehr fragwürdig. Man wird den Schritt auf ein neueres machen müssen. Auf 2011 ist sicher ebenfalls nicht verkehrt. Finde es nur schade, aktuell mit alten Mitteln Server auszurollen. Vorsicht: Die Sammelwut an Informationen der Dienste ist unbeschreiblich, zieht die Performance unter Umständen ganz schön in den Keller bei Verwendung als VM auf einem nicht sehr schnellen System.

SBS 2012 usw. schön wärs... Fakt ist, er kann beim SBS nur auf ein bereits älteres OS migrieren. Das heisst auf den SBS 2011 welcher auf Server 2008R2 basiert. Vom 2008R2 gibt es zum heutigen Zeitpunkt bereits 2 Nachfolger (bzw. 1.5). Alternative ist nur die deutlich teurere "gewöhnliche" Lizenzierung.

So sehe ich das in diesem Fall auch, wollte mich nur absichern. Auch wenn der Vergleich hinkt, der Chef hat meistens den teureren ;) Dankeschön

Hallo Leute, Muss bei einem Kunden neue, aktuelle Lizenzen beschaffen. Dieser sieht nun nicht ganz ein, warum seine Lehrlinge in der Produktion auch alle soviel wie seine Arbeiter bezahlen sollen, vor allem weil sie ja gar nicht an die PC's sollen, dürfen, können ;) Folgende Situation 1. Lehrlinge haben in einem Betrieb keinerlei Zugriff auf irgendwelche Computer des Betriebs 2. Die Lehrlinge haben einen eigenen Lerncomputer um zB. Aufgaben für die Schule oder das 10-Finger System zu lernen 4. Der oder die "Lehrlingscomputer" haben Zugriff auf Ihre Ordner auf dem Fileserver sowie den Printserver 5. Die Umgebung ist komplett auf User CAL's basierend lizenziert, es gibt für jeden MA eine UserCAL (Deutlich Mehr Geräte, Maschinen und Computer als Mitarbeiter) 6. Es ist unmöglich, dass sich ausser den Lehrlingen jemand anders auf dem PC einloggt (Keine Anmelderechte) 7. Die Lehrlingen müssen irgendwann an Maschinen arbeiten, welche wiederum Filedienste auf dem Server beansprucht Fragen Office: Dürfen solche Computer mit "Office for Home/Students" lizenziert werden obwohl er im Prinzip wegen der File/Printdienste auf das Unternehmensnetzwerk zugreift? Zugriff-Cal: Braucht es für jeden Lehrling ebenfalls eine UserCAL? Reicht eine Device-basierte Lizenz? Dieser hat allerdings Zugriff auf den Server, damit Sie Ihre Dokumente sicher ablegen können. Zudem Drucken sie über die Betriebs-Umgebung. Office: Da es sich um einen Firmencomputer handelt, dürfte leider die Student-Version ebenfalls unzulässig sein oder? Zugriff-Cals: Für mich ist eigentlich Punkt 4+7 der Grund, warum zum Beispiel auch eine UserCAL benötigt wird, Device CAL würde imho nur gehen wenn sie an den Maschinen mit Netzwerkzugriff nix machen dürften, sonst fällt deren Konzept mit der UserCAL-Lizenzierung. So habe ich denen das mal empfohlen, auch wenn die das nur widerwillig geschluckt haben, dass alle Maschinen und Drucker eigentlich auch eine CAL benötigen. Es wurden dann eben zusätzlich UserCAL's beschafft. ;) Ich bin zwar auch der Meinung, dass MS in letzter Zeit schon genügend Kohle abzwackt und ziemlich Kundenfeindlich geworden ist, aber ich sehe irgendwie kein wirkliches Entgegenkommen für Auszubildende in den Unterlagen von MS und würde denen deshalb die Kiste ganz normal wie eine Arbeitsstation lizenzieren und für die Lehrlinge eben auch UserCAL's. Lösung wäre wohl nur, dass der Lehrling generell keinen Kontakt mit den entsprechenden Maschinen haben darf und der PC völlig eigenständig ist und z.B. direkt mit dem Printserver kommuniziert und die Files selber ablegt. Wie seht ihr das? Grüsse und vielen Dank!

Und wenn man lieb per Telefon fragt und eine stichhaltige Begründung liefert, bekommt man auch solche die deutlich Älter sind. MS ist da sehr zuvorkommend :thumb1: Virtuelle Desktops: Du kannst auch allen User ein Server-OS anbieten und den Zugriff mit RDS UserCals abdecken. Vorteil: Weniger Spyware, länger unterstütztes OS, keine unbedingte SA-Zwang, Lizenz-Kauf möglich (VDA nur Miete), man kann also aus einem Vertrag aussteigen und weiter arbeiten Nachteil: Ohne DC-Version evtl. unsinnig, Zusatzprogramme unter Umständen deutlich teurer --> Antiviren-Scanner etc., etwas teurere Anschaffungskosten Hat man genügend Server in der gleichen Umgebung im Einsatz, ist das mitunter sogar sinnvoll alle Hosts mit DC auszurüsten. Erspart einem manchen Ärger, weil MS leider immer noch nicht laufende und eingesetzte Instanzen von Server OS lizenziert sondern mehrfach-lizenzierung fordert (Keine Lizenzmobilität zwischen Hosts). VmWare hat sogar mit der offiziellen Unterstützung von Server-OS in View begonnen. Bis dato war das nur mit Installer-Manipulation und unsupported möglich.

Auch wenn es nicht um SSD's geht (denke ich mal bei USB-Platten?) Das mit dem Hardwarecontroller mag sein, muss aber nicht in jedem fall sinnvoll sein. - Hardware-Controller und Trim ist nach wie vor ein extrem seltene Kombination. Die beste GC macht Trim nicht überflüssig (das kann in Teilen nur ein massives Overprovisioning wirksam bewerkstelligen) - SSD's verwenden einen eigenen Cache, was da drinn ist, ist tot wenn der Strom weg ist. Kondis als Pufferung haben die wenigsten. - die Hardware-Controller leiten Schreib-Befehle direkt an die SSD's, also kein Cache der mit einer Batterie gepuffert wird Wozu also noch eine zusätzliche Instanz dazwischen verwenden wenn es die SP's auch gut machen? Das Filesystem an sich ist so robust, dass es Stromausfälle locker aushält. Was aktuell geschrieben wird, ist mit den meisten SSD's eh weg oder wurde schon vorher genügend schnell auf die Platte gebruzelt. Aufgrund dieser Tatsachen kann man gut darauf verzichten bzw. muss sein Backupsystem ebenfalls entsprechend performant auslegen und das Zeitfenster sehr klein halten. Dann sind die Daten, falls es dennoch crashen sollte, ratzfatz wiederhergestellt, auch wenn es mehrere hundert GB sind. Probleme mit dem ersetzen von ausgefallenen Platten hatte ich bis anhin nicht. Habe aber auch nur diverse Konstellationen mit SSD's und hartem entfernen und Stromausfällen unter Volllast durchgespielt, weil mir noch keine SSD's weggestorben sind. Was man mit den Storage Spaces immer beachten muss ist, dass bei der Verwendung von ReFs genügend freier Speicherplatz vorhanden ist. Kann mitunter lästig werden. Das neue System ist so robust, weil erst die neuen Blöcke geschrieben werden, dann die Links im Filesystem angepasst und die alten Blöcke freigegeben werden. Dumm nur, wenn kein Platz mehr vorhanden ist und diese Dinge nicht mehr funktionieren. Ist ein unsäglicher Bug bei dem angeblich schon einige Volumes gecrashed sind. Selber provoziert oder überprüft habe ich diesen Fall noch nicht. Wie auch immer, alles was nicht SSD ist, würde ich persönlich ebenfalls nen Hardware-RAID-Controller verwenden. Für SSD's geht auch gut ein hochwertiger HBA mit TrimSupport und Storage-Spaces. Zwei Hardware-RAID-Boxen die mit Storage-Spaces gespiegelt werden gehen natürlich auch. Storage Spaces mit direkt angeschlossenen Magnetplatten ist dagegen Write-Technisch eine ziemlich miese Angelegenheit. Bei aktiviertem Cache der HD's ist wiederum ein korruptes Filesystem ziemlich wahrscheinlich wenn der Strom weg ist.

Also ich bin ja ein Befürworter von den Storage-Pools und setze sie mittlerweile in einigen kleinen Umgebungen als Basis für VM's ein. Man erhält mit SSD's und Storage Spaces eine extrem hohe Performance, hohe Sicherheit und gute Erweiterbarkeit. Im Grunde bin ich ja auch für innovative oder unübliche Wege. Was Du hier aber betreibst, ist meines erachtens aber das Gegenteil von sinnvoll. USB-Platten sind meiner Ansicht nach nur als Single-Laufwerk für den Datentransport oder als Ziel für Backups tauglich. Die Storage Spaces sind wie jedes Software-RAID oder Hardware-Box ziemlich komplex, auch wenn sie relativ einfach zu bedienen sind. Da sollte, nein muss man auch entsprechende Hardware verwenden. Dazu gehört mindestens ein Server mit ECC-Ram, Doppelnetzteil, eine (besser zwei) USV sowie entsprechende Festplatten/SSD's aus dem Unternehmenssegment der Hersteller. Alles andere ist Murks. Das ganze im Energiesparmodus zu betreiben halte ich auch nicht für die sinnvollste Variante. Wäre mir deutlich zu heiss. Unabhängig davon ob es bei dir nun bis jetzt funktioniert hat oder nicht.

Diesen Fehler habe ich in VM's auch schon öfter gehabt. Allerdings unter VmWare. Chkdsk und Reboots waren jeweils für die Katz. Lösung war jeweils nicht um die gesamte verfügbare Grösse zu erweitern, sondern ca. 150Mb weniger, je grösser die Disc war, desto mehr Freiraum. Bei Discs mit mehreren 100GB habe ich ca. 5GB freigelassen und das Spiel solange getrieben mit kleinen Erweiterungen, bis der Fehler nicht mehr kam. Normal reichte 1x wenn ich ein paar GB frei liess. Was genau da schief läuft habe ich nie herausgefunden. Es war aber immer das Systemlaufwerk, immer wenn Schattenkopien aktiv waren und fast immer wenn nicht viel freier Speicher verfügbar war vor der Erweiterung.

Naja, MS hätte das SBS-System Modernisieren können. Rein laufende ServerInstanz-basiert, egal ob physisch oder virtuell (also nicht 2 instanzen pro Lizenz) So mit ner Art-AddIn-System und RundUm-Sorglos Cals für Kleinkunden. Das ganze bis 50 oder 75 User oder so. - Instanz für AD1/Files - Instanz für AD2/Files - Instanz für Exchange - Instanz für WSUS/Print Dazu SQL-AddOn - Instanz Server + SQL-Server (evtl. separate Cals) Sowie ein HA-AddOn - Lizenzmobilität innerhalb eines Clusters von max. 3 Maschinen (wie zbsp. VmWare Essentials) sowie das recht ein Replikat auf einer anderen Maschine zu halten. Ist leider Wunschdenken....

So siehts aus. Deine Mails gehen immer an DynDNS und dann zu Dir. Auf Wunsch wird auch gleich Spam herausgefiltert oder auch ein allgemein vertrauenswürdiger Server (wegen Spam) für den Versand bereitgestellt (sollte man dyn-Ip haben sinnvoll). Die Kosten sind ziemlich überschaubar. Ob man dabei DynDNS seine Mails anvertrauen möchte (Datenschutztechnisch) steht auf einem anderen Blatt, aber ganz alles kann man eben doch nicht haben und Mails sind eh ein offenes Buch im Netz. Bis dato habe ich noch keine vernünftige Fertiglösung/Anleitung gefunden wie man das selber auf einem Webspace zbsp. mit einem vServer realisieren könnte. Es ist technisch nicht ganz so einfach wie es vorerst aussieht, zumindest nicht für dynamische IP's. Würde daher also auch nicht selber 'basteln'. Sondern eher einen solchen Anbieter verwenden, Mail gänzlichen auslagern oder damit leben, dass vielleicht Mails mal nicht ankommen. Wenn das wirklich 48h dauert bis eine Mail verworfen wird - ich war immer der Meinung das sei wesentlich weniger - dann dürfte das bei fixer IP völlig problemlos sein, auch wenn ein Recovery gefahren werden muss.

Bezüglich dem von mir genannten E-Mail-Gateway von DynDNS: Das ist weder eine Frickellösung mit POP3 noch ein BackupMX. Zustellung erfolgt wie üblich per SMTP. Der einzige Unterschied, er nimmt eben an und wartet mit der Weiterleitung bis man wieder online ist und verwirft die Mails nicht. Dabei werden alle Mails darüber geroutet. Kleiner Exkurs wofür das eigentlich gedacht ist: zbsp. dann verwenden wenn man keine fixe IP hat / bekommen kann / aus Kostengründen weil Übertragunsrate extrem lausig usw. In einigen Regionen bekommt man beispielsweise keine DLS-Line mit fixer IP mehr bei den normalen Abos. Man braucht also ein Business-Abo wo wiederum die Downloadraten extrem schlecht sind oder das Abo viel zu teuer wäre. Würde also bedeuten entweder separate Anbindung des Mailservers oder eben Dynamische IP. Bei separater Anbindung muss man wieder beachten, dass Mail-Daten zbsp. via Line1 und Surfen via Line2 geleitet werden. Nicht immer so einfach wie man das gerne hätte. Es ist immer sehr einfach und schnell gesagt, das macht man so nicht, das ist gebastelt usw. Aber Fakt ist auch, Kleine haben nunmal nicht das gleiche Budget wie ein Grosser. Die Funktionalität und Flexibilität möchte/muss er aber auch haben. Man kann überall sagen da muss er durch, aber das summiert sich gewaltig und ist irgendwann nicht mehr tragbar. Sei es Lizenzen, Internetanbindung, Support, Hardware usw. Clouddienste sind auch nicht die eierlegende Wollmilchsau. Bezüglich Backup: Da würde ich Mails einfach bei Ankunft direkt an eine Sammelmailadresse auf einem anderen (internen oder externen) Mailserver weiterleiten. Für Notfälle reicht das aus. Der eigentliche Mailserver wird ja entsprechend per Backup gesichert.

Zu deinem Wunsch für ein E-Mail-Abnehmer im Falle eines Downs deines Server gibts (gabs?) zbsp. von DynDNS einen Dienst welcher die Mails annimmt und per smtp an deinen Server leitet sobald er wieder online ist. Quasi Pop für SMTP ;) Nannte sich "Dyn E-Mail Gateway". Geht auch mit fixer IP.

Sag ich doch, das Ding ist eh schon nimmer wirklich supported ;) Und MS würde schon helfen, zumindest wenn man das gleiche Verhalten auch auf ner physischen Maschine reproduzieren kann... Gibt halt Vorbereitungsarbeit...

Wegen virtualisiert supported oder nicht, darüber würde ich mir mal gar keine Gedanken machen. Das läuft problemlos. Was mir eher Sorgen machen würde, ist die Tatsache, dass auch bald die Einstellung von Sicherheitsupdates folgt. Daher lieber auf SBS 2011 upgraden wenns ein eigener Mail-Server sein soll, sonst kommt das preisliche erwachen wenn man weiterhin Exchange betreiben möchte. ;)

Es gibt diverse Möglichkeiten einen SBS oder kleine Serverumgebungen auch zuverlässig inkl. Überwachugn mit Bordmitteln zu sichern ohne dass man auf zusätzliche Backupsoftware zurückgreifen muss, welche zwar Komfort schafft, aber auch zusätzliche Komplexität durch deren Datenbanken, eigene Filesysteme, Software mit Fehlern, Unterstützung neuerer OS manchmal erst später usw. aber vor allem Kosten. Anbei auch noch ein paar Inputs: - Windows Backup ist weder Gebastel noch schlecht. Fehler kommen in der Ereignisanzeige. Entweder prüft man diese regelmässig oder man baut Trigger mit einer E-Mail Warnung für Ereignisse die man überwachen möchte. (zbsp. per E-Mail mit Blat) - Windows kann mit robocopy sehr wohl auch geöffnete Files sichern, wenn auch nicht direkt. Dazu braucht es entweder ein Tool wie DriveSnapShot oder das SDK für VSS für die entsprechende Windows Version. Damit kann man dann per Kommandozeile einen VSS-konsistenten SnapShot erstellen und anschliessend in einem Windows-Ordner bereitstellen und diesen sichern. - Um Files möglichst Rasch wieder griffbereit zu haben, kann man zbsp. einen Robocopy-Mirror auf einem andern Laufwerk vorhalten, welcher zbsp. Stündlich abgelichen wird. -->Zbsp.auf einem PC in einem anderen Brandabschnitt liegt oder dem Rechner des Chefs. Vorteil gegenüber einem einfach NAS ist wie immer die erhaltung von NTFS-Rechten. - Auch DFS Replikation ohne den Ordner in DFS tatsächich zu Verfügung zu stellen (Oder als gesperrtes/deaktiviertes Ziel) ist eine gute Mirror-Variante welche sehr schnell wieder online ist. - Historyproblematik mit Windows Backup bzw. Sicherung des System Volume Infos: Die Recht kann man sich durchaus mit Gewalt aneignen, wenn es sein muss. Notfalls mit einem Script welches einem die Rechte gibt und per Task als System ausgeführt wird. Allerdings gefällt mir schon die Art von Sicherung auf 'normale' NAS-Lauwerke nicht besonders, weil eben häufig die ganzen NTFS-Berechtigungen verloren gehen. Auch sind Schattenkopien von verschiedenen NTFS-Diensten wie USN-Journal abhängig, ich habe keine Ahnung ob das wirklich zuverlässig per reinem Filecopy gesichert und vor allem wieder rückgesichert werden kann. Wäre mir zu heiss und zu kompliziert. - Sicherung mit WindowsBackup auf ein iSCSI-Laufwerk welches auf einem anderen Server liegt: Hat den Vorteil, dass man alle History-Funktionen weiterhin nutzen kann. Recovery ist mühsamer, da erst nach einer Windows-Installation nutzbar. - Verwenden von Virtualisierung: Hat den Vorteil, dass man Laufwerke von verschiedensten Datastores einbinden kann. Also kann auch ein günstiges NAS problemlos als BackupZiel aus einre VM heraus verwendet werden. Oder wiederum ein Dedupeziel wo man die komplette Virtuelle Disk aus dem Host-System drauf kopiert. So hat man wiederum eine History von einzelnen Fullbackups bzw. ganzen Backupketten, die aber nicht viel Speicher brauchen. Vorteil ist hier vor allem, dass bei einer Wiederherstellung direkt auf die Discs zurückgegriffen werden kann. Da ist ein Recovery zu einem beliebigen Datenbestand unter Umständen Ratz-Fatz gemacht. - Betriebssoftware mit Datenbanken etc. --> Jeweils Fullbackup auf ein Dedupe-Volume. --> Schafft auf einfache weise eine riesige Backuphistory ohne viel Speicherplatz zu verbraten. Die Files können wieder mit Robocopy auf ein weiteres Volume kopiert werden. Es gibt X-Varianten wie man viele der Funktionen von modernen Backupsystemen mit Windows-Bordmitteln erreichen kann. Der Einwurf das wäre alles viel zu kompliziert, kann ich nicht teilen. Es erfordert lediglich etwas Kreativität und eine gute Dokumentation. Verwendet man zbsp. SSD's als primären Speicher, sind selbst Full-Recoverys innerhalb kürzester Zeit erstellt. Manche der Dinge wie tägliches Fullbackup aller Files machen natürlich nur bis zu einer gewissen Menge an Daten Sinn. Aber das muss man eben situativ entscheiden. Wenn man vom Desaster-Fall ausgeht wie Brand oder Diebstahl, kommt es auf ein paar Stunden mehr Arbeit auch nicht mehr drauf an. Es reicht meiner Meinung nach deshalb aus, das 'normale' Backup schnell Recoverfähig zu halten und für den Desasterfall ein Szenario zu wählen, welches für das Recovery unter Umständen mühsamer ist und mehr Vorbereitungszeit benötigt. Wichtig ist nur, dass es gut dokumentiert ist. Hier noch Lektüre zu VSS und dessen Bereitstellung als Mount-Points in Verbindugn mit Robocopy (Sicherung von geöffneten Files): - http://serverfault.com/questions/119120/how-to-use-a-volume-shadow-copy-to-make-backups - http://axelilly.wordpress.com/2009/01/15/creating-vss-snapshots-on-windows-2003-server/

Die 2400er Serie ist die abgespeckte von 2600/1600. Die haben nur 3 Memory Channel, die grossen aber deren 4. Deshalb nehme dafür Supermicro. Das heisst ich würde Single Socket Xeons E5 aus der Reihe 1600v2 verbauen: E5-1660, E5-1650, E5-1620 wobei der Schritt von 1620 zu 1650 deutlich spürbar ist. Exkurs zur virtualisierung (in Hinblick darauf, dass es den SBS eigentlich schon gar nimmer wirklich gibt und man mehrere virtuelle Instanzen braucht). Ein E5-1650/1660 reicht bei entsprechend performanten Platten mit genügend IOPS (zbsp. SSD's) sogar für eine komplette kleine virtuelle Umgebung mit ein paar Server und Arbeitsplätzen auf sehr performantem Level. Mir kommen da regelmässig die Tränen, die virtuellen Clients sind deutlich schneller als meine physische Arbeitskiste (Quad wenig GHZ, SSD) bei den gewöhnlichen Arbeiten. Office-Starts usw. Hab in diesem Jahr zwei kleine Umgebungen im produktiven Testbetrieb so eingerichtet und das läuft wie die Hölle. Is halt einfach so, das bei viel GHZ die anfragen schneller bearbeitet sind und der Kern somit auch schneller wieder frei für was anderes. Wenn SSD in Frage kommen, keinesfalls daran sparen (Intel DC3700 zbsp. oder PCI-Express SLC von Micron). Auch Recovery (in der Testphase) sind extrem schnell gemacht. Bei gscheitem Backup-Konzept ist die Umgebung dank SSD's auch bei vielen Daten extrem schnell wieder oben, auch wenn alles tot ist. Ist meine Meinung dazu die niemand teilen muss =)

Hi, setze einige Fujitsu Server ein. Sind alle problemlos bis jetzt. Support ist auch zufriedenstellend. Mühsamn sind sie nur in Verbindung mit VmWare und den angepassten Images. Das dauert ewig und machen Dell und HP besser. Kann man aber auch alles zu Fuss erledigen. Ansonsten: Hohe GHZ-Zahl ist sinnvoll, wenn man Anwendungen hat, die nur auf einem Core rechnen. Da sind die Auwirkungen teilweise ziemlich extrem. Bei Virtualisierung sollte möglichst wenig Kerne gegeben werden (Verwaltungsaufwand bis alle frei sind usw.), mit zwei funktioniert der SBS zbsp. prächtig, die hohe GHZ-Zahl ist aber deutlich spürbarer als nen Kern mehr bei zbsp. WSUS-Übersichtsberechnungen oder Dedupe Vorgänge (neueres OS) Wie man sieht, es kommt wie immer darauf an was und wie man mit der Kiste etwas macht, kann man so pauschal nicht beantworten. Stromverbrauch steigt mit hoher Taktrate auch massiv an. Immer berücksichtigen in der Preiskalkulation. Im Grunde liegt bei vielen Server die CPU ziemlich brach, in dem Moment wo sie gebraucht wird, kann es eh nie schnell genug sein. Ich würde mich nach einem Single-Socket System auf E5 Basis für 1600er/2600er CPU's umsehen. Da hast du Quad-Channel RAM + verhältnissmässig günstige sehr schnelle CPU's zur Auswahl. Die Schnellen CPU's sind auch deutlich preiswerter als solche für die DualSysteme. Die meisten Serverhersteller bieten aber nur den kleinen Xeon bzw. agespeckte Version für Server als Single Socket an und die grosse Serie nur in Workstations. Warum auch immer. Schöne Ausnahme ist zbsp. Supermicro.

Das genannte Tool scheint ziemlich schlau zu sein... Im Grunde gehen solche Dinge auch mit folgender dreckiger Variante. Mittels-PC welcher mit dem ADMT-Tool ausgestattet ist. Mitglied soweit ich mich erinnere in der Ursprungsdomäne. Sowie ein Migrations-User in beiden Domänen jeweils mit Domänen-Admin Berechtigungen mit identischem Namen und Passwort. Ist nicht wirklich schön aber zumindest von 2003 auf 2008 ging das jeweils sehr problemlos. War das/mein Standardvorgehen für den SBS-Server wenn die neue Domäne sowie der Server nach der Migration am Ende identisch heissen sollten ohne das ein Inplace Update gemacht werden kann/soll. Heute sind die Migrationen deutlich entspannter. Fallstricke: Die Benutzer sollten in der neuen Domäne noch nicht existieren. Alle migrierten Gruppen/Konten haben am Ende neue SID's mit der alten SID in der History sowie ein Verfallsdatum (Benutzer)! Das musst du manuell deaktivieren. Entweder per Script oder zu Fuss. Sonst hast ein paar Monate Später die Hölle in der Helpline. Wenn Du nach SBS-Migration mit identischer Domäne und Server Name suchst, solltest die entsprechende detaillierte Guides eigentlich finden und ableiten können. Wenn schon bestehende Benutzer sind, sollte man besser ein Tool verwenden wo man einem bestehenden Benutzer bzw. SID mit einer Tabelle eine oder mehrere weitere SID der History hinzufügen kann. Habe ich auch schon gesehen. Oder eben anders rum, die Berechtigungen auf den Ordner ändern. Da hätte ich aber gemischte Gefühle.

Je nach Definiton von finanziell vernünftig, gibts da verschiedenen Varianten und einige auch günstiger als mit gespiegelten SAN's machbar. Ein Klassiker sind zbsp. Zugangssystem-Anbieter, die sind dauernd mit solchen 'Spässen' konfrontiert. Je nach Aufgabe, benötigtem Speicherplatz, Rechenleistung etc. würden evtl. zwei synchron laufende Maschinen bereits ausreichen. Wenn Ein Ausfall der Maschine und Neustart ausreichen würde, wäre evtl. auch ein Replikatlösung möglich. HyperV kann das oder DoubleTake Varianten: - Xen und der Marathon-Erweiterung für MultiCPU-VM's im Lockstep (braucht nur zwei Standardserver mit eigenem lokalen Storage, sehr clever gemacht, Primäre Maschine wird nur im Totalausfall gewechselt), einigermassen preiswert - Physisches Lockstep mit Stratus-Server, Nachteil: Beide Maschinen selber Standort bzw. ein Gehäuse, theoretisch HyperVisor direkt installierbar, ziemlich teuer - VmWare mit FaultTolerance, Beschränkung auf eine vCPU sowie einem gespiegelten Storage mit transparentem Failover (Datacore, HP LeftHand usw.), sehr teuer

Es ist eigentlich ganz einfach mit dem vor einigen Posts geposteten Ausschnitt aus den PUR's. Du kanns eine Lizenz einem neuen Server erst dann zuweisen wenn dieser ausser Dienst ist. Im Falle von vMotion müsste der Zielserver also bereits vor dem vMotion Vorgang lizenziert sein. Ansonsten würde das faktisch heissen, 1. VM herunterfahren 2. Lizenz verschieben 3. VM auf Zielserver hochfahren. Mit vMotion müsstest du also minimal eine Lizenz zuviel pro Host haben, damit ein solches Konstrukt überhaupt korrekt lizenzierbar ist und ist immer noch alles andere als praktisch. Nicht das ich das wirklich verstehe, finde es auch total beknackt, ist aber so. Fair wäre, wenn die laufende Instanz zertifiziert werden müsste. Völlig egal worauf sie läuft. Aber so ist das nunmal.

Danke für die neuen Inputs. @Dr. Melzer: Ein Chef der viel unterwegs ist, steigt aus einem vernünftigen Firmenwagen deutlich erholter bzw. eben nicht zusammengestaucht aus als zbsp. in einem Kompaktwagen. Schlägt sich direkt aufs Wohlbefinden und seine Leistung aus. Die Preise dieser Firmenwagen wurden nicht innerhalb von ein oder zwei Generationen im Preis verdoppelt oder verdreifacht. Neue Funktionen und Leistung gibts beim Neuen in der Regel auch dazu, sonst wird der alte behalten. Der Vergleich hinkt also deutlich. So sieht aber die Realität im Kleinkundensegment aus. Bei MS gehts aktuell anders rum, Funktionalität wird teilweise gestrichen und Preise erhöht. Verglichen mit einem SBS 2003 R2 - der zugegebenermassen sehr sehr günstig war - bezahlt ein kleiner Kunde mit sagen wir 5-10 Arbeitsplätzen mit Office, Exchange, SQL-Server für Software-mässig das gleiche mindestens das Vier- bis Fünffache als vor ein paar Jahren. Unter anderem weil eine Lizenz noch eine Lizenz war, egal über welches Programm sie gekauft wurde, man hatte die gleichen Rechte. Komischerweise hat MS zu damaliger Zeit noch richtig Kohle verdient. Da wurde noch mit Innovation von sich Reden gemacht, nicht mit beschneiden von Kundenservice, Funktionen, explodierenden Kosten, Lizenzverschärfungen und und und. Heute werden auf den ersten Blick unrentable Produkte welche mit entsprechendem Marketing richtig geil gewesen wären (ISA/TMG) einfach gekillt, ohne Ersatz. Die aktuelle Entwicklung finde ich wirklich extrem Schade und sehr bedenklich. MS wurde mit dem Kleinkunden-Segment gross (Verbreitung). Sie scheint vergessen zu haben, dass diese riesige Basis abspringen könnte wenn es ein gutes Konkurrenzprodukt gibt wenn sie preislich dermassen über die Stränge schlagen und die Bedingungen so schrecklich gestalten. Wenn Sehr viele kleine das Produkt einsetzen, dann sind auch die grossen nicht mehr weit. Von daher ist das meiner Meinung nach sehr kurzfristig gedacht. Am Ende haben wir wieder den Salat von X Plattformen und für jedes Programm ein eigenes Süppchen weil es nur auf einer Plattform läuft. Es war so schön die letzten 15 Jahre und MS hätte es in der Hand, dass es wenigstens im Unternehmensbereich so bleibt. So wie das aber aktuell läuft, wird das böse enden und weder MS noch seinen Kunden was bringen. Ganz im Sinne von Grossinvestoren und Manager. Fett einsteigen, dirigieren, fett Kohle machen und einen Scherbenhaufen hinterlassen. @Norbert: Den App-Schrott auf Windows 8 bekommt man mit einem kleinen Powershell-Script fast komplett deinstalliert. Den Windows Store sowie AppX-Dienst bekommt man mit einem Registry-Eintrag ebenfalls deaktiviert. Per GUI, Powershell ist Fehlanzeige. Kann man aber (noch) alles in ein wunderbares - mittlerweile riesiges - Script verpacken, zusammen mit den 100 anderen unnötigen Diensten und Aufgaben im Task-Scheduler. Zu 2012 R2, naja, es sind wirklich ausschliesslichen Dinge die früher mit nem SP gefixt wurden. Unterschiede im Funktionsumfang sind marginal und waren bei 2012 eher Beschneidungen bzw. noch nicht fertig (Beschränkter Ram-ReadCache, Dedupe bei ReFS usw.). Aber sehe das auch so, dient dem ursprünglichen Zweck einer SA. Man erhält Produktverbesserungen. Sind auch ein paar gute Verbesserungen mit dabei. Die Cals bleiben ja die gleichen. Die Liste von unfertigem wie Exchange 2013 lässt sich beliebig erweitern, zum Beispiel mit WSUS. WSUS braucht Report Viewer 2008, nicht etwas 2012. Report Viewer 2008 braucht .Net 3.5, .Net 3.5 lässt sich auf 2012 nur mit Powershell vernünftig installieren, weil das Setuppaket auf der DVD zwar vorhanden, aber nicht aktiviert ist. 3.5 ist mittlerweile ein unglaubliches Flickwerk. Wie auch immer, es kommt keine Meldung, schieb DVD rein um .NET 3.5 nachzuinstallieren, nein es funktioniert einfach nicht. Auf den Essentials hatte man es auch gleich deaktiviert bei 2012 und mittlerweile nex fix bereitgestellt. Bei R2 immerhin wieder von Anfang an aktiviert weil einfach zu viele gemeckert haben.

Hallo Leute, Vielen Dank für die Inputs! :) @kamikatze: Betrifft natürlich nur jene die 2003 R2 und SA hatten, da habe ich aber dafür gesorgt, dass die Verträge jeweils top-aktuell waren oder gleich noch nen neuen abgeschlossen haben kurz vor erscheinen des 2008. Im Wissen, dass so eine Gelegenheit nie mehr kommt und MS bei SA-Kunden und Ersatzprodukten bis dato noch immer fair war. So war es dann auch, man erhielt den TMG ;) Einige haben es auch nachgekauft. Ich kenne kein einfacheres Mittel für einen guten Proxy und Inhaltsbeschränkung für spezifische AD-Gruppen/Mitarbeiter, das so einfach zu konfigurieren ist und zbsp. in der Mittagspause viel mehr zulässt als während der Arbeitszeit. Äusserst Schade wurde es eingestampft. Nur noch Vollwertige Produkte: Ja schon, aber das ist unglaublich was man da in die Software investieren muss. Die halten mich regelmässig für verrückt (ok bin ich vielleicht auch etwas :D ) Finde es kostenmässig ja selbst total übertrieben für ein paar Clients wo man halt trotzdem irgendwo supported unterwegs sein möchte. Zwingt einem halt wieder etwas zu basteln und Dienste zusammenzulegen die einem nicht gefallen, Backupkonzepte wie vor 20 Jahren (keine Replikate) zu machen usw. Schade wird die Software nicht für quasi Umme verkauft und die Cals ein paar Euro teurer. Wäre viel 'moderner' und für die kleinen auch besser bezahlbar. Für MS wärs natürlich wieder ein Grund für einen massiven Preisaufschlag. :(

Hallo Leute, Vielleicht sind andere in der gleichen Situation. Ich habe einige Kunden und auch mich selbst wo die SA-Verträge auslaufen oder bereits ausgelaufen sind. Die jeweiligen Kunden haben sich an Exchange, SQL, WSUS und TMG gewöhnt. Also das klassiches SBS-Premium-Paket. Folgende Probleme: - Die SA ist für TMG quasi nutzlos und Neukunden können nichts vergleichbares erwerben. Preislich ähnlich interessant wie vorher im SBS sowieso nicht. - Deutliche höhere CAL-Kosten, aber OK, das ist schliesslich für alle so - Massiv höhere Server und Applikationskosten, das fällt richtig heftig ins Gewicht und ist für 5-10 User völlig unverhältnissmässig - Teilweise doppelte bis dreifache Lizenzierung nötig bei Nutzung aktueller Backuptechnologien oder modernen Ifrastrukturen mit Ausfallsicherung Mit HyperV wäre es ja grundsätzlich kein Thema das alles immer noch auf einer Maschine bzw. in der heutigen Zeit auf zwei Maschinen zwecks Ausfallsicherheit laufen zu lassen, nur die Lizenzierung ist haarsträubend teuer für Kleinkunden. Für das gleiche bezahlt man heute ein Mehrfaches. Die Cloud ist keine Alternative, ich wie auch diverse Kleinkunden möchten das nicht. Sei es wegen der Auspioniererei oder schlicht weil man dann noch weniger die Wahl für einen Ausstieg hat und komplett ausgeliefert ist. Beim Mail hat man diesbezüglich keine Wahl, also auch egal wenn das auf nem Server ist. Bei Kalender, Datenbanken etc. hört der Spass bei den meisten aber auf. Lügen auftischen mag ich den Kunden auch nicht. Grundsätzlich fällt es mir schwer auf Produkte und eine Firma zu verzichten, die ich seit DOS 5 sehr schätzen gelernt habe nur weil das aktuelle Management und vermutlich auch ein paar Investoren einen totalen Dachschaden hat und deren Ziel nur noch das maximale Melken und Abhängig machen des Kunden bedeutet - wie leider so üblich auf Konzernstufe. Alles nur, weil sie es sich aktuell einfach erlauben können und kein Patron mehr wirklich hinter der Firma steht. Was sind die Alternativen? Pfannenfertiges gibt es ja eh nichts, ein paar Überlegungen: - Wechsel auf Linux-Systeme und OpenSource-Varianten von Exchange die kein Mensch selber administrieren kann (so übliche Dinge) und Wartungsaufwand grösser sein dürfte - Darauf warten bis die Jungs wieder vernünftig werden? - Verwenden von alter (gebrauchter?) Server-Software auf Clients zwecks längerem Support-Zeitraum für Sicherheitsupdates? evtl. in Virtuellen Desktop-Infrastruktur inkl. RDP - Weiterarbeiten mit veralteter Software, evtl. Konzepte mit von Internet abgeschotteten Oberflächen auf welche man sich nach dem Graphical-Wall-Prinzip verbindet Alle mit aktueller SA können wenigstens auf die aktuellsten Versionen zurückgreifen und haben so noch ein paar Jahre Ruhe. Sie wurden grundsätzlich sehr gut und fair entschädigt. Die Verlängerung wollen und teilweise können Sie sich aber nicht leisten. OEM-Lizenzierungsformen sind wegen Lizenzrestriktionen auch nicht mehr ein gangbarer Weg für moderne Infrastrukturen. Auch wenn man nicht MS-Technolgien nutzt und sie das nicht interessieren müsste. Mich würde da eure Meinung dazu interessieren sowie evtl. Lösungsvorschläge. Herzlichen Dank!

Mit einem einigermassen guten Proxy würde sich das relativ einfach machen lassen... Leider ist das entsprechende MS-Produkt EOL --> TMG Bitte bedenken, dass die Mobilfunkbetreiber solche Dinge normalerweise in den Verträgen verbieten und einem den Zugang sperren können...