Horstenberg

Copernic Desktop Search haben wir bis vor einigen Jahren auch in unserem Netzwerk gesucht. Es war in vielerlei Hinsicht unzuverlässig. Wir haben sicher drei Versionen abgewartet, es hat aber nie zufriedenstellend funktioniert. Wir versuchen uns jetzt mit Lookeen in der Enterprise-Version. Das Zuschneiden auf unser System erweist sich als aufwändig. Es funktioniert bei uns aber besser als Copernic.

Danke für Deinen sehr kenntnisreichen und wirklich sehr hilfreichen Beitrag. Zwei Fragen: Hast Du denn auch schon PCIe-NVMes in einen Storage Pool eingebunden? Und wenn Du ohne HW-RAID-Controller arbeitest, aber das OS immer auf einen RAID legst, hast Du dann das Betriebssystem in einen Raid-1 auf dem Motherboard-Raid-Controller gelegt? Auf SATA-SSDs? In den Storage Pool geht das ja wohl nicht. Nochmals danke für Deinen Beitrag! Derzeit hat HP professionelle, lüfterlose Switches im Angebot. Die haben aber keinen 10-GBit oder SFP+-Port. Alles, was 10GBit hat, hat nach meiner Kenntnis Lüfter. Das ist leider der Killer, wenn der Switch in unmittelbarer Nähe von Arbeitsplätzen steht (da manche Switches ja wirklich an Flugzeuge erinnern). Ich befürchte, der Artikel befasst sich mit Storage Spaces Direct und nicht mit Storage Pools. Aber, wie gesagt: Die Terminologie ist nicht wirklich einheitlich.

Dass sind für mich unerreichbare Datendurchsatzraten. Ich brauche im wesentlichen lüfterlose und Silent-Konzepte, weil wir keinen separaten Serverraum haben. Ich hätte schon längst eine 10-GBit-Anbindung der Server, wenn es lüfterlose Switche mit entsprechender Leistung gibt. Ist übrigens bei vielen Settings in kleineren Unternehmen ein Thema und spricht bei der Server-Hardware für einen kompletten Abschied von Festplatten (Lautstärke, Lüfter).

Habe ich mir auch überlegt. Ich dachte, dass in der Praxis vielleicht schon viele solcher Lösungen im Einsatz sind... Nachdem ich mich in den letzten Monaten viele Stunden mit Storage-Lösungen in KMU-Settings befasst habe, denke ich eigentlich, dass die Zeit der RAID-Controller mit Festplatten oder SSDs vorbei ist. Ich halte Ansätze wie den vroc-Ansatz von Intel (virtual raid on a chip) oder auch neue Schnittstellen wie Oculink und NVMe für deutlich überlegen, weil sie alte Flaschenhälse abschaffen und ganz neue Geschwindigkeiten ermöglichen. Natürlich ist das im heute noch üblichen 1-GBit-Netzwerk völlig überdimensioniert. Aber auch wenn Moore's Law nicht mehr gilt, ist auch sicher: Der Zahn der Zeit nagt an "alten" Raid-Lösungen. Da muss ich mir jetzt nicht mehr eine solche zulegen. --- Das muss aber natürlich jeder für sich selbst wissen, da habt Ihr Recht.

Danke für die Hinweise. So weitgehende Hinweise hatte ich aber auch gar nicht erwartet. Wenn man einen Server für die nächsten Jahre kauft, muss den jeder für sich selbst konzipieren. Die letzten Server habe ich in 2012 gekauft und die waren auch teils überdimensioniert und nicht passend für das Konzept, dafür halten sie auch heute noch gut deutlich anspruchsvollere Software aus. Meine eigentliche Frage (Storage Pools und PCIe-NVMe-SSD) scheint allerdings nicht zu beantworten zu sein. Also unterstelle ich mal, dass es leider nicht geht. Jedenfalls habe ich nirgends im Internet gefunden, dass das Microsoft-Doc an dieser Stelle falsch ist und Herrn Joos kann man wohl nicht uneingeschränkt vertrauen.

Das Host OS lege ich auf eine M.2-NVMe-SSD, weil es praktisch ist (onboard M.2-Slot). Die M.2 kostet ja auch nicht die Welt (120 Euro oder so). Zum RAID-Controller: Die Frage ist eher, warum ich heute noch einen brauche? Mit Cache und allen Software-Options kostet der schnell EUR 1.200 extra. Warum dann nicht auf superschnelle PCIe-NVMe-Karten gehen. Wenn, ja wenn man bei diesen eine gewisse Ausfallsicherheit schaffen kann, etwa durch Storage Pools... Derzeit laufen die Server als Hyper-V-Maschinen auf fast neun Jahre alten XEONs. Prozessorauslastung meist so um die null Prozent, außer beim Exchange 2019, der läuft aber "nur" mit 64 GB. Die Prozessorauslastung ist da meist auch unter 10%. Derzeit habe ich aber noch keinen TerminalServer. Auf dem TerminalServer soll voraussichtlich MS Office laufen (wenn ich das lizenztechnisch gelöst habe) und (wenig anspruchsvolle) Spezialsoftware. Es gibt aber eine größere Datenbank, auf die wir zugreifen (leider homemade beim Spezialsoftwaremann, aber das ist hier nicht das Thema).

Ich lasse mir (voraussichtlich bei Thomas Krenn) einen neuen Server zusammenbauen, mit 2x Intel Silver 4208 Prozessoren, 256 GB RAM. Auf dem Server laufen unter Hyper-V einige virtuelle Maschinen (alle Server 2016/19 und Windows 10): - Insgesamt 9 Mal Server 2016/19: DC, Printserver, Exchange 2019, Mailstore, RDP, Web Application Proxy, ADFS, Work Folders, Fileserver. - Dazu 4 - 10 Windows 10 Clients. Bislang hatten alle Server bei mir Hardware-Raid. Die Raidkarte ist aber ein Single-Point-of-Failure und mir auch schon kaputt gegangen. SSD-Ausfälle hatte ich bis heute genau Null (bei jahrelangem, permanenten Office-Einsatz von zahlreichen SSDs). Hinzu kommt, dass Raid-Controller wie Megaraid eine NVMe-SSD eher verlangsamen als beschleunigen. Daher meine Überlegung: Weg von Hardware-Raid-Controllern. Den Server kaufe ich bei Thomas-Krenn mit höchstem Support-Level (Same Day). Dann muss ich mich aber - jenseits der 2xtäglichen Backups um Datenausfall kümmern. Ergebnis zum Storage: - Betriebssystem (Hyper-V-Server) geht auf eine interne M2-NVMe-SSD auf dem Mainboard. - Drei 3,2TB-Samsung PCIe-NVMe-SSD binde ich als Storage-Pool zu einem RAID5 zusammen (= Parity), für die systemkritischen Hyper-V-Server. - Weiterhin eine separate SATA-SSD (ohne RAID) 1,92 TB für die nicht systemkritischen Server/Clients. Klingt für mich wie ein guter Plan. Wenn ich allerdings die 3,2TB Samsung PCIe-NVMe-SSDs nicht als Parity-Storage-Pool zusammenbinden kann, ist der Plan schon nicht mehr so toll.

Ich möchte in Windows Server 2019 Standard mehrere NVMe-SSDs, die über PCI-Express am Motherboard hängen, über Storagepools (dt. wohl "Speicherpools") zusammenbinden. Die Terminologie dazu im Internet ist nie einheitlich, da Storagepools wohl oft mit Storage Spaces Direct verwechselt wird. Im Ergebnis möchte ich Storagepools als Software-Raid einsetzen (RAID-1 oder RAID-5-Ersatz), mit dem ich direkt angeschlossenen Speicher (DAS) bündele. In diesem Link von Microsoft werden verschiedene Schnittstellen für Festplatten und SSDs genannt, mit denen Speicherpools möglichst sind. NVMe über PCI-E wird dort aber nicht als zulässiger Datenträgerbustyp genannt: https://docs.microsoft.com/de-de/windows-server/storage/storage-spaces/deploy-standalone-storage-spaces Im Buch zu Thomas Joos zu Windows Server 2019 liest man dann aber, dass "leistungsstarke NVMe-Datenträger integriert werden" können. Also was denn nu? Ich möchte mir nicht einen Server mit teuren PCIe-NVMe zusammenstellen und dann kann ich diese nicht in einen Speicherpool einbinden.

Es gibt jedenfalls Gründe, von Exchange 2013 auf Exchange 2019 zu wechseln: Exchange 2013 läuft zwar derzeit super-stabil auch mit den neuesten Outlook-Versionen, aber der Lifecycle ist drei Jahre kürzer. Der zweite ist der Einfluss des Exchange auf das Gesamt-System. So wird nach der Support-Matrix ein Windows-Server-2019 Domain-Controller nur von Exchange 2019 und ab Exchange 2016CU7+x supported. Wer also einen 2019er-DC haben will und einen Exchange 2013 hat, muss umsteigen. Da die Preise für Exchange 2019 nicht mehr deutlich über Exchange 2016 liegen, kann man dann direkt auf 2019 gehen. Im Handling ist Exchange 2019 auch nicht so viel anders als 2013. Die eigentlichen Änderungen gab es imho zwischen Exchange 2010 und 2013.

Derzeit sehe ich den auch nicht, wegen des verringerten Supportzeitraums bei Exchange 2019. Aber mal sehen, ob Exchange 2016 auch mit Outlook 2022 oder Outlook 2025 zusammenarbeiten wird.

Hat jemand hier zwischenzeitlich Erfahrungen mit Exchange 2019 in kleineren Umgebungen mit weniger als dem empfohlenen Speicher gesammelt? Ein virtualisierter Exchange 2019 mit 64 GB für 30-40 Postfächer. Aushaltbar?

Was sagt die Remotedesktop-Lizenzierungsdiagnose? Selbst wenn der Lizenzserver scheinbar überall richtig registriert ist, muss man dies noch in den Einstellungen des RD-Servers vornehmen. Hierzu etwa folgender Link: https://social.technet.microsoft.com/Forums/de-DE/0a044565-4585-4b43-80cc-d6f08077d082/remote-desktop-server-terminal-server-lizensierung?forum=windowsserver8de Ist nirgendwo dokumentiert, ich musste dies aber schon mehrfach so machen, zuletzt sogar unter Windows Server 2019.

Nach sechs Jahren ist es jetzt tatsächlich preiswerter, insbesondere, wenn es jetzt noch ein paar Jahre läuft. Das war aber nicht mein Ziel. Ich beschäftige mich halt gerne mit Computern, mit der Hardware, der Software und der Programmierung, so als Hobby. Da ist eine Bastlerlösung halt interessanter. Manche haben zu schnelle Autos; das brauche ich glücklicherweise nicht.

Mir geht es um den erweiterten (extended) Support. Windows Server 2019 hat extended Support bis Januar 2029. Scheint mir ein guter Deal zu sein. Exchange 2019 hat extended Support nur bis Oktober 2025. Gegenüber Exchange 2013 (extended Support bis April 2023) gewinne ich damit also nicht viel. Deswegen warte ich auf Exchange 20XX, es sei denn, die auch nicht mehr ganz zuverlässige Exchange/Outlook Support-Matrix ändert sich (was etwa sein kann, wenn Exchange 2013 nicht mehr mit Outlook 365 zusammenarbeitet). Mir wurde 2010 über ein Systemhaus ein Server von Tarox verkauft. Wenn ich mich recht entsinne (ist lange her und ich will auch niemandem Unrecht tun!), war dann 2013 eine Verlängerung des Server-Supports nicht mehr möglich, den Grund dafür weiß ich nicht mehr. Das führte bei mir zu Zorn (?!) und dem Entschluss, mich davon nicht mehr abhängig zu machen. Daher entwickelte ich die Strategie "kaufe überdimensionierte Hardware, das auch noch zwei Mal, habe weitere Ersatzteile bei Dir und spare Dir den Support". Das ist zum Nachmachen natürlich nicht empfohlen, aber es funktioniert bei mir bestens. Ein Problem kann ich eigentlich nur bekommen, wenn beide Motherboards gleichzeitig abrauchen. Für die Festplatten, Raid-Controller, Netzteile usw. habe ich Ersatz vor Ort (den ich selbst einbauen kann). Nach sechs Jahren hat sich die Investition übrigens mehr als gelohnt. Bis auf Ram-Erweiterungen und ab-und-an Festplatten-Defekte war sechs Jahre nichts. Ist aber als Bastellösung nur Leuten zu empfehlen, die gerne an Computern schrauben (wie mich).

In 2010 habe ich Server gekauft mit 3 Jahren Support. Naiv wie ich war, wollte ich den 2013 verlängern, was natürlich verweigert wurde. Darüber habe ich mich geärgert, deswegen habe ich in 2013 meine eigene Lösung geschaffen: Zwei Mal die exakt (nahezu) exakt gleiche Hardware, komplett überdimensioniert, die aufeinander repliziert, so dass ich notfalls mit einem Server weitermache, wenn der andere abraucht. Hat mir gute Dienste geleistet. Eigentlich war für 2019 neue Hardware geplant, zusammen mit einem neuen Exchange. Bei 2019 hat mich aber der verkürzte Lifecycle enttäuscht, so dass ich jetzt auf Exchange 2022 warte (so es diesen geben wird) und die für diesen geltenden Hardware-Anforderungen. Die beiden Server aus 2013 laufen weiter brav, Ersatz-Festplatten habe ich zur Genüge bei mir liegen. Läuft also alles. Backups habe ich zur Genüge. Es bleibt also va das Risiko, dass beide Server innerhalb kurzer Zeit mit Hardware-Defekt abrauchen, ohne dass ich zwischenzeitlich Ersatz bekomme. Damit kann ich leben. P.S. Dass das jetzt alles OT ist, ist für mich völlig in Ordnung. Meine Ursprungsfragen hat man mir ja vollständig beantwortet.

Eine Lösung wie die Hyper-V-Replication von Exchange wird Microsoft wohl schon deshalb nicht supporten, weil es für Microsoft total uninteressant ist. Interessant ist das nur für kleinere Umgebungen, die Microsoft ohnehin in die Cloud schieben möchte. Größere Umgebungen sollen das über DAG lösen, was ja sicherlich auch besser ist als Hyper-V-Replication. Jede kleinere Umgebung, die alles On-Premises lösen will, muss gucken, zu welchen Kompromissen man bereit ist. Da kann es manchmal erwägenswert sein, auch einen Weg zu gehen, bei dem es keinen Support von MS gibt. Übrigens an alle ein herzliches Dankeschön für die Beiträge hier! Die Hyper-V-Server habe ich jetzt auf Windows Server 2019 umgestellt, da die Lizenzen ohnehin da waren. Ich hatte etwas Bedenken, WS 2019 auf recht betagter Hardware zu installieren (sechs Jahre alt). Gefühlt war die Installation von WS 2019 aber sehr unproblematisch und problemloser als die vieler anderer früherer WS-Versionen. Und die Updates laufen plötzlich ziemlich schnell.

ok und Danke für die Info. In irgendeinem Blog hatte ich mal gelesen, dass das mit der Replikation von Exchange in Hyper-V klappen kann, seit es Production-Checkpoints gibt. Zur Nachahmung war es aber sowieso nicht empfohlen.

In den meisten Fällen dürftest Du damit Recht haben. Das Ausfallen eines physischen Hosts wäre bei uns dadurch zu kompensieren, dass im Wesentlichen nur die VMs, die für den Remotezugriff "zuständig" sind, ausgeschaltet bleiben. Das ist bei uns nicht systemkritisch und hat nur für wenige User Folgen. Das könnten wir tatsächlich verschmerzen.

