Category Archives: Exchange 2003

Post navigation

With all the media attention for Windows XP support coming to an end today, one might forget that today also marks the official death of Exchange Server 2003 as the extended support phase ends for one of the products many of us developed a love-hate relationship with over the years. In addition, extended support for Office 2003 also ends today.

Reaching the end of extended support means that as of today, those products are no longer supported and will no longer receive security patches. Therefor, organization running Exchange Server 2003 or using Outlook 2003 might be exposed to security risks.

Of course there is an exception to this rule, depending on how deep your pockets are. Organization neglecting or ignoring the upcoming demise of products for some period can continue to receive support for a hefty price. For example, the UK government paid $9m for an additional year of Windows XP, Office 2003 and Exchange 2003 support, and the Dutch government paid an undisclosed amount for an additional year of Windows XP support for around 40,000 systems. Ironically, the Dutch National Cyber Security Center NCSC, part of the department of justice, warned citizens to stop using Windows XP and upgrade.

For organizations still running Exchange Server 2003, there is nothing to be ashamed of as there are occasional sightings of Exchange 5.5 out there. When you think about upgrading, be advised that there is no direct upgrade path to Exchange Server 2013 and you either need to perform a double hop migration through Exchange Server 2007 or Exchange Server 2010 (recommended) or migrate to Office 365 as an alternative.

Like this:

In an earlier blog, I described the situation where a customer had improperly decommissioned Exchange 2003 Administrative Groups and ended up with invalid, orphaned legacyExchangeDN values causing all sorts of issues, most Public Folder / Free Busy related. Read more on this story here.

In the blog, I had two options on how to proceed:

Edit the legacyExchangeDN attribute of the users affected;

Recreate the Free/Busy public folder.

In the first blog, I described how to fix the situation using the 2nd option. Here’s how to solve this if you have no Exchange 2003 server left and want to go with the other option.

To fix this situation by changing the legacyExchangeDN values, you need to perform the following steps:

Identify all mailboxes containing improper legacyExchangeDN values;

For all those mailboxes, add the current legacyExchangeDN value as an x500 address;

Fix the current legacyExchangeDN.

Note that by adding the invalid legacyExchangeDN value as an X500 address, we make sure (responding to) old e-mail messages or nickname entries can resolve properly.

You could use tools like ADModify to bulk edit those values. However, you also achieve the same result using a little PowerShell (surprise!), as shown in the following script:

Note: Use the script at your own risk. I cannot accept any responsibility for consequences when using this in your production environment. Before using it, prepare it in a lab environment first: test, test, test! Also, this script fixes invalid legacyExchangeDN values; it does not fix any related invalid settings, like delegates; that might be something for a next version when there’s demand for it.

To use the script, replace the $oldDN value with your old, invalid legacyExchangeDN value (as reported in the Event Log entries with Event ID 14031). Set $newDN to your new legacyExchangeDN value; the default value of would be in the format “/o=<Organisation Name>/ou=<Administrative Group, i.e. Exchange Administrative Group (FYDIBOHF23SPDLT)>/cn=Recipients/cn=<Name>”.

If you have any questions, drop them in the comments below.

For all the PowerShell purists: Sometimes I prefer readability over trying to fit everything one 1 line. After all, this isn’t an Obfuscated Code Contest 🙂

A customer who recently migrated to Exchange 2010 and was still in the co-existence setup with Exchange 2003, reported lots of users experiencing issues with regards to Free/Busy information. Symptoms were inaccurate or missing Free/Busy information, which especially gets annoying when scheduling appointments.

It turned out these users were using Outlook 2003; users on Outlook 2007 or later experienced no issues. As you probably know, Outlook 2003 still utilizes public folders to publish users’ Free/Busy information. This information is consulted by Outlook 2003 when scheduling appointments; Outlook 2007 or later uses Exchange Web Services for this purpose.

A quick look in the Eventlog revealed lots of 14031 errors were generated by the FreeBusy Assistant:

This told us Exchange was unable to store Free/Busy information in a public folder, in this case /o=EUROPE/ou=First Administrative Group. A quick look at the Public Folder Management Console in Exchange 2010 showed that the folder didn’t exist. Since the Free/Busy public folder to be used by an Outlook 2003 user is determined by the legacyExchangeDN attribute, this was the cause of the issue.

The reason for the folder’s absence was unknown so one can only speculate. My best guess is improper decommissioning of the organization and administrative group originally hosting those users, identified by that “orphaned” legacyExchangeDN.

With the Free/Busy public folder missing and the original Exchange infrastructure gone, there are two alternatives to resolving this issue, apart from upgrading clients to a recent version of Outlook of course:

Edit the legacyExchangeDN attribute of the users affected;

Recreate the Free/Busy public folder.

The 1st option has consequences for the users, like being able to reply to earlier e-mail by co-workers. This can be resolved by adding the current legacyExchangeDN as an X500 address to the current set of e-mail addresses, but that also makes things a bit messy.

The 2nd option is to recreate the Free/Busy public folder; Here’s how to proceed:

First, using the Exchange System Manager (luckily, Exchange 2003 was still present), create an Administrative Group, e.g. First Administrative Group

Right-click the Administrative Group, e.g. First Administrative Group, and click Properties. There, edit the legacyExhangeDN attribute. Set it to match the missing Free/Busy public folder, e.g. /o=EUROPE/ou=First Administrative Group

Next, edit the siteFolderServer attribute. Set it to match the distinguishedName of a a public folder database. Note that you can pick the Exchange 2003 as well as Exchange 2010 Public Folder database here. In this example, I picked the Exhange 2003 public folder database, hence the storage group (SG1):

