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 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)
  • And its True! Microsoft Windows has been more open then some of the other Departments, to support modern Authorization and Encryption.
  • But Certain things like Skype and possibly Exchange 2016 Secure Mail, may be limited to SHA1RSA as an absolute requirement. This has not changed as of 10.2017

So for the mean time, this means you are more and more likely, to find this occurring, and my article will become helpful. I will try to find some errors to post, to give you some terms of this challenge.

For Example:

  • Elliptic Curve Cryptography
  • Microsoft works with them all
  • To avoid this issue, you need to install you CA with “Use Alternate Signature Format” Unchecked, during Install.
  • If the issue is a Public Certificate, you will need to re-Request the Certificate and tell the Provider you do not want an Alternate Signature format for your PKCS #1 Version 2.1  Certificate.

I have it on my desk but i am out of time. But Early warning. 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,

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



Skype for Business First Clean install on RTM bits has issues with windows updates.

I installed clean Skype for Business 2015 over the weekend and I did get stuck in an odd place. The pre-requesites for a clean in stall of server 2012 R2 are not documented well at the time of this writing. The new Windows intall, does not seem to install SFB if the windows updates are complete. I mean complete. Green check mark. Microsoft says all good here!



The whole issue begins with Update kb/2982006. This wont install on my system. It requires the pre-requisite KB 2919355, which in turn looks to require- KB2919442 which wont install.

What to do. What to do. My 15 th try was to clean my image up with the following command:

Dism /Online /Cleanup-Image /ScanHealth

THis command stayed at 20% for 20 minutes or more, so I am pretty sure something was being fixed. I should look at the logs, but I am trying to install SFB, not windows server. In due process, the DISM command finished, failed

Next, I found a great script, which I am keeping, which by the way failed, because of this issue-


I struggled on for two more days and finally just manually installed the update with a dism extraction. What a lousy ending to the story. Well I hope you dont have the situation I had.

It does work, But it is odd, to say the least. It seems like its an error in the RTM release, because the Pre-Requisites seem to have rolled up into other KB numbers then the infamous KB2982006. Here we go, a work around is near-

Before installing this, I removed the admin tools for SFB from Programs and features and reviewed this article-DN933900
Expand –F:* C:\Hotfixes\Windows8.1-KB2982006-x64.msu c:\temp\
DISM.exe /Online /Add-Package /PackagePath:c:\temp\

And the Lync, I mean SKYPE install completed. This is the portions which is installing the Business components, via the wizard:



Happy Skype for Business day: defined as the day you finally get around to installing it and it works. 🙂

Lync 2013 Installed in a Null root or Resource forest. Issues include Prepare Schema fail, Front end service fails, and conferencing fails.

Several issues may occur when using a Null root domain or resource Forrest.  I had created a few articles which have evolved into a story. I have seen the Null Root domain cause failure of Schema and Forest preparation, Services not to start, failure of Office 365 to connect and Conferencing to fail. Below is a narration of this story


Please reference the first two articles below:

Prepare Lync 2013 Forrest where a null root domain exist.

Front End Services wont start on Lync 2013 when installing Lync in a child domain of a Null root forest


Hopefully the final chapter can put this all together. An annoyance in deploying Lync occurs when it is a complex Active Directory Environment. You will want to be aware if you have a multi child domain scenario, where your root forest is not really used for business needs. The Child organization has all the main active directory usage and you may only have two Domain Controllers and a DNS server in the Root domain. The main clue you have this scenario is the Schema preparation fails with the Lync wizard.  See the link above to resolve this.

Be aware it has come to light CsUserReplicatorConfiguration contains the sip domains where the Front end service looks before the services start. We found out that the default setting is $null. with Null set, the behavior is Lync will check all domains for front end services. If Lync is not installed in all domains, the Front end Service will not start.  Here is how you would resrtict that search

Set-CsUserReplicatorConfiguration —ADDomainNamingContextlist

The next issue is quite a surprise. With this setting changed, services will start but the conferencing object is now separated from the domain installation and “any  Lync objects in the forest”  will not be able to contact objects in the domain. On the other hand, objects listed in the CsUserReplicatorConfiguration will allow Lync FE service to start, Unless Lync is not installed in one of the listed domains.

We need to have a simple rule to go by. based on all known information here is the Postulation of Lync AD entry requirement for Resource Forest Lync Deployment:

1.  If the Schema and Forest will not update for Lync 2013 and you have a Null root domain or Resource Forrest you must run the updates manually

2. If Lync is not installed in all the child domains, a change is needed in the CsUserReplicatorConfiguration Lync setting.  This setting includes the Root Forest Domain and the Children where Lync is installed

