Nach der Umstellung der primären E-Mail-Adressen auf den Konzern wurde ich mindestens einmal pro Tag mit einem Mitteilungsfenster belästigt.
“Skype for Business kann nicht überprüfen, ob der Server für ihre Anmeldeadresse vertrauenswürdig ist. Trotzdem verbinden?“
Meine erste Reaktion war den Haken bei “Diesem Server immer vertrauen und nicht mehr anzeigen” zu setzen und “Verbinden” zu klicken.
Schon an dieser Stelle fiel mir auf, dass Skype ohne Unterbrechung weiterlief.
Tags darauf ploppte das Fenster wieder auf.
Ich nahm einfach an, ich habe einen Tag zuvor völlig verpeilt den Haken vergessen, und setzt ihn erneut.
Allerdings machte ich mir zur Sicherheit eine Notiz für den Fall, dass die Mitteilung wieder erscheinen sollte.
Natürlich wurde ich am nächsten Tag erneut mit dem Pop-Up erfreut.
Nun war es an der Zeit den Ursachen auf den Grund zu gehen.
Das Zertifikat war gültig. Die Zertifikatskette war auch ok.
Somit ab zur Suchmaschine.
Zwar gab es etliche Treffer, u.a. auch was zu Lync, allerdings traf das alles nicht zu.
Da das Problem zwar nervig, aber unkritisch war, habe ich nach 2 h die Lösungssuche erstmal beendet.
Zumal ich davon ausging, dass es nur mich betraf.
Es breitet sich aus
Einige Zeit später meldete sich eine weitere Kollegin.
Es war wieder Zeit die Ärmel hochzukrempeln.
Dieses Mal nahm ich den Konzern-Helpdesk mit hinzu. Schließlich lassen sie mich bei Exchange und Skype nicht mitspielen. Also sollen sie ruhig auch die Suppe auslöffeln, die sie uns eingebrockt haben. Also mal schön ein Ticket geöffnet.
Die nächste Runde Lösungssuche verlief genau so erfolglos, wie zu vor. Ich war – Gag – sogar so verzweifelt, dass ich Google auf Seite 2 und 3 sowie andere Suchmaschinen abgesucht habe.
Ein Export/ Import des Zertifikats brachte auch nichts.
Den Nachmittag hätte ich auch besser verbingen können.
Also das Problem wieder für dringendere Dinge zu Seite legen.
Es eskaliert
Das Ganze liess sich bei zwei Betroffenen gut ignorieren, bis die Meldungen über das nervige Mitteilungsfenster in Stundentakt bei mir hereinflatterten.
Anscheinend hatte so langsam alle Kolleginnen und Kollegen die Faxen dicke.
Damit war die Problematik eine Stufe eskaliert und es bedurfte einer Lösung.
Der Helpdesk träumte ebenfalls weiter vor sich hin.
Alle vorherigen Lösungen hatten irgendwie mit einem Registry-Key “TrustModelData” unter “Software\Policies\Microsoft\Office” zu tun.
Wahlweise unter “HKCU” oder “HKLM”. Doch ab einer gewissen Tiefe waren bei uns diese EInträge gar nicht vorhanden.
Diese Schlüssel in drei oder mehr Ebenen nach unten alle manuell für einen Test anzulegen erschienen mir widersinnig und wenig zielführend.
In diesem Microsoft-Dokument fand ich schließlich einen Ansatz.
Eine Lösung zeichnet sich ab
Relativ weit unten auf diese Seite war eine Gruppenrichtlinie, welche die Liste vertrauenswürdiger Domänen bereitstellt, die nicht mit dem Präfix der SIP-Domäne des Kunden übereinstimmen.
Was ich an dieser Stelle kurios fand und immer noch finde. Denn somit würde es eigentlich bedeuten, dass jede Konzern-Niederlassung, deren primäre Adresse umgestellt worden ist, genau das gleiche Problem haben müsste. Doch aus dieser Ecke bis heute “Stille”.
Die Gruppenrichtlinie war mit der angemahnten Domäne schnell erstellt und auf die OU verlinkt, der mein Rechner zugeordnet ist.
Trotzdem erfreute mich Skype am nächsten Tag mit dem Fenster.
Bevor ich meinen Kollegen laut fluchend aufschrecken konnte, fiel mir direkt auf, dass es dieses Mal eine andere Domäne war, der nicht vertraut wurde. Fast schon lustig war es “outlook.com”.
Somit zurück zur Richtlinie “Computerkonfiguration – Richtlinien – Administrative Vorlagen – Skype for Business 2016/ Microsoft Lync-Featurerichtlinien – Liste der vertrauenswürdigen Domänen” und die neue Domain “outlook.com” hinzufügen.
In der Beschreibung der Richtlinie stand unten “Nicht konfiguriert (Standard)/Deaktiviert: Standardmäßig sind die folgenden Domänen vertrauenswürdig: “lync.com”, “outlook.com”, “lync.glbdns.microsoft.com” und “microsoftonline.com”.”.
Anscheinend wird die Liste bei einer Konfiguration zurückgesetzt statt ergänzt. Somit habe ich die Standardwerte “lync.com, outlook.com, lync.glbdns.microsoft.com, microsoftonline.com” hinzugefügt.
Der Abschluß
Am darauffolgenden Tag: Stille.
Bei vereinzelten Kolleginnen und Kollegen musste noch einmal der Haken bei “Diesem Server immer vertrauen und nicht mehr anzeigen” gesetzt werden.
Eine Systematik, bei wem und warum konnte ich nicht erkennen.
Aber seit dieser Maßnahme ist alles wieder gut.