A Solution for Skype for Business 2015 “Response groups may stop receiving calls after you run the Enable-CsTopology command”

Response group may stop receiving calls after you run the enable-CsTopology command

 

Good morning to everyone,

I have the first new ground in some time, for a Response group issue, I found in 2015, documented in 2016 and finally found it had been committed to KB4015898

Or Just SFB CU5!

 

I wrote this Piece on Response groups not ringing available agents, when the group members were in modes like longest Idle.

I said the only remedy available was to rebuild the response group and you may (or not) get a different result. Another viable step is

to “Use Attendant Mode.” This was my shtick in 2016.

 

So it turns out there had been an issue dating back 2015. I had personally run into this issue several times. It turns out somthing

you may do every day, turns out to be a “No No”. So if you have a need for “Re-Publishing” the topology Frequently, and you

have response groups, that may no longer be a good Idea, Even if there is a patch in place.

 

Just be aware, and make sure you update to CU5 or higher.

 

 

“Response group may stop receiving calls after you run the enable-CsTopology command

 

This needs to be installed on any server where you have installed the Skype for business. Back up your

Response groups for CU5.

Louis

 

Advertisements

Skype For Business Certificate Encryption Agorithm RSASSA-PSS is not supported in Skype for Business

 

I ran into this issue for the first time and just wanted to document this. It was a bit of a surprise, but documented is the fact

that Skye For Business is not supporting Current Encryption Methodology RSASSA-PSS. This was a real snake bite. Having

been involved in many deployments, I never ran into this issue. so a few point on this:

  • From Skype 4B stand point, look at this as a Certificate authority problem
    • besides failing calls you have
    • Bad certificate endpoint audits
    • bad chain audits
  • SHA1RSA is being phased out like this year was the deadline as I recall
  • You would expect SFB to have moved to more modern encryption
  • SHA2RSA is apparently not supported either but does support RSAPSS (which MS documentation says is supported)
  • What they really mean is SHA1RSA is an absolute requirement and has not changed as of 10.2017

So for the mean time this means you are more and more likely to find this occurring, until there is a breaking point, and my article will become helpful. I will try to find some errors to post to give you some terms to look up soon.

 

I have it on my desk but i am out of time. But Early waning. The New RSASSA-PSS is not currently supported by SFB.

Yeah RSASSA-PSS is not supported signature algorithm for Lync/SFB servers, this information has been provided in the following article, https://technet.microsoft.com/en-us/library/gg398066(v=ocs.15).aspx

Like it. This 2013 article is what Microsoft Passed on for Skype for Business 2013.

L

Just the Shell commands for Skype Trouble Logging

I wanted to take a few minutes to just document a simple thing. Well the scope of the subject can become complex quickly. But this is not that. This is just a quick review of how to get the basic log output so you can troubleshoot a Skype issue.

I have a Video for this topic on Youtube.

So now matter how you approach logging, you will end up needing the Skype Debugging Tools.

The Debugging tool contains the Snooper log tool you will use to analyze the log. But It also contains the Skype GUI for also collecting the logs. So let me say your best method to collecting the Skype logs is to use the Gui in the Debugging tool kit. Here is a link for covering that topic: here

If the debugging tool kit is not working, you have another choice here that will act as a GUI for Log collection and analysis. Why not have a back up.


Command Line Logging

We are not going deep into Command line. If you want that please look here.

This is the emergency list of command if you just need to get logs now. below are the basic commands in order.

 

  • Show-CsClsLogging -Pools “pool.domain.com”
  • Start-CsClslogging -scenario  alwayson
  • Stop-Csclslogging -scenario “AlwaysOn”
  • Search-CsClsLogging -OutputFilePath “C:\Users\admin\mylogs\ouput.txt

 

This is the bare bones commands you can use in a pinch to get your basic logs.


Scenarios there are many you can run

So the one item missing from the commands above is a way to get the different scenarios you can choose. In order to get this information, just run the following:

  • Get-CsClsScenario | fT name

This command is important as you can target what your looking for more clearly by using the right scenario to log:

clsloggingscenario

So one thing to note is that the always on log will collect the sip stack trace, which is used in the lion share of Skype troubleshooting.

