From MSDN:
A program database (PDB) file holds
debugging and project state
information that allows incremental
linking of a Debug configuration of
your program. A PDB file is created
when you compile a C/C++ program with
/ZI or /Zi or a Visual
Basic/C#/JScript .NET program with
/debug.
So it looks like the "issue" here (for lack of a better word) is that some of your DLLs are being built in debug mode (and hence emitting PDBs), and some are being built in release mode (hence not emitting PDBs). If that's the case, it should be easy to fix -- go into each project and update its build settings. This would be the default scenario, if you haven't done any tweaking of command line options.
However, it will get trickier if that isn't the case. Maybe you're all in release or debug mode. Now you need to look at the command line compile options (specified in the project properties) for each project. Update them to /debug accordingly if you want the debugger, or remove it if you don't.
Edit in Response to Edit
Yes, the DLLs "know" that they have PDBs, and have paths to them, but that doesn't mean too much. Copying just DLLs to a given directory, as others have mentioned, won't clear this issue up. You need the PDBs as well.
Copying individual files in Windows, with the exception of certain "bundle"-type files (I don't Microsoft's term for this, but "complete HTML packages" are the concept) doesn't copy associated files. DLLs aren't assembled in the "bundle" way, so copying them leaves their PDB behind.
I'd say the only answer you're going to have is to update your process for getting the DLLs to those central locations, and include the PDBs ... I'd love to be proven wrong on that, though!