PDM Server Configuration Considerations


Written by: John MacArthur, PDM Project Manager

While not the most exciting topic in the world, I get asked a LOT about my recommendations for setting up PDM Servers. So, I thought I would get it out there in a blog post for anyone who needed the info.

First, I would like to clarify the different server components involved in a SOLIDWORKS PDM installation:

  1. Microsoft SQL – This is the Database backbone of SOLIDWORKS PDM. Currently, SQL 2014 Standard comes with a purchase of PDM Professional and SQL Express for PDM Standard is included in the download and on the DVD. It houses the databases, which store information about the vaulted files. It does not actually store the CAD data itself.
  2. Archive Server – This is included in the purchase of PDM Professional or Standard. This software houses the CAD data, and stores each version of the files.
  3. PDM Database Server – This is also included in the purchase of PDM Professional or Standard. This is the software that communicates between SQL and the archive. It also handles the notification system in PDM.
  4. License Manager (SNL) – This is included in the purchase of PDM Professional or Standard. This software serves the licenses available for client use.

So those are the 4 major server components. Does that mean you need multiple servers? No, but that it is an option. All 4 of these components can be installed on the same server, or you can split them up between multiple servers.

With the split up being optional, what do I recommend?

Personally I think having a dedicated Server for SQL and the Database Server is a good idea. With no other software running on that server, it leaves the most resources for SQL, and minimizes network traffic for SQL as well. What does that mean? It means it’s easier to isolate and troubleshoot performance issues when SQL is on a dedicated server.

Depending on available resources, I think installing the Archive server on its own server is ideal. Otherwise, it would utilize the same resources as the SQL and Database Server. Having a second server for the Archive may improve performance and makes diagnosing issues easier.

The License Manager can go on either server, or on its own. It’s a very lightweight application, so it’s not a performance consideration.

What don’t I recommend?

Running SQL, PDM Database Server, Archive Server, and a bunch of other software packages on the same server. This makes troubleshooting fairly difficult, and takes down those other software packages while that server reboots. (Which is needed during updates)

Running SQL for PDM as a named instance on an existing SQL install. This is fine from a functionality standpoint. I understand that some IT professionals prefer this for different reasons. The concern I have with it, again is isolating and troubleshooting issues, taking down the other databases when rebooting and the sharing of resources on that operating system. SQL is a very heavy software resource wise, and I simply recommend keeping it isolated.

How about running on Virtual Machines?

Sure, no problem. We have many customers running PDM server components on virtual machines without issue. In fact, the benefit of virtual machines is their ability to increase storage, RAM, and processors on the fly. This makes it nice to see if throwing more resources at the specific components will yield performance results, without having to take a computer apart. Just make sure you’re staying with the license agreement of SQL.

How much RAM/Processor/Hard Drive space does each server need?

SOLIDWORKS has their recommended minimums on their website. But, below I’ll outline my recommendations.

For the PDM Professional, SQL and Database server:

SQL will use as much RAM as you give it. In fact, you need to go into settings in SQL and limit it, or it will use everything available. Typically companies run 8Gb, 16Gb or 32Gb depending on size, activity and number of users. You want to have enough available that you could load the entire database into memory. This means it may need to be adjusted down the road.

The amount of storage space needed is minimal. The OS and SQL install will use between 35Gb-60Gb, then the database will grow over time, 10Gb is a pretty large PDM Database. So in my opinion a hard disk of 100Gb is adequate. SQL again will use as much processor as you let it, but you need to follow the SQL licensing here. I believe licensing for 4 processor cores are all that is included with a Professional PDM Site License, you can purchase additional core licensing thru Microsoft.

For PDM Standard, SQL Express and Database:

Everything I mentioned above applies, however SQL Express limits to 1Gb of RAM used by SQL, so throwing more at it then that does no good. The Database size is limited to 10Gb.

For PDM Professional and Standard Archive:

This server does not need much RAM, 4Gb or 8Gb would be fine. It also doesn’t need much processor, again 2 cores here. This machine needs access to much more hard drive space and ample drive speed. Sizing should be based on how much data you plan to vault, plus room for growth over at least 1 year, with a buffer. If you’re building a new server I would recommend at least 3 years of growth. Many companies like the archive to be on a NAS or SAN for speed and backup purposes. This is fine, as long as the machine sees that as an actual drive, and not a mapped network drive.

What ports need to open if a firewall is in place?

For the Database, 1433 is the default instance SQL port, and 1434 is the default for a named instance. The Archive uses 3030 and will also need to be opened. The License Manager communicates thru port 25734 and 25735 for the vendor daemon port by default. Open all these ports incoming and outgoing, TCP and UDP and you should be all set.


Piece of cake right? But seriously, I hope this helps get you headed in the right direction, and feel free to contact DASI Solutions to discuss setting up PDM anytime. We’ll be glad to help.



John MacArthur

PDM Project Manager


Leave a Reply

Your email address will not be published.