VectorWorks Isolating client p.c's from rest of Network!

[Eire 0]

Please help...

We have a major issue on our small windows network, basically we have 6 windows based p.c's all operating over a small hub'd network, we have Vectorworks installed on two p.c's Ver 12.0 and Ver 12.5... we keep all of the vectorworks files on a shared file on one of the Vectorworks p.c's..

The issue is this, whenever the vectorworks app is started on one of the client p.c's the p.c loses its connectivity to all the other p.c's on the network the network shares become disconnected and the p.c is not pingable from other p.c's (it can still access the default gateway and internet connectivity!) all p.c's sit on the same subnet. Further to this, the p.c remains in this disconnected state after the app has been closed for up to 40 minutes (even after reebooting!).

This is having a major impact on the business.. we have tried moving the network share to another p.c but still the same issue.. please help, is this a known issue? what can be done immediatley to solve this, please help!

many thanks

[Eire 0]

Please help me!!

[rcarch 0]

Eire-

You should repost this out on the General message board. You will get a lot more notice there.

[Pat Stanford 1,100]

Actually, this sounds like a problem that can be best solved by calling Tech Support. The response is likely to be much faster.

Pat

[klinzey 142]

Eire,

Give tech support a call if you have not already.

Your network is may be sutting down because of some firewall settings in network. Vectorworks uses the network connection. The network may be seeing this communication as an attack and shutting down the connection.

Especially with the "40 minutes" delay before reconnection, it sounds like something in the network firewall is causing the problem.

[Eire 0]

Thanks for the reply, i will doublecheck with the users..

[Eire 0]

Hello, yes as i suspected there isnt really any major firewall per-se, this is a very small design house with only 5 windows p.c's (all with windows firewall OFF) set up in the upstairs of someones house, the only type of firewall they have is on their home/soho router that feeds there ADSL connection, this just monitors traffic thru that router.. the p.c's are all hubbed together.

[Christiaan 648]

You're absolutely sure that the PC in question doesn't have some 3rd party Firewall/Anti-virus software installed? I may be wrong but presumably one can have a 3rd party firewall installed and on, while still having the built in Windows firewall off.

[Guest]

Well tell us how this started, out of the blue? Did you recently reinstall VW? Did you recently install new software on the machines in question? Is it *only* one machine that does this, or if you run VW on other machines, will it exhibit the same behavior? Which version of Windows is it?

[Eire 0]

it has been the case since the first time the software was installed, we have tried uninstalling and re-installing, giving full access to the registry keys.. the software is installed on two p.c's there is no 3rd party firewall software, windows firewall is disabled.. basically they have 2 p.c's w/the software installed on it, one of the p.c's acts as a fileshare for the others one for the VW documents, this drive is mapped on that p.c and the other p.c's in the office..

basically if you run a continuouse ping to the vectorworks installed p.c it replies fine, as soon as you fire up the vectorworks app the pings to it time out, and it loses its mapping to the 'share drive' it is unable to ping other p.c's on the same network but can ping its internet default gateway (on a home router)! (so not totally isolated) when you close the app the p.c remains in this state for about 40 minutes, even if you reboot the p.c!

this is the same for both of the p.c's with the app installed.. have tried moving the mapped drive off of a vector works installed p.c to a.n other p.c but it is the same issue, as soon as the app is fired up it is affectivley isolated from other p.c's

Other information, just so you are completley in the picture, there are no other funky apps on the machines, just office products i.e etc. the software is a Japanese version as the company are based in Tokyo and it is fully licensed.

thanks so much for your assistance, i greatly appreciate it.

One other thought i have is that they dont have a license server or dongle?? could it be that they need one of these, but i thought that was only for like multi license educational establishments etc??

Edited March 14, 2008 by Eire

[Guest]

What is the username of the computer it was installed on?

[Guest]

This is definitely up there with some of the strangest problems I have ever encountered. They always have a logical solution though, so lets keep thinking on this one.

Are you familiar at all with network analysis tools like wire shark?

Perhaps it could be worthwhile to use it to analyze the network traffic to see what is going on.

The only other thing I could suggest would be using a tool like STraceNT in conjunction with some network diagnostic tools. If you can correlate the time of the proble firings in stracent with the time the network fails, we can at least get a rough approximation of what vectorworks is doing on your machine at the time the network fails.

I'm not really sure what your experience level is with these sort of topics though, so this may not really be an option.

[Eire 0]

Hello,

Sorry, this issue is still ongoing!!!, we found out that we had the stand-alone version and thought that it was doing it by design, however the distributor A&A say that it SHOULDNT exhibit this behaviour even though this is stand-alone version.

I am happy to sniff the network at the time when this is happening, will prob use Ethereal, i guess what i need to know is what i would be having to filter for. Im guessing Layer2 frames with the client p.c as the source?

If you can give some idea of what to filter for i will go and take a look, this is really hitting there business now..

thanks

[Guest]

Let's say the machine running VectorWorks is called machine A, and another machine that can't be reached on the network is called machine B.

First, I'd run ethereal on A to first verify that you see traffic when you attempt to go to the internet (which I believe you said should work). Then on A, attempt to view a share on B (or ping it, I guess in this case you could filter for icmp). If this works, lets move on to B.

I would run ethereal on B as you try and ping B from A. See if B notes that it is being pinged.

It's most likely though that the truth of the matter will be discovered on A. Like I said, I think a tool like STraceNT would be most helpful, if anything will be at all.