Seit Exchange Server2016 CU11 Update kein Clientzugriff mehr möglich.

[Ralf2019 0]

Client: Outlook 2016 auf Windows 10 (vorletzte Version, alle Patches) "AppX, Modern App aus dem Microsoft Store, neuste Version: verbindung: getrennt.
Es lässt sich kein neuer Client einrichten (IMAP wird angeboten, danach Outlook 365, auch mal per Registry Block lokal deaktiviert)

Clientseitig: diverseste Dinge probiert RPC Aktivierung (Registry, mapiOverHTTP Deaktivierung etc.)

Das CU11 Update lief erfolgreich durch (gängige Regeln beachtet Virenscanner aus, Serverneustart alle Serverfixes etc.) auch beim Start nix zu bemängeln und keine Infos,
danach ging aber "nix" mehr ...

 

Der Server konnte mit CU11 Setup /recovery und Installation des neusten Net SDKs (4.7.2)  wieder zum laufen gebracht werden. (Rücknahme des Updates schlug fehl, keine direkte Fehlermeldung nur kryptische Assembly Meldungen)
ECP und OWA Virtuelle Directories im IIS mussten auch neu eingerichtet werden.
Jetzt funktioniert alles wieder (z.B. über Apple MAC-Clients oder OWA auf den PC), bis auf die Clientanbindung von Outlook 2016.

Es läuft nur ein (nicht redundanter) ExchangeServer 2016 (keine virtuelle Maschine) auf Windows Server 2016 in einem System mit redundantem Domaincontroller (auch Windows Server 2016, DNS, DHCP redundant)

- MapioverHTTP ist für die Organisation aktiviert und funktionierte mit CU10
- Authentifizierung unter Mapi im IIS war nach Update deaktiviert --> aktiviert (unter ECP war bei mapi Authentifizierung aktiviert)
- Autodiscover, Zertifikate und DNS müssten soweit (ich es überblicken kann) ok sein, hier kann aber dennoch ein Fehler (bei DNS eher nicht) liegen.
- Im Ereignisprotokoll sind keine Einträge.
- erster CU11 Fix ist eingespielt.

 

Ich tippe auf SSL/Auth Fehler oder doch einen Autodiscover Fehler

 

Wo nachweislich ein Fehler auftritt:

Test-OutlookConnectivity -RunFromServerId XYserver2018 -ProbeIdentity OutlookMapiHttpSelfTestProbe

AUSFÜHRLICH: Verbunden mit XYSERVER2018.wamedia.local.
[PS] C:\Windows\system32>Test-OutlookConnectivity -RunFromServerId XYserver2018 -ProbeIdentity OutlookMapiHttpSelfTestProbe
WARNUNG: Unerwarteter Fehler. Ein Watson-Abbild wird generiert: Sequence contains no elements.
Sequence contains no elements
    + CategoryInfo          : NotSpecified: (:) [Test-OutlookConnectivity], InvalidOperationException
    + FullyQualifiedErrorId : System.InvalidOperationException,Microsoft.Exchange.Management.Tasks.TestOutlookConnectivity
    + PSComputerName        : XYserver2018.XY.local

 

Kann man das "exchange" Directory im Exchange Backend im IIS entfernen und neu erstellen lassen, da es den Fehler /siehe Screenshot) ausgibt, wenn ich auf Authentifizierung klicke.

Ich bin jetzt kein "Exchange-Crack" würde mich allerdings auch nicht als Anfänger bezeichnen und über eine Hilfe oder Ideen sehr freuen.

Ich wünsche allen ein frohes Weihnachtsfest und einen guten Rutsch.

 

[Nobbyaushb 1.472]

Moin,

das beachtet?

https://blogs.technet.microsoft.com/exchange/2018/10/09/ms11-025-required-on-exchange-server-versions-released-before-october-2018/

 

Und einfach das CU11 noch mal laufen lassen - das etwas neu eingerichtet werden muss, ist nicht richtig.

[Ralf2019 0]

Lieben Dank für die schnelle Antwort, habe Ihren Link geprüft, aktuelle Version war installiert.

 

CU11 noch mal drüber laufen lassen wäre ehrlich gesagt auch meine liebste Option … (so habe ich diverse andere Exchange Installationen auch "wieder fit bekommen").

