In the Event log on the server that generates your OAB you may see the following:
Event Type: ErrorEvent Source: MSExchangeSAEvent Category: OAL Generator Event ID: 9325Description:OALGen will skip user entry 'Display Name' in address list '\Global Address List' because the SMTP address '' is invalid. - Default Offline Address List
If you check the user that is mentioned in the event you may find that all of the SMTP proxy addresses look fine on the "E-mail Addresses" tab in Active Directory Users and Computers (ADU&C). However if you look at the "E-mail" field on the "General" tab you may notice that the address there doesn't match the Primary SMTP address on the "E-mail Addresses" tab (the one next to the bold SMTP). These have to match.
About the only place I have found this documented is in the link in the actual event. You know the one that says:
For more information, see Help and Support at:http://go.microsoft.com/fwlink/events.asp
That link will take you to here, where it says:
"This Error event indicates that the user account specified in the event description has not been included in an offline address list because of an incorrectly configured SMTP address. For example, an incorrectly configured SMTP address is an address that contains a dash "-", an underscore "_", or no characters after the @ symbol. Incorrectly configured SMTP addresses can occur in the following circumstances:
A script modified either a user's primary SMTP proxy address attribute or e-mail address attribute. These attributes must match for a user to be added to an offline address list.
An administrator modified the e-mail address of a user on a computer that did not have the Exadmin.dll extensions loaded. "
If you have administrators using ADU&C but don't have the Exchange extensions loaded, then they may think that this is the right place to change someone's email address. If they had the proper extensions this would also change the Primary SMTP address as well, but since they don't... The next time the server generates the OAB, it will skip this user and your users with Outlook 2003 in cached mode may be missing that mailbox.
I'd be remiss if I didn't mention that OABInteg also helps you with this issue. See Dave Goldman's blog for more about that.
Many people are aware of the changes in Exchange 2003 SP2 with the V4 OAB. What many are not aware of are the changes with the other two versions of the OAB, V3a and V2.
Starting with SP2, when a change is done in your environment that would have required a full download of the OAB previously, we now actually throw an event that says:
Event ID : 9360Category : OAL GeneratorSource : MSExchangeSAType : ErrorGenerated : 4/17/2006 10:52:34 AMMachine : ServerNameMessage : OALGen encountered an error while generating the changes.oab file for version 2 and 3 differential downloads of address list '\Global Address List'. The offline address list has not been updated so clients will not be able to download the current set of changes. Check other logged events to find the cause of this error.
If the cause of the problem was intentional or cannot be resolved, OALGen can be forced to post a full offline address list by creating the DWORD registry key 'HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeSA\Parameters\OAL post full if diff fails' and setting it to 1 on this server. When OALGen next generates the offline address list, clients will perform a full OAB download. After that time, the registry key should be removed to prevent further full downloads.
- Default Offline Address List
Read that error again... It is telling you that the server has stopped generating OAB for those older versions. So your clients that are not running Outlook 2003 SP2 and that are using OSTs will probably give an error when trying to download the OAB.
The good news is that prior to that error we throw another event that explains what happened. For instance you may see the following:
Event ID : 9340Category : OAL GeneratorSource : MSExchangeSAType : WarningGenerated : 4/17/2006 10:52:34 AMMachine : ServerNameMessage : A new parent Legacy Exchange DN container value '/o=Organization/ou=Site/cn=NewRecipientsContainer' was found during generation of the differential update file for offline address list '\Global Address List'. This will force clients using this offline address list to do a full download of the offline address list.
Now this is useful. If I go to that site I may find a recipient container that is not needed and I could remove that container. Or perhaps it is an X500 address that was added with a typo to a mailbox. I can fix that and then next time the OAB generation run we should be fine.
For more information regarding this, look at Dave Goldman's blog. It is kind of deep, but if you take the time to read it, you will learn a lot.
I gave some thought to some of the issues you might experience after a cross-site move of mailboxes.
The main thing is that you must either recreate the profile or run the Exchange Profile Update Tool (ExProfRe.exe). Just putting changing the name of the server in the profile is not enough.
Please take a look at the information found at:873214 The Exchange Profile Update toolhttp://support.microsoft.com/default.aspx?scid=kb;EN-US;873214
The first sentences of the article pretty much spells it out:
“After you move a mailbox across an administrative group, any Microsoft Outlook profiles that were in use for this mailbox no longer function correctly. Mailbox servers can refer Outlook to the correct server after mailboxes have been moved within an administrative group, but this process does not work correctly for mailboxes that are moved across an administrative group. Security settings for e-mail messages, calendaring, free and busy information, public folder moderation, and delegation may not work. You must update the profile for 100 percent functionality after such a move.”
More information can be found at:838235 TechNet Support WebCast: Mixed-mode site consolidation in Microsoft Exchange Server 2003 Service Pack 1http://support.microsoft.com/default.aspx?scid=kb;EN-US;838235The transcript of this presentation is available for those who would rather read it.
In that transcript it says:
"... when we move mailboxes cross-site we're actually eliminating the object that represents the mailbox in 5.5 and creating a new object in a different site. So if you don't run that Exchange Profile Redirector Tool, the profile on your Outlook client will then still believe that it is associated with the distinguished name of the source site mailbox, meaning that the profile will make assumptions about who it actually is. Even though you can get into your mail after you do a cross-site move, and you can even send and receive mail after a cross-site move without running that Exchange Profile Redirector, if you don't run the Exchange Profile Redirector you'll have weird little issues going on because we will make assumptions about who we are that will be incorrect. So you need to run that Profile Redirector Tool. "
Under the heading of: "You may already be aware of this, but we wanted to make sure..."
Some of our customers are having issues with permissions since they have upgraded to Exchange 2003 SP2 and a hotfix that makes the store.exe version 7650.23 or higher. I wanted to make sure that you were aware of some resources that are available to help you, in case you run across this.
What is the issue? The introduction here explains it well:
"In the past, additional accounts could be granted the "Full Mailbox Access" permission to a mailbox and these accounts could then send mail as the mailbox owner. From now on, the "Send As" permission must be explicitly granted to additional accounts or they will not be able to send mail as the mailbox owner. "
We recently updated the KB article that addresses this issue.
In the KB article we now include a script that will let you know which accounts in the organization have "Full Mailbox Access" permissions, but not "Send As" permissions. The script has three modes: Export – this tell you the accounts that have "Full Mailbox Access", but not "Send As" permissions. Import – This allows you to modify a list so that certain accounts that have "Full Mailbox Access" will get "Send As" permissions as well. SetAll – This automatically sets all accounts with "Full Mailbox Access" to have "Send As" permissions as well. Now you know... Again... :) Update: Post SP2 hotfix and formatting.
In the KB article we now include a script that will let you know which accounts in the organization have "Full Mailbox Access" permissions, but not "Send As" permissions.
The script has three modes:
Now you know... Again... :)
Well it is officially public now. The name is Exchange Server 2007. http://www.microsoft.com/exchange/preview/default.mspx
And Vivek also is telling us that Monad is now called PowerShell.The downloads also have been updated to show this.