monstermania

Grundsätzlich würde ich überdenken jetzt noch auf Windows 2008R2 zu migrieren. Sofern es keine technische Notwendigkeit gibt würde ich gleich auf 2012R2 umstellen. Lizenztechnisch wäre das eh egal, da man 2008R2-Lizenzen eh nur noch als Downgrade-Lizenz bekommt. Und vom Arbeitsaufwand von der Migration ist es eh egal. Ich gehe ja mal davon aus, dass es auch neue HW gibt und die Migration nicht Inplace durchgeführt werden soll?

Moin, ich würde das Backup auch auf einen 2. Server auslagern. Dann kannst Du gleich noch einen 2. DC auf dem Backupserver betrieben. AFAIK hat es ein Hyper-V Host nicht so gerne, wenn beim Start kein DC vorhanden ist. Die Backupdaten selbst müssen nicht zwingend auch auf dem Backupserver liegen, sondern können z.B. auf einem relativ preiswerten NAS liegen. Der Vorteil ist, dass Du mit einer geeigneten Backupsoftware (Veeam B&R Essentials) auch eine Replikation auf das NAS einrichten kannst. Das bedeutet, dass Du im Falle eines Ausfalls Deines lokalen Serverspeicher die Replikate vom NAS aus starten könntest. Als Backupsoftware würde ich Veeam empfehlen. Ist z.Zt. im Bereich Backup von virtuellen Umgebungen einer der Marktführer. Funktioniert Agentless und kann aus Exchange auch einzelne Elemente zurücksichern. Die Essentialslizenz von Veeam liegt so bei 700€. Wie soll ein Offsite-Backup realisiert werden? Ob nun RAID10, RAID5 oder gar RAID6!? Kommt immer auf die konkreten Anforderungen an IOPS und die vorhandene Hardware an. In Deiner angegebenen Größenordnung würde ich wohl zu einem RAID-5 mit Hotspare tendieren (SAS Platten mit echtem RAID-Controller mit Cache und BBU!). Gruß Dirk

Moin, wie genau definierst Du eine monatliche Sicherung!? Ein einzelnes Fullbackup, oder ein diff/inc. Backup, dass 30 Tage enthält?

Hui, 30 Minuten ist aber mal eine Ansage! :shock: Ich kann da Nils nur zustimmen. Holt Euch Jemanden mit Erfahrung und lasst Euch ein Konzept mit unterschiedlichen DR Zeitrahmen und den entsprechenden Kosten erstellen. Dann kann die Geschäftsführung entscheiden, ob Sie bereit ist das notwendige Budget bereitzustellen.

Das Problem ist, dass es nur in sehr wenigen Bereichen auf das 'letzte' Quentchen an Performance ankommt. Da diese Anforderungen schon sehr speziell sind wirst Du dazu kaum etwas im Internet finden. Gutes Beispiel ist z.B. auch der Turbo-Modus bei den Intel Core-CPU's. Wir haben hier mal Test im Bereich OCR (DMS) gefahren. Ein OCR Task lastet einen CPU-Kern für mehrere Sekunden pro Seite voll aus. Da kann es im Einzelfall schon sinnvoll sein, wenn die CPU im Turbo Modus um 25% schneller ist. Bei einem Desktop merkt man das dann schon. Bei einer parallelen Auslastung aller Kerne durch mehrere OCR Tasks spielt der Turbo-Modus dagegen nahezu keine Rolle. Da hilft dann nur die reine Anzahl der Kerne. Gerade das von Dir genannte Beispiel (SQL-Server) ist schon sehr speziell. Da muss man schon sehr genau wissen, welche Werte man wie misst.

Auf RDP-Servern haben wir mit estos sehr gute Erfahrungen gemacht.

Moin, stellt sich die grundsätzliche Frage, was willst Du damit bezwecken!? Der Umstand dass eine native Installation des OS performanter ist, als eine Installation per Hypervisor ist grundsätzlich ja schon klar. Von daher finde ich das genaue Ausmessen jetzt ziemlich sinnfrei. Aus der Praxis heraus kann ich sagen, dass sich bisher kein Kunde beschwert hat, wenn er auf Virtualisierung umgestellt wurde, da meist der Host entsprechend leistungsstärker gewählt wird (schließlich läuft ja i.d.R. nicht nur eine VM auf einem Host). Gruß Dirk

So einfach würde ich es mir und dem Kunden nicht machen. Ein guter Berater sollte den Kunden detailliert auf die möglichen Schwachstellen hinweisen. Dazu gehört z.B. dem Kunden genau zu erläutern, was z.B. passiert, wenn sich der Server verabschiedet (z.B. Mainboard oder Netzteil). Dem Kunden muss klar sein, dass je nach Defekt durchaus ein mehrstündiger oder gar mehrtägiger Komplettausfall Seiner IT bzw. des Servers möglich ist. Und natürlich gehört dann auch Dazu, wie z.b. einem solchen Szenario begegnet werden kann (Disaster Recovery) mit konkreten Reaktionszeiten und Anforderungen an vorhandene bzw. notwendige Hard- und Software und dem dafür notwendigen Kostenrahmen. Klar, kann der Kunde das nachher Alles/Teile davon ablehnen, weil es Ihm zu teuer ist. Allerdings bist Du als Dienstleister zumindest in sofern abgesichert als dass Du den Kunden vorher auf mögliche Ausfälle hingewiesen hast.

Aua Aua... :cry: Wenn Du nur einen 2012'er Server als Memberserver in die SBS Domäne aufnehmen willst brauchst Du keine Schemaerweiterung. Willst Du aber den 2012'er als zusätzlichen DC in der SBS Domäne betreiben muss natürlich auch das Schema erweitert werden. Das Problem bei Deinem konstrukt wird der der Lizenzserver für den RDP-Server werden. Dieser muss auch auf einem 2012 laufen. Aus Sicherheitsgründen sollte man die RDP-Lizenzdienste nicht auf einem RDP-Server installieren. Von daher wäre es am besten gleich 2 x 2012 Server zu nehmen. 1 als zusätzlichen DC mit den RDP-Lizenzdiensten und 1 als reinen RDP-Server.

Ja komische Konfiguration, klingt nach einem typischen "Eigenbauprodukt" Warum soll man einen solchen Server nicht zuverlässig betreiben können? Läuft doch gerade, oder? Ein Problem gibt es doch immer erst dann, wenn etwas nicht bzw. nicht gut läuft. Und sich gegen solche möglichen Probleme abzusichern ist die Kunst bzw. Deine Aufgabe als Dienstleister gegenüber einem Kunden. Diesen Server habe ich noch nicht gesehen. Aber in 20 Jahren Praxis habe ich so ziemlich Alles gesehen. Schon manchmal erstaunlich mit was für Systemen Firmen Ihre IT betrieben :rolleyes: . Aber alle 3 Jahre ein neuen Firmenwagen für den Chef! :D Was mein ich wozu? Zum Server? Na ja, wenn es läuft sehe ich zunächst mal keinen direkten Handlungsbedarf. :cool: Was ist denn Deine Aufgabe bei der Sache? Sprich mit irgendeiner Anforderung ist der 'neue' Kunde doch an Dich herangetreten, oder? Ohne eine Anforderung zu definieren ist es schwer etwas sagen zu können.

Moin, derzeit teste ich die Migration unseres Exchange 2007 auf Exchange 2010 (Aus technischen Grünen können wir z.Zt. nicht auf Ex 2013 migrieren). Zur Zeit haben wir 48 Ex. Nutzer und eine MB-db mit 122 GB und eine PublicFolder DB mit 2,5 GB. Das Wachstum in den letzten 12 Monaten war 30 GB. Es ist davon auszugehen, dass das auch in den nächsten Jahren so weitergeht. Bei immer mehr Mitarbeitern wird auch aus organisatorischen Gründen auf eine Begrenzung der max. Postfachgröße verzichtet (leider! :rolleyes: ). Bei der Migration stellt sich mir jetzt die Frage, ob ich Alles wieder nur eine MB-db migriere oder mehrere MB-db's einrichte (z.B. Abteilungsbezogen mit 3-4 MB-db). Wie sieht hier die Best-Practise bzw. Euren persönlichen Erfahrungen aus (pro oder contra mehrere MB-db's)? Gruß Dirk