Leider erhalte ich nach (meines Erachtens ordentlichem) Schließen der Dienste vom CU11 Setup das:

 

Fehler:
Der folgende Fehler wurde generiert, als "$error.Clear();
          & $RoleBinPath\ServiceControl.ps1 -Operation:DisableServices -Roles:($RoleRoles.Replace('Role','').Split(',')) -SetupScriptsDirectory:$RoleBinPath;
          & $RoleBinPath\ServiceControl.ps1 -Operation:Stop -Roles:($RoleRoles.Replace('Role','').Split(',')) -IsDatacenter:([bool]$RoleIsDatacenter)
        " ausgeführt wurde: "System.Management.Automation.CommandNotFoundException: Die Benennung "D:\Exchange2016\Bin\ManageScheduledTask.ps1" wurde nicht als Name eines Cmdlet, einer Funktion, einer Skriptdatei oder eines ausführbaren Programms erkannt. Überprüfen Sie die Schreibweise des Namens, oder ob der Pfad korrekt ist (sofern enthalten), und wiederholen Sie den Vorgang.
   bei System.Management.Automation.CommandDiscovery.LookupCommandInfo(String commandName, CommandTypes commandTypes, SearchResolutionOptions searchResolutionOptions, CommandOrigin commandOrigin, ExecutionContext context)
   bei System.Management.Automation.CommandDiscovery.LookupCommandProcessor(String commandName, CommandOrigin commandOrigin, Nullable`1 useLocalScope)
   bei System.Management.Automation.ExecutionContext.CreateCommand(String command, Boolean dotSource)
   bei System.Management.Automation.PipelineOps.AddCommand(PipelineProcessor pipe, CommandParameterInternal[] commandElements, CommandBaseAst commandBaseAst, CommandRedirection[] redirections, ExecutionContext context)
   bei System.Management.Automation.PipelineOps.InvokePipeline(Object input, Boolean ignoreInput, CommandParameterInternal[][] pipeElements, CommandBaseAst[] pipeElementAsts, CommandRedirection[][] commandRedirections, FunctionContext funcContext)
   bei System.Management.Automation.Interpreter.ActionCallInstruction`6.Run(InterpretedFrame frame)
   bei System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame)".

 

 

 

 

 

[gelöscht 0]

Mal das UpdateCas.ps1 Script aus dem /bin Verzeichnis probiert?

 

ASR

[Ralf2019 0]

Hallo ASR,

 

super vielen Dank, das hat geholfen. "Die Version der CAS Rolle wurde von 8 auf15" upgedatet. Jetzt sehe ich die Verbindung mit Outlook wieder siehe Screenshot, es gibt nur einen Auth Fehler, prüfe gerade Zertifikate ... Bisher noch kein Erfolg. (bei virtuellen Mapi Verzeichnis im ECP und im IIS ist die Authentifizeirung m. E. richtig gesetzt).

 

[john23 5]

Laufen alle Dienste?  Geht owa noch?

bearbeitet 21. Dezember 2018 von john23

[Ralf2019 0]

Hallo, ja alle Dienste laufen, OWA geht 100% mit öffentlichen Ordnern, Empfang/Senden für alle Postfächer etc. (das ist momentan meine Notloesung für die wenigen die noch vor Weihnachten arbeiten ...)

Es wurden auch alle virtuellen Directories neu erstellt und die Grundkonfig mit allen Abhängigkeiten geprüft. Die Zertifikate sind alle gültig und an Dienste gebunden. Aber ich vermute fast es liegt irgendwie an den Zertifikaten?  Es läuft Avira professionell müssen nach dem CU11 irgendwelche Ports neu freigegeben werden für die Authentifizierung?? (mit CU10 und mapioverhttp ging es ja ...)

[john23 5]

Im zweifel Avira mal ausschalten / testweise deinstallieren.

 

Generell gibt es eine ganze Liste von Ordnern welche nicht gescannt werden sollten + Prozesse siehe

https://docs.microsoft.com/de-de/exchange/antispam-and-antimalware/windows-antivirus-software?view=exchserver-2019

 

Was ist die Ausgabe von get-servercomponentstate -identity servername ? 

 

 

[Ralf2019 0]