So now below I will include some examples of command you may find useful. this is not exhaustive, but this is the main things you may need for an average log collection

 

  1. Is logging running – Show-CsClsLogging -Pools “skypepool.domain.com
  2. Run Edge Log- Start-CsClsLogging -Pools pool.domain.com -Computers edge.domain.com -Scenario alwayson
  3. Complex search by time- Search-CsClsLogging -pools “pool01.contoso.net” -StartTime “11/20/2012 08:00:00 AM” -EndTime “11/20/2012 09:00:00 AM” -OutputFilePath “C:\Logfiles\logfile.txt”

 

To conclude, this is the crude basics you need to get those logs. if you want additonal information on hoe to make your own scenarios, that is very doable. see here for additional information if you are interested.

 

Thank you and happy logging.

 

Louis

 

 

 

 

Edge Replication Status is false and the Last Update Creation time stops updating for command get-csmanagementstorereplicationstatus

When it comes to Edge Replication checking, this looks like a false positive below. But I know we all like to see true. So you see where the date says 6/22? That change means the last status report was a few month’s earlier. That missing update creation, is possibly saying the replication is not working. this is not hard to fix, so lets fix it!

 

Perform the steps below:

  1. Go to the Front end server and open Skype Management Shell
  2. Run the command Export-CsConfiguration –Filename C:\filename.zip
  3. Copy the file to the Edge Server.
  4. Open the Skype for Business Deployment Wizard
  5. Choose Install Or Update Skype for Business Server System
  6. Choose install local configuration store.
  7. Browse to the file and finish the wizard.
  8. You can restart the Edge Server or just wait several minutes.
  9. If this fails, you just need to restart the SFB replication service on the FE and Edge Servers.

 

This is the point at which you browse to the configuration Zip file. Its Step 7.

I hope this helps your issue. I have seen this just stop refreshing and this step normally fixes the issue in my experience.

 

Louis

Creating or migrating the CMS of a SQL 2014 Always on Availability Group for Skype for Business 2015.

Creating or migrating the CMS of a SQL 2014 Always on Availability Group for Skype for Business 2015

 

I think one you get done with your deployment, you get to sit back and Enjoy the Honey of your Efforts. But If you are Migrating a SQL Always On Availability Group, See Below for some steps!

 

 

Basic Bullets steps

 

  1. Review Prerequisites
  2. Don’t try this on Lync 2013. This must be done using A fully patched SFB Fe Servers, as well as Fully Patched Server 2012 R2 Machine.
  3. So point # 2 is the reason for this article. The word is, Lync 2013 is not supported, but it works. Below you may see the gotcha, and be able to set it up.
  4. Install the Clustering Role on both SQL Servrs with Add-WindowsFeature Net-Framework-Core, Failover-Clustering, RSAT-Clustering-Mgmt,RSAT-Clustering-PowerShell -Source d:\sources\sxs
  5. Do not try to use SQL 2016. Only use SQL 2014 with SFB 2015 and Server 2012 R2-
  6. Test-Cluster -Node SQL1, SQL2 and make sure you have pre-requisites correct.

Follow the documentation of your choice to install your Skype for Business on SQL, but please review the notes from my friend in the Field, Timothy E Boudin. His notes may come in helpful, if you’re facing the move, and see no documentation. This is what he ran across, and brought to me. Thank you to Tim , for bringing this issue up so I could write about it:

First Find your Links for the Job

Skype

SQL

 

So to summarize, you should basically move the CMS when you do the SQL always on Availability group in my opinion. Otherwise, you are going to have to come back later, and do the second part of this cold. This is just an opinion. Below, Please Find Tim’s, Comments on his Move of the CMS with SQL Always on and Lync 2013, and SFB 2015 Migration.

 

Skype for Business setup using SQL always on Clustering

This configuration requires some unique settings for the build of the Skype for Business (SFB) support when dealing with the issue of supporting the CMS migration from Lync 2013 or previous versions to SFB 2015.

 

For this discussion the servers are as follows

Enterprise Front End Servers (3)

FE1, FE2, FE3

Always on SQL Cluster servers (2)

SQLNode1, SQLNode2, SQL Listener

During the process of defining a new Enterprise Front End pool, you provide the names of the Servers that are members of the pool as normal, but when providing the new Back end servers information you have to handle this in a specific way to be able to support fail-over.

Create the new SQL Server Store as follows

 

