Skype for Business routing group missing both secondary replicas

For some reason Get-CsPoolFabricState reported an error in a routing group after patching the operating system of 4 enterprise pool FE servers. Users were getting limited functionality and there were som “exciting” errors in the Lync server logs in event viewer.

Event 64004 LS Join Launcher Web Service
Event 32083 LS Audio-Video Conferencing Server

Event 32261 LS User Services

 

I’ve had some cases where Front End service wouldn’t start, and the solution would be to run Reset-CsPoolRegistrarState -PoolFqdn serverpool.domain.com -ResetType QuorumLossRecovery , but this time it was different.

Get-CsPoolFabricState reported that all routing groups had their primary, but one of them was missing both secondary (secondary and backup-secondary). As previously mentioned, Reset-CsPoolRegistrarState didn’t do the trick….but there is another command that should be helpful, if there only were a place to get information about it…. Microsoft documentation… but at least in my browser, the attributes isn’t correct and there is no information about what they do. The first line of example in the documentation is also wrong, using the attribute -Type, when it is -ResetType, this have to be one of the worst docs I’ve read. The attribute that is actually interesting here is of course the ResetType, but this is the list from the website:

I see allowed values : Invalid, Permanent, Transient. No explanation…and Invalid? What?

Having spent too much time already I decided to give it a go…..

Reset-CsRoutingGroup -RoutingGroup 1D8E94CB114A5FAFBF03FBA2A781E8E3 -TargetFqdn sfbFE1.domain.com -ResetType Transient

Hmm. Didn’t do me any favors, it just moved the routinggroup primary to another server, but didn’t fix the problem.

Reset-CsRoutingGroup -RoutingGroup 1D8E94CB114A5FAFBF03FBA2A781E8E3 -TargetFqdn sfbFE1.domain.com -ResetType Invalid

Yeah…right. But at least I got an error with some information telling me that Invalid is an Invalid option….I’ve would have been crying if some genious at MS hadn’t included a little more information about what values that was acceptable:  Permanent, Transient and Recreate.

Now, that’s what I’ve been searching for the whole day. A way to recreate the routing group.

Reset-CsRoutingGroup -RoutingGroup 1D8E94CB114A5FAFBF03FBA2A781E8E3 -TargetFqdn sfbFE1.domain.com -ResetType Recreate

BOOM. Fixed in 1 minute.

Hats of to MS for a documentation from “He**” and a smiley to the genious programmer that included the values.

Skype for Business CsRGSHolidaySet

Created RGSHolidaySet for Norway 2018.

$poolname = Read-Host -Prompt “Legg inn Skype-pool navn, full FQDN”
$NyttAar = New-CsRgsHoliday -Name “Nyttårsdag” -StartDate “1/1/2018” -EndDate “2/1/2018”
$SkTo = New-CsRgsHoliday -Name “Skjærtorsdag” -StartDate “29/3/2018” -EndDate “30/3/2018”
$LaFr = New-CsRgsHoliday -Name “Langfredag” -StartDate “30/3/2018” -EndDate “31/3/2018”
$PMan = New-CsRgsHoliday -Name “2. Påskedag” -StartDate “2/4/2018” -EndDate “3/4/2018”
$Arb = New-CsRgsHoliday -Name “Arbeidernes dag” -StartDate “1/5/2018” -EndDate “2/5/2018”
$Himmel = New-CsRgsHoliday -Name “Kristi Himmelfartsdag” -StartDate “10/5/2018” -EndDate “11/5/2018”
$17Mai = New-CsRgsHoliday -Name “Grunnlovsdagen” -StartDate “17/5/2018” -EndDate “18/5/2018”
$2Pinse = New-CsRgsHoliday -Name “2. Pinsedag” -StartDate “21/5/2018” -EndDate “22/5/2018”
$Jul = New-CsRgsHoliday -Name “Julen 2018” -StartDate “25/12/2018” -EndDate “27/12/2018”

New-CsRgsHolidaySet -Parent “ApplicationServer:$poolname” -Name “Holiday 2018” -HolidayList ($NyttAar, $SkTo, $LaFr, $PMan, $Arb, $Himmel, $17Mai, $2Pinse, $Jul)

Network connectivity issues or an incorrectly configured certificate on the destination server

Issued new certificate for internal Front End. The new certificate had SHA256, vs old one had SHA1. There were two FE servers but only one gave this error:

Sending HTTP request failed. Server functionality will be affected if messages are failing consistently.

