Pages

Showing posts with label Lync Powershell. Show all posts
Showing posts with label Lync Powershell. Show all posts

Monday, June 6, 2016

PowerShell Script to Add Normalization Rule to Multiple Dial Plans


During some recent Lync and SfB deployments, there has been a need to add a normalization rule to all existing dial plans or only user dial plans. Of course, the easiest way to add the same normalization rule to multiple dial plans is to script it. So here is the info for the script as well as the script itself:


First create the normalization rule in one of the dial plans. For example, you can create a "Catch All" rule in the Global dial plan that will normalize any number to prepend it with a +. The rule will look like this:

Normalization rule name: Catch All
Pattern to match: ^(\d*)$
Translation pattern: +$1

So the idea is to copy the normalization rule that you just created in the Global dial plan to all the User dial plans that already exist (I will explain later how to copy to All dial plans including Site dial plans later in this post). What the script is doing is getting all dial plans that begin with Tag:. This is how User dial plans are identified. Then it will get the normalization rule settings and copy them into all the User dial plans. Here is the script:

$DialPlans=Get-CSDialplan -Filter Tag:*
$CatchAll=Get-CsVoiceNormalizationRule -Filter "Global/Catch All"

foreach ($D in $DialPlans) 
{
Write-Host ("Adding Catch All Normalization Rules to Dial Plan: " + $D.Identity)    
ForEach ($Rule in $CatchAll) {New-CsVoiceNormalizationRule -Parent $D.Identity -Name $Rule.Name -Description $Rule.Description -Pattern $Rule.Pattern -Translation $Rule.Translation -IsInternalExtension $Rule.IsInternalExtension | Out-Null} 
}

If you didn't create the rule in the Global dial plan but in a User dial plan, you would change the -Filter parameter in the second line of the script to be the name of the dial plan/normalization rule name. If you are not sure how to find that out, run the Get-CsDialplan cmdlet and get the name of the dial plan. For example, a User dial plan will look like this: Tag:NA-HoustonDP. User dial plans start with Tag: while site dial plans start with Site:. Then put a forward slash and the name of the normalization rule in that dial plan. Make sure to put quotes around the whole dialplan/normalizationrule name if you have spaces in the names.

So by default, this script will add this "Catch All" normalization rule to the User dial plans and it will be the last normalization rule in the list of normalization rules. The order can be changed by setting the -Priority parameter. Be careful with this though because if you have a lot of global dial plans, you will need to make sure that it doesn't take precedence over some of the normalization rules it shouldn't. Otherwise, you will have to go into each dial plan and move the rule to the appropriate order.

Also, you can narrow the dial plan selection down to just site dial plans by changing the -Filter parameter on the first line of the script from Tag:* to Site:*. This will choose just the site dial plans to add the number normalization rule. And if you want to add the normalization rule to all dial plans, just remove the -Filter parameter all together.

Hope this helps. Let me know if you have any other questions, comments or issues.

Friday, July 12, 2013

Lync 2013 Server Prerequisites on Server 2008 R2 SP1

The following Powershell cmdlets will install the system prerequisites for Server 2008 R2 SP1:

Import-Module ServerManager

Add-WindowsFeature RSAT-ADDS,desktop-experience,Web-Server,Web-Static-Content,Web-Default-Doc,Web-Scripting-Tools,Web-Windows-Auth,Web-Asp-Net,Web-Log-Libraries,Web-Http-Tracing,Web-Stat-Compression,Web-Dyn-Compression,Web-ISAPI-Ext,Web-ISAPI-Filter,Web-Http-Errors,Web-Http-Logging,Web-Net-Ext,Web-Client-Auth,Web-Filtering,Web-Mgmt-Console,msmq-server,msmq-directory,Telnet-Client

Then download and install the following:
.NET 4.5 Framework (install this before Powershell 3.0) - http://www.microsoft.com/en-us/download/details.aspx?id=30653
Powershell 3.0 - http://www.microsoft.com/en-us/download/details.aspx?id=34595
Windows Identity Foundation - http://www.microsoft.com/en-us/download/details.aspx?id=17331
Windows Update (heap corruption in IIS 7.5) - http://support.microsoft.com/?kbid=2646886

I have not had a chance yet to test this yet as I only installed Lync 2013 on Server 2008 R2 SP1 last year. If there is anything missing or it errors out, please let me know. I will remove this statement once I get a chance to test this. *Update - I have run this script during a recent Lync 2013 deployment for a client and it is valid.

Wednesday, May 29, 2013

Lync 2013 replication issue with the Edge server installed on Windows Server 2012

On a recent Lync 2013 deployment to migrate from Lync 2010, I ran into an issue with the Lync 2013 Management Store Replication not working on the Edge servers that were installed on Windows 2012 OS (all the servers in the Lync 2013 deployment were on 2012). I notice the red X's on replication on the Lync Control Panel and I ran the PowerShell cmdlet Get-CsManagementStoreReplicationStatus showing UpToDate as FalseLastStatusReport blank and ProductVersion blank for both Lync 2013 Edge servers.

The event logs on the Lync 2010 Front Ends, Lync 2013 Front Ends and Lync 2013 Edge servers didn't show any errors or warnings stating that replication was failing. I checked all the usual suspects:

  • Certificate issues
    • I looked and verified the internal certificate had the proper Subject Name
    • Verified the internal root CA certificate was in the proper location
    • Verified that certificate checks based on the Microsoft KB article Lync Server 2013 Front-End service cannot start in Windows Server 2012 http://support.microsoft.com/kb/2795828 was not the case
  • Verified I could telnet to the Edge servers from the Front Ends over port 4443
  • Verified DNS was correct
  • Verified the computer name on the Edge servers were correct with the proper primary DNS suffix entered
  • Performed a WireShark trace on the Edge server and verified that there were connections to the server over port 4443
...and finally performed an comprehensive web search about this issue with no luck.

I spent enough time on this issue and decided to enroll the help of a very knowledgeable coworker named James Denavit (who happens to be a Lync 2010 MCM) before I throw in the towel and call Microsoft Support.

Luckily for me, James had the great idea of running the Lync Logging Tool from one of the Lync 2010 Front End servers. We ran it on the 2010 Front End because I did not move the CMS to the Lync 2013 yet. So we ran logging with the following options:
 
After running the Invoke-CsManagementStoreReplication PowerShell cmdlet from the Lync 2010 Front End server a couple times. I stopped the Logging tool and analyzed them. What we found were the following warnings:
 
One of the red flags we saw was:

TL_WARN(TF_COMPONENT) [2]0560.2E58::05/24/2013-20:25:24.920.4d11ccab (XDS_File_Transfer_Agent,FileTransferTask.CopyFilesFromReplicaUsingWcf:filetransfertask.cs(644))
(0000000002D2AF4D)[FileTransferTask(7, 5/24/2013 1:21:30 PM): {TASK_NOT_STARTED, fromReplica, [L13EdgeServerFQDN, HttpsWebService, 4443], 0}] Failed to copy files from replica. Exception: [System.ServiceModel.EndpointNotFoundException: Could not connect to https://L13EdgeServerFQDN:4443/ReplicationWebService. TCP error code 10061: No connection could be made because the target machine actively refused it 10.61.1.204:4443.  ---> System.Net.WebException: Unable to connect to the remote server ---> System.Net.Sockets.SocketException: No connection could be made because the target machine actively refused it 10.61.1.204:4443
   at System.Net.Sockets.Socket.DoConnect(EndPoint endPointSnapshot, SocketAddress socketAddress)

James did a search based on this and found the following post from The Lync Guy Blog:

I did find this blog post during my web search but lucky for me, James read the responses (which obviously I didn't) and pointed out the response from Jonatan talking about adding the registry entry: DWord value SendTrustedIssuerList to the HKey_Local_Machine\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL key and assigning it a value of 0.

After modifying the registry, I rebooted the Edge server and ran the Invoke-CsManagementStoreReplication PowerShell cmdlet from the Lync 2010 Front End server a couple times again and still no luck. I then proceeded to read more of the responses and the last response from Chris Duva stated that he added another registry entry. 

I added the registry entry DWord value ClientAuthTrustMode to the HKey_Local_Machine\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL key and assigning it a value of 2. I rebooted the Edge server again and ran the Invoke cmdlet again and voila!!! It worked. 

Since I had 2 Lync 2013 Edge servers, I just wanted to verify that only the ClientAuthTrustMode registry entry was needed so I added only that entry to the second Edge server and rebooted it and it worked! So I removed the registry entry for SendTrustedIssuerList from the first Edge server, rebooted it and verified that the replication still worked. 

Thanks to James for helping me with this issue as well as answering questions whenever I have them.

Hope this helps.