Intermittent delay mapping OpenVMS shares to Windows XP

[Patrick Grealy]

Hi,
We have a group of about 30 users with standard company-issued Dell PCs running almost identical software including Windows XP Pro(SP2), MS-Office and VirusScan 8.0 on a Windows 2003 server network with pretty tight security, firewall, etc. A certain group of these PCs has a problem mapping a drive to our Alpha/OpenVMS shares while others don't. We're running OpenVMS 7.3-1, Advanced Server 7.3A and TCPIP 5.3 on OpenVMS cluster of two DS10s.

Here's a sample scenario:
On my machine which is functioning correctly, I map a drive to U: connecting to
\\txdallas\cpca where \\txdallas\ is one node of our VMS cluster. On Judy Smith's PC, she tries to map drive U: using the identical \\txdallas\cpca target and gets a DNS lookup error. She then tries to map U: to VMS share cpca using the full name \\txdallas.msb.edu\cpca and it fails with a pop-up error window with message:

An error occurred while reconnecting U: to \\txdallas.msb.edu\cpca folder.
Microsoft Windows Network: The local device name is already in use.
This connection has not been restored.

She retries and succeeds after an additional attempt or two. When it succeeds it takes approximately 75 seconds. If she later tries to access U: there may be a delay while it
reconnects. E.g., if a program like WordPerfect or Stata goes into an Open FIle dialog after a certain period of time since the mapped drive was last accessed(probably the 15-minute Windows default), the drive must reconnect, causing the 75 second delay again, or worse if it fails. It doesn't matter that she intends to open a file on another drive.

Note: this problem does not occur if Judy logs into the PC in my office. Conversely, if I logon Judy's machine, I experience the same failure/delay problem in mapping an Alpha share.

Note: Using the full IP address or the full name works the same way on the problem PCs.

Note: Going to the command prompt on either machine and issuing a ping to server txdallas results in quick and successful hits.

(Final note: all names of people and servers have been changed to protect the innocent.)

Thanks,
Pat G.

[Peter Quodling]

Sounds like a DNS Problem.

what are the results of ipconfig/all in a DOS window on here system, and yours... PArticular Gateway/DNS.

Also what is the network topology between your system and your DNS Servers, and her system and the DNS Servers.

q

[Andy Bustamante]

I agree with Peter. You should also check the host and lmhost files on the client PCs.

Andy

[Patrick Grealy]

Hi,
Thanks for the two quick responses. The HOSTS and LMHOSTS look ok. This problem actually occurs on several machines and we've tried adding entries to HOSTS on some machines with no success. Also, the IPCONFIG/ALL id pretty much the same. I did IPCONFIG/FLUSHDNS and that did not change anything.
The key seems to be that I can go to the command prompt and PING txdallas with success yet if I try NET USE X: \\txdallas\cpca the server is not found and I must enter NET USE X: \\txdallas.msb.edu\cpca and wait the 75 seconds.
Our plan here is to try physically swapping the ports on the swicth. Further investigation needs to wait for now - we're in hurricane preparation mode!
Thanks,
Pat G.

[Doug Phillips]

Hi Pat,

What about the problem group makes them different from the other users, and what do they have in common with each other?

Are they in a different workgroup or domain?

What does ipconfig/all say about WINS?

Does NET VIEW show everyone it should?

Is the AntiVirus scanning the network drives?

Doug
ps. Here's sending good thoughts your way as well as to my friends in the SE Texas and gulf coast area.

[Andy Bustamante]

Another thought. Do you have enough licenses available for all users? Pathworks is designed to allow users to share licenses, that is user A, B and C can be configured to share pair of licenses. As long as all thre don't want simultaneous access no issue.

$ADMIN/LICENSE brings up a license configuration menu.

$ADMIN/CONFIG will bring up a resoure configuration menu. Client capacity shouldn't be less that 50, for your 30 users, I'd bump it up to 90. Pathworks uses internal connections against this quota so it doesn't mean the number of your users.


Andy

[Patrick Grealy]

Hi,
Thanks for the suggestions. It's been a while since I've been able to get back to this. I've checked all the things that have been suggested and the NET VIEW seems to offer the most interesting results:
- on a "bad" pc, net view \\txdallas fails
- net view \\txdallas.msb.edu immediately shows all the shares that it should
- net use x: \\txdallas.msb.edu\cpca then takes the customary 75 seconds to successfully connect

Otherwise, there are no detectable differences between good pc vs. bad pc: same domain, subnet, groups and ipconfig/all results from both yields no significant differences. WINS is not enabled on any pc. Antivirus is not scanning net drives.

ADMIN/License show no license server running.
ADMIN/Config shows capacity of 100 clients.

Thanks,
Pat G.

[Patrick Grealy]

Hi,
Still haven't solved this and must admit we're not devoting a whole lot of time to it. I did try bringing one of the "bad" PCs into my office and plugging into the ethernet port in my wall. Problem behavior persisted which seems to rule out cabling or routing disparities. We are considering the possibility of USB conflicts or re-imaging the hard drive on the problem PCs. - Pat G.

[Patrick Grealy]

Well, after more than a year we seem to have solved this problem and at least a couple of us are pretty red-faced. After our IT group pushed one of the Microsoft updates out to our group the problem suddenly got worse - all PCs now experienced delays and required full DSN in order to map the VMS shares.

So, what was in this magical update you might wonder. Among other things, it forced all Windows XP up to ServicePack2 and turned on Windows Firewall. Stopping/disabling the Windows Firewall service on a PC fixed the problem!

Now, anyone still reading this may have noticed my initial posting that declared all our PCs are "running almost identical software including Windows XP Pro(SP2)". HA, APPARENTLY NOT!

Our network guy and I cannot believe we overlooked this. In our defense, this problem manifested itself around the same time we were changing domains, IPs and subnets and that's where we concentrated our troubleshooting. It seems that coincidentally, some PCs were upgraded to XP/SP2 that same week. I still find it hard to believe we were not all at the same SP2 level but at this point the evidence is overwhelming.

We would now like to know if a firewall exception can be added to permit our Pathworks shares to work while allowing Windows Firewall to be enabled. This is not really critical since we are pretty well locked-in behind the institution's firewall and can leave the PC firewall off. And, I don't think this forum needs to hear anymore about this anyway. - Pat G.

[Paul Nunez · Accepted solution]

Hi Pat,

What you're experiencing is PATHWORKS' attempt to determine if the client has any client-based licenses.

The pwrk$license_r (the license registrar) process will attempt to establish a session over TCP port 139 (the standard file server port) to the client and query it for licenses.

By default, the Windows firewall has port 139 blocked.

You can either:

a. Add the "File and Print Sharing" option to the Exceptions list in the Windows firewall.

b. Prevent the pwrk$license_r process from querying (aka "pinging") clients for a license.

Option b is preferred if your clients don't use client-based licensing and rely instead on server-based licensing.

To implement option b:

$ def/sys/exec pwrk$lr_disable_client_ping 1

If the logical was not previously defined, you'll have to restart PATHWORKS to affect the change. Thereafter, any change is dynamic. For more info, see:

sys$startup:pwrk$license_r_start.com

Be sure to include the logical name definition in your system startup procedures...

Regards,

Paul