Twitter

Wednesday, July 23, 2014

Lync 2013 Client, Desktop Sharing shows blank screen (Windows 7, Windows 8, Windows 8.1)

I came across this problem, where a customer reported:
A user could not participate on desktop sharing session, neither in conference nor in a p2p session. Other video related submission were working, like video or white board.
First I was guessing it could have been the video driver, but if video in Lync was working it didn't sound quite logic.

After investigating this problem, I saw a ActiveX blocking Error Message in the Eventviewer:

Microsoft Lync
CLSID: {00000000-0000-0000-0000-000000000000}
CATID: {9B179D6E-9BDB-454b-BE3D-89F9A792BD39}
The ActiveX Compatibility setting disabled loading this object to help protect your security.

15.0.4433.1506
0x80004005

This let me investigate more closer into Internet Explore. Well even there is couldn't see anything directly:

Microsoft reports several TechNet article:
http://support.microsoft.com/kb/240797/en-us
http://support.microsoft.com/kb/909738/en-us

So you need to change the ActiveX Control Settings for Lync 2013 Client:

SOLUTION:

Go and delete both registry keys. A reboot is not necessary and it will work.

In Windows 7, Windows 8 and Windows 8.1 they are hidden here:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Internet Explorer\ActiveX Compatibility\{00000000-0000-0000-0000-000000000000}

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{00000000-0000-0000-0000-000000000000}



Wednesday, July 16, 2014

Polycom VVX UC Software 5.1.1 Revision B is released

Hello everyone,
 
We are pleased to announce  the most awaited Polycom® UC Software 5.1.1 Revision B associated utilities and documents are now available on the Polycom Product Support web pages (http://support.polycom.com) for download.
 
UC Software 5.1.1 Revision B is a UC Software feature for all VVX Business media phones and SoundStructure.
 
This Version 5.1.1 Rev. B is now certified from Microsoft for Lync 2013
Polycom UC Software 5.1.1 Revision B offers support for the following endpoint platforms:
·      VVX® 300/310 business media phone
·      VVX® 400/410 business media phone
·      VVX® 500 business media phone
·      VVX® 600 business media phone
·      VVX® 1500 business media phone
·      Polycom® SoundStructure®
This release also provides support for the following VVX accessories:
·      Polycom VVX® camera
·      Polycom VVX® Expansion Module
 
What is available now on web?
·         UC Software 5.1.1 Revision B ( Split & Combined)
·         Polycom CAB files for UC Software 5.1.1 Revision B
·         Release Notes for 5.1.1 Revision B
·         Administrators’ Guide 5.1.0
 
How to download UCS 5.1.1 Revision B software, release notes & documents:
 
You can obtain the software and the related documentation from the supported phone model pages: example Click SPIP560/Polycom® Latest UC Software Release/ Polycom® UC Software Support Center
 
Manual Phone Update via UserInterfce (WEB):
Software is also available on the Polycom Hosted server and Phone can be upgraded by using the phone’s web UI.
Note:  Polycom BToE Connector 2.3.0 and ZTP will be updated soon

Monday, July 14, 2014

Cannot join external Lync Meeting: Lync Edge Server Single IP Address (How too and issued Problems for Web Conferenceing)

Lync Edge Server FQDN and IP PORTS

As we all know, we can configure Lync Edge Server in several way.

1) Single Edge Server with a SINGLE IP ADDRESS
2) Single Edge Server with MULTIPLE IP ADDRESSES (3x IPs)
3) Multiple Edge Server in a Pool, with MULTIPLE IP ADDRESSES (Zx 3 IPs)

Regardless what we are going to configure, there are common / well-known TCP Port necessary making Lync work, which are:

Access:
Port: 443 and 5061

Conferencing:
Port: 443

AV:
Port: 443


External FQDN with single IP address:

What can we see here? If we are going to choose a single IP address, we would have TCP Port overlapping. Therefore the only way avoiding this is assigning other ports.
Additionally we will also see and are reminded that Lync highly depends on DNS. If we have single IP, we must have use single, unique FQDN for all services.

E.g.:
ACCESS:
SIP.CUSTOMER.COM PORT:5061

CONFERENCING:
SIP.CUSTOMER.COM PORT:5061

AV:
SIP.CUSTOMER.COM PORT:5061


External FQDN with multiple IP addresses:

In comparison, if we are choosing to make use of three individual IP addresses. We also need three different FQDN, one for each service.

ACCESS:
SIP.CUSTOMER.COM PORT:443
 
