Phone Number Mismatch

I have been at many sites where the phone numbers on the AD contact is not the same as what is configured on Lync/SfB (Skype for Business).

Since SfB is the single source of truth when it comes to which number the user will ultimately answer on; I have devised a quick script that will match those two numbers up, and make sure that all AD contacts that have a Lync/SfB account have the correct phone number associated with them.

Hope this helps a few people out there...

P.S. This script can be easily modified to make other changes to contacts as required.

Download
v.0.1 - 2016-07-18 -Invoke-CsNumberMatch.v.0.1.zip

Sonus SBC Call Actions

I haven't found a place that explains the real life use case for this; so I thought I would write one for anyone that may search one day for how to do this.

I usually use this as a first step in the call flow, to manipulate the call before it gets to the routing stage.

As a simple example (don't want to get too complicated here). Let's say you want to mask certain caller IDs based on the "department" field in AD.

First thing, you need to setup the AD integration (lots of details on Google about how to do this), and make sure you synchronise (or otherwise leave it set to online) the AD attributes:

• msRTCSIP-Line
• department

Once you have got that working, you should create a manipulation table that will make the required changes to your call based on certain rules. In our case, it should check the "department" field and change the CallingNumber based on that.

Next an "Action" needs to be created to direct the call flow. In our example, we need to call to continue down its path regardless of the outcome.

This action will need to be used in an "Action Set" to modify the call flow. Again, in this case, we will allow the call to continue down the same path regardless. Quick gotcha here, the "Continue" option in the "Action Set" does not mean continue the call; it means continue the processing of the rules, so if you put "Continue" the call will fail...

Finally, you need to apply this "Action Set" to a signalling group for it to take affect. In our case, we will apply it to the "To/From SfB" so that it will be intercepted before the call is made out to the PSTN...

New Year ... New Holiday Lists

Since its the new year, and everyone is updating their RGS holiday lists, I thought I would contribute with a quick one-liner to help all those who want to quickly view which RGS groups have what holiday lists (you would think Microsoft would make that easier for you).

$Workflows = get-CsRGSWorkflow
$Holidays = @()

foreach($Workflow in $Workflows){

   $List = @($Workflow.HolidaySetIDList)
   $S = ""
   if ($List){
     $S = [string]::Join(", ",($List |%{$Holiday = $_;Get-CsRgsHolidaySet -ShowAll|?{$_.Identity -match $Holiday.InstanceId}}).Name)
   }
   $Workflow |Add-Member "HolidaySet" $S
   $Holidays += $Workflow |Select-Object Name,LineURI,Language,TimeZone,HolidaySet
}

return $Holidays

Changing the primary SIP domain

Recently I came across a situation where it was necessary to change the primary SIP domain for a Lync 2013 customer (although this will work for any Lync or Skype for Business deployment). This is not a very difficult process but there are a few gotchas which I would like to share...

1. Make sure that you change the SIP address for all your users after making the change to the new SIP domain
2. Make sure you run the bootstrap after you have made the change on all servers
3. Make sure you modify all your RGS workflows to use the new SIP domain
4. Finally, and the hardest one (because its not documented anywhere); you will need to manually edit the application contacts using ADSIEdit.exe to use the new SIP domain

 Changing the Application Contacts

First open ADSIEdit and go to the configuration node, and navigate to the Application Contacts folder:

 Once there, open each entry and modify the msRTCSIP-PrimaryUserAddress and Proxy address to use the new SIP domain:

 

Don't forget to restart the services that you have changed !!

Lync/SfB Disabled your AD Disabled Users

I have noticed this with many customers I have visited. Their off-boarding process usually misses disabling the user from Lync/SfB.

The end result is that users being disabled in AD are still active and visible in Lync/SfB; this also has licensing implications, especially with today's O365 licensing and auditing. Add to that, the DID number assigned to the user will still be in use and will not be freed up.

I came up with this script that will quickly go through the AD/SfB environment and spit-out (or also disable) all users that are already disabled in AD.

Download
v.0.01 - 2015-09-06 - Get-CsDisabledUsers.v.0.01.zip
v.0.02 - 2016-05-17 - Get-CsDisabledUsers.v.0.02.zip

Lync Mirroring Status Disconnected

Ok, this is a very quick one that caught me by surprise. At one of our customers; changes to the Lync settings were not taking affect. Checking the replication status, I found that replication was down for over 10 days. Running "Get-CsManagementStoreReplicationStatus" I found ...

This immediately pointed me to the SQL servers. When I checked the servers, I found the primary server was completely down. The mirror server had taken over as the principle, but apparently, Lync wasn't talking to it :( ... Checking the mirroring status "Get-CsDatabaseMirrorState" confirmed this limbo state ...

Looking at the SQL Managment Studio on both servers; I found that both servers were showing the databases as "Principle"; while the failed server was showing "Principle, Disconnected / In Recovery"; the mirror server was showing "Principle, Disconnceted"

Solution

After a bit of research and asking around; I came to this article, which helped resolve the issue. I have summarized the steps below, so that it is easier for anyone searching for this in the future...

1. Connect to Mirror DB server
2. Click on "New Query..."
3. type the command "alter endpoint mirroring_endpoint state=stopped"
4. Press the button "Execute"
5. Wait until the command completes, at this point you have disabled the replication between the servers.
6. Execute the command "alter endpoint mirroring_endpoint state=started"
7. This will re-start the mirroring process, and this time, the database server will see the primary server as up, and will start replicating back to it the information that it lost.

At this point you have two options, of either leaving the second SQL server as the principle, and the original one as the Mirror, or you can failover the Databses back to the original state. In both cases, Lync doesn't mind, and doesn't care.

Sonus SBC AD Lookup Gotchas

I have recently been troubleshooting issues with a Sonus SBC 1000 doing call routing using AD lookups.

There are many blogs out there about how to do this, including the guide from Sonus themselves which is pretty descent.

Let me however, go into some of the gotchas that caught me by surprise, and are not well documented on the Sonus site...

AD Cache Lookup

There is a very clear note saying that it is "recommended" to have a USB stick attached to the SBC if you are going to use the AD Lookup in cached mode.

What there is no mention of, is the way the Sonus SBC uses the cache, and how it gets updated. This information was provided to me from Sonus TAC/Engineering, and is current as of the date of publishing this blog post; this applies to having the AD Configuration in "Updates" mode...

1. All domain controllers configured are treated equally; i.e. if any one of them responds back with a successful query, than the cache is valid, even if all the other queries fail.
2. The cache is dropped before the new cache is read; thus if the AD query fails, the system is left with "NO CACHE" unless you have a USB stick with a backup cache to be used.
3. if "ALL" domain controllers fail to respond, the SBC switches to online mode, and tries to query the domain controllers in order for the user in question.
4. The system will not try any failed domain controllers again until the next update cycle as configured in the "Cache Settings"

they have said that they are working on improving the process...

Case Sensitive Lookup

Apparently the lookup is case-sensitive; while simply testing for "=msRTCSIP-Line=" in your transformation table may work most of the time, if a Lync administrator decides to type "Tel:+xxxxx" instead of "tel:+xxxx" the query will fail to return a positive match.

To overcome this issue the recommendation is to use "(?i)=msRTCSIP-Line=" which would make the lookup case-insensitive.

Of course you can use the same "(?i)" in other locations too for matching without case.

 Lookup Limits

Transformation table lookups on the SBC have a hard limit of 256 characters for the string being manipulated. This is a hard limit and as per the Engineering team, the registers were never meant to hold large strings of data (such as memberof fields.

This is a major draw-back if you do routing based on group memberships or on other fields which may exceed this hard limit.

Lync Edge Certificates

Are you getting problems starting your Edge service role ?

Is your Edge service going crazy about the certificate being not accessible ?
Do you get this dreaded error message from EventID: 14591

Event ID: 14591

Error 0xC3FC7D95 (LC_E_VALIDATION_CERT_NO_KEYEXCHANGE)

Cause: The certificate may have been deleted or may be invalid, or permissions are not set correctly.

Fear not, you are not alone, after banging my head against the wall for a few days, rebuilding the Edge server from scratch, and trying out a bunch of different certificate templates; I have finally found the solution...

Although Microsoft Windows is happy with many types of Crypto Providers; alas, Lync on the other hand, only likes the "Microsoft RSA SChannel Cryptographic Provider"

Next time you want to issue a certificate, make sure you choose the "Microsoft RSA SChannel Cryptographic Provider"

To make this more informative, I have added below the certificate template options that should be used for generating Lync certificates...

• Don't select to publish to AD, as Lync Edge can not access the AD and is not authorized to do so:

Template - General Tab

• Choose the Purpose to be "Signature & Encryption" and allow "Private Key to be Exported"

Template - Request Handling Tab

• Choose only the "Microsoft RSA SChannel Cryptographic Provider"

Template - CSP Selection

• Choose the Application Policies to be "Server Authentication"

Template - Extensions Tab

• Choose the Key Usage to be "Allow key exchange only with key encryption"

Template - Extensions Tab

Get-CSUserForwards

I was asked recently to come up with the best way to figure out which users were forwarding their land-line to another number (e.g. mobile) or to another user.

I came up with the idea of using SEFAUtil to figure out all the currently enabled users' setting.

# Initialize Variables
$AllUsers = @()
$Count = 0

# Define Location of SEFAUtil
$SEFAUtil = "C:\Program Files\Microsoft Lync Server 2013\ResKit\SEFAUtil.exe"

# Get Application Pool Server to use
$LyncServer = Get-CsTrustedApplication | ?{$_.ApplicationId -eq "urn:application:sefautil"}|%{$_.TrustedApplicationPoolFqdn}

# Get Lync EV Enabled Users
$LyncUsers = Get-CsUser | where {$_.EnterpriseVoiceEnabled -eq $true}
$TotalUsers = $LyncUsers.Count

# Loop for each one and get details
Foreach ($LyncUser in $LyncUsers){
    $Destination = $Null
    
    #Convert User SIP to lowercase
    $UserSIP = $LyncUser.SipAddress.ToLower().Replace("sip:","")

    #Write Progress
    $Count += 1
    Write-Progress -Activity "Processing Users" -status "User $UserSIP" `
        -percentComplete ($Count / $TotalUsers*100)

    #Do the magic
 &$SEFAUtil /Server:$LyncServer $UserSIP| Tee-Object -Variable output|Out-Null

    #Split the output to lines & convert to an object
    $parts = $output -split "`n"

    #Figure Out Destination  
  $Destination = ($parts[4] -split "to: ")[1]
 If ($Destination -eq "") {
    } ElseIf ($Destination -Match "user=phone") {
     # Destination is a number
  $Destination = $Destination.Split("@")[0].Split(":")[1]
 } Else {
  # Destination is a SIP address
        write-output $Destination
  #$Destination = $Destination.Split(":")[1]
 }

    #Display information
    $Data = New-Object -Type PSObject -Property @{
        SIP = ($parts[0] -split ": ")[1]
        Name = ($parts[1] -split ": ")[1]
        EVEnabled = ($parts[2] -split ": ")[1]
        SimRing = ($parts[3] -split ": ")[1]
        ForwardTo = $Destination
    }
    $AllUsers += $Data
}

Your feedback is always welcome.