If you are going to keep any of the units on 3.1.5378 then you should move them all to 3.1.5378. You said you have 3 units on 3.2, so I would suggest you bring them all to the same release. The IPO is not really meant to be running in an SCN with units on different releases.
Also, having more than one release means you must have more than one release manager to manage the units. If you do not have more than one release of manager installed, and being used then it lends itself to a probability that the 3.1 unit has been managed with the 3.2 manager. Even if you do have both releases of manager installed somewhere on different PC's on your network the probability that someone forgot, and used the 3.2 to manage the 3.1.5378 system is high.
If the 3.1.5378 system has been managed with the 3.2 manager then I suggest that you default the 3.1.5378 system, rebuild the CFG from scratch, and then upgrade, or downgrade all of the units to be on the same release as they should be. Running 3.1.5378, and 3.2 on the same SCN is only something that should be done on a temporary basis while you migrate through the process of changing the units over, and is not a long term solution.
The issues when you make changes in my opinion lends itself to the system CFG being corrupt, and probably from mis-management with mis-matched manager software.
Finally, I have come in to work on systems that have been having weird issues so many time that I can not even remember them all. Simply by defaulting the switch, downgrading it to the original release it came with, and then re-upgrading it has fixed a myriad of systems from having the weird issues. Improper upgrades can corrupt the system, and or the CFG causing unexplained issues such as this. Rebuilding one system CFG is not that hard especially if you have the old CFG to load up on a laptop to look at to recreate it with. Do not however just load the old CFG on the system after you re-upgrade it as that will just bring the problem along with you back to the new scenario if the CFG is corrupt.
I realize this is not what you want to hear, but it has worked for me when coming in after someone else has been managing the IPO, and it is not working properly. I realize that some may not have had issues like this with the systems they have implemented, and neither have I. I have had them with other peoples systems though. I believe that many do not follow the proper procedures when upgrading the IPO, and corrupt the system, and the CFG by doing so.
It is best not to assume that the IPO has been upgraded competently when issues arise that are not inherent to systems which have been upgraded properly. Issues of this sort from my experience with inability to make changes to the mismatched release unit on an SCN without errors, inability of only that same mismatched system to communicate properly on the SCN, and a programming change occurrence having been the catalyst for the failure events all leads to corruption as the diagnosis. What release of manager was used to change the IP on the system having errors? If you can not certify that the change was made with the
3.1.5378 manager to the 3.1.5378 unit then the next step is obviously downgrade, and re-upgrade the system, and default it to start from scratch. You could default, and DTE the system, but I have never messed one up bad enough to have had to DTE one yet, so I am not the best guy to instruct you on that. I am well over 100 units serviced, and never had a DTE cable out yet, and hoping to make it to 200, no 300.