Stimmt, das ist keine Hochverfügbarkeit. Es ist aber eine gute Fallback-Option, mit der ich seit Jahren gute Erfahrungen mache. Stimmt. Da man für die Replikation ohnehin doppelte Lizenzen braucht, habe ich auf jedem Host einen DC (mit AD und DNS), die ohnehin aufeinander replizieren. Zum Exchange habe ich backups und eine separate Maschine mit Mailstore. (Stimmt, ist jetzt aber echt OT). Übrigens: Für Exchange ist Hyper-V-Replication nicht "unzulässig", es ist "nicht supportet". Das heißt nicht, dass es nicht funktioniert (und technisch müsste es es funktionieren, jedenfalls, seit Production-Checkpoints repliziert werden, das habe ich aber noch nicht probiert. Windows-Server-Backup sichert den Exchange auch nicht anders, und das funktioniert nun nachweislich gut.).

Die beiden physischen Hosts sind hardwaretechnisch fast identisch. Ausfallsicherheit besteht durch Hyper-V-Replication, mit der die wichtigsten Server-VMs jeweils auf den anderen Host repliziert werden. Wenn ein physischer Host ausfällt, müssten ein paar VMs "ausgeschaltet" werden, die zentralen Dingen laufen dann aber dann auf dem verbleibenden Host weiter (DC, AD, Printserver, Exchange, Fileserver). Klappt bislang alles so ganz gut, immerhin seit ca. 6 Jahren ohne größere Probleme. Ist mehr so Hochverfügbarkeit und Clustern für Arme, angesichts der geringen Größe des Netzwerks aber akzeptabel.

Entschuldige, so war das nicht gemeint. ;)

Vielleicht ist das aus Deiner Sicht kein Problem. Es dauert aber stundenlang. Das nervt, deswegen habe ich hier einmal in die Runde gefragt. Mit WS 2019 ist das Ganze vielleicht in 30 Minuten erledigt. Das ist dann ein Vorteil. Darum geht es mir, ob ein Upgrade der Hosts sinnvoll ist. Jetzt einen dritten Host anzuschaffen, wäre angesichts der Größe unseres Netzwerks übertrieben (und ist hier auch ziemlich OT).

Das mag sein. Mir geht es hier um das Update-Verhalten von WS 2016.

Wir haben zwei Hyper-V-Hosts, die sind sozusagen das Rückgrat der gesamten IT. Die würde ich nur ungern unbeaufsichtigt nachts updaten und neustarten.

Hallo an alle, das Update-Verhalten von Windows Server 2016 erlebe ich als fast schon unerträglich. Allein der Download der monatlichen Updates dauert (nach Anzeige) über eine halbe Stunde, dazu kommen (gefühlt) ewige Installations- und Neustartzeiten. Das Thema ist auch schon an einigen Stellen thematisiert worden, zB https://social.technet.microsoft.com/Forums/en-US/7b412a7a-3377-46f7-95f8-cd42d24451a0/windows-server-2016-updates-slow?forum=ws2016 https://social.technet.microsoft.com/Forums/en-US/250914a1-b013-434a-baa0-639e31a839dd/whats-with-the-really-slow-windows-updates-on-2016?forum=ws2016 https://www.heise.de/newsticker/meldung/Windows-Server-2016-Update-Installation-braucht-Geduld-4316646.html Hinzu kommt bei mir noch das folgende Phänomen: Wenn das quälend langsame monatliche Update eingespielt ist (im Juli etwa KB4507460), dann fordert WS 2016 direkt noch einmal die Installation weiterer Updates (im Juli etwa (KB4507459). Fast jeden Monat das gleiche. Resultat ist wieder die gleiche, ewig lange Prozedur. Das nervt extrem. Weiß jemand, - ob es hierzu bald von Microsoft eine Lösung gibt? - ob ich etwas falsch mache? - ob insbesondere der doppelte Update-Aufwand durch zwei Kumulative Updates im Monat vermeidbar ist? Nerven tut dies natürlich insbesondere auf den Hyper-V-hosts. Hat jemand Erfahrung mit WS 2019 als Hyper-V-Host? Ist es dort besser? Danke für jede Hilfe! -- Gruß, Horstenberg