Jabber Custom Tab link disappearing after network move

[leonardjam1]

We recently enabled OAuth for Jabber (ver 14.1) to support push notifications for MRA.  That's hasn't gone great but really our biggest issue is our custom tab blanking out on the client whenever users swap networks.  

We run a 3rd party ACD login screen out of custom tab on Jabber.  It's just a URL in the config that offers login.  We've never had issues before enabling OAuth.  We've been working with TAC but still not seeing progress.  

The scenario is a person is working on Net, no issues with Jabber or custom tab.  They disconnect from the work network, go home and fire up the VPN and after Jabber is up and running the custom tab is blank.  Showing "view page source" shows no URL info. The other scenario is it works when they're home but as soon as they're back at work on-net, the custom tab is blank again.

The hardest part about this is it's intermittent.  We did enable the parameter

"<RefreshCustomTabsOnNetworkChange>true</RefreshCustomTabsOnNetworkChange>"

but that didn't appear to make a difference.

We also still see the tab URL info clearly listed in the "jabberAllConfig" out of the problem reports.

I'm convinced it has something to do with Jabber connecting via MRA before the user logs in to VPN, this is pretty normal but again, no issues previous.

Anyone run into anything like this?  Again, the intermittence is driving us crazy.  I can't duplicate it to save my life but I have a coworker how sees it every day or so.

We're on 12.5 SU3 for UCM/IMP.  Ver 14.06 on the Eways.

We're about to send a ton of ACD folks home to work off VPN and we're rushing to see this fixed.

[Robert Profit]

@ leonardjam1 Hello!
If the clients are starting to discover and connect to services before the VPN is up, they could be connecting via MRA and custom Tabs are NOT supported via MRA.
Jabber 14 Planning Guide 
If the intent is to have the clients connect after VPN is established, you could always disable the client from starting when the machine OS starts. This would require the user to manually start the client once connected to VPN.

Jabber 14 Parameters Reference Guide <Start_Client_On_Start_OS>true</Start_Client_On_Start_OS>

Additionally, you should be able to find the client attempting to resolve the Custom Tab in the logs and the error that is encountered.

Hope that helps!

Rob

[leonardjam1]

Hi Rob, understood and thank you.  This is tough because we still want the Jabber client to work immediately (preferably regardless of on/off network).  It's okay if the custom tab doesn't load/work when they're MRA.  We just need to start loading properly as soon as they're back connected to on-net.

The odd thing is that we'd had no issue with this until OAuth was enabled.  Our likely fix, to ensure users can go from work to home to vpn, etc, is to disable OAuth and just live with push notification not working.

Thanks

[leonardjam1]

Hey Rob, additionally we're scouring the logs right now to figure out when the error has been encountered but, to the best of my understanding, we and TAC haven't definitively caught it.  I'm turning my attention to that now, as I get those problem reports (thus the challenge in not reproducing it myself)

[Robert Profit]

Definitely easiest to open up the log files in multi-tabbed text editor of your choice. Then do search/find for the URL across all log files. If it is not in there, it may have been overwritten as I believe there are about 10 log files total. Let me know if you find anything in the logs!

[TechLvr]

Since you think the issue has to do with MRA, and also @Robert Profit confirmed Customs Tabs are not supported via MRA, can you test restricting MRA for a few users by configuring a MRA Access Policy? This way they can only connect on net or via VPN. If this works, you may have to consider applying the change to all remote agents to avoid this issue. If they connect via VPN, they may not need MRA anyways. 

You can use link below for instructions on how to configure the policy. your version of CUCM and Exp supports this feature so you should be good there. 

https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/12_0_1/systemConfig/cucm_b_system-configuration-guide-1201/cucm_b_system-configuration-guide-1201_chapter_01011010.html#task_F3E0C536FD10B3E92C338CF12BB33721

[leonardjam1]

Hi TechLvr, thanks for the offered solution, good to keep in mind.
The rough part is the "need" to keep MRA working, even for ACD users.  What we now see but can't quite understand why it broke (after enabling OAuth) is that b/c we set pre-load parameter to "true" the custom tab tries to load once connected via MRA, before the users connects on the VPN. Once the tab shows the 404 or whatever error, it won't re-connect once back on the network (either via VPN or on-net).  Most frustrating is that you HAVE TO RESET Jabber once it breaks.  Restarts/Reloads/powering on/off won't repair it.  Really seems like a bug or something odd.  Though it's fully related to the MRA piece.

Unfortunately TAC hasn't been very helpful and we've sort of thrown in the towel on trying to see why.

Our solution is to set "preload = false" which then means the tab won't load until it's clicked on.  This means it should be fine for the vast majority of ACD users who won't try and use the tab until they're back on-net.

Not totally happy with this but it'll do for now, we're sending ACD users home to work off VPN next week so we're just doing final CYA before we update the overall JAbber config.

Thanks.

[TechLvr]

@ leonardjam1 When you configure APN, OAuth Refresh logins setting is a completely optional feature. 
If you think OAuth Refresh Logins is causing more harm than good, I would say then try disabling that in CUCM and Expressway. Your APN will continue to work.

Refer to the document below.
https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/push_notifications/cucm_b_push-notifications-deployment-guide/cucm_b_push-notifications-deployment-guide_chapter_01.html#task_365B20FC1DAB9D64DB7743657480B34C 

[leonardjam1]

@TechLvr Interesting suggestion.  I'm afraid we hadn't considered what enablements of Oauth were leading to the issue, just that OAuth is likely the issue.  Unfortunately the user side of our company has sort of rejected our current solution of setting preload to false.  They are asking us to turn off OAuth to return the custom tab behavior to how it operated previously.  They want avoid the issue altogether as Jabber resets really frustrate our users.  Much of my frustration is from TACs inability to explain how/why it started happening at all, or can it be fixed with keeping OAuth on. Thanks for the help.

[leonardjam1]

An update but not a solution.  We've found that the issue resides with a .dat file 
%userprofile%\AppData\Roaming\Cisco\Unified Communications\Jabber\CSF\Config\edge-config.dat

If/when there's a network change and Jabber doesn't successfully connect back on net, this file is responsible for either corrupting or offering an incorrect state of the URL for the custom tab.  When the blank tab occurs, you can delete this file, sign out/in and then the tab displays the right webpage (if you're back onnet /vpn)

We're, very, very quickly, trying to write a script that detects a network change, closes Jabber/deletes the file/launches jabber.

TAC is aware but still not offered any solutions.  Hoping that changes.

We further tested that if you disable MRA via the user profile, the file never gets created thus we never get the blank tab.  Frustratingly, MRA is a requirement for our users and you can't pick the device you turn off MRA (disable is user specific).  Even blocking connections out the Eway don't matter, simply the fact that the client expects MRA and sees a network change can lead to it.  We did change the tab to preload "false", this reduces the issue but doesn't stop it.