[Skype for Business] SDN Interface 3.0

Microsoft a publié le 2 février une mise a jour pour l'interface SDN.

• New Fields in 3.0:
  Some new requested fields have been added to Schema D. This might break backward compatibility with some receivers and therefore requires a specific activation using a hidden schema extension setting.

• Schema Validation:
  Schema validation of messages from Dialog Listener to SDN Manager is (now) disabled (minimalschemavalidation=true) by default. Minimal validation is performed on messages (specifically client QoE messages). Schema validation can be enabled by setting the SdnManager parameter minimalschemavalidation=false. Schema validation errors found will only be logged. This setting’s default has been changed to respond an increasing number of schema validation errors due to recent changes in the SfB client’ QoE structure.

• Support for TLS 1.2
  SSL connections between SDN Manager and Dialog Listener now require TLS1.2 support. SSL connections between SDN manager and subscribers now support TLS1.2 and TLS1.1. SSL 3.0 is, for security reasons, rejected. Some older OS versions might need to adjustments.
  App sharing streams will continue to be measured based on the 500kbps/1Mbps limit for poor, bad, good in end of call stream quality. If VbSS is used AppSharing data streams will check different limits (15/14K).
• Customer Experience reporting:
  The SDN Interface will report anonymous usage data as part of the Customer Experience program. No user PII or organizational data is collected.
• New fields available with 3.0 when schema preview is enabled

- In a Federation call scenario, some messages are not transmitted
- During retransmission, some call ended events are incorrectly re-ordered
- SdnManager Performance Counter '# calls completed' would not account for some calls leading to an incorrect counter

- Logs created for replay do not account for some fields in the message
- Trunk field was inconsistently reported in QoE and Signaling messages were being filtered
- Log level Debug didi not have sufficient detail to troubleshoot an issue
- Fixed association of protocols name in signaling messages with different capitalization.
- SDNManager does not accept all 2xx code to indicate successful receipt of a message (only accepts 200 OK)
- AppliedBandwidth limit in VSS scenario Is not being handled correctly

Notes et problèmes connus:

1. LDL Unattended install parameters are not validated
2. There is no way to specify an output file for all Subscribers or Listeners.
3. Previous instances of REDIS allowed case-sensitive subscriber names. These are no longer supported, and are ignored. Users must either drop the entire REDIS data cache OR remove the case-sensitive subscriber name by matching the case-sensitivity.
4. Dialog Listener install, by default, configures a Service startup dependency on Skype for Business Server Front-End service. The installer then attempts to start the LDL service, which will attempt to start the FE service. If this is undesirable, the workaround is to add the installer parameter 'SKIPREGISTRATION=1' to the invocation of msiexec.exe.
5. The contents of the MSDiagnostics field reported to subscribers may contain PII, SDN Interface does not obfuscate this field.
6. After the SDN Manager has been upgraded to 3.0, active Dialog Listener services MAY require restart. If the new SDN Manager uses a new MSPL script it is not updated in active Dialog Listeners until that Dialog Listener settings are updated. Certain settings need to be updated in the Dialog Listeners after the SDN Manager has been upgraded to 3.0. Please either restart the Dialog Listener services, or as a simple trick, add a random Listener setting or change some setting.
7. LSM Unattended install does not check for missing required parameters Subsequent errors provide little information.
8. Connection attempts using SSL from Dialog Listener to an SDN Manager installed on WS2008R2 fails. WS2008R2 machines do not support TLS1.2 by default. When hosting SDN Manager, the host needs to enable TLS1.2 support in its registry.
9. Support for Lync 2010 is now deprecated.
10. After installing version 3.0 in an active deployment, there may be some errors reported in the logs and reports lost for some calls due to a change in how QoE reports are kept in the data store. Only reports for events during the time of the upgrade may be affected. This is still true if they jump from 2.2 to 3.0.
11. InCallQoE is referred to as InCallQoS in the SfB front-end powershell configuration, which can be misleading if you look for the setting to activate/deactivate.
12. Due to some changes to how we store state for calls, during an upgrade, some failures may be reported for ongoing calls during the upgrade.