Disable StartTLS on EX2010 Send Connectors - Quick Fix

In your Exchange Hub Transport Server event viewer you may see a repeated TransportService Error 12014 on a regular basis.

This is typically because you do not have a certificate installed on the HT server with a FQDN that matches the FQDN entered into the send connector or the local computer FQDN if the send connector FQDN is empty.

When you check the properties of the Send Connector you see that TLS is NOT required but you still get the error.

This is because the receiving server has requested TLS so your exchange server tries to start TLS but this fails and the message is sent without TLS in the normal fashion. Everything works but you see the annoying errors!

Even when you have disabled TLS on a send connector this does not stop the receiving server from requesting TLS. If you examine the send connector using the EMS - get-sendconnector [connectorname] | fl you will probably see an entry called "IgnoreSTARTTLS" set to false.

This is the default and allows the Exchange server to provide TLS when requested. But if the following are true then the solution is simple:

• If you dont have a certificate installed and bound to the SMTP service
• If your certificate does not have the correct names
• You just dont want to provide or use TLS ever

Solution:

Use the Exchange Management Shell (EMS) and change the IgnoreSTARTTLS value to $true as shown below:

Open the EMS

1. get-SendConnector -identity [send connector name] | set-SendConnector -IgnoreSTARTTLS: $true
2. Restart the Microsoft Exchange Transport Service (restart-service msexchangetransport).

Important Note:

If you have configured your server to Require TLS this procedure will not work and you will need to sort your certificates out.

Server 2008 R2 Slow Shut Down

If you experience very slow shutdowns after deploying a 2008 R2 member server in to a 2003 domain you might want to check the Page file at Shutdown option. If the option is enabled it can take 25 minutes or so to shutdown the server.

In order to disable this setting follow the below steps:

Select Start > run and type secpol.msc
Select Local Policies > Security Options > Shutdown: clear virtual memory pagefile

You should then find that server shutsdown in normal time

Veeam 5 - File is larger than the maximum size supported by datastore

When Veeam is used to back up a virtual machine a snapshot is created while the backup takes place.


By default VMware snapshots are stored on the same datastore as the virtual machine configuration file (the .vmx file).


So, if the VM that you want to back up has additional VMDK files on other datastores and the additional VMDK file is larger than the block size of the datastore where the configuration file is stored you will not be able to back it up with Veeam and you will get this error.

File <unspecified filename> is larger than the maximum size supported by datastore <unspecified datastore>


The datastore where the snapshot will be created does not have a large enough block size to hold the snapshot of the large VMDK so the operation fails.


To work around this you have two options:

1. Storage VMotion the configuration file only to the datastore that holds the biggest VMDK for the machine in question.
2. Edit the VMX file and reboot the VM.

If you have a licence for storage VMotion then simply do that as its simple and does not require a reboot, remember to use the advanced options for SVMotion to just move the configuration file.

If you don't have a SVMotion licence you will have to power off the VM and perform an offline SVMotion of the configuration file only.

Alternatively you can download the .vmx file using the VI Client and edit the "workingDir" entry to reflect a datastore with a large enough block size to accommodate the snapshot.

This VMware article describes the process in more detail: 

Remember that the .VMX file is read by the VM on startup so you will have to reboot it for the changes to take place, but if you have to reboot it why not just offline SVMotion the configuration file - it's much easier this way!

Once this is all done Veeam should back up your large VM again.

Exchange 2010 MAPI not working - Only Outlook Anywhere works!

Recently I had an issue during an EX2003 - EX2010 migration where MAPI appeared not to work but Outlook Anywhere did!!

The symptoms were this:

An outlook profile would refuse to connect first time but upon a restart of Outlook you would get a standard username/password dialog box. Once the credentials were entered Outlook would connect and the user would be happy. A quick look at the connection status showed that Outlook was connected over HTTPS ie. Outlook Anywhere - But this had not been configured for the client so how was this happening?

One look at the Outlook profile showed that Outlook Anywhere was indeed enabled, indeed if you disabled this it would immediately re apply itself next time Outlook was launched.

All the ususal suspects were examined in turn as we thought it must be a GPO or dodgy Outlook .PRF file, the onsite guys even thought it was some new Exchange 2010 security feature that forces all connection to be made by HTTPS!!


The Exchange CAS array was behind a hardware load balancer so this was bypassed but the result was the same. So that ruled out the load balancer...So we thought :-)

Basically I had made a schoolboy error and had neglected to add the RPC Endpoint Mapper (TCP:135) to the Exchange Virtual IP. The result was that Exchange treated all client connections as remote and using a bit of autodiscover wizardry it established a HTTPS connection and modified the Outlook profile to reflect a HTTPS connection.

Closer examination of the load balancer showed the error and once RPC traffic was added to the load balancer front end everything started working properly.

But why did it still fail when I bypassed the loadbalancer? Simple - I had a peaky hosts file directing the CAS array name to the load balancer so changing the CAS array 'A' record had no effect!

Moral of the story is to check the simple things first I guess!

You must close all dialog boxes before you can close Exchange Management Console

I thought it was just me but a bit of research shows that loads of people are getting the annoying error above when they try to close the Exchange 2010 EMC.

There is a massive thread here: http://social.technet.microsoft.com/Forums/en-US/exchangesvradmin/thread/ea4e1ffe-472e-4508-9a14-0735ac6322ca/ but to save you the trouble of reading it in full there is a simple fix...

Uninstall Internet Explorer 9 and the EMC will work correctly again.

Then I suggest keeping an eye on IE9 hotfixes to see when the bug is fixed.

Install Exchange 2010 without 64bit DCs

No 64bit Domain Controllers in Forest Root Domain


Recently a customer wanted Exchange 2010 installed into a multi domain environment where the forest root domain had no 64 bit servers. As the Exchange 2010 setup program will only run on a 64 bit machine you will need either a 64bit DC or 64bit member server in the forest root domain to run the necessary preparation routines.


This can easily be addressed but it requires some thought beforehand - ie, don't get caught out by bad planning and have to rush the procedure through change control!


Basically the machine that you use to prepare the Active Directory must be in the same domain and site as the schema master and if it is not a domain controller it will need the RSAT (Remote Server Admin Tools) installed.


According to Technet topic article - 

Forest/Domain Preparation - With Exchange Server 2010, you will need to leverage a 64-bit operating system to perform the schema extension and forest/domain preparation work. Hopefully you have 64-bit Active Directory servers deployed (or are planning to deploy them) and this won't be an issue. In the event that you do not have 64-bit Active Directory servers, you can install a 64-bit member server (physical or virtual) into the forest root domain, place it in the schema master's AD site, and apply the schema and forest preparations; for domain preparation, you can either update all domains by leveraging the /preparealldomains setup switch, or by removing/joining the 64-bit member server to each domain in the forest that you need to update.

When Exchange 2010 is installed into an organisation with more than one domain the setup process needs to make certain changes to the directory schema and AD structure. This process is normally handled seamlessly by the Exchange setup program and if you have only one domain then regardless of the DCs in use the Exchange 2010 server must be a 64 bit machine so assuming it is in the same AD site as the schema master your setup will proceed directly from the new exchange server itself.


If your forest root domain does not have any suitable 64bit DCs I have found the easiest thing to do is to move a potential exchange 2010 server into the Forest Root domain (ensuring it is in the same site as the schema master), run the exchange setup program as follows:

1. Move suitable server into Root Domain
2. Open Powershell as Administrator
3. Import-Module ServerManager - to allow you to add windows features
4. Add-WindowsFeature RSAT (& restart) If you don't do this setup will fail

Once you have got the server ready we need to use an elevated command prompt and use the Exchange 2010 CLI setup program to prepare the Schema, Exchange2010 permissions and AD itself. See http://technet.microsoft.com/en-us/library/bb125224.aspx for the full explanation.

So, from the command line we need to run the following commands:

setup /prepareAD This command prepare AD as a whole (sub features like legacy permissions are automatically prepared)

setup /pad This will prepare ALL domains in the forest

Once you have taken these steps you should check to ensure that the relevant security groups etc have been created in both the top level and child domains. Assuming they have you can proceed to move the 64 bit server back out of the root domain and continue to install exchange 2010 into the organisation.