CONFERENCING:
CONF.CUSTOMER.COM PORT:443
 
AV:
AV.CUSTOMER.COM PORT:443


If we now compare with the Microsoft provided illustration of the Edge Server related Enterprise Perimeter Network. This TCP Port named here are for INCOMING CONNECTIONS ONLY.
Now it becomes more clearer what the requirements are if a outside Lync user needs a connection to the published services.

The most common used server are:
IM, Audio/Video, Desktop or App Sharing, as well as Presence Queries.
Regardless which configuration was chosen, the single IP or triple IP configuration. Those service are all addressed via the common port of 443 and 5061. So we can assume, those service are mostly working independently of the chosen configuration model.

Web Conferencing Service:

Now we need having a look into the Lync Web Conferencing Service, publish via the Edge Server. Right, we looked at the incoming IP connection and here is a different
If you really configure Best-Practice and user three (3) public IP addresses, everything is going to be fine. Now one should experience any issue. This is due to the connection mad to e.g. conf.customer.com TCP Port 443 incoming.
And this ports are always activated on every Firewall or via the Reverse Proxies.

But what happened if we are using the single IP address with single FQDN?
Sure, as you can see in the config example, we must use another TCP Port rather than 443.
As per default, Microsoft suggests TCP Port 444.
But regardless of this, what ever port we are going to chose, mostly the outgoing Firewalls are not open for any for those other TCP Ports.

This clearly means, you will experience issues with a lot of your Federation Partners!

NOTE:
Beware of the negative impact if you decide going for a SINGLE PUBLIC IP ADDRESS. I do NOT recommend this configuration.


Having a look into the Protocol:

Beside the trace, this is also very nice example of how the Edge service is acting as a Application Proxy, you see how the Edge receiver an internal message, will do  the processing and than only it will send the message on behalf out to the internet.
I traced a problematic single IP configuration from outgoing point of view:
This is the Edge Server:

The customer clicked an MEETING INVITE in Outlook, the Web Browser opened and was issuing the conference back to the Lync Desktop Client.

- invited user is identified as nils.caller@correct.com (aka CALLER)
- internal network is 10.10.x.y with an AD FQDN INTERNAL.AD
- meeting initiator is false@singlip.com and meeting ID is V3JZ92CZ (aka  ORGANIZER)
- external single IP 99.79.91.241

 
Edge intern NIC incoming from caller -> organizer INVITE
the Edge should initiate the outgoing meeting, seen in the message-body. the conferencing service should add an used (caller) to the meeitng
TL_INFO(TF_PROTOCOL) [0]097C.0834::07/11/2014-11:15:26.143.0000003d (SIPStack,SIPAdminLog::ProtocolRecord::Flush:ProtocolRecord.cpp(265))[2376455152] $$begin_recordTrace-Correlation-Id: 2376455152
Instance-Id: BF9DB
Direction: incoming;source="internal edge";destination="external edge"
Peer: LYNCFEPOOL01.INTERNAL.AD:51714
Message-Type: request
Start-Line: INVITE sip:false@singleip.com;gruu;opaque=app:conf:focus:id:V3JZ92CZ SIP/2.0
From: "Caller, Nils"<sip:nils.Caller@correct.com>;tag=e4776a37ed;epid=f5710ea2b3
To: <sip:false@singleip.com;gruu;opaque=app:conf:focus:id:V3JZ92CZ>
Call-ID: 53fa037467934a3aa58afa7da405cffd
CSeq: 1 INVITE
Contact: <sip:nils.Caller@correct.com;opaque=user:epid:6Ng_wBKilFeryhezW1lEuAAA;gruu>
Via: SIP/2.0/TLS 10.10.10.127:51714;branch=z9hG4bKDFE93E20.E0C27AFE227343AD;branched=FALSE
Via: SIP/2.0/TLS 10.10.45.69:49360;ms-received-port=49360;ms-received-cid=2E9D600
Record-Route: <sip:LYNCFEPOOL01.INTERNAL.AD:5061;transport=tls;ms-fe=LYNCFRCLSERV01.INTERNAL.AD;opaque=state:T;lr>;tag=0CF71FDEF89C166BEDCEB50B598409B1
Max-Forwards: 69
Content-Length: 1018
Content-Type: application/cccp+xml
Message-Body:


- <request xmlns="urn:ietf:params:xml:ns:cccp"
mscp="http://schemas.microsoft.com/rtc/2005/08/cccpextensions"
C3PVersion="1"
to="sip:false@singleip.com;gruu;opaque=app:conf:focus:id:V3JZ92CZ"
from="sip:nils.Caller@correct.com"
requestId="344391952">
+ <addUser>
</request>


 
Next the domain discovery done by the Edge Server and finding the FQDN and IP
TL_INFO(TF_CONNECTION) [3]097C.02C0::07/11/2014-11:15:26.174.000001eb (SIPStack,SIPAdminLog::WriteConnectionEvent:SIPAdminLog.cpp(454))[3899431948] $$begin_recordSeverity: information
Text: TLS negotiation started
Local-IP: 10.11.10.84:61621
Peer-IP: 99.79.91.241:5061
Peer: sip.singleip.com:5061
Connection-ID: 0x49E800
Transport: M-TLS


 
Here the TLS negotiation INFO message is generated.
TL_INFO(TF_DIAG) [0]097C.0C74::07/11/2014-11:15:26.252.00000286 (SIPStack,SIPAdminLog::WriteDiagnosticEvent:SIPAdminLog.cpp(802))[1802118479] $$begin_recordSeverity: information
Text: Routed a locally generated request
SIP-Start-Line: NEGOTIATE sip:127.0.0.1:5061 SIP/2.0
SIP-Call-ID: 38AA2A4D958FC58A1F97
SIP-CSeq: 1 NEGOTIATE
Peer: sip.singleip.com:5061


 
The Edge Server send the negotiate message the meeting org.
TL_INFO(TF_PROTOCOL) [0]097C.0C74::07/11/2014-11:15:26.252.00000292 (SIPStack,SIPAdminLog::ProtocolRecord::Flush:ProtocolRecord.cpp(265))[1802118479] $$begin_recordTrace-Correlation-Id: 1802118479
Instance-Id: BF9DC
Direction: outgoing;source="local";destination="external edge"
Peer: sip.singleip.com:5061
Message-Type: request
Start-Line: NEGOTIATE sip:127.0.0.1:5061 SIP/2.0
From: sip:SIP.CORRECT.COM;tag=6AA3DC66E3BF1C9E7EFA44888B1B7E51
To: sip:sip.singleip.com
Call-ID: 38AA2A4D958FC58A1F97
CSeq: 1 NEGOTIATE
Via: SIP/2.0/TLS 10.11.10.84:61621;branch=z9hG4bKD7CAB5A3.FA2521EF7066539E;branched=FALSE
Max-Forwards: 0
Content-Length: 0
Compression: LZ77-64K
Supported: NewNegotiate,OCSNative,ECC,IPv6,TlsRecordSplit
Server: RTC/5.0


 
We now receive the SIP 200/OK message based in the INVITE, so the ACCESS Edge at the caller site is working.
TL_INFO(TF_PROTOCOL) [0]097C.0C74::07/11/2014-11:15:26.283.000002bf (SIPStack,SIPAdminLog::ProtocolRecord::Flush:ProtocolRecord.cpp(265))[3194725999] $$begin_recordTrace-Correlation-Id: 3194725999
Instance-Id: BF9DD
Direction: incoming;source="external edge";destination="internal edge"
Peer: sip.singleip.com:5061
Message-Type: response
Start-Line: SIP/2.0 200 OK
From: sip:SIP.CORRECT.COM;tag=6AA3DC66E3BF1C9E7EFA44888B1B7E51
To: sip:sip.singleip.com;tag=EDEE8C0427072C271B9B823E3B26BC5F
Call-ID: 38AA2A4D958FC58A1F97
CSeq: 1 NEGOTIATE
Via: SIP/2.0/TLS 10.11.10.84:61621;branch=z9hG4bKD7CAB5A3.FA2521EF7066539E;branched=FALSE;received=80.157.6.163;ms-received-port=61621;ms-received-cid=D5BD000
Content-Length: 0
Compression: LZ77-64K
Supported: NewNegotiate,OCSNative,ECC,TlsRecordSplit
Server: RTC/4.0