Fill in the name of the SQL Listener in the SQL Server FQDN field

 

Provide the name of the SQL Instance if your using one.

Check the High Availability Settings option

Select SQL Always-on Availability Groups

Fill in the name of the SQL Node1 server

Click OK and complete the Front End pool Wizard.  When you Publish the changes to topology you should be prompted to provide details on how you want to establish the tables for the Cluster.  If this is setup by a DBA check with them on location of the Data and Log files.

Once publishing is completed, go back and edit the SQL Store settings and change the SQLNode1 setting to SQLNode2 server name.

 

Publish the change and then do an Install or upgrade a Database

Once publishing is completed, go back and edit the SQL Store settings and change the SQLNode1 setting to the SQL Listener server name.  Now publish a finial time.  There is no need to do an Install Database for this change.

 

Once the finial publish is complete you should be able to start services on the Front End Pool servers.

Move the CMS

To move the CMS from the previous location to the Front End pool using the Always-on Cluster use the following process.

  • Stop Services on the Front End Pool to be hosting the new CMS location
  • Open the Lync Power-Shell and use the following commands:

Stop-cswindowsservice

  • Backup the CMS to a file with the following

Export-CsConfiguration –filename c:\media\cmsbackup.zip

 Create the new Tables for the CMS on the new Front End pool specifying the node1 of the cluster, when you specify the database paths they are listed by Log file location first and then by Data file location.

Install-CsDatabase –CentralManagementDatabase –SQLServerFQDN SQLNode1.contoso.com -databasepaths g:\RTC_logs,f:\RTC_data -sqlinstancename RTC –verbose

 Once the tables have been created, have the DBA verify Mirroring between the nodes is in place.

 Enable-cscomputer

Get-CsManagementStoreReplicationStatus

If replication is good then move the CMS to new server by using the Move command on the Front end server in the target pool.

Move-CsManagementServer

 

Once the move is complete, allow for server replication and then Run local Setup in the deployment wizard on all affected Front end servers and reboot them and Monitor replication

Get-csmanagementconnection

Get-CsService –CentralManagement

 

I hope this is helpful Documentation, if you have to face this situation.

 

Thank you,

 

Louis

Auto-Attendant announces there has been a System Error! and hangs up!

 

Hello All. I had a support case where the answer was right in front of me but I didn’t initially put my hand right on the problem. Actually there is two incidents and the customer was the same. Let me share both stories with you.

The first issue was an auto-Attendant who failed to use voice to interface with a user. Instead It screams out System error! In fact the error simply said there was a system error and hung up. It was very nasty and there was no definitive help in the event log or anywhere else.

The work around plan to fix this was to simply upgrade the Exchange CU and the .NET Framework version. As it turns out, even that would not have helped this situation.

So if your environment is just one Gateway, one Dial Plan, one Auto attendant and one Hunt group, there is a good chance you wont have this problem. However, that may also be the perfect situation for the problem. The issue looks like the product of recreating the Dial plan multiple times. Below is a good result. But what if the results were the same for three lines in a row? If you only have one dial plan, this would be something to be alarmed about!

image

Not so much the picture above, but the one below:

So with multiple hunt groups per dial plan, the search behavior changes and you may get an un documented failure. Not so much because its a problem failure, but

because, often times, documentation is written in terms of what some application will do, not what it wont do. So word to the wise, check your hunt hunt groups.

I saw the problem when you have multiple hunt groups and only one dial plan. I know there is also only one Dial Plan. But I think you can see how a seach outside of the local dial plan could render a problem.

When you run the get-UMHuntGroup command, You will see the Hunt group displayed, one for every Dial plan. This is an area where you may have old hunt groups pile up for dial plans you created and deleted.

Its fine to have old hunt groups, but if they have the same name, there could be a system error.

The system error occurs, If you have a ghost Hunt group object and:

the name of the hunt group matches the one your using for your production dial plan. and you have the “in the entire organization” checked in the address book and operator access setting in the auto attendant setting.

image

Changing the radio button to this dial plan only, protects the Auto Attendant for issues with other hunt groups, or dial plans. This is a lesson learned for me! My default setting is not this dial plan only! Such an easy thing to miss!

This seems more like a corner case then a call driver, but I have to mention it, as I am sure we will see it again! Have a great roman holiday!

 

