Jump to content

Freigegebener Kalender keine Verbindung


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

Hallo zusammen,

ich habe hier ein merkwürdiges Problem.

Seit neusten bekomme ich von Mitarbeitern die Meldung, das freigegebene Kalender in Outlook etwa ewig brauchen bis sie angezeigt werden, oder Outlook meldet, das keine Verbindung aufgebaut werden kann.

Ich habe unseren KEMP Loadbalancer da in Verdacht, auch wenn was dagegen spricht.

Zu unserem System:

2 Exchange 2016 mit CU11 zu einer DAG zusammen geschaltet.

Kemp Loadbalancer der die Verbindungen auf beide Exchange Server aufteilt.

Outlook 2016 Version 1904 (Build 11601.20178)

 

Wenn ich alle Datenbanken auf einen Exchange verschiebe und im KEMP den anderen Exchange deaktiviere, dann wird zwar langsam, aber es wird eine Verbindung zu den Kalender aufgebaut. Dadurch würde ich mit auf dem KEMP tippen.

Jedoch wundert mich es, das die Verbindung noch langsam ist.

Beim KEMP wurde seit Monaten aber nix verstellt, von daher sehe ich iwie doch keinen Zusammenhang.

 

In letzter Zeit habe ich in den Exchange Servern nur das Zertifikat aktualisiert. Kann es damit unter Umständen mit zu tun haben? Wüsste aber ehrlich gesagt, nicht wieso.

Wenn ich in der OWA einen Kalender hinzufüge, dann ist dieser sofort da, ohne Wartezeit.

 

Hat irgendwer eine Idee wo ich noch nach den Fehler suchen könnte?

 

VG

Lindi

 

Link zu diesem Kommentar

Ich habe heute mal weiter nach den Ursachen geforscht und ob nur einer der Server in der DAG betroffen ist.

Egal welchen Server ich aktiv benutze, der Fehler ist bei beiden.

Mir wurde von Mitarbeitern gesagt, das er wohl auch schon etwas länger vorhanden ist, jedoch wurde das nicht gemeldet, sondern hingenommen :(

Mittlerweile könnte es mit unserer Umstellung auf Office 365 zusammen kommen, der Zeitraum ist nicht weit von einander entfernt. Hier wurde eine Hybridumgebung eingerichtet, wo aber trotzdem noch alles bei uns InHouse läuft. Die Hybridumgebung wurde nur wegen Skype gebraucht. Kann es damit zusammenhängen?

Zusätzlich sind mir folgende Fehler in der Ereignis log aufgefallen.

 

Ereigniss 4999 MSExchange Common

Watson report about to be sent for process id: 17380, with parameters: E12IIS, c-RTL-AMD64, 15.01.1591.010, w3wp#MSExchangeServicesAppPool, M.Exchange.Security, M.E.S.O.V1ProfileLocalTokenIssuer..ctor, M.E.S.OAuth.OAuthTokenRequestFailedException, 6446-dumptidset, 15.01.1591.008.
ErrorReportingEnabled: False 

und 

Ereigniss 1325 ASP.NET 4.0.30319.0

Der Prozess wurde aufgrund einer unbehandelten Ausnahme beendet.

Application ID: /LM/W3SVC/2/ROOT/EWS

Process ID: 17380

Exception: Microsoft.Exchange.Security.OAuth.OAuthTokenRequestFailedException

Message: Missing signing certificate.

StackTrace:    bei Microsoft.Exchange.Security.OAuth.V1ProfileLocalTokenIssuer..ctor(ILocalConfiguration localConfiguration)
   bei Microsoft.Exchange.Security.OAuth.V1ProfileOAuthTokenBuilder..ctor(ILocalConfiguration localConfiguration, ITokenIssuerHelper tokenIssuerHelper, OAuthSnapshot oAuthSnapshot)
   bei Microsoft.Exchange.Security.OAuth.OAuthExchangeToExchangeTokenFactory..ctor()
   bei Microsoft.Exchange.Services.Core.GetClientAccessToken.<>c.<.cctor>b__49_0()
   bei System.Lazy`1.CreateValue()
   bei System.Lazy`1.LazyInitValue()
   bei Microsoft.Exchange.Services.Core.GetClientAccessToken.GetExchangeUserTokenForConnectors(ADUser user)
   bei Microsoft.Exchange.Services.Core.GetClientAccessToken.CreateConnectorsToken(ADUser user)
   bei Microsoft.Exchange.Services.Core.GetClientAccessToken.ExecuteGetClientAccessToken()
   bei Microsoft.Exchange.Services.Core.GetClientAccessToken.Execute()
   bei Microsoft.Exchange.Services.Core.ExceptionHandler`1.Execute(IRequestDetailsLogger logger, CreateServiceResult createServiceResult, Int32 index, ExecutionOption executionOption)
   bei Microsoft.Exchange.Services.Core.BaseStepServiceCommand`3.InternalExecuteStep(Boolean& isBatchStopResponse)
   bei Microsoft.Exchange.Services.Core.ServiceCommandBase`1.<ExecuteStep>b__82_0()
   bei Microsoft.Exchange.Services.Core.ServiceCommandBase`1.<>c__DisplayClass88_0.<ExecuteHelper>b__0()
   bei Microsoft.Exchange.Common.IL.ILUtil.DoTryFilterCatch(Action tryDelegate, Func`2 filterDelegate, Action`1 catchDelegate)
   bei Microsoft.Exchange.Services.Core.ServiceDiagnostics.SendWatsonReportOnUnhandledException(ICallContext callContext, Action methodDelegate)
   bei Microsoft.Exchange.Services.Core.ServiceCommandBase`1.ExecuteHelper(Func`1 action)
   bei Microsoft.Exchange.Services.Core.Types.ServiceTask`1.<>c__DisplayClass11_0.<ExecuteHelper>b__0()
   bei Microsoft.Exchange.Common.IL.ILUtil.DoTryFilterCatch(Action tryDelegate, Func`2 filterDelegate, Action`1 catchDelegate)
   bei Microsoft.Exchange.Services.Core.Types.BaseServiceTask`1.SendWatsonReportOnGrayException(Action callback, Action exceptionHandlerCallback, Boolean isGrayExceptionTaskFailure)
   bei Microsoft.Exchange.Services.Core.Types.ServiceTask`1.ExecuteHelper(Func`1 multiStepAction)
   bei Microsoft.Exchange.Services.Core.Types.ServiceTask`1.<InternalExecute>b__7_0()
   bei Microsoft.Exchange.Diagnostics.RequestDetailsLoggerBase`1.TrackLatency[TResult](Enum latencyMetadata, Func`1 method)
   bei Microsoft.Exchange.Diagnostics.RequestDetailsLoggerBase`1.TrackLatency[TResult](Enum latencyMetadata, Func`1 method, Double& latencyValue)
   bei Microsoft.Exchange.Services.Core.Types.ServiceTask`1.InternalExecute(TimeSpan queueAndDelay, TimeSpan totalTime)
   bei Microsoft.Exchange.Services.Core.Types.BaseServiceTask`1.<>c__DisplayClass33_0.<Execute>b__0()
   bei Microsoft.Exchange.Services.Core.Types.BaseServiceTask`1.LocalTimedCall(Action action)
   bei Microsoft.Exchange.Services.Core.Types.BaseServiceTask`1.ExecuteWithinCallContext(Action action)
   bei Microsoft.Exchange.Services.Core.Types.BaseServiceTask`1.Execute(TimeSpan queueAndDelayTime, TimeSpan totalTime)
   bei Microsoft.Exchange.Services.Core.Types.BaseServiceTask`1.ExecuteLoop(Boolean synchronously)
   bei System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   bei System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   bei System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()
   bei System.Threading.ThreadPoolWorkQueue.Dispatch()

Mich wundert hier, das es ASP.NET 4.0.... heißt. installiert ist 4.7.2 (Release 461814)

 

Beide Fehler sind auf beiden DAG Server vohanden. Google bringt mich hier leider nicht weiter. Hat da jemand eine Idee dazu?

 

VG

Lindi

Link zu diesem Kommentar

Hallo,

der Fehler scheint gefunden zu sein.

Ich habe nach langen suchen Hinweise gefunden das es mit den neuen Zertifikaten und der Hybridlösung zusammen hängen soll.

Also gestern Abend alle Zertifikate erneuert, kompletter Restart aller Exchange Server und dann bis heute laufen lassen.

Beim erneuern nicht vergessen das OAuth Zertifikat zu überprüfen :) .

Heute früh geht nur der Kalender wieder ohne Probleme.

Mein Problem mit der Outlook suche ist im übrigen somit auch beseitigt.

 

VG

Lindi

bearbeitet von lindi200000
Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...