Die schlechte Nachricht vorweg: Nein, es gibt momentan keine mir bekannte Lösung obwohl ich permanent zu diesem Thema recherchiere.

Die gute Nachricht ist, dass dieser Sachverhalt Millionen betroffene Nutzer um den ganzen Globus betrifft. Wenn man aber direkt mit Microsoft oder Cisco zu diesem Thema spricht, hat man das Gefühl, dass beide nicht aufeinander zugehen wollen. Ich zumindest habe das Gefühl, dass beide diese Diskrepanz zwischen beiden Systemen eher als Argument für den vollständigen Wechsel auf die jeweils eigene Telefonie- oder Kollaborationsplattform nutzen wollen.

Einen Lichtblick am Ende des Horizont, einen kleinen Hoffnungsschimmer des aufeinander Zugehens gibt es trotzdem: Cisco hat ein Jabber-Add-On für Teams veröffentlicht. Leider ist der Funktionsumfang nur sehr klein. Ich kann aus dem Teams-Add-On eine Telefonnummer wählen – doch diese startet dann einfach den Jabber Client und ich verliere den Teams-Kontext.

Auch auf Seiten der Microsoft Nutzer werden die Rufe nach einer Verfügbarkeits-Status-Synchronisation lauter. Im Microsoft Teams Feature Request Board gibt es eine Forderung nach der Synchronisation zwischen Jabber und Teams.

Unter folgendem Link kann man mit Angabe seiner Mailadresse abstimmen, eine Registrierung wird nicht benötigt: https://microsoftteams.uservoice.com/forums/555103-public/suggestions/40285315-synchronise-status-with-cisco-jabber
Mit Stand vom 07.01.2021 haben 46 User ihre Stimme für diesen Feature Request abgegeben und ich rate auch Euch Eure Stimme hierfür abzugeben.

Sobald ich eine funktionierende Lösung für dieses Problem gefunden habe, werde ich diese auf dieser Seite vorstellen.

Solltet Ihr bereits eine funktionierende Lösung für dieses Problem kennen, informiert mich gerne über die Kommentarfunktion.

Der Beitrag Verfügbarkeitsstatus zwischen Microsoft Teams und Cisco Jabber Synchronisieren erschien zuerst auf Pixelfriedhof.

In dieser Anleitung geht es darum, dass ein Windows-Server, gehostet in der Cloud, zu einem oder mehreren festen Zeitpunkten die Verbindung mit einem privaten Netzwerk mittels VPN-Client von alleine beendet und wiederaufbaut, damit sich Nutzer über die private IP-Adresse innerhalb des LANs zum Server verbinden können. Diese Verbindungstrennung und Wiederverbindung ist oftmals sinnvoll, weil sich der OpenVPN Client auf dem Server im Standard nur dann neu verbindet, wenn ein Nutzer aktiv in einer Sitzung die Verbindung startet. Für den Einsatz eines Server ist dies allerdings sehr unpraktikabel, da man diesen ständig im privaten Netzwerk zugriffsbereit haben möchte. Auch im Falle von Verbindungsabbrüchen, zum Beispiel nach Zwangstrennungen auf der VPN-Serverseite, stellt ein zeitgesteuerter Reconnect die Verbindung wieder sicher.

Wie in der Einleitung beschrieben, setze ich in dieser Anleitung die erfolgreiche Installation und Konfiguration eines Open-VPN Zugangs bestehend aus Server- und Clientseite voraus. Der Nutzer sollte bereits in der Lage sein, den OpenVPN-Tunnel manuell erfolgreich aufbauen und eine IP-Adresse aus dem privaten Netz beziehen zu können.

Wir setzen diese Funktion mit Hilfe der Windows Aufgabenplanung und einiger Batch-Skripte um.

1. OpenVPN-Dienst aktivieren

 In der Verwaltung unseres Systems suchen wir den OpenVPN-Dienst. Diesen setzen wir auf den Starttyp „Automatisch“ (NICHT verzögerter Start) und starten den Dienst.

2. Batch-Skripte bereitstellen

Nun brauchen wir zwei Batch-Scripte. Einen zum Trennen einer ggf. bestehenden VPN-Verbindung und einen zum Herstellen der VPN-Verbindung.

Der ein oder andere wird nun sagen: „Wozu zwei Scripte?“. Ganz einfach: Damit evtl. Fehler granularer untersucht werden können. Aus diesem Grund werden wir die Trennung und die Herstellung der Verbindung in jeweils einer Aufgabe und einer damit in Verbindung stehenden Batch-Datei angehen. Schöner Nebeneffekt: Durch die Unterteilung unserer Kommandos in zwei Scripte und Aufgaben können wir sicherstellen, dass zwischen Trennung und Wiederherstellung der Verbindung genug Zeit vergeht.