Louis

Move-CsUser Fails from command line when Migrating User to New Pool. It succeeds from Graphical Interface

 

Hello All,

I am hoping to make some videos about SFB, but I am still low on time. In the mean time, I hope these articles are helpful to some. My Friend called me with an interesting problem. His move-Csuser command failed from the command line. The GUI move succeeded. I provide below a few things to check and set to repair the issue.

Figure 1. Roman Numerals of Lync Issues Colosseum-Entrance_LII

 

There are a couple reasons for the failure you are having. I will list below, along with the most plausible solutions:

I. The difference between the Command line and GUI is permissions related. When you open the command line, you need to be a member of the following groups :

  • 1. RTCUniversalUserAdmins (not CSUserAdministrators
  • 2. CsAdministrator 
  • 3. I know you think you have proper permissions but please check- This is often gotten wrong
      • a. You will check and see you have two permissions – CSAdministrator and RTCUniversalServerAdmins
      • b. You also need to add – you need to be a member of CsAdministrator and RTCUniversalUserAdmins

II. The other side of this issue is the User. The user may have been one of many users who had their default user created without inheritable permissions. Lync move command will fail!! Fix it before making the move command!

Move command fails due to user permissions

III. User is legacy OCS user? Your error contains the text OCSADUser. Without the full text of the error, there is some guesswork here but, perhaps try this out:

Lync fails to move between pools

    • a. Port 135 is blocked between pools. (not sure how the GUI gets around that)
    • b. Run get-CsManagementStoreReplicationStatus on all Servers. Correct failures
    • c. Check any SBAs they need the right ports etc..
    • d. Did you try the –Force yet? Try it out. If it succeeds, then likely we have a data issue.
    • e. Run Get-CsFabricPoolState and Get-CsBackupServiceStatus if either fail, then we know this needs to be fixed first.
    • f. Move-CsLegacyUser -Identity “sip:kate@domain.net”-Target “lync-se.domain.net

IV. Are the users potentially legacy OCS users? They could be. Try Move-CsLegacyUser

V. Weather legacy or not, the database may have a problem. Try to check the database for clarity below

  • a. The error in this link may not match, but it contains the how to check for Database corruption DBANALYZE
  • b. If the user database is not right, and you cant repair then you may have to homogenize the data by completing the CMS move or moving the CMS to another machine.
  • Or you want to Export and Import the User data, after running a –force on the move command. see roman num. 8 below

VI. User or pool Attributes are wrong or corrupt, or not changeable in AD. Note the following attributes. You can even change manually if you know the values for the desired state. For the Pool:

  • a. msRTCSIP-PoolDomainFQDN
  • b. msRTCSIP-PoolDisplayName
  • c. msRTCSIP-BackEndServer

2. For the User

  • a. msRTCSIP-UserRoutingGroupId
  • b. msRTCSIP-UserEnabled
  • c. msRTCSIP-PrimaryHomeServer

VII. Lync Server Move-CsUser and Move-CsLegacyUser commands fail with error –like  SetMoveResourceData failed because the user is not provisioned.

VIII. This is a perfect little process if Force works. So the commands are restated below. Thanks FlinchBot:

  • a. Export-CsUserData -UserFilter “user@flinchbot.com” -Poolfqdn pool.flinchbot.com -filename “e:\tempuser.zip
  • b. Move-CsUser “user@flinchbot.com” -Target pool.flinchbot.com –force
  • c. Update-CsUserData -UserFilter “user@flinchbot.com” -FileName “e:\tempuser.zip” –verbose

IX. If you Move back in version, it will automatically fail without a force. Here is a long time disclaimer:

“WARNING: Moving a user from the current version to an earlier version (or to a service version) can cause data loss”

X. I just had to get to 10. Now I know My Roman numerals. Ok I am leaving you with a more complex example, which includes two of my fixes from above, in combination. I think I have captured a good number of the reasons why Move-CsUser may fail.

Bonus #11 – Issue with Move command and AD Connect

 

I hope this has been fun and informative. This is a summary article about the many reasons you may not be able to run move-CsUser in the command line. I will leave you with a couple last articles which have to do with getting all the user objects that may be causing things to fail. You can manually parse the list to see if there are any that show up with a problem.

 

 

Louis