Month: January 2012

Some of my recent work

For the past two years, I have only been posting my work on Muziboo, Facebook and Soundcloud. Going forward, my blog and facebook will be the primary source for all my music. I have a number of original compositions on the way, but to get things started, I thought I would post some of my most recent work. Enjoy!

You are My King (Chris Tomlin)

Dirty Diana (Michael Jackson)

Sau Gram Zindagi (Guzaarish)

Forbidden Colors (ryuichi sakamoto)

Everything (Michael Buble)

Earth Song (Michael Jackson)

Rocketeer (Far East Movement)

Gaby Turns 1

As cliche’d as this sounds, its hard to imagine that its been a year since Gaby was born. Roshan and I feel so blessed and grateful to God for all the happiness that Gaby has brought to our lives. Every day is an adventure as she learns something new. Now she walks, says words like book, light, calls me Dada, calls Roshan, Mimi, screams in perfect pitch and louder than anyone else in church, her innocent smile is the highlight of our day. While I am on the train on my way back home, all I think about is how she’s going to greet me that night. She has totally changed our life and its been the most amazing year! A lot of you have been following Gaby’s growth and have been very supportive. Roshan and Iwant to thank you for the same. Below are pics from her Birthday Parties.

[nggallery id=11]


[nggallery id=12]

Exchange 2010 – TLS negotiation on Send Connectors

Over the past month of so, I’ve been troubleshooting an issue that I felt I should blog about. What we would notice was that when Exchange receives emails with attachments, it took an awfully long time to forward the email to the smart host. An email with a 1Mb attachment would typically take between 10-15 minutes to be delivered to the external recipient. The issue only occurred when send emails to external domains via the smart host. To make things worse, while the mail with the attachment was processed, all other emails would be queued up.



To figure out exactly where the slowness was occuring, I decided to try a different smart host. We noticed that mail delivery was working perfectly with the new smart host. So my initial theory was that this was a smart host specific issue. After opening a ticket with the vendor, they informed me that they believe its an Exchange issue (surprise surprise!).  They sent me debug logs which showed that Exchange would open up an SMTP connection and just keep it open for 10 minutes before actually send ing the data to the smart host. What puzzled me was why I was not seeing the same behavior with the other smart host. You would think that if it was an Exchange bottleneck, the behavior should not be any different irrespective of the smart host.

So I finally decided to do a packet capture on the Exchange Hub Transport server. To my surprise I noticed that all the SMTP traffic including the MIME traffic was fully encrypted. So I quickly checked the Send connector and Smart host authentication was completely turned off. This really confused me as there are no other obvious settings to turn off TLS authentication. I wanted to rule out the possibility that encryption is the cause for slowness. So I did some research and found this article:


For those who want a summary of the article, Exchange 2010 Hub Transport enables TLS encryption on the Send connectors by default and even if the setting is disabled in EMC, it is not truly disabled. To disable the setting, you need to use powershell and type the following commands:


Get-SendConnector | FL

This will list all the Send Connectors that are configured within the Exchange environment. The next step is to determine the send connector that is being used and look for the IgnoreStartTLS setting. If this setting is set to False (which is true by default), TLS encryption is enabled. This was true in our case. To disable TLS encryption for the send connector, issue the following command:

Set-SendConnector -Identity “Name of Send Connector” -IgnoreStartTLS: $TRUE

After issuing this command, restart the MS Exchange Transport Service. After I did this, mail flow was smooth and mails with very large attachments would take just a few seconds to forward to the smart host.

My conclusion was that there was some issue with TLS encryption between our smarthost and Exchange. We had TLS encryption enabled between Exchange and the second smart host as well and we did not face the same issues. So it seems isolated to the Sonicwall smart host in question.

All in all it was a good feeling to resolve the issue using packet captures. As they say, a packet capture never lies!