Believe it or not, we just upgraded to ICM 4.1.6 and are having problems when modifying scripts. It takes about 3 minutes to make a change and save the script. I feel that it's b/c we only have 56k lines (min requirement) from each PG to the Router/Logger. We had slow responses on the 2.x version we were on, but it's become worse since the upgrade. (I believe we are sending larger packets now, thus creating the problem.)
My question is: What type of connections is everyone else using from their PGs to their Router/Logger? All four of our PGs are in various locations throughout the country, with our Router/Logger based in Texas.
Thanks for your help!
Do you mean the connection from the AW to the Router/Logger since the AW is where you're making script changes? Are your AWs in the same location in Texas as the Router/Logger? Are they on the same network?
Sorry for my slow response. I was traveling quite a bit lately. Yes, the connection from the AW to the Router/Logger. AWs are in Houston, Router/Logger is in Plano, Texas. They are on the same private network. It's takes as long as 5 minutes to just apply a skill group addition! Thanks for your help!
What you describe is 2 separate issues.
a) Script Changes take a long time to change and save scripts. Script changes occur on an AW and are submitted to the Call Router(s) for acceptance (PGs are not involved). Your delay could certainly be network induced (bandwidth, delay, jitter, etc.), hardware induced (processor, memory or disk drive insufficiencies) or a software issue (ICM, Windows or SQL). The only way to really tell is by looking at your specific ICM architecture and running some performance tests. Does this occur on all your AWs or only a small number? Did you upgrade the hardware when you did the ICM upgrade?
b) PG WAN infrastructure. Depending upon the amount of calls, CTI or no CTI and post routing or not will size your links. Most ICM users are satisfied with 56k. If this is increased, the PG setup will need to be modified to account for this. Was PG traffic suitable prior to the upgrade? Did you change any services with the upgrade?
a) What is the definition of "long time"? It takes about 3 minutes for the us to even open the Script Editor, then about 60 seconds for a change to process. With our upgrade, we did upgrade all of the hardware as well as software.
b) As of right now, we do not use Post Routing or Cisco CTI.
Out of curiosity, do you have Configure ICR open on the same AW or on other AWs in the enterprise? We've seen some funky things when one of our AWs has both applications open or if one AW is modifying scripts and the other is making changes in Configure ICR.
Also, maybe it is just our impression, but it seems that Script Editor is more likely to hose than some of the other ICM applications.
Finally, what hotfix are you on? There have been a few that address other issues with Script Editor (such as 132).
It is very likely we have Script Editor open on other AWs in the enterprise. We definitely have other AWs running real time reports at the same time we might be making a scripting change. Those AWs are in different physical locations, but part of the overall enterprise.
We currently have hotfix 54, 127, 132 & 225 installed on the AWs.
You mentioned that you're running real-time reports, but are you using Configure ICR anywhere else at the same time you are using Script Editor?
Also, are all of your AWs pointed to the same Logger/Router/HDS?
There are times when we would have Configure ICR open along with Script Editor, but we try to avoid it.
Yes, all AWs are pointed to the same Router/Logger, we don't have an HDS.
Hope this helps! I appreciate your help!
This might be part of the issue - your AW "architecture".
You should have your Real-Time Distributor AWs balanced between the 2 Central Controller sides (assuming you have a duplexed CC). In addition, you should attempt to minimize the number of Distributors you have and also make sure that you have Primary and Secondary Distributors paired correctly.
In a very basic sense, each site that needs AWs should be set up as follows:
First AW - Real-Time Distributor, Primary, CC Side A preferred
Second AW (if needed) - Real-Time Distributor, Secondary (determined by Admin Site Name in ICM Setup), CC Side B preferred
Third and successive AW(s) - Real-Time Client Only AWs, configured to Primary and Secondary Distributors.
The Preferred side can be swapped - the point being to have the Primary and Secondary prefer different sides. They will both still be able to connect to either CC side.
It is important to note that the Primary/Secondary AW relationship is a hot standby, not synchronized execution. When all is well, the Primary has a connection to a CC side, and the Secondary connects to the Primary as a Client Only. All other Clients also connect to the Primary. In the event of a failure of the Primary, the Secondary activates its Real-Time Feed, all the Clients then switch to it for feed, and the Primary will also attempt to connect to it for feed like a Client.
Sorry to get deep into it. The ultimate point is that, when set up correctly, there should only ever be 1 Real-Time feed to the CC over the WAN link (assuming the AW is remote from the CC). Also, the Client ICM Setup asks for "Primary" and "Secondary" Distributor hostname/IPs. The connection to Primary or Secondary occurs on 2 different TCP ports, so the Primary entry must be a Primary Distributor, and the Secondary be a Secondary...
Hopefully that all makes sense and is of some help!
Thank you! This is some great info. My question now would be why there should only be 1 Real-Time Feed to the CC? Prior to the upgrade, we have 2 AW in one location able to receive a real time feed. And although I see your point about balancing our AWs between the 2 CC sides, if they are both running across the same link to the CC, will I see any improvement?
Where is the Primary Domain Controller for your ICM domain located? We had a similar issue in our lab environment when we upgraded from 4.1.4 to 4.1.5. It turned out that there are many SQL authentication requests that were going back and forth and we had the PDC at a different location than the Logger. Once we put them on the same LAN segment, everything was fine. Is your Logger acting as the PDC or do you have a stand alone one? That was the other thing we did when we upgraded is move the PDC function off the Logger.
Yes, our Logger is acting as the PDC. Did you move your ICM onto your corporate network, still keeping a virtual private network within your ICM system?