Edge as Application Proxy must process several Information, here connection is established with the organizer site
TL_INFO(TF_CONNECTION) [0]097C.0C74::07/11/2014-11:15:26.283.000002da (SIPStack,SIPAdminLog::WriteConnectionEvent:SIPAdminLog.cpp(383))[3899431948] $$begin_recordSeverity: information
Text: Connection established
Peer-IP: 99.79.91.241:5061
Peer: sip.singleip.com:5061
Transport: M-TLS
Data: alertable="no"


 
Now the Edge has processed even more and also agreed the sip.singleip.com domain, its certificate and established TLS connection
TL_INFO(TF_CONNECTION) [0]097C.0C74::07/11/2014-11:15:26.283.0000030a (SIPStack,SIPAdminLog::WriteConnectionEvent:SIPAdminLog.cpp(383))[3899431948] $$begin_recordSeverity: information
Text: SIP message traffic has established the peer server as a Discovered Domain federated peer
Peer-IP: 99.79.91.241:5061
Peer: sip.singleip.com:5061
Transport: M-TLS


 
Edge internal process info for send INVITE from intern site (caller), domain is now in the discovered domain list
TL_INFO(TF_DIAG) [0]097C.0C74::07/11/2014-11:15:26.283.00000310 (SIPStack,SIPAdminLog::WriteDiagnosticEvent:SIPAdminLog.cpp(802))[2376455152] $$begin_recordSeverity: information
Text: The message has a Discovered Domain
SIP-Start-Line: INVITE sip:false@singleip.com;gruu;opaque=app:conf:focus:id:V3JZ92CZ SIP/2.0
SIP-Call-ID: 53fa037467934a3aa58afa7da405cffd
SIP-CSeq: 1 INVITE
Peer: sip.singleip.com:5061
Data: domain="singleip.com"


 
Edge is now preparing for sending the INVITE to the external organizer
TL_INFO(TF_DIAG) [0]097C.0C74::07/11/2014-11:15:26.283.0000036b (SIPStack,SIPAdminLog::WriteDiagnosticEvent:SIPAdminLog.cpp(802))[2376455152] $$begin_recordSeverity: information
Text: Routed a request to a Discovered Domain federated peer
SIP-Start-Line: INVITE sip:false@singleip.com;gruu;opaque=app:conf:focus:id:V3JZ92CZ SIP/2.0
SIP-Call-ID: 53fa037467934a3aa58afa7da405cffd
SIP-CSeq: 1 INVITE
Peer: sip.singleip.com:5061



Here it comes:
Edge has now proxied the internal caller sending request he would like to join the external meeting. therefore the caller request is send finally to the external site (singleip.com) 
TL_INFO(TF_PROTOCOL) [0]097C.0C74::07/11/2014-11:15:26.283.00000377 (SIPStack,SIPAdminLog::ProtocolRecord::Flush:ProtocolRecord.cpp(265))[2376455152] $$begin_recordTrace-Correlation-Id: 2376455152
Instance-Id: BF9DB
Direction: outgoing;source="internal edge";destination="external edge"
Peer: sip.singleip.com:5061
Message-Type: request
Start-Line: INVITE sip:false@singleip.com;gruu;opaque=app:conf:focus:id:V3JZ92CZ SIP/2.0
From: "Caller, Nils"<sip:nils.Caller@correct.com>;tag=e4776a37ed;epid=f5710ea2b3
To: <sip:false@singleip.com;gruu;opaque=app:conf:focus:id:V3JZ92CZ>
Call-ID: 53fa037467934a3aa58afa7da405cffd
CSeq: 1 INVITE
Contact: <sip:nils.Caller@correct.com;opaque=user:epid:6Ng_wBKilFeryhezW1lEuAAA;gruu>
Via: SIP/2.0/TLS 10.11.10.84:61621;branch=z9hG4bK1616E949.64036B07705F839E;branched=FALSE;ms-internal-info="aqgQ48dd2SfNMeRfbruAAZXq8dFFBTtKluOHag-KpPn1wHawNkNq4BswAA"
Via: SIP/2.0/TLS 10.10.10.127:51714;branch=z9hG4bKDFE93E20.E0C27AFE227343AD;branched=FALSE;ms-received-port=51714;ms-received-cid=4B8F00
Via: SIP/2.0/TLS 10.10.45.69:49360;ms-received-port=49360;ms-received-cid=2E9D600
Record-Route: <sip:SIP.CORRECT.COM:5061;transport=tls;epid=f5710ea2b3;lr;ms-key-info=AAEAAdJOgwIBMa2t5ZzPASlkLxWClArLg5fYAz5vMU1--3qvyX7XKhdANCiKC-GE07tJz6E3DmxM-Uo1JCVXZwiNF0uZ2ZM-MBkpzf8q70BVHpEeVVJxW4-ptvp1zWHfjfpaL75-G59cC8TTOSXREQP7w4wTVzV730yNT9Ph48zRr2YVibOrM1R1QJThh3fhOMGY6BjkBdw1rGGmlgbssXVOjCAu7Q9vs3VwxSIOqB6A1VbZNUG8zoAjDaqm_FdS6cziurxnJSAl9at4yVYFUS7LIzHbhMal7Clz5WDPENfDR-6YkottO4A0_I4ocqv3P6k_txrZumb8uB5Gf0pnwjZuwy2boSzwgo2aVu-OrvBcaL9IIlRA0kMgZs62YXBCUVl_F7KRJ9cSUpgbN-B5pMVtPhU7nlCZluxkqB-db2B149xOw4aQ4Eyso3c7gRntFMq61dfI3kPyPFDgNdpDtNmgWwcvEBXFCK2l8EGSHElRsNSIyE-D1UgGQBieo3bPW41uxGIXJfndV9nAMQlbB6mqR-UEbwNGyCgX_cbdHEdPQbClzoqvQFDZ9D857BWNaTBAYfVtbstvrVLsx5vvjAuFY_zFDtNjwKZtYkKJRnedDYnv0kJbBK7pu3bw3LQ0WruFFS-shxBWC9mrUSrhFggcQIoolloakvT0bXL4tHdggWb9fsSSUrCMCQm4KSQC;ms-route-sig=dtgD9HmH2Ck2pYUw_OaiCBzENJLtQyjLBgVnOdt26vsAoHawNkjqWm6wAA>;ms-rrsig=dtATEXIj4kuWMVvcXWz8MoMCB3C4BfDk6UfICkkpSjpRMHawNkjqWm6wAA;tag=6AA3DC66E3BF1C9E7EFA44888B1B7E51
Record-Route: <sip:LYNCFEPOOL01.INTERNAL.AD:5061;transport=tls;ms-fe=LYNCFRCLSERV01.INTERNAL.AD;opaque=state:T;lr>;tag=0CF71FDEF89C166BEDCEB50B598409B1
Max-Forwards: 68
Content-Length: 1018
Content-Type: application/cccp+xml
Message-Body:


- <request xmlns="urn:ietf:params:xml:ns:cccp"
mscp="http://schemas.microsoft.com/rtc/2005/08/cccpextensions"
C3PVersion="1"
to="sip:false@singleip.com;gruu;opaque=app:conf:focus:id:V3JZ92CZ"
from="sip:nils.Caller@correct.com"
requestId="344391952">
+ <addUser>
</request>


 

Immediately after the INVITE was send, the SIP 404 Not Found was received. How this can be happened? 
The Web Conferencing Server is awaiting incoming request on TCP Port 444, This is REQUEST is coming directly from the initiating client. The local PC's Lync Client. 
The TCP Port 444 is blocked and the opposite Edge Server now send the INFO that a client did not send a request, meaning he did not receive any request matching on Port 444. (You would see this message, if you run a WireShark on our Web Traffic)
TL_INFO(TF_PROTOCOL) [0]097C.0C74::07/11/2014-11:15:26.299.000003b3 (SIPStack,SIPAdminLog::ProtocolRecord::Flush:ProtocolRecord.cpp(265))[2376455152] $$begin_recordTrace-Correlation-Id: 2376455152
Instance-Id: BF9DE
Direction: incoming;source="external edge";destination="internal edge"
Peer: sip.singleip.com:5061
Message-Type: response
Start-Line:
SIP/2.0 404 Not Found
From: "Caller, Nils"<sip:nils.Caller@correct.com>;tag=e4776a37ed;epid=f5710ea2b3
To: <sip:false@singleip.com;gruu;opaque=app:conf:focus:id:V3JZ92CZ>;tag=EDEE8C0427072C271B9B823E3B26BC5F
Call-ID: 53fa037467934a3aa58afa7da405cffd
CSeq: 1 INVITE
Via: SIP/2.0/TLS 10.11.10.84:61621;branch=z9hG4bK1616E949.64036B07705F839E;branched=FALSE;ms-internal-info="aqgQ48dd2SfNMeRfbruAAZXq8dFFBTtKluOHag-KpPn1wHawNkNq4BswAA";received=80.157.6.163;ms-received-port=61621;ms-received-cid=D5BD000
Via: SIP/2.0/TLS 10.10.10.127:51714;branch=z9hG4bKDFE93E20.E0C27AFE227343AD;branched=FALSE;ms-received-port=51714;ms-received-cid=4B8F00
Via: SIP/2.0/TLS 10.10.45.69:49360;ms-received-port=49360;ms-received-cid=2E9D600
Content-Length: 0



