14
Einer von 4 RDP-Servern verliert Internetzugang
Guten Tag,
da unser IT-Dienstleister nicht tätig wird, versuche ich mein Glück bei euch. Wir haben für unsere 2019er-Umgebung zwei HyperV-Server laufen. Auf HyperV1 sind drei Server virtualisiert (File/DC, Exchange, Datev). Auf HyperV2 laufen vier RDP-Server (WTS 1 - 4) für die User. Ca. einmal pro Woche fällt auf WTS 2 für einige Stunden der Internetzugang aus. Bisher funkionierte es immer von alleine wieder, ohne Neustart oder sonstige Eingriffe. Soweit ich es nachvollziehen kann, laufen auf WTS 1 und 2 exakt diesselben Programme (auf 3 und 4 zusätzlich Datev).
Das Internet läuft über einen Router der Datev mit proxy zu deren RZ.
Hat jemand einen Tipp woran das liegen kann? Ich füge gern weitere Infos hinzu falls nötig und entschuldige mich im Voraus für meine Unkenntnis, bin kein gelernter Admin.
da unser IT-Dienstleister nicht tätig wird, versuche ich mein Glück bei euch. Wir haben für unsere 2019er-Umgebung zwei HyperV-Server laufen. Auf HyperV1 sind drei Server virtualisiert (File/DC, Exchange, Datev). Auf HyperV2 laufen vier RDP-Server (WTS 1 - 4) für die User. Ca. einmal pro Woche fällt auf WTS 2 für einige Stunden der Internetzugang aus. Bisher funkionierte es immer von alleine wieder, ohne Neustart oder sonstige Eingriffe. Soweit ich es nachvollziehen kann, laufen auf WTS 1 und 2 exakt diesselben Programme (auf 3 und 4 zusätzlich Datev).
Das Internet läuft über einen Router der Datev mit proxy zu deren RZ.
Hat jemand einen Tipp woran das liegen kann? Ich füge gern weitere Infos hinzu falls nötig und entschuldige mich im Voraus für meine Unkenntnis, bin kein gelernter Admin.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 571007
Url: https://administrator.de/contentid/571007
Ausgedruckt am: 24.11.2024 um 16:11 Uhr
14 Kommentare
Neuester Kommentar
Hi,
Warum nicht?
Das kann 1000 Gründe haben. Unmöglich, das ohne Analyse vor Ort einzugrenzen.
Ein paar aus der Nase gebohrt:
- Proxy fällt aus/ "will nicht"
- Proxy-Eintrag am Benutzerkonto oder in der Software falsch
- zeitweilig doppelte IP-Adresse
- Konto gesperrt
- Softwarefehler
- DNS-Problem
E.
Warum nicht?
Ca. einmal pro Woche fällt auf WTS 2 für einige Stunden der Internetzugang aus.
Tatsächlich der komplette Internetzugang für diesen Server? Oder nicht doch bloß ein bestimmtes Ziel, wovon Ihr aber abhängig seid?Das kann 1000 Gründe haben. Unmöglich, das ohne Analyse vor Ort einzugrenzen.
Ein paar aus der Nase gebohrt:
- Proxy fällt aus/ "will nicht"
- Proxy-Eintrag am Benutzerkonto oder in der Software falsch
- zeitweilig doppelte IP-Adresse
- Konto gesperrt
- Softwarefehler
- DNS-Problem
E.
Moin,
Welchen Teil des Wortes hat er nicht verstanden? Dienen oder leisten?
Das ist ja spannend, dass es sich von selbst behebt. Was heißt denn genau "das Internet fällt aus"?
Wenn der Fehler auftritt, dann gibst Du bitte Folgendes auf der Kommandozeile ein:
und postest die Ergebnisse hier.
Liebe Grüße
Erik
Welchen Teil des Wortes hat er nicht verstanden? Dienen oder leisten?
versuche ich mein Glück bei euch. Wir haben für unsere 2019er-Umgebung zwei HyperV-Server laufen. Auf HyperV1 sind drei Server virtualisiert (File/DC, Exchange, Datev). Auf HyperV2 laufen vier RDP-Server (WTS 1 - 4) für die User. Ca. einmal pro Woche fällt auf WTS 2 für einige Stunden der Internetzugang aus. Bisher funkionierte es immer von alleine wieder, ohne Neustart oder sonstige Eingriffe.
Das ist ja spannend, dass es sich von selbst behebt. Was heißt denn genau "das Internet fällt aus"?
Wenn der Fehler auftritt, dann gibst Du bitte Folgendes auf der Kommandozeile ein:
ping interne_IP_Adresse
ping www.spiegel.de
nslookup www.spiegel.de
ipconfig /allund postest die Ergebnisse hier.
Liebe Grüße
Erik
Moin,
nichts für ungut, aber mit den Informationen könnte ich als DL auch nicht weiterhelfen :/
Im Zweifel einfach mal vergleichen, was an WTS2 in Bezug auf Internet anders konfiguriert ist (Proxy/IP-Konfig etc.), als bei WTS1, 3 und 4, dazu muss man kein gelernter Admin sein, aufmerksames Lesen reicht ;)
VG
nichts für ungut, aber mit den Informationen könnte ich als DL auch nicht weiterhelfen :/
Im Zweifel einfach mal vergleichen, was an WTS2 in Bezug auf Internet anders konfiguriert ist (Proxy/IP-Konfig etc.), als bei WTS1, 3 und 4, dazu muss man kein gelernter Admin sein, aufmerksames Lesen reicht ;)
VG
Moin,
Als Dienstleister loggt man sich dann auf dem System ein oder fährt hin und beschafft sich die notwendigen Informationen. Die typische Fehlermeldung meiner Kollegen vor Ort ist: Das Internet ist kaputt.
Liebe Grüße
Erik
Zitat von @chgorges:
nichts für ungut, aber mit den Informationen könnte ich als DL auch nicht weiterhelfen :/
nichts für ungut, aber mit den Informationen könnte ich als DL auch nicht weiterhelfen :/
Als Dienstleister loggt man sich dann auf dem System ein oder fährt hin und beschafft sich die notwendigen Informationen. Die typische Fehlermeldung meiner Kollegen vor Ort ist: Das Internet ist kaputt.
Liebe Grüße
Erik
Vielen Dank für die Antworten!
Programme die ins Internet gehen, können keine Verbindung aufbauen bis auf eines, soweit ich bisher testen konnte. Ich habe den proxy im Verdacht, da in dem funktionierenden Programm (es kann mit seinem Update-Server kommunizieren) ist der Proxy anders konfiguriert.
Die Einstellungen am Server sind aber korrekt und gleich denen auf den anderen Servern. Datev stellt extra ein Tool zur Verfügung, dass den Proxy einträgt. Hier die gewünschten Ergebnisse.
C:\Users\administrator.DUDEN>ping 192.168.100.7
Ping wird ausgeführt für 192.168.100.7 mit 32 Bytes Daten:
Antwort von 192.168.100.7: Bytes=32 Zeit=1ms TTL=128
Antwort von 192.168.100.7: Bytes=32 Zeit=1ms TTL=128
Antwort von 192.168.100.7: Bytes=32 Zeit=1ms TTL=128
Antwort von 192.168.100.7: Bytes=32 Zeit=1ms TTL=128
Ping-Statistik für 192.168.100.7:
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 1ms, Maximum = 1ms, Mittelwert = 1ms
C:\Users\administrator.DUDEN>ping www.spiegel.de
Ping wird ausgeführt für aacfb9d106f4.link11.de [128.65.210.180] mit 32 Bytes Daten:
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Ping-Statistik für 128.65.210.180:
Pakete: Gesendet = 4, Empfangen = 0, Verloren = 4
(100% Verlust),
C:\Users\administrator.DUDEN>nslookup www.spiegel.de
Server: filesrv.duden.lokal
Address: 192.168.100.1
Nicht autorisierende Antwort:
Name: aacfb9d106f4.link11.de
Addresses: 128.65.210.185
128.65.210.184
128.65.210.182
128.65.210.181
128.65.210.183
128.65.210.180
Aliases: www.spiegel.de
C:\Users\administrator.DUDEN>ipconfig /all
Windows-IP-Konfiguration
Hostname . . . . . . . . . . . . : WTS2
Primäres DNS-Suffix . . . . . . . : duden.lokal
Knotentyp . . . . . . . . . . . . : Hybrid
IP-Routing aktiviert . . . . . . : Nein
WINS-Proxy aktiviert . . . . . . : Nein
DNS-Suffixsuchliste . . . . . . . : duden.lokal
Ethernet-Adapter Ethernet:
Verbindungsspezifisches DNS-Suffix:
Beschreibung. . . . . . . . . . . : Microsoft Hyper-V Network Adapter
Physische Adresse . . . . . . . . : 00-15-5D-01-6B-01
DHCP aktiviert. . . . . . . . . . : Nein
Autokonfiguration aktiviert . . . : Ja
Verbindungslokale IPv6-Adresse . : fe80::f444:7844:7563:8bbc%12(Bevorzugt)
IPv4-Adresse . . . . . . . . . . : 192.168.100.5(Bevorzugt)
Subnetzmaske . . . . . . . . . . : 255.255.255.0
Standardgateway . . . . . . . . . : 192.168.100.250
DHCPv6-IAID . . . . . . . . . . . : 100668765
DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-25-68-0E-DF-00-15-5D-01-6B-01
DNS-Server . . . . . . . . . . . : 192.168.100.1
NetBIOS über TCP/IP . . . . . . . : Aktiviert
Nun ja, ich denke es ist ihr Job, die Infos zu beschaffen, Zugang haben sie.
Tja, wenn ich das wüsste. Keine Zeit, wichtigere Kunden? Wenn jemand in der Region zwischen Bremen und Hamburg einen Dienstleister empfehlen kann, bin ich ganz Ohr.
Zitat von @erikro:
Das ist ja spannend, dass es sich von selbst behebt. Was heißt denn genau "das Internet fällt aus"?
Wenn der Fehler auftritt, dann gibst Du bitte Folgendes auf der Kommandozeile ein:
und postest die Ergebnisse hier.
Liebe Grüße
Erik
Das ist ja spannend, dass es sich von selbst behebt. Was heißt denn genau "das Internet fällt aus"?
Wenn der Fehler auftritt, dann gibst Du bitte Folgendes auf der Kommandozeile ein:
> ping interne_IP_Adresse
> ping www.spiegel.de
> nslookup www.spiegel.de
> ipconfig /all
> und postest die Ergebnisse hier.
Liebe Grüße
Erik
Programme die ins Internet gehen, können keine Verbindung aufbauen bis auf eines, soweit ich bisher testen konnte. Ich habe den proxy im Verdacht, da in dem funktionierenden Programm (es kann mit seinem Update-Server kommunizieren) ist der Proxy anders konfiguriert.
Die Einstellungen am Server sind aber korrekt und gleich denen auf den anderen Servern. Datev stellt extra ein Tool zur Verfügung, dass den Proxy einträgt. Hier die gewünschten Ergebnisse.
C:\Users\administrator.DUDEN>ping 192.168.100.7
Ping wird ausgeführt für 192.168.100.7 mit 32 Bytes Daten:
Antwort von 192.168.100.7: Bytes=32 Zeit=1ms TTL=128
Antwort von 192.168.100.7: Bytes=32 Zeit=1ms TTL=128
Antwort von 192.168.100.7: Bytes=32 Zeit=1ms TTL=128
Antwort von 192.168.100.7: Bytes=32 Zeit=1ms TTL=128
Ping-Statistik für 192.168.100.7:
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 1ms, Maximum = 1ms, Mittelwert = 1ms
C:\Users\administrator.DUDEN>ping www.spiegel.de
Ping wird ausgeführt für aacfb9d106f4.link11.de [128.65.210.180] mit 32 Bytes Daten:
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Ping-Statistik für 128.65.210.180:
Pakete: Gesendet = 4, Empfangen = 0, Verloren = 4
(100% Verlust),
C:\Users\administrator.DUDEN>nslookup www.spiegel.de
Server: filesrv.duden.lokal
Address: 192.168.100.1
Nicht autorisierende Antwort:
Name: aacfb9d106f4.link11.de
Addresses: 128.65.210.185
128.65.210.184
128.65.210.182
128.65.210.181
128.65.210.183
128.65.210.180
Aliases: www.spiegel.de
C:\Users\administrator.DUDEN>ipconfig /all
Windows-IP-Konfiguration
Hostname . . . . . . . . . . . . : WTS2
Primäres DNS-Suffix . . . . . . . : duden.lokal
Knotentyp . . . . . . . . . . . . : Hybrid
IP-Routing aktiviert . . . . . . : Nein
WINS-Proxy aktiviert . . . . . . : Nein
DNS-Suffixsuchliste . . . . . . . : duden.lokal
Ethernet-Adapter Ethernet:
Verbindungsspezifisches DNS-Suffix:
Beschreibung. . . . . . . . . . . : Microsoft Hyper-V Network Adapter
Physische Adresse . . . . . . . . : 00-15-5D-01-6B-01
DHCP aktiviert. . . . . . . . . . : Nein
Autokonfiguration aktiviert . . . : Ja
Verbindungslokale IPv6-Adresse . : fe80::f444:7844:7563:8bbc%12(Bevorzugt)
IPv4-Adresse . . . . . . . . . . : 192.168.100.5(Bevorzugt)
Subnetzmaske . . . . . . . . . . : 255.255.255.0
Standardgateway . . . . . . . . . : 192.168.100.250
DHCPv6-IAID . . . . . . . . . . . : 100668765
DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-25-68-0E-DF-00-15-5D-01-6B-01
DNS-Server . . . . . . . . . . . : 192.168.100.1
NetBIOS über TCP/IP . . . . . . . : Aktiviert
Zitat von @chgorges:
nichts für ungut, aber mit den Informationen könnte ich als DL auch nicht weiterhelfen :/
nichts für ungut, aber mit den Informationen könnte ich als DL auch nicht weiterhelfen :/
Nun ja, ich denke es ist ihr Job, die Infos zu beschaffen, Zugang haben sie.
Tja, wenn ich das wüsste. Keine Zeit, wichtigere Kunden? Wenn jemand in der Region zwischen Bremen und Hamburg einen Dienstleister empfehlen kann, bin ich ganz Ohr.
Wenn der Internetzugang über Proxy erfolgt, dann ist der Ping- und NSLOOKUP-Test für die Diagnose nutzlos.
Moin,
Moment, das ist ein ganz anderes Fehlerbild als "der Internetzugang fällt aus". Wenn eine Anwendung Zugang hat, dann funktioniert der Zugang vom Prinzip.
Nun wird's schwer:
Manchmal funktioniert der Zugang bei allen gewünschten Anwendungen. Also ist die Konfiguration vom Prinzip richtig. Sonst würde es via Proxy nie funktionieren. Also muss es ein Fehler sein, der von einer Anwendung ausgelöst wird oder von irgend einem anderen Ereignis.
Nach gewisser Zeit funktioniert es wieder ohne Eingriff. Das spricht dafür, dass der Zugang für die Anwendungen temporär blockiert wird. Da stellt sich mir die Frage: Welches Protokoll benutzt die Anwendung, um sich mit dem Update-Server zu verbinden? Kann auf Email zugegriffen werden? Welche Fehlermeldung gibt der Browser aus?
Insgesamt wirklich ein Vor-Ort-Problem.
Liebe Grüße
Erik
Zitat von @Alxwgnr:
Programme die ins Internet gehen, können keine Verbindung aufbauen bis auf eines, soweit ich bisher testen konnte. Ich habe den proxy im Verdacht, da in dem funktionierenden Programm (es kann mit seinem Update-Server kommunizieren) ist der Proxy anders konfiguriert.
Die Einstellungen am Server sind aber korrekt und gleich denen auf den anderen Servern. Datev stellt extra ein Tool zur Verfügung, dass den Proxy einträgt. Hier die gewünschten Ergebnisse.
Programme die ins Internet gehen, können keine Verbindung aufbauen bis auf eines, soweit ich bisher testen konnte. Ich habe den proxy im Verdacht, da in dem funktionierenden Programm (es kann mit seinem Update-Server kommunizieren) ist der Proxy anders konfiguriert.
Die Einstellungen am Server sind aber korrekt und gleich denen auf den anderen Servern. Datev stellt extra ein Tool zur Verfügung, dass den Proxy einträgt. Hier die gewünschten Ergebnisse.
Moment, das ist ein ganz anderes Fehlerbild als "der Internetzugang fällt aus". Wenn eine Anwendung Zugang hat, dann funktioniert der Zugang vom Prinzip.
Nun wird's schwer:
Manchmal funktioniert der Zugang bei allen gewünschten Anwendungen. Also ist die Konfiguration vom Prinzip richtig. Sonst würde es via Proxy nie funktionieren. Also muss es ein Fehler sein, der von einer Anwendung ausgelöst wird oder von irgend einem anderen Ereignis.
Nach gewisser Zeit funktioniert es wieder ohne Eingriff. Das spricht dafür, dass der Zugang für die Anwendungen temporär blockiert wird. Da stellt sich mir die Frage: Welches Protokoll benutzt die Anwendung, um sich mit dem Update-Server zu verbinden? Kann auf Email zugegriffen werden? Welche Fehlermeldung gibt der Browser aus?
Insgesamt wirklich ein Vor-Ort-Problem.
Liebe Grüße
Erik
Zitat von @emeriks:
Wenn der Internetzugang über Proxy erfolgt, dann ist der Ping- und NSLOOKUP-Test für die Diagnose nutzlos.
Wenn der Internetzugang über Proxy erfolgt, dann ist der Ping- und NSLOOKUP-Test für die Diagnose nutzlos.
Nicht ganz. Hätte der Ping funktioniert, wüssten wir, dass er in dem Moment den Proxy nicht nutzt, sondern direkt ins Internet geht.
Zitat von @erikro:
Nicht ganz. Hätte der Ping funktioniert, wüssten wir, dass er in dem Moment den Proxy nicht nutzt, sondern direkt ins Internet geht.
Dann müsste das Wissen aber auch wirklich wollen. So richtig! Nur dann.Nicht ganz. Hätte der Ping funktioniert, wüssten wir, dass er in dem Moment den Proxy nicht nutzt, sondern direkt ins Internet geht.
Moin,
das hatte ich bei unseren 2 Datev WTS (als VMs auf Hyper-V) im DATEVnet Umfeld ebenfalls; sporadisch verweigert immer mal wieder einer der Server das normale Surfen, während die Kommunikation zum Datev-RZ trotzdem weiterhin funktioniert. Nach reboot des Servers (passiert automatisch täglich) war der Spuk dann vorbei.
Da manche user aber nicht bis zu reboot warten konnten, war mein workaround am betroffenen Server den DATEVnet Proxy-Server zu wechseln - vom "frei" zugänglichen Proxy-Server win-proxy.services.datevnet.de:8880 auf den Proxy mit Authentifizierung proxy.services.datevnet.de:8080 bzw. umgekehrt, wenn es der freie Proxy-Server war, der streikte.
Eine Lösung habe ich nie gefunden, auch unsere Servicepartner hatten keine Lösung parat; ich habe es aber auch nie konsequent verfolgt, da wir zu dem Zeitpunkt als die Probleme begannen aufzutreten bereits dabei waren uns von DATEVnet zu verabschieden.
Sorry, dass ich keine andere Lösung als den workaround anbieten kann ...
Edit: Typo
das hatte ich bei unseren 2 Datev WTS (als VMs auf Hyper-V) im DATEVnet Umfeld ebenfalls; sporadisch verweigert immer mal wieder einer der Server das normale Surfen, während die Kommunikation zum Datev-RZ trotzdem weiterhin funktioniert. Nach reboot des Servers (passiert automatisch täglich) war der Spuk dann vorbei.
Da manche user aber nicht bis zu reboot warten konnten, war mein workaround am betroffenen Server den DATEVnet Proxy-Server zu wechseln - vom "frei" zugänglichen Proxy-Server win-proxy.services.datevnet.de:8880 auf den Proxy mit Authentifizierung proxy.services.datevnet.de:8080 bzw. umgekehrt, wenn es der freie Proxy-Server war, der streikte.
Eine Lösung habe ich nie gefunden, auch unsere Servicepartner hatten keine Lösung parat; ich habe es aber auch nie konsequent verfolgt, da wir zu dem Zeitpunkt als die Probleme begannen aufzutreten bereits dabei waren uns von DATEVnet zu verabschieden.
Sorry, dass ich keine andere Lösung als den workaround anbieten kann ...
Edit: Typo
Nabend,
ich hatte so einen Fehler ebenfalls mal im RZ ebenfalls in Verbing mit Hyper-V. Hier war dann schlussendlich nich der Fehler in der VM sondern ian der virtuellen Netzwerkkarte. Stichwort Duplicated MAC. Hier haben sich die Hosts nicht richtig verhalten und haben einfach mal ein paar MAC Adressen doppelt vergeben.
Prüfe mal dein Netzwerk ob das hier auch der Fall ist.
Gruß
ich hatte so einen Fehler ebenfalls mal im RZ ebenfalls in Verbing mit Hyper-V. Hier war dann schlussendlich nich der Fehler in der VM sondern ian der virtuellen Netzwerkkarte. Stichwort Duplicated MAC. Hier haben sich die Hosts nicht richtig verhalten und haben einfach mal ein paar MAC Adressen doppelt vergeben.
Prüfe mal dein Netzwerk ob das hier auch der Fall ist.
Gruß
Vielen dank für die weiteren Antworten! Gestern war obendrein noch längere Zeit unser Anschluss gestört, Montag gehört abgeschafft. 
Passend zu dem Hinweis von dnotice verwendet die Anwendung den Proxy mit Authentifizierung via FTP-Protokoll.
Auf Email kann weiter zugegriffen werden, da der Exchange Server das Problem nicht hat. Wie gesagt nur WTS 2 ist (bisher) betroffen. Der Browser sagt "proxy antwortet nicht".
Zitat von @Fabezz:
Nabend,
ich hatte so einen Fehler ebenfalls mal im RZ ebenfalls in Verbing mit Hyper-V. Hier war dann schlussendlich nich der Fehler in der VM sondern ian der virtuellen Netzwerkkarte. Stichwort Duplicated MAC. Hier haben sich die Hosts nicht richtig verhalten und haben einfach mal ein paar MAC Adressen doppelt vergeben.
Prüfe mal dein Netzwerk ob das hier auch der Fall ist.
Danke für den Tipp, werden wir beim nächsten Mal prüfen. Aktuell geht es wieder. Nabend,
ich hatte so einen Fehler ebenfalls mal im RZ ebenfalls in Verbing mit Hyper-V. Hier war dann schlussendlich nich der Fehler in der VM sondern ian der virtuellen Netzwerkkarte. Stichwort Duplicated MAC. Hier haben sich die Hosts nicht richtig verhalten und haben einfach mal ein paar MAC Adressen doppelt vergeben.
Prüfe mal dein Netzwerk ob das hier auch der Fall ist.
Zitat von @dnotice:
Da manche user aber nicht bis zu reboot warten konnten, war mein workaround am betroffenen Server den DATEVnet Proxy-Server zu wechseln - vom "frei" zugänglichen Proxy-Server win-proxy.services.datevnet.de:8880 auf den Proxy mit Authentifizierung proxy.services.datevnet.de:8080 bzw. umgekehrt, wenn es der freie Proxy-Server war, der streikte.
Die Geschichte macht ja nicht gerade Mut, aber wenn wir keine Lösung finden, werde ich das auch so machen. Dein Erfahrungsbericht liefert mir jedenfalls Argumente gegen DatevNet, ich habe schon häufiger versucht, die Chefetage davon zu überzeugen das abzuschaffen.Da manche user aber nicht bis zu reboot warten konnten, war mein workaround am betroffenen Server den DATEVnet Proxy-Server zu wechseln - vom "frei" zugänglichen Proxy-Server win-proxy.services.datevnet.de:8880 auf den Proxy mit Authentifizierung proxy.services.datevnet.de:8080 bzw. umgekehrt, wenn es der freie Proxy-Server war, der streikte.
Zitat von @erikro:
Nach gewisser Zeit funktioniert es wieder ohne Eingriff. Das spricht dafür, dass der Zugang für die Anwendungen temporär blockiert wird. Da stellt sich mir die Frage: Welches Protokoll benutzt die Anwendung, um sich mit dem Update-Server zu verbinden? Kann auf Email zugegriffen werden? Welche Fehlermeldung gibt der Browser aus?
Nach gewisser Zeit funktioniert es wieder ohne Eingriff. Das spricht dafür, dass der Zugang für die Anwendungen temporär blockiert wird. Da stellt sich mir die Frage: Welches Protokoll benutzt die Anwendung, um sich mit dem Update-Server zu verbinden? Kann auf Email zugegriffen werden? Welche Fehlermeldung gibt der Browser aus?
Passend zu dem Hinweis von dnotice verwendet die Anwendung den Proxy mit Authentifizierung via FTP-Protokoll.
Auf Email kann weiter zugegriffen werden, da der Exchange Server das Problem nicht hat. Wie gesagt nur WTS 2 ist (bisher) betroffen. Der Browser sagt "proxy antwortet nicht".
ich kenne so ein Verhalten bei einer doppelten IP im Netz. Da war der Server nur sporadisch funktionabel.
Zitat von @Alxwgnr:
Die Geschichte macht ja nicht gerade Mut, aber wenn wir keine Lösung finden, werde ich das auch so machen. Dein Erfahrungsbericht liefert mir jedenfalls Argumente gegen DatevNet, ich habe schon häufiger versucht, die Chefetage davon zu überzeugen das abzuschaffen.
Die Geschichte macht ja nicht gerade Mut, aber wenn wir keine Lösung finden, werde ich das auch so machen. Dein Erfahrungsbericht liefert mir jedenfalls Argumente gegen DatevNet, ich habe schon häufiger versucht, die Chefetage davon zu überzeugen das abzuschaffen.
Moin,
besonders bei den Kosten von DatevNet.
Da kann ich locker eine Firewall inklusive 3 Jahre Fuktions- und Supportpaket kaufen und fahre immer noch günstiger ... die Trafficpreise bei DatevNet sind ja nur utopisch.
Schau Dir - falls Du Zugriff auf die Datev Rechnungen hast - einfach mal die Preise für das ganze DatevNet Paket an (also Routermiete, DatevNet Lizenzkosten, Traffickosten) und rechne das gegen die Firewall Deines Vertrauens. Bei dem Firewall Angebot, das ich bekommen hatte, sprach das deutlich gegen DatevNet.
Laters
