Evan Dodds - Microsoft Exchange Server Blog : Exchange 2003 SP1

Using PowerShell + WMI to manage legacy Exchange

evand — Mon, 10 Sep 2007 17:44:00 GMT

Dmitry blogs all about it here. I'd been meaning to write pretty much this very same post ever since I attended Devin's talk on managing Legacy Exchange with PowerShell at ExchangeConnections ~~last November~~ this past April, so I'm glad to see Dmitry write it up!

How to find out which users have the Junk E-mail rule enabled

evand — Sat, 01 Apr 2006 01:14:00 GMT

I received an email the other day from someone who had read my “IMF and the Junk E-Mail folder in Outlook” posting. This person was wondering: “How can I tell who does and doesn’t have this per-mailbox setting enabled?” and I replied that there’s no built-in way that I know of and that you’d probably have to write another script to check for it.

Well, either this person also had asked Glen (the author of the original DAV-based script) directly, or it’s a crazy coincidence… because just a day or so later, Glen had posted this script, which will get that information for you.

Bravo Glen, and thanks!

Can't run Exdeploy after installing W2k3 SP1?

evand — Mon, 04 Jul 2005 19:56:00 GMT

Here’s an interesting problem: After you apply Windows 2003 SP1, the new security settings prevent running HTA files from a network share. So this means if you download the Exdeploy pack and dump it into a network share, it won’t work properly on a W2k3 SP1 server.

The workaround, of course, is to put the files locally on the W2k3 SP1 server.

Seems to me that people most affected by this should be those who are doing cross-site mailbox moves, since anyone doing a regular in-place upgrade from Exchange 2000–>2003 wouldn’t yet be running the server on Windows 2003 SP1.

See KB.897340 for more info.

Cross-site moves: The importance of proper ADC Connection Agreements

evand — Tue, 24 May 2005 19:42:00 GMT

It’s now been about a year since Exchange 2003 SP1 released, and cross-site, mixed-mode mailbox moves were introduced. In that time, I think folks have really started to get the hang of how it works and what needs to be in place to ensure successful moves.

That said, there’s one topic that I’ve seen popping up more and more frequently over the past few months (perhaps it’s just because some of the other common questions are starting to recede in volume as more and more documentation hits the web).

“Why won’t my stub objects go away?” (or its close cousin — “why do I keep getting NDRs long after I moved the mailbox?”)

Ok, so you might say “hey Evan, didn’t you already cover that in this post”

Yup. That post covers the under-the-hood details of the move, and will probably help you understand where the process is breaking down. Have a look at it if you haven’t yet.

But, I’ve had it brought to my attention that there’s one area of this post that I might not have emphasized enough: You Have To Have The Proper Connection Agreements In Place!

Almost every step in the cross-site, mixed-mode mailbox move process relys on the proper ADC connection agreements being there. The Exchange Deployment tools (download here) guide you through the whole process, and actually have you run the “ADCTools” to create and confirm the proper CAs several times during the process.

This is very important. If you don’t have the proper ADC Connection Agreements in place, you will run into very weird “blocking” problems where objects don’t get created/deleted/updated, etc.

One specific case I’ve had brought to my attention is the scenario described in KB.888032. This is the case where you have a “pure” Exchange 2003 site (ie - a site with only E2k3 in it, no 5.5… no SRS). In this scenario, another site has an SRS that “owns” this pure E2k3 site. Various updates for the “5.5 view” of this pure E2k3 site have to be handled by this particular “owning” SRS. But since it’s a “pure E2k3” site, it’s really quite easy to forget that even this site needs to have a CA too (and that it needs to point to this SRS in another site.. an altogether confusing situation for most people!)

So, in summary, if you’re running into problems with the “transition” part of your cross-site, mixed-mode mailbox moves, I suggest you start with the following:
1) Have a look through my original detailed process post and see where you’re getting stuck.
2) Make sure you’ve run the ADCTools and/or confirmed your CAs are correct
3) Have a look through KB.888032 to make sure it’s not the issue you’re hitting

Hotfix for E2k3 on W2k3 SP1 cluster

evand — Wed, 30 Mar 2005 18:40:00 GMT

Gerod points out in this blog post that if you install Windows 2003 SP1 onto your Exchange 2003 cluster nodes, you’ll need to install the hotfix in KB.841561.

If you don’t apply this hotfix, users will not be able to access OWA (they will receive 500 – internal server error), although Administrator accounts will be successful in accessing OWA.

If this scenario applies to you, double-check if the hotfix is available for download from the KB.841561 link — it’s not linked for download today — and if not, call PSS and request the KB.841561 hotfix. Requesting a specific hotfix from PSS is a no-charge call.

Updated 4/1/2005 (not an April fools prank): The hotfix download for KB.841561 is now linked from the KB article, or you can download it directly at this link. Note that this hotfix is for servers running Exchange 2003 SP1. If you can’t upgrade your server from Exchange 2003 RTM to Exchange 2003 SP1, you need to get the hotfix in KB.841560.

Funky mail routing after cross-site mailbox moves

evand — Thu, 17 Mar 2005 16:07:00 GMT

When you move mailboxes across mixed-mode site boundaries with the Exchange 2003 SP1 feature, there is a period of time where mail will have trouble routing properly to these moved mailboxes. There are a couple of ways you may see this presented, as I’ll discuss in this post.

The most common case is the Non Delivery Report (NDR) scenario. That is to say that after you move a user’s mailbox across administrative group boundaries in mixed mode, mail sent to this user may be returned non deliverable. This is discussed in KB.841659. The short explanation is that:

Mailbox is moved from Site1 to Site2 (so the data is now in Site2, not Site1)
5.5 directory in Site1 is updated to make the original mailbox a “stub” object which cannot receive email
AD is updated to reflect that the object exists in Site2
5.5 directory in Site2 is not updated until ADC replicates from AD->Site2 (so there is not yet a directory object for the mailbox in the Site2 5.5–world)

While we’re in this transitioning phase, if someone on a 5.5 server tries to send to the moved mailbox the 5.5 directory will be referenced. The 5.5 directory is not completely updated at this point, so the message will eventually hit a 5.5 server that doesn’t know how to deliver mail to this mailbox object (for instance, the 5.5 directory in Site2 hasn’t yet had the ADC create the new object, so it has no knowledge of this mailbox from a directory perspective).

This happens right up until the ADC replicates, directory replication completes, and the stub object is removed – see this post for more details on this process.

There’s also another scenario I’ve seen that has slightly different results. The scenario is that you have no RPC connectivity between the server that is the source of the move and the server that is the target of the mailbox move. A common way this may be the case is for the two sites to be connected by X400 connectors, and not share a common service account.

During the mailbox move (as in all mailbox moves, see my EHLO post for more info), the PR_IN_TRANSIT property is set on the mailbox to prevent new messages delivering to the mailbox while it is moving. In most cases, the source of the mailbox move is a 5.5 server, so when the move completes, any messages that had queued up during the move are released back into the MTA for delivery.

The MTA isn’t really smart about cross-site mailbox moves, so it makes the assumption that (of course) the target of the mailbox move has to be in the same site, which means that (of course) we will have RPC connectivity to the server where the mailbox now resides.

Except in the scenario I’ve described above. With X400 connectors and no shared service-account, there’s no guarantee we’ll be able to make an RPC connection to the destination server. Enter the problem: The MTA short-cuts the mail routing, and just drops these queued messages into an RPC queue, destined for the servername of the destination server. The typical symptom is that you’ll see a mail queue on the source 5.5 server destined for the (netbios) name of the target server with queued items in it, even though new mail destined for this target server is flowing just fine across the appropriate connector. You may also see events logged from the MTA indicating a failure to connect to the server in the other site.

This doesn’t affect all environments, as RPC connections are often possible between sites. If you have a site connector between the sites, this behavior is totally transparent and the mail will route just fine. That’s the suggested workaround – just create (even temporarily) a site connector between the two sites so that these mail items can drain out of the queue and deliver.

Couple of Interesting KBs

evand — Wed, 16 Mar 2005 20:14:00 GMT

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

KB.884863 (http://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 (http://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 (http://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 (http://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.

Hotfix for scripted cross-site mixed-mode moves!

evand — Fri, 04 Feb 2005 18:46:00 GMT

Thanks to Dave Howe for pointing out this newly released hotfix. With the release of KB.883652, it’s now possible to script cross-site mixed-mode moves based on the Exchange 2003 SP1 feature. Before applying this hotfix, if you are doing scripted moves with the MoveMailbox method of the IMailboxStore interface and you select a destination in a different site you will get an error like:

This mailbox cannot be moved to a different Exchange Server 2003 administrative group while in a mixed Exchange 5.5/Exchange Server 2003 Organization.
Error code: -1056749031

With the hotfix in place, a new parameter (FCrossAG) is exposed that allows you to specify that the move should be cross-site. Also included with this hotfix is exposure of a parameter that allows you to control the Skip Bad Items feature of Exchange 2003 mailbox moves (IMaxBadItemsToSkip).

Please see KB.883652 for more detail on how to use these changes and download the hotfix here.

Updated IMF filter released today!

evand — Thu, 03 Feb 2005 01:36:00 GMT

Hot off the presses, there’s a filter update for the Exchange Intelligent Message Filter that released today. You can download this updated filter at: http://www.microsoft.com/downloads/details.aspx?familyid=c1ea8cf1-48c9-4e43-a4eb-82d9a83fd4a7&displaylang=en. See the Readme for more info.

IMF and the Junk E-mail folder in Outlook

evand — Mon, 31 Jan 2005 21:39:00 GMT

I’ve posted several IMF-related blog postings in the past — here, here, and here. In these posts, I’ve focused mainly on the gateway behavior of the IMF. This is because that’s really what the IMF is, of course… just the gateway behavior. But when your mailbox server is running Exchange 2003 or better, there’s a whole different angle to consider: Store behavior.

As I’d mentioned, through the IMF UI in ESM, you can set the Store Action Threshold. This sets a value in the AD that is read by the Information Store on Exchange 2003 (or newer) and controls the server-side Junk E-mail folder behavior. What this means is that if the mail makes it to the Store (ie – is not stopped by IMF at the gateway), it will have an SCL stamped on it. The Exchange 2003 Information Store will detect that there is an SCL value associated with the message. The store will then make a determination on whether or not the message SCL value means it needs to be moved into the mailbox’s Junk E-mail folder.

Important to note that this IMF/SCL related Store Action is totally separate from and unrelated to the Outlook client-side Junk E-mail evaluation. It’s a bit of a confusing interaction, but they really are separate. Even if you never log onto your mailbox with Outlook 2003 in cached mode and set the Junk E-mail options to be enabled, you can still have the Exchange Junk E-mail processing move messages to the Junk E-mail folder. There’s a bit more information on Outlook 2003 client-side Junk E-mail behavior in KB.842510.

Bonus: Outlook doesn’t use the IMF provided SCL values for its client-side (cached-mode only) anti-spam determination. Instead, it does its own Junk E-mail evaluation and determines whether or not to move the mail to the Junk E-mail folder based on the settings within the “Tools->Options” Junk E-mail settings.

“Low” setting corresponds to approximately a store action threshold of 6 (ie – it will move messages with SCL or 6 or higher to the Junk E-mail folder).
“High” setting is more aggressive and corresponds to an SCL of between 4 and 5 (ie – it will move messages with SCL greater than somewhere between 4 and 5 to the Junk E-mail folder). Note that there’s not a 1:1 mapping between the four settings in Outlook Junk E-mail behavior and IMF SCLs, so that’s why impacted SCL values are “somewhere between 4 and 5” for Outlook.

Back to the StoreActionThreshold, much of the confusion I see in this area is around what has to be done to get the server-side Junk email processing to work. It’s important to understand that there is actually another requirement that has to be taken into account here. It’s not just the server realizing that the message processed by IMF has a particular SCL and moving it to the Junk E-mail folder… there actually has to be a special rule in place within each mailbox to make this move happen. The rule is made up of information about your junk email settings, safe senders, etc..

Now we’ve established that in order for the Store Action to work properly, you need to have both Exchange 2003 (or better) Information Store that knows to read the StoreActionThreshold value from the AD and ALSO a special rule set in the mailbox to tell the store how to process the Junk E-mail. That’s where most people run into trouble, and why sometimes it seems to work and sometimes it doesn’t. It’s all about how this special rule gets set (or doesn’t)!

If you fire up Outlook 2003 in cached mode, it will set this special rule in your mailbox automatically.
If you fire up Outlook 2003 in online mode, it will NOT automatically set this special rule, although you can go into the Tools->Options dialog and change the Junk E-mail configuration to ensure it is set.
If you fire up Outlook Web Access (OWA) 2003 and go into the Options page, you can check the checkbox to “Filter Junk E-mail”, which creates the special rule.

So, in short, if you’re not having all of your users login to the server with Outlook 2003 in cached mode already, the rule probably isn’t already created and won’t be automatically created just because you implement IMF.

What to do? If you’re not using Outlook 2003 or if you only have a handful of users affected by this behavior, the best option is probably to go into the affected mailboxes (or have the end-user do it) with OWA2003 and set the Filter Junk E-mail checkbox. This will set the special rule in the mailbox, and Junk E-mail folder will begin to function.

But what if you have a BUNCH of mailboxes to set this on? Unfortunately, there’s no built-in way to bulk set this rule on each mailbox directly. But one of my Microsoft colleagues (Jerry Wang) put together a VBScript that will automate the process of spinning through the mailbox in OWA and setting up the special rule. This script was subsequently modified a bit by Xavier Coppin to make it work in more end-user cases. Some credit also belongs with Glen who posted some of these details back in December: http://gsexdev.blogspot.com/2004/12/setting-outlook-2003-junk-email.html. This script might be useful if you’ve a need to set this on a large number of mailboxes. This script comes with no warranty, etc and please review it before you use it, and of course you use it at your own risk!

You feed this script a file containing a list of mailboxes (alias or SMTP address), one per line. If you can’t connect to the mailbox OWA with /exchange//">http://<servername>/exchange/<line-from-the-input-file>/ it won’t work, so construct the input file accordingly and change the strURL value in the script if you need to adjust the URL. The script will prompt for the server, username, password, etc if you don’t provide them according to the usage: cscript JunkEnable.vbs servername domain\user <file name> [Password]

SCRIPT UPDATED Feb 8, 2005

'=======================================================================
' Microsoft provides programming examples for illustration only,
' without warranty either expressed or implied, including, but
' not limited to, the implied warranties of merchantability
' and/or fitness for a particular purpose. This article assumes
' that you are familiar with the programming language being
' demonstrated and the tools used to create and debug procedures.
' Microsoft support professionals can help explain the functionality
' of a particular procedure, but they will not modify these examples
' to provide added functionality or construct procedures to meet your
' specific needs. If you have limited programming experience, you may
' want to contact a Microsoft Certified Partner or the Microsoft fee-based
' consulting line at (800) 936-5200. For more information about Microsoft
' Certified Partners, please visit the following Microsoft Web site:
' http://www.microsoft.com/partner/referral/
'=======================================================================

'==========================================================================
' VBScript Source File
'
' NAME: JunkEnable.vbs
'
' AUTHOR: Xavier Coppin (http://xavblog.net/)
' DATE : 8/Feb/2005
'
' COMMENTS:
' Enable Junk Email filter at mailbox level
'==========================================================================

Option Explicit
'==========================================
Dim ServerName, AdminUserName, Password, oArgs, ArgNumber, TextFileName
Set oArgs = Wscript.Arguments
ArgNumber=CInt(oArgs.Count)
If ArgNumber > 0 Then
If oArgs(0)="/?" Or oArgs(0)="?" Then
Usage()
End If
End If
'WScript.echo "oArgs.count=" & oArgs.count
If ArgNumber < 1 Then
ServerName=InputBox("Can you please enter the Exchange Back-End server name ?","ServerName","ServerName")
Else
ServerName=oArgs(0)
End If
If ArgNumber < 2 Then
AdminUserName=InputBox("Can you please enter an Exchange Administrator account name ?","AdminUserName","DOMAIN\USERNAME")
Else
AdminUserName=oArgs(1)
End If
If ArgNumber < 3 Then
TextFileName=InputBox("Can you please enter the name of the plain text file ?","Text File Name")
Else
TextFileName=oArgs(2)
End If
If ArgNumber < 4 Then
Password=InputBox("Can you please enter the Password of " & AdminUserName,"Password")
Else
Password=oArgs(3)
End If
Dim oFileObject, oLog
Dim strLine,strURL
Set oFileObject = CreateObject("Scripting.FileSystemObject")
Set oLog = oFileObject.OpenTextFile(TextFileName,1)
Do Until oLog.AtEndOfStream
strLine = oLog.ReadLine
strLine = Trim(strLine)
strURL = "HTTP://" & ServerName & "/Exchange/" & strLine
ForceJunkEmailFolder strURL, AdminUserName, Password
Loop
oLog.Close
Set oLog = Nothing
Set oFileObject = Nothing

'==========================================
' Print the usage
'==========================================
Public Sub Usage()
WScript.Echo "Usage:"
WScript.Echo "Enable Filter Junk Email at mailbox level ."
WScript.Echo " cscript JunkEnable.vbs servername domain\user <file name> [Password]"
WScript.Quit 0
End Sub

'==========================================
'Logon to specified mailbox by OWA
'==========================================
Public Sub ForceJunkEmailFolder(strURL,strUserName,strPassword)
On Error Resume Next
Dim XmlHttpStr, ObjXmlHttp
Set ObjXmlHttp = CreateObject("Microsoft.XMLHTTP")
XmlHttpStr = ""
xmlHttpStr = xmlHttpStr & "Cmd=options" & vbLf
xmlHttpStr = xmlHttpStr & "junkemailstate=1" & vbLf
XmlHttpStr = XmlHttpStr & "cmd=savejunkemailrule" & vbLf
ObjXmlHttp.Open "POST", strURL,false,strUserName,strPassword
ObjXmlHttp.SetRequestHeader "Accept-Language","en-us"
ObjXmlHttp.SetRequestHeader "Cache-Control","no-cache"
ObjxmlHttp.setRequestHeader "Content-type:","application/x-www-UTF8-encoded"
ObjxmlHttp.setRequestHeader "Content-Length:", Len(XmlHttpStr)
ObjXmlHttp.SetRequestHeader "Accept", "*.*"
ObjXmlHttp.Send XmlHttpStr
If Err <> 0 Then
WScript.Echo "Filter Junk Email failed at " & strURL & " Failed!"
WScript.Echo "Error number" & Err.Number
WScript.Echo "Description : " & Err.Description
Exit Sub
End If

If ObjXmlHttp.Status <> 200 Then
Wscript.Echo "Filter Junk Email failed at " & strURL & " Failed!"
WScript.Echo "Http status code =" & ObjXmlHttp.status
Elseif ObjXmlHttp.responsetext <> "" Then
     WScript.Echo "It seems an error occured during the Send Command. Are you sure you have the correct permissions on this mailbox ?"
     WScript.Echo "Response of the server was " & ObjXmlHttp.responsetext
Else
    WScript.Echo "Filter Junk Email enabled for mailbox " & strURL
End If

Set ObjXmlHttpStr = nothing
End Sub

More DS/IS prerequisite validation info for cross-site, Exchange mixed mode mailbox moves

evand — Tue, 25 Jan 2005 18:24:00 GMT

Back in July of last year, I posted about how the DS/IS hotfix prereq check works and why you need to apply it. Since that time, I’ve run into one other item I wanted to talk about in the process that I didn’t provide enough detail on in the original post.

Here’s a recap of the “check for the DS/IS hotfix” prereq steps from the earlier blog post:

How we check for the DS/IS hotfix during cross-site moves:
When moving mailboxes or DLs cross site, the tools check to see if the hotfix has been applied to ALL 5.5 servers that have a public folder store. The move mailbox GUI is even nice enough to provide a list of servers where it doesn't believe the hotfix has been applied. So what do you do when you are POSITIVE that you've applied the hotfix to the “EXMAIL4” server, but the GUI says it's not? Why does this happen?

The process to check for the DS/IS hotfix is roughly as follows:

Figure out what our target site is -- what site are we moving the mailbox (or DL) to? For the sake of example, let's say we're moving the mailbox from “Site1“ to “Site2“.
Look through the list of Config_CAs to see which one “owns“ this naming context. One of the Config_CAs will have this site listed in msExchServer2ExportContainers, and this is the Config_CA (and therefore the SRS) that owns this 5.5 site.
Open a connection to this SRS. If the SRS is offline or unavailable, we're done here and the prereq fails.
Query the SRS for a list of all 5.5 servers that have a public folder store defined.
Scan the list of 5.5 servers for the heuristics attribute on each server object. If the server object in this SRS directory doesn't have the proper heuristics attribute (to indicate that the hotfix has been applied), we fail the prereq.

And that's it; if we DO have the proper heuristics attribute stamped on all of the servers in our query, we pass the prereq test and move on.

Notice in Step #3, “Open a connection to this SRS” is sort of undefined. After Step #2, we’ve determined which SRS owns the site which is the target of the move. But if we try to open a connection to this SRS and fail to connect it for some reason, what happens?

Well, a very common error code to see in this case is: “Unable to find a responsive Exchange 5.5 server in the specified site. ID NO c1034a34”. This error is somewhat misleading because we’re not REALLY trying to find a responsive Exchange 5.5 server, but rather, an SRS that acts just like an Exchange 5.5 directory.

If you run into this error, it means that the Exchange System Manager UI was unable to connect to the particular SRS that owns the naming context of the target site. You will probably need to confirm that this SRS is running, that there’s no firewalls blocking RPC communication between the ESM GUI and the SRS, etc. If you cannot connect to this SRS directory with 5.5 Admin from the machine running the ESM GUI, it is unlikely that the ESM GUI will be able to connect to do the prerequisite check!

But let’s go back even one step more. What if you are trying to run through the prereq check yourself, manually, and you can’t find the proper Config_CA listed in Step #2? If you’re using the ADC management UI to go through each listed Config_CA, it’s possible the Config_CA you’re looking for is not listed!

Each connection agreement is associated with one-and-only-one ADC server. There’s an attribute called msExchHomeSyncService stored on each connection agreement to link that connection agreement back to its owning ADC. It’s this association that causes each connection agreement to be listed subordinate to a particular ADC server in the ADC management GUI.

Here’s where it gets a little dicey. If you remove the ADC service from a server while it still has connection agreements associated with it, these connection agreements will become unassociated with *ANY* ADC server… they become “orphaned”, essentially. If you look at the msExchHomeSyncService attribute on such a CA, it will be blank. This means when you look through the list of all CAs in the ADC management GUI, you will not even see this CA listed. There’s a bit more info on this whole situation and how to recover from it in KB.319486.

Note that if you end up with the owning SRS for the target site as an orphaned SRS, you have bigger problems than the failure of the DS/IS prereq check! You will definitely want to clean up the ADC to make sure all connection agreements are properly in place, and that all SRS replication functionality is restored before attempting to move mailboxes cross site! Be sure to carefully follow the steps in KB.319486 and maybe rerun the ADC Tools (in the ADC management GUI) for good measure before attempting such moves.

I installed the roll-up, why does it still say I'm running SP3?!

evand — Wed, 05 Jan 2005 21:57:00 GMT

Ok, so that title sort of says it all. You’ll find that installing a roll-up hotfix onto an Exchange 2000 or 2003 server may not update the display in the Exchange System Manager to reflect the new version. So what’s really going on?

For example, an Exchange 2000 SP3 server is going to display itself as 6249.4 in ESM:

If you upgrade it with the latest post-SP3 E2k roll-up (currently the August 2004 “6603” roll-up available at KB.870540), you will find that it still shows as 6249.4 rather than as 6603.1, the updated version.

When do we expect the version # to update in ESM?

The only time you’re going to see the version number update in ESM is if it’s a major version update (like going from Exchange 2000 -> 2003) or if it’s a service pack update. The one exception to this is that some of the earlier roll-up hotfixes post-Exchange2000SP3 would update the version number in ESM when applied to Clustered Exchange

Why does it get updated in ESM?

In order for the ESM version number display to be updated, a few things have to happen:

The hotfix has to include the EXSETDATA.DLL file
The hotfix has to be applied on a clustered Exchange 200x machine

If you meet both of those criteria, you’ll see the version number bump up in ESM to whatever version is associated with the EXSETDATA.DLL file. If you fail either of these criteria, the version number in ESM will be untouched.

That begs the question “why does it only happen on clusters?”:

Exchange clusters undergo a slightly different process than do non-clustered Exchange servers when you do a service pack upgrade. In fact, Exchange 2000 clusters run back through a bunch of the “initial setup” code instead of sticking just to the “upgrade” code.

This will be familiar if you’ve ever done an Exchange 2000 service pack upgrade on cluster. Generally, it’s done in a rolling-upgrade fashion:

Move EVS to active node (let’s call it node1)
Install SP binaries on passive node (call it node2)
Reboot node2 and move EVS over to the upgraded node
<After EVS comes online on upgraded node2, the actual SP upgrade happens to the databases, etc>
If everything comes online on the upgraded node2, you’ve upgraded to the SP successfully!
Complete the process by installing SP binaries on node1 and reboot

Note that moving the EVS to the node with upgraded binaries is where the actual service pack upgrade work takes place behind the scenes. If the upgrade fails at that stage, you’re still able to run the EVS on the non-upgraded binaries of node1. If it succeeds at that stage, you’ll want to finish it off by upgrading the remaining node(s). It’s during the process of upgrading the EVS to match the upgraded binaries on the node that the “setup” code is run to do the upgrade, and this is the code that updates the version number in ESM.

Exchange 2003 is a little different, as the upgrade/setup stuff doesn’t happen automatically when you bring the EVS online any longer (see KB.867624 for more detail on the Ex2003–>Ex2003SP1 upgrade process). In Exchange 2003, you have to tell the cluster (in CluAdmin) to “Upgrade Virtual Server”, at which point just about everything else is the same as in the Exchange 2000 upgrade case.

Perhaps an even better question then is “why DOESN’T it happen on non-clusters!?”:

Since there is separate “setup” and “upgrade” code — and the setup code touches this version number while the upgrade code does not — hotfix applications on non-clustered Exchange servers will not touch the version number, even if there is an updated EXSETDATA.DLL file in the hotfix. This is a shame, as it makes it a bit harder to tell whether hotfixes have been applied to your Exchange servers.

Well, if it doesn’t always update in ESM, how can you tell if the hotfix has been properly applied?

You can choose from several great ways to tell what version/hotfix you’re running:

Run ExBPA (http://www.microsoft.com/exchange/exbpa/)
Check in Add/Remove programs and/or the registry
Check the actual file versions

Run ExBPA

By far, the easiest way to check if you’ve got the latest Exchange hotfix roll-up is to run the ExBPA “Best Practices Analyzer” program against your server or your whole organization. It’ll check whatever scope of servers you select and will tell you (from its frequently updated ruleset) whether or not you’ve got the latest roll-up on each of your servers. Very cool tool. You want to run it. http://www.microsoft.com/exchange/exbpa/

Add/Remove and/or the registry:

Anytime you add an Exchange 200x hotfix to your server, it’ll be logged in the Add/Remove programs dialog so you can visually inspect that location to see if your particular hotfix is listed. Alternately, all of the hotfixes are also listed in the registry at location by KB number:

HKLM\Software\Microsoft\Updates\Exchange Server 200x\SP#\KB######
(substitute the right Exchange version, service pack #, and KB #)

Check the actual file versions:

It’s a bit arduous, particularly if you want to be thorough and check each and every file in the hotfix. In many cases, you can get away with checking only one or two of the main updated files (say “store.exe” or “mad.exe”) to make sure they have the latest file version.

But if you want to check all the files you can certainly do it. Each hotfix KB article (see KB.870540, for instance) lists all of the updated files along with their respective updated file version. You can find each file on your Exchange server, pull up properties, and then compare the listed version in the KB with the listed version on the file itself. The biggest benefit of this method is that once you’ve gone through and checked each and every file, you know 100% that the hotfix is completely applied to the server. But I certainly don’t envy you the task of checking 150 file versions!

MichaelP actually pointed me to a slightly easier way if you want to scan through all the files manually. Here are the steps:

Open up Windows Explorer
Browse to the folder/directory where the files were installed (i.e., C:\Program Files\Exchsrv\Bin)
Set the Windows Explorer View to “Details” (View > Details)
Right-click anywhere on the existing column headers and choose “More…”
A “Choose Details” dialog window should appear… find “Module Version” and check its box.
Click the OK button.

Now all of the binaries should be displayed with their file version in Windows Explorer (sample below).

KB.841765 Ex55 Post-Sp4 hotfix re-released

evand — Fri, 17 Dec 2004 05:03:00 GMT

The "Exchange 5.5 Post-SP4 Rollup" (KB.841765) containing the DS/IS Hotfix required for Exchange 2003 SP1 Site Consolidation work (see my earlier posting) has been updated as of December 16, 2004. If you've been looking for it, you can now download the updated version here.

Evan gets a mention in Redmond Mag

evand — Tue, 14 Dec 2004 05:08:00 GMT

Wow, this is a pretty cool scenario. I'm sitting on a plane, diligently reading my December 2004 Redmond Magazine. I flip the page and there's an article on Exchange 2003 consolidation. Here's where it gets good...

Reading through the article by Bill Boswell, I think to myself - "wow, this sure sounds a lot like the Exchange 2003 SP1 site consolidation training and KB articles I wrote, plus it also really relates to the stuff I've posted to the blog since SP1 release".

And then, at the very end of the article, Contributing Editor Bill Boswell highly recommends one of my KB articles and the cross-site mailbox migration webcast I did last summer. Sweet.

Read the whole article starting page 45 in the magazine or online at: http://redmondmag.com/features/article.asp?editorialsid=449

Cross-AG moves and ADC version upgrades

evand — Mon, 22 Nov 2004 20:31:00 GMT

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:

Upgrade all ADCs to Exchange 2003 SP1 (earlier blog posting)
Apply DS/IS hotfix to all 5.5 (KB.841765 and earlier blog posting)
Ensure your "target" server is running Exchange 2003 SP1

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.