Two more processing infos regading the SIP domain. 
TL_INFO(TF_DIAG) [0]097C.0C74::07/11/2014-11:15:26.299.0000040f (SIPStack,SIPAdminLog::WriteDiagnosticEvent:SIPAdminLog.cpp(802))[2376455152] $$begin_recordSeverity: information
Text: The message has a Discovered Domain
SIP-Start-Line:
SIP/2.0 404 Not Found
SIP-Call-ID: 53fa037467934a3aa58afa7da405cffd
SIP-CSeq: 1 INVITE
Peer: sip.singleip.com:5061
Data: domain="singleip.com"
 

 
Preparing the SIP 404 message being send to the internal Lync Frontend.
TL_INFO(TF_DIAG) [0]097C.0C74::07/11/2014-11:15:26.299.000004c3 (SIPStack,SIPAdminLog::WriteDiagnosticEvent:SIPAdminLog.cpp(802))[2376455152] $$begin_recordSeverity: information
Text: Response successfully routed
SIP-Start-Line: SIP/2.0 404 Not Found
SIP-Call-ID: 53fa037467934a3aa58afa7da405cffd
SIP-CSeq: 1 INVITE
Peer: LYNCFEPOOL01.INTERNAL.AD:51714


  
the proxied message is now send to the internal Frontend.
TL_INFO(TF_PROTOCOL) [0]097C.0C74::07/11/2014-11:15:26.299.000004cf (SIPStack,SIPAdminLog::ProtocolRecord::Flush:ProtocolRecord.cpp(265))[2376455152] $$begin_recordTrace-Correlation-Id: 2376455152
Instance-Id: BF9DE
Direction: outgoing;source="external edge";destination="internal edge"
Peer: LYNCFEPOOL01.INTERNAL.AD:51714
Message-Type: response
Start-Line: SIP/2.0 404 Not Found
From: "Caller, Nils"<sip:nils.Caller@correct.com>;tag=e4776a37ed;epid=f5710ea2b3
To: <sip:false@singleip.com;gruu;opaque=app:conf:focus:id:V3JZ92CZ>;tag=EDEE8C0427072C271B9B823E3B26BC5F
Call-ID: 53fa037467934a3aa58afa7da405cffd
CSeq: 1 INVITE
Via: SIP/2.0/TLS 10.10.10.127:51714;branch=z9hG4bKDFE93E20.E0C27AFE227343AD;branched=FALSE;ms-received-port=51714;ms-received-cid=4B8F00
Via: SIP/2.0/TLS 10.10.45.69:49360;ms-received-port=49360;ms-received-cid=2E9D600
Content-Length: 0
ms-diagnostics: 1034;reason="Previous hop federated peer did not report diagnostic information";Domain="singleip.com";PeerServer="sip.singleip.com";source="SIP.CORRECT.COM"
ms-edge-proxy-message-trust: ms-source-type=AutoFederation;ms-ep-fqdn=EDGEPOOL01.INTERNAL.AD;ms-source-verified-user=unverified;ms-source-network=federation


  
The Frontend Server informs the organize site now that the connection was failing and Edge Server starts it proxying process.
TL_INFO(TF_PROTOCOL) [0]097C.0C74::07/11/2014-11:15:26.299.00000507 (SIPStack,SIPAdminLog::ProtocolRecord::Flush:ProtocolRecord.cpp(265))[3798769121] $$begin_recordTrace-Correlation-Id: 3798769121
Instance-Id: BF9DF
Direction: incoming;source="internal edge";destination="external edge"
Peer: LYNCFEPOOL01.INTERNAL.AD:51714
Message-Type: request
Start-Line: ACK sip:false@singleip.com;gruu;opaque=app:conf:focus:id:V3JZ92CZ SIP/2.0
From: "Caller, Nils"<sip:nils.Caller@correct.com>;tag=e4776a37ed;epid=f5710ea2b3
To: <sip:false@singleip.com;gruu;opaque=app:conf:focus:id:V3JZ92CZ>;tag=EDEE8C0427072C271B9B823E3B26BC5F
Call-ID: 53fa037467934a3aa58afa7da405cffd
CSeq: 1 ACK
Via: SIP/2.0/TLS 10.10.10.127:51714;branch=z9hG4bKDFE93E20.E0C27AFE227343AD;branched=FALSE
Max-Forwards: 70
Content-Length: 0
ms-diagnostics-public: 5012;reason="ACK is being generated on receipt of a failure final response for an INVITE forked by application";AppUri="http%3A%2F%2Fwww.microsoft.com%2FLCS%2FUdcAgent"


 
Processing the ACK so it can be send to the organizer
TL_INFO(TF_DIAG) [0]097C.0C74::07/11/2014-11:15:26.299.00000637 (SIPStack,SIPAdminLog::WriteDiagnosticEvent:SIPAdminLog.cpp(802))[3798769121] $$begin_recordSeverity: information
Text: The message has a Discovered Domain
SIP-Start-Line: ACK sip:false@singleip.com;gruu;opaque=app:conf:focus:id:V3JZ92CZ SIP/2.0
SIP-Call-ID: 53fa037467934a3aa58afa7da405cffd
SIP-CSeq: 1 ACK
Peer: sip.singleip.com:5061
Data: domain="singleip.com"


 
Processing and check against the discovered domain list.
TL_INFO(TF_DIAG) [0]097C.0C74::07/11/2014-11:15:26.299.00000679 (SIPStack,SIPAdminLog::WriteDiagnosticEvent:SIPAdminLog.cpp(802))[3798769121] $$begin_recordSeverity: information
Text: Routed a request to a Discovered Domain federated peer
SIP-Start-Line: ACK sip:false@singleip.com;gruu;opaque=app:conf:focus:id:V3JZ92CZ SIP/2.0
SIP-Call-ID: 53fa037467934a3aa58afa7da405cffd
SIP-CSeq: 1 ACK
Peer: sip.singleip.com:5061



