Wednesday, October 21, 2009

Microsoft Exchange couldn't find a certificate that contains the domain name mail.smtp25.org in the personal store on the local computer. Therefore, it is unable to support the STARTTLS SMTP verb for the connector HTS-IronPort with a FQDN parameter of mail.smtp25.gov. If the connector's FQDN is not specified, the computer's FQDN is used. Verify the connector configuration and the installed certificates to make sure that there is a certificate with a domain name for that FQDN. If this certificate exists, run Enable-ExchangeCertificate -Services SMTP to make sure that the Microsoft Exchange Transport service has access to the certificate key.

Solution

Open EMS

Get-ExchangeCertificate | FL

You will need to highlight the Thumbprint and paste into fallowing PS command

Below article is taken from MSExcahnge team site, if you have not seen it yet , here it is.

Exchange 2010 is Code Completeand on its way to General Availability

We are happy to announce that Exchange 2010 is Code Complete! Our senior leadership team has signed off on the final code, and it has been sent to our early adopters for one final look before its public release. This Release to Manufacturing (RTM) milestone means we are on our way to general availability and the launch at Tech·Ed Europe 2009 (http://www.microsoft.com/europe/teched/) in early November.

For those of you attending Tech·Ed in Berlin this year, be sure to check out the Unified Communications track, which is packed with technical content on Exchange 2010. And be sure to visit us at the Exchange product booth in the Exhibition Hall and let us know what you think of the product. Crystal Flores, who interviewed some of you on video at Tech·Ed North America earlier this year, will be on-hand in Berlin in a few weeks, armed with a camera and interview questions. A group of us are also marching to Las Vegas for Exchange Connections the same week where our fearless leader Rajesh is giving the keynote.

Monday, October 5, 2009

This was asked on the MS forums and I tried to pass on some of my positive experience and end up writing long answer and of course decided to post it here , hoping I could give some positive feed back to some of you out there wondering how exchange would be performing on VM environment.

Dave, I understand you have your own reasons to go for SCC and wondering if CAS , HTS roles would be a good idea placing on virtual environment and my previous implementation experience might be able to answer your questions, hopefully (-:

I had to go for SCC for my own reasons as well, not the limitations but SAN appliance was offering perfect DR solutions (NETAPP) Snapmanager and I was extremely comfortable going for SCC for so many reasons I will just mention couple of them, Netapp has never failed me over 10 years, in multiple very large implementations and Snapmanager offered perfect DR solutions ( it does log shipping and just like CCR) and replicate SAN data to San data.

So I ended up placing two Hub servers on VM, two CAS servers on VM, and two ISA servers, for redundancy, each server was placed on separate VM farm, so that if one VM farm goes down the mail infrastructure would work without any interruption. I used as mail gateways 2 Ironport on toe different data center and created two sent connectors one with high cost for redundancy. Both Ironport published outside to public DNS for redundancy .Although traditional DNS provides round robin response, in reality it is up to sender who to send the mail too and one thing I did not implement was road balancer in front of Ironport like F5 to be able to provide true redundancy (-: , ran out off $$$$

So VM servers has been working with no glitch over months, mail uptime is 99.9 , I have been extremely pleased with Exchange servers running on VMware ( HTS, CAS) no issues at all. Same goes for SCC , it has been running flawless fail over with 08 server is much better in my opinion, and maintenance is the most part I love about SCC.

This wasn’t the first time I placed Exchange servers on VM farm we have been doing this since Exchange 2003 (except mailbox server) we placed exchange 2003 servers in large environments 40.000 + mailboxes and they have been running with no issues over years (almost 6 years) ,

honestly I have not seen one single issue, but please remember all these implementation have been followed by MS best practices ( memory, HD, CPU etc.) except the VM part (-:

Good luck to you on your implementation

In addition Exchange 2010 is almost out, as I said so many times to me Exchange 2010 is the ***MOST ADVANCE*** version of messaging application ever, and due to critical changed have been done to the application itself , I strongly recommend everyone out there start planning to place Exchange 2010 in your business, it really wont be brainer to figured out business reasons and benefits running your messaging environment with next generation messaging application with incredible changes and stunning performance not to mention full redundancy out the box (-:

Many thanks to Exchange team for incredible hard work and providing us the best messaging application.

If you are trying to figure out how and why your account or someone in your organization here is one of the easiest way of doing this. This was the case for my manager his account suddenly would get locked out and he would need his account to be unlocked 4 or 5 times , a day and imagine he goes bananas (-:

I figured this is a very common scenario and wanted to share a secret here with you guys (-:, as always secret will be the Obvious (-:

Fist when AD account gets locked out, it happens on a particular domain controller, remember the DC is authentication server. As you would imagine related event logs gets recorded on the DC in this regard so your missing is, in which DC troubled account gets locked out? Imagine you have many DC’s (-:, no worries download account lockout

extract the files on your computer,

click on LockOutStatus.exe , insert user name you are investigation

Now you found out the DC’s the account is getting locked , all you need to do is to search specific event ID’s to find out who is the calling machine , click on eventcombMT.exe

Account Lockouts

Populates search criteria based on normal canned searches:

1. Gets All DCs

2. Selects all DCs for searching

3. Selects the Security Log

4. Selects Success and Failure Audits.

5. Sets the Specific IDs to 529, 539, 644,

The logs are being created in the “Temp directory” based on your search. Open the logs and locate the caller machine name

You do know what is causing the problem the calling machine is where the problem is being originated, in this example this is a workstation.

Now you narrowed the investigation and all you need to find out is, if there is a script running from this PC , could be using the user name and password for the users and causing lock outs, or same goes by for any application could be possibly doing same thing and causing the issue. I recommend using process explorer to try to indentify the source. What we will be end up doing in my case is to format the workstation because we are way to lazy (-: to go further troubleshooting!!!!