Monday, July 26, 2004

Microsoft Community Blogs

Well, MS has published a web site for all internal employee BLOG's that are available publicly.  They are sorted by topic.  Have fun.  Looks like my RSS reader will be busy.

http://www.microsoft.com/communities/blogs/PortalHome.mspx

Wednesday, July 21, 2004

Recover deleted items using OWA

This is an original post from Paul Holmes at Horizons Consulting http://www.hrizns.com   

As you may be aware, there is a registry setting which you can set on a workstation to allow you to recover items that have been deleted from ANY folder in Outlook.  That functionality is now available in Outlook Web Access when the mailbox is located on an Exchange 2003 server without changing the registry.  You'll need to be logged on with an account that has access to the mailbox and connect directly to the Exchange server the mailbox is on – not through a front-end server.  Here's a link that you can use to access a user’s recoverable deleted items through OWA.

http://<serverName>/exchange/<userID>/<folderpath>/?cmd=showDeleted&close=1

Where serverName is the Exchange server, userid is the account name, and the folderpath is the folder name or its path if it's a sub-folder.

This will open a web page showing the deleted items in that folder with a recover button to restore the items to the original folder.

Regards,

Paul Holmes

 

Recovery Storage Groups bug - Must have matching Parenthsis!

This is an original post from Paul Holmes from Horizons Consulting http://www.hrizns.com   

While working on the Exchange 2003 servers, I ran into an interesting issue.  After creating a recovery storage group I attempted to add a mailbox store to the RSG.  However, this would fail with an LDAP filter error.  In working with PSS we discovered that this was being caused by a typo in one of the mailbox store names.  Apparently, one store had a missing right parenthesis.  According to PSS, the total of left and right parentheses must match but they do not necessarily have to be in any sort of order.  After adding the missing parenthesis to the store name it resolved the issue.

 

Regards,

 

Paul Holmes

Tuesday, July 20, 2004

What is that ca_defaults.xml in Exchange 2003 SP1 ADC anyway?

A common complaint with the version of ADC Tools released with Exchange 2003 was:
 
When you use the wizard to create your connection agreements you don't have a chance to look at them or change them before they replicate.  What if I want to look at them before they replicate to make sure all is well?
 
Well, with SP1 you can now set many default ADC options up front by modifying a file called ca_defaults.xml.  By default, Ca_defaults.xml is in the \program files\msadc folder (once SP1 ADC is installed).  Before creating new connection agreements with the ADC Tools wizard you can modify this file to set the defaults you would like new connection agreements to possess.
 
For example, if you would like to have all new connection agreements be set to "never replicate" so that you can review them before they initially run (and solve the problem I listed above) you would change the following line in the ca_defaults.xml file
            from:
            <attribute name="activationStyle" value="2">   
to:
            <attribute name="activationStyle" value="0">
On the activationStyle attribute, 2=ALWAYS, 0=NEVER, and 1=selected times
 
Great news! What else can you do with ca_defaults.xml?  Well for another example, you can also control the default settings on the "Deletion" tab:

You can control the option "When replicating deletions from the Exchange Directory" by setting msExchServer1DeletionOption
                        A value of 0 = deletions are processed as normal
                        A value of 1 = deletions are written to the LDF file
You can control the option "When replicating deletions from the Windows Active Directory" by setting msExchServer2DeletionOption
                        A value of 0 = deletions are processed as normal
                        A value of 1 = deletions are written to the CSV file
 
In fact, you can set many of the attribute defaults by modifying this file.  (Although most of them you probably wouldn’t really have a need to control)  The other attributes you can control are listed in:
http://support.microsoft.com/?id=867627 along with more information on setting them.  That article doesn’t discuss what each attribute actually does so if you need a detailed explanation of the attributes, take a look at Appendix C of the "Understanding and Deploying Exchange 2000 Active Directory Connector White Paper" located at: http://www.microsoft.com/downloads/details.aspx?FamilyId=C763B584-C511-4687-B27F-A13A8F82D4C8&displaylang=en
 
A few other things to note:
 
If you reinstall the ADC (which would include service packing the ADC since that is really a reinstall) you will overwrite the ca_defaults.xml file - so make sure you back this up if you modify it so you can easily drop it back in.
 
Let’s say you set the default to "never replicate" in our original example and then the wizard comes back and tells you that you need to create 100 connection agreements for your environment.  You run through, verify you agree with the settings and all is good and you are ready to use the connection agreements - except now you need to modify all 100 of these connection agreements to start replicating (remember you set it to NEVER).  What now?  Well there is a nice little script in that very same directory called activate_cas.vbs.  Using this script you can easily set the value on all existing connection agreements to 2 (ALWAYS) by running:

            Activate_cas NOW

July 13, 2004 Updated: Exchange Server 2003 Disaster Recovery Operations Guide

Microsoft has released on July 13th a revised edition of the Exchange Server 2003 Disaster Recovery Operations Guide.

Some of the things covered in this document are:

  • What not to backup when doing a full computer backup.
  • How to backup and restore Databases, SRS, Connectors, and Certificate Authorities.
  • How to backup and restore Cluster Servers (individually or the entire cluster).
  • How to restore Windows 2003.
  • What information about the server you should record before a server fails.