The ACK is now send the sip.singleip.com organizer site. 

TL_INFO(TF_PROTOCOL) [0]097C.0C74::07/11/2014-11:15:26.299.00000685 (SIPStack,SIPAdminLog::ProtocolRecord::Flush:ProtocolRecord.cpp(265))[3798769121] $$begin_recordTrace-Correlation-Id: 3798769121
Instance-Id: BF9DF
Direction: outgoing;source="internal edge";destination="external edge"
Peer: sip.fev.com:5061
Message-Type: request
Start-Line: ACK sip:fleu@fev.com;gruu;opaque=app:conf:focus:id:V3JZ92CZ SIP/2.0
From: "Schumacher, Nils"<sip:nils.schumacher@berner-mattner.com>;tag=e4776a37ed;epid=f5710ea2b3
To: <sip:fleu@fev.com;gruu;opaque=app:conf:focus:id:V3JZ92CZ>;tag=EDEE8C0427072C271B9B823E3B26BC5F
Call-ID: 53fa037467934a3aa58afa7da405cffd
CSeq: 1 ACK
Via: SIP/2.0/TLS 10.11.10.84:61621;branch=z9hG4bK1616E949.64036B07705F839E;branched=FALSE
Via: SIP/2.0/TLS 10.10.10.127:51714;branch=z9hG4bKDFE93E20.E0C27AFE227343AD;branched=FALSE;ms-received-port=51714;ms-received-cid=4B8F00
Max-Forwards: 69
Content-Length: 0
ms-diagnostics-public: 5012;reason="ACK is being generated on receipt of a failure final response for an INVITE forked by application";AppUri="http%3A%2F%2Fwww.microsoft.com%2FLCS%2FUdcAgent"


Monday, June 30, 2014

Lync Stress Test – How Too, Setup and Configuration (free eBook)

I extended the last Lync Stress Test Guide. Version 2.0

Now all important information are provided, incl. all parameters which can be modified and customized around all stress tests.

You can download the free eBook here:
Microsoft TechNet: http://gallery.technet.microsoft.com/office/Lync-Stress-Test-How-Too-c4c276e1
SlideShare: http://de.slideshare.net/thomaspoett/lync-stress-test-guide-v20-ebook

 

Table of Content:

Introduction
The Calculation Process (I can recommend to you):
Build the Stress Test Lab
The Stress Test Process:
The Validation Process:
User Provisioning Tool
Setup User Provisioning Tool
User Creation
Contacts Creation
Distribution List Creation
Location Info Service Config
Run Configuration Scripts
Stress Test Simulations
User Profile Generator
Common Configuration
General Scenario
Voice Scenario
Reach Scenario
Mobility Scenario
Summary (Important User Load definition)
Table of Figures


Sunday, June 8, 2014

