Lync 2013 Delegates Pt.1 (Non Lync Enterprise Voice enabled delegation)

Lately I have seen some confusion around delegates between Exchange and Lync that I wanted to help clear up. The unknown variable seems to be whether the user needs to be enabled for Enterprise Voice within Lync to setup Exchange delegates. Exchange delegates within Lync can be setup regardless of whether or not the user is Enterprise Voice enabled but there are gotcha's that admins need to know. In this first part we will talk about Non-EV users setting up delegates and in the second part we will look at the same experience when delegating users are EV enabled.
Delegator is not EV enabled within Lync
Delegator (Manager) = User20
Delegate (Assistant) = User21
By default, the client user policy is not enabled for "EnableExchangeDelegateSync". So let's see what happens if we try to schedule a meeting and then add Lync details to that meeting. User20 went into Outlook, clicked File, Account Settings, and then Delegate Access. Within delegates they added User21 to delegates as an Editor of their calendar (Figure 1). Now lets add User20's calendar to User21 (Open Calendar) and click New Meeting (non-Lync). This works successfully as it should because we only created a meeting within Outlook\Exchange (Figure 2). Now what happens if we select "Lync Meeting"? You will see we get the error in Figure 3. This is due to the fact that we haven't enabled the "EnableExchangeDelegateSync" option on User20's Lync client policy.

Figure 1: Manager (User20) delegating access to User21

Figure 2: User21 creating a new meeting for Administrator

Figure 3: User21 trying to add Lync meeting options as User20

Now let's set User20's Lync client policy to EnableExchangeDelegateSync. This will enable the sync from Outlook\Exchange to Lync. Remember User20 must logout and back in to get this new policy.

1.       Set-CsClientPolicy <policy_name> –EnableExchangeDelegateSync $True

Now that the policy is in effect, User21 sees the message below informing them they have been added as a delegate for User20 and a new group named "People I manage Calls For" gets created with User20 as a member (Figure 4). User21 should also now be able to create Lync meetings for User 20 (Figure 5).

Figure 4: User21 added as delegate for User20


Figure 5: User21 can now successfully create a Lync meeting for User20

There is one thing I want to mention about this whole process before going into why this isn't the preferred method.

1.       In order for delegates to get synced from Outlook\Exchange to Lync the Outlook client must be open on the delegator's machine. The reason for this is because delegation uses MAPI only and not EWS (

2.       The "You were added as a delegate for User20" banner notification will be displayed each time you login to each computer until you click the X to dismiss the notification. The notification gets written to the registry keys below (Figure 6). Once you click the X to dismiss the notification User20 will be removed from the "Outstanding DelegatorList" key and added to "Dismissed DelegatorList" so the banner is no longer displayed on this computer for that specific user.

a.       Location - HKCU\Software\Microsoft\Office\15.0\Lync\

b.      Last DelegatorList – current list of delegators.

c.      Outstanding DelegatorList – display the banner for users listed under this key

d.      Dismissed DelegatorList – Once User21 clicks the X next to the banner that sip uri will get moved under this key so it doesn’t display that message again on this computer.


Figure 6: Registry keys for delegation


That seemed fairly easy so why is this not the recommended method of creating delegates? The main reason is because when Lync writes the delegate list to the BE database it’s a one-time create record. This means that the record never gets removed from the BE database unless done manually. The behavior described can cause issues when User20 removes User21 from their Outlook delegate list. When that happens User21 will no longer be able to create Lync meetings for User20 but will still see the "People I manage calls for" group and still get the notifications "You were added as a delegate for User20".
In order to get rid of all the remnants of the delegation between User20 and User 21 you need to have the delegator (User20) go into their Lync Client and remove delegate (User21) from "delegates" group.
Close User20's Lync client and sign back in. You will now see the message below and the registry keys will be updated (Figure 7). At this point all the remnants are now removed.
With Part 2 we will look at the same experience if the delegating user is Lync Enterprise Voice enabled.
Thanks to Jimmy Vincent for help with this scenario!!
Comments (9)
  1. Nice write-up… I ashamed to admit I hadn’t considered delegating the creation of Lync meetings.

  2. Neerajj says:

    Hi Richard, thanks for your response. Can you point me to what I should be looking for in the BE database to conform that Delegation is in place? Is there also some "msRTC.." attribute that also gets set by the delegation action?

    This was the other way of doing non-EV delegation (
    that also did not work for me.

  3. @NJ – Is the delegation record getting put in the BE DB? I have seen cases where the sync to the BE got stuck and to clear that request we had to have the delegator and delegate both close their Lync clients, delete the delegators Lync profile, reboot
    computer, and then both log back into Lync. I would say if you are working with support they will be able to resolve it and more than likely will have you try this.

  4. ryan says:

    I’ll be interested to read the 2nd part. Can you also elaborate on what happens as users who are NOT EV enabled then become EV enabled? Is there still cleanup?

  5. Me says:

    Thanks alot

  6. NJ says:

    Interesting read, but I’ve not been able to get delegation work in a non-EV environment using either the policy method or the sefautil method. Have not yet seen the prompt "You have been added as a delegate for xyz". Instructions are simple enough, so
    not sure what I could be overlooking. Have a case opened with MS, and they are stumped for the moment too. Any ideas what else I can check on 🙁

  7. Anonymous says:

    In the first part of this article we discussed delegation within Lync and OutlookExchange when the user

  8. Greg Seeber says:

    thank you very very much for this. We were really struggling with it – and, honestly, I did not know of the extreme importance and significance of -EnableExchangeDelegateSync flag. Thanks for the write-up!

  9. WilfredB1 says:

    For the most part I have not had any issue working on a non-EV environment, but there are a couple of users where nothing works, even try SefaUtil (that is meant for EV only), on top of it, few keep getting the yellow notification over and over.

    I had twice opened an incident with Microsoft and they have not find a way to fix this issue.
    Has someone found out a way to solve this issue?

Comments are closed.

Skip to main content