SOLIDWORKS PDM Network Communication Troubleshooting

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.

Network Communication Requirements

The most basic network requirement for SOLIDWORKS PDM is that general network communication be allowed (usually tested using a “ping” command) between the following:

• Client to PDM server (this would apply to both the archive and SQL server if they’re hosted on separate machines)
• Client to license server
• License server to client(s)
• PDM Server(s) to client(s)

If using a web server:

• Client to web server
• Web server to client
• Web server to PDM server (if hosted on separate machines)
• PDM server to web server (if hosted on separate machines)

Ports

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.

Antivirus and other security software

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:

• SOLIDWORKS PDM program folders: C:\Program Files\SOLIDWORKS Corp\SOLIDWORKS PDM
• Local vault view folders (default is on the root of C:\, but this can be changed and should be verified)
• SOLIDWORKS program folders: C:\Program Files\SOLIDWORKS Corp
• SOLIDWORKS Toolbox folder (if not integrated with PDM and stored locally/on a network folder)

Server-side folders:

• SOLIDWORKS PDM program folders: C:\Program Files\SOLIDWORKS Corp\SOLIDWORKS PDM
• Archive Server folders (default is C:\Program Files\SOLIDWORKS Corp\SOLIDWORKS PDM\Data\Vault Name, but this can be changed and should be verified)
• Microsoft SQL Server program folders: C:\Program Files\Microsoft SQL Server
• If storing your SQL logs and backups elsewhere, be sure to whitelist those locations as well.

Client-side processes:

• ViewServer.exe
• EdmServer.exe
• ConisioAdmin.exe
• FileViewer.exe
• Search.exe
• Report.exe
• Inbox.exe
• Itemexplorer.exe
• Any other executable found in the SOLIDWORKS PDM program files folder(s).

Server-side processes:

• ArchiveServerService.exe
• ConisioDbServer.exe

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.

Communication tests and tools

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:

SOLIDWORKS PDM 2020 and Newer

SOLIDWORKS PDM 2019 and Older 

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.

• ComputerNameand RemoteAddress tell you the hostname and IP of the destination machine.
• SourceAddress tells you the IP of the local machine. PingSucceeded tells you whether the communication reached the destination using true or false.
• PingReplyDetails tells you the average latency between the two.

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.

• RemotePort lists the port you told it to connect over.
• TcpTestSucceeded tells you whether the test succeeded for the port connection using true or false. 

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.

Related Articles

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

VIEW ALL SOLIDWORKS PDM ARTICLES