I'm late to the game here, but you could use a bit of javascript to test if the pub is active and display a link to Finesse based on that.  That way you end up with a single link to the user.  Or even just supply a redirect based on that so the user doesn't have to click a link at all.  I've always hated the somewhat obscure URL needed for agents to login.  It should be more easily aliased or something to ease that pain.  I'd hate for an agent not to be able to do their work because they can't remember what port number to use or even that there is such a think as a port number.   <script src="https://ajax.googleapis.com/ajax/libs/jquery/3.3.1/jquery.min.js"></script> <script> $.get("http://<uccx-PUB>:8445/desktop").done(function () { document.write("<a href=http://<uccx-PUB>:8445/desktop>Finesse Login</a>"); }).fail(function () { document.write("<a href=http://<uccx-SUB>:8445/desktop>Finesse Login</a>"); }); </script>   ... View more

I ran into the same issue going down the same path and this post seems to be the best reference.  Its been a while but figured I'd post for the next guy. Ran into some neat features in the cube config guide for copying fields from the inbound sip header and modifying the outbound with sip profiles.   voice class sip-copylist 3000  sip-header from  sip-header to ! voice class sip-profiles 3000  request INVITE peer-header sip TO copy "sip:(.*@.*)>" u01  request INVITE sip-header To modify "sip:(.*)(>.*)" "sip:\u01\2"  request INVITE sip-header SIP-Req-URI modify ".*" "INVITE sip:\u01 SIP/2.0" ! dial-peer voice 3000 voip  rtp payload-type cisco-codec-fax-ack 111  rtp payload-type cisco-codec-video-h264 97  session protocol sipv2  session target ipv4:172.20.110.20  destination uri 2  incoming uri to 2  voice-class sip early-offer forced  voice-class sip profiles 3000  voice-class sip copy-list 3000  dtmf-relay rtp-nte sip-kpml  codec transparent  no vad   http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube_fund/configuration/xe-3s/cube-fund-xe-3s-book/voi-sip-param-mod.html#task_0DC87B03479A4DD9A81AD2E405CA8EC9 ... View more

I was running into the same thing.  Restarting EM service resolved. ... View more

I know this is a little late, but if you use the enduser telephone field as the extension, you can lookup the userid from the enduser table.  If you pull it from the actual phone you'll have to get pretty complex - joining dnorpattern with devices and then joining devices with enduser controlled devices which may contain more than a single match etc. <sql> select userid,mailid from enduser where telephonenumber='3955' </sql> If you are using the same format of the normal EM login then you have the PIN already and can just use the original style get request (http://<<CUCM IP>>/emapp/EMAppServlet?device=<<DEVICENAME>>&userid=<<USERID>>&seq=<<PIN>>) to call to CM using that same format, but replacing the extension for the username.   I'm looking at a customer right now with similar needs. ... View more

Per our conversation this is a limitation of programing and the work around is to builld out the full dialplan and options for each site.  This causes quite a bit of double work to implement. I have played around and can work around the issue by selecting the NA dialplan and not selecting a DN block, then assigning it through AD during the sync.  I think the ability to have a less than full number avaible block is needed.  The full number block may be best practice, I see it as more hassle for small site deployments who generally do not have e194 number blocks for phones.  We do a good bit of business in the ~1000 phone market and I have not seen a site in the past year that it makes time or feature since to deploy as 11 Digit extensions and then translate back to 4 or 5 digit. ... View more

It is resolved knowing that UPM handles the sync with AD and adds only local users to CM ... View more