Sending the message to https://FQDN:444/LiveServer/Replication failed. IP Address is 10.10.0.12. Error code is 0x2EFE. Content-Type is application/replication+xml. Http Error Code is 0x0.
Cause: Network connectivity issues or an incorrectly configured certificate on the destination server. Check the eventlog description for more information.
Resolution:
Check the destination server to see that it is listening on the same URI and it has certificate configured for MTLS. Other reasons might be network connectivity issues between the two servers.

 

Solution: Run local setup on server. Was not necessary on the other for some reason.

PSTN to Lync 2013 Unassigned Number failure

A sidenote: if upgrading from lync server 2010, it may not be sufficient to redirect the gateways to the new 2013 pool. you will then have to delete the gateway(s) and trunks, publish topology, then re-add them to topology with 2013 pool, and publish again. Be sure to update the “Associated trunk” on the voice route configuration. Thanks to Michael for sharing this unassigned number failure solution.

D(one) IT

Incoming calls from the PSTN to an unassigned number within the unassigned number range on Lync 2013, the call fails. The same number called from the Lync client completes successfully, and is routed to either the Announcement service or Exchange Attendant depending on configuration. In Snooper the call trace shows a “486 Busy Here” or “403 forbidden” or “404 not found” depending on your Gateway/PSTN provider.

Looking into the 403 forbidden message, I came across VOIPNorm’s Call Park Retrieval Issues From CUCM 8.x. It seems as though both the Call Park Service and the Unassigned Numbers are skipped for external inbound calls.

The fix is to create a trunk that has no PSTN usage records.

View original post

Kerberos Authentication for Lync Web Services

Original source : http://howdouc.blogspot.no/2011/07/kerberos-web-authentication-for-lync.html

 

I know that everyone runs the Lync Best Practices Analyzer (BPA) on a regular basis…right?  After running the BPA, you might see the following warning:

Pool fully qualified domain name (FQDN) “fqdn” is not found as a http service principal name (SPN) on any user or computer.  Kerberos web authentication is not configured..

The warning pops up due to the fact that Lync uses NetworkService to run the Web Services and NetworkService cannot have SPNs assigned to it (this is a change from how OCS handled it).

I am not going to address the “why use kerberos authentication?” because there is already agreat article written by Jens Trier Rasmussen.  I suggest reading it before proceeding.

The rest of this post will describe the process of enabling Kerberos authentication for the Lync Web Services.

1) Create a Kerberos account

Pre-req: member of Domain Admins and computer running Lync Management Shell (LMS)

From the LMS, run:  New-CsKerberosAccount –UserAccount “Domain\UserAccount” –ContainerDN “CN=Users,DC=DomainName,DC=DomainExtenstion”

My command:  New-CsKerberosAccount –UserAccount “Homelab\LyncKerbAcct” –ContainerDN “OU=UC Objects,DC=homelab,DC=local”

Note that the –UserAccount parameter is used even though we are creating a computer account with this command.

2) Assign the Kerberos account to a site

Pre-req: member of RTCUniversalServerAdmins and computer running Lync Management Shell (LMS)

To use the Kerberos account, you must assign it to a site.  While you can create multiple Kerberos accounts for your environment, you can only assign one account per Lync site.

From the LMS run: New-CsKerberosAccountAssignment –UserAccount “Domain\UserAccount” –Identity “site:SiteName”

My command: New-CsKerberosAccountAssignment –UserAccount “Homelab\LyncKerbAcct” –Identity “site:Datacenter”

Then run Enable-CsTopology

3) Set Kerberos account password and Synchronize to IIS

Pre-req: member of RTCUniversalServerAdmins and computer running Lync Management Shell (LMS)

From the LMS run: Set-CsKerberosAccountPassword –UserAccount “Domain\UserAccount”

My command: Set-CsKerberosAccountPassword –UserAccount “Homelab\LyncKerbAcct”

If any servers are added to the topology in the site (like Front-ends and Directors) you will need to synchronize the Kerberos account password to IIS of the new server.

From LMS run: Set-CsKerberosAccountPassword –FromComputer SourceComputer –ToComputer DestinationComputer

My command: Set-CsKerberosAccountPassword –FromComputer lablyncfe01.homelab.local –ToComputer lablyncfe02.homelab.local

4) Testing to make sure Kerberos is working properly

To test for full functional readiness of Kerberos within a site, the following command can be run to create a report:

From LMS run: Test-CsKerberosAccountAssignment –Identity “site:SiteName” –Report “C:\reportpath\reportname.htm” –Verbose

My command: Test-CsKerberosAccountAssignment –Identity “site:Datacenter” –Report “C:\Temp\KerbTest.htm”

Report generated:

 

Copy from : http://howdouc.blogspot.no/2011/07/kerberos-web-authentication-for-lync.html

Forward on Response Group to PSTN telephone number not working

All taken from this site: http://www.fots.nl/index.php/forward-on-response-group-to-pstn-telephone-number-not-working/

I came across an issue regarding the forward on a Lync response group. There was a queue time-out enabled and set to “Forward to telephone number”. This field was filled with sip:+4777665544@domain.com (where domain.com was the SIP domain). 

When a call came and hit the time-out, the call was forwarded to the number specified, but then an error was displayed on the client, on both Lync client 2013 and a Polycom Lync Phone Edition. The error was “the call could not be completed. Please try again later. The call could not be completed due to a busy network.“.

I started the logging on the Lync Front-End server and found the following error that was displayed:

ms-diagnostics: 1003;reason=”User does not exist”;TargetUri=”+4777665544@domain.com”

This is an expected error, as the user is not an existing user. But after this error, there was no SIP signal to the PSTN gateway for an outbound call. After some search on the internet, I saw this blog from Tim Day. This was exactly the same issue I was having. His solution sounded plausible, so I tested it, but with no luck.

Solution

I started testing with different Response Groups and found the problem. This specific Lync environment consists of multiple SIP domains. When a response group was made with a SIP domain that wasn’t the primary SIP domain, the problem existed. As there is no way of changing the SIP address of response group, I recreated the group.

After recreating the response group (workflow) with a primary SIP domain SIP address, the outbound call was made after the time-out was hit.

Configuring an On-Premises Partner Application for Microsoft Lync Server 2013

All taken from Microsoft Technet : http://technet.microsoft.com/en-us/library/jj204975.aspx

 

After you have assigned the OAuthTokenIssuer certificate you must then configure your Microsoft Lync Server 2013 partner applications. (The procedure about to be discussed configures both Microsoft Exchange Server 2013 and Microsoft SharePoint to act as partner applications.) To configure an on-premises partner application, you must start by copying the following Windows PowerShell script and pasting the code into Notepad (or any other text editor):

if ((Get-CsPartnerApplication -ErrorAction SilentlyContinue) -ne $Null)
   {
       Remove-CsPartnerApplication app
   }

$exch = Get-CsPartnerApplication microsoft.exchange -ErrorAction SilentlyContinue

if ($exch -eq $null)
   {
      New-CsPartnerApplication -Identity microsoft.exchange -MetadataUrl https://atl-exchange-001.litwareinc.com/autodiscover/metadata/json/1 -ApplicationTrustLevel Full 
    }
else
    {
       if ($exch.ApplicationIdentifier -ne "00000002-0000-0ff1-ce00-000000000000")
          {
             Remove-CsPartnerApplication microsoft.exchange
New-CsPartnerApplication -Identity microsoft.exchange -MetadataUrl https://atl-exchange-001.litwareinc.com/autodiscover/metadata/json/1 -ApplicationTrustLevel Full 
           }
        else
           {
             Set-CsPartnerApplication -Identity microsoft.exchange -ApplicationTrustLevel Full 
           }
     }

$shp = Get-CsPartnerApplication microsoft.sharepoint -ErrorAction SilentlyContinue

if ($shp -eq $null)
   {
      New-CsPartnerApplication -Identity microsoft.sharepoint -MetadataUrl http://atl-sharepoint-001.litwareinc.com/jsonmetadata.ashx -ApplicationTrustLevel Full 
    }
else
    {
       if ($shp.ApplicationIdentifier -ne "00000003-0000-0ff1-ce00-000000000000")
          {
             Remove-CsPartnerApplication microsoft.sharepoint

             New-CsPartnerApplication -Identity microsoft.sharepoint -MetadataUrl http://atl-sharepoint-001.litwareinc.com/jsonmetadata.ashx -ApplicationTrustLevel Full 
           }
        else
           {
             Set-CsPartnerApplication -Identity microsoft.sharepoint -ApplicationTrustLevel Full 
            }
   }

Set-CsOAuthConfiguration -ServiceName 00000004-0000-0ff1-ce00-000000000000

