This little nugget of an error occurs when you use the Skype for Business Topology Builder to Install Persistent Chat. The scenario where this error is relevant is when you have two Lync Sites and you have setup High Availability and Disaster Recovery. It just so happens this is also a Persistent chat Stretched Pool. I have spent considerable time trying to understand the underlying behavior. I hope I have gotten enough facts to help you avoid spending a bunch of hours trying to get Microsoft Support to fix it.
Before I start, I want to say This exercise has taught me that the Always On Availability group is a much more elegant solution for High availability and helps simplify Disaster recovery too. At the time of this reading, Always On Availability was not supported for Persistent chat. But I thought I would mention, it may be best to keep Persistent chat down to its basic essence and just do good backups. I am about to share with you why Mirroring and log Shipping is not a perfect solution for SKYPE for Business Persistent chat (from the topology builder)
The primary disparity comes in looking at the TechNet design vs. the Different Setup Documents you find available online:
Vs . The Deep Dive example by Richard Schwendiman.
By comparing the two Graphics of the Design, you can clearly see that the HA and DR for Persistent chat, Is defined, over and over, In a fairly straight forward design, which includes only one Mirror Database in the in the primary Site. This Primary Site is laid out below:
In contrast, you notice both Sites show 2 SQL mirrors. The Tech-net Documentation shows only one mirror. Channel 9 videos only show one mirror. I will now Juxtapose the Tech Net Document on the Same Design for SQL mirror setup.
Notice below, the SQL backup database is the log shipping target database. This Log Shipped database, is something you define in the Topology Builder, and constitutes the Disaster recovery copy of the Persistent chat database
In these small differences, there is a bug or a limit to the software. You will be able to publish the topology Builder, with either setup. However, Since the persistent chat Principle databases is log shipping to SQL backup, the Database state of the SQL backup database with be in recovery, on a permanent basis.
Since this is always recovering, the secondary mirror and witness will not be able to handle any commands from the topology Builder. you will get a failure if you try to “Publish Database” to the Secondary Site.
One of the errors you will see is Warning :No Databases were found for mirroring or witness setup for SQL server SERVERNAME and Instance PCHAT:
This is by design! The Secondary settings are there, because they can be used when and if you actually do the fail-over process, to execute the Disaster recovery steps.
This is the screen where you will make your setup, and because of the lack of documentation, you will not realize two of the three entries here, are not going to work as the Back Up SQL store is going to work, when you publish the topology.
The choices In the Red square above, Are not going to be functioning, accept for the Backup SQL server Store. This is the Log shipping database, as a result of being published, the Backup database, can be the recipient of the log shipped transaction log files.
- Because that databases is a log shipped database, the Mirror of this and the Witness cannot be working, because the Lync Services will basically be turned off, until the Lync Services are needed. Once you fail over the Primary Database, you may then use the Mirror and the Witness defined in the Topology. Until Failover, they will lay dormant!
This is a limit to how the Lync HADR process works. The only documents I could find on this issues was the following 2 articles:
Basically what these two links show is that If you set up the HADR as the Figure 1 setup, with a SQL mirror at the secondary Site, That mirror will not work, based on the log ship copy of the Persistent chat Primary Database. The log shipped databases will be in recovery at all times, as it is always changing, based on the constant updates.
To solidify this phenomenon, here is a Link the expresses this condition here–How to back up the secondary log shipping database. If you notice, it looks like the Always on is the solution to this problem. Hopefully this is supported for Persistent chat soon!
Otherwise, this is largely manual process, whose goal is to allow the second data center to be able to take over persistent chat, based on several manual configuration changes, laid out in these articles:
- Plan For Persistent Chat
- Configure HA and DR for Persistent chat in Skype for Business
- Plan for HA and DR for Persistent chat in Skype for Business
Once you have failed over the persistent chat pool to the DR site, you may then reconnect the Pchat database, Mirror and Witness on the DR server. The gotcha is you will not be able to do it before.
Automation is not built into the DR procedures.
To conclude, I would really recommend you stay within the supported DR guidelines for HA ad DR with the Persistent chat pool. SFB had consolidates the steps (Over Lync 2013), so use the links above and you should be able to configure Persistent chat as a best practice. Originality will not likely pay off in this endeavor.
It looks like you may be able to have two mirrors in two Data Centers. This would not be directory supported by Microsoft. However, below are some possible helping steps if you wish to try:
- SQL instances should both be in the same domain, as should both Sites.
- Configure Chat permissions – User must be a member of CsPersistentChatAdministrator. To change policy, user must be in CsUserAdministrator, at a minimum.
- All SQL databases need to have a domain account, with Admin permissions, common to all SQL instances involved with PCHat.
- The Sub-net should be on the same sub-net.
- There can only be one active Persistent chat primary database, at any given time, in the forest.
- If the SQL Server service account on your primary server runs under the local system account, you must create your backup folder on the primary server and specify a local path to that folder.
- to change log shipping, you have to fail over the mirror in the primary Chat Database.
- The only time the Second PChat Mirror is used is in conjunction with Disaster recovery. is “with an optional mirror to provide high availability during disaster recovery” The words indicate that second mirror is only used when the DR process is being manually carried out.
- There was a Gotcha in how you added the Databases and mirrors in the Topology builder.Review in case it comes up in your setup
Finally, this comes from Channel 9, which confirms the two way Mirror for Persistent chat is not showing up in design and configure documentation:
notice it does not say SQL mirror pair in both Sites.
I hope this is helpful in dispelling what Lync and Skype for Business will accept as far as the Supported HA and DR, when they are both set up and how they are set up.
To conclude, you may be able to manually make the log shipped Database, work with the secondary mirror and witness. This will generally require manual intervention, and may not be supported with MS and Skype foe Business. You can try to recreate the end point and manually initiate the mirror. However, you will need to break the supported configuration in able to make it work. Here are a few links to look at: