Doso

Die komplett freie Version vom ESXi hatte sowas mal vor einigen Jahren, ich glaube das Limit war da irgendwo bei 32 GB oder sowas. Vielleicht kommt die Vermutung daher.

Vielleicht schaust du dir erst mal die Dokumentation dazu an, da steht nämlich GENAU das drin.

Der Host reserviert sich Speicher, wenn es ihm zu wenig ist kannst du VMs nicht mehr starten. Die genauen Werte diesbezgl. findest du in der Microsoft Doku oder Suchmaschine der Wahl.

Wir brauchen die System Center Lizenzen für SCCM und DPM (Backups) sowieso, da gibt es den VMM zusätzlich dazu dann kann man den schon mal nutzen. Aber ja, nur für ein paar Hosts alleine lohnt sich der VMM sicherlich nicht.

Wir haben einen Exchange 2016 Server CU6 und verwenden ein aktuelles Outlook 2016. Einige wenige Nutzer haben manchmal Verbindungsprobleme mit ihrem Outlook. Ich konnte das jetzt nachstellen: - Nutzer hat Outlook offen - Nutzer klappt Laptop zu -> Laptop geht in den Schlafmodus - Nutzer macht Laptop wieder auf Wenn der Nutzer das 2-3x macht zeigt Outlook einen Verbindungsfehler. Der Verbindungsfehler ist nur bei Outlook, Webmail geht. Der Verbindungsfehler ist dann auch unabhängig vom Rechner oder Betriebssystem. Er scheint also allgemein an der Mailbox des Nutzers zu hängen Wenn der Nutzer Verbindungsprobleme hat, lasse ich den Outlook Verbindungstest laufen: https://testconnectivity.microsoft.com Er wirft mir einen MAPI Fehler: Testing the MAPI Mail Store endpoint on the Exchange server. An error occurred while testing the Mail Store. .... Attempting to log on to the Mailbox. An error occurred while logging on to the Mailbox. The mailbox logon failed with unknown error 2614. StatusCode: 2614 Ich vermute daher das Outlook durch den Energiesparmodus irgendwelche Verbindungen nicht trennt und dann neue aufmacht und man dann in irgendein Verbindungslimit auf dem Exchange Server rein läuft. Wenn ich in den Verbinungsstatus von Outlook reinschaue sehe ich das teilweise auch nicht alle zusätzlichen Postfächer verbunden werden. Leider finde ich in den Logfiles vom Exchange Server auf Anhieb nichts, muss aber gestehen das ich auch nicht genau weiß wo ich jetzt suchen sollte. Von Exchange 2010 kenne ich Nutzer die teilweise Verbindungsprobleme hatten da sie viel zu viele Ordner in freigegebenen Postfächern hatten. Man konnte hier dann das Limit höher schrauben. Diese Fehler konnte ich aber leicht finden da sie in der Ereignisanzeige leicht zu sehen waren. Hat hier jemand eine Idee wo man hier nachschauen könnte bzw. was man dagegen machen kann?

Hyper-V Cluster sichert den Ausfall des Hosts (z.B. der Hardware) aber nicht unbedingt der Anwendung/des Dienstes. Dafür braucht es dann weitere Hochverfügbarkeitslösungen. Wie das geht hängt sehr von der Anwendung ab. Evtl. geht es auch gar nicht. Beispiel: Windows DHCP Server ab 2012 hat eine eigene Hochverfügbarkeitslösung eingebaut, genau wie Exchange Server. SQL Server gibt es mehrere Lösungen, eine davon ist Windows Failover Cluster. Für Web Anwendungen braucht es dann oft einen Load Balancer und eigene Sachen für die Datenbanken. Oder ums kurz zu machen: Kann kompliziert und verdammt teuer werden. Und wie immer: Es kommt drauf an.

Für die meisten Sachen der Doku ist oft Microsoft Visio Mittel der Wahl wenn man etwas visualisieren will.