Lync Stress Test - Key Health Indicators KHI (how to design/ define the server hardware requirements)

Since Microsoft released Lync Server 2013, there was one change in the planning document. No detailed SPECs were released so you could exactly calculate your server performance requirements.
Truly, there is the performance calculation sheet which provides you with a rough overview.

For this entire process you need the following tools and documents:
I provide you with the Lync KHI Performance Counter: Download here
Note:
The XML I have provide contains a consolidated Lync Frontend installation entirely on drive C: with 6 CPU core. If you have another setup, please add more CPU counter and if the SQL Server is installed on drive D:, please also add the I/O counters for this drive too.

But generally the server hardware requirements are physically and virtually the same:


Front End, Back End, Standard Edition, pChat - Server
Component
Minimum requirements
CPU
2x64 bit CPU with 6 Core (also if virtualized)
Memory
32 GB
Disk
2x RAID 1 min. 72GB[1] free space
6x RAID 10 for SQL databases
Network
1x Dual-Port network card with min. 1GBit/Sec
If teaming is activated, unique MAC address must be used




[1] It is required having at least 20GB free disk space after installation, else it might have a serious impact during update and CU installations, this is related tot he local SQL database copies.


Edge, Standalone Mediation – Server and Director, Office Web Apps
Component
Minimum requirements
CPU
64 bit CPU and min. 4 Core (also if virtualized)
Memory
16 GB
Disk
Mind. RAID 6 Performance with min. 72GB free space
Network
1x Dual-Port network card with min. 1GBit/Sec
If teaming is activated, unique MAC address must be used

This general definition for your hardware is simply not enough if you design your environment. There are some questions you need to answer to your customers:
- how can I guarantee the hardware performance on virtual environments
- how does Lync impact our SAN
- if we don't utilize the max user, how and can I reduce CPU's and RAM, or even the SQL Disk I/O's

Here you stand as consultant and don't know what to say.
E.g. the supportability matrix give you a clear answer, design the server as provided in the requirement document.
So, say you have 3 Frontend servers as recommended for High Availability (HA), but you only run 1.000 users.
This would be a complicated answers, since you simply cannot know the answer, as it was possible with Lync 2010, since you had more information how to calculate.

The Calculation Process (I recommend to you):

Lync server load highly depends on the user profile!
Talk to your customer and figure out what is the main purpose and how in the past users utilized Voice (PSTN and PBX)
Analyze the Video utilization, also and especially the AppSharing (with is video data too)
Start using the Lync Server 2013 Capacity Calculator.
With the results popping up you need to reverse engineer the capacity needed on your servers.
 
Finally you have some SPEC's, but you need (better say: MUST) validate them if you are not using the exact SPEC provided in the tables above.


The Stress Test Process:

Please use the Stress Test Guide from Microsoft and setup the environment in a Test Lab first. It simple even on physical, as well as on virtual environment.

Some recommendations from my experiences:

1. the Stress Client SPEC's are not sufficient as Microsoft wrote, please use here more CPU's, at least the double amount.
2. Split the Test across 3 Stress Clients,
    Stress Test Client 1: All IM, APPClients and Conferences

    Stress Test Client 2: all Reach Client features
    Stress Test Client 3: all PSTN functions (PSTN Gateway Simulator), here you might need more clients, since the PSTN Simulator can only provide one (1) gateway on a PC
3. run a Pre-Test, where you closely monitor you client performances, especially the CPU after the so call RAMP UP TIME
4. Check if information are written to the Lync Monitoring Database (validate the reports)
5. Re-balance some of you Test Scenarios and run the Step 3 again if necessary
6. Start the Main Stress Test now

Now it's time for the core test itself.
Ensure you either monitor the KHI on a dedicated machine or on the Lync server themselves. Please do NOT use any of the Stress Test Clients!

I have provided you with the Performance Monitor DataCollection. Make sure you see some results during Step 3.


The Validation Process:

Now you have all results necessary to write your report and even see you underestimated the server load ;)

Get the Performance Data and see if any of the counters above did jump above some of the provided counters for a longer periods of time or if any of those counters jump more frequently above the thresholds.

The go to the Lync Monitoring Reporting and validate all Failure Reports (related to the test you have ran).

I also recommend checking the Lync Server Eventlogs.

With the collection and analysis of all data write your own validation paper to the customer.

NOTE:
If you need help, don't hesitate asking me for help, I can provide you professional service and do the write-up for you.
Use the contact app on the right site of my blog.