Lync Server 2013. Bulk Enable Enterprise Voice and Conferencing.

Often I am tasked with enabling Voice or Conferencing or both for many users at once. This is how I go about it.

Step 1. Create a CSV file with the following table.
Note: Email can also be UPN, in my environment email and UPN are the same.

DisplayName,Email,Extension,ConferencingPolicy,DialPlan,VoicePolicy

Step 2. Import the CSV and pipe to your commands enabling voice and conferencing.

Import-CSV Extensions.csv | %{ Get-CSUser $_.email | Set-CSUser -EnterpriseVoiceEnabled $True -LineURI $_.extension ; Grant-CsConferencingPolicy -Identity $_.email -PolicyName $_.ConferencingPolicy ; Grant-CsDialPlan -Identity $_.email -PolicyName $_.DialPlan ;Grant-CSVoicePolicy -Identity $_.email -PolicyName $_.VoicePolicy}

Adjust to suit your needs.

Lync 2013. Domain Migration. Users can’t log. Ms-Diagnostics-Fault ErrorId: 28000, Reason: User is not SIP enabled.

Scenario: You’ve moved users to another domain in the same Forest. Users now tell you they can’t sign into Lync via mobile or the internet.

– You’ve checked replication through Toplogy in the Lync console. The Edge Replication is ok.
– You’ve disabled and renabled the Lync account
– You’ve run update-csuserdatabase
– Test-CSRegistration is successful.

Lync Connectivity Analyser for mobile (http://www.microsoft.com/en-nz/download/details.aspx?id=36535) gives you errors like below

Reason: Internal server error (HTTP status code 500)
Ms-Diagnostics-Fault ErrorId: 28000, Reason: User is not SIP enabled.

Solution

Check your CSUserReplicatorConfiguration settings. I found my domain users were being migrated to was missing

PS > Get-CsUserReplicatorConfiguration

Identity                  : Global
ADDomainNamingContextList : {dc=mycomain,dc=co,dc=region,}
ReplicationCycleInterval  : 00:01:00

Run the following

PS > Set-CsUserReplicatorConfiguration -Identity global -ADDomainNamingContextList @{Add=”dc=mynewdomain,dc=co,dc=region”}

You can also run the command below to allow for all domains in your Forest, however I wasn’t prepared to allow connections if people were accidentally (or another reason) added into the root domain.

Set-CsUserReplicatorConfiguration -Identity global -ADDomainNamingContextList $Null

More information: http://technet.microsoft.com/en-us/library/gg398540.aspx

Lync Server 2013. Presence issues, orphaned data.

Lync Server 2013, some funky issues identified. One Pool, Two Front End Servers.

Users connected to FE1 can see status of User X.
Users connected to FE2 cannot see status of User X. User X appears offline for X days.

User can connect to FE1 with username@sipdomain.com
User cannot connect to FE2 with username@sipdomain.com – Username and password is rejected.

Dbanalyze of username@sipdomain.com on each FE server show different results.
FE2 shows old contacts and conference data.
FE1 shows the live and accurate data.

Although a pool with Two FE servers aren’t recommended, they are supported.
http://technet.microsoft.com/en-us/library/gg412996.aspx

The fix

Through further investigation, I connected to each servers RTCLocal Databases, under Resources.dbo I found the user. The ID of the user differed. This looked like orphaned data that was not being cleared.

To resolve, I’d need to remove the user from the SQL Database.  I followed this process

Disable from Lync Server
Delete from Databases

OSQL -S fe1\rtclocal -d rtc -E -Q “exec RtcDeleteResource ‘user@domain.com'”
OSQL -S fe2\rtclocal -d rtc -E -Q “exec RtcDeleteResource ‘user@domain.com'”
 
update-csuserdatabase
Add User
update-csuserdatabase

What causes this?

Each impacted end user, I found had either

 – Left the company and came back
 – Had their account removed and readded for one reason or another

This looks to have been a problem in Live Server, http://support.microsoft.com/kb/885342 . Our organization had followed an upgrade path to date of Live > OCS  > Lync 2010 > Lync 2013.

This appears to be a problem with users who have followed along since OCS or Live, which communicating with each affected person appears to be the case.

At this stage, nuking the users from the database appears to be the resolution. As to the actual cause, I do not know yet. More investigation required.