Vielen Dank, Avira Server habe ich mal deinstalliert, leider keine Änderung (Client und Server danach neugestartet etc.) Der servercomponentstate ist 100% active bei allen Komponenten.

Ein Avira Exchange Security ist im Einsatz und konnte nicht mehr gestartet werden (bereits vor der Avira Server Deinstallation/ nach Wahl von Reparatur in der Installationsroutine wieder 100% ok, betrifft ja nur den Mailfluss (100% ok) und nicht die Clients. Ich glaube das lag daran, dass ich aufgrund von NobbyHBs Beitrag und Abhängigkeitsprüfung nochmal die beiden Runtimes installiert habe.

 

Wie prüfe ich denn, "welches Zertifikat mapioverhttp hat?" und an welche Dienste muss es gekoppelt werden? Kann fehlerhafte "Auth" mit Autodiscover zu tun haben? (unter cu10 ok)

Subject            : CN=Microsoft Exchange Server Auth Certificate | Services: SMTP  |   Status: Valid

Was wäre die Standardauthentifizierung? Windows Authentifizierung? (ist ist alles auf Standard eingerichtet)

 

Was mir auch aufgefallen ist, in meinem IIS sind die Mapi Verzeichnisse beide identisch, bei anderen Screenshots von Installationen ist im Backend "mapi" eine Verknüpfung, die virtuellen mapi verzeichnisse habe ich im ECP und später auch noch via shell neu erstellt. Einstellungen beide Verzeichnisse identisch.

 

Wo ich noch am ehsten ne Fehlermeldung produzieren kann ist hier:

 

Test-OutlookConnectivity -RunFromServerId XYserver2018 -ProbeIdentity OutlookMapiHttpSelfTestProbe

AUSFÜHRLICH: Verbunden mit XYSERVER2018.xy.local.
[PS] C:\Windows\system32>Test-OutlookConnectivity -RunFromServerId XYserver2018 -ProbeIdentity OutlookMapiHttpSelfTestProbe
WARNUNG: Unerwarteter Fehler. Ein Watson-Abbild wird generiert: Sequence contains no elements.

 

Ereignisanzeige Anwendung

Watson report about to be sent for process id: 48032, with parameters: E12, c-RTL-AMD64, 15.01.1591.011, w3wp#MSExchangePowerShellAppPool, M.Exchange.Management, M.E.M.T.TestOutlookConnectivity.InternalProcessRecord, System.InvalidOperationException, cdae-dumptidset, 15.01.1591.011.
 

Ich bekomme es nach mehreren Stunden Fehlersuche leider nicht hin. Kann ich am Server global wieder RPC aktivieren? Oder wird das von "modern App" Outlook 2016 nicht mehr unterstützt?

 

Lieben Dank und gute Nacht.

 

[NorbertFe 2.045]

vor 23 Minuten schrieb Ralf2019:

mapioverhttp hat?" und an welche Dienste muss es gekoppelt werden

Was würdest du bei dem Namen denn vermuten? ;) Evtl. http=IIS?

[Ralf2019 0]

Danke ok, dass ist allerdings logisch. Manchmal hat man halt ein Brett vor dem Kopf.

 

[john23 5]

Ein "falsches" oder nicht gültiges Zertifikat sollte höchstens zu Zertifikatsfehlern beim Start von Outlook führen aber nicht zu einer verweigernden Verbindung. Habe ich zumindest noch nicht gehabt.

 

Was gibt dir

Get-AutodiscoverVirtualDirectory | fl

aus?

[NorbertFe 2.045]

vor 12 Minuten schrieb john23:

Get-AutodiscoverVirtualDirectory | fl

Was sollte es deiner Meinung nach denn ausgeben? Bzw. Auf was sollte er achten?

bearbeitet 22. Dezember 2018 von NorbertFe

[Ralf2019 0]

Das dort untern:

 

Wenn ich das Zertifikat falsch einbinde, werden auch von Outlook beim Start  Zertifikatfehler angezeigt. Beim Autodiscover (wenn ich versuche einen Outlook 2016 Client neu einzubinden) wird mir nur imap angeboten (pop deaktiviert), auch wenn ich "manuell" Exchange wähle. Danach kommt der Microsoft Login, wenn der korrekt eingegeben wird kommt "da hat etwas nicht funktioniert"

