Unable to change an ESXi 5.x server’s hostname in the vSphere client because the OK button is grayed out

I’ve recently been asked at least 5 times over the past 2 months a problem that may seem trivial but at the same time be quite the annoyance.  An administrator attempts to change the hostname of a newly deployed ESXi 5.x server via the vSphere client:

… but notices that as soon as they change the name the OK button grays out:

Editing the IP address doesn’t enable the button either.

The answer to this issue is actually quite simple and that is because the Domain field isn’t filled out and while you can change the hostname at the console without entering a domain, the same can’t be done in the vSphere client so to enable the OK button, simply enter a domain:

Definitely one of the more silly issues I’ve heard about over the past few months.

Installing Veeam license onto Veeam Backup and Replication 7.0 throws the error: “The provided license is not valid.” or “License is not installed.”

Problem

You’re attempting to install Veeam Backup and Replication 7.0 on a new Windows Server 2012 server but noticed that as you go through the install and enter the license file you received from Veeam (veeam_backup_full_0_4.lic), you are unable to proceed past Provide License step because the following error is thrown:

 The provided license is not valid.

 

Removing the license file and installing Veeam as trial completes without any errors so you attempt to install the license by navigating to Help –> License:

Select the license:

But then receive the following error:

License is not installed.

You need to install a license before you can start using the product.

To install the license, select Menu > Help > License > Install License…

Solution

Searching through the web didn’t provide me with much information on this error so I went ahead and opened a support call with Veeam.  The first response from the engineer was that I may have a Veeam 7 license but I’m installing it into a Veeam 6.5 install but that wasn’t the case so he told me to try opening the license file with notepad to see whether there was actually content in there and to my surprise, there wasn’t.  The .lic file was completely blank.

The engineer proceeded to tell me that he has seen a lot of clients downloading the .lic file from webmail (i.e. Exchange OWA) which ends up corrupting the file. I went back to my Outlook 2013 full client to redownload the file on my laptop and quickly saw the content.  From there, I copied the .lic file to the server which then installed fine.  Strange issue but glad it was a quick fix.  One last point I’d like to try and make is that I asked the engineer whether I could just copy the license file contents to the another notepad then save it as a .lic file and he said no because that wouldn’t work.  Hope this helps anyone who might come across the same issue.

Lync Server 2013 and Avaya RCC integration logs the error: “Start-Line: SIP/2.0 481 Call Leg Does Not Exist”

Problem

You’re setting up an RCC integration between Lync Server 2013 and Avaya’s AES (Application Enablement Services) server and while you’ve set up all of the configuration required for Lync Server 2013, users see a No Phone System Connection error at the bottom of their Lync client:

Clicking on the error displays the following:

Cannot connect to the phone system.

The call control server may be temporarily unavailable. If the problem continues, please contact your support team.

Launching the logging tool on the front end server to perform a trace (S4 and SIP) reveals the following errors:

TL_INFO(TF_PROTOCOL) [0]1240.1694::09/18/2013-17:01:41.530.0002f184 (SIPStack,SIPAdminLog::ProtocolRecord::Flush:2436.idx(196))[2759714301] $$begin_record
Trace-Correlation-Id: 2759714301
Instance-Id: B33
Direction: outgoing;source="local"
Peer: 172.16.7.6:49478
Message-Type: response
Start-Line: SIP/2.0 481 Call Leg Does Not Exist
From: <sip:jdowling@contoso.bhl.bm>;tag=d25d5d219e;epid=ded4b550da
To: <sip:aes@aes.contoso.bhl.bm>;tag=7C025889D5D01E62305AC8F8FF841540
Call-ID: 07c2e2224dc1452fa9739adf4661a781
CSeq: 1 CANCEL
Via: SIP/2.0/TLS 172.16.7.6:49478;ms-received-port=49478;ms-received-cid=2000
Content-Length: 0
ms-diagnostics: 2;reason="See response code and reason phrase";HRESULT="0xC3E93C09(PE_E_TRANSACTION_DOES_NOT_EXIST)";source="bhllyncstd13srv.contoso.bhl.bm"
$$end_record

Another error reveals the following:

