Twitter

Tuesday, August 26, 2014

Lync Edge Server or Pool Server have uncommon call drops (30sec) and other IM issues

I came across a funny problem.
I customer complained if a federated call was initiated the call always dropped after exactly 31 seconds.
What we could figure out was this error message.

SIP/2.0 504 Server time-out
ms-client-diagnostics: 52085;reason="Dialog does not exist"

So I continued the analysis and traced the calls. With the wonderful tool SNOOPER, I was able to get a see the "Call Flow Windows", which is really a very helpful visualization of the exact package flow.
I saw now the SIP Session was initiated correctly.

BUT
I figured out, the PRACK message was not acknowledge, so the ACK 200/OK was missing. Even the message was send correctly the target host. "This is a kind of early media." The Voice stream is established, but need to be reconfirmed in case some port/ parameter should be changes/ optimized.
Since the ACK is missing, truly the Lync Server must think the call has ended and actively dropped it.

This all is happened on the EDGE Server of the affected customer.
I really struggled, as I also analyzed the HOSTS file on the EDGE Server.

So far ones I run the IPCONFIG /SHOWDNS command and saw something strange. After some DNS entries I have seen wired characters. Especially behind the Frontend FQDNs.

SOLUTION:
The HOSTS File was not written proper and contain invisible characters behind the FQDNs. So Lync EDGE Server was not able finding the Frontend Servers via DNS and therefore the PRACK request from the Frontend could not be ACK acknowledged.  



Lync 2013 Reverse Proxy Solution with IIS ARR (Application Request Routing) - Instllation and Consulting guide

Before we start with the Lync 2013 Reverse Proxy solution design and setup guide. I want to keep some supportability statement in mind.

By today, the date of writing this blog, Microsoft has to supported solutions.
1. Microsoft TMG (Thread Management Gateway) - if the TMG was purchased before the EOL date.
2. Microsoft IIS ARR (Internet Information Server Application Request Routing)

A third solution, the Microsoft Web Application Proxy introduced with Windows Server 2012 R2 is not jet supported. This is due to the reason that WAP has a problem with multiple SIP Domains, meaning here: I cannot handle requests other than for the primary SIP domain, especially the MEET simple URL.

The configuration guide here runs through the entire process from the ISS ARR Installation and setup. The guide concentrates on Windows Server 2012 R2. Therefore we need to understand the installation process for IIS ARR first. ARR cannot simply installed by download the MSI package, rather than using the Web Installer. If you are going to use the Standalone installer, you need to distribute it.

(Typical Lync Reverse Proxy Design with IIS ARR)

Since this we are focusing on Windows Server 2012 R2, the IIS ARR Version described here is: Version 3.0

Download Links:
Web Platform Installer: http://www.microsoft.com/web/gallery/install.aspx?appid=ARRv3_0
Installer Package: http://www.microsoft.com/en-us/download/details.aspx?id=39715

Install Application Request Routing 3.0:

Before we install ARR, we need to have the following prerequisites installed for IIS.

Therefore we install with this command (valid for all platforms)
Import-Module ServerManager
Add-WindowsFeature Web-Static-Content,Web-Default-Doc,Web-Dir-Browsing,Web-Http-Errors,Web-Net-Ext,Web-Http-Logging,Web-Request-Monitor,Web-Http-Tracing,Web-Filtering,Web-Stat-Compression,Web-Mgmt-Console,NET-Framework-Core,NET-Win-CFAC,NET-Non-HTTP-Activ,NET-HTTP-Activation,RSAT-Web-Server


 
If you should have the ARR Installer, it looks this.
 
If you try using the Installer, you might run into an error: Web Farm Framework is a requisite for installing Application Request Routing. (PI is installing Web Farm Framework automatically)

 
Us the PI and start over again:
 
The PI provides several options and make sure you select ARR version 3.0:
 
 
 

Once the installation has ended, you might restart the server and please ensure the Windows 2012 R2 server is fully patched/ updated.

Next we start configuring ARR according to the need.
In our case here, we have multiple SIP domains. As in Lync recommended, you will have multiple MEET pages, a single DIALIN page and the Lync Web Service, as well as the LYNCDISCOVER URLs. It is necessary regarding Lync Mobility Service, that your internal Deployment allows the internal Mobile device to connect the mobility service via the IIS ARR.
This is not part of this article, but keep in mind the mobility service URL is related to the external Web Service FQDN.

Configuration of IIS ARR (Application Request Routing):

First Step is creating the Server Farm. this is not related to a IIS Farm of Servers, e.g. which you might create for HA/ redundancy.
A Farm is related to the URL you are going to publish.

Since Lync simple URL publishing does not require any SSL Offloading if you have the External Web Site in Lync assigned with a Public Certificate, you do not need a certificate installed on the IIS.
Most likely you have assigned a private certificate from your internal Certificate Authority, you have to assign the IIS ARR an public certificate and reencrypt the traffic for internal use.
Be aware of two point here:
1. this is called SSL Offloading and requires some extra CPU load on your server
2. IIS must not be "domain joined" therefore you need to have the internal Certificate authority Root Certificates assigned as TRUSTED !

Also you must be aware of the TCP Port redirection.
for HTTP request redirect 80 -> 8080
for HTTPS request redirect 443 -> 4443

Lync internal IIS has two web site identified, Lync internal and external Web Services. The web sites are assigned with different ports, while the external service interact with 8080 and 4443.

You have to repeat all the following steps for each simple URL!


 Identify the simple URL here:

Ensure you have set the internal TCP Ports (8080 and 4443):
Remember, you must specify the HTTP port too. If you don't want to expose HTTP to the Internet, you have to restrict this on you fronting Firewall.


Set MEMORY CACHE DURATION to: 60 seconds:

HTTP version is: PASS THROUGH and Time-Out is set to 200 seconds:

Routing: is defined as use URL Rewrite to inspect incoming requests:

Choose your public certificate for this service:

Repeat this steps for all Simple URLs.


Finally assure all URLs are defined and have the correct settings:


Next step should be a Test. I prefer the Dialin web page, since I doesn't require an immediate login. If you can see this page, try also if you can login. This will ensure you that the Web Ticket Service in Lync is working correctly too.


Last but not least, you can validate all URL Requites if you click to the IIS Root and click Rewrite:


 So far this is the entire configuration for Lync 2013 and Lync 2010 too. If you need to publish other service e.g. Exchange, you might choose similar settings. In Exchange you might want to use a pre-authentication, which Lync 2013 does not require.

Happy IIS ARR setup ;)




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