Die virtuellen Directories für Autodiscover wurden neu erstellt.

 

Wie sieht denn bei euch so ein "virtuelles" mapi Verzeichnis auf dem IIS bei "cu11" aus?

bei mir gibt es die Files

emsmdb
nspi

globalasax

web.config

(mehr nicht)

 

Genügt das für eine Outlook Client Verbindung "mapioverhttp" oder müssten da noch weitere Dateien sein? Oder habe ich Dateien "zuviel"?

 

... wo ich auch noch ansetzen wollte ...  unmittelbar nach einem ersten Serverneustart nach cu11 Installation, wurde schon das erste Update für das CU11 eingespielt. das habe ich jetzt noch nicht runtergenommen. Habe allerdings beim googlen gesehen, das auch "Exchange Profis" mit Clusterinstallationen hier (mit dem CU11 Update) extreme Probleme hatten (nicht das die Clients sich nicht mehr anbinden ließen, sondern andere "Installationsprobleme", wie gesagt eine CU11 Installation per Setup bricht bei mir ab, eine "Recovery" Installation mit dem CU11 Setup funktioniert, löst das Clientproblem aber nicht.

 

 

 

 

RunspaceId                      : 8249489e-3777-4626-bdc2-9319821cf55d
Name                            : Autodiscover (Default Web Site)
InternalAuthenticationMethods   : {Basic, Ntlm, WindowsIntegrated, WSSecurity, OAuth}
ExternalAuthenticationMethods   : {Basic, Ntlm, WindowsIntegrated, WSSecurity, OAuth}
LiveIdNegotiateAuthentication   : False
WSSecurityAuthentication        : True
LiveIdBasicAuthentication       : False
BasicAuthentication             : True
DigestAuthentication            : False
WindowsAuthentication           : True
OAuthAuthentication             : True
AdfsAuthentication              : False
MetabasePath                    : IIS://XYSERVER2018.XY.local/W3SVC/1/ROOT/Autodiscover
Path                            : D:\Exchange2016\FrontEnd\HttpProxy\Autodiscover
ExtendedProtectionTokenChecking : None
ExtendedProtectionFlags         : {}
ExtendedProtectionSPNList       : {}
AdminDisplayVersion             : Version 15.1 (Build 1591.10)
Server                          : XYSERVER2018
InternalUrl                     :
ExternalUrl                     :
AdminDisplayName                :
ExchangeVersion                 : 0.10 (14.0.100.0)
DistinguishedName               : CN=Autodiscover (Default Web Site),CN=HTTP,CN=Protocols,CN=WXYERVER2018,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=XY
                                  GmbH,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=XY,DC=local
Identity                        : XYSERVER2018\Autodiscover (Default Web Site)
Guid                            : 1a9091d8-4ecf-40ec-aa25-bc2343240785
ObjectCategory                  : xy.local/Configuration/Schema/ms-Exch-Auto-Discover-Virtual-Directory
ObjectClass                     : {top, msExchVirtualDirectory, msExchAutoDiscoverVirtualDirectory}
WhenChanged                     : 21.12.2018 09:52:46
WhenCreated                     : 21.12.2018 09:52:46
WhenChangedUTC                  : 21.12.2018 08:52:46
WhenCreatedUTC                  : 21.12.2018 08:52:46
OrganizationId                  :
Id                              : XYSERVER2018\Autodiscover (Default Web Site)
OriginatingServer               : XYSERVER2018.xy.local
IsValid                         : True
ObjectState                     : Changed

 

bearbeitet 22. Dezember 2018 von Ralf2019
besseres Layout, missverständlich formuliert (während dem Setup wurde natürlich kein Server neugestartet ...)

[Ralf2019 0]

Ach du Schande ... (glaub ich zumindest).

 

Ich habe gerade in meine "nicht virtuellen" Installationsordner unter dem Intsallationsverzeichnis Exchange_Installation_Dir\ClientAccess\Mapi geschaut in den beiden Ordnern emsmdb und nspi gibt es jeweils einen BIN Ordner und der enthät 0 Dateien, das darf nicht so sein oder? Wie bekomme ich da meine CU11 Dateien wieder hin?

 

Oder sind diese Ordner leer?