Verbindungen mit UNC-Pfad auf Windows-Server

[Walter Cordes]

brauchen lange, lange, lange,...

Hallo Allerseits,

wir haben auf allen betroffenen AP den Netware-Client 4.91, Sp2 installiert.
Ein Programm (Saperion) auf dem Client verbindet sich beim Aufruf mit einem
Win2k-Server und sucht dort nach Programm-updates. Dazu benutzt es einen
INI-Eintrag: \\servername\freigabe
Das Programm braucht zum Starten etwa 20 Minuten.
Bei gleicher Konfiguration des Arbeitsplatzes - jedoch ohne Netware-Client
(!!) - startet das Programm sofort.
Das sniffen zeigt, daß die Clientanfrage nach dem Servernamen immer wieder
im an alle Netware-Server (6.5 SP4) gerichtet wird.
Kurzum, gibt es Einstellungen am NwClient, die die Verzögerung (20 Minuten)
verursachen?

Der Vollständigkeit halber: In der Hosts des Clients ist ein Eintrag für den
Server gemacht worden - keine Verbesserung. In der INI wurde \\servername
durch \\ip-adresse ersetzt - keine Verbesserung.
Wenn ich aber ein Laufwerk auf die Serverfreigabe mappe (und damit wieder
einen Laufwerksbuchstaben opfere) klappt der Programmaufruf sofort. Also
genauso schnell, als wenn gar kein Netware Client installiert wäre. Die INI
behält bei dieser "Lösung" den ursprünglichen Eintrag \\servername\freigabe
.

Es erscheint so, also ob der Netware Client ein Problem mit dem Zugriff auf
UNC-Pfade hat.

Weiß jemand Rat?

Gruß,
Walter

[t***@myrealbox.com]

Das sollte mit einem aktuellen Client eigentlich nicht mehr passieren,
da diese eine entsprechende Filterfunktion haben. Passiert das auch auf
frisch installierten Maschinen?

Falls nicht, kannst du durch einen Registry-Eintrag dem Client das
kontaktieren diverser MS-Freigaben abgewöhnen:
HKLM\SYSTEM\CurrentControlSet\Services\NetwareWorkstation\Parameters

Neuer Wert: BadServer
Typ: REG_MULTI_SZ
Werte: Server-IP oder Servername, nach jedem Eintrag mit Return
abschließen.

Das führt dann für den NW-Client zu einem sofortigen Timeout und
Übergabe an den nächsten Network-Provider, in deinem Fall den
MS-Client.

http://www.novell.com/coolsolutions/appnote/620.html

Thorsten

Post by Walter Cordes
brauchen lange, lange, lange,...
Hallo Allerseits,
wir haben auf allen betroffenen AP den Netware-Client 4.91, Sp2 installiert.
Ein Programm (Saperion) auf dem Client verbindet sich beim Aufruf mit einem
Win2k-Server und sucht dort nach Programm-updates. Dazu benutzt es einen
INI-Eintrag: \\servername\freigabe
Das Programm braucht zum Starten etwa 20 Minuten.
Bei gleicher Konfiguration des Arbeitsplatzes - jedoch ohne Netware-Client
(!!) - startet das Programm sofort.
Das sniffen zeigt, daß die Clientanfrage nach dem Servernamen immer wieder
im an alle Netware-Server (6.5 SP4) gerichtet wird.
Kurzum, gibt es Einstellungen am NwClient, die die Verzögerung (20 Minuten)
verursachen?
Der Vollständigkeit halber: In der Hosts des Clients ist ein Eintrag für den
Server gemacht worden - keine Verbesserung. In der INI wurde \\servername
durch \\ip-adresse ersetzt - keine Verbesserung.
Wenn ich aber ein Laufwerk auf die Serverfreigabe mappe (und damit wieder
einen Laufwerksbuchstaben opfere) klappt der Programmaufruf sofort. Also
genauso schnell, als wenn gar kein Netware Client installiert wäre. Die INI
behält bei dieser "Lösung" den ursprünglichen Eintrag \\servername\freigabe
.
Es erscheint so, also ob der Netware Client ein Problem mit dem Zugriff auf
UNC-Pfade hat.
Weiß jemand Rat?
Gruß,
Walter

[Walter Cordes]

Hallo Thorsten, hallo Hans!
danke für Eure Beiträge. Der BadServer-Eintrag führt leider nicht zu einer
Beschleunigung des Programmstarts... Leider hat das Löschen des Reg-Eintrags
auch keine Auswirkungen gehabt.

Bin weiterhin dran. Christophs Beitrag weiter unten läßt mich nun nwfilter
und slp prüfen.
Gruß,
Walter

<***@myrealbox.com> schrieb im Newsbeitrag news:***@j55g2000cwa.googlegroups.com...
Das sollte mit einem aktuellen Client eigentlich nicht mehr passieren,
da diese eine entsprechende Filterfunktion haben. Passiert das auch auf
frisch installierten Maschinen?

Falls nicht, kannst du durch einen Registry-Eintrag dem Client das
kontaktieren diverser MS-Freigaben abgewöhnen:
HKLM\SYSTEM\CurrentControlSet\Services\NetwareWorkstation\Parameters

Neuer Wert: BadServer
Typ: REG_MULTI_SZ
Werte: Server-IP oder Servername, nach jedem Eintrag mit Return
abschließen.

Das führt dann für den NW-Client zu einem sofortigen Timeout und
Übergabe an den nächsten Network-Provider, in deinem Fall den
MS-Client.

http://www.novell.com/coolsolutions/appnote/620.html

Thorsten

Post by Walter Cordes
brauchen lange, lange, lange,...
Hallo Allerseits,
wir haben auf allen betroffenen AP den Netware-Client 4.91, Sp2 installiert.
Ein Programm (Saperion) auf dem Client verbindet sich beim Aufruf mit einem
Win2k-Server und sucht dort nach Programm-updates. Dazu benutzt es einen
INI-Eintrag: \\servername\freigabe
Das Programm braucht zum Starten etwa 20 Minuten.
Bei gleicher Konfiguration des Arbeitsplatzes - jedoch ohne Netware-Client
(!!) - startet das Programm sofort.
Das sniffen zeigt, daß die Clientanfrage nach dem Servernamen immer wieder
im an alle Netware-Server (6.5 SP4) gerichtet wird.
Kurzum, gibt es Einstellungen am NwClient, die die Verzögerung (20 Minuten)
verursachen?
Der Vollständigkeit halber: In der Hosts des Clients ist ein Eintrag für den
Server gemacht worden - keine Verbesserung. In der INI wurde \\servername
durch \\ip-adresse ersetzt - keine Verbesserung.
Wenn ich aber ein Laufwerk auf die Serverfreigabe mappe (und damit wieder
einen Laufwerksbuchstaben opfere) klappt der Programmaufruf sofort. Also
genauso schnell, als wenn gar kein Netware Client installiert wäre. Die INI
behält bei dieser "Lösung" den ursprünglichen Eintrag
\\servername\freigabe
.
Es erscheint so, also ob der Netware Client ein Problem mit dem Zugriff auf
UNC-Pfade hat.
Weiß jemand Rat?
Gruß,
Walter

[Hans Nellissen]

Starte Regedit
gehe zu:
"Hkey_Local_Machine\Software\
Microsoft\Windows\CurrentVersion\Explorer\RemoteComputer\NameSpace"
suche den Schluessel
"{D6277990-4C6A-11CF-8D87-00AA0060F5BF}"

sichere den Schluesselinhalt.
Loesche den Schluessel.
Starte den Rechner neu.

Problem sollte gegessen sein.

Hans

[Christoph Maercker]

Hallo Hans,

Post by Hans Nellissen
"Hkey_Local_Machine\Software\
Microsoft\Windows\CurrentVersion\Explorer\RemoteComputer\NameSpace"
"{D6277990-4C6A-11CF-8D87-00AA0060F5BF}"

