4
Word-Probleme im VPN
Hallo zusammen,
wir haben bei uns in der Firma das Problem, dass bei manchen aus dem Home Office heraus, also über VPN, Word nicht vernünftig funktioniert. Dateien, egal ob lokal oder auf einem Netzlaufwerk, benötigen teils bis zu vier Minuten um sich zu öffnen und sind dann auch erst mal noch ein paar Sekunden lang sehr träge, wenn man dort reinklickt. Irgendwann fängt sich die Sache dann und auch andere Dateien, welche später geöffnet werden, öffnen sich direkt und flüssig.
Ohne VPN, also vor Ort im Büro, funktioniert alles einwandfrei. Es melden sich immer mehr User bei mir mit diesem Problem, ich habe die Hände voll zu tun und mir fehlt hier ehrlich gesagt das Know-How um mir da eine Lösung auf die Schnelle einfallen zu lassen. Vielleicht gibt es hier ja jemanden, der dieses Problem kennt oder erkennt?
Kurz zu den Details:
- Es geht um MS Office 2016 (leider werden wir bezüglich Upgrade konzernseitig noch zurück gehalten). Per Volumen-Lizenzschlüssel aktiviert und innerhalb Outlook mit einem Exchange-Account verbunden (falsch wichtig)
- Es geht nur um Word (Excel-Dateien und Co. machen keinen Ärger)
- Es tritt sowohl unter Windows 10 als auch 11 auf
- Die User haben verschiedene Anschlüsse und es hat bei denen auch schon mal zu Hause funktioniert, aber beispielsweise seit einer OS-Neuinstallation oder generell neuen Rechner nicht mehr.
- Das VPN läuft über SSL und kommt von unserer SecurePoint Firewall/IP-Gateway. Der Client sollte einfach ein gebrandeter OpenVPN sein.
- Hier auch mal die Config vom VPN-Client, vielleicht ist da ja ein Fehler?
Natürlich habe ich schon viel gegooglet, aber leider sind die meisten Ergebnisse diesbezüglich um die 15 Jahre her.
Folgendes habe ich aber schon probiert:
- Unter \HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\Open Find einen DWORD namens "EnableShellDataCaching" mit dem Wert "1" angelegt.
- Im Word selber unter Optionen > Erweitert > Speichern > Den Haken gesetzt bei "Remote gespeicherte Daten auf Computer kopieren und beim Speichern aktualisieren"
Beides ergab leider bisher keinen Erfolg und es geht ja eben auch sogar um das Öffnen lokaler Word-Dateien.
Irgendwie sieht es für mich nach mehreren Baustellen aus und kann es kaum zuordnen. Irgendwie DNS-technisch, als wenn Word da was nicht findet und anschließend auf den Timeout wartet. Aber irgendwann klappt es ja und dann auch für alle weiteren Dateien. Irgendwo sieht es da für mich wieder nach einer lokalen Einstellungssache aus.
Kann wer weiterhelfen?
wir haben bei uns in der Firma das Problem, dass bei manchen aus dem Home Office heraus, also über VPN, Word nicht vernünftig funktioniert. Dateien, egal ob lokal oder auf einem Netzlaufwerk, benötigen teils bis zu vier Minuten um sich zu öffnen und sind dann auch erst mal noch ein paar Sekunden lang sehr träge, wenn man dort reinklickt. Irgendwann fängt sich die Sache dann und auch andere Dateien, welche später geöffnet werden, öffnen sich direkt und flüssig.
Ohne VPN, also vor Ort im Büro, funktioniert alles einwandfrei. Es melden sich immer mehr User bei mir mit diesem Problem, ich habe die Hände voll zu tun und mir fehlt hier ehrlich gesagt das Know-How um mir da eine Lösung auf die Schnelle einfallen zu lassen. Vielleicht gibt es hier ja jemanden, der dieses Problem kennt oder erkennt?
Kurz zu den Details:
- Es geht um MS Office 2016 (leider werden wir bezüglich Upgrade konzernseitig noch zurück gehalten). Per Volumen-Lizenzschlüssel aktiviert und innerhalb Outlook mit einem Exchange-Account verbunden (falsch wichtig)
- Es geht nur um Word (Excel-Dateien und Co. machen keinen Ärger)
- Es tritt sowohl unter Windows 10 als auch 11 auf
- Die User haben verschiedene Anschlüsse und es hat bei denen auch schon mal zu Hause funktioniert, aber beispielsweise seit einer OS-Neuinstallation oder generell neuen Rechner nicht mehr.
- Das VPN läuft über SSL und kommt von unserer SecurePoint Firewall/IP-Gateway. Der Client sollte einfach ein gebrandeter OpenVPN sein.
- Hier auch mal die Config vom VPN-Client, vielleicht ist da ja ein Fehler?
client
remote-cert-eku "TLS Web Server Authentication"
dev tun
tun-mtu 1500
# fragment 1300
mssfix
proto udp
float
remote (IP-Adresse) 1194
nobind
persist-key
persist-tun
ca GESCHWAERZT
cert GESCHWAERZT
key GESCHWAERZT
verb 3
mute 20
#auth-nocache
auth-user-pass
route-method exe
route-delay 2
#http-proxy server_IP port
#http-proxy-retry
reneg-sec 0
#comp-lzo yes
#redirect-gateway
explicit-exit-notifyNatürlich habe ich schon viel gegooglet, aber leider sind die meisten Ergebnisse diesbezüglich um die 15 Jahre her.
Folgendes habe ich aber schon probiert:
- Unter \HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\Open Find einen DWORD namens "EnableShellDataCaching" mit dem Wert "1" angelegt.
- Im Word selber unter Optionen > Erweitert > Speichern > Den Haken gesetzt bei "Remote gespeicherte Daten auf Computer kopieren und beim Speichern aktualisieren"
Beides ergab leider bisher keinen Erfolg und es geht ja eben auch sogar um das Öffnen lokaler Word-Dateien.
Irgendwie sieht es für mich nach mehreren Baustellen aus und kann es kaum zuordnen. Irgendwie DNS-technisch, als wenn Word da was nicht findet und anschließend auf den Timeout wartet. Aber irgendwann klappt es ja und dann auch für alle weiteren Dateien. Irgendwo sieht es da für mich wieder nach einer lokalen Einstellungssache aus.
Kann wer weiterhelfen?
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 33068370873
Url: https://administrator.de/contentid/33068370873
Printed on: April 27, 2024 at 13:04 o'clock
4 Comments
Latest comment
Moin,
bin da auch nicht wirklich tief drinnen... aber wenn das vor Allem bei neu aufgesetzten Geräten immer auftritt hört sich das nach einer GPO an?
Würde mal die Add-Ins deaktivieren, nicht dass da einer den Start verzögert bei aktiver Verbindung des VPNs.
Ggfs. auch mal den Safe-Modus ausprobieren.
Würde nochmal mit dem ProcMon schauen, ob der beim Starten irgendetwas versucht. Vielleicht kann damit die Ursache weiter eingegrenzt werden.
Ansonsten manuell die Registry-Einträge vom Word löschen und schauen, ob das Problem ausgehend von der Registry kommt?
Wenn bspw. ein online UNC Pfad für weitere Templates auf einem Share abgerufen werden sollen und der nicht direkt per DNS erreichbar ist, könnte das zu deiner Beschreibung bzgl. DNS passen.
VG
bin da auch nicht wirklich tief drinnen... aber wenn das vor Allem bei neu aufgesetzten Geräten immer auftritt hört sich das nach einer GPO an?
Würde mal die Add-Ins deaktivieren, nicht dass da einer den Start verzögert bei aktiver Verbindung des VPNs.
Ggfs. auch mal den Safe-Modus ausprobieren.
Würde nochmal mit dem ProcMon schauen, ob der beim Starten irgendetwas versucht. Vielleicht kann damit die Ursache weiter eingegrenzt werden.
Ansonsten manuell die Registry-Einträge vom Word löschen und schauen, ob das Problem ausgehend von der Registry kommt?
Wenn bspw. ein online UNC Pfad für weitere Templates auf einem Share abgerufen werden sollen und der nicht direkt per DNS erreichbar ist, könnte das zu deiner Beschreibung bzgl. DNS passen.
VG
1
Routet das VPN alle Daten durchs Firmennetz oder nur die, welche ins Firmennetz "gehören" ?
Die Frage deshalb, falls Word irgendwas ausserhalb des Firmennetzwerks anspricht, könnte das Einfluss haben.
Ich hatte auch schon, dass irgendwas versucht beim Starten die installierten Drucker abzufragen. Wenn da Drucker im Firmennetz dabei sind, die via VPN nicht erreichbar sind, könnte das ein Einfluss haben.
DNS ist bei VPN auch immer eine mögliche Fehlerquelle. Da kann schon mal was auf einen Timeout warten.
Die Frage deshalb, falls Word irgendwas ausserhalb des Firmennetzwerks anspricht, könnte das Einfluss haben.
Ich hatte auch schon, dass irgendwas versucht beim Starten die installierten Drucker abzufragen. Wenn da Drucker im Firmennetz dabei sind, die via VPN nicht erreichbar sind, könnte das ein Einfluss haben.
DNS ist bei VPN auch immer eine mögliche Fehlerquelle. Da kann schon mal was auf einen Timeout warten.
1
Zitat von @ITwissen:
Ich hatte auch schon, dass irgendwas versucht beim Starten die installierten Drucker abzufragen. Wenn da Drucker im Firmennetz dabei sind, die via VPN nicht erreichbar sind, könnte das ein Einfluss haben.
Ich hatte auch schon, dass irgendwas versucht beim Starten die installierten Drucker abzufragen. Wenn da Drucker im Firmennetz dabei sind, die via VPN nicht erreichbar sind, könnte das ein Einfluss haben.
Hi,
ich würde (ersteinmal) auf den Zug von ITwissen "aufspringen".
Prüfe ob auf der betroffenen Kiste ein Netzwerkdrucker der Standarddrucker ist. Falls ja, mach testweise mal einen lokalen (USB)Drucker zum Standardgerät. Gibt es keinen lokalen im Raum nimm einen pdf Drucker zum testen.
Ändert sich da etwas am Verhalten?
mfg
kowa
1
Oh mein Gott :D Leute, vielen Dank, es sieht aus, als wäre die Ursache gefunden und vor allem Dank eurer Hilfe
Habe die ganze Geschichte auf meinem eigenen Rechner mal probiert und da ist mir dann zufälligerweise aufgefallen, dass der Fehler bei mir nur bei Word-Dokumenten auftritt, wenn diese besondere Schriftarten verwenden (wir haben ca. zwei Dutzend "eigene" Schriftarten). Habe diesbezüglich schon mal was gelesen von Font Cache löschen.
Konnte dann aber, nach eurer vorgabe, gezielt hier mal versuchen vor dem VPN-Start den Standard-Drucker umzustellen (habe ihn mal testweise auf den Microsoft To PDF eingestellt). Und zack öffnen sich auch alle Dokumente mit besonderer Schriftart sofort und flüssig. Sorry, irgendwie hätte ich das vorher auch schon mal selbst probieren können.
Jetzt macht auch alles Sinn für mich :D Seit dem ich da bin, wird hier halt erst richtig der entsprechende Standard(Netzwerk)-Drucker eingestellt und auch ich habe erst damit begonnen diese Schriftarten immer direkt beim User zu installieren.
Muss das Ganze jetzt bei betroffenen Usern natürlich noch mal verifizieren, aber bei mir war es jetzt genau so bei fünf Tests hintereinander, denke mal, dass es das war dann.
Vielen Dank für Eure Hilfe! Falls jemand dahingehend einen Tipp hat, wie man das Ganze vielleicht auch so fixen kann, dass man einen richtigen Standard(Netzwerk)-Drucker einstellt und es trotz VPN und besonderer/externer Schriftart funktioniert würde ich mich natürlich freuen, aber das ist nicht so wichtig und kriege ich ja vielleicht dann auch mal selbst raus
Bezüglich dem Redirect vom gesamten Traffic könnte ich mir vorstellen, dass die vorletzte Zeile der VPN Config (#redirect-gateway) entsprechend wichtig ist, die da aktuell auskommentiert ist. Werde es mal ohne bzw. mit aktiver Zeile probieren.
Habe die ganze Geschichte auf meinem eigenen Rechner mal probiert und da ist mir dann zufälligerweise aufgefallen, dass der Fehler bei mir nur bei Word-Dokumenten auftritt, wenn diese besondere Schriftarten verwenden (wir haben ca. zwei Dutzend "eigene" Schriftarten). Habe diesbezüglich schon mal was gelesen von Font Cache löschen.
Konnte dann aber, nach eurer vorgabe, gezielt hier mal versuchen vor dem VPN-Start den Standard-Drucker umzustellen (habe ihn mal testweise auf den Microsoft To PDF eingestellt). Und zack öffnen sich auch alle Dokumente mit besonderer Schriftart sofort und flüssig. Sorry, irgendwie hätte ich das vorher auch schon mal selbst probieren können.
Jetzt macht auch alles Sinn für mich :D Seit dem ich da bin, wird hier halt erst richtig der entsprechende Standard(Netzwerk)-Drucker eingestellt und auch ich habe erst damit begonnen diese Schriftarten immer direkt beim User zu installieren.
Muss das Ganze jetzt bei betroffenen Usern natürlich noch mal verifizieren, aber bei mir war es jetzt genau so bei fünf Tests hintereinander, denke mal, dass es das war dann.
Vielen Dank für Eure Hilfe! Falls jemand dahingehend einen Tipp hat, wie man das Ganze vielleicht auch so fixen kann, dass man einen richtigen Standard(Netzwerk)-Drucker einstellt und es trotz VPN und besonderer/externer Schriftart funktioniert würde ich mich natürlich freuen, aber das ist nicht so wichtig und kriege ich ja vielleicht dann auch mal selbst raus
Bezüglich dem Redirect vom gesamten Traffic könnte ich mir vorstellen, dass die vorletzte Zeile der VPN Config (#redirect-gateway) entsprechend wichtig ist, die da aktuell auskommentiert ist. Werde es mal ohne bzw. mit aktiver Zeile probieren.