The server manager is a Java application running on each server host. Its primary role is to manage a set of method servers, but it also maintains user session credentials, and manages background processing and other system management functions.

There is a single instance of a server manager on each Windchill server host. It runs in its own Java Virtual Machine (VM) and must be running for the Windchill system to be considered available. This process could be viewed as a Windchill daemon since it must be running at all times.

Running more than one server VM is not a requirement of the Java architecture. Windchill implements this architecture for reasons of reliability and scalability. Allowing for multiple method servers reduces the risk of a single VM being unable to fully use high-performance multiprocessor hardware when contention for shared resources within a single VM becomes a limiting factor. By allowing multiple processes, the system itself can scale beyond the capacity of the individual VMs to handle high transaction rates.

For example, if a given type II (native method) JDBC driver implementation began to show synchronization bottlenecks at some number of concurrent DB transaction threads, a second method server could double the system's capacity for concurrent transactions.

This architectural feature also addresses reliability because the method servers, unlike the server manager, execute customized Java code developed by non-Windchill programmers. Although the Java VM provides a very reliable, thread-safe environment, which makes it difficult for errant code to affect other threads, instability can be introduced in the form of memory consumption or resource deadlocks. Further, method servers may use native (non-Java) libraries for database interfaces or other application-specific interfaces. These native libraries can contain bugs that introduce instability into an entire VM. By keeping the Windchill system daemon (server manager) and instances of method servers in separate VMs, individual method servers can terminate without making the Windchill system unavailable or losing user validation information.

Performance concerns are addressed by minimizing the interprocess communication required between the method servers and the server manager, and between clients and the server manager. After clients use the server manager to bind to a method server once, they call that method server directly. If that method server later becomes unavailable (terminates), automatic exception handling transparently rebinds the client to a new one.