After copying the code, save the script using a .PS1 file extension (for example, C:\Scripts\ServerToServerAuth.ps1). Note that, before you run this script, you must replace the metadata URLs https://atl-exchange-001.litwareinc.com/autodiscover/metadata/json/1 and http://atl-sharepoint-001.litwareinc.com/jsonmetadata.ashx with the metadata URLs used by your Exchange 2013 and SharePoint servers, respectively. See the product documentation for Exchange 2013 and SharePoint for information on how you can identify the respective product’s metadata URL.

If you look at the last line of the script you will notice that the Set-CsOAuthConfiguration cmdlet is called using this syntax:

Set-CsOAuthConfiguration -ServiceName 00000004-0000-0ff1-ce00-000000000000

Because the Realm parameter was not used when calling Set-CsOAuthConfiguration the realm will automatically be set to the fully qualified domain name (FQDN) of your organization (for example, litwareinc.com). If your realm name is different from your organization name then you should include the realm name, like this:

Set-CsOAuthConfiguration -ServiceName 00000004-0000-0ff1-ce00-000000000000 -Realm "contoso.com"

After making these changes you can then execute the script, and configure both Exchange 2013 and SharePoint as partner applications, by running the script file from within the Lync Server 2013 Management Shell. For example:

C:\Scripts\ServerToServerAuth.ps1

Note that you can run this script even if you do not have both Exchange 2013 and SharePoint Server installed:, no problems will occur if you, say, configure SharePoint Server as a partner application even though you do not have SharePoint Server installed.

When you run this script you might receive an error message similar to the following:

New-CsPartnerApplication : Cannot bind parameter 'MetadataUrl' to the target. Exception setting "MetadataUrl": "The metadata document could not be downloaded from the URL in the MetadataUrl parameter or downloaded data is not a valid metadata document."

This error message typically means one of two things: 1) that one of the URLs specified in the script is not valid (that is, one of your metadata URLs is not an actual metadata URL); or, 2) one of the metadata URLs could not be contacted. If this happens, verify that the URLs are correct and are accessible, and the re-run the script.

After creating the partner application for Lync Server 2013 you must then configure Lync Server to be a partner application for Exchange 2013. You can configure partner applications for Exchange 2013 by running the script Configure-EnterprisePartnerApplication.ps1; all you need to do is specify the metadata URL for Lync Server and indicate that Lync Server is the new partner application.

To configure Lync Server as a partner application for Exchange, open the Exchange Management Shell and run a command similar to this:

"c:\Program Files\Microsoft\Exchange Server\V15\Scripts\Configure-EnterprisePartnerApplication.ps1" -AuthMetadataUrl "https://lync.contoso.com/metadata/json/1" -ApplicationType "Lync"

Lync 2013 server. Unable to forward calls, unable to receive calls, unable to call at all

Updated Lync server 2010 to 2013 at a client. The Pilot pool they gave me was 1 user……not the best pilot pool in the world, but……

Anyway. The pilot tested the lync 2013 installation for 2 days, and everything was working perfect. IT-manager told me to transfer all users to new pool, and decommision the old pool.

I transferred all users, responsegroups, caphones….everything to lync 2013. uninstalled the lync 2010 edge server, monitoringserver and moved cms.

And then….trouble began. 20 out of 240 users started complaining about not being able to receive calls via pstn, and some also had trouble with lync-lync calls. The biggest issue was that the switchboard could not hold a conversation for more than 20 seconds, and was unable to transfer calls at all.

Long hours…… At first I thought it was the DMG2000 gateway that was having a bad pill, and startet troubleshooting that. That would not explain lync-lync calls failing, but I had to start somewhere….

Changing settings, moving gateway back to lync 2010, moving users back to 2010, nothing worked.

Then I saw an article….(google, jay) : http://www.bricomp.com/blogs/post.cfm/unable-to-transfer-blind-or-direct-using-lync-2013

http://msunified.net/2013/01/09/cannot-complete-the-transfer-in-lync-server-2013/

Bottom line……Windows is always Windows. REBOOT the server. Worked for me.

IIS ARR ssl certificate

To make a ssl certificate for the IIS ARR proxy for Lync Server 2010/2013 i followed this guide :

http://dusk1911.wordpress.com/2011/12/12/manually-generating-the-certificate-request-for-lync-web-services-to-be-used-in-your-reverse-proxy/

 

Don’t need to invent the gunpowder all over again. 🙂