Wir erstellen uns zwei Batchdateien, die über ein net-Kommando den OpenVPN-Dienst ansprechen und ihn stoppen, sowie starten. Denn bei jedem Start des Dienstes, wird die Verbindung mit dem OpenVPN-Server auf der Gegenseite erneut aufgebaut. 

Die Batchdateien legen wir an einem für das System zugänglichen Speicherort ab, in meinem Falle im Ordner „Netlogon“ direkt auf dem Laufwerk „C:/“.

Der Start des Dienstes geschieht über den Batch Befehl net start „OpenVPNService“, abgelegt in einem separaten Batch-Script.

Das Beenden des Dienstes geschieht über den Batch Befehl net stop „OpenVPNService“, ebenfalls abgelegt in einem separaten Batch-Script.

3. Aufgabe planen

Nun müssen die zuvor erstellten Batch-Dateien mit Ihren Kommandos gestartet werden. Am besten geschieht dies zeitabhängig.
Bei uns zum Beispiel wird ab morgends 08:00 Uhr bis Abends 22:00 Uhr mit dem Server gearbeitet, sprich in dieser Zeit muss das Gerät im lokalen Netzwerk erreichbar sein. Damit dies der Fall ist, muss natürlich die Internetverbindung zum Cloud-Server in dieser Zeit stabil sein. In unserem Beispiel gibt es eine Zwangstrennung der Internetleitung zwischen 23:00 Uhr und 02:00 Uhr nachts. Und dabei wird die Verbindung des OpenVPN-Clients getrennt und ohne diese Anleitung einfach nicht wieder aufgebaut. 

Die Einstellungen für diese Aufgabe nehmen wir in der Windows Aufgabenplanung vor, welche Teil der Computerverwaltung ist. Hier erstellen wir zwei neue Aufgaben. Eine zum Stoppen einer eventuell vorhandenen VPN-Verbindung und die andere zum Start. Die nun nachfolgen Schritte müssen wir daher jeweils für die Stop- und die Start-Aufgabe wiederholen.

Damit das System ab 08:00 Uhr morgens, ggf. etwas früher, startklar ist, lege ich die Verbindungstrennung auf täglich 06:30 Uhr. In der zweiten Aufgabe zum Start der Verbindung hinterlege ich als Zeitpunkt täglich 06:31. 1 Minute sollte zum Beenden der ggf. vorher existenten VPN-Verbindung ausreichen.

Als auszuführende Aktion hinterlege wir den Aufruf der zuvor abgelegten Batch-Skripte.

Wichtig hierbei ist, als welcher Benutzer wir diese ausführen lassen. Damit die Ausführung der Aufgaben ohne Nutzerkontext, sondern auf Systemebene auch ohne angemeldete Benutzer funktioniert, führen wir die Aufgabe als Nutzer „SYSTEM“ aus. Wir stellen die korrekte Kompatibilität ein und wählen „Mit höchsten Privilegien ausführen“, damit der Task auch auf die Batchdateien zugreifen darf.

Das warschon alles. Der Dienst wird nun jeden Morgen um 06:31 Uhr neugestartet und der Server ist ab 06:31 im lokalen, privaten Netz registriert und erreichbar.

Weiterführendes / Produktiveinsatz

Das oben im Beispiel genannte Zeitmodell ist natürlich sehr starr. Man kann die ganze Aufgabe noch intelligenter machen. Hier Anregungen für den Produktiveinsatz.

Man kann die ganze Sache erheblich intelligenter und robuster machen, indem man versucht, den Reconnect, also den Dienstneustart nur dann auszuführen wenn dieser auch erforderlich ist sprich wenn keine VPN-Verbindung mehr besteht.

Dazu kann man im aufgerufenen Batch-Script zunächst prüfen, ob eine Verbindung zu einem im Zielnetzwerk (lokales Netz) befindlichen Rechner exisitert. Erst wenn diese Verbindung nicht zu Stande kommt, wird der Reconnect ausgelöst. Das hat den Vorteil, dass man nurnoch das Script zum Neustart des Dienstes aufrufen muss und erlaubt zudem die Ausführung der Aufgabe in kürzeren Intervallen, da nicht jedesmal ein Reconnect erzwungen wird, was sonst die Erreichbarkeit des Servers und somit die Arbeit stören würde. Denkbar wäre dann ein Intervall von 10 Minuten. 

Die so abgebildete Logik wäre:

„Prüfe im 10 Minuten Rhythmus, ob der Server 192.168.1.1 erreichbar ist, wenn nein, starte den Dienst neu und verbinde mit dem LAN.“

Der Beitrag Open VPN Dienst ohne Benutzeranmeldung auf Windows Server starten erschien zuerst auf Pixelfriedhof.