Schau mal ob du über Powershell weiter kommst. Wir hatten auch mal den Fall das der Snapshot in der GUI nicht angezeigt wurde, aber per Powershell konnt ich es dann mit -force Parametern oder sowas zusammenführen.

Man kann eine Live Migration auch machen wenn die VM aus ist wenn man nicht mit den CPU Einstellungen rumspielen will. Wenn man die Downtime verkraften kann. Das erinnert mich an die Zeiten wo wir noch Windows Server 2008R2 hatten und das alles offline "per Hand" machen musste. Brrr... gut das das vorbei ist =)

Welche Exchange/Outlook Version habt ihr? Wir hatten das bei Exchange 2010/Outlook 2010 auch immer weider mal. In Exchange 2016/Outlook 2016 noch nie. Man kann das Caching übrigens auch nur für die zusätzlichen Postfächer abschalten. Das war unser Workaround für das Problem.

Hyper-V/SCVMM löst das recht smart. Man kann VMs zu Gruppen zusammenfassen die, soweit möglich, NICHT auf dem gleichen Host laufen sollen. z.B. eben Domain Controller. Das wird bei so Optimierungssagen, Cluster Aware Updating berücksichtigt.

Hyper-V kann sowas in der Richtung mit SCVMM - Dynamische Optimierung. Das greift halt bei gewissen Schwellenwerten und macht ein Live Migration. z.B. 80% RAM Auslastung auf einem Node, mehr Platz auf einem anderen Node -> es wird verschoben. Das wird zu konfigurierbaren Intervallen gemacht z.B. alle Stunde einmal. Bei uns läuft das alle 6 Stunden, das reicht locker. Wir nutzen das weniger zum Lastenausgleich als mehr zum gleichmäßigen Verteilen der VMs nach Windows Updates der Hosts. Irgendwie hat das Cluster Aware Update bei uns Probleme gemacht also patchen wir per Zeitfenster und SCCM und am Ende hat dann ein Host viele VMs und einige gar keine. In Hyper-V 2016 Clustern gibt es das so ähnlich, Node Fairness: https://www.altaro.com/hyper-v/node-fairness-hyper-v-2016/ Damit habe ich aber bisher keine Erfahrung.

Bei kb4038782 würde ich mir keine Sorgen machen. Das Update hat allgemein seine Probleme...

Wir planen den Einsatz von nicht-LTSB Windows 10 Enterprise, ca. eine Windows 10 Upgrade Version hinterher und cumulative updates ca. 2 Wochen hinterher. Neue Windows 10 Upgrades und CUs haben recht häufig irgendein Probleme gehabt in der Testphase bisher. Die Ausrede "Microsoft hat Schuld" des Software Herstellers gilt nicht. Windows 1703 ist 6 Monate raus, dafür gab es eine längere Preview Phase. Wenn sie nun behaupten ihre Software kann mit Windows 10 umgehen und es gibt Probleme ist das nicht die Schuld von Microsoft.

Habt ihr den Rechner von dem aus ihr zugreift aktuell gepatcht? Inkl. RSAT Tools? Die RSAT Tools unter Windows 10 waren anfangs nicht so geil, es gibt da mittlerweile aber Version 1.2 die sind stabil.

Bei E-Mails habt ihr eine ordentliche betriebliche Regelung der E-Mail Accounts bezgl. privater E-Mail? Wenn unklar oder nein (Duldung) dann können da private E-Mails drüber laufen und ihr dürft da vom Datenschutz her keine Rechte vergeben oder Mails weiterleiten. "Einsteigen und Mails weiterleiten" und Windows Passwort zurücksetzen um es dem Kollegen zu geben ist nicht nur Grauzone, da könnte es schon ggf. kriminell werden. Ich argumentiere da immer mit Datenschutz, verweise darauf das wir da wohl den Betriebsrat hinzuziehen müssen und plötzlich ist das alles gar nicht mehr so wichtig. Würde ich nie einfach so machen! Die Lösung ist nur: Nicht für die Mitarbeiter "mitarbeiten". Keine Funktionskennungen mehr, reine Shared Mailbox und hart bleiben und mit dem Datenschutz argumentieren. Ja, das ist ggf. ein harter Kampf, ich weiß. Ansonsten kann der Kollege die Abwesenheitsnotiz auch über Webmail selbst einrichten.