get-CsUserReplicatorConfiguration I fL
Set—CsUserReplicatorConfiguration —ADDomainNamingContextlist $null
$a= @{add=”DC=domain,DC=com”, “DC=parentdomain,DC=com”}
Set-CsUserReplicatorConfiguration —ADDomainNamingContext @{add=”DC=parentdomain,DC=com”

Verify the domain is present as expected


Add any other Lync domain needed

Set-CsUserReplicatorConfiguration —ADDomainNamingContextlist


3. At minimum, an install such as this will have two entries. One for the Rood domain and one for a child domain. do not include any non-Lync domains. Do include any Office 365 domains where the objects for the O365 domain have been created on premise to the local environment.


At the time of this writing, this is the latest and most complete settings and instructions. This may change over time. I hope this is helpful to someone who is facing similar problems.


Copying Files Between Windows VM(ESX) Servers cause VMWARE host to fail, freeze or virtual machines become inaccesible

Good Evening- Copying files takes one or more ESX servers down? Yes- Using a UNC path to copy a file from VMa to VMb could purple screen your ESX server. All you need to do is use the E1000 VM NIC type. Synopsis> Don’t use E1000 VNIC on ESX 5.x if you use windows VMS? Apparently so!

This problem is not Lync Specific, but I saw this happen with a verifiable pattern. To reproduce this issue, all that was necessary was to copy a large file between virtual machines that had a common storage device (SAN). All Virtual Machines on multiple hosts failed, and a hard power down was required in some cases to return server to functionality. A ticket was put in to VMware and the results were surprising.

1. The Issue was confirmed as a problem from VMware under KB-2059053

2. The Recommendation from VMware was to use the VMXNET3 virtual adapter and reduce the usage of the E1000 series adapter as much as possible.

3. In addition, disable RSS within the Windows virtual machine. For more information, see the Resolution section of the KB article Poor network performance or high network latency on Windows virtual machines (2008925).

4. This problem may occur on ESX 5.0, 5.1 or 5.5

The Simple operation of copying a file between virtual machines could occur under many circumstances so I would add tags to suggest this could effect any windows implementation on VMware. Please beware of this problem as the issue could cause multiple VMware Hosts to fail, taking down all machines on the Host. We saw this occur on a copy of Lync Update.exe from one server to another. I placed this in the Lync Blog section of my posts, but any Windows application with the VMware virtual NIC E1000- Is susceptible to this problem.

The cause is listed as- This issue occurs when the rx Ring buffer fills up and the max Rx ring is set to more than 2. The next Rx packet received that is handled by the second ring is NULL, causing a processing error.

Prepare Lync 2013 Forest where a null root domain exist.

Hey Everyone,

I had an interesting one with Hugh this week.  This is a corner case but nevertheless, it may cause grief to the unknowing.  Preparing the Schema, forest and domain for Lync 2013 was a little different for a  null root domain. If this is the case, you must perform the following so the topology will publish. The Error you will get will look something like this;



Schema must be run in the root domain and works ok as:

Install-CsAdServerSchema -Ldf “C:\Program Files\Microsoft Lync Server 2013\Deployment\Setup”

The LDF file is located on the Lync installation disk on the deployment\setup folder.

Once the Schema is extended, your next step may fail. The command run would be:

Enable-CsAdForest –

You will also find that if you run enable-Csadforest in the root or child domain, the command will fail by reporting errors that the domain controller is not writable, or the user is not a  member of the group to update the forest in the root domain (Universal groups are missing from the root domain), or the reference to an object is missing, etc… The bottom line is  you need to log into the forest root or null root of the forest with Enterprise admin permissions and run the following:

  1. Log into the Root Null forest as Enterprise Admin
  2. Open Lync Control Panel from Null Root DC.
  3. Run the following:
  4.     Enable-CsAdForest -GroupDomain rootsdomain.local  -GroupDomainController dc.domain.local -GlobalCatalog dc.domain.local
    1. Open the Lync Deployment wizard and run the Prepare domain as normal and now. prepare domain is going to work because this does not need access to the Root domain, The main issue here is the Forest Level command is run against the child DC or GC. The Enable-CSADforest is not able to run against the domain GC Or DC. The command fails in Lync Deployment Wizzard. It chooses one of the non-Root Forrest Domain controllers by default.


How to set up Lync 2013 RDP 8.0 with a Virtual Desktop Environment including a WYSE thin client.

The difficulty of setting up a virtualized client to function with Lync 2013 was the order of steps then the method used to install the necessary bits. Please follow vendor specific information to determine the way your particular thin client needs to be provisioned. In my instance, I used a WYSE X90M7 thin client with Windows 7 Embedded as the Operating System.  In this article WYSE refers to the physical client and VDI client refers to the virtual machine that will run on the Wyse.

My particular set up was a VDI in a box 5.3 setup with Hyper-V as the hypervisor. I have Server 2012 on all servers, Windows 7 SP1 embedded is running on the WYSE, and the VM is going to be windows 8. All but the embedded machine support RDP 8.0 natively. Lync 2013 is on Server 2012 as well and July updates have been applied.

Prerequisites include a fully functional Lync environment with correct EWS functionality. With this in place, the steps to get Lync 2013 running across multiple virtualization technologies with RDP 8 is laid out as follows.


  • The Server for Lync Needs to be 2012 or, if you have 2008 R2 server, updates for Server 2008 R2 and windows 7 need to be applied. This includes any windows 7 machines, including a VDI client like WYSE- running Windows 7 embedded.
  • The Wyse client needs the latest update (KB2574819)
  • Please keep in mind the Wyse updates procedure requires 3-4 restarts in and out of admin mode. Here are the sub steps for the two needed updates:
    • Boot WYSE to admin mode (hold down the shift key after splash and hold until you admin login. administrator and Wyse#123 for the password
    • use the FBWF filter. Disable it. This should be a red ICON on the desktop. Restart back into ADMIN mode.
    • Install the above 2 updates.
    • Restart into admin mode
  • The next update is to the VDI (Wyse machine) client. This Lync 2013 plug-in will be X32 or X64
  • Warning: the VDI client and the physical client must be on the same “bitness”. In other words, the x32 Wyse, means I am using a VM that is 32 bit windows 8, with lync 32 bit client installed.
  • The plug-in needs to be extracted to a flash drive, before being installed in the physical VDI hardware. In my case, the hard drive was small. I ran the command lyncvdi.exe /extract:pathfolder and then ran the installer from the USB. The Lync plug-in was about 750 MB.
  • Now RDP 8 and Lync VDI client are installed on the Wyse terminal. If RDP is installed your connection will look like this:

Figure 1


If you don’t see it installed, then you can also download the plug-in for RDP 8 from the Wyse support site for your model.  Use the ADMIN mode to install the update. Once you have all the bits in the correct location, The other prerequisites can be accomplished.


  • Log in as Admin mode (WYSE), Go to the mmc-file->add remove snapin->certificates->local computer and import the internal and external pool FQDN certificates, Root CA certificate, and other certificates as required by your organization.
  • On the Wyse client- add the following Registry Key-   HKLM\Software\Policies\Microsoft add a key called office, Add a Key under that called 15.0. Add a key under that called Lync. Create a new string in the Lync folder called “TrustModelData”. The values here will be the pool FQDN, and any FQDN for all Lync servers in the organization that need to have a trust to the endpoint.
  • On the Lync server enable the redirection policy- New-CsClientPolicy -Identity 2013Lync -EnableMediaRedirection $true
  • Configure GPO Redirection as per this article on local audio redirection  (mmc->group policy object editor) of WYSE and Domain Policy  (gpmc.msc)-
  • Set terminal services RDP to allow redirection
  • Set fDisableAudioCapture to 0 in the registry location – HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp
  • On Lync Server, set the existing policy or create a new policy to allow media redirection. An Example:  New-CsClientPolicy -Identity VDI -EnableMediaRedirection $true

Next, is it time to move to the VDI instance and details. I had to set the Wyse machine default RDP settings to use the remote computer and do not record. I then set the Virtual client (VDI in a box client) to play on this computer and enable audio redirect.  QOS is beyond the scope of this article, but needs to be considered if you are planning to use the VDI in production.  See TechNet for More information on its setup.  The VDI client needs to be setup like the following.


  • The virtual client needs to be the same bitness as the Wyse terminal it will be connecting from.
  • If Windows 7 install  hot fix 2592687 and 2574819 as explained above.  In my case the Windows 7 VDI client is joined to the domain.
  • For Windows 7 or 8, install the Lync VDI module and Lync full client, with latest patch. The basic client will not work.
  • Install Integration services for hypervisor, or VMware tools or Citix Agent, depending on the virtualization used.
  • VDI plug-in Charts overview
  • Verify the local or domain policies default to RDP 8.0.  If not they must be set manually. Here is a good walk through on this subject at

Once this is completed, if you have not finished bringing the WYSE terminal out of admin mode by restarting in Admin Mode and  Enable the FBWF filter . Restart the client into admin mode and make sure you have anything else done you want to complete. login to regular mode and login to VDI machine with RDP 8. Start your
client and make a call to it. It will look like this when it works: