User strored procedure
dbo.DiagShowPublisherPresence
in RTCLOCAL SQL copy on each FrontEnd (not SBA)
http://mikestacy.typepad.com/mike-stacys-blog/sql/
Search This Blog
Thursday, June 14, 2018
Tuesday, May 29, 2018
Skype for Business Hybrid one way
We have a problem of one way presence in hybrid deployment. From one Prems, we can not see online users in the same domain. Here is subscribe ok we get on onprem side:
TL_INFO(TF_PROTOCOL) [EDGE01\EDGE01]0E00.1480::05/25/2018-19:37:29.817.0000BB79 (SIPStack,SIPAdminLog::ProtocolRecord::Flush:ProtocolRecord.cpp(261)) [2044151173] Trace-Correlation-Id: 2044151173
Instance-Id: F3
Direction: incoming;source="external edge";destination="internal edge"
Peer: sipfed.online.lync.com:5061
Message-Type: response
Start-Line: SIP/2.0 200 OK
From: "Test Skype1"
To:
Call-ID: f7f33e99902d45488e4b2c76924d00a5
CSeq: 1 SUBSCRIBE
Contact:
Via: SIP/2.0/TLS 10.100.1.41:49186;branch=z9hG4bK9FE0F169.F3E35464A2AA98C9;branched=FALSE;ms-internal-info="aaDSMbd_7l0a4U9R6npyIrDBxYlV2GUNocfizAJ2ScR15kVOPzyc4VHQAA";received=52.112.132.124;ms-received-port=49186;ms-received-cid=B6C95E00
Via: SIP/2.0/TLS 10.20.1.36:61901;branch=z9hG4bKB46E0708.870D177F11B578C8;branched=FALSE;ms-received-port=61901;ms-received-cid=300
Via: SIP/2.0/TLS 10.20.1.9:49176;branch=z9hG4bK7D7D836D.E605002CA2AA98C9;branched=FALSE;ms-received-port=49176;ms-received-cid=4DBD00
Via: SIP/2.0/TLS 192.168.168.244:55348;received=84.75.200.148;ms-received-port=55348;ms-received-cid=1400
Record-Route:
Record-Route:
Content-Length: 470
Content-Type: multipart/related; type="application/rlmi+xml";start=resourceList; boundary=1550b37c575843dbb98e18be4e840f3d
ms-split-domain-info: ms-traffic-type=SplitIntra
ms-telemetry-id: D31CB29B-EEE7-56FB-A1C5-7F04353D74C3
Expires: 0
Require: eventlist
Event: presence
subscription-state: terminated;expires=0
ms-piggyback-cseq: 1
Supported: ms-piggyback-first-notify
Message-Body:
--1550b37c575843dbb98e18be4e840f3dContent-Transfer-Encoding: binaryContent-ID: resourceListContent-Type: application/rlmi+xml
Solution, refresh directory schema in AADconnect.
Monday, May 28, 2018
How to check user attributes in Azure AD
Open https://graphexplorer.azurewebsites.net/#
login with a user who has access to Azure AD
then type url:
https://graph.windows.net/myorganization/users/tskype1@domain.com
login with a user who has access to Azure AD
then type url:
https://graph.windows.net/myorganization/users/tskype1@domain.com
Monday, May 7, 2018
Windows 7 WebDAV client requires SHA protocol
If you have a Sharepoint site that provides Open with explorer functionality make sure you do not disable SHA (hash) protocol on your server. Otherwise some clients with Windows 7 will not be able to open shares in Explorer.
Tuesday, May 1, 2018
Thursday, April 12, 2018
Exchange and Skype for Business error 14563: Two servers cannot be configured at the same FQDN with different server version numbers.
Event ID 14563
Source LS Protocol Stack
Two servers cannot be configured at the same FQDN with different server version numbers.
Cannot configure a server at FQDN [exchange.doamin.com] because another server is already configured there with a different server version number.
Cause: This is a configuration problem.
Resolution:
Review the server roles that are configured at this FQDN and ensure that they have identical version numbers.
Please review https://blogs.technet.microsoft.com/jenstr/2012/11/13/when-to-have-a-lync-trusted-application-pool-for-exchange-owa-im-integration/
It seems that you have trustedapplicationpool defined in Topology and also UM server is assigned for a dial plan. This will push twice server name to Skype.
Remove from topology or if you have several servers, do it in the way that it is popolated without a conflict.
Source LS Protocol Stack
Two servers cannot be configured at the same FQDN with different server version numbers.
Cannot configure a server at FQDN [exchange.doamin.com] because another server is already configured there with a different server version number.
Cause: This is a configuration problem.
Resolution:
Review the server roles that are configured at this FQDN and ensure that they have identical version numbers.
Please review https://blogs.technet.microsoft.com/jenstr/2012/11/13/when-to-have-a-lync-trusted-application-pool-for-exchange-owa-im-integration/
It seems that you have trustedapplicationpool defined in Topology and also UM server is assigned for a dial plan. This will push twice server name to Skype.
Remove from topology or if you have several servers, do it in the way that it is popolated without a conflict.
Wednesday, April 11, 2018
Microsoft-Windows-Windows Fabric/Admin warning 4097 in Skype for Business
Hello,
if you have this error (actually warning) in Skype for Business FrontEnd, you most probably can ignore it.
Investigation:
check settings.xml in C:\ProgramData\Windows Fabric\GVASFE1.domain.com\Fabric\Fabric.Config.1.0.0
you can see
Parameter Name="IgnoreCrlOfflineError" Value="true"
Parameter Name="CrlCheckingFlag" Value="3221225476"
So the setting is set to ignore the error. The description of CrlCheckingFlag you can find in
C:\Program Files\Skype for Business Server 2015\Server\Core\ClusterManifest.Xml.Template
CrlCheckingFlag setting follows the rest of the Lync Server components (sipstack, web) which
set the following flags:
CERT_CHAIN_CACHE_ONLY_URL_RETRIEVAL =0x00000004 | // do not go on the wire for cert retrieval
CERT_CHAIN_REVOCATION_CHECK_CACHE_ONLY =0x80000000 | // do not go on the wire for cert revocation check
CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT=0x40000000
0xC0000004=3221225476 (unsigned int)
as you see CrlCheckingFlag equal 0xC0000004
means - check cache only - exclude root - we must be checking only intermediate CRL and if it is locally cached.
to check local cache (of current user) use command
certutil -urlcache CRL
to chache a specific CRL - use command
certutil -f -urlfetch -verify gvasfe1.cer
where cer is a file with a certificate
refer https://blogs.technet.microsoft.com/pki/2006/11/30/basic-crl-checking-with-certutil/
Fabric run as network service, so you can check that also, but it would require hacking: https://windoh.wordpress.com/2011/04/23/crl-caching-in-windows-and-a-little-bit-about-ocsp-caching-too/
Summary: as you can see SFB Windows fabric is set up to ignore the error and continue, the error may come from issues retrieving CRL or absence of CRL in local cache. In most cases you should also ignore this error. If you want to fix it (not recommended), replace in ClusterManifest.Xml.Template %CRLCHECKINGFLAG% as 0 and reboot
if you have this error (actually warning) in Skype for Business FrontEnd, you most probably can ignore it.
Investigation:
check settings.xml in C:\ProgramData\Windows Fabric\GVASFE1.domain.com\Fabric\Fabric.Config.1.0.0
you can see
Parameter Name="IgnoreCrlOfflineError" Value="true"
Parameter Name="CrlCheckingFlag" Value="3221225476"
So the setting is set to ignore the error. The description of CrlCheckingFlag you can find in
C:\Program Files\Skype for Business Server 2015\Server\Core\ClusterManifest.Xml.Template
CrlCheckingFlag setting follows the rest of the Lync Server components (sipstack, web) which
set the following flags:
CERT_CHAIN_CACHE_ONLY_URL_RETRIEVAL =0x00000004 | // do not go on the wire for cert retrieval
CERT_CHAIN_REVOCATION_CHECK_CACHE_ONLY =0x80000000 | // do not go on the wire for cert revocation check
CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT=0x40000000
0xC0000004=3221225476 (unsigned int)
as you see CrlCheckingFlag equal 0xC0000004
means - check cache only - exclude root - we must be checking only intermediate CRL and if it is locally cached.
to check local cache (of current user) use command
certutil -urlcache CRL
to chache a specific CRL - use command
certutil -f -urlfetch -verify gvasfe1.cer
where cer is a file with a certificate
refer https://blogs.technet.microsoft.com/pki/2006/11/30/basic-crl-checking-with-certutil/
Fabric run as network service, so you can check that also, but it would require hacking: https://windoh.wordpress.com/2011/04/23/crl-caching-in-windows-and-a-little-bit-about-ocsp-caching-too/
Summary: as you can see SFB Windows fabric is set up to ignore the error and continue, the error may come from issues retrieving CRL or absence of CRL in local cache. In most cases you should also ignore this error. If you want to fix it (not recommended), replace in ClusterManifest.Xml.Template %CRLCHECKINGFLAG% as 0 and reboot
Subscribe to:
Posts (Atom)