Hast du die VMs einmal neu gestartet, wie es der Installer es verlangt hat? Ansonsten hatten wir keinerlei Probleme damit.

NIC Teaming hat auch den angenehmen Effekt der erhöhten Ausfallsicherheit. Geht mal eine Netzwerkkarte kaputt oder zieht einer versehentlich am Server ein Kabel läuft es weiter. In der Praxis werdet ihr das aber kaum merken. Wir haben es auf unseren Hyper-V Servern an da es hier teilweise positive Effekte hat wenn man einen Host per Live Migration leer macht, aber auch hier merkt man sonst kaum was davon. Edit: Übrigens gibt es glaube ich keinen Upgrade Pfad direkt von Windows Server 2003 auf Windows Server 2016 bei Domänen Controllern. Da wird es einen Zwischenschritt brauchen.

Voll gepatcht habt ihr, ja? Eine aktuelle Windows 10 Version habt ihr?

Ich wollte nur darauf hinweisen das eine Anforderung wie "kann gar nicht down sein" nicht mit 24 Stunden Servicevertrag und nur einem physischen Server problematisch sein könnte.

Nein. Unser Netzwerkexperte ist im Urlaub und die Betreiber des Mailrelay konnten das direkt umsetzen. Hätte ansonsten noch einige Wochen dauern können.

24 Stunden Service bedeutet hier höchstwahrscheinlich 24 Stunden *REAKTIONSZEIT*. Das reicht schon wenn sie ein Ticket erstellt haben. Das bedeutet NICHT das der Server in 24 Stunden wieder läuft. Wenn man so hohe Anforderungen an die Verfügbarkeit hat muss man entsprechend auch Geld dafür in die Hand nehmen und nicht alles auf einen kleinen Server mit Essentials installieren. Hochverfügbarkeit kostet leider meist richtig viel Geld.

Wir haben entsprechend dieser Anleitung einen neuen Empfangsconnector auf Port 2626 angelegt und die Standard Exchange Empfängerprüfung aus dem Antispam Filter verwendet: https://www.heinlein-support.de/blog/mailserver/exchange-2013-dynamische-empfaengerpruefung-fuer-postfix/ Danach Port 2626 auf den Firewalls für die vorgeschalteten Mailrelays erlaubt. Der Betreiber der Mailrelays liefert E-Mails bei uns nun statisch auf dem Port 2626 ein. Damit kommen jetzt auch die ach so wichtigen E-Mails aus Mailinglisten wieder durch, wenn ein Empfänger unbekannt ist. Halleluja! Danke nochmal für eure Unterstützung.

https://support.microsoft.com/de-de/help/3097392/outlook-logon-fails-after-mailbox-moves-from-exchange-2010-to-exchange

Bei uns schaut das so aus: Failover Clustername: cluster.xyz.de SQL Cluster Standardinstanz: sqlcluster SQL Instanz Intranet: SQLIntranet\SQLIntranet SQL Instanz Test: SQLTEST\SQLTEST Ja, das schreibt man wirklich so.... -_- Die kurze Schreibweise ist dann nur bei der Standardinstanz möglich. Wobei die dann eigentlich SQLCLUSTER\. heissen könnte. Auf den Server die denn SQL Server nutzten kannst du ggf. mit SQL Aliasen arbeiten: https://tblankertz.wordpress.com/2011/10/13/einrichten-eines-sql-alias-unter-sql-server-2008-r2/ Da kann dann durchaus ein "AlterSQLServername" auf "SQLBlah\SQLBlah" zeigen ohne das du an der Anwendung rumschraubst.