Beiträge von Jack

    Hi,


    ich habe dazu noch ein paar Fragen;


    1. bekommst du den Fehler wenn du den Befehl PowerShell.exe -PSConsoleFile "Path\ExShell.Psc1" -Command ". '<Path\MyScript>'" direct auf den Server ausführst oder remote?
    2. sind Server A & Server B beide Exchange Server?
    3. Welches OS?
    4. Tritt der Fehler bei jedem Script auf?


    Gruß,
    Jack

    Nach eine Woche und einen CritSit sieht es so aus, als liegt das Problem in der Umgang von Exchange 2016 mit der NUMA Architektur.


    Nachdem wir im BIOS unserer Server die Einstellung "NUMA Group Size Optimisation" auf "Flat" geändert haben ist der Performance sehr viel besser.
    Nach Aussage von MS Support, kommt .NET unter Umständen nicht mit mit mehreren KGroups zu recht. Das haben wir gefunden nachdem [system.environment]::processorcount in Powershell nur 10 CPU Cores gezeigt hat, wir aber 20 Cores in den Servern haben.
    Das hat dann dazu geleitet, das der Threadverwaltung durch einander gekommen ist.
    Übrigens ist der Einstellung im BIOS erst seit dem letzten BIOS Update vorhanden :)

    Moin Forumfreunde,


    ich streue hiermit mal meine Erfahrungen mit Exchange 2016 in unserem Unternehmen (ca. 11000 Mailboxen) und die Probleme die wir im Moment haben.


    In Januar 2017 haben wir mit der Migration von Exchange 2010 nach Exchange 2016 angefangen. Wir haben den Microsoft Service "Onboarding Accellerator" für Exchange 2016 in Anspruch genommen und hatten 3 Wochen lang einen PFE vor-Ort welche unsere Umgebung analysiert, unsere neue Hardware auf Tauchlichkeit untersucht und uns bei der Installation der Exchange 2016 Server begleitet hat.


    Nach Phase I, die Analyse von unsere Exchange 2010 Umgebung haben wir uns 8 Server bestellt (HP Apollo). Die wurden dann mit Jetstress geprüft und von MS als "sehr gut" abgesegnet. Ziel war es die 11.000 Mailboxen über die 8 Server und 48 Datenbanken zu verteilen und ausreichend Reserve für 40% zuwachs bereit zu halten für die nächste 3-5 Jahr. Als Loadbalancer war einen neue F5 vorgesehen.


    Die Migration der ersten, ca 3500 Mailboxen verlief problemlos. Erst nachdem wir ca. 8500 Mailboxen auf Exchange 2016 migriert hatten, begannen die erste Anwender sich über die Geschwindigkeit von Outlook zu beschweren. Uns wurde relativ klar, dass die Probleme nur sichbar waren wenn Outlook in "Online-Mode" betrieben wurde, was bei uns für ca 1600 "Shared Mailboxen" der fall ist.
    Darüberhinaus merkten wir, das die Probleme später in der Mittag verschwunden; dann fahren viele Anwender ihren Rechner herunter und gehen nach hause. Auf der F5 konnten wir gut verfolgen, wie die Anzahl an Connections abnahm und ab eine Bestimmte Anzahl an Verbindungen (ca. 1700 pro Server) waren die Probleme Weg.


    Nachdem Microsoft Premier Support uns nicht weiterhelfen konnte haben wir entschieden zusätzlichen Server zu installieren. Das leitete dazu das Outlook schneller reagierte, nie aber das Niveau von Exchange 2010 erreichte. Mittlerweile haben wir zusäzlich zu den 8 HP Server 12 Virtuellen Server die als quasi CAS Server laufen also nur Clientverbindungen entgegen nehmen, selbst aber keine Postfächer 'hosten'.


    Nach gut 3 Wochen bekamen wir dann die Aussage von Microsoft Support, dass wir tatsächlich nicht die Einzigen mit diesem Problem sind und das die Ursache wol im MAPI/HTTP Protokoll liegt. Bei MAPI/HTTP wird bei jedem Aktion in Outlook ein HTTP Get-Request abgesetzt. Läuft Outlook in Cached Mode, dann gegen der OST, sonst aber direct gegen der Loadbalancer und damit einer der Exchange Server, welcher u.U. den Request wieder weitergeben muss an dem Server wo der Aktive Datenbank mit dem Postfach worauf zugegriffen wird liegt.
    Empfehlung von Microsoft war, diese Postfächer über "set-casmailbox "id" -mapihttpenabled $false auf RPC/HTTP umzustellen.


    Also, wir daran unsere 1600 in Online Mode laufenden Postfächer zu identifizieren und umzustellen.


    Nun bin ich mit meiner Geschichte in der KW22 gelandet, also letzte Woche. Immer mehr Anwender, vor allem die im Ausland beschweren sich, dass Outlook sehr lange braucht zum starten. Ein Englischer Mitarbeiter teilte mir dann mit, das dieses Phenomän erst auftritt, nachdem einige Updates installiert wurden. Es dauerte dann nicht lange bevor wir das April Security Update für Outlook 2010 (KB3118388) gefunden hatten. Update deinstalliert, Outlook startet wieder schneller. Update wieder installiert, Outlook wieder langsam.
    Während dem Arbeiten aber konnten wir keinen Unterschied merken zwischen MAPI/HTTP und RPC/HTTP. Da auch ohne KB3118388 die Performance in den Online-mode Postfächer schlechter war als vor 3 Wochen haben wir heute alle wieder auf MAPI/HTTP umgestellt und hoffen, dass die Anwender am Montag wieder besser arbeiten können (das Rollback von KB3118388 kriegen die Kollegen der SCCM Truppe wohl nicht so schnell hin).


    Mir würde jetzt mal brennend interessieren, ob ihr die gleiche Erfahrungen mit Exchange 2016 habt. Auch über neue Lösungsansätze würde ich mich sehr freuen. Wir überlegen uns jetzt schon die Postfächer über mehrere DAGs zu verteilen und mit mehrere Namespaces zu arbeiten damit wir die Last auf den Servern besser steuern können.


    Viele Grüße,
    Jack

    Hi Pirat,


    ich denke, dass Problem ist, dass die notwendige VEEAM binaries auf Server 2 vorhanden sein müssen, auch beim Remoting.
    Du arbeitest ja remote auf Server 2.


    Gruß,
    Jack