Moin, das Problem lag offenbar in meiner Testumgebung und der mangelhaften Performance derselben begründet. Offenbar hat des das Exchange Setupt gestört, dass sowohl der 2012 DC als auch der 2003x64 mit dem Exchange 2007 drauf beide GC-Server waren. Nachdem der GC nur noch auf dem 2012 DC läuft, lief auch das /preparead von Exchange 2010 sauber durch. Gruß Dirk

:D

Eine :D . Hab ich jetzt was gewonnen? Und die Gruppe 'Exchange Organization Administrators' gibt es auch in dieser OU...

Moin, bin leider gestern nicht mehr dazu gekommen noch zu antworten. Werde jetzt mal Eure Fragen der Reihe nach beantworten. Ja, in der produktiven Umgebung sind noch mehr DC's vorhanden. Diese habe ich aber in meiner Testumgebung aus dem AD entfernt/gelöscht. DNS ist auch sauber. Replikationstests mit REPADMIN funktionieren und DSASTAT zwischen den beiden DC's führt auch zu keinem Fehler. DCDIAG /e wirft auch nur aus, dass der Zeitserver nicht erreicht werden kann. Das ist aber logisch, da es Diesen natürlich in meiner Testumgebung nicht gibt. Die Uhren der Server laufen aber synchron! Setup /Prepare läuft auch auf einen Fehler, was ja auch logisch ist, da PrepareDaomain (PD) ja hier auch ausgeführt wird. Nein, habe ich nicht versucht. Im ExchangeInstallLog ist aber der richtige DC aufgeführt. Sorry, aber wo müssen welche Exchangegruppen im AD liegen? M.W. nach wurde der Exchange 2007 damals neu installiert (2008). Der 2003 DC auf dem der Exchange läuft war dann auch der 1. 2003 Server in der jetzigen Domäne. Ich habe gestern noch mal das vorhanden Schema geprüft. Das AD hat Schemaversion 56, was ja auch richtig ist, da ich 2012 DC's in der Domäne habe. Beim Exchange Schema wird es jetzt etwas strange. Ich habe schlichtweg nicht den entsprechenden Eintrag für Exchange im Schema gefunden! :shock: Gemäß der Vorgehensweise hier: http://blog.dikmenoglu.de/2011/01/die-ad-und-exchange-schemaversion-abfragen/ habe ich per ADSIEdit versucht die Schemaversion von Exchange 2007 auszulesen. Es gibt das Attribut 'rangeUpper' einfach nicht! :suspect: Gruß Dirk

