A build that works under Visual Studio locally does not work with the plugin. A build step fails, reporting that it cannot find a file, and so on.
There are multiple possible reasons for this:
One reason has been that the files were located on an AFS file system on a server, which was accessed through the OpenAFS driver on Windows. It appears that OpenAFS has scalability issues, mainly because they chose to implement this as a local SMB server (see here for a discussion about them wanting to implement a "real" driver some day).
There are instances where multiple users on the same machine may overload the system, although those might be related to Unix. Find notes on robustness and scalability here.
A customer was using OpenAFS 1.4.2. It might help to upgrade to a newer version that is more scalable.
Reduce the number of agents being run to lessesn the load on the AFS server. This reduces the overall number of agents, so it’s the last resort if you are unable/unwilling to resolve the AFS issue.
There are instances where the ClearCase server was undersized for the throughput demands of a parallel build.
Improve the ClearCase server performance.
Reduce the number of parallel Electric Make (emake) builds.
A common reason is that Visual Studio allows the global setup of INCLUDE, LIB, LIBPATH, PATH, and REFERENCES as part of the IDE setup. Those must be correctly configured on all agent machines for individual users (ECloudInternalUser1, and so on.) to match the setup on a regular build machine.
It is recommended to not rely on these values. Instead, configure these values through the environment.
If the problem is specific to finding dlls and typelibs, you may experience the registry underlay problem. The agent node contains a local registry key for the class ID that points to a path that no longer exists. The way registry mirroring currently functions means that the value for that key comes from the local node and not from the emake machine.
Ensure you clean that registry key on the agent machine.