Microsoft has recently released Exchange 2013 RTM Cumulative Update 3 or CU3 and an updated UM Language Pack, the last Cumulative Update before Exchange 2013 Service Pack 1.
Several new features have been added to the product: Continue reading Upgrade to Exchange Server 2013 RTM CU3
If you have a DAG with multiple Mailbox servers and a lot of Mailbox databases it’s a good practice to regularly have a look at the distribution of the Mailbox database.
When you reboot a Mailbox server for example all active copies of Mailbox databases are moved to other Mailbox server but they are never moved back to their original location.
Customer is running a web application and this web application is able to send SMTP messages, for example after a new user registration or a ‘forgot my password’ option that sends out a link for resetting a password.
This application is not always able to send out messages, when it’s not able to the following error is logged on the web server:
Service not available, closing transmission channel. The server response was: 4.3.2 The maximum number of concurrent connections has exceeded a limit, closing transmission channel.
Continue reading Maximum number of concurrent connections has exceeded a limit
This issue was brought to my attention by Veeam, VMware recently issues a support KB article about possible data corruption when sending large amounts of data of a virtual NIC. Any data send across the network can get corrupted, including file copies, database actions etc. Naturally this can also impact Exchange server operations.
This occurs only with Windows Server 2012 running inside the VM and when the VM is using the default E1000E virtual network adapter.
Two workarounds are available:
· Disable TCP Offloading in Windows Server 2012, but this may increase CPU utilization.
· Replace the E1000E NIC with an E1000 NIC or a VMXNET3 NIC. This is probably the best solution but it is labor intensive as it means reconfiguration of all your Virtual Machines. PowerCLI may be your friend in this case.
The root cause is currently under investigation. For more information (and updated information over time) please check the VMware support KB article.
In my lab environment I noticed that my Lync (2010) client does not show the availability for all contacts. In this screenshot I can see the status of my personal Lync account (running on my laptop) and the status of my wife’s account (running on a Polycom CX600). My work account however keeps whining about “Presence unknown”.
Federation traffic goes through the Lync Edge servers. When looking at the eventlog of the Lync Edge servers in my test environment (Lync 2013 with Lync Hosting Pack v2 – running on Windows Server 2008 R2) I can see the following entry:
Log Name: Lync Server
Source: LS Protocol Stack
Date: 3-9-2013 9:10:55
Event ID: 14428
Task Category: (1001)
Level: Error
Keywords: Classic
User: N/A
Computer: LYNC-EXT01.contoso.com
Description:
TLS outgoing connection failures.
Over the past 21 minutes, Lync Server has experienced TLS outgoing connection failures 3 time(s). The error code of the last failure is 0x80090325 (The certificate chain was issued by an authority that is not trusted.) while trying to connect to the server "sip.amsio.com" at address [109.109.115.147:5061], and the display name in the peer certificate is "Unavailable".
Cause: Most often a problem with the peer certificate or perhaps the host name (DNS) record used to reach the peer server. Target principal name is incorrect means that the peer certificate does not contain the name that the local server used to connect. Certificate root not trusted error means that the peer certificate was issued by a remote CA that is not trusted by the local machine.
Resolution:
Check that the address and port matches the FQDN used to connect, and that the peer certificate contains this FQDN somewhere in its subject or SAN fields. If the FQDN refers to a DNS load balanced pool then check that all addresses returned by DNS refer to a server in the same pool. For untrusted root errors, ensure that the remote CA certificate chain is installed locally. If you have already installed the remote CA certificate chain, then try rebooting the local machine.
Note. These error messages are logged on both Lync 2013 Edge servers.
The most important part of the entry is the “The certificate chain was issued by an authority that is not trusted” message. The Lync 2013 Edge servers at my office use Comodo certificates, and the Comodo Trusted Root certificate and Intermediate certificate are not installed in the Certificate store of the local Windows Server in my test environment where the Lync 2013 Edge servers are installed.
The solution is to manually add the Comodo Root and Intermediate certificate on the Lync Edge server. The Lync Edge server of the federated partner will now be trusted (since the chain is complete and correct) and federation will work.
Why are the other federated accounts working? In my personal Lync environment I’m using Digicert certificates, and the Root and Intermediate certificates are installed by default on the Windows server. The SSL chain is correct and therefore federation works fine.
The Comodo Root and Intermediate certificates can be downloaded from the Comodo Support pages.
Jaap Wesselius 
You must be logged in to post a comment.