TL_INFO(TF_PROTOCOL) [0]1240.1694::09/18/2013-17:01:41.530.0002f184 (SIPStack,SIPAdminLog::ProtocolRecord::Flush:2436.idx(196))[2759714301] $$begin_record
Trace-Correlation-Id: 2759714301
Instance-Id: B33
Direction: outgoing;source="local"
Peer: 172.16.7.6:49478
Message-Type: response
Start-Line: SIP/2.0 481 Call Leg Does Not Exist
From: <sip:jdowling@contoso.bhl.bm>;tag=d25d5d219e;epid=ded4b550da
To: <sip:aes@aes.contoso.bhl.bm>;tag=7C025889D5D01E62305AC8F8FF841540
Call-ID: 07c2e2224dc1452fa9739adf4661a781
CSeq: 1 CANCEL
Via: SIP/2.0/TLS 172.16.7.6:49478;ms-received-port=49478;ms-received-cid=2000
Content-Length: 0
ms-diagnostics: 2;reason="See response code and reason phrase";HRESULT="0xC3E93C09(PE_E_TRANSACTION_DOES_NOT_EXIST)";source="bhllyncstd13srv.contoso.bhl.bm"
$$end_record

In some situations, you may also see the following error logged:

TL_INFO(TF_PROTOCOL) [0]2268.22EC::09/18/2013-15:27:57.415.004c3c79 (SIPStack,SIPAdminLog::ProtocolRecord::Flush:2436.idx(196))[2906464479] $$begin_record
Trace-Correlation-Id: 2906464479
Instance-Id: 322
Direction: incoming
Peer: aes.contoso.bhl.bm:4723
Message-Type: response
SIP/2.0 404 Not found: Session could not be established - no AD record loaded for this user
Start-Line: SIP/2.0 404 Not found: Session could not be established - no AD record loaded for this user
From: "Dowling, James" <sip:jdowling@contoso.bhl.bm>;tag=76adae21b5;epid=ded4b550da
To: <sip:aes@aes.contoso.bhl.bm>
Call-ID: e05b19021ca2409f93abeadeff04ab94
CSeq: 1 INVITE
Via: SIP/2.0/TLS 172.16.1.160:62970;branch=z9hG4bKDFE445FC.559F3707CB33968D;branched=FALSE;rport=62970,SIP/2.0/TLS 172.16.7.6:61597;ms-received-port=61597;ms-received-cid=1900
Content-Length: 0
$$end_record

Solution

While I’m sure there may be various reasons that would log these errors, the situation I had was actually because the Enterprise Directory information on the Avaya AES server wasn’t filled out:

Once I filled out the information on the AES server, RCC began to work as expected.

Exchange Server 2013 OWA throws the error: “Error: Your request can't be completed right now. Please try again later.”

Before I begin, let me state that I doubt many others will experienced the same issue I had even though the error message:

Error: Your request can't be completed right now. Please try again later.

… appears quite frequent when searched but none of the solutions fixed my issue.  To save others from going through all of the troubleshooting steps I went through myself as well as with a Microsoft support engineer, what ended up fixing my issue was to treat the server as if I’ve lost it and had to perform a recovery install with the:

Setup /m:RecoverServer /IAcceptExchangeServerLicenseTerms

… command.  There are many articles and blog posts out there demonstrating a recovery install so I’ll just list out the basic steps that I did:

1. Deploy a new Windows Server 2012 server and don’t join it to the domain
2. Configure the same drives and letters as the existing Exchange Server 2013
3. Copy the Exchange databases over to the new server maintaining the same drive and path
4. Copy the prerequisites required for Exchange over to the new server
5. Copy the installed Exchange Server 2013 Cumulative Update package (in my case CU2) to the new server
6. Export the public certificate used for OWA and other services to a new server
7. Document where Exchange is installed (this information can be found via ADSIEdit by navigating to CN=Ex-15,CN=Servers,CN=First Administrative Group,CN=Administrative Groups,CN=First Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=Contoso,CN=Local and opening the CN=EX-15 object then viewing the properties of the msExchInstallPath attribute.
8. Shutdown the existing Exchange Server 2013 server (we will not start this server back up again so make sure you’ve copied what you need off of it)
9. Reset the old Exchange server’s computer account
10. Assign the new Exchange server’s IP to be the same as the problematic one
11. Change the name of the new server to the problematic Exchange server’s name and restart
12. Join the new renamed server to the domain
13. Install the prerequisites for Exchange Server 2013 (the downloaded packages and Roles and Features via PowerShell)
14. Using the same CU2 package, run the command Setup /m:RecoverServer /IAcceptExchangeServerLicenseTerms

Once the install is complete, restart the server, log into ECP, mount the IS store, reconfigure the virtual directories (i.e. OWA, OAB, etc), review the event logs, then test the services.  This fixed the issue I had as the Microsoft engineer suspected that here was some file, handler mapping, or a component that wasn’t functioning properly.

With the solution out of the way, I’m going to include the troubleshooting steps below:

Problem

You have a new Exchange Server 2013 deployment (all roles on the same server) with CU2 installed in the environment and while testing OWA, you notice the following error when you attempt to read the content of an email:

Error: Your request can't be completed right now. Please try again later.

Composing new emails and sending it outbound appears to work properly:

However, browsing the contents of the sent email exhibits the same error:

Clicking on the Drafts node display the following:

Your request can’t be completed right now. Please try again later.

There are no items to show in this view.

Troubleshooting Steps Performed

The event logs do not show any relevant error messages.

Attempting to remove the net.pipe binding on the Site Bindings of Exchange Back End site in IIS:

… as per the following blog post:

http://gaurang-microsofttechnology.blogspot.com/2013/08/error-your-request-cant-be-completed.html

… does not correct the issue.  Note that I’ve confirmed with with a Microsoft engineer that there is no harm in removing this as it’s not used by OWA.

Checking the Port 444 certificate binding shows the default self signed certificate which was confirmed by Microsoft that it is ok for the Exchange Back End site in IIS.

Checking all of the IIS permissions as per the following KB:

Default Settings for Exchange Virtual Directories
http://technet.microsoft.com/en-us/library/gg247612.aspx

… appear to be fine.

Reinstalling the:

Windows Process Activation Service

• Process Model
• Configuration APIs

… does not fix the issue.

Trying to rerun the CU2 update does not work as you won’t be able to click the Next button to start the upgrade.  Running CU2 with setup /m:upgrade works but does not fix the issue.

Browsing the IIS logs in the folder:

C:\Program Files\Microsoft\Exchange Server\V15\Logging\HttpProxy\Owa

… and opening the latest log after mimiking the issue in OWA you noticed the following lines created:

2013-10-23T02:04:42.337Z,ebcea5c9-fff5-421b-a200-aaef3c04090a,15,0,712,12,,Owa,webmail.contoso.bm,/owa/ev.owa2,,FBA,True,contoso\hugh.nevile,,Sid~S-1-5-21-788572559-3134175131-1749204635-1116,Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0; chromeframe/30.0.1599.101),199.172.202.68,BM1-AZIM-40-001,200,200,,GET,Proxy,bm1-azim-40-001.contoso.local,15.00.0712.000,IntraForest,WindowsIdentity,Database~2ea1e285-a27c-4183-9931-dad6075ed100~~10/23/2013 2:13:42 AM,,,0,810,1,,1,0,,0,,0,,0,0,59951.0693,0,,,,3,1,59951,1,59958,0,59956,2,3,4,59959,?ns=PendingRequest&ev=PendingNotificationRequest&UA=0&cid=23bef3f4-905a-4782-b4ce-b1e3284f5d96&X-OWA-CANARY=1Rm53J0O10qf83-QL8VTQJ4jmRqnndAIvI239N21LeirqJbvhalTBvn7ONLGfv5yrj94xD4axCg.,,OnBeginRequest=0;,HttpException=ClientDisconnect;
2013-10-23T02:04:42.384Z,a1aefcad-d10a-43e0-8b66-301e1100eaaa,15,0,712,12,,Owa,webmail.contoso.bm,/owa/service.svc,FindConversation,FBA,True,contoso\hugh.nevile,,Sid~S-1-5-21-788572559-3134175131-1749204635-1116,Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0),199.172.202.68,BM1-AZIM-40-001,405,405,,POST,Proxy,bm1-azim-40-001.contoso.local,15.00.0712.000,IntraForest,WindowsIdentity,Database~2ea1e285-a27c-4183-9931-dad6075ed100~~10/23/2013 2:14:42 AM,,,875,1293,1,,5,0,,0,,0,,0,0,15.5942,0,1,0,2,0,0,0,0,6,0,1,3,3,8,11,?action=FindConversation&UA=0,,OnBeginRequest=5;,WebExceptionStatus=ProtocolError;ResponseStatusCode=405;WebException=System.Net.WebException: The remote server returned an error: (405) Method Not Allowed.    at System.Net.HttpWebRequest.EndGetResponse(IAsyncResult asyncResult)    at Microsoft.Exchange.HttpProxy.ProxyRequestHandler.<>c__DisplayClass20.<OnResponseReady>b__1e();
2013-10-23T02:05:31.649Z,c2614a6e-8846-4b55-9dc8-139e1cc9601e,15,0,712,12,,,,,,,,,,,,,BM1-AZIM-40-001,,,,,,,,,,,,,,,,,,,,,,,,,,600038.8438,,,,,,,,,,,,,,,,,,S:ActivityStandardMetadata.Action=GlobalActivity;I32:ADS.C[UNINSTR]=1;F:ADS.AL[UNINSTR]=4.7919,
2013-10-23T02:05:43.006Z,44349282-87e7-4520-92ad-aeca244490f8,15,0,712,12,,Owa,webmail.contoso.bm,/owa/ev.owa2,,FBA,True,contoso\hugh.nevile,,Sid~S-1-5-21-788572559-3134175131-1749204635-1116,Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0; chromeframe/30.0.1599.101),199.172.202.68,BM1-AZIM-40-001,200,200,,GET,Proxy,bm1-azim-40-001.contoso.local,15.00.0712.000,IntraForest,WindowsIdentity,Database~2ea1e285-a27c-4183-9931-dad6075ed100~~10/23/2013 2:14:42 AM,,,0,810,1,,1,0,,0,,0,,0,0,60606.254,0,,,,7,1,60581,3,60595,1,60593,4,5,6,60597,?ns=PendingRequest&ev=PendingNotificationRequest&UA=0&cid=23bef3f4-905a-4782-b4ce-b1e3284f5d96&X-OWA-CANARY=1Rm53J0O10qf83-QL8VTQJ4jmRqnndAIvI239N21LeirqJbvhalTBvn7ONLGfv5yrj94xD4axCg.,,OnBeginRequest=0;,HttpException=ClientDisconnect;
2013-10-23T02:06:09.245Z,2d027367-cd3a-40b0-8634-5c74a033db5b,15,0,712,12,,Owa,webmail.contoso.bm,/owa/ev.owa2,,FBA,True,contoso\torgeir.dagsleth,,Sid~S-1-5-21-788572559-3134175131-1749204635-1113,Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_5) AppleWebKit/536.30.1 (KHTML  like Gecko) Version/6.0.5 Safari/536.30.1,199.172.240.98,BM1-AZIM-40-001,200,200,,GET,Proxy,bm1-azim-40-001.contoso.local,15.00.0712.000,IntraForest,WindowsIdentity,Database~2ea1e285-a27c-4183-9931-dad6075ed100~~10/23/2013 2:10:49 AM,,,0,1140,1,,1,0,,0,,0,,0,0,319723.4178,0,,,,4,0,319712,1,319719,0,319717,2,2,3,319720,?ns=PendingRequest&ev=PendingNotificationRequest&UA=0&cid=ab24e4be-32f9-48f2-877c-cdaf1dd7c816&X-OWA-CANARY=KbqlV02F5EObilbXWME5wiHF9AOHndAIHbXU9aRJUWoCtt2QdtBS3st9SK8UzEhXxw_QjQWdkDo.&n=hn3x0v2p,,OnBeginRequest=0;,
2013-10-23T02:06:30.243Z,66e7d747-37a5-4909-acf4-a8afbf440e7a,15,0,712,12,,Owa,webmail.contoso.bm,/owa/ev.owa2,,FBA,True,contoso\torgeir.dagsleth,,Sid~S-1-5-21-788572559-3134175131-1749204635-1113,Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; WOW64; Trident/6.0; Touch),199.172.240.98,BM1-AZIM-40-001,200,200,,GET,Proxy,bm1-azim-40-001.contoso.local,15.00.0712.000,IntraForest,WindowsIdentity,Database~2ea1e285-a27c-4183-9931-dad6075ed100~~10/23/2013 2:11:09 AM,,,0,1706,1,,1,0,,0,,0,,0,0,320128.994,0,,,,3,1,320115,4,320124,0,320123,1,2,3,320125,?ns=PendingRequest&ev=PendingNotificationRequest&UA=0&cid=d346ff16-b3cd-4655-9a88-705154896893&X-OWA-CANARY=HQjKAb7cQUqZYxo77UNQ2sZzVEyGndAIaL8fK3fa16q8-KVMLXheqc4LBrRis4iMT7u7NPQS2Zc.,,OnBeginRequest=0;,

**Sorry about the word wrap but the lines are supposed to look like what is shown in the screenshot.

The output we’re interested in is actually the following:

WebExceptionStatus=ProtocolError;ResponseStatusCode=405;WebException=System.Net.WebException: The remote server returned an error: (405) Method Not Allowed.    at System.Net.HttpWebRequest.EndGetResponse(IAsyncResult asyncResult)    at Microsoft.Exchange.HttpProxy.ProxyRequestHandler.<>c__DisplayClass20.<OnResponseReady>b__1e();

To fix the error in the logs, perform the following:

Prior to making any changes to IIS, it is recommended to use the following command to backup the site settings first:

%windir%\system32\inetsrv\appcmd.exe add backup "My Backup Name"

The following is an example:

%windir%\system32\inetsrv\appcmd.exe add backup "IIS-Backup-10-22-2013"

The above command will create a folder in the following folder:

C:\Windows\system32\inetsrv\backup

After reviewing all the settings with the Microsoft engineer I was working with noticed that the environment with the issue was missing some Handler Mappings for the Default Website:

 

The following is another environment I have access to and note that the following 3 Handler Mappings is missing:

1. svc-Integrated-4.0
2. svc-ISAPI-4.0_32bit
3. svc-ISAPI-4.0_64bit

… are missing:

What ended up bringing the missing handler back was rerunning the prerequsites PowerShell cmdlet (this is for a server with all the roles installed, go to the following URL to find the cmdlets for other configurations http://technet.microsoft.com/en-us/library/bb691354(v=exchg.150).aspx#WS2012MBX):

Install-WindowsFeature AS-HTTP-Activation, Desktop-Experience, NET-Framework-45-Features, RPC-over-HTTP-proxy, RSAT-Clustering, RSAT-Clustering-CmdInterface, RSAT-Clustering-Mgmt, RSAT-Clustering-PowerShell, Web-Mgmt-Console, WAS-Process-Model, Web-Asp-Net45, Web-Basic-Auth, Web-Client-Auth, Web-Digest-Auth, Web-Dir-Browsing, Web-Dyn-Compression, Web-Http-Errors, Web-Http-Logging, Web-Http-Redirect, Web-Http-Tracing, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Lgcy-Mgmt-Console, Web-Metabase, Web-Mgmt-Console, Web-Mgmt-Service, Web-Net-Ext45, Web-Request-Monitor, Web-Server, Web-Stat-Compression, Web-Static-Content, Web-Windows-Auth, Web-WMI, Windows-Identity-Foundation

… close the IIS manager then execute iisreset command.  This did not fix my issue but probably nice to know for other environments.

We went on to try and recreate the web services directories with the following cmdlets:

Remove-WebServicesVirtualDirectory -Identity "ServerName\EWS (Default Web Site)"

Remove-WebServicesVirtualDirectory -Identity "ServerName\EWS (Exchange Back End)"

New-WebServicesVirtualDirectory -Server "ServerName" -WebSite "Default Web Site"

New-WebServicesVirtualDirectory -Server "ServerName" -WebSiteName "Exchange Back End" -role:mailbox

This did not fix the issue so we then tried to recreate the OWA virtual directories with the following cmdlets:

Remove-owavirtualdirectory -Identity "ServerName\owa (Default Web Site)"

Remove-owavirtualdirectory -Identity "ServerName\owa (Exchange Back End)"

New-owavirtualdirectory -SERVER "ServerName" -WebSite "Default Web Site"

New-owavirtualdirectory -SERVER "ServerName" -WebSiteName "Exchange Back End" -role:mailbox

We also went ahead to check the server component’s state with the cmdlet:

Get-ServerComponentState

… and all of them checked out ok.

--------------------------------------------------------------------------------------------------------------------------------------------------------------------

It was unfortunate that after 6 hours on a call with Microsoft, the engineer wasn’t able to fix it but I did appreciate the effort he put in.  Hope this helps anyone out there who may come across such an issue.

Using autodiscover to setup a user’s Outlook on a computer not joined to the domain keeps prompting for password

Problem

You have several remote users who are trying to set up their Outlook via the Outlook Anywhere service using Autodiscover to detect the settings but all of them are continuously prompted for their password.  The process looks similar to the following:

You enter the appropriate information:

The wizard proceeds to use the autodiscover service to set up the mailbox:

The user then receives a password prompt:

The user proceeds to type in their password but continuously gets prompted as shown above and after 3 or 4 attempts, the user is presented with the following:

An encrypted connection to your mail server is not available.

Click Next to attempt using an unencrypted connection.

Solution

Assuming your autodiscover service is set up appropriately and verified with the Microsoft Remote Connectivity Analyzer (https://testconnectivity.microsoft.com/) tool, this issue may be because your internal domain is different than your external SMTP domain.  In this example, the external SMTP domain is <someDomain>.com but the internal domain is <someDomain>.local.  This means that the user’s default UPN login is actually <username>.<someDomain>.local and not <username>.<someDomain>.com.  If we look closing to the default login username presented to the user, we will see that it has defaulted to the user’s email address which is not a valid login for the user:

One of the workarounds in this situation is to add a new UPN suffix to the domain with the external domain in Active Directory Domains and Trusts then change the user’s Account tab to use the new UPN:

If adding a new UPN suffix is not acceptable, the user can configure their mailbox by select User another account and change the login username to domain\username:

Doing so will allow the user to successfully configure their mailbox:

I find this simple issue can throw a lot of administrators off so I hope this post would help save someone’s time.

“Exchange Database iDataAgent” option grayed out with CommVault Simpana 9.0 R2 installer on Exchange Server 2013

Problem

You attempt to install the Exchange Database iDataAgent with the CommVault Simpana 9.0 R2 installer on Exchange Server 2013 but notice that the option grayed out:

Hovering over the option displays the following message:

Provides backup and recovery of Microsoft Exchange databases.

This platform is disabled because:

It requires a supported version of Microsoft Exchange.

 

Solution

As per the CommVault SP3 notes:

http://documentation.commvault.com/hds/release_9_0_0/books_online_1/english_us/service_pack/win32/sp9/list_of_updates.htm

… to add support for Exchange Server 2013, you will need to create the following registry key:

[HKEY_LOCAL_MACHINE\SOFTWARE\GalaxyInstallerFlags]

"bEmulateThirdPartyApps"=dword:00000001

Note that I had to create the GalaxyInstallerFlags key as it did not exist.  Once the key and dword is created, restart the installer and you should see the Exchange Database iDataAgent available:

Lync messages between 2 federated partners only work 1 way

Problem

You’ve set up federation between 2 Lync Server 2013 environments but notice that only 1 of the company can see presence information and have the ability to send messages while the other company is unable to see presence information from the other company, unable to send messages but is able to receive messages.  Opening up a logging session on the Lync Edge server at the company that is unable to send or see presence information and the logs reveal the following error entries:

**Note that the user tluk@ccs.bm is able to send messages and view presence.

TL_INFO(TF_PROTOCOL) [0]09F8.0C88::10/12/2013-01:39:41.834.00012234 (SIPStack,SIPAdminLog::ProtocolRecord::Flush:2436.idx(196))[1741920323] $$begin_record
Trace-Correlation-Id: 1741920323
Instance-Id: 2BDA
Direction: outgoing;source="internal edge";destination="external edge"
Peer: sip.ccs.bm:49487
Message-Type: response
Start-Line: SIP/2.0 200 OK
From: <sip:tluk@ccs.bm>;tag=2187c36e06;epid=25ff4d1f78
To: <sip:ccs@domain.bm>;epid=e69af42711;tag=ca96430b85
Call-ID: afd96a4c19f7408685609405dff39e7d
CSeq: 4 MESSAGE
Contact: <sip:ccs@domain.bm;opaque=user:epid:6m94aPj8T1WXhLvmR6kj4wAA;gruu>
Via: SIP/2.0/TLS 172.16.37.55:49487;branch=z9hG4bK5391C9B0.0FCE7A99208BC946;branched=FALSE;ms-internal-info="cj7lCn8xAJRUUdlatMoH--sroWxv41foxdQ3JeVVGNT-qZes4PDsNiuwAA";received=69.17.205.55;ms-received-port=49487;ms-received-cid=43E00
Via: SIP/2.0/TLS 172.16.1.152:51919;branch=z9hG4bK353C6B47.C170580869629948;branched=FALSE;ms-received-port=51919;ms-received-cid=500
Via: SIP/2.0/TLS 172.16.1.211:49162;branch=z9hG4bK9A01874C.B60005E6208AD946;branched=FALSE;ms-received-port=49162;ms-received-cid=8F1700
Via: SIP/2.0/TLS 172.16.58.131:54782;received=199.172.198.55;ms-received-port=57155;ms-received-cid=19F00
Content-Length: 0
$$end_record

TL_ERROR(TF_CONNECTION) [0]09F8.0C64::10/12/2013-01:39:45.516.000122b4 (SIPStack,SIPAdminLog::WriteConnectionEvent:1222.idx(452))[710685110] $$begin_record

Severity: error

Text: Failed to complete outbound connection

Peer-IP: 69.17.205.55:5061

Connection-ID: 0x44103

Transport: TLS

Result-Code: 0x8007274c

Data: fqdn="sip.ccs.bm";peer-type="FederatedPartner";winsock-code="10060";winsock-info="The peer did not respond to the connection attempt"

$$end_record

TL_ERROR(TF_DIAG) [0]09F8.0C64::10/12/2013-01:39:45.516.000122da (SIPStack,SIPAdminLog::WriteDiagnosticEvent:1222.idx(784))[1836810921] $$begin_record

Severity: error

Text: Message was not sent because the connection was closed

SIP-Start-Line: SUBSCRIBE sip:tluk@ccs.bm SIP/2.0

SIP-Call-ID: 57e81be269b942b2a579617dc94553f0

SIP-CSeq: 1 SUBSCRIBE

Peer: 69.17.205.55:5061

$$end_record

TL_INFO(TF_DIAG) [0]09F8.0C64::10/12/2013-01:39:45.516.0001259d (SIPStack,SIPAdminLog::WriteDiagnosticEvent:1222.idx(778))[1836810921] $$begin_recordSeverity: information
Text: Routed a locally generated response
SIP-Start-Line: SIP/2.0 504 Server time-out
SIP-Call-ID: 57e81be269b942b2a579617dc94553f0
SIP-CSeq: 1 SUBSCRIBE
Peer: lyncstd01.corp.domain.bm:62684

$$end_record

TL_INFO(TF_PROTOCOL) [0]09F8.0C64::10/12/2013-01:39:45.516.000125f5 (SIPStack,SIPAdminLog::ProtocolRecord::Flush:2436.idx(196))[1836810921] $$begin_record
Trace-Correlation-Id: 1836810921
Instance-Id: 2BDB
Direction: outgoing;source="local";destination="internal edge"
Peer: prplyncstd01.corp.domain.bm:62684
Message-Type: response
Start-Line: SIP/2.0 504 Server time-out
From: "CCS"<sip:ccs@domain.bm>;tag=7d7ab30b5f;epid=e69af42711
To: <sip:tluk@ccs.bm>;tag=205B29FB0474E9F50009EEADAE695524
Call-ID: 57e81be269b942b2a579617dc94553f0
CSeq: 1 SUBSCRIBE
Via: SIP/2.0/TLS 10.1.70.50:62684;branch=z9hG4bKF368244B.0850C8B18CE9E93B;branched=FALSE;ms-received-port=62684;ms-received-cid=44000
Via: SIP/2.0/TLS 10.1.70.50:62588;ms-received-port=62588;ms-received-cid=300
Content-Length: 0
ms-diagnostics: 1046;reason="Failed to connect to a federated peer server";fqdn="sip.ccs.bm";peer-type="FederatedPartner";winsock-code="10060";winsock-info="The peer did not respond to the connection attempt";source="sip.domain.bm"
$$end_record

TL_WARN(TF_DIAG) [0]09F8.0C64::10/12/2013-01:39:45.516.0001263f (SIPStack,SIPAdminLog::WriteDiagnosticEvent:1222.idx(781))[1836810921] $$begin_recordSeverity: warning
Text: Routing error occurred; check Result-Code field for more information
Result-Code: 0xc3e93c7f SIPPROXY_E_ROUTING_MSG_SEND_CLOSED
SIP-Start-Line: SUBSCRIBE sip:tluk@ccs.bm SIP/2.0
SIP-Call-ID: 57e81be269b942b2a579617dc94553f0
SIP-CSeq: 1 SUBSCRIBE
Peer: 69.17.205.55:5061

$$end_record

TL_ERROR(TF_DIAG) [0]09F8.0C64::10/12/2013-01:39:45.516.00012653 (SIPStack,SIPAdminLog::WriteDiagnosticEvent:1222.idx(784))[3012324582] $$begin_recordSeverity: error
Text: Message was not sent because the connection was closed
SIP-Start-Line: NOTIFY sip:tluk@ccs.bm;opaque=user:epid:6478nGN5flqtbdWmNWKPpQAA;gruu SIP/2.0
SIP-Call-ID: b67a5a8669c6498a8b9cff6f03b18d89
SIP-CSeq: 2 NOTIFY
Peer: 69.17.205.55:5061

$$end_record

TL_INFO(TF_DIAG) [0]09F8.0C64::10/12/2013-01:39:45.516.00012917 (SIPStack,SIPAdminLog::WriteDiagnosticEvent:1222.idx(778))[3012324582] $$begin_recordSeverity: information
Text: Routed a locally generated response
SIP-Start-Line: SIP/2.0 430 Flow Failed
SIP-Call-ID: b67a5a8669c6498a8b9cff6f03b18d89
SIP-CSeq: 2 NOTIFY
Peer: lyncstd01.corp.domain.bm:62684

$$end_record

TL_INFO(TF_PROTOCOL) [0]09F8.0C64::10/12/2013-01:39:45.516.0001296d (SIPStack,SIPAdminLog::ProtocolRecord::Flush:2436.idx(196))[3012324582] $$begin_recordTrace-Correlation-Id: 3012324582
Instance-Id: 2BDC
Direction: outgoing;source="local";destination="internal edge"
Peer: prplyncstd01.corp.domain.bm:62684
Message-Type: response
Start-Line: SIP/2.0 430 Flow Failed
From: <sip:ccs@domain.bm>;tag=23480080
To: <sip:tluk@ccs.bm>;tag=e3520bfb35;epid=25ff4d1f78
Call-ID: b67a5a8669c6498a8b9cff6f03b18d89
CSeq: 2 NOTIFY
Via: SIP/2.0/TLS 10.1.70.50:62684;branch=z9hG4bK1A7CF1F8.E103137E90058948;branched=FALSE;ms-received-port=62684;ms-received-cid=44000
Content-Length: 0
ms-diagnostics: 1046;reason="Failed to connect to a federated peer server";fqdn="sip.ccs.bm";peer-type="FederatedPartner";winsock-code="10060";winsock-info="The peer did not respond to the connection attempt";source="sip.domain.bm"
$$end_record

 

Solution

There wasn’t a whole lot I could find through searching the error messages so through logically thinking about it, what appeared to be the problem was that the company that could not send messages or see presence information was sending information out but wasn’t receiving any information back (hence the The peer did not respond to the connection attempt messages). Seeing how the other company that was able to send and see presence information was federated with other partners and was working properly, I figured it was probably because the other company probably had an outbound port blocked.  A quick telnet via port 443 from the Edge server of the company that wasn’t able to send messages or receive presence information revealed that this was indeed the case and 443 was blocked.  Once the Edge server was allowed TCP 443 outbound, the problem went away.