Moin, ich bin gerade dabei eine Testmigration unseres Exchange 2007 auf Exchange 2010 zu machen. Dazu habe ich mir in einem abgetrennten Netz eine virt. Umgebung erstellt. Die folgenden Server wurden aus einer Veeam Sicherung in die virt. Umgebung zurückgesichert. 1. Win 2012 (DC, FSMO, GC, DHCP, DNS) 2. Exchange 2007 auf Windows 2003x64 (DC, GC) 3. virtueller Win7 Client (Office 2010) Die Server in der virt. Umgebung wurden mit aktuellen Windows-Updates versorgt und Exchange 2007SP3 mit dem CU14 versorgt. Anschließend habe ich eine neue 2012VM installiert mit Windows Updates versorgt und in die Domäne aufgenommen. Gemäß der Vorgehensweise hier: http://www.frankysweb.de/installation-exchange-2010-auf-server-2012/ möchte ich den 2012 Server für die Installation von Exchange 2010SP3 vorbereiten. Leider lauf ich dabei auf einen Fehler beim Vorbereiten des AD gelaufen: .\setup.com /preparelegacyexchangepermissions -> fehlerfrei durchgelaufen .\setup.com /ps -> fehlerfrei durchgelaufen .\setup.com /pd bricht mit folgender Fehlermeldung ab: Der folgende Fehler wurde generiert, als "$error.Clear(); if ($RolePrepareAllDomains) { initialize-DomainPermissions -AllDomains:$true -CreateTenantRoot:($RoleIsDatacenter -or $RoleIsPartnerHosted); } elseif ($RoleDomain -ne $null) { initialize-DomainPermissions -Domain $RoleDomain -CreateTenantRoot:($RoleIsDatacenter -or $RoleIsPartnerHosted); } else { initialize-DomainPermissions -CreateTenantRoot:($RoleIsDatacenter -or $RoleIsPartnerHosted); } " ausgeführt wurde: "Die universelle Sicherheitsgruppe (USG) 'Exchange-Organisationsadministratoren' kann nicht über ihre bekannte Sicherheits-ID 29a962c2-91d6-4ab7-9e06-8728f8f842ea gefunden werden. Stellen Sie sicher, dass 'Setup /PrepareAD' ausgeführt wurde.". Setup von Exchange Server wurde nicht abgeschlossen. Weitere Details finden Sie im Protokoll 'ExchangeSetup.log' im Ordner '<SystemDrive>:\ExchangeSetupLogs'. Jemand eine Idee, wo das Problem liegt? Gruß Dirk

Moin, also Lizenzrechtlich ist der Einsatz von SQL Express im Netzt kein Problem. Es gibt diverse Kaufsoftware, die standardmäßig mit SQL Express ausgeliefert wird. Wir haben gerade ein MS Audit durch. SQL Express-Installationen interessiert die Prüfer nicht die Bohne. Ob man das TCP/IP-Protokoll schon während einer Silent-Installation aktivieren kann weiß ich nicht. Gruß Dirk

Moin, zum Umzug Office 365 kann ich nichts beitragen. Warum willst Du den DC outsourcen? Verstehe den von Dir angedachten Vorteil nicht! Bei Deinem geplanten Konstrukt könnte der Fileserver auch noch locker die Rolle des DC übernehmen. Veeam ist eine Backupsoftware! Archivierung und Backup sind verschiedene Dinge! Um Mails dauerhaft zu archivieren gibt es Archivierungslösungen. Je nach Komplexität bzw. Anforderungen geht es bei reinen Archivierungslösungen für Emailserver los (z.B. Mailstore). Das endet dann in komplexen Archivsystemen wie z.B. ELO DMS oder EasyArchiv. Hier werden dann neben den Emails eines Projektes auch andere zugehörige Daten archiviert (z.B. CAD-Zeichnungen, Verträge, Fotos, Wartungsunterlagen, usw.). Die Daten können i.d.R. auch Revisionssicher archiviert werden. Also wie so häufig: Erstmal die genauen Anforderungen definieren. Und Achtung: Es gibt längst noch nicht zu jeder Archivierungslösung eine Anbindung an Office365! Viele Systeme benötigen eine direkte Anbindung an den Exchange-Server.

Moin, also 60 User mit Office 2013 auf einem RDP finde ich schon recht sportlich! Meist Denke ich so ab 30 User über einen 2. RDP Server nach. Über welches Plattensystem verfügt der RDP Server? Wie ist die Anbindung des RDP ans Netzt geregelt. Läuft der gesamte Traffic für den RDP über die UTM (auch intern) oder nur der Traffic der von extern kommt? Gruß Dirk

Doch, das erkennen sicherlich viele hier an (ich sowieso, da ich Veeam hier im Unternehmen eingeführt habe). Aber kannst Du evtl. auch mal anerkennen, dass es hier Leute gibt, die ein Produkt erst im Unternehmensumfeld einsetzten (dürfen), wenn es auch offiziell und explizit vom jeweiligen Hersteller für ein bestimmtes Szenario freigegeben ist. Derzeit gibt es eben noch keine Freigabe für Veeam Endpoint Protection für Serversysteme. Könnte aber sein, dass das mit Veeam 8 Update 2 kommt.