Thursday, July 15, 2004

Duplicate Detection of Messages

Duplicate detection of delivered messages is done by the Exchange store. The store does duplicate detection based on two properties on the message - the Internet Message Id and the client submit time. We would have liked to do duplicate detection based solely on the Internet Message Id but there are several not-to-be named applications out there that use the same Internet Message Id on all their messages.

The store keeps track of duplicates using a table in JET called the DeliveredTo table. When a message is delivered to a user, the store checks this table and if no entry is found the message is delivered to the user and a row is added to this table to indicate that the user received the message. If an entry is found, the message is turfed.

The store only tracks duplicates for 1 hour by default. This can be changed by changing the value of registry setting:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<Server Name>\<Private/Public-Guid>\Track Duplicates (in hours)

The maximum value that the store will accept for this registry value is 49 days, if a value greater than 49 days is set, the store will ignore the value and keep duplicates for 24 hours. But keep in mind that increasing this value will cause this table to grow really large and this could slow down delivery.

The store will periodically delete the old items from the deliveredTo table which is handled by the background cleanup thread which runs every hour. This is also configurable and the registry setting is:
 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<Server Name>\<Private/Public-Guid>\Background Cleanup (in msecs).

There is still a chance that you will get duplicate email if the delivery of email is delayed because of the following reasons:

1) If either the internet message id or the submit time is different on the two messages, the second message will not be treated as a duplicate.

2) If the two are the same, but time interval between the arrival of the two messages is greater than 1 hour, the store cleanup task would have deleted the original entry in the deliveredTo table and the user will get duplicates.

3) If the user is moved. The deliveredTo table is per database and the information is not moved when the user's mailbox is moved.

4) In older versions of Exchange we had a problem where duplicates would occur when a message was sent to a user and a DL containing the user using OWA. When the message was submitted the store would stamp an Internet Message Id on the outgoing message. However, since OWA submits messages with native MIME and the fact that the Internet Message Id stamped by the store on submission did not update the MIME Message Id header, the MAPI message was out of sync with the native MIME. The message would then be bifurcated by Transport and this would result in messages with different Internet Message Ids and therefore, duplicates. We changed this in Exchange 2003 so that the store only stamps the Internet Message Id on a message if it detects that the MIME has to be regenerated or if it is a pure MAPI message.

Tuesday, July 06, 2004

Next Exchange might get "log shipping" support

Next Exchange might get "log shipping" support
Posted by bink on July 1, 2004 at 6:25 PM
 
 

At a Exchange session the speaker revealed that the Exchange team is researching “log shipping” support for the next version of Exchange, just like SQL has log shipping.

What is Log Shipping (in SQL)

Essentially, log shipping is the process of automating the backup of database and transaction log files on a production SQL server, and then restoring them onto a standby server. But this is not all. The key feature of log shipping is that is will automatically backup transaction logs throughout the day (for whatever interval you specify) and automatically restore them on the standby server. This in effect keeps the two SQL Servers in "synch". Should the production server fail, all you have to do is point the users to the new server, and you are all set. Well, its not really that easy, but it comes close if you put enough effort into your log shipping setup. more on sql log shipping at this source



Working with Active Directory Permissions in Microsoft Exchange 2003

A colleage of mine just forward a link to the long awaited MS Whitepaper update from Paul Bowden on E2K3 permissions.  I have lived by the E2K version of this document, and have long awaited it's replacememnt for E2K3.  It is a MUST have to any advanced Exchange deployments!

This guide discusses the necessary minimum rights needed for Exchange administrators to manage Exchange-related data in Active Directory as it pertains to user, inetOrgPerson, group, and contact objects so that separation of administrative tasks can be implemented. Further, this document is a reference guide for administrators implementing a split permissions model.

http://www.microsoft.com/downloads/details.aspx?FamilyID=0954b157-5add-48b8-9657-b95ac5bfe0a2&DisplayLang=en

This time it has sample sample txt files that make using DSACLS easier.

Thanks Henry for the link!

Thursday, July 01, 2004

What Is The RUS Doing Now and Why?

What Is The RUS Doing Now and Why?


In Exchange 2003, you can view the object the RUS is processing by setting Proxy Generation diagnostics to maximum

Using ESM, pull up the server properties of the RUS machine. Choose Diagnostic Logging, MSExchangeSA, Proxy Generation. Set that value to maximum. Now in the event log you will start to see 3006 messages. Each message will contain the object being processed, which polices that apply to the object, the proxies the object has, and the proxies the RUS will apply.

If the RUS is doing a full rebuild, you can see how far along the RUS is, by setting the Address List Synchronization diagnostics to medium.

Using ESM, pull up the server properties of the RUS machine. Choose Diagnostic Logging, MSExchangeAL, Address List Synchronization. Set that value to medium. Now in the event log look for 8329, 8332 and 8330. The RUS logs 8329 at the beginning of a rebuild. 8330 at the end. During the rebuild the RUS will log a 8332 message every 10% of the way( approximately).