A place to ask questions, connect with others, and stay in the know
Dear Community members, We are currently working to provide seamless login option for our CC agents between Primary & Backup site.Before I state the problem, let me give brief background of our environment.CURRENT ENVIORNMNET & BEHAVIOURWe have 2 sites - primary & backup, both with their switchover pair of servers. Currently, CC agents are login to client application using FQDN dedicated for each site, as follows:For Primary site:cic-osn.intra.mydomain.com ==> (SSOSN2065: Primary IC Server & SSOSN2066: Backup IC Server)For Backup site:cic-fkn.intra.mydomain.com ==> (SSFKN2065: Primary IC Server & SSFKN2066: Backup IC Server)At present there is no issues in login when agents use the FQDN for induvial sites.DESIRED SOLUTION & EXPECTED BEHAVIOURAs during troubles/maintenance users' needs to switch between sites, they need to manually change the FQDN of available site on client application login. e.g., if they were using primary site FQDN: *cic-osn.......*) & need to switch to backup site, re-login is required with FQDN: *cic-fkn......* & vice-versa.In order to avoid this manual switch, we want to implement new DNS as follows:cicuat-login.intra.mydomain.com, which can be switched using automated batch job between cic-dev.intra.mydomain.com & cic-uat.intra.mydomain.comWe have created this switching job & DNS switching is done perfectly but when login to Interaction Desktop, it doesn't use the switched DNS information. rather, it usage the previous information which was cached in *SessionManagerClusters* file under user's local profile.*C:\users\serv_tst_icadmin\AppData\local\Interactive Intelligence* path.As client applications are always referring the cache information, updated DNS values are not used, which restricts us to implement the desired solution.Kindly review the screenshot from the test & let us know how to address this.I there is any server parameter which can be added to avoid looking into cache file, please suggest that too.Regards,Subhash Srivastava
Hi there. When you reference "Primary Site" and "Backup Site", are these sites nodes in a single Switchiver pair? Or are they completely independent PureConnect instances?
If they are nodes in a SO pair, there are published ways to configure DNS to allow clients to connect to the SO instance without having to manually update the server host name.
Hi Chris, Thanks for your response.No, Primary & Backup sites are having their own individual SO pairs.We are using different DNS records for Parimry & Backup sites & there is no issues.Primary site is used with cic-osn.intra.shinseibank.com for switchover pair SSOSN2065/SSOSN2066.Backup site is used with cic-fkn.intra.shinseibank.com for switchover pair SSOSN2065/SSOSN2066.Issue is faced when we are trying to use another DNS record CICUAT-login.intra.shinseibank.com to switch between Primary & backup sites.For normal scenarios: CICUAT-login.intra.shinseibank.com ==> cic-osn.intra.shinseibank.comFor Maintenance: CICUAT-login.intra.shinseibank.com ==> cic-fkn.intra.shinseibank.com (by switching DNS record)When we login to client application using CICUAT-login.intra.shinseibank.com in normal scenario, for first time, CIC resolves the DNS to cic-osn.intra.shinseibank.com (Servers - SSOSN2065, SSOSN2066) & update this information in SessionManagerClusters file.In trouble scenario, when we switch DNS to Backup Site (CICUAT-login.intra.shinseibank.com ==> cic-fkn.intra.shinseibank.com), we expect that CIC should connect to cic-fkn.intra.shinseibank.com, however it doesn't perform DNS resolution again but uses cached information from SessionManagerClusters file & keeps connecting to cic-osn.intra.shinseibank.com.Would like to know if there is any way to force CIC to lookup up DNS on every login instead of referring to SessionManagerClusters file.Regards,Subhash Srivastava
Unfortunately, PureConnect is designed to work with SO pairs and avoid multiple disaster scenarios. It sounds like you have DNS set up correctly for the pair, but what the client actually does is to cache both the Primary and Backup information when it connects to either. This means that even if you connect t a specific server, as long as it's accessible (even as backup) during the first connection, all future attempts will connect to whichever is Primary, regardless of whether one or both is functional.
For most people, this works well, but I'm afraid it does mean that the caching prevents it resolving DNS on every attempt, which your scenario would require. I'm not sure if there is a way to reduce the Cache timeout. You could try putting /notifier=<fqdn> on the command line (not sure if that forces it to ignore cache...) If it still screws up, you could have two icons....
For clarity, what most folks do is to have a single SO pair with one on each site, if you have a backup site. This takes some additional configuration, depending on bandwidth etc. When it comes to maintenance, you do one server at a time and can have almost zero downtime - a second pair should not be necessary.
------------------------------Paul SimpsonEventus Solutions Group------------------------------
------------------------------Subhash SrivastavaSBI Shinsei Bank, LimitedOriginal Message:Sent: 06-08-2023 16:40From: Chris MayoSubject: Interaction Desktop doesn't use IC Server Hostname resolved by DNS
------------------------------Chris MayoDirector, Professional Services - GenesysConvergeOneOriginal Message:Sent: 06-07-2023 01:40From: Subhash SrivastavaSubject: Interaction Desktop doesn't use IC Server Hostname resolved by DNS
#AskMeAnything(AMA)------------------------------Subhash SrivastavaSBI Shinsei Bank, Limited------------------------------
Paul is correct. Ideally, you would use a SO pair with geo-diversity to provide for the maintenance and DR scenarios. I have a few thoughts, but admittedly, it's been a bit since I worked in the PureConnect space, but I believe the following are still applicable and valid.
If there is no SessionManagerCluster file to reference, the active SO team member you're contacting will provide a new one. Can you script the existing reference file to be deleted or renamed to force a new one to be created?
For DNS caching in Windows, you can run "ipconfig /flushdns" to force the TCPIP stack in the OS to clear its DNS cache. This may or may not be affecting this scenario but something to consider.
Thanks Paul & Chris for your suggestion.Unfortunately, we don't have liberty to change the design as it is already in production & used since very long.We have to maintain 2 independent sites (Primary & Backup) with their own switchover pairs.Only possibility that I can see here is what Chris has suggested to remove SessionManagerCluster file on every logon.I am wondering if there is any adhoc parameter available for server parameters to do that or not else writing a scripts could be an option.Let me try some alternates & update you back.Regards,
Hi Chris, Paul, This is to update you on the progress.We have created custom batch scripts to execute following 2 steps.1 - On execution, first delete the existing SessionManagerCluster file from user path - *C:\users\serv_tst_icadmin\AppData\local\Interactive Intelligence*2 - Run client application (Interaction Desktop or Interaction Administrator or ICBM) using (start InteractionDesktop.exe /notifier=cicuat-login.intra.shinseibank.com)Provide new shortcut for applications (Interaction Desktop or Interaction Administrator or ICBM), which executes above batch file.This work as before login SessionManagerCluster file is deleted & client apps are forced to refer to DNS resolution on every login.Hope this would not impact any other functions & solution would be still supported by Genesys Support.
Check out the Genesys Knowledge Network - your all-in-one access point for Genesys resources
Every year, Genesys® orchestrates more than 70 billion remarkable customer experiences for organizations in more than 100 countries. Through the power of our cloud, digital and AI technologies, organizations can realize Experience as a Service℠, our vision for empathetic customer experiences at scale. With Genesys, organizations have the power to deliver proactive, predictive, and hyper personalized experiences to deepen their customer connection across every marketing, sales, and service moment on any channel, while also improving employee productivity and engagement. By transforming back-office technology to a modern revenue velocity engine Genesys enables true intimacy at scale to foster customer trust and loyalty.