Moin, technisch und lizenzrechtlich ist das grundsätzlich möglich. Ob es sinnvoll ist hängt vom vorhandenen SBS Server (Hardware) und der Belastung bzw. Auslastung der einzelnen Systeme (Exchange, MS-SQL) ab. Ein SBS ist schon ganz schön mit sich selbst beschäftigt und wenn jetzt noch der SQL dazu kommt sollte die HW des Servers schon entsprechend potent sein. Grundsätzlich ist es nicht optimal einen DC, Exchange und einen SQL auf einem Server zu betreiben. Gruß Dirk

Wieso? Ich kenne viele Installationen die den SBS virtuell völlig legal betreiben. Allein schon wegen des leichteren Umzugs auf eine neue Hardware würde ich heute einen SBS bzw. einen Server generell nur noch virtuell betreiben. Konkret geht es hier ja darum einen SBS in einem aktiven HA Cluster einzusetzen. Und das ist nun mal gemäß der MS-Lizenzbedingungen für den SBS ausdrücklich verboten. Ich denke dazu ist jetzt auch Alles gesagt.

Beim SBS2011 fehlt die Lizenzmobilität. D.h. Du darfst den SBS2011 nur auf eine Hardware lizenzieren und betreiben (egal ob Native auf dem Blech installiert oder als VM). Wenn Du die Funktionaltität des SBS im HA-Clusterbetrieb nutzen willst, musst Du die SBS Installation auf die einzelnen Windows-Produkte umstellen (Windows Server, Microsoft Exchange, ggf. MS-SQL). Sprich, Du musst alle Lizenzen neu kaufen und neu installieren! Bei Exchange/MS-SQL gilt dann noch, dass Du für die Lizenzmobilität die SA brauchst. Das mit der Replikation auf den 2. Host ist erstmal kein Problem. Nur dürftest Du halt den SBS nicht auf diesem 2. Server starten! Von daher wäre dann auch die Replikation Unsinn! Das sind aber Spitzfindigkeiten! Nimm es einfach so hin wie es Dir die Lizenzierung vorschreibt. Wenn Du einen höheren Sicherheitslevel durch den HA-Cluster haben willst musst Du eben die Lizenzbedingungen akzeptieren und die entsprechend notwendigen Lizenzen gemäß den Lizenzbedingungen kaufen! Das entscheidende für die Kompatibilität der Hosts sind die CPU's (Generation). Ob nun ein Server von HP, Dell oder IBM ist egal wenn die CPU's aus der gleichen Generation stammen gibt es normalerweise keine Probleme. Bei VMware kannst Du den EVC-Mode der CPU auch herunterstufen um damit eine vorherige CPU-Generation passen zu einem anderen (älteren) Host dargestellt wird. Hier mal eine Übersicht der EVC-Level und den Intel-CPU's: http://www.virten.net/2013/04/intel-cpu-evc-Matrix/

Sorry, aber Dein einziger Nachteil wäre für mich schon ein absolutes NoGo für eine Backuplösung! Dafür wären mir schon 300€ zu viel. Selbst Windows Backup kann m.W. nach FileRecovery aus VM's und ist kostenlos beim Server dabei.

Wo hat Du denn Diese tollen Erkenntnisse her? Schon mal etwas von Vorsatz gehört? Wenn Du eine HA-Umgebung betreibst und darauf wissentlich einen SBS2011 installierst ist dass ein vorsätzlicher Lizenzverstoß. Das ist schon mal etwas anderes, als wenn im Rahmen eines Lizenzaudits festgestellt wird, dass z.B. einige CAL-Lizenzen fehlen! Auch wenn es scheinbar immer wieder Leute gibt, die es nicht wahrhaben wollen: Nicht Alles was technisch möglich ist, ist auch Lizenztechnisch erlaubt. Im übrigen lässt sich per Logging sehr einfach feststellen, ob und wann welcher Server im HA Cluster gelaufen ist und welche Maschinen wann und wo gelaufen sind. Und im Streitfall must Du beweisen/sicherstellen, dass der SBS2011 niemals zwischen den Hosts verschoben wurde!