Welche Bedeutung hat dieser Schlüssel? ^
In meinem System (W2k/SP4 mit Client v4.83/SP3) existiert der nicht.

Post by Hans Nellissen
Problem sollte gegessen sein.

Ob dem wirklich so ist, würde mich allerdings brennend interessieren.

[Rudolf Thilo]

Post by Hans Nellissen
D6277990-4C6A-11CF-8D87-00AA0060F5BF

Google spuckt dazu z.b. den hier aus:

http://winhlp.com/WxSlowNetworkBrowsing.htm


Schönen Gruß, Rudi.

[t***@myrealbox.com]

Ich denke nicht, dass dieser Schlüssel passt, denn:

- Dieses Verhalten tritt AFAIK auf, wenn man _nur_ den Rechnernamen
aufruft. Hier wird direkt eine Ressource angesprochen
(\\server\freugabe).

- Der OP sagte, er habe bei einem Sniff gesehen, dass alle Anfragen an
den NW-Server gehen. Kann also nicht eine Fehleinstellung des
Win32-Netzclients sein.

Thorsten

Post by Rudolf Thilo

Post by Hans Nellissen
D6277990-4C6A-11CF-8D87-00AA0060F5BF

http://winhlp.com/WxSlowNetworkBrowsing.htm
Schönen Gruß, Rudi.
--
IT-Beratung Rudolf Thilo
Schweinfurter Str. 131
97464 Niederwerrn
t: +49 (0)9721/6464840
f: +49 (0)9721/6464841
m: +49(0)171/685 9 685

[Rudolf Thilo]

Hallo.

- Dieses Verhalten tritt AFAIK auf, wenn man nur den Rechnernamen
aufruft. Hier wird direkt eine Ressource angesprochen
(\\server\freugabe).
- Der OP sagte, er habe bei einem Sniff gesehen, dass alle Anfragen an
den NW-Server gehen. Kann also nicht eine Fehleinstellung des
Win32-Netzclients sein.

Hallo: Ich habe nicht behauptet, dass der Schlüssel passt, nur eine
Beschreibungs-URL gepostet :)


Schönen Gruß, Rudi.

[Christoph Maercker]

Post by Rudolf Thilo

Post by Hans Nellissen
D6277990-4C6A-11CF-8D87-00AA0060F5BF

http://winhlp.com/WxSlowNetworkBrowsing.htm

Mann, is Google schlau!

Könnte mit LoadWC.exe zu tun haben. Dessen Deaktivierung wurde ja schon
im Performance-Tuning für Client32 empfohlen. Soviel ich weiß, sucht das
Teil nach irgendwelchen Tasks im Netzwerk.

[Rudolf Thilo]

Post by Christoph Maercker
Mann, is Google schlau!

LOL, erste *ECHTE* KI von Christoph entdeckt. ;-)


Beiname "KI-Columbus" gefällig? ;-))))


Schönen Gruß, Rudi.

[Christoph Maercker]

Hallo,

Post by Walter Cordes
wir haben auf allen betroffenen AP den Netware-Client 4.91, Sp2 installiert.

Also mit Filterdriver.

Post by Walter Cordes
Ein Programm (Saperion) auf dem Client verbindet sich beim Aufruf mit einem
Win2k-Server und sucht dort nach Programm-updates. Dazu benutzt es einen
INI-Eintrag: \\servername\freigabe
Das Programm braucht zum Starten etwa 20 Minuten.
Bei gleicher Konfiguration des Arbeitsplatzes - jedoch ohne Netware-Client
(!!) - startet das Programm sofort.
Das sniffen zeigt, daß die Clientanfrage nach dem Servernamen immer wieder
an alle Netware-Server (6.5 SP4) gerichtet wird.

*Nur* an die NetWare-Server, an die Windows-Server überhaupt nicht?
*Was* für Anfragen sind es? NDS, DNS, SLP oder wird gar WINS bei
NetWare-Server angefordert?

Post by Walter Cordes
Kurzum, gibt es Einstellungen am NwClient, die die Verzögerung (20 Minuten)
verursachen?

Stichwort Name Services: SLP, NDS, DNS, WINS. Wenn davon auch nur eines
falsch konfiguriert ist, gibt's Ärger.

Post by Walter Cordes
Der Vollständigkeit halber: In der Hosts des Clients ist ein Eintrag für den
Server gemacht worden - keine Verbesserung. In der INI wurde \\servername
durch \\ip-adresse ersetzt - keine Verbesserung.

Ein DNS-Problem ist es also eher nicht.

Post by Walter Cordes
Wenn ich aber ein Laufwerk auf die Serverfreigabe mappe (und damit wieder
einen Laufwerksbuchstaben opfere) klappt der Programmaufruf sofort. Also
genauso schnell, als wenn gar kein Netware Client installiert wäre. Die INI
behält bei dieser "Lösung" den ursprünglichen Eintrag \\servername\freigabe

Also merkt das System, dass ein Drive-Mapping zur betr. Resource
existiert und ignoriert den UNC-Pfad? Sehr seltsam.

Post by Walter Cordes
Es erscheint so, also ob der Netware Client ein Problem mit dem Zugriff auf
UNC-Pfade hat.

Dank Filterdriver hat er eigentlich keins mehr. Prüfe bitte mal, ob der
UNC-Path-Filter (log. Device NWFILTER) wirklich läuft.

[Walter Cordes]

Hallo Christoph,

nwfilter.sys Hm. Ein kurzer Exkurs: Die Mehrzahl unserer AP habe ich mittels
Zenworks-Imaging verteilt. Nachdem das Image vom Server auf die
Ziel-Hardware kopiert wurde, startete sysprep. Sysprep fügte die
Arbeitsplätze dann einer Domäne hinzu. Dies funktionierte damals nicht, wenn
sich die nwfilter.sys schon in C.\windows\system32\netware befand. Ich
benannte die nwfilter.sys vor der Verteilung des Images demzufolge in
irgendwas.sys um. Nach der Verteilung und dem joindomain Befehl wurde die
irgendwas.sys wieder in nwfilter.sys zurückbenannt. - Und alles schien gut
zu sein - .
Kurzum, kann ich, wie Du unten schriebst, die Funktion von nwfilter testen?
Wie - ganz demütig - geht das?

Außerdem kann es ein Problem mit SLP geben, da die SLP Konfiguration nur in
einem Subnetz per DHCP verteilt wird. Es gibt aber noch andere Subnetze mit
statischer Adressierung. Da muß ich gleich noch mal draufschauen.

Ich bin also noch dran und danke Dir und allen anderen für Eure Beiträge.

Wenn ich eine Lösung habe, dann werde ich sie natürlich posten.

Walter

Post by Christoph Maercker
Hallo,

Post by Walter Cordes
wir haben auf allen betroffenen AP den Netware-Client 4.91, Sp2 installiert.

Also mit Filterdriver.

Post by Walter Cordes
Ein Programm (Saperion) auf dem Client verbindet sich beim Aufruf mit
einem Win2k-Server und sucht dort nach Programm-updates. Dazu benutzt es
einen INI-Eintrag: \\servername\freigabe
Das Programm braucht zum Starten etwa 20 Minuten.
Bei gleicher Konfiguration des Arbeitsplatzes - jedoch ohne
Netware-Client (!!) - startet das Programm sofort.
Das sniffen zeigt, daß die Clientanfrage nach dem Servernamen immer
wieder an alle Netware-Server (6.5 SP4) gerichtet wird.

*Nur* an die NetWare-Server, an die Windows-Server überhaupt nicht?
*Was* für Anfragen sind es? NDS, DNS, SLP oder wird gar WINS bei
NetWare-Server angefordert?

Post by Walter Cordes
Kurzum, gibt es Einstellungen am NwClient, die die Verzögerung (20
Minuten) verursachen?

Stichwort Name Services: SLP, NDS, DNS, WINS. Wenn davon auch nur eines
falsch konfiguriert ist, gibt's Ärger.

Post by Walter Cordes
Der Vollständigkeit halber: In der Hosts des Clients ist ein Eintrag für
den Server gemacht worden - keine Verbesserung. In der INI wurde
\\servername durch \\ip-adresse ersetzt - keine Verbesserung.

Ein DNS-Problem ist es also eher nicht.

Post by Walter Cordes
Wenn ich aber ein Laufwerk auf die Serverfreigabe mappe (und damit wieder
einen Laufwerksbuchstaben opfere) klappt der Programmaufruf sofort. Also
genauso schnell, als wenn gar kein Netware Client installiert wäre. Die
INI behält bei dieser "Lösung" den ursprünglichen Eintrag
\\servername\freigabe

Also merkt das System, dass ein Drive-Mapping zur betr. Resource existiert
und ignoriert den UNC-Pfad? Sehr seltsam.

Post by Walter Cordes
Es erscheint so, also ob der Netware Client ein Problem mit dem Zugriff
auf UNC-Pfade hat.

Dank Filterdriver hat er eigentlich keins mehr. Prüfe bitte mal, ob der
UNC-Path-Filter (log. Device NWFILTER) wirklich läuft.
--
CU Christoph Maercker.

[Christoph Maercker]

Hallo,

Post by Walter Cordes
Kurzum, kann ich, wie Du unten schriebst, die Funktion von nwfilter testen?
Wie - ganz demütig - geht das?

1. muss NWFilter als logisches Device laufen. Siehst Du am besten mit
diesem hybschen Servicemanager:
http://www.nttools-online.de/deutsch/srvmgr.htm

2. Frage nach einem beliebigen Windows-Computernamen sowie nach einem
NetWare-Server und trace die Packets, die der Computer verschickt.
Windows-Namen sollten nur mit WINS/DNS, NetWare-Server nur mit NDS
bzw. SLP , evtl. auch mit IPX-SAP oder DNS erfragt werden. Wird ein
Windows-Name mit NDS erfragt oder ein NetWare-Name mit WINS, kriegt
das System entweder auf die korrekte Anfrage keine bzw. eine negative
Antwort oder es ist was faul im System. Insbesondere müssen die
jeweils ersten Anfragen an den zuständigen Nameservice gerichtet
sein. Falls nicht, macht der Filterdriver Mist oder ist inaktiv.

Post by Walter Cordes
Außerdem kann es ein Problem mit SLP geben, da die SLP Konfiguration nur in

Poste doch mal den Output von SLPInfo /A beim Client.
DISPLAY SLP SERVICES auf den Servern sollte ebenfalls was Vernünftiges
anzeigen.

Post by Walter Cordes
einem Subnetz per DHCP verteilt wird. Es gibt aber noch andere Subnetze mit
statischer Adressierung. Da muß ich gleich noch mal draufschauen.

Wobei das meiner Ansicht nach nicht Dein Problem erklärt. Ob SLP
überhaupt verwendet wird entscheidet sich erst, nachdem klar ist, ob der
NetWare-Client oder der MS-Client zur Namensauflösung benutzt wird. Und
*dabei* macht Dein System Fehler.

Post by Walter Cordes
Wenn ich eine Lösung habe, dann werde ich sie natürlich posten.

Unbedingt. Manche dieser Probleme sind von großem Interesse.

[Walter Cordes]

Hallo Christoph,
danke für Deine prompte Antwort!

srvmgr ist ein prima Tool und nwfilter läuft als device.
Ein ping auf windows-server bringt zunächst ein Abfrage an den WINS-Server.
Der antwortet mit der korrekten ip-adresse und der ping läuft ab.
Ein ping auf einen Netware-Server verursacht das Gleiche! Anfrage an
WINS-Server (Eintrag besteht auch für Novellserver!) gibt ipadresse zurück
und ping läuft ab.

slpinfo /all gibt folgendes:


*****************************************************
*** Novell Client for Windows NT ***
*** Service Location Diagnostics ***
*****************************************************

SLP Version: 4.91.3.0
SLP Start Time: 11:36:53am 6/7/2006
Last I/O: 11:37:52am 6/7/2006
Total Packets: Out: 242 In: 19
Total Bytes: Out: 19223 In: 2042


SLP Operational Parameters Values
------------------------------- ------------
Static Scopes NO
Static Directory Agents NO
Active Discovery YES
Use Broadcast for SLP Multicast NO
Use DHCP for SLP YES
SLP Maximum Transmission Unit 1400 bytes
SLP Multicast Radius 32 hops


SLP Timers Values
------------------------------------- ------------
Give Up on Requests to SAs 15 seconds
Close Idle TCP Connections 5 minutes
Cache SLP Replies 1 minutes
SLP Default Registration Lifetime 10800 seconds
Wait Before Giving Up on DA 5 seconds
Wait Before Registering on Passive DA 1-2 seconds


Scope List Source(s)
---------------------------------------- ------------
<unscoped>
STHSLP DHCP,DA


DA IP Address Source(s) State Version Local Interface Scope(s)
--------------- --------- ----- ------- --------------- ---------------
192.168.xxx.xxx DHCP UP SLPV2 192.168.xxx.xxx STHSLP


Local Interface 192.168.15.11
---------------------------------
Operational State: UP
Operating Mode(s): MCAST,STATIC-DA,DHCP-MANDATORY-SCOPES
SA/UA Scopes: STHSLP
Last I/O: 11:37:52am 6/7/2006
Total Packets: Out: 27 In: 19
Total Bytes: Out: 2019 In: 2042
Last Addr Out: 192.168.xxx.xxx
Last Addr In: 192.168.xxx.xxx



Ich steh' vor tausend Rätseln...

Gruß,
Walter

[Christoph Maercker]

Hallo Walter,

Post by Walter Cordes
srvmgr ist ein prima Tool und nwfilter läuft als device.

OK, der SrvMgr hat's an's Licht gebracht, was Windoof so leicht nicht
anzeigt. ;-)

Post by Walter Cordes
Ein ping auf windows-server bringt zunächst ein Abfrage an den WINS-Server.

Der WINS-Server macht auch DNS? Ping löst normalerweise eine DNS-Anfrage
aus, für WINS interessiert sich ICMP nicht.

Post by Walter Cordes
Der antwortet mit der korrekten ip-adresse und der ping läuft ab.

OK. Was passiert bei einer Abfrage NBTSTAT -a <wins-name> ?

Post by Walter Cordes
Ein ping auf einen Netware-Server verursacht das Gleiche!

Logo. Gleiches Protokoll (ICMP), gleiche Anfrage.

Post by Walter Cordes
WINS-Server (Eintrag besteht auch für Novellserver!) gibt ipadresse zurück
und ping läuft ab.

Und was passiert, wenn Du einen NetWare-Server aufrufst, z.B. mit Start
\ Ausführen \\<servername> ?

Post by Walter Cordes
SLP Version: 4.91.3.0
SLP Start Time: 11:36:53am 6/7/2006
Last I/O: 11:37:52am 6/7/2006
Total Packets: Out: 242 In: 19
Total Bytes: Out: 19223 In: 2042

OK, da passiert auf jeden Fall was.

Post by Walter Cordes
Use DHCP for SLP YES

d.h. der SLP-DA u.a.m. wird per DHCP mitgeteilt. Läuft der DHCP-Server
unter NetWare?
Die übrigen Einstellungen sind Default und bei mir genau so.

Post by Walter Cordes
Scope List Source(s)
---------------------------------------- ------------
<unscoped>
STHSLP DHCP,DA

Auch das ist gleich, nur DHCP fehlt bei mir, weil nicht konfiguriert.

Post by Walter Cordes
DA IP Address Source(s) State Version Local Interface Scope(s)
--------------- --------- ----- ------- --------------- ---------------
192.168.xxx.xxx DHCP UP SLPV2 192.168.xxx.xxx STHSLP

