Exchange 2003

This is the 3rd blog in the Exchange 2013 ABC serie. In this blog we will look at the Client Access Server component. Let’s first have a look at a little history of client access in the previous versions.


In Exchange 2003 clients could connect via two ways:

  • Directly to the Back-end server
  • Via a Front-end server which proxied the connection to the correct Back-end server

Starting from Exchange 2007 Microsoft decided to create a separate server role which was used to handle the client access called the Client Access Server (CAS). This server could be either installed:

  • As a separate server
  • On the same server as the Hub Transport Server
  • On the same server as the Hub Transport and Mailbox Server aka multirole server (only allowed if clustering for the Mailbox Server was not used)

In Exchange 2010 Microsoft did continue to separate the roles but there was a big change in the support colocation of server roles on one server. Compared to Exchange 2007 it was now supported to collocate the CAS, Hub Transport and Mailbox Server role even if the Mailbox Server would be a part of a Database Availability Group (DAG). So this created the following options:

  • As a separate server
  • On the same server as the Hub Transport Server
  • On the same server as the Hub Transport and Mailbox Server aka multirole server

Exchange 2013

So now we had a brief look at the past let’s have a look at how Microsoft did arrange it starting from Exchange 2013. Well it looks like they have updated the Client Access part so it matches the architecture as it was in Exchange 2003.

The Client Access part of Exchange 2013 consist of two pieces:

  • CAS role
  • Mailbox Server role

Let’s explain it in more detail. The CAS role from Exchange 2013 contains three components:

  • Client access
  • SMTP
  • UM Routing

So what happens when a request from a client arrives? The Client Access component authenticates the session and then proxies the connection to the Mailbox Server which hosts the active copy of the Mailbox Database containing the mailbox of the user. Clients will never make a direct connection to the components hosted on the Mailbox Server role. All connections are made via the Client access component on the CAS role.

This is just one change in Exchange 2013. The most important change in Exchange 2013 is that clients won’t use RPC over TCP anymore but are using RPC over HTTP. This change has several benefits among them:

  • Clients only use HTTPS to connect so no large port range has to be opened on the firewall
  • HTTPS is more suitable if connecting over a network connection which has a high latency

So let’s discuss the points mentioned above. In some cases a firewall is placed between the clients and the servers. Although you could limit the RPC usage for as described in this article. This still required multiple ports to be opened. Now Microsoft has decided to move to RPC over HTTP only port 443 is being used to access the resources of Exchange. A configuration change has to be made to make thsi possible. By default the OAB is available at port 80 so you will need to change this so it can also be accessed via 443.

That brings us to the second point which would normally not occur on LANs: latency. This has a high impact on RPC over TCP but RPC over HTTPS can handle this issues better although it’s still something you would like to be kept at a minimum in your LAN environment.

Another change in Exchange 2013 is the namespaces required for your environment. In a typical site resilient Exchange 2010 environment you could end up with 8 names which are required for your environment. Two of them where the names for the CAS Array. These names were set as RPC Client Access Server on the databases and would appear in the Outlook profile of the user:

Now in Exchange 2013 we don’t need to set the RPC Client Access Server parameter anymore. Instead of the CAS Array name we will connect to something like this: MailboxGUI@corp.local.

So what’s the advantage of this? Well maybe you remember the pop up that users received this pop up:

Well that’s history starting from Exchange 2013. This since the server value does not change anymore. So if an administrator decides to move a mailbox the user won’t be prompted to restart Outlook anymore.

Load Balancing

And what about load balancing has this changed? Yes this has changed. In Exchange you would need to setup session affinity and use layer 7 load balancing for some of the protocols. In Exchange 2013 you don’t have to do anything with layer 7 just use layer 4 functionality of the load balancer. Besides this session affinity is not required anymore. This because it will have no effect if the session is arriving via another CAS this since rendering of for example OWA happens on the Mailbox Server. So if a session is lost and is reconnected via another CAS it will still arrive at the same Mailbox Server which performed the rendering.

But what about the authentication? After the user has logged in an authentication cookie is provided which is encrypted with the CAS’s SSL certificate. When the client is connected via another CAS the authentication cookie is decrypted. For this proces to work it is imported that all CAS will share the same certificate.

Here ends the third blog in the Exchange 2013 ABC series. In this blog we discussed the changes in the Client Access Server component. In the next blog we will have a look at Database Availability Groups in Exchange 2013. Below are some interesting links about the Client Access Server of Exchange.

Useful links:

Robert’s Rules of Exchange: Multi-Role Servers:

Exchange 2013 Client Access Server:

Last Saturday we recorded the 8th episode of TheUCArchitects and one of the subjects was the announcement made by Microsoft about TMG and ForeFront Protection for Exchange.

Since it was a really nice discussion about the consequences for both the reverse proxy part as the A/V part I decided to write a blog about it. In this blog we will only concentrate on the A/V part because that’s the subject where not a lot of people have discussed about.

So let’s start with a short description of ForeFront Protection for Exchange. It can be used to scan both the message traffic as in store scanning. It can be configured to use several A/V engines to scan a message. This has the advantage that if one of the A/V engines doesn’t contain the pattern it will be picked out by an engine which does contain the pattern. The downside of this is that is can cost a lot of resources so during the sizing process don’t forgot to take them into account.

Besides the on-premises product Microsoft does also have a Cloud solution called ForeFront Online Protection for Exchange (FOPE). This product will only scan messages which are sent to or from your mailserver.

Last week Microsoft did announce to stop several ForeFront products among them ForeFront Protection for Exchange.

Probably Microsoft wants to push customers to FOPE but does FOPE really covers all features ForeFront Protection for Exchange contained? Well the answer is quite easy. No it will not cover everything.

Let’s start with the scanning of the scanning of the mailboxes also known as instore scanning. This feature has the advantage that you can perform real-time, scheduled or a manual A/V scan on the store scanning. This may be necessary if an outbreak has occurred or just as additional maintenance once a month.

The second feature is scanning the message content between internal clients. Since this won’t be send via the cloud threats can only be detected by an A/V solution on your Hub server which will add a transport agent to perform message scanning. Of course all your company clients will contain a local A/V client so it might be found by this one.

If you had time to look at the Tech Preview of Exchange 2013 you might have seen that it contains an antispam and antimalware feature by default. Especially the antimalware feature might be interesting for some organizations. This feature will add some basic antimalware protection to protect your environment from receiving malware. Because the product is not RTM this may change when it hits the RTM status.

The antimalware feature is enabled by default and can be combined with using message filtering in the cloud. By default messages scanned by the hosted email filtering service will not be scanned again when they arrive on your on-premises servers. However this configuration can be changed so it both scans messages using the hosted email filtering service and the antimalware feature from Exchange 2013. As far as I have discovered it only contains one AV-engine so the other engines which were available in ForeFront Protection for Exchange are not available anymore.

Also instore scanning will not be provided by the feature only messages which will be send/received by your transport servers. The actions that can be configured for the feature are:

  • Block entire message
  • Delete attachments and use either the default or customer alert

As you can see no quarantining option is available it’s either delete the complete message or only delete the attachments.

For those companies who will require stuff like quarantining, multi av-engines, instore scanning, etc. the only option left is to select a 3rd party product. At this moment I haven’t seen any vendors that already published a beta of their product with Exchange 2013 Tech Preview. But I think this will be a matter of time before vendors will announce their products to support the new Exchange.

What the future will bring? That’s just a matter of time, let’s wait till Exchange 2013 hits RTM and see if anything has changed in the antimalware feature.

 [JV1]Officiele statement nog opzoeken

Can’t remove the Exchange Virtual Server

During the removal of an Exchange 2003 cluster I had the issue that I couldn’t remove the Exchange Virtual Server from the Cluster Administrator.

In the event log nothing special was logged so it was time to dig into the log files which are created during this process. Since the removal of Exchange Virtual Server is a cluster related task the cluster log file was needed. This is located in the c:\windows\cluster directory.

When having a look at the log you will see that several settings are checked before the Exchange Virtual Server is removed.

[11:21:42] Leaving ScTestAceOnObject
[11:21:42] ANONYMOUS LOGON does have READ permissions for MDB objects on the organization
[11:21:42] Checking to see whether the Exchange Domain Servers group has been DENIED Receive-As permissions on the Servers container(s)
[11:21:42] Checking the ACL on the Servers container in the admin group “First Administrative Group”
[11:21:42] Entering ScTestAceOnObject
[11:21:42] Attempting to get DOB for DN “/dc=LOCAL/dc=Corp/cn=Configuration/cn=Services/cn=Microsoft Exchange/cn=Corp/cn=Administrative Groups/cn=First Administrative Group/cn=Servers”
[11:21:42] Attempting to read security descriptor from DOB
[11:21:42] Attempting to initialize CAce object
[11:21:42] Testing to see if given ACE is present
[11:21:42] Test succeeded; fACLPresent = TRUE, fExtraRights = FALSE
[11:21:42] The ACE tested for is present in the ACL of this object
[11:21:42] Leaving ScTestAceOnObject
[11:21:42] The Exchange Domain Servers group has been DENIED Receive-As permissions on the Servers container(s)
[11:21:42] The required permissions have already been set
[11:21:42] Leaving ScDetermineIfLocalDomainServerGroupHasAlreadyBeenACLedOnExchangeCT
[11:21:42] Entering ScFindRoutingGroupThatContainsServer
[11:21:42] Leaving ScFindRoutingGroupThatContainsServer
[11:21:42] ScPRQ_ServerIsNotHomeServerForPostmasterOfNonEmptyOrg (f:\tisp2\admin\src\udog\excommon\prereq.cxx:2981)
Error code 0X80072030 (8240): There is no such object on the server.
[11:21:42] CCompServer::ScCheckEVSPrerequisites (f:\tisp2\admin\src\udog\exsetdata\components\server\compserver.cxx:1405)
Error code 0X80072030 (8240): There is no such object on the server.
[11:21:42] ScSetupExchangeVirtualServer (f:\tisp2\admin\src\udog\exsetdata\exsetds.cxx:1541)
Error code 0XC103FC97 (64663): Setup encountered an error while checking prerequisites for the component “Microsoft Exchange Server”: 0X80072030 (8240): There is no such object on the server.
[11:21:42] Leaving ScSetupExchangeVirtualServer

For example several ACL’s are verified. Besides the ACL checks the removal process will verify if the postmaster mailbox is homed on this server. By default the account used for installing Exchange 2003 will automatically be the postmaster. If the mailbox can’t be found, because it’s deleted, the process will be aborted.

But how can you solve it? Well first and easiest method maybe to restore the account and mailbox from the backup. If this is not possible you might decide to re-assign the postmaster mailbox to another account.

To re-assign the mailbox to another account you must use ADSIEDIT. Before making any changes with ADSIEDIT make sure you have a correct and recent back-up of your Active Directory.

Once you have confirmed this it’s time to make the change. Open the Configuration partition of Active Directory and expand the following nodes:

  • CN=Services
  • CN=Microsoft Exchange
  • CN=Organization Name, for example Corp

Get the properties of CN=Global Settings and search for the attribute called MsExchAdminMailbox. You will see the value of this attribute has been a deleted object:

In this case the attribute has the value CN=Exchadmin\0ADEL:bbf20ca9-7def-4e0f-bdd9-f9107c1643d6,CN=Deleted Objects,DC=Corp,DC=local. The DEL means the object doesn´t exist anymore. To solve this issue replace the value with a value of an existing user, for example CN=Postmaster,DN=ServiceAccounts,DC=Corp,DC=local.

 After AD replication has occurred you should be able to remove the Exchange Virtual Server using the Cluster Administrator tool.

During the removal of an Exchange 2003 cluster I found an issue after the removal of Trend Micro Scanmail (SMEX) 8.0. After the deinstallation was completed the Cluster Administrator started with an error. Once of the things I expected to cause the issue was the resource object from SMEX which was still there. This could be solved easily by removing the default procedure for removing cluster resources.

Despite removing the resource the Cluster Administrator kept prompting with and error. After some research I discovered that the issue was caused by a resource type clusRDLL which was still their.

To cleanup this resource type you will need to use the cluster command:

cluster restype clusRDLL /delete /type

After this command was executed the error did dissapear and I could remove the Exchange 2003 Virtual Server.

Trend Micro has published a knowledge article about this issue:

Uninstalling Scanmail for Exchange (SMEX) 8.0 from cluster servers open

During a cross-forest test migration from Exchange 2003 to Exchange 2010 I got the following error:

Warning: Unable to update AD information for the source mailbox at the end of the move.  Error details: An error occurred while updating a user object after the move operation. –> Failed to find the address type object in Active Directory for address type “SMTP:AMD64″.
Failed to cleanup the source mailbox after the move.
Error details: MapiExceptionNotFound: Unable to delete mailbox. (hr=0x8004010f, ec=-2147221233)

When I looked in the old and new environment I found out that the mailbox both existed in the old and new environment. In this  case you might have a big issue even when the mail is delivered in the Exchange 2003 environment  and the homeMDB attribute is not updated. Updating the attribute may take a while due to AD replication, in this case mail is not delivered in the new mailbox and so mails will not be placed in the new mailbox.

To prevent this issue Microsoft has released a hotfix for Exchange 2003 which can be found on the website below.


Problems removing Exchange 2003 cluster

During one of my forum visits I found a really interesting issue. Someone tried to remove his old Exchange 2003 cluster but received the following error when trying to dit it:

Found no Disk resource for the disk that contains the folder ‘W:\EXCHSRVR’

When looking in the Cluster Administrator the resource was not visible, very strange. So we needed to remove the pointer to the w:\ disk by using ADSIEDIT.

Before performing such an action you will first need to create a backup of your AD.

Next execute the following steps:

– open adsiedit
– choose connect to
– change the domain to configuration
– expand CN=Configuration …
– expand CN=services
– expand CN=Microsoft Exchange
– expand CN=First organization (or your organization if different)
– expand CN=servers
– expand CN=servername
- expand CN=Information Store

There you will find the First Storage group and other storage group. Get the properties of them both the storage group and the databases in it it and check if none of them points to the w:\disk
But in this case it was something else where we need to have a look at, perform the same steps as above but stop after expand CN=servers and continue with the steps below:

– get the properties of theservername
- search for the value MsExchDataPath
– check if the pointer is not listed

After this try to remove the Exchange cluster again.

Exchange 2003 keeps resending the same mail

Today I had a nice issue with Exchange. For some kind of strange reason Exchange 2003 kept sending the same mails.  Even when deleting the mails from the queue in the Exchange System Manager. A result of this was that the bandwidth was almost used 100% so I adjusted the simultaneous connections etc, without any effect.

So I decided to search for a solution for this issue. I found a post on expert-exchange which described almost the same issue. It adviced to use MFCMAPI to cleanup the temp table. The specific messages may get stuck in that table

After applying the solution the issue was solved indeed, below you will find the steps to solve the issue:

  • download and install MFCMAPI
  • choose session and select logon and display store tables
  • if there are multiple profiles found you will be asked to select a profile, in this case select the administrator profile
  • an overview of the mailbox and public folders will be displayed. Select MDB  and choose the option get mailbox table
  • an overview of all mailboxes found in the store will be displayed. Search for the mailbox of SMTP
  • search in the left pane for Temp Tables
  • delete all sub folders below the Temp Tables, when asked if the messages need to be hard deleted choose to do this
  • restart the SMTP service