Now we need to wait for the store to recreate the Free/Busy public folder during its maintenance cycle, which may take up to 24h. If you’re in a hurry, and the situation allows you because of the service interruption, you can also restart the Information Store. When the Information Store has created the Free/Busy public folder, event 3047 is logged by the MSExchangeIS Public Store:

To verify this, startup the Public Folder Management Console or any other Public Folder management tool, and you’ll see the newly created folder:

After a while you’ll notice Outlook 2003 users are now storing their Free/Busy information in this public folder and Free/Busy will work again for these users. You can verify clients are storing Free/Busy information using EMS, ExFolders or MFCMAPI, e.g.:

Finally, don’t forget to create replicas of this new Free/Busy public folder when appropriate.

There are still a lot of questions and tweets on Mac’s Outlook 2011, Exchange 2003 and why that combination doesn’t work. I can only assume people overlooked the system requirement in the Apple store, which clearly states “Exchange support in Outlook 2011 requires connectivity to Microsoft Exchange 2007 SP1 RU4 or later”.

The reason for lack of support lies in the fact that Outlook 2011 connects to Exchange Server using what is called Exchange Web Services. These services were introduced with Exchange 2007 (and thus are also available in Exchange 2010). The result is that Office 2011 can’t synchronize information, like e-mail, contacts and calendar, with Exchange 2003.

On a side note, you could use Entourage 2008 which utilizes the WebDAV protocol. This is supported by Exchange 2003 as well as 2007, but was discontinued in Exchange 2010.

Is this bad? I think not. Apart from the requirement, which is clearly mentioned, Exchange 2003 is almost 8 years old now. Products evolve and mainstream support has already ended for Exchange 2003. Even if Exchange 2003 is running rock solid, organizations should be considering on what to do with their Exchange 2003 environments as part of the IT life cycle management process.

The JetStress tool can be used to simulate disk I/O load on a test server running Exchange to test and validate performance and stability of the disk subsystem, prior to moving them into a production environment.

In the long list of recent Exchange news today Microsoft published the RTM versions of Exchange Jetstress 2010 and Load Generator AKA LoadGen 2010.

Both tools are now at version 14.01.0180.003.

Jetstress can be used to check performance and stability of storage under load. It simulates Exchange I/O behaviour for Exchange 2003, 2007 or 2010 in order to verify dimensioning and check if storage meets performance expectations for a certain number of users with a certain I/O profile.

LoadGen can be used to simulate MAPI, OWA (2007, 2010 or 2010SP1), EAS, IMAP, POP and SMTP client load against Exchange 2007 or 2010 servers. LoadGen will use real clients to simulate the load and, like Jetstress, LoadGen can be used to verify dimensioning and check if the design meets performance expectations.

Unlike Jetstress, which can be used to verify things from a database perspective, LoadGen can be used to verify things from a client (handling) perspective.

You can download the Jetstress 2010 here and LoadGen 2010 here (x64, x86 version here).

Note: If you used the beta version of JetStress you should recreate the databases for the RTM version as Doug Gowans found out.

Like this:

Johan Veldhuis blogged about the problem we encountered when moving mailboxes cross-forest from Exchange 2003 to Exchange 2010 (also see my 2-part article on cross-forest move). We received the following mailbox move failure message:

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″.

So, besides an Exchange 2010 mailbox the Exchange 2003 mailbox was still there, and AD attributes weren’t changed on the source AD object (e.g. HomeMDB still pointing to Exchange 2003). This is a potential serious condition as incoming e-mail might be delivered to the Exchange 2003 mailbox instead of the new Exchange 2010 mailbox, depending on your setup and speed to remove the source mailbox.

To assist with this issue Microsoft released hotfix 940012 for Exchange 2003. It will generate an event on Exchange 2003 when it cannot remove the mailbox. It will also log which folder might be the culprit. After detecting and identifying the mailbox with issues, you still need to remove it manually (steps should be known; if not, they’re contained in the kb article).

You can view kb article 940012 here and download the related hotfix for Exchange Server 2003 SP2(!) through here.

Like this:

The PFDAVAdmin tool has been updated to version 6.05.8170. As you probably know, PFDAVAdmin can be used to perform management tasks related to Exchange’s public folders and mailboxes and is supported on Exchange 2000, Exchange 2003 and Exchange 2007.

Like this:

The MAPI and CDO libraries, still required by some applications or scripts talking to Exchange, have been updated.

The libaries are meant to unwind the application and storage layers, making applications and code using these libraries independent of the underlying Exchange or Outlook version. It also enables certain applications/scripts to run remotely (mostly apps/scripts from the pre-PowerShell era). Only problem you can encounter is when applications/scripts make use of certain functionality only to be found in certain Exchange/Outlook versions, requiring specific MAPI or CDO library versions.

Follow Us on Twitter

Follow Us via Email

Enter your email address to follow this blog and receive notifications of new posts by e-mail.

Copyright

Unauthorized use or duplication of this material without permission from EighTwOne is strictly prohibited. Excerpts and links may be used, provided full and clear credit is given to EighTwOne with appropriate direction to original content.

Disclaimer

Content is verified as far as possible, however, usage is at your own risk. EighTwOne does not accept liability for information contained on sites linked to. Opinions expressed are my own and do not represent my employer’s positions, strategies or opinions.

About Michel de Rooij

Michel is an Office Servers and Services MVP with a PowerShell affection, and publisher of EighTwOne. You can find him on Twitter, LinkedIn, Facebook, or Google+. Use the Contact form for questions, consulting, support or other engagements.