SOLIDWORKS PDM is a client-server software that requires various network connections to function properly. There are numerous ways to check on those connections to ensure everything is working as it should – or to identify the problem when it’s not.
The most basic network requirement for SOLIDWORKS PDM is that general network communication be allowed (usually tested using a “ping” command) between the following:
If using a web server:
A big part of communication with SOLIDWORKS PDM relies on various ports being open on the network. A port is a software-defined virtual point on your network that’s identified by a unique number.
Across the different components in a PDM environment (the client, server services, SQL, etc.) are the various ports that need to be opened for inbound and outbound (listening/receiving vs sending) communication. You must ensure these rules are set up in your local and network firewalls.
You should also consider any antivirus or security software you have in place when using PDM, as certain whitelist exceptions must be added so PDM won’t be blocked unnecessarily. Here are the general antivirus recommendations from SOLIDWORKS: https://www.solidworks.com/support/hardware-benchmarks
The following folders and processes should be whitelisted as well:
Client-side folders:
Server-side folders:
Client-side processes:
Server-side processes:
All of the above should be applied to any firewall or VPN exception lists as needed.
Note: This list is based on the default PDM processes and locations, and anything further will be dependent on any add-ins (e.g., SOLIDWORKS add-ins) and applications (File Upgrade Utility, etc.) installed on a particular PC beyond those.
Connectivity Test Tool
The Connectivity Test tool is made directly from SOLIDWORKS and takes a lot of the guesswork out of manually performing connection testing. It performs ping and telnet tests on the three different server components for PDM, as well as confirming ODBC connectivity. This is specifically meant to be used on a client machine to check the connection to the PDM server(s).
You can get the tool and associated instructions via the 3DSupport Knowledge Base article S-069274 / QA00000119794 here.
Ensure that .NET 4.0 and telnet are enabled on the client machine before running. If you’re unsure or unable to do so, please contact your IT team to enable them.
You can also access direct downloads here:
This tool gives some basic information about the system you’re running it on and has four separate tests you can run. Run individual tests or all of them based on what issues you’re experiencing and what information is available.
CMD: Ping
A ping test is the most basic form of network test that determines if two machines can “see” each other using TCP/IP. To check whether a client can talk to the server or the server to the client, start by performing a ping test.
Open up a Command Prompt by searching “cmd” in the Windows Start menu.
Type ping followed by either the hostname or IP address of the machine you want to ping, then hit enter: ping 192.168.1.1 or ping PDMServer
The system then sends four packets of data, each consisting of 32 bytes, to the destination computer reporting how long each of those packets took to get there (or whether they got there at all).
Ensure that the ping goes through and doesn’t drop any packets. Also, make sure the latency isn’t too high (SOLIDWORKS recommendation for PDM is to keep latency under 150ms maximum, but ideally under 100ms for better stability and performance). We generally test latency on networks a little differently, but it’s still good to take note of when checking.
If you receive messages saying the destination was unreachable or that it timed out, talk to your IT team about network stability and communication.
CMD: Telnet
A ping reports whether two machines can see each other, but as we covered earlier, PDM also requires specific ports to be open between clients and servers. You can test port communication by using Windows Telnet in Command Prompt for this.
Note: Internal IT teams are increasingly disabling telnet for security reasons. If this is the case, you can use the test-netconnection option in PowerShell below as an alternative.
To perform a telnet, open Command Prompt and type “telnet [servername or IP address] [port]” and hit enter when finished.
For example: telnet PDMArchiveServer 3030 or telnet 192.168.1.1 1433
If the screen comes back with a blinking cursor, the telnet succeeded.
If the telnet failed, you’ll generally receive a message saying, “connection failed” or “could not open connection to host”.
In this case, there is likely a TCP/IP problem between the client and the server, and it should be investigated by the network administrator.
Usually, it’s a firewall blocking communication on that specific port.
If you get a message saying telnet isn’t recognized as a command, you might need to turn it on first.
To turn telnet on, open the Windows Start menu and search Turn Windows features on or off. Then, check Telnet Client and hit OK.
PowerShell: test-netconnection
In cases where ping or telnet isn’t an option, use PowerShell instead to perform communication tests. PowerShell can accomplish the same tests using a different command called test-netconnection, sometimes referred to as “test-net”.
To access PowerShell, open the Windows Start menu and search PowerShell.
The interface looks very similar to Command Prompt and can be treated much the same way.
To test for basic TCP/IP communication, you can use the same syntax as ping, but replace ping with test-netconnection.
For example, type test-netconnection followed by the server name or IP address, and then hit enter.
A quick pop-up confirms the test is running.
When finished, you’ll get the results of the test, as well as additional information about the machines and latency.
PowerShell: test-netconnection -port
You can also check port communication using test-netconnection. After entering the server name/IP, add -port [port number] at the end of the command. For example, test-netconnection [server name or IP] -port [port number]
You’ll get a similar output to a regular test-net with two extra lines.
Note that a ping can succeed even when a port may fail. This means the machines can see each other, but the outbound port on the local machine and/or the inbound port on the destination machine likely isn’t open. Outbound communication is generally open by default, so inbound being blocked is more likely in most scenarios.
This concludes SOLIDWORKS PDM network communication troubleshooting. Learn more about SOLIDWORKS PDM below.
SOLIDWORKS PDM & Windows Active Directory: A Master List
SOLIDWORKS PDM: Input Formula Aliases
Default Expressions in SOLIDWORKS PDM Data Cards
SOLIDWORKS PDM vs 3DEXPERIENCE CLOUD PDM: Workflows, Licensing & More
How to Check What Version of SQL a SOLIDWORKS PDM Environment is Running
About Rowan Gray
Rowan Gray is a Technical Support Team Lead at GoEngineer with a specialty in SOLIDWORKS PDM and related data/lifecycle management. They have been with GoEngineer since 2020, and have a strong IT background that helps them more fully support customers with whatever issues may arise in their PDM environment. In their free time they enjoy playing video games, crocheting, and spoiling their pets.
Get our wide array of technical resources delivered right to your inbox.
Unsubscribe at any time.