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 (http://technet.microsoft.com/en-us/library/gg398806(v=ocs.14).aspx).
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\user21@fabrikam.com
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 can either manually edit the SQL Databases on each FE that contains a replica for the users or use the SEFAUTIL.
1. SQL Queries to remove delegates – this needs to be ran against each Frontends RTCLOCAL SQL instance against the RTC database. This needs to be done on each Frontend individually because the IDs change between servers.
a. Browse to the Frontends RTCLOCAL\RTC-->dbo.Resource table and ran the query below
i. Select * From [rtc].[dbo].[Resource] Where UserAtHost = 'user20@fabrikam.com'
ii. Select * From [rtc].[dbo].[Resource] Where UserAtHost = 'user21@fabrikam.com'
b. Note down the ID numbers. Example below:
i. Delegator = 123
ii. Delegate = 456
c. Open a new SQL query and run the below command for each user listed under “People I manage calls for”
i. DELETE FROM [rtc].[dbo].[Delegate]
WHERE DelegatorId = '123' AND DelegateId = '456'
GO
d. 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.
2. SEFAUtil - I haven't always had success with this command but in some cases it worked.
a. Install and configure the SEFAUtil per this article
i. http://blogs.technet.com/b/jenstr/archive/2010/12/07/how-to-get-sefautil-running.aspx
b. Run this command for each delegator in the “People I manage calls for” list.
i. SEFAUtil.exe /server: lyncserver.contoso.com sip:user20@fabrikam.com /removedelegate:user21@fabrikam.com
Now try managing this for a medium to large organization and you can easily see why this is not preferred. With Part 2 we will look at the same experience if the delegating user is Lync Enterprise Voice enabled.
