NetApps file share does not work via alias for Skype for Business

Log Name:      Lync Server

Source:        LS Storage Service

Date:          21.01.2019 13:55:45

Event ID:      32008

Task Category: (4006)

Level:         Error

Keywords:      Classic

User:          N/A

Computer:      

Description:

Unexpected exception.

Message=Error: Path \\fs_AppsData_.domain.com\Apps_Data$\SFBshare\1-WebServices-11\StorageService failed to be read for flushed data. Error details: System.IO.IOException: The account used is a computer account. Use your global user account or local user account to access this server.

The problem is that we use alias, if we change alias to server name, it works. This share is actually NetApp vfiler.

Here is a reference on how to add SPN for the alias. The alias is CNAME or A record.

https://social.technet.microsoft.com/Forums/lync/en-US/896a987f-990f-4668-9fc4-9c0be523f4db/lync-replication-wont-work-with-file-share-on-netapp-nas?forum=ocsplanningdeployment

SCVMM manually install agent

https://seneej.com/2013/06/04/scvmm-2012-sp1-host-agent-manual-installation-and-client-logs/

Direct Access on Windows 10 does not send troubleshooting logs

http://itcalls.blogspot.com/2018/08/windows-10-directaccess-collect-logs.html

Skype for Business Address Book normalisation rules

In the past Lync used txt files Company_Phone_Number_Normalization_Rules.txt to manage normalisation rules, with SFBit is now powershell Get-CsAddressBookNormalizationRule, etc.

By default it contains already some rules, but if you need to modify you can.

Here is a test tool that will show existing rules and will allow to test with a specific test number:
https://gallery.technet.microsoft.com/Skype-for-Business-Address-2ab65ca7


One thing remains unclear - the tool and all articles that I could find says that SFB will automatically strip spaces and other symboles like dashes from the phones number. However, I have an example where it does not work - when number is typed in contact lookup in SFB client the string must match exactly the string in AD phone field, otherwise the contact is not proposed. For the moment I do not know why. In another installation it work ok. It looks like something related to either client version  or method (web search only) or client  or GPO policy - had no time to analyse further.