Ralf2019

Ja, ich weiß auch nicht, was mich da geritten hat den zu ändern, ich vermute, dass das auch der einzige Grund ist, weshalb das Update fehlgeschlagen ist, ansonsten war m.E. eigentlich alles ok bei der Installation (Config, Updates, Virenscanner aus etc.).

D:\EXCHANGE_CU11\ExchangeServer2016-x64-cu11\Setup.exe /IAcceptExchangeServerLicenseTerms /Mode:RecoverServer /TargetDir:D:\Exchange2016 /DomainController:XYserver2018 Habe diesen Parameter benutzt Mit dem Befehl konnte ich auch remote gut prüfen, ob die Clients verbinden: Test-OutlookConnectivity -RunFromServerId XYserver2018 -ProbeIdentity OutlookMapiHttpSelfTestProbe (solange das Problem bestand war die Fehlermeldung Sequence contains no elements Ich habe außerdem die web.config Dateien (ClientAccess) nach dem Update verglichen und bin noch auf Variablenfehler (InstallDir/Installpath) gestoßen. Allerdings hatte ich vorher schon das Script aus dem Bin Ordner ausgeführt, das alle Pfade anpasst, durch das Zurückschieben der Backupdaten hatte ich aber dann wieder Variablenfehler drin. Manuell habe ich Notepad++ mit dem Plugin Compare verwendet, was man auch gut für andere Programmiersprachen oder Texte benutzen kann.

Es geht wieder! Vielen Dank für alle Hilfen und Kommentare, das neue Jahr fängt doch gut an Die Lösung war die folgende: Im IIS Mapi Backend Verzeichnis auf eine Verknüpfung zurückgesetzt (siehe mein erster Screenshot da war irgend etwas falsch.) Dann Exchange recovery setup, dann musste noch via ECP bei EWS Standardauthentifizierung aktiviert werden und bei Mapi Virtual Directory Kerberos (d. h. bei mapi alle Authentifizierungen an). Die beiden Authentifizierungen oben waren allerdings vorher auch schon gesetzt, das alleine kann es "leider" nicht gewesen sein. Die Änderung mit dem Mapi Verzeichnis im IIS haut auch ne ASP.net Fehlermeldung ("kryptisch") ins Ereignisprotokoll. Es funktioniert soweit aber "alles" (was funktionieren muss). Es wird immer noch mapioverhttp verwendet. Statt NTLM jetzt aber negotiate. Ich bin jetzt erst mal auf das CU12 im März gespannt (werd es dann bei Regenwetter im Sommer anwenden ... und vorher alle IIS Einstellungen abfotografieren ... /screenshots machen ... und hoffe dass dies dann erfolgreich durchläuft. Hab jetzt wieder viel gelernt, hätte es aber lieber unter anderen Bedingungen gelernt Einen guten Rutsch ins neue Jahr 2019!

Das ist der Zustand nach einem Disaster Recovery Setup ... RunspaceId : 600f033d-3c32-4d70-acdd-b57181bc4640 IISAuthenticationMethods : {Basic, Ntlm, OAuth, Negotiate} MetabasePath : IIS://XYSERVER2018.xymedia.local/W3SVC/1/ROOT/mapi Path : D:\Exchange2016\FrontEnd\HttpProxy\mapi ExtendedProtectionTokenChecking : None ExtendedProtectionFlags : {} ExtendedProtectionSPNList : {} AdminDisplayVersion : Version 15.1 (Build 1591.10) Server : XYSERVER2018 InternalUrl : https://xyserver2018.xymedia.local/mapi InternalAuthenticationMethods : {Basic, Ntlm, OAuth, Negotiate} ExternalUrl : ExternalAuthenticationMethods : {Basic, Ntlm, OAuth, Negotiate} AdminDisplayName : ExchangeVersion : 0.10 (14.0.100.0) Name : mapi (Default Web Site) DistinguishedName : CN=mapi (Default Web Site),CN=HTTP,CN=Protocols,CN=xySERVER2018,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=xy Media GmbH,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=xymedia,DC=local Identity : xySERVER2018\mapi (Default Web Site) Guid : 3133190f-39b2-4a3e-941e-39867fc4951e ObjectCategory : xymedia.local/Configuration/Schema/ms-Exch-Mapi-Virtual-Directory ObjectClass : {top, msExchVirtualDirectory, msExchMapiVirtualDirectory} WhenChanged : 27.12.2018 12:35:51 WhenCreated : 23.12.2018 20:36:12 WhenChangedUTC : 27.12.2018 11:35:51 WhenCreatedUTC : 23.12.2018 19:36:12 OrganizationId : Id : xySERVER2018\mapi (Default Web Site) OriginatingServer : xySERVER2018.xymedia.local IsValid : True ObjectState : Changed OAuth habe ich heute manuell per Shell ergänzt

Ich hoffe Ihr hattet schöne Weihnachten, leider hat sich das Problem über Weihnachten nicht von selbst gelöst ... meine Outlook 2016 Clients verbinden noch immer nicht mit Exchange 2016 CU11 Da mein System leider keine Testumgebung ist, muss ich es bis 02.1 wieder flott bekommen ... Jetzt bin ich nicht remote verbunden sondern "vor Ort". OWA und ECP (Mailempfang, Versand, öffentliche Ordner etc.) funktioniert. OWA und ECP benutzen formularbasierte Authentifizierung. Vor CU11 Update gingen alle Outlook 2016 Clients via mapioverhttp rein im Client-Logfile (vor CU11) steht "negotiate, NTLM und anonymous" Kann man einen RPC Fallback implementieren? Es handelt sich um eine "0/8/15" Installation. Mapi Verzeichnisse (und alle anderen) wurden mehrfach über ECP zurückgesetzt (leider ohne Erfolg). Muss ich beim zurücksetzen des Mapi Verzeichnisses via Exchange Shell außer den Auth Einstellungen weitere Parameter mitgeben? Ich vermute sehr stark, dass es mit den Auth Einstellungen in den/im IIS zusammenhängt. Wie müssen denn virtuelles EWS Verzeichnis und Mapi Verzeichnis im Standardfall eingerichtet sein? Habe beim EWS Backend auch den Ordner "bin" wo ich ein"Auth" setzen kann, bei Mapi im Backend die Ordner emsmdb und nspi ich habe die Auth Einstellungen dort überall einheitlich gewählt. Komisch kommt mir auch vor, das bei mir Mapi im IIS Backend keine Verknüpfung ist sondern ein "normaler Ordner". kann ich das irgendwie ändern (Siehe Screenshot am Anfang dieses Themas). Die IIS hab ich nach jeder Änderung neu gestartet, den Server komplett vielleicht 1-3 mal während meinen Änderungen. Gibt es irgendwo Screenshots, wie alle Werte bei einer Standardinstallation eingerichtet sind? Ich bin langsam am verzweifeln, gerne loben wir auch "Amazon-Gutscheine" oder ähliches aus.

the issue was in IIS configuration on MAPI virtual directory and EWS VIRT EWS VIRT on defaulter web site the negotiate authentication provider was missing under Windows authentication MAPI VIRT on Exchange Back End was configured with Windows authentication instead of anonymous authentication Ich glaube ich bin jetzt auf einer heißen Spur ... noch funktioniert es nicht aber das war trotz zurücksetzen der virtuellen Verzeichnisse nicht in Ordnung.

Wo würdest du/ würden Sie denn suchen? Autodiscover, IIS, Zertifikate ? m.E. DNS ok Dienste ok Firewall/Ports ok Clients ok/neuste Version virtuelle Verzeichnisse ok/neu erstellt Net SDK neuste Version keine "komischen" Registry Einstellungen für Outlook Fehler tritt auf neustem Windows 10 auf und vorletzter Windows 10 Version auf lokales Avira Professionell hat bei CU10 nicht blockiert Konfig unter CU10 ok, keine Probleme Fehler: CU11 Setup bricht ab, CU 11 recovery Setup läuft imap wird gefunden, Verbindung zum Exchange Server nicht Verbindungstests schlagen fehl mit Session contains no Elements (Watson Protokoll wird erstellt)

Gut oder schade, dachte hätte endlich mal einen Fehler/neuen Weg gefunden. Also in meinen MAPI Ordner sieht es so aus: \mapi\ mapi\emsmdb mapi\emsmdb\bin(leer) mapi\emsmdbglobal.asax mapi\emsmdbweb.config mapi\emsmdbweb.config.bak mapi\nspi mapi\nspi\bin(leer) mapi\nspi\global.asax mapi\nspi\web.config mapi\nspiweb.config.bak mapi\web.config (keine BAK) Sieht das gut aus oder fehlen Dateien? Ich werde jetzt mal die web.config mit der .bak vergleichen

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?

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

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

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.

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 ...)

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).

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)".

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.