dsPIC chips running at a fraction of normal speed
In MPLAB X, the config bits cannot be set separately from the code (like MPLAB 8 used to let you do). The only way the config bits could be 'wrong' is if someone modified the code. Since you're using a standalone HEX file project, this is unlikely.

You haven't said if reprogramming one of the 'bad' boards on a 'working' PC actually fixes the issue. Give that a try.

Another thing you could do (if you don't use code protect) is read back the HEX file from a 'working' setup and flash that into one of the malfunctioning boards. This should eliminate code change as one of the uncertainties.

Another (unlikely) scenario is that your dsPIC stock covers multiple revisions, and a stepping change has somehow invalidated your code. Make sure the IC part numbers are correct, and when the PICkit3 connects, you should see a revision code that you can cross-reference to the silicon revision.

EDIT: It's now time to make sure that the various installations of MPLAB X are matching on all the PCs - are they the same revision? Are they the latest revision?

Whenever there's a new version of MPLAB X, the PICkit3 firmware tends to get upgraded - there may be a bug or incompatibility with older PICkit3 firmware and your HEX file.

I had a similar situation recently (now that it just dawned on me - duh) where a HEX file that I generated on my machine with MPLAB X and XC16 would program correctly on my machine, but would not on another machine using MPLAB 8 v8.50 - the code seemed to be running slower (initialization LEDs seemed sluggish). When that PC was updated with MPLAB 8 v8.88, using the same programmer and the same HEX file, things started working again. Weird.