In the process of deploying an SfB installation or maybe in the early days of go-live it’s not uncommon for users to report a problem where they’re unable to add people to their Delegates or Team-Call Group list. It’s less common to see this in established installations, but there are genuine reasons why this might happen.
When this problem occurs you’ll typically be able to see the user when you search, but the OK button won’t light up:
Interestingly, my Office 2016-based client’s giving me some extra text – but only intermittently:
If OK isn't enabled, you've picked one or more contacts who can't participate in this activity.
The usual fixes
If you don’t even see the other user’s name appear below the search box, it might just be the address book hasn’t updated. Try entering their SIP address (as “blah@contoso.com”) and they should materialise.
Once you have them visible but not “OK-able”, confirm that the other user’s enabled for Enterprise Voice, as Team Calling and Delegation are EV features.
Next – and more commonly-seen in a brand new deployment – is that the other user has never signed into their new account and it’s not been ‘initialised’. Have them sign in and then repeat this test.
If having the above confirmed you still can’t get OK to light up, try restarting your client and repeat – there might just be a replication lag delaying your success. If all else fails, read on…
Enter “Privacy Mode”
Privacy Mode exists for those deployments where you might have a desire – or a government mandate – for an “opt in” approach to sharing presence information. In this screen-capture it’s enabled:
Here’s how the client reports that privacy mode is active:
If PrivacyMode is disabled, the text around the radio buttons changes:
With “EnablePrivacyMode” $true, you won’t be able to see the presence of any other users – or add them as a Team-call Group member or Delegate – until they’ve changed the radio button in the above image, or added *you* as a Contact. In my Lab this change didn’t manifest for my client instantly, and I was forced to restart the client before I could then see the other user’s presence and add them.
When all Else Fails
They haven’t blocked you have they? It wouldn’t be the first time…
Reference
Acknowledgement
Thanks to my colleague Mike for suggesting the Privacy Mode fix.
Revision History
3rd Feb 2018: this is the initial post
– G.
“confirm that the other user’s enabled for Enterprise Voice, as Team Calling and Delegation are EV features.”
Some vague wording here: the devil lies in the fact, whether both ME and my TEAMMATE must be EV-enabled to form a team-call-relationship (initiated by ME and answered by HIM)
Hey Soder,
You’re 100% correct. I didn’t think it necessitated making that distinction above, because if *you’re* not EV-enabled, you won’t even be presented with the Call Forwarding option in order to find yourself in the predicament depicted!
– G.
I’ve totally run into this before. Usually because the customer has incorrectly configured EV on the delegate.
another great article Greig.
I’ve had issues adding CAP’s to a Team-Call group, some would show up others not when using the SfB client, the only solution I found so far is to use SEFAutil, then I can add a CAP and as soon as I do it it shows up in the Client as a Team-Call group member.
Here is the command:
SEFAUtil.exe /server:fe.contoso.com sip:xxxx@ /addteammember:yyyy@
To enable it add /simulringteam to add a delay /delayringteam z
I had this same exact issue for a customer I support and I ended up finding that Telephone number field in AD for whatever reason was not populated with a number despite the user being EV enabled.
After adding the number to the telephone field in AD and wait for it to sync across the user was able to add the same user as a delegate. OK button was then NOT greyed out.
This worked for me, may be a different case for others.
We encountered this issue with a user who had signed in to Skype for Business, but only with the Mac client. After signing them in to the Windows SfB client, the issue was resolved.