A little while ago I posted a “Quick Tip - Exchange 2007 Upgrading the Default Email address policy…” which is located here: http://telnetport25.wordpress.com/2008/03/30/quick-tip-upgrading-the-default-email-address-policy/.

I had not thought much about it since until I received a rather nice comment from a chap called Jamie which read as follows;

Hey Andy,

Great post - you have hit the nail on the head with the problem I am currently faced with after upgrading to Exchange 2007 from Exchange 2000.

My problem though is this - we have already removed Exchange 2000 from the domain (uninstalled it, yada yada yada) and now I do not have the option of removing the mailbox manager policy using the older version of exchange manager.

what to do?

Many thanks.

Admittedly I had not considered this as a possibility, and I thank Jamie for passing comment as we have come up with a solution should you also find yourself in this situation which is as follows;

Removing the Mailbox Manager Policy after Exchange 2003 has been Removed:

On a Windows XP workstation which is a member of the same domain as your Exchange 2007 Organisation log onto the workstation with a domain account that has local admin and Exchange FULL Administrator rights (this will enable you to install the required tools and access Exchange) then install the ADMINPAK.msi (http://www.microsoft.com/downloads/details.aspx?familyid=e487f885-f0c7-436a-a392-25793a25bad7&displaylang=en) which will give you access to the Windows 2003 admin tools (ADUC) - these are a prerequisite of the Exchange 2003 System Manager which is required next to solve this particular problem.

When the ADMINPAK has been installed on the workstation, install the Exchange 2003 Exchange System Manger - and apply any Exchange Service packs that were equivalent to the level of you previous Exchange 2003 servers (you might be able to get away with this step - but from a best practice point of view it is safer to do).

When the ESM has been installed open it via [ START -> PROGRAMS -> Microsoft Exchange -> Exchange System Manager ] and then navigate to [ Recipients -> Recipient Policies ] - see below;

and then from the Right hand Window select the recipient policies that have the Mailbox Manager settings configured. As with the previous article - disable all settings and then apply - you should now be able to upgrade your policies from within Exchange 2007.

So, there I was busily working on some of the final configuration elements of my CAS setup when I receive a Helpdesk (or ticket) from a customer suggesting that they can no longer change their password via OWA 2003 Interface.

Although considering the time scales that I have been working to - this perhaps might have been a minor problem (as our SLA does not cover Password changes via the OWA Interface) but this bugged me a little bit so I decided to have a look.

Essentially as we are mid migration I have a number of customers who’s mailboxes still reside on Exchange 2003, however, I have already removed my existing Exchange 2003 FES (Front End Servers) and replaced them with Windows 2008, Exchange 2007 SP1 Client Access Servers.

When one of my Exchange 2003 based people logon to OWA and try to change their password  via [OPTIONS] - see below;

Then from the OWA options screen which appears in the right hand window select [Change Password] - see below;

They are presented with the following error (where the usual change password box would appear):

As you can see from the above - the error that is produced is from the IIS 7 web service running on my Windows 2008 CAS server, and it also suggest that the files or indeed the directory that contains the file to perform the password reset are not present.

This was indeed a bit of a “slap head” moment (whilst screaming “DOH!!!!“) as although my previous Windows 2003 based FES had the IISADMPWD directory enabled my CAS servers which are running on Windows 2008  do not.

“Never Fear” I thought, I’ll just have a quick look around the web and find out how to enable to IISADMPWD feature in IIS 7 - I found nothing, nada, zip, bupkiss - bugger.

I sat there for a little bit scratched my head then thought “What if I copy over the IISADMPWD file from the old FES to the IIS CAS” - this seemed like a crazy but logical idea so:

Before I began I ran the serverManagerCMD -q command on my Windows 2008, Exchange 2007 CAS to review the IIS components that were installed (in view that this actually worked I the following are the installed components within my installation):

[X] Web Server (IIS)  [Web-Server]
    [X] Web Server  [Web-WebServer]
        [X] Common HTTP Features  [Web-Common-Http]
            [X] Static Content  [Web-Static-Content]
            [X] Default Document  [Web-Default-Doc]
            [X] Directory Browsing  [Web-Dir-Browsing]
            [X] HTTP Errors  [Web-Http-Errors]
            [X] HTTP Redirection  [Web-Http-Redirect]
        [X] Application Development  [Web-App-Dev]
            [X] ASP.NET  [Web-Asp-Net]
            [X] .NET Extensibility  [Web-Net-Ext]
            [X] ASP  [Web-ASP]
            [ ] CGI  [Web-CGI]
            [X] ISAPI Extensions  [Web-ISAPI-Ext]
            [X] ISAPI Filters  [Web-ISAPI-Filter]
            [ ] Server Side Includes  [Web-Includes]
        [X] Health and Diagnostics  [Web-Health]
            [X] HTTP Logging  [Web-Http-Logging]
            [X] Logging Tools  [Web-Log-Libraries]
            [X] Request Monitor  [Web-Request-Monitor]
            [X] Tracing  [Web-Http-Tracing]

[X] Security  [Web-Security]
            [X] Basic Authentication  [Web-Basic-Auth]
            [X] Windows Authentication  [Web-Windows-Auth]
            [X] Digest Authentication  [Web-Digest-Auth]
            [X] Client Certificate Mapping Authentication  [Web-Client-Auth]

[X] Management Tools  [Web-Mgmt-Tools]
        [X] IIS Management Console  [Web-Mgmt-Console]
        [X] IIS 6 Management Compatibility  [Web-Mgmt-Compat]
            [X] IIS 6 Metabase Compatibility  [Web-Metabase]
            [X] IIS 6 Management Console  [Web-Lgcy-Mgmt-Console]

I decided that the installed components above should be enough to support the functionality of the original change password components so on my Windows 2008 Exchange 2007 CAS server I navigated to [c:\windows\system32\inetsrv] and created a directory called “IISADMPWD” - see below;

From my old Exchange 2003 Front End Server (FES) I copied the contents (all the ASP files) of the [ C:\Windows\System32\Inetsrv\ ] directory to the new directory on my Windows 2008 CAS (see above for the directory) - see below for the contents as it should look on your Windows 2008 CAS;

I then jumped into the IIS 7 Administration tool on my Windows 2008 CAS [ START-> Programs -> Administrative Tools -> Internet Information Services (IIS) Manager ] and expanded [ <Server Name> -> Sites ] here I right clicked with my mouse on the Default Web Site and then from the context menu that appeared I choose the “Add Virtual Directory Option” - see below;

Within the dialog box that opened I provided the following information (if you are following this you ensure your settings correspond to the following - when done click on the “OK” button;

After clicking on the “OK” button I was returned to the IIS 7 main interface - where I could now see my new IISADMPWD virtual directory - I right clicked on the new virtual directory entry and from the context menu that appear I chose “Convert to Application” option - see below;

From the dialog box that appeared I chose the “Select Button” located next to the “Application Pool” data section - see below;

From the dialog that appeared from the drop down menu entitled “Application Pool” I choose the “MSExchangeOWAAppPool” option and then clicked on the “OK” button and then “OK” again which returned me to the main IIS 7 admin screen - see below;

From the right hand tree node in the IIS manager I selected my new “IISADMPWD” application directory which changed the main window to display the configurable options - under the IIS section I double clicked on the “Authentication” option - see below;

This changed the main window to look like the following example - here I ensured that the only form of Authentication selected was “BASIC” - see below;

From here I ensured that all settings had been applied - I then reset the IIS services [ Start -> RUN - > IISRESET /noforce ] and then retried accessing the change password feature via the OWA 2003 mailbox via my CAS server which worked - see below;

I ran through the change password process which worked perfectly - cool.

I hope this helps someone along the way.

A number of companies have, or are in the process of the move from Exchange 200x to Exchange 2007 (like me) which can and often does present a number of challenges. There is a huge amount of information on the web which deals with the technical challenges of such a migration – however one key issue that I have noticed where I work is how can you provide support your Exchange admin team during the transition phase from Exchange 2000 or 2003 to Exchange 2007.

For example;

I work as part of a 11 person team – within the team I take the lead on all of the advanced Exchange and Active Directory related activities (such as migration and complex problems as they arise) – however day to day there are 4 others whom run the Exchange systems (essentially keeping the systems fed and watered).

As many of you will well know, when you are migrating to Exchange 2007 from and existing environment you enter into what is called “Interoperability” or “Co-existence” mode – which presents a number of changes to the Exchange 2003 system manager and indeed the overall management of the Organisation that others in your team might not be prepared for.

In a perfect world (and indeed some businesses do this as a matter of course) you would send every potential Exchange admin out on the various Exchange 2007 training courses to ensure that they are appropriately “clued up” on the process of migration prior to beginning the implementation.

However where I work this is not possible (due to budgetary reasons), therefore you end up in a situation where some people have a greater understanding of Exchange and indeed the migration processes than others – but we try to adopt an approach of train the trainer.

During a migration from Exchange 200x to Exchange 2007, during the intermediary stages there are a number of management tasks that either change in function, are removed or are placed in a different location – in this article I would like to take you through some of the management tasks that are affected whilst we were operating in Co-existence mode.

Some Common Questions:

Question: Can you create / Move a mailbox for or to Exchange 2007 using ADUC on an Exchange 2003 Server?

Answer:

Yes you can - however I would not recommend it for the following reason;

When using Active Directory Users and Computers you account and indeed the mailbox will be created with no issues (you will be able to use Outlook and send and receive mail)- however, after you have created the account you logon to on of your Exchange 2007 servers and open up the Exchange Management Shell and type in the following command:

Get-Mailbox <your ADUC created user> | fl ExchangeVersion and you will get the output below;

You should note the version 0.0 (6.5.xxxx.x) - this indicates that the account was created using a version of Exchange prior to 2007 - this can cause problems if your user wishes to logon to OWA 2007.

In order to fix this issue you will need to run the following command;

Set-Mailbox <your ADUC created user> -applyMandatoryProperties - see below;

By running the applyMandatoryProperties command you can upgrade your mailbox to the correct version and avoid any issues with OWA 2007 - however if you are creating new users you might as well use the Exchange Management Console / Shell to negate this additional step.

Question: Can you DELETE an Exchange 2007 Mailbox using ADUC on an Exchange 2003 Server?

Answer: Yes - I have not seen any problems with this - but bear in mind that Microsoft DO NOT recommend that you do this.

Question Can you DELETE an Exchange 2003 mailbox from the Management Console or Management Shell in Exchange 2007?

Answer: Yes you can, although I have noted that you might receive a warning similar to the following:

It appears that you can safely ignore this message, as upon investigation in my environment the mailbox in the source Exchange 2003 store did tombstone correctly after the maintenance interval.

Question: Can you perform a message track for  Mailboxes which are residing on an Exchange 2007 Server from the 2003 ESM?

Answer: No, you cannot Message Track Exchange 2007 messages from Exchange 2003 which purely experienced transport within the 2007 environment - you can use the ESM to track messages that originated from within Exchange 2003 - but you will not be able to see transport from the Exchange 2007 HT onwards.

Question: Can you perform a message track for Mailboxes which are residing on an Exchange 2003 Server from the 2007 Management Console or Exchange Management Shell?

Answer: No,When in Interop mode, if the bridgehead server for the 2007 routing to the Internet lies within the Exchange 2003 environment - or indeed attempting to track messages beyond the bridgehead to 2003 based mailboxes you cannot use the 2007 tracking tools. You would need to pick up the message tracking from within the 2003 environment.

Question: Can I use ADUC, the Exchange 2007 Management Console and Shell to edit the properties of users (such as Department, Phone etc).

Answer: Yes

Question: Can I use the Exchange 2003 ESM to review the Item Count, and Last Logged on / Off values of a 2007 Mailbox?

Answer: Yes

Question: Can I use the Exchange 2007 Management Console or Shell to review the Item Count, and logon information of a 2003 mailbox?

Answer: No

The above list is not exhaustive list and deals with some of the more common basic administration tasks - I am sure that there are many more questions (so I you have any more that you would like to add please feel free to mail me) - however below I have provided a more extensive chart which covers the main administration differences between management tools which is based upon: http://technet.microsoft.com/en-us/library/aa995972(EXCHG.80).aspx

To download the chart please click on the following link:

Exchange Management Tools Compatibility Guide [240KB]

Ok, since my work on integrating KVS (or Enterprise Vault) into my interop environment is almost at an end - I resumed the configuration of my first (and primary CCR database cluster).

My primary task today was to create and define the Disks that would house the Database files which are located on a pair of SANS (in separate Data centre’s) - however with these drives finally in place I needed to move the existing (created by default “Mailbox Database.edb” file from the DAS Log Drives to my new spanky RAID 10 SAN based storage.

I have supplied the following diagram to give you an overview of the scenario that I was facing:

Essentially as I had installed CCR clustering on both my nodes PRIOR to finalising the disk configuration, Exchange setup had placed the default “Mailbox Database” on one of the locally attached drives of my Nodes (actually it had placed the drives where I told it to during setup). However, these local drives are configured as x 3 RAID 1 pairs (with the view they will hold the transaction logs) so now I had my Database LUNS I needed to move the default database.

Now, some of you may have found that moving CCR databases from their existing locations to new locations is not that straight forward.

In fact there is no provision within the Exchange Management Console (unlike Exchange 2003) for moving CCR database between locations (there is for other server types) - if you wish to move a CCR Exchange database you have to use the Exchange Management Shell and a little manual intervention.

Moving the Database:

Open an Exchange Management Console [ START -> Programs -> Microsoft Exchange Server 2007 -> Exchange Management Shell ] and then type the following command line:

suspend-StorageGroupCopy -identity “First Storage Group” -confirm:$false

dismount-Database -identity “First Storage Group\Mailbox Database” confirm:$false

NOTE: BEFORE YOU BEGIN THE NEXT STAGE ENSURE THAT YOU HAVE A FULL BACKUP OF YOUR DATABASES AND CCR CONFIGURATION

At this stage you need to locate your “Mailbox Database” (the actual edb file) within the file system and then physically MOVE the database to it new location - so for example if your database is located in “C:\Program Files\Microsoft\ExchageSrvr\MDBDATA\Mailbox Database.edb” you will need to physically move this file to its new location (actually I would copy it to be on the safe side).

When you have copied (or moved) the database you will need to return to the Exchange Management Shell and then type in the following command:

Move-DatabasePath -Identity “First Storage Group\Mailbox Database” -EdbFilePath:”<new file system path\mailbox database.edb” -configurationOnly:$true

You will then be prompted twice for confirmation - enter A (for all) in both instances - see below:

You should at this point allow for Domain Controller replication (about 15 minutes) - then within the Exchange Management Shell type in the following commands:

Mount-Database -Identity “First Storage Group\Mailbox Database”

Update-StorageGroupCopy -Identity “First Storage Group” -deleteExistingFiles

You might receive a message about obsolete checkpoint file - at this stage enter in “A” for all to proceed - see below:

When done type in the following command line in to the Exchange Management Shell:

resume-StorageGroupCopy -Identity “First Storage Group” -confirm:$false

You should at this stage have a fully functioning (and correctly moved) database in a new location.

You may have noticed that I have done a number of articles recently which cover both Exchange 2007 (SP1), Windows 2008 and Symantec Enterprise Vault.

The main reason for this is that the biggest hold up of my current migration it terms of moving forward has been getting EV to work properly within an Interop environment where the CAS servers are in a position to provide OWA connectivity to both Mailboxes located on Exchange 2003 and Exchange 2007 - whilst also providing access to mail items contained within the vault.

I can truthfully tell you that it has been a nightmare - and due to this fact I wish to share with you all the processes that I went through to get both KVS and Exchange 2007 SP1 working together as I have lost many weeks on the project due to these problems.

The following have been the objectives that I needed to comply with in order to proceed with the migration:

Note: You will see in the following passage references to FULL KVS FUNCTIONALITY - from my organisational perspective this consists of the following requirements:

• People can still Archive Mail from within the specified client (OWA or Outlook)
• They need to be able to CANCEL archiving on an item
• They should be able to see and access their archived items
• They should be able to search their archives - and review items using the “Search Archive” function.

 

The following is a basic diagram of the desired functionality of EV within an Exchange Interop Environment whilst using an Exchange 2007 SP1 CAS server as the primary means of accessing OWA.

Outlook 200x Clients;

Users MUST be able to use the full functionality of KVS when connected to their Exchange 2007 mailboxes which are located on the new CCR clusters (see http://telnetport25.wordpress.com/2008/04/13/windows-2008-ccr-clustering-symantec-enterprise-vault-2007-exchange-2007-sp1-cas-servers-getting-it-to-work/ for information on this process). Full KVS functionality MUST also be maintained to mailboxes still located on the Exchange 2003 Servers.

OWA 2003 - via the Exchange 2007 NLB Client Access Servers;

As you will know, Exchange 2007 CAS servers can proxy requests to Exchange 2003 Mailbox servers (via the http://<casServerName>/exchange) route - however I needed to ensure that FULL KVS functionality is maintained for users whom still get redirected to legacy Exchange 2003 mailboxes even though they are using the CAS.

OWA 2007 - via the Exchange 2007 NLB Client Access Servers;

People whom have been migrated across to the new Exchange 2007 SP1 servers need to be able to have full KVS Functionality within their OWA 2007 Mailboxes.

Right, you might be looking at the requirements above and thinking “Easy” - well  can assure you that it is far from simple.

You see, when I began this migration our Enterprise Vault installation was based on version 6 - if you wish to achieve all the above objectives (and have them work) you MUST and I really mean MUST be running Enterprise Vault 2007 SP2 with the CAS servers running the following Enterprise Vault SP2 OWA Extensions http://seer.entsupport.symantec.com/docs/300400.htm - without this combination of software you will experience problems (and all this is before you have to make some configuration changes in AD) - I could bore you at this point with all the compatibility matrices, and indeed the fact that KVS 2007 was compatible with Exchange 2007 RTM but not with SP1 but take my word for it - EV SP2 with the latest OWA client updates are should be the only way forward if you are in Interop and using Exchange 2007 SP1.

So assuming that you are also running version 6.0 of EV and wish to migrate to Exchange 2007 SP1 you will need to do the following with you Enterprise Vault installation:

• Upgrade to Version 7.0
• Upgrade to Version 2007 (also known as 7.5)
• Upgrade to EV SP 2
• Install the OWA 2003 EV extensions on all Exchange 2003 Front End and Back End Servers
• Install the OWA 2007 extensions referenced in the above article (http://seer.entsupport.symantec.com/docs/300400.htm)

 

You should note that the Enterprise Vault 6.0 OUTLOOK client extensions will REMAIN compatible with EV 2007 SP2 - so you do not have a major problem in terms of having to upgrade all your clients in a short space of time - but, you should ensure that the most up to date Outlook client extensions are deployed soon after the upgrades to take advantage of enhanced functionality and updates.

All of the above is a project in itself. After which you will need to add your Exchange 2007 SP1 server into your EV site (this is described in the following article http://telnetport25.wordpress.com/2008/04/13/windows-2008-ccr-clustering-symantec-enterprise-vault-2007-exchange-2007-sp1-cas-servers-getting-it-to-work/).

OK, I have done all of the above - EV is still not working in OWA 2007 SP1?

Ok, this is where we will need to make those modifications in Active Directory that I spoke about earlier.

What you may have noticed is that after bringing your EV installation up to date and you install the OWA 2007 extensions on your CAS SP1 server - user whom have Exchange Mailboxes based on Exchange 2003 server will receive the following error message when clicking on the “Search Archives” option in OWA 2003 - see below;

You will be presented with the following error;

Users whom have mailboxes homed on Exchange 2007 SP1 Mailbox servers can make use of the features with no problems.

In order to fix the problems above you need to apply “Constrained Delegation” to your CAS servers.

Essentially as you will know you CAS server operates as a “proxy” to your Exchange backend servers (if they are 2007 servers it uses RPC if they are 2003 servers it uses HTTP) - in either sense the CAS needs to supply a set of credentials to the backend server in order for data to be accessed.

In the sense of your Exchange 2003 mailbox servers - the CAS needs to submit a set of credentials to the EVProxy Service - which in turn is presented to the Vault server which will allow for the correct vault to be searched in OWA (I said it was complicated). These credentials need to be presented to the EVProxy via Integrated Windows Authentication.

In order to configure the above you need to use a process called “Constrained Delegation” which - before you begin requires your “Domain Functional Level” to be set at “Windows Server 2003 or higher” (again I said that this was a pain).

Configuring Constrained Delegation:

Open Active Directory Users and Computers and navigate to the OU or Container which contains your CAS server(s) computer account, right click on the account and from the context menu that appears choose “Properties” - see below;

 

From the properties dialog that appears choose the “Delegation” tab - then select the “Trust this computer for delegation to specified services only” and then choose the “Use any authentication protocol” - then click on the “Add” button - see below;

 

When you click on the “Add” button you will be presented with the dialog box displayed below - click on the “Users and Computers” button, where you will be required to type in the names of the Exchange 2003 and Exchange 2007 MAILBOX Servers that you would like to delegate to - you should note that if your mailbox servers are CLUSTERED you should enter in the CLUSTER NAME not the NODE name of the servers.

When you have done this, the “Add Services” dialog box will change to reflect the list of services on each server that you have chosen which can be delegated - scroll down to “HTTP” and then choose your servers (you can use CTRL-CLICK to select multiple servers) - when you have highlighted your servers (as per the example below) click on the “OK” button:

You will then be returned to the main server properties dialog box which will have changed to reflect your choices - see below;

 

Click on the “Apply” and then “OK” button - then close ADUC, if you have more than one domain you will need to await for domain replication to take affect.

You should repeat this process for any CAS servers which are part of a NLB cluster.

You should now have full EV functionality within OWA 2003 and OWA 2007 from your CAS servers.

If you would like to read more on the above topic I recommend the following links;

http://seer.entsupport.symantec.com/docs/300407.htm

http://msexchangeteam.com/archive/2007/09/04/446918.aspx

When I am not wearing my Exchange Hat, like many I tend to have to dabble in other areas of the IT technical spectrum. One area other than Exchange where I have had a lot of experience is Citrix. Admittedly these days I have a very good team of Citrix professionals whom do all of the day to day admin, and indeed when new Citrix project come along they take lead on the design and implementation - however recently due to some staffing issues and indeed availability of staff I have been helping out on a major Citrix Presentation Server 4.5 migration from XPe FR3 to 600 of our customers.

Like all major roll outs, despite the most detailed of planning, there have been teething issues - and it is one such issue that I would like to share with you all.

If you have been following my Blog you will know that my current company uses Symantec Enterprise vault as its corporate e-mail compliance solution.

Now as one would expect during the “Due Diligence” phase of the migration from Citrix XPe FR3 to PS 4.5 we highlighted that we had 600 Citrix based KVS users whom were being migrated - therefore we would require the Outlook client extensions to be installed within the new PS 4.5 farm.

As part of the migration we were also providing an upgrade from Outlook 2000 to 2003 (yes I know don’t slate us - it complicated).

So to cut a long story short, we commissioned all the servers, installed all of the required applications, syspreped the servers, completed the imaging process, installed PS 4.5 and then migrated all of the users over.

For the most part it went very well, until we started receiving phone calls from customers complaining that they could not access their previously archived items via Outlook 2003.

Essentially the customers would be able to see their archived items in Outlook, which includes the preview stub and the correct icon to denote that the mail item is indeed a vaulted item - see below;

However when trying the retrieve the item from the vault all our customers would be presented with the standard stub preview - see below:

 

Clicking on the “Click here to view the original item” did nothing, functions such as forward failed to work as well.

I ran through the usual suspects that cause such issues and indeed review the tools bolted into Outlook via the client extensions:

• Re-installing the client extensions
• Ensuring that the Citrix Server could resolve the hosts names of the EV site and the EV server
• Ensuring that the client had access to the Organisational Forms repository which contained the EV forms.
• Reviewed the EV log for the user

 

All of which did not help or were set correctly.

After a lot of trial and error and indeed some feverish research on the Internet I discovered that using the default method of installing Outlook 2003 (or indeed Outlook XP, and 2007) within a Terminal Server based environment will omit (or not install) the core VBSCRIPT components of Outlook. This might not seem relevant to many, but Enterprise vault still relies very heavily on VBSCRIPT within Outlook to function.

OK - so by knowing this does this fix the problem?

Essentially it would seem that if you use the standard “Transforms” file to install Office 2003 / 2007 within Terminal services the following DLL file is not installed by default “OUTLVBS.DLL“.

What you need to do is find a “normal” office (or Outlook) 2003 / 2007 installation and then copy the DLL above to one of the following locations on each Terminal / Citrix Server:

• Outlook 2003 = Program Files\Microsoft Office\Office 11\
• Outlook 2007 = Program Files\Microsoft Office\Office 12\

 

Then restart Outlook - after which retrieving items from the Vault should work correctly.

For more information on this problem see http://support.microsoft.com/default.aspx?scid=kb;en-us;302003

As always - I hope that this helps some one along the way.

I have been blessed to work with a fine bunch on IT professionals over the years - none that I hold in higher regard than members of my current team.

The other day member of my team whom has expressed a firm interest in learning Exchange server in more depth came to me with a set of questions. The first question that he asked me was - how relevant the Exchange MTA service is considering that we have no legacy x400 requirements (I’ll get shot for called x400 “legacy”).

He had noted that the MTA service was still functional on our Exchange clusters and was curious why.

I thought that this was a good question, which although I have seen covered elsewhere on the Internet I thought that I would have my own stab at an answer

In this article I would like to go through the answer that I have given to Anil and how depending on the version of Exchange you are running affects your MTA requirements.

What is the Exchange MTA (Message Transfer Agent)?

The Exchange MTA has been a major part of Exchange for a number of years - certainly up until Exchange 2003. It is primarily responsible for the transportation of non SMTP based messages within an Exchange environment.

You will hear a lot about the MTA being the key part of transporting e-mail to and from X400 compliant messaging systems (such as Domino, GroupWise and Notes via associated connectors).

If you have an environment which is co-existing between Exchange 5.5 and Exchange 200x (except 2007) the MTA will also handle all RPC traffic between the 5.5 and 200x servers.

One common misconception that I have come across over the years is the belief that the MTA Service (or Microsoft Exchange MTA Stacks as it is known) in Exchange 200x plays a part in all forms of message routing - this is not true.

Protocols such as SMTP have their own internal routing functions which are independent of the MTA functions.

There is a huge amount of information around on the Internet about the MTA service - however if you are really interested in a firm technical description, the best resource that I have found is located here: http://technet.microsoft.com/en-us/library/aa997788(EXCHG.65).aspx

Ok - but what about the question - why are you running X400 if you don’t need it?

Good question (and one that if you search the Internet is answered many times), however I would like to elaborate.

I am old school Exchange, I started out with Exchange 4.0 and then progressed through to Exchange 5.5 - all of which had a very high dependency on the MTA Stacks service (you would not consider disabling it back then unless you wished to have problems).

Exchange 2000 was released, and again the story was that even if you did not have a requirement for x400 transport or Exchange 5.5 servers in your organisation you should still keep the MTA Stacks services running - Microsoft have explained this stance for “supportability” reasons as “unexplained” problems could occur within Exchange 2000 if the MTA service was not running.

Now most articles that I have read on this subject are fairly “vague” on the issues that can occur as a result of the MTA stacks service being disabled within Exchange 2000. The reason that I was given (by an unnamed Microsoft person) as to why there are no definitive answers as to what could happen is that MS is unsure as the to exact effects as it is not a fully tested scenario, however the following are definite problems that will manifest:

• X400 transport is not available
• 5.5 Co-existence models are severely hampered
• Move Mailbox tasks can fail (I am assuming that this would be between a 5.5 and Exchange 2000 site)
• Internal message transport can be disrupted

 

Given the importance of the MTA service in previous versions of Exchange, and indeed considering the time that Exchange 2000 was released I think that one could not blame Microsoft for not recommending disabling the MTA service. If you consider the following:

• Microsoft had a product in the market that relied on MTA in 5.5
• Microsoft released a successor to 5.5 and needed to entertain migration scenarios to the new 2000 platform from the 5.5
• The ground that Exchange had in the market compared to other competitors meant the if they were to tempt people away from Notes for example they needed to maintain x400

 

In Exchange 2003 things changed - essentially due to changes in the functional architecture of Exchange you could disable the MTA service as long as the following scenarios were met:

• Your Exchange 2003 Server routes messages to a 5.5 Org
• Your Exchange server is making use of connectors to x400 based mail systems
• Your Exchange server is directly interfacing with x400 based mail systems

 

If you are considering disabling the MTA stack services on your Exchange 2003 installation as you feel that you meet all of the criteria as per above I strongly recommend that you have a read of:

http://support.microsoft.com/kb/810489

The article takes you through how to accomplish disabling the MTA Stacks service but before you begin I would urge you to think about the following:

• Why are you disabling the MTA service?
• Is is because you wish to reduce your attack surface from exploits?
• Is it because you need to reduce the amount of resource usage?

 

If you are reducing your attack surface - I would urge you to balance risk over benefit - for example - In your current company you may use Exchange clusters and comply with all the scenarios above to warrant disabling the MTA stacks - but as the KB article explains removing the MTA stacks service from the first EVS is a simple task to accomplish - however if your company was to then acquire another which uses Notes for example - you have a major issue in establishing x400 based communication again.

If you are looking to disable MTA stacks from a resource point of view and you comply with the given scenarios which warrant disabling the service - then I would argue the amount of resource saved would be negligible as the service was never used to a degree where it would contribute to the utilisation of the system - if you need to claw back resource in such a manner you might need to review the whole of you installation.

I hope that you find this useful.

A little while back I posted (admittedly in a very downbeat mood) that in my current organisation I was Vulnerable to Redundancy. Since then I was told that, although my post had been flagged for redundancy it had been removed - as it had been decided that - and I Quote “At this specific time still considered to have some value in the future of the streamlining process” - roughly translated “they have noted that they cannot extract me easily at this point, and indeed my skills might help makes other redundant“.

I considered this for a little while (about 2.56 seconds), and decided that it was time to look at the job market for the first time in 11 years - as it is not in my nature to only be of “some value” to a company and indeed I will not use my skills to remove others from gainful employment unless they are guilty of some infringement.

Today I am pleased to announce that on Tuesday 17th June 2008 I will be taking up a new position with Atomwide Ltd as a Senior Networking Engineer.

Atomwide are mainly known in the UK for a long term and highly successful working relationships with large and complex Education based IT projects (for example large WANs, Internet and e-mail filtering, and LEA (Local Education Authority) and managed services - to name just a few services that they currently provide).

Recently Atomwide has been taking on more and more Exchange Server related work (both Educational and Commercial) and even though it has a wealth of highly skilled and experienced in house staff - they have decided they need another body to bouncing things off - and I was lucky enough to be appointed.

I am very excited about this opportunity, and indeed exceptionally pleased to be heading back into a world of “Full Time” technical work.

So if you are a company in need so some help with Exchange / Active Directory / LANS / WANS, or indeed some Exchange call off consultancy - and fancy my colleagues and I popping along to help or advise - drop us a line :-).

In addition to this I also have some exciting news about an international hook up that I have in the pipeline - however more on this later.

One of the best things about working on this blog is that over time it has become a mechanism to make friends with people whom normally I would not have had the opportunity to speak with.

One such friend is a chap called Josh Andrews.

Josh and I speak every now and then and the other day Josh dropped me a line about a problem that he was having Load Balancing a pair of Windows 2008 based Terminal Servers.

Essentially the following was Josh’s scenario;

He had a pair of Windows 2008 Terminal Servers each with a Pair of Broadcom Gigabit Network Adapters

Each Terminal Server was assigned a unique IP address for the LAN (e.g the non NLB Interface) and a unique IP Address for the NLB Adapter

When Josh created the NLB cluster (using the NLB interfaces in Each server) he found that although each interface converged correctly - he could ping the LAN addresses of the member servers, and indeed connect to them using RDP, however, if he tried to RDP or ping the Clustered NLB addresses he would get “Request Timed Out (Ping)” or “Cannot Connect (RDP)”.

Below is a simple diagram which illustrates a typical NLB configuration (in the example I have used fake IP addresses to protect Josh’s details), however you should assume that all IP addresses are all in the same Subnet and all connections are located on the same Switch) - when comparing this to Josh’s situation the following facts should be applied:

From his local machine (in the example below the TSCLIENT) He COULD Ping and RDP to the LAN IP addresses of: 11.23.1.82, 11.23.1.86

COULD NOT Ping or RDP to the NLB addresses of 11.23.1.83, 11.23.1.85

COULD NOT Ping or RDP to the CLUSTER IP address of 11.23.1.84

 

However he COULD ping and RDP to the both the Unique NLB and CLUSTER IP addresses from each node in the NLB Cluster.

At first I went through the usual suspects with him - for example;

• Was the Windows Firewall configured correctly to allow PING and RDP on the NLB Connections?
• Was the RDP Configuration within the Terminal Services manager configured to listen on the correct interface address?
• Was the port range for the Clustered IP address of the NLB configured to allow RDP and ICMP?
• As he was using a single Subnet and each server had two NIC’s had he given the NLB NIC the same Default Gateway has the Public NIC?

 

Essentially the answers to the above questions resulted in answers which indicated that all had been configured correctly so I started to look at other reasons for this problem.

My next suggestion (perhaps foolishly when looking back on it) was to install the Terminal Services Session Broker - this would ensure that he had followed the best practices guides for deploying Windows 2008 Terminal Services in a NLB (and I at that point suspected that the problem could be to do with the absence of the TS Session broker) - if you are interested in the recommended deployments of TS NLB on Windows 2008 you should review the following links:

http://technet2.microsoft.com/windowsserver2008/en/library/f9fe9c74-77f5-4bba-a6b9-433d823bbfbd1033.mspx?mfr=true

http://computer.ebooktops.com/step-by-step-guide-for-configuring-network-load-balancing-with-terminal-services-in-windows-server-2008/

Again, after installing the TS Session Broker - still nothing.

At this point I though that perhaps I needed to actually see what was happening within Josh’s environment so I asked Josh if he would be willing to allow me to use Cross Loop for a remote session into his network - to which he agreed.

After some investigation I established the following:

• Josh’s network consisted of a single subnet where all of the interfaces for the Terminal Servers and indeed the clients were patched into the same Switch - there were in VLANS in play.
• From assessment Josh had configured the Terminal Servers correctly, this included the NIC’s and indeed the NLB Clustering.
• No firewalls were interfering with traffic
• The only way to establish a RDP connection to either of the Terminal Services was to use the Public Interface Address.

 

This was, of course very frustrating - everything seemed to be working correctly, however you could not use RDP or Ping the cluster interface outside the cluster nodes.

At this point I jumped onto trusty Google to see if it could yield any useful advice:

Firstly I came across this article on TechNet http://support.microsoft.com/kb/898867 - admittedly this was slightly outside the scope of the problems that we were having but I thought that I would give it a go - nothing changed.

I then came across this article on TechNet http://support.microsoft.com/kb/816910 - which seemed to be more like it, however, the Network cards in Josh’s server were indeed server adapters and to boot - recent models therefore I discounted this.

After 20 minutes of floundering on Google I decided to rest my head on the keyboard, sob a little and contemplate defeat.

Then a moment of “clarity” - I decided to run the “ARP -a” command on the Preferred NLB node in the cluster. So I dropped to a Windows 2008 command prompt and typed in “arp -a” which revealed an interesting clue.

Essentially the ARP output reported the “Virtual” Interface  of the cluster - but no other meaningful data. I thought this was odd.

I pondered this for a little while, whilst I ran through the facts of the configuration. It was at this point I decided to look at the configuration settings of the NLB network card. Josh was using a Broadcom Gigabit server adapter - within his Dell servers, which to all intents and purposes are essentially the same devices as used in HP servers (just with slightly different drivers and obviously the branding is different) - so I accessed the NIC Properties and clicked on the “Configure” button - see below;

Clicking on the “Configure” button brought up the following dialog box - here I clicked on the “Advanced” tab which revealed a set of options similar to below (note if you have a True Broadcom card the options may differ from that below).

I reviewed the options that were available in the “Property” list. The option that I was most interested in was “Locally Administered Address“. Given what I had seen from running the ARP command and the configuration of Josh’s network, I decided to set the value for “Locally Administered Address” to “Not Present” (as I at this point suspected a MAC addresses issue) for the NLB NICs in both nodes within the cluster.

I then tried to ping the Cluster IP address from Josh’s PC - and……… Finally a reply!!!!!

I then attempted an RDP connection which also functioned correctly - yee haaa!

Josh was now able to proceed with configuring his NLB Windows 2008 Terminal Servers.

I learned a number of things from this problem, however the main point that sticks out is that the Network card configuration will be one of the first points of scrutiny in future - especially if all other settings appears to be as they should.

Both Josh and I hope that this will help someone else along the way.

Wow, yep I know that the title is a little bit of a mouthful, but today I have been working on getting my Enterprise Vault configuration to play nicely with my Windows 2008 based Exchange 2007 SP1 servers – and it has been a little bit of a job but now that it is pretty much playing as I would like which I thought that I would share the process that I used with you all.

Firstly let me give you a little bit of the background;

Within my environment prior to installing Exchange 2007 SP1 we were running Symantec Enterprise Vault version 6 (service pack 3) – this version obviously did not support Exchange 2007 in many aspects therefore we needed to upgrade to Enterprise Vault 2007 in order to support mailbox Journaling, Archiving and full .NET support for OWA 2007. The upgrade process involved firstly upgrading to Enterprise Vault 7.0 and then Enterprise Vault 2007 (known also as 7.5) – it is quite important to note that if you are a version 6.x user of EV you will need to upgrade to EV 7.0 BEFORE you can upgrade to 2007 (the actual upgrade process is beyond the scope of this article).

When we finally arrived at EV 2007 it was time to go away an build the foundations of my production Exchange 2007 SP1 organisation (which would run in interop mode along side Exchange 2003) which is made up of the following components:

x 2 CAS servers – NLB – running Windows 2008 x64

x 2 CCR Clusters – running Windows 2008 x64

x 2 Hub Transports (not relevant here)

Essentially the focus of my work would be the following objectives:

• Add the Exchange 2007 SP1 CCR Clustered Mailbox Server into the EV site as an archive target
• Install the EV OWA 2007 client Extensions on each of the CAS servers to provide access to archived items via OWA 2007 SP1
• Test that archiving works via OWA 2007 (this would include adding to the vault and accessing items contained within the vault)

 

Adding your CCR Clustered Mailbox Server to the EV site:

There are a few steps to this process, all of which must be followed. I have found that generally speaking Enterprise Vault runs exceptionally well once it is up and running, therefore a lot of Exchange system admins tend to forget the day to day complexities of it – in favour of the more straight forward “day to day” tasks (creating archive, review journal) so when it comes to changing the configuration of the Site and indeed adding in an additional server it can be quite daunting.

Configure an archive account for your the mailbox archive task on your CCR cluster:

Each mailbox server within an Enterprise Vault site requires a mailbox which is used for the processing of archive item data, this mailbox can reside in any Storage Group / Database – however the following are some provisos that you should consider:

• The mailbox can exist in any Storage Group / Database – however it should as best practice reside on the server where the archiving tasks will be run.
• The mailbox should not (under normal operation) grow to large proportions – however you should exclude it from any Organisation sizing restrictions – this could cause issues with the archiving process.

 

Therefore the very first step is to the create a new mailbox user which will act as the archive account on the CCR Mailbox server that you wish to add into your KVS Site – when you have created this account you are ready to assign permissions to the KVS Service Account and the New Mailbox that you have created. 

Configure Permissions for the EV Service account (VSA) on your Exchange 2007 SP 1 CCR Cluster:

During the installation of KVS you would have specified what is called the “KVS Service Account” AKA the VSA.

Essentially the service account is assigned full permissions to each mailbox server within your organisation, this allows KVS to perform its duties during Journaling and Archiving. In Exchange 2003 in order to assign the correct permissions to the KVS Service account you would need to ensure that you had the security tab enabled in the 2003 Exchange System Manager (see http://exchangepedia.com/blog/2004/12/how-to-view-security-tab-in-exchange.html) for an good overview of enabled the tab.

In principle when you had the tab available in Exchange 2003, you will then assign “Full Control” to the services account on each Exchange mailbox server (this would include the Send As and Receive As rights).

However in Exchange 2007 – the process of assigning the KVS Services account rights to your mailbox server has changed a little bit and now requires you to use ADSI edit.

Note:

This article is based around Exchange 2007 SP1 running on Windows 2008 being added into KVS – however, the same steps can equally be applied to Exchange 2007 (with or without SP1) running on Windows 2003 (the process can also be applied to non clustered Mailbox servers – although you need to be wary of running the CAS role on the Mailbox Server) – you should note that if you are running Windows 2003 you will need to install ADSI edit from the Windows 2003 support tools – if you are using Windows 2008 on your Exchange servers you will see that it is installed by default.

Open ADSI Edit [ START -> Programs -> Administrative Tools -> ADSI Edit ] then connect to the configuration partition of AD.

You will then need to navigate to [ Configuration -> Services -> Microsoft Exchange -> <Your Org > -> Administrative Groups -> Exchange Administrative Group (FYDIBOHF23SPDLT) -> Servers -> <Your CCR Server> ]

Right click on the entry for your server and from the context menu that appears choose “Properties”

From the dialog box (below) that appears choose the “Security” tab – then click on the “Add” button.

From the Select box (below) that appears either locate or type in the name of the KVS Service Account and then click on the “OK”

You will then be returned to the Security dialog box – choose the KVS Services account, and then tick the “Full Control” option (below) and then click on the “Advanced” button.

From the dialog box that appears (below) sort the permission entries by name – then locate your KVS Services account, select it and then click on the “Edit” button:

From the permissions box that appears (below) under the “Applies to” section choose “This object and all descendant objects” or if using Windows 2003 “This object and all child objects” then click “OK” 3 times.

After domain replication has taken place you will have successfully applied the correct permissions to the CCR Mailbox Server for the KVS Services account (VSA).

It is also necessary to grant the KVS Services account (VSA) “Full Control” permissions on the Archive system mailbox that you created earlier:

• Again open adsiedit.msc and open the Domain [<your Domain>] partition.
• Locate the Archive mailbox account that you created earlier this is usually under CN=Users, however you may have placed elsewhere depending on your AD configuration.
• When you have located the account object Right-click on it and from the context menu that appears choose “Properties”.
• From the dialog box that appears choose the Security tab.
• Add the KVS Services account (VSA) and then apply Full Control permissions to this account.
• Click Apply.
• Click OK

Adding your Clustered Mailbox Server to Enterprise Vault:

On your desired Enterprise Vault server open the Vault Administration tool [ START –> Programs -> Enterprise Vault -> Administration Console ] – see below;

When the administration console has loaded expand the following [ Enterprise Vault -> Directory on <Server Name> -> <Your Vault Site> -> Targets -> Exchange -> <Your Domain> -> Exchange Server ] right click on the Exchange Server node and from the context menu that appears choose NEW -> Exchange Server - see below;

You will then be presented with the “New Exchange Server” wizard – from the intro screen (below) click on the Next button;

From the screen that appears (see below) In the top most edit box enter in the name of the of the Exchange 2007 Mailbox Server that you wish to add, from the section entitled “Create Tasks for the Exchange Server” tick the tasks that you wish to be performed (for my example I only wish to setup a “Exchange Mailbox Task”).

When you are done from the section entitled “Create the tasks on this Enterprise Vault Server” choose the correct EV server in your environment which will take responsibilities for the Exchange 2007 Mailbox Server – then click on the “Next” button.

The wizard will change to display the “Choose Archiving System Mailbox” section (see below) – using the browse button locate the account that you created earlier on and then click on the “Next”.

You will then be presented with the task completion wizard (see below) – click on the “Finish” button.

You will be returned to the Enterprise Vault administration console – navigate to [ Enterprise Vault -> Directory on <Server Name> -> <Your Vault Site> -> Enterprise Vault Servers -> <your site> -> Tasks ] - see below;

Review the task list you should now see a new task entry which corresponds to the server that you have just added – initially you will see the task in a “Stopped” state – if you wait the task will start automatically - see below;

Close down the Administration Console for Enterprise vault and then using Windows Explorer (or via My Computer) navigate to the folder on your Enterprise Vault server where the EV binaries have been placed – this is typically:

[ C:\Program Files\Enterprise Vault ]

When you have done this, locate and then open the text file entitled “Exchange Servers.txt” in Notepad (it might be an idea to take a copy before you proceed).

When opened you will see that this file contains a list of IP addresses for your existing Exchange Servers which are configured to work with Enterprise Vault – at the bottom of the file add in the IP addresses for the following Exchange 2007 servers (in your Infrastructure):

• The CCR Cluster IP address for you mailbox server
• The IP addresses of you CAS server(s)

When you have added the IP addresses save the file.

Below is an example of where the file is located.

When you have finished adding the IP addresses to the file - you will need to configure the OWA anonymous access account so that it has the relevant permissions on your Exchange 2007 Mailbox and / or CCR servers (which you should have added to the IP address file previously) – therefore in order to proceed you will need to ensure that you know the samAccountName and the Password for the OWA account for your EV installation – this should have been documented during the EV implementation – it should NOT be the same has the KVS Services (VSA).

When you have the OWA account name for KVS – open a command prompt and navigate to the Enterprise Vault directory on your EV server (typically cd “Program files\Enterprise vault”) and then type in the following command:

cscript.exe OWAUser.wsf /domain:<Default NETBIOS DOMAIN> /user:<KVS OWA ANNON ACCOUNT> /password:<Password> /exch2003

So for example if my NETBIOS Domain was Trixy and my OWA samAccountName was OWAKVS with a password of “password” the command would be:

cscript.exe OWAUser.wsf /domain:trixy /user:OWAKVS /password:password  /exch2003

Even through you are installing for Exchange 2007 and indeed using KVS 2007 you still need to use the /exch2003 switch at the end! – below is an example of the command and the correct output:

When the VBSCRIPT command has run correctly, go to [ START -> RUN ] and from the RUN Command type in “Services.msc” and then clock on “OK” - when the services management console has opened locate the “Enterprise Vault Admin Service” and right click on it. From the Context menu that appears choose the “Restart” command - during the Restart of the service confirm that you wish to restart all the dependant services - see below;

When the EV Services have restarted you will need to Open the Enterprise Vault Administration Console [ START –> Programs -> Enterprise Vault -> Administration Console ] then from within the console navigate to [ Enterprise Vault -> Directory on <Server Name> -> <Your Vault Site> -> Enterprise Vault Servers -> <your site> -> Tasks ] - see below;

Locate the mailbox archival task for your new Exchange 2007 Mailbox Server then right click on the entry. From the Context menu that appears choose the “Properties” option. From the dialog box that appears choose the “Synchronization” tab and then from the “Update details of” section ensure that “All mailboxes” and all the tick boxes are Selected - then click on the “Synchronize” button - see below;

 

Installing the Enterprise Vault Client Extensions on your CAS Server:

Improved COM and installation my back side! - first things first do not install the Client Extensions from the KVS 7.5 media on a Exchange 2007 SP1 CAS server, they don’t work properly, instead I suggest that you go to the Symantec Web Site and down load the Extensions that are provided in this article http://seer.entsupport.symantec.com/docs/300400.htm

When you have downloaded the zip file - extract it to a convenient location on your CAS server, then run the EV_OWA2007_Extensions_x64.msi - see below;

When you have executed MSI file you will be presented with the following introduction screen - essentially here you can click on the “Next” button:

When you have click next the screen will change to display the EULA - click the “I Agree” box and then click on the “Next” button - see below;

The screen will then change to ask you where you like the EV binaries to be installed on your CAS - I would accept the default location and then click on the “Next” button - see below;

You will then be presented with the “Ready to Install” screen - click on the “Next” button to proceed - see below;

If you are installing the EV extensions on a CAS server which is installed on Windows 2008 SP1 you might during installation see the following error message;

You can safely click on the “Ignore” button.

When setup has completed you will be presented with the following dialog box - click on the “Finish” button.

If your CAS implementation is based around NLB you will need to install the EV Extensions on the other CAS servers which form the NLB.

When done, choose a “Test” mailbox which exists on your newly added Exchange 2007 Mailbox Server and run through the process of enabling it for Archiving - then access it via OWA 2007 and test the client experience.

That pretty much completes the process of adding in your 2007 SP1 mailbox server to Enterprise Vault and then installing the Client Extensions on your CAS servers - my next article will cover “Constrained Delegation” for EV and OWA 2007 SP1.