Bei mir simile, nur dass wir keine Scope-Units definiert haben.

Post by Walter Cordes
Local Interface 192.168.15.11
---------------------------------
Operational State: UP
Operating Mode(s): MCAST,STATIC-DA,DHCP-MANDATORY-SCOPES

Besser als bei mir: Mein Client macht nur Multicast, obwohl ich die
IP-Adressen der DAs fest eingetragen habe! Liegt das nun an der
Client-Version (v4.83/SP3) oder daran, dass wir keine Scope-Units
eingerichtet haben?

Post by Walter Cordes
SA/UA Scopes: STHSLP

Bei mir <unscoped>, klar.
...
Rest simile. Wenn SLP auch serverseitig sauber konfiguriert ist, würde
ich es definitiv als Fehlerursache ausschließen. Aber nochmal zu Deinem
Ur-Beitrag:
Du schriebst, die Anfragen werden an die NetWare-Server gerichtet, aber:
*Was* für Anfragen? Da kommt SLP, NDS, DNS und dumm, wie Wind... nun mal
ist, auch WINS und DHCP in Frage. Da es NW6.5 ist, schließe ich mal aus,
dass IPX läuft, sonst gäbe es noch mehr Möglichkeiten.

[Walter Cordes]

Noch eine Ergänzung:
Habe mich gerade mit meinem PC *NUR* an der Windows-Domäne angemeldet, also
Häkchen bei "Nur Arbeitsstation" gesetzt und - der Aufruf dieses Programmes
(in dessen ini-Datei ein UNC-Pfad auf den Windowsserver eingetragen ist)
funktioniert sofort. Hm.
Diese Geschwindigkeit erreiche ich inklusive Novell-Anmeldung nur, wenn ich
irgendeinen Laufwerksbuchstaben auf den entsprechenden Server\Freigabe
gemappt habe.
Die Programm-ini bleibt in allen Fällen unverändert. Habe dort also keinen
Laufwerksbuchstaben anstelle des UNC-Pfades eingetragen.

Gibt es noch Hoffnung?

Gruß,
Walter

[Walter Cordes]

Hallo Christoph,

das Phänomen ist AUFGELÖST ! Seufz...

SLP scheint korrekt konfiguriert zu sein.
Nwfilter läuft als virtual device - aber, siehe unten...

Aber: An den Arbeitsplätzen, an denen der Aufruf des Programmes lange,
lange, lange Zeit in Anspruch nahm, war clientseitig in den Einstellungen
des NWClient BAD SERVER CACHE auf AUS, und der UNC-Pathfilter ebenso auf AUS
gesetzt.
Nachdem ich mich auf einige der Problemrechner geschaltet und beide
Einstellungen auf ON setzte, funktionierte der Programmaufruf !
Werde jetzt die Clientkonfiguration auf allen AP angleichen...

Bin sehr erleichtert und danke Dir, wie auch den anderen die mir halfen, für
die Unterstützung !!!!


Vielen Dank & bis zum nächsten Prob.

Walter

[Christoph Maercker]

Post by Walter Cordes
Aber: An den Arbeitsplätzen, an denen der Aufruf des Programmes lange,
lange, lange Zeit in Anspruch nahm, war clientseitig in den Einstellungen
des NWClient BAD SERVER CACHE auf AUS, und der UNC-Pathfilter ebenso auf AUS
gesetzt.

Danke, diesen Werten musste ich bisher noch nie Beachtung schenken, weil
sie immer auf On standen. Aber gut zu wissen, dass es sie gibt und
welche Wunder sie bewirken. Sollte mit in die Doku für das Tuning vom
Client32 rein. Falls Letztere inzwischen Bestandteil der FAQ ist:
Darf ich St. Braunstein höflichst bitten?

Post by Walter Cordes
Nachdem ich mich auf einige der Problemrechner geschaltet und beide
Einstellungen auf ON setzte, funktionierte der Programmaufruf !

Das glaube ich gern. ;-)