Share via

Couple of Interesting KBs

  • Article

Here are a couple of interesting KBs that have come out or been updated recently:

KB.884863 (https://support.microsoft.com/kb/884863) – “Update to Exchange 2000 Server adds application event logging for deletion of public folders”

An additional feature that is related to public folder diagnostics logging is now available for Microsoft Exchange 2000 Server. When you use this new functionality, an event is generated in the Event Viewer Application log when a user deletes an Exchange 2000 public folder. If the Public Folders General category is set to Medium logging or higher, an event that similar to the following will be logged when a user deletes a public folder in Microsoft Exchange 2000 Server:

Event Type: Information
Event Source: MSExchangeIS Public Store
Event Category: General
Event ID: 9682
Description: Folder /Name_of_Public_Folder with folder ID 9-9999B was deleted by /o=Exchange_Organization_Name/ou=Exchange_Site_Name/cn=Recipients_Container/cn=User, user account Domain\NTAccount_Name.

 

Note, you can also get this hotfix for Exchange 2003 Post-SP1 by referencing KB.891968 with PSS.

 

 

KB.895847 (https://support.microsoft.com/kb/895847) – “Multi-site data replication support for Exchange 2003 and Exchange 2000”

 

You can use replication technology to help provide high availability for Microsoft Exchange Server 2003 or Microsoft Exchange 2000 Server data. Exchange 2003 and Exchange 2000 replication solutions are provided by third-party program vendors. This article describes our support policies for Exchange when Exchange is used together with a third-party replication solution.

 

(Translation: this is the definitive “Exchange on replicated storage” KB article. It covers synchronous replication, asynchronous replication, software replication, Geo-clusters, you name it!)

 

 

KB.894094 (https://support.microsoft.com/kb/894094) – “You can take the MTA resource offline, but you cannot bring the MTA resource back online after you restart a Windows-based cluster”

 

On Exchange 2003 clusters – particularly clusters with lots of MDB stores – you might find that if you cycle the MTA resource in CluAdmin, the resource fails to come back online. This is because in some scenarios, the DB000001.DAT file may be corrupted by this action. Please see the KB for a bit more detail, and get the hotfix if this applies to your large cluster.

 

 

KB.175481 (https://support.microsoft.com/kb/175481) – “Exchange single-instance storage and its effect on stores when moving mailboxes”

 

This KB article about single-instance storage behavior during mailbox moves (ie – that we keep it if you use the built-in move process) has been updated to include the cross-site mixed-mode Exchange 2003 SP1 feature. The article clarifies that these cross-site moves also retain SIS, unlike the old “Exmerge” method of moving mailboxes cross-site.

Comments

  • Anonymous
    March 17, 2005
    Hello Evan.

    Can I ask you one question regarding Exchange clustering and event sinks?
    For example:
    We have two node active/passive Exchange 2003 cluster.
    COM+ applications which holds the event sink dll installed on both nodes.
    Then we register event sink globally on mailbox and public folders stores on active node.
    Now everything works fine - event sink process messages.
    Then we failover to second node, so it become active.
    After that the event sink is not triggered at all.
    The event sink registration records is present (I can check this through Exchange Explorer).
    If we re-register (remove this records and create again) then the event sink will start receive events and function properly.
    Thus, to make event sink failover compatible we need to create cluster resource that depends on Information store resource and re-register event sinks on failover.
    Question: Is this a normal behaviour or I miss something? And what is the reason of fact that we need to re-register event sink?
    The only bad thing is that sink re-registration is not very fast process and some messages may pass through before it completes after failover.

    Thanks in advance.
    Alexey Shlibanov.
  • Anonymous
    March 17, 2005
    I forgot to leave my e-mail: shlibanov(at)mapilab.com
    Alexey Shlibanov.