Monday, December 27, 2004

How to check the progress of the Exchange Recipient Update Service

In this KB http://support.microsoft.com/default.aspx?scid=kb;en-us;246127, we get a good description of how to check if the RUS is working properly to update user accounts. 

SUMMARY

This step-by-step article describes how to verify that the Recipient Update service is working correctly. In Microsoft Exchange 2000 Server and Microsoft Exchange Server 2003, a user may not appear in the Global Address List if the Recipient Update Service is not configured properly.

Verify the existence of the showInAddressBook attribute

Use ADSI Edit (Adsiedit.exe) to retrieve the properties of a known user and make sure it has the following attribute: showInAddressBook. If this attribute is present, the Recipient Update Service has correctly populated the information in Active Directory, and there is another issue that is preventing the user from appearing in the Global Address List.

To use ADSI Edit to look for the showInAddressBook attribute, follow these steps:
1.
Click Start, point to Programs, point to Windows 2000 Support Tools, point to Tools, and then click ADSI Edit.
2.
Expand Domain NC [server_dc.yourdomain.com]
3.
Expand DC=yourdomain,DC=com
4.
Expand CN=Users
5.
Right-click CN=User_Name and then click Properties.
6.
In the Select which properties to view list, click Optional.
7.
In the Select a property to view list, locate the showInAddressBook attribute.

Verify that the uSNChanged value is greater than the msExchServer1HighestUSN value

Use ADSI Edit to view the properties of the same user and to note the value of the uSNChanged attribute. This value must be greater than the value of the msExchServer1HighestUSN attribute in the Recipient Update Service object that is responsible for this user. To compare these two values, follow these steps:
1. Click Start, point to Programs, point to Windows 2000 Support Tools, point to Tools, and then click ADSI Edit.
2. Expand Domain NC [server_dc.yourdomain.com]
3. Expand DC=yourdomain,DC=com
4. Expand CN=Users
5. Right-click CN=User_Name and then click Properties.
6. In the Select which properties to view list, click Optional.
7. In the Select a property to view list, click the uSNChanged value attribute, and then note the number in the Value box.
8. Expand Configuration Container [server_dc.yourdomain.com]
9. Expand CN=Configuration...
10. Expand CN=Services
11. Expand CN=Microsoft Exchange
12. Expand CN=Your_Exchange_Org
13. Expand CN=Address Lists Container
14. Click CN=Recipient Update Services.
15. In the right pane, right-click CN=Recipient Update Service (yourdomain.com), and then click Properties.
16. In the Select which properties to view list, click Optional.
17. In the Select a property to view list, click the msExchServer1HighestUSN attribute, and then note the number in the Value box.
Note You must obtain the properties of the Recipient Update Service object for your domain.

If the uSNChanged value is greater than the msExchServer1HighestUSN value, it means that the user has not been updated by the Recipient Update Service. The user will be updated during the next Recipient Update Service cycle if the Recipient Update Service is running.

Manually run the Recipient Update Service

You can manually run the Recipient Update Service to update the user information in the Global Address List. To do this, follow these steps:
1. Open Exchange System Manager.
2. Expand Recipients, and then click Recipient Update Service.
3. In the right pane, right-click Recipient Update Service (yourdomain.com) and then click Update Now.

Set the default schedule setting for the Recipient Update Service to Always Run

To set the default schedule setting for the Recipient Update Service to Always Run, follow these steps:
1. Start Exchange System Manager.
2. Expand Recipients and then click Recipient Update Service.
3. In the right pane, right-click Recipient Update Service (yourdomain.com), and then click Properties.
4. Click the General tab, and then click Always run in the Update Interval list.

Configure IMF gateway settings per server?

From http://blogs.msdn.com/evand/archive/2004/09/05/225916.aspx:

Someone sent me email the other day asking about the global configuration of the Intelligent Message Filter (IMF). "Is there anyway to configure the IMF settings at the Admin Group level or something less than global," they asked.

Well, it turns out there is a way to configure the IMF (or at least, the gateway portion of the IMF) at the server level.

By default, when the IMF initializes, it reads the "gateway action" and "gateway threshold" configuration information from the "Global Settings" configuration defined in ESM -- configuration which is stored in the AD and is global to the entire Exchange organization. See the IMF Deployment Guide or the MSDN Content Filtering Object configuration for more information on these settings stored in the AD.

This configuration is global, however. So how would you facilitate the scenario of having two different gateways with IMF handling inbound spam using different threshold values and/or actions? This might be useful if you have two different DNS domains, one of which requires agressive spam filtering and the other requires very minimal spam filtering. Configuring multiple inbound gateways, each with different IMF thresholds and actions might be quite useful in this case.

The answer is "registry override". The gateway settings are read first from the AD, but the registry on the IMF gateway server is also consulted and if there is an override setting configured, these "per-server" override settings are used instead.

Here are the details:
Reg Key: HKLM\Software\Microsoft\Exchange\ContentFilter

Value: GatewayThreshold
Type: REG_DWORD
(Create value and set within the range 0-9. This maps to the Gateway threshold defined on Global Settings)

Value: GatewayAction
Type: REG_DWORD
(Create value and set to one of the values from the following table)

Possible Actions for the GatewayAction (these map to the "when blocking messages" dropdown):
0x0 = No Action
0x1 = Delete
0x2 = Reject
0x5 = Archive (+Delete)

Note that these two registry values will allow you to control the gateway IMF behavior at a per-server basis, but will NOT do anything to control the "information store" UCE behavior.

 

Wednesday, December 22, 2004

Showing how much whitepace is in your database via script

Glen Scales just keeps pumping out very useful scripts.  This one is designed to show how much whitespace is available in all the databases in the org.  It is great because it also shows the number of Deleted mailboxes being held in the database as well as the amount of storage they are consuming.  This is all available information in the Event log, but it is nice to have it all in one place once the script is run.

When the Information Store maintenance process runs it logs to the windows eventlogs the results of its retention and de-fragmentation operations. More importantly it tells you how much space is held in deleted item retention (and how much it just released). How much space is held in deleted mailbox retention and how much it just released. And finally how much free-space there is in the database after the online de-fragmentation has just run.

So what this script does is query AD for all the mail and public folder stores in your domain. Then it querys each servers event log for 3 specific events that contain the details of the 3 maintenance operations and then parses the result out of that text and displays the result at the commandline. Event “1221” is logged after an online de-fragmentation is run on a mailbox or public folder store. Event “1027” is logged after the deleted item retention cleanup is done and the result of starting and ending size and numbers is logged. Event “9535” is logged after the deleted mailbox cleanup is run and logs the number and size of deleted mailboxes retained and purged.

To identify each mailstore within the eventlog exchange uses a format storagegroup\mailboxstore. This format isn’t stored in Active directory anywhere (easy) so I had to build it from the Active Directory DN path. This should all work fine as long as you don’t have any “,” in your mailstore name (this is going to break the split).

I’ve post a downloadable copy of the script here

Tuesday, December 21, 2004

Microsoft to delay SMTP relay software

Well, the news is out about another change in the messaging product line by MS.  Seems like Edge Services will be delayed until 2006 and Exchange Server 2003 SP2 will now include a reworking of Anti-SPAM technology.  Read more at SearchExchange.com

Some changes are:

  • Edge delayed until 2006
  • SP2 to include SenderID
  • Future Exchange core product to include Edge services type of functionality

Exchange Special Mailboxes Part 2 - System Attendant mailbox

Evan Dodd has written Part 2 in his series on Special Mailboxes in Exchange.  Read on....

This post is a follow-on post to the SystemMailbox post from last week. Here I’m talking about System Attendant mailbox in Exchange 200x.

 

System Attendant mailbox

What is it and what is it used for?

 

Each Exchange 200x server has one (and hopefully only one) System Attendant mailbox. If the server has a System Attendent mailbox (note the misspelling), someone has probably been messing around with the server. Yes, I put that in mostly so it would be indexed with the incorrect spelling as a keyword also. J

 

The System Attendant mailbox has a folder within it called SpecialPrivateFolderForFreeBusyStorage. This folder is used when CDO or OWA push Free/Busy information up to the store through the MSExchangeFBPublish process.

 

System Attendant mailbox is also required to be available during mailbox moves. For instance, if you have the mailbox store containing the System Attendant mailbox dismounted during a mailbox move, the move will fail and you’ll find events 9175, 9167, and 1008 in your application event log (see KB.264413).

 

The SA mailbox is also used to send and receive the messages used by the legacy link monitoring service.

 

Where can it be found?

 

There are two parts to make up the complete System Attendant mailbox: a directory object and a mailbox object. The directory object is the actual System Attendant object in the configuration container (ie, at a location like: CN=Microsoft System Attendant,CN=<servername>,CN=Servers,CN=<sitename>,CN=Administrative Groups,CN=<orgname>,CN=Microsoft Exchange,CN=Services,CN=Configuration,CN=<domain> ). This directory object hosts all of the directory attributes associated with the system attendant. There is also a mailbox object, stored in the first Mailbox store created on an Exchange 200x server. This is generally the “Mailbox Store (servername)” store.

 

When does it get created? Can it be moved and/or recreated?

 

The System Attendant mailbox is created when the System Attendant is created on a server. It is associated with the first mailbox store created on a server.

 

If an attempt is made to delete the mailbox store containing the System Attendant mailbox, the following warning will appear:

 

Deleting this mailbox store may result in the loss of system messages used by Exchange, such as Free/Busy or Key Management Security. If you choose to continue, you need to restart the system attendant service after the store is deleted.”

 

If the store is then deleted, the System Attendant mailbox will be moved automatically into another mailbox store on the server (ie – the HomeMDB value on the directory object will be updated). System Attendant service will have to be restarted to reconfigure MSExchangeFBPublish to use the new mailbox location, and the mailbox object may not reappear under the “Mailboxes” node of ESM until it is used in the future.

 

If there is a System Attendant directory object but no mailbox object (ie – one good cause of this is dropping in a blank store for troubleshooting), the mailbox store object will be recreated automatically in the mailbox store referenced by the HomeMDB attribute as soon as it’s needed.

 

How can I log onto the System Attendant mailbox?

 

It can be done, but it’s a fairly complicated set of steps and you’ll have to call PSS to get them.

 

SHOULD I log on to the System Attendant mailbox?

 

Probably not. I can’t think of any good reasons for accessing this mailbox without PSS directing you to do so.

 

What happens if I don’t have a proper System Attendant mailbox?

 

If there’s no System Attendant mailbox available on a server (and in a mounted and functional mailbox store), anything that requires it will almost certainly fail. You’ll see 9175 events logged in the application log, indicating a failure to logon to this mailbox by the system. You’ll see OWA-generated Free/Busy information not getting updated. You’ll see mailbox moves fail. It’s a very important mailbox to have configured properly and available!

Group Policy Webcasts

There is a blog entry on Bink.nu that had these webcasts listed.  This is a good set of reference webcasts for anyone starting to understand GPO's.

TechNet Webcast: Introduction to Group Policy (Part 1 of 14) (Level 200)

TechNet Webcast: Applying Group Policy (Part 2 of 14) (Level 200)

TechNet Webcast: Creating and Editing Group Policy Objects (Part 3 of 14) (Level 200)

TechNet Webcast: Managing Group Policy with GPMC (Part 4 of 14) (Level 200)

TechNet Webcast: Managing Group Policy Operations with the GPMC (Part 5 of 14) (Level 200)

TechNet Webcast: Group Policy Processing Behavior Part 1 (Part 6 of 14) (Level 200)

TechNet Webcast: Group Policy Processing Behavior Part 2 (Part 7 of 14) (Level 200)

TechNet Webcast: Group Policy Administrative Templates (Part 8 of 14) (Level 200)

TechNet Webcast: Security with Group Policy (Part 9 of 14) (Level 200)

TechNet Webcast: Group Policy Security Templates and IPSEC (Part 10 of 14) (Level 200)

TechNet Webcast: Designing and Planning Group Policy (Part 11 of 14) (Level 200)

TechNet Webcast: Managing Your Group Policy Environment with GPMC (Part 12 of 14) (Level 200)

TechNet Webcast: Troubleshooting Group Policy (Part 13 of 14) (Level 200)

Exchange 2003 Offline Address books (OAB) Best Practices guide

If you want to know how to deploy and manage OAB's in your organisation, then read this document.  It also has some useful tips on how to automate the deployment of OAB's when you deploy the client along with useful tips on administering the OAB .

Managing Free / Busy Folders and servers in Exchange 2003

I noticed that there has been an addition to the Exchange Technical Documentation library with an explanation of how free/busy data is generated.  It's quite a useful addition to your background reading as I can't find much more on the web about it.  The document includes sections on:

  • How do Exchange clients generate free/busy data?
  • How does Exchange store and distribute the free/busy data, and how can you configure servers to provide free/busy support to your clients most efficiently?
  • How does Exchange maintain free/busy data?
  • If you have multiple Exchange organisations, or an Exchange organisation and a messaging system other than Exchange, how does Exchange replicate free/busy data among them?
  • If users who have delegated access to their mailboxes receive error messages related to calendaring and free/busy data, how can you resolve the situation?

MOM 2005 guides

Although this is not really Exchange related, it is important for most of us since MOM is used to monitor Exchange and AD.

Microsoft Operations Manager 2005 Operations Guide – Now Available

The Microsoft Operations Manager 2005 Operations Guide includes guidance and recommended best practices for backing up and restoring, maintaining, optimizing and monitoring Microsoft Operations Manager 2005 (MOM) in an existing IT infrastructure. This guidance is based on the supported MOM deployment architectures described in the Microsoft Operations Manager 2005 Supported Configurations Guide. Additional instructions are provided for managing agents across multiple domains, across firewalls, across slow links, and in workgroups. Detailed instructions are provided for each of the MOM components: the MOM Database, the Management Server, agents, consoles and the MOM Reporting Database. Detailed information about MOM security-related features and processes are provided in the Microsoft Operations Manager 2005 Security Guide.

Microsoft Operations Manager 2005 Deployment Planning Guide

This guide provides you with a roadmap for developing a deployment plan for your Microsoft Operations Manager 2005 (MOM) monitoring solution. In addition, this guide directs you to the relevant conceptual, security, and planning resources you might need to help you develop a sound deployment strategy.

Nice new Exchange 2003 site

Here is a new independantly run Exchange Server 2003 web site.  It seems to be pretty informative, so check it out.


Monday, December 20, 2004

Listing the file sizes of all Exchange Stores on all Exchange Servers in a Domain V2

Here is an interesting script from Glen's Exchange Dev Blog,  I have used this with a high degree of success. 

[updated fixed new bug when there's more then one mailbox store on a server]

I've had a bit of feedback about the first version of the script that i posted here so I decided to give it a quick revise and add some additional functionality. The additional functionality added to this script is that instead of just returning the size of each store file it also now returns the freespaces left of the disk where the file is located and the percentage of the diskspace that is free. Also there are some fixes for it to allow the script to work when there are more then 1000 mailboxes. I've posted a copy of the new code up here

set conn = createobject("ADODB.Connection")
set com = createobject("ADODB.Command")
Set iAdRootDSE = GetObject("LDAP://RootDSE")
strNameingContext = iAdRootDSE.Get("configurationNamingContext")
rangeStep = 999
lowRange = 0
highRange = lowRange + rangeStep
Conn.Provider = "ADsDSOObject"
Conn.Open "ADs Provider"
mbQuery = "pfQuery = "Com.ActiveConnection = Conn
Com.CommandText = mbQuery
Set Rs = Com.Execute
Wscript.echo "Mailbox Stores"
Wscript.echo
While Not Rs.EOF
objmailstorename = "LDAP://" & Rs.Fields("distinguishedName")
mbnum = 0
quit = false
rangeStep = 999
lowRange = 0
highRange = lowRange + rangeStep
set objmailstore = getObject(objmailstorename)
Do until quit = true
on error resume next
strCommandText = "homeMDBBL;range=" & lowRange & "-" & highRange
objmailstore.GetInfoEx Array(strCommandText), 0
if err.number <> 0 then quit = true
varReports = objmailstore.GetEx("homeMDBBL")
if quit <> true then mbnum = mbnum + ubound(varReports)+1
lowRange = highRange + 1
highRange = lowRange + rangeStep
loop
err.clear
Set fso = CreateObject("Scripting.FileSystemObject")
edbfilespec = "\\" & mid(objmailstore.msExchOwningServer,4,instr(objmailstore.msExchOwningServer,",")-4) & "\" & left(objmailstore.msExchEDBFile,1) & "$" & mid(objmailstore.msExchEDBFile,3,len(objmailstore.msExchEDBFile)-2)
stmfilespec = "\\" & mid(objmailstore.msExchOwningServer,4,instr(objmailstore.msExchOwningServer,",")-4) & "\" & left(objmailstore.msExchSLVFile,1) & "$" & mid(objmailstore.msExchSLVFile,3,len(objmailstore.msExchSLVFile)-2)
Set efile = fso.GetFile(edbfilespec)
set sfile = fso.GetFile(stmfilespec)
edbsize = formatnumber(efile.size/1073741824,2,0,0,0)
stmsize = formatnumber(sfile.size/1073741824,2,0,0,0)
set edrive = fso.GetDrive("\\" & mid(objmailstore.msExchOwningServer,4,instr(objmailstore.msExchOwningServer,",")-4) & "\" & left(objmailstore.msExchEDBFile,1) & "$")
set sdrive = fso.GetDrive("\\" & mid(objmailstore.msExchOwningServer,4,instr(objmailstore.msExchOwningServer,",")-4) & "\" & left(objmailstore.msExchSLVFile,1) & "$")
edbtotalspace = round(edrive.totalsize/1073741824)
edbfreespace = round(edrive.FreeSpace/1073741824)
edbpercentleft = FormatNumber((edbfreespace/edbtotalspace)*100, 0)
stmtotalspace = round(sdrive.totalsize/1073741824)
stmfreespace = round(sdrive.FreeSpace/1073741824)
stmpercentleft = FormatNumber((stmfreespace/stmtotalspace)*100, 0)
Wscript.echo Rs.Fields("name") & "# Mailboxes: " & mbnum & " EDBSize(GB): " & edbsize & " STMSize(GB): " & stmsize
wscript.echo "Freespace on EDB Drive (" & left(objmailstore.msExchEDBFile,1) & ":) :" & edbfreespace & " GB Percent Left :" & edbpercentleft & " %"
wscript.echo "Freespace on STM Drive (" & left(objmailstore.msExchSLVFile,1) & ":) :" & stmfreespace & " GB Percent Left :" & stmpercentleft & " %"
wscript.echo
Rs.MoveNext

Wend
Wscript.echo "Public Folder Stores"
Wscript.echo
Com.CommandText = pfQuery
Set Rs1 = Com.Execute
While Not Rs1.EOF
objmailstorename = "LDAP://" & Rs1.Fields("distinguishedName")
set objmailstore = getObject(objmailstorename)
Set fso = CreateObject("Scripting.FileSystemObject")
edbfilespec = "\\" & mid(objmailstore.msExchOwningServer,4,instr(objmailstore.msExchOwningServer,",")-4) & "\" & left(objmailstore.msExchEDBFile,1) & "$" & mid(objmailstore.msExchEDBFile,3,len(objmailstore.msExchEDBFile)-2)
stmfilespec = "\\" & mid(objmailstore.msExchOwningServer,4,instr(objmailstore.msExchOwningServer,",")-4) & "\" & left(objmailstore.msExchSLVFile,1) & "$" & mid(objmailstore.msExchSLVFile,3,len(objmailstore.msExchSLVFile)-2)
Set efile = fso.GetFile(edbfilespec)
set sfile = fso.GetFile(stmfilespec)
edbsize = formatnumber(efile.size/1073741824,2,0,0,0)
stmsize = formatnumber(sfile.size/1073741824,2,0,0,0)
set edrive = fso.GetDrive("\\" & mid(objmailstore.msExchOwningServer,4,instr(objmailstore.msExchOwningServer,",")-4) & "\" & left(objmailstore.msExchEDBFile,1) & "$")
set sdrive = fso.GetDrive("\\" & mid(objmailstore.msExchOwningServer,4,instr(objmailstore.msExchOwningServer,",")-4) & "\" & left(objmailstore.msExchSLVFile,1) & "$")
edbtotalspace = round(edrive.totalsize/1073741824)
edbfreespace = round(edrive.FreeSpace/1073741824)
edbpercentleft = FormatNumber((edbfreespace/edbtotalspace)*100, 0)
stmtotalspace = round(sdrive.totalsize/1073741824)
stmfreespace = round(sdrive.FreeSpace/1073741824)
stmpercentleft = FormatNumber((stmfreespace/stmtotalspace)*100, 0)
Wscript.echo Rs1.Fields("name") & " EDBSize(GB): " & edbsize & " STMSize(GB): " & stmsize
wscript.echo "Freespace on EDB Drive (" & left(objmailstore.msExchEDBFile,1) & ":) :" & edbfreespace & " GB Percent Left :" & edbpercentleft & " %"
wscript.echo "Freespace on STM Drive (" & left(objmailstore.msExchSLVFile,1) & ":) :" & stmfreespace & " GB Percent Left :" & stmpercentleft & " %"
wscript.echo
Rs1.MoveNext

Wend
Rs.Close
Rs1.close
Conn.Close
Set Rs = Nothing
Set Rs1 = Nothing
Set Com = Nothing
Set Conn = Nothing

Exchange Special Mailboxes Part 1 - System Mailbox

Evan Dodds has done a great job explaining in part 1 the System Mailbox.  For all those curious...

Every now and then, people ask about one (or all) of the system-related mailboxes on Exchange 2003 servers. There are actually three in particular that people frequently notice and confuse: SystemMailbox{guid}, System Attendant Mailbox, and SMTP (servername-{guid}) Mailbox. There are a bunch of common questions, which I will try to address in the next few posts.

 

SystemMailbox{guid}

What is it and what is it used for?

 

In the SystemMailbox{guid} mailbox you can find the following structure:

 

 Private Store - Schema-root Hierarchy

 

and, underneath “Top of Information Store”:

 

 Private Store - Store Events Hierarchy

 

The schema-root hierarchy of folders provide the structure for defining the schema (which is principally stored in the exchangeV1 folder). The StoreEvents hierarchy holds any ExOleDB (“store”) event sinks attached to this mailbox store. Note that MAPI public folder stores also have roughly this same set of folders – one schema-root per hierarchy and a StoreEvents folder for each public folder store, possibly explaining many of those extraneous folders you’ve seen in your NON_IPM_SUBTREE!

 

Where can it be found?

 

There are two parts to each SystemMailbox – the mailbox itself, and an associated directory object. The mailbox object is located in its respective mailbox store. The directory object is located in the Microsoft Exchange System Objects (MESO) folder of the AD, along with all the other public folder and system directory objects. You may have to turn on Advanced view in AD Users and Computers to see this folder at the root of the domain naming context.

 

What is the GUID?

 

The GUID in the SystemMailbox{guid} format is the “objectGUID” of the mailbox store with which this SystemMailbox object is associated. This can be useful to know if you have a couple of different SystemMailbox{guid} directory objects sitting in the MESO container and you want to know which one relates to a particular MDB store.

 

When does it get created?

 

Whenever you mount a mailbox store, one of the checks it runs through is whether or not a SystemMailbox{guid} object is in place. If it can’t find one, it looks in the directory for the SystemMailbox{guid} directory object within the MESO container, and then piggy-backs off that to create the SystemMailbox{guid} mailbox object within the mailbox store.

 

Can it be moved and/or how do I recreate it?

 

There shouldn’t be any need to move it – remember, each MDB has its own GUID associated with a particular instance of SystemMailbox{guid}.

 

Following the train of thought in the “When does it get created?” question, if the directory object is missing, this won’t work and the mailbox object will not be created. In that case, you may want to have a look at KB.316622 which will walk you through recreating this directory object.

 

What happens if I don’t have a proper SystemMailbox{guid}?

 

If you don’t have a fully functioning SystemMailbox{guid} in place, there’s a very good chance EXOLEDB event sinks will not function.

Tuesday, December 14, 2004

Creating an Active Directory Site for Exchange Server

Here is an interesting article on designing Exchange Server 2003 using an AD Site just for it.  A document defining discussion and procedureson how Microsoft IT created a dedicated Active Directory services site to optimize the performance of Exchange Server 2003 is available now.

Explaining Exchange 2003 Http Access (Parts 1 and 2)

 

http://www.msexchange.org/tutorials/Exchange-2003-Http-Access-Part1.html

http://www.msexchange.org/tutorials/Exchange-2003-Http-Access-Part2.html

"Outlook Web Access, Outlook Mobile Access and Exchange ActiveSync all use HTTP methods to access Exchange 2003. This article describes the mechanisms behind these features and explains why the features can sometimes be so awkward to configure."

Achieving High Availability with Exchange Server at Microsoft

 

"Overview of how Microsoft IT used a variety of solutions with Exchange Server 2003, including new server and storage technologies, aggressive service level agreements with weekly performance review meetings, and personnel management, to help achieve 99.99 percent user mailbox availability."

Friday, December 10, 2004

SMTP Session Tarpitting for Windows 2003 and Exchange

 

A common strategy for increasing the cost of would-be mail abuse uses a technique called tarpitting. Mail servers that tarpit wait a specified period of time before issuing SMTP responses to the client, thus increasing the time investment needed to successfully send a large amount of mail or a constant stream of (usually invalid) SMTP commands. To minimize the impact on the performance of well-meaning senders, servers can tarpit responses only for SMTP errors and allow authenticated clients to bypass the tarpit time.

Tarpitting is a useful countermeasure for:

  • Dictionary harvest attacks (where an attacker is trying to compile a list of valid e-mail addresses from your organization)
  • User account attacks (where an attacker repeatedly attempts to authenticate via username/password guessing)
  • Spam scripts that send more invalid than valid e-mail recipients.

Most of these abuses depend on quick SMTP server responses to complete in an acceptable timeframe. SMTP servers that tarpit slow down the amount of work they can do in a given amount of time, thereby making the abuse less enticing or lucrative.

Until recently, there wasn’t a way to enable tarpitting behavior for Windows/Exchange. Now, you can.

Simply install the KB:842851 package. The only requirement is that you’re running Windows Server 2003 with Internet Information Services 6.0. If you’re running Microsoft Exchange, the package automatically integrates with it.

Then, create/set the following registry key:

            HKLM\System\CurrentControlSet\Services\SmtpSvc\Parameters\TarpitTime (DWORD)

The key value is the number of seconds you wish the server to tarpit error responses. You must stop/start the SMTP service for the change to take place.

When used with Microsoft Exchange Server 2003 features like recipient lookup, tarpitting increases the cost of invalid lookups that makes it harder to abuse the feature to launch a dictionary harvest attack.

- Greg Beitler

Cross-AG moves and ADC version upgrades

 

If you've tried to do Exchange 2003 SP1 cross-AG mixed-mode moves, you've (hopefully!) realized that you need to meet a bunch of prereqs before you can proceed. The Site Consolidation Overview KB (KB.843104) lists these various prereqs, but here is the short version again for reference:

The second one has been covered pretty extensively in my earlier blog posting, and the third one is sort of a no-brainer. That leaves the first one: Upgrade your ADCs to SP1.

In the earlier blog posting, I said you had to do this ADC upgrade. But what if you are fairly certain you've upgraded them all and the cross-AG moves are still blocking you with an error message like: "Your organization has at least one Active Directory Connector that is not Exchange 2003 SP1 or later. Cross administrative groups moves will be blocked until all Active Directory Connectors have been upgraded to Exchange 2003 SP1 or later."

Let's talk about what is really being checked during this prerequisite process. First of all, the info we check regarding the ADCs installed and their version may have very little to do with what's really up and running in your environment. This info is all stored in the AD. For example, say you install an ADC on a test server in your production environment and then fdisk this server when you're done. Poof, lingering ADC object in the AD that most likely does not identify itself as an E2k3 SP1 version.

Each ADC defined in the AD is stored at a location like this:

CN=Active Directory Connector (SERVER),CN=Exchange Settings,CN=SERVER,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=DOMAIN

You can find your way to the ADCs defined in your organization by using AD Sites and Services snap-in, or perhaps (and carefully!) with ADSIedit snap-in. But the easiest way may be to use the LDIFDE tool to simply scan the whole configuration naming context for these objects.

Use a syntax like this (you'll have to change the domain info in red for your environment, of course):
LDIFDE -f out.txt -d "cn=configuration,dc=domain,dc=com" -r "(objectClass=msExchActiveDirectoryConnector)" -l versionNumber

This will find all instances of msExchActiveDirectoryConnector objects underneath the configuration container and will return their versionNumber.

In many cases, at this point it'll be very easy to see that this out.txt file lists ADCs that you weren't expecting or that no longer exist. If this is the case, either upgrade them to E2k3 SP1 version or remove them from the AD.

But suppose there are only ADCs at this point that you think have been upgraded. The prerequisite for cross-AG moves checks this versionNumber value to see if it indicates that it's an SP1 version, so here are the two most common versions you'll see listed:

16973842 = Exchange 2003 ADC RTM (initial release of 2003)
16973843 = Exchange 2003 ADC SP1 version

If it's the RTM version, clearly it wasn't upgraded successfully. Have another look at my earlier blog posting to make sure you followed the correct steps. If all of the ADCs listed show the SP1 versionNumber, then you've probably got an AD replication problem and the prereq is talking to a different DC than your LDIFDE process.

Wednesday, December 08, 2004

MSDTC and Exchange clusters

Over the years, the best practice recommendations on where to place the MS Distributed Transaction Coordinator (MSDTC) resource in Exchange cluster has bounced between two differing views. One camp thought it was unadvisable to place this resource in the cluster group occupied by the quorum resource, while others noted that Exchange doesn't really use DTC and its wasteful to dedicate a whole group (with IP and disk) to this resource.


Let's address this from the bottom up:


Why does Clustered Exchange 200x need a MSDTC resource anyways?

Exchange provides support for a workflow function, and this capability is installed on all Exchange 200x servers by the Exchange setup. This functionality is encapsulated in the CDOWFEVT.DLL binary. This workflow functionality requires various components to be registered with COM+ to function. COM+ requires DTC to be running. And on Clustered Windows, DTC won't initialize unless it's configured for the cluster -- ala MSDTC resource. Perhaps this domino-effect failure is familiar, particularly if you've run into the problem described in KB.312316!

So, does Exchange 200x workflow use MSDTC extensively?

Nope. Essentially just for the setup/upgrade steps, particularly if you've not actively implemented workflow applications.

When, then, do some folks recommend to not put MSDTC into the default cluster group?

KB.168948 says pretty clearly not to put anything in the default cluster group that doesn't need to be there. This is a very important group, and anything placed in this group can contribute to lowered availability of the cluster.

But doesn't the old COMCLUST.EXE program put it there automatically?

Yes. Typically. Unless you follow the wacky steps in KB.290624. This is a big part of what leads to this confusion, because in Windows 2003 you don't use Comclust anymore, instead following the steps in KB.301600 so we see lots of variation with customers here based on which method they followed.

Ok, that makes sense... so why do others say DO put it in that group for Exchange 200x clusters?

Here's where it gets interesting. Consider the characteristics of a typical, real-world Exchange 200x cluster server: heavily-loaded, never enough disk spindles, etc. If you follow this path of recommendations, now all of a sudden you need to add AT LEAST one extra IP, one extra network name, and one extra physical disk. Just to support this MSDTC resource that 99% of Exchange clusters only need for setup/upgrade purposes. If you have to choose between allocating this extra disk spindle to an underutilized MSDTC resource or to an underprovisioned database store LUN, most Exchange design architects will choose the second!

Now, here's the meat of this posting: Microsoft has long advocated the first option (dedicated group/disk/etc for MSDTC) as a best practice, since it maintains the cluster group containing the quorum disk untouched. Pretty much all of the documentation and KBs currently state this position. However, after a bunch of internal discussion and debate, this recommendation is about to change and the KB/documentation will be updated shortly.

So, if you have long ignored this recommendation and placed the MSDTC resource in the cluster group containing the quorum... you're fine. Exchange so minimally utilizes DTC that the performance hit and impact to cluster availability are negligible and generally not worth allocating the additional resources. Put that extra disk toward your Exchange data storage instead (see previous postings here, here, and here for more). Additionally, it is recommended that you remove (uncheck) the option to "Affect the Group" from this MSDTC resource, so that if it does ever fail it will not impact the cluster group containing the quorum resource.

Note that this recommendation change does NOT apply if you are running SQL or some other application that utilizes MSDTC extensively. If your MSDTC is being utilized, you definitely still should keep this resource out of the cluster group containing the quorum to avoid any possible negative effect on cluster availability.


ExBPA 1.1 is now out.

ExBPA 1.1 is now out. So what's new with this release?

Here's what Paul Bowden says:
1.1 provides some improvements and refinements to the overall ExBPA experience. There are no major code changes in 1.1, we've focused mainly on usability improvements.

Here's a quick list of the improvements in 1.1:

Installation
  • You can in-place upgrade from 1.0 to 1.1 (i.e. no need to remove previous versions from Add/Remove Programs)
  • You can now specify the data directory (where the output XML files are kept)
  • Ability to launch ExBPA at the end of the MSI install
  • Incorporates the very latest ExBPA.Config.xml (configuration & rules) and ExBPA.chm files (version 1.6.3.1)

Update Checking

  • ExBPA checks to see if a new version of the binaries are available (in addition to the ExBPA.Config.xml file)
  • ExBPA can auto-download new binaries and perform in-place upgrades of the tool
  • There's a new "Cancel this check" option if you wish to bypass update checking
  • Better text and error messages

General

  • Text clean-up in the user interface. Reworded many sentences.
  • Uses a global catalog server rather than domain controller to ensure mailbox count is correct
  • Validation performed on credentials (if entered)

Scan Options

  • You can now enter an identifying label for the scan. This label will be part of the output XML filename as well.

Scan Results

  • More report options providing a better breakdown of items found
  • Non-Default Settings, Recently Changed Settings, and Baseline output is broken out into separate reports
  • 'Items of Interest' report lists out all information events
  • 'Run Time Log' shows the list of events and errors encountered during collection and analysis
  • The 'Tell me more.' links for non-problem events (such as a Non-Default setting) is more appropriate
  • Pressing CTRL-E on a node whilst in the Summary/Detailed View expands all child nodes (NOTE: This option can be resource intensive)
  • Better support for launching non-IE browsers