When trying to startup MR-PG so that web channel routing can be delivered, the MR-PG startup window gives the following error:
Unable to register with MDS process
Last MDS error: client is already registered
It then initiates a system shutdown that needs to be cancelled using the stopshut utility
I did not set up the MR-PG as a network VRU. Should I do that? The patches that are installed are those that comes with the CISCO ICM5.0 installation CDs. The configuration that I use to set up the MR-PG are all default values. Please advice further.
I have set up MRPG as a network VRU using Targets-Network VRU. I have also assigned this to the Peripherals-Peripheral-PG Explorer and select the MRPG VRU for the MRPG Peripheral. It still causes the shutdown. Please advice further on configuration or setup needed.
It seems that the shutdown is caused by MDS service contention by the IP-IVR PG and the MR-PG. If I were to start the IP-IVR PG first and try to start the MR-PG, the shutdown initiates... and if I were to start the MR-PG first, and IP-IVR PG later, it also initiates a shutdown. Where should I configure the PGs so that they use different ports or connections to the MDS service? What exactly is the MDS service and what is its function? Thanks.
MDS is Message Delivery Service. In Simple terms it's the backend communications path between ICM component processes.
There is a out-of-the-box limitation of a maximum of 2 PGs installed on a single server. It doesn't sound like you exceeded that here though. I susepct that you selected them as the same PG number (e.g. PG1). They need to be different numbers. Such as: IVR PG is PG1 and MR is PG2. Also, the moment that you clicked 'NEXT' in PG setup, the PG # is written to the registry. If this was mistakenly set at 1 and clicked next, you noticed the error and went back to change it to PG2 - it's too late. Delete the MR PG and start over again.
If you do have more than 2 PGs on the same server, and this is a lab or demo install then you may go into the registry in MDS in the PG instance and manually change the port numbers (if it's duplex, then match both sides A and B for this PG instance).
If it's production, then this hack is not supported.
As always, when playing w/ the registry, use REGEDIT and export the entire HKLM\Software\Cisco Systems hive before your changes.
P.S. for everyone: an MDS error like this and or an immediate 'stophut' request 99% of the time points to a IP Address/Hostname problem or port # problem. Deleteing the troublesome PG and carefully reloading should solve most of the port # issues. Making sure that you can ping all the hostnames _and_ IP addresses before loading ICM should solve the other.
I do have more than 2 PGs: 1 for CallManager, 1 for IP-IVR and another for MR-PG.
You mentioned about changing the registry in MDS in the PG instance. Can you please direct me to the correct key, ie.HKEY_LOCAL_MACHINE -> SOFTWARE -> Cisco Systems and so on. Thanks.
You also mentioned that the hack is only supported for lab install but not production. The question is how will the software tell whether it is a lab install or a production install, and then decide to support or not support the hack? Thanks!
I have edited the registry with path HKLM\SOFTWARE\Cisco Systems,Inc\ICM\icm01\PG3A\MDS\Process
where icm01 is the ICM instance
and the keys
MDSPort from 44040 to 44050
StateXferPort from 44041 to 44051
(just changing MDSPort ONLY also causes the shutdown).
The good news is the shutdown does not initiate again, but on the pgagent window it actually complains:
Connection to Central Controller side A failed. Last EMT Error: The connection has been closed by the remote process.
Please continue to advice further.
I have actually checked the other forums and realized that I have not set the CallRouter configuration to accept 3 PGs. When I run setup and put that in, the old error message is gone but comes up with this new problem:
Connection to MR application established
But then right after:
PIM connection to MR application has been closed.
MR_Application::Receiver. Problem with receiving application messages. Exit Receiver thread.
Timeout occured waiting for response to OPEN_REQ message.
TCP connection to MR application has been broken.
The looping then repeats itself. Please further advice.
It doesn't look like your Media peripherals (applications) are connecting (no response to the OPEN_REQuest message). Are they ready/configured to connect? If they aren't ready then this cycle of looping is normal.
Also, as far as 'supported' goes, this isn't a software issue (there is no product difference for lab or production) but the Cisco TAC might have an issue with this in production if you need to call for assistance. I suspect that an ICM upgrade will also change your port numbers back to default - strong documentation surrounding what you did will protect the customer (and you) for the long-term. The software wasn't authored for more than 2 PGs on a single server - this fix is a hack and everything associated with the term 'hack' goes with it. I've never deployed in production in this manner.