By popular demand and since many of you requested this: I’ve put the Visio file of the Exchange 2010 SP1 Network Ports Diagram online. The original post in PDF format is of April 5th.
If you got any comments or additions worth sharing, do not hesitate to write ’em down in the comments or send me an e-mail. When used, crediting or a reference is appreciated.
The Visio document can be downloaded from here.
A customer who recently migrated to Exchange 2010 and was still in the co-existence setup with Exchange 2003, reported lots of users experiencing issues with regards to Free/Busy information. Symptoms were inaccurate or missing Free/Busy information, which especially gets annoying when scheduling appointments.
It turned out these users were using Outlook 2003; users on Outlook 2007 or later experienced no issues. As you probably know, Outlook 2003 still utilizes public folders to publish users’ Free/Busy information. This information is consulted by Outlook 2003 when scheduling appointments; Outlook 2007 or later uses Exchange Web Services for this purpose.
A quick look in the Eventlog revealed lots of 14031 errors were generated by the FreeBusy Assistant:
This told us Exchange was unable to store Free/Busy information in a public folder, in this case /o=EUROPE/ou=First Administrative Group. A quick look at the Public Folder Management Console in Exchange 2010 showed that the folder didn’t exist. Since the Free/Busy public folder to be used by an Outlook 2003 user is determined by the legacyExchangeDN attribute, this was the cause of the issue.
The reason for the folder’s absence was unknown so one can only speculate. My best guess is improper decommissioning of the organization and administrative group originally hosting those users, identified by that “orphaned” legacyExchangeDN.
With the Free/Busy public folder missing and the original Exchange infrastructure gone, there are two alternatives to resolving this issue, apart from upgrading clients to a recent version of Outlook of course:
The 1st option has consequences for the users, like being able to reply to earlier e-mail by co-workers. This can be resolved by adding the current legacyExchangeDN as an X500 address to the current set of e-mail addresses, but that also makes things a bit messy.
The 2nd option is to recreate the Free/Busy public folder; Here’s how to proceed:
Now we need to wait for the store to recreate the Free/Busy public folder during its maintenance cycle, which may take up to 24h. If you’re in a hurry, and the situation allows you because of the service interruption, you can also restart the Information Store. When the Information Store has created the Free/Busy public folder, event 3047 is logged by the MSExchangeIS Public Store:
To verify this, startup the Public Folder Management Console or any other Public Folder management tool, and you’ll see the newly created folder:
After a while you’ll notice Outlook 2003 users are now storing their Free/Busy information in this public folder and Free/Busy will work again for these users. You can verify clients are storing Free/Busy information using EMS, ExFolders or MFCMAPI, e.g.:
Finally, don’t forget to create replicas of this new Free/Busy public folder when appropriate.
After pulling Rollup 4 for Exchange Server 2010 SP1 on July 13th, after potential data loss issues were discovered during folders movements, and publishing an intermediate hotfix to resolve the RU4 issues without a rollup rerelease, the Exchange team decided to publish an updated version of rollup 4. This is somehow unexpected because of the expected release of rollup 5 in August. It’s good to see the Exchange team getting very open in this post about recent missteps in published rollups for such a mission critical application.
Exchange 2010 SP1 Rollup 4 v2 raises Exchange 2010′s version number to 14.1.323.6 (initial release was 14.1.323.1). The related knowledgebase article is kb2579150.
For the correct procedure on how to update a DAG and its members, check here.
You can download Exchange 2010 SP1 Rollup4 v2 here.
Just a quick notice that few minutes ago the Exchange Team pulled Exchange Server 2010 Service Pack 1 Rollup 4.
As reported earlier, there were potential data loss issues with this rollup when moving folders around in public folders or PST files using any version Outlook; Note that moving folders using OWA through Exchange Web Services works fine.
A fix for this issue will be incorporated in the RU5 update which is scheduled for August. So, like RU3 v2 v3 which took about a month to appear after the initial RU3 release was pulled, we’ll have to wait until August for RU5.
For those who already deployed RU4 an interim update has been made available that fixes this issue. The interim update can be obtained by contacting support.
When managing receive connectors in Exchange, you probably had to configure IP addresses or IP ranges on those receive connectors. This may be required when limiting access to a certain receive connector for applications to drop their mail using SMTP. Of course this can be done using the Exchange Management Console, but this may become tedious when lots of addresses are involved. Also, when multiple Hub transport servers are involved you may need to keep those IP ranges in sync on those Hub Transport servers in which case mismatches are likely.
As you’ve probably guessed, a little PowerShell makes life more easier. To configure the allowed IP ranges we need to use Set-ReceiveConnector and configure the RemoteIPRanges attribute. We’ll use a text file to maintain the list of allowed IP ranges and a PowerShell one-liner to set RemoteIPRanges.
The file should contain IP ranges in a RemoteIPRanges acceptable format, e.g.:
When we have prepared the file, we can use the following cmdlet to set RemoteIPRanges:
Get-ReceiveConnector *\APPRELAY | Set-ReceiveConnector -RemoteIPRanges (Get-Content RemoteIPRanges.txt)
This will configure all receive connectors named APPRELAY on all Hub Transport servers in the organization using IP ranges defined in the file RemoteIPRanges.txt. Be advised that this cmdlet overwrites the current configuration of RemoteIPRanges; if you need to add it to the current configured set of IP ranges on each receive connector, use the following cmdlet:
Get-ReceiveConnector *\Appl-Relay | ForEach { Set-ReceiveConnector -RemoteIPRanges ($_.RemoteIPRanges+ (Get-Content ipranges.txt) | Sort -Unique) }
By adding the Sort -Unique filter, we make sure each range is only specified once. This prevents errors caused by setting a range using the RemoteIPRanges.txt file when that range has already been configured in the current value of RemoteIPRanges.
Note that when inspecting the results you can set $FormatEnumerationLimit to a value higher than the default (16) to have Get-ReceiveConnector * | fl RemoteIPRanges display all its values. Also, keep in mind when configuring connectors that the connector with the most specific matching IP address wins.
EighTwOne (821) 
