Problems with Exchange 2007 SP1 UR6? Not here…
It seems like a good number of folks are saying they’re having issues with UR6 within their Exchange environments (pay no attention to the one who said it wouldn’t install on Exchange Server 2003…).
There are quite a few discussions going on currently about the effects of UR6, both at the MS Exchange team’s blog and on the TechNet forums.
All I can say, is that so far I’ve seen no issues. I do make it habit to run the updates using an account with Exchange Organization Administrator privileges though, so that explains away several of the complaints people have made (you’ve got to have that level of access for the scripts to run properly…).
I’ve put the update on 1 HT, 1 CAS and 2 SCR target nodes as well as a DPM 2007 SP1 server. I’ll be updating an additional 2 HT, 2 CAS and 4 CCR nodes shortly. So far, I wasn’t asked to perform any reboots and I had no issues. Yes, the update does take a long time to apply, but that’s been normal for the recent UR packages. As a general rule, even though a reboot was not requested, I ALWAYS make it a rule to reboot Exchange after applying any Update Rollup or Service Pack…consider that good advice that will go along way towards services that don’t start properly after an update.
Have you had any issues? I’ll post the results of my next round of updates after I complete them.
Exchange 2007 SP1 Update Rollup 6 arrives
Patch Tuesday this month brought an usual update: Update Rollup 6. That’s unusual for an UR to appear on Patch Tuesday…but in this case there are two security fixes that are rated as Critical, so the timing makes sense.
Get the UR here and install it as soon as possible. No mention of whether or not this UR fixes the bug identified with SCR in UR5 or not.
Microsoft Security Bulletin MS09-003 explains the two vulnerabilities in general terms. Sounds bad, generally speaking.
This security update resolves two privately reported vulnerabilities in Microsoft Exchange Server.
The first vulnerability could allow remote code execution if a specially crafted TNEF message is sent to a Microsoft Exchange Server. An attacker who successfully exploited this vulnerability could take complete control of the affected system with Exchange Server service account privileges.
The second vulnerability could allow denial of service if a specially crafted MAPI command is sent to a Microsoft Exchange Server. An attacker who successfully exploited this vulnerability could cause the Microsoft Exchange System Attendant service and other services that use the EMSMDB32 provider to stop responding.
MS KB 959241 contains the full list of updates and fixes.
Update Rollup 6 for Exchange Server 2007 SP1 fixes the issues that are described in the following Microsoft Knowledge Base articles:
950675: Downloaded .xls file attachments are empty when you open the files by using Outlook Web Access on Exchange Server 2007 Service Pack 1
955443: Some free/busy messages are not replicated from Exchange 2007 to Exchange 2003 servers after some mailboxes are migrated from Exchange Server 2003 to Exchange Server 2007
956536: The Microsoft Exchange File Distribution service uses lots of memory and processor time when Exchange Server 2007 processes many OABs
956624: The Microsoft Exchange Transport service crashes continuously after you enable journal rule or deploy an antivirus application on an Exchange Server 2007 server
957748: The custom message class of contact object is overwritten by the normal IPM.Contact class when an Exchange 2007 server replicates the contact object to any other public store
959239: MS09-003: Vulnerabilities in Microsoft Exchange could allow remote code execution
Windows Update error 80072F78 in Windows Server 2008
Although I haven’t actually found the exact cause (and thus the solution), I’ve run across problems using Symantec Endpoint Protection (i.e. Symantec Corporate 11.0) on Windows Server 2008. It seems that something in the protection configuration in the Symantec product is blocking Windows Updates. You’d get the error code 80072F78 and no updates.
Uninstalling version 11 and moving back to version 10.2 allows Windows Updates to be performed again, although I’m not sure yet what the real issue is or how to fix it. Anyone else run across this?
Update 2/20/2009: This may be the solution, though I’ve not tried it.
HOW TO: Configure and Start SCR Replication
It was a bit surprising to find that the TechNet documentation about configuring and starting SCR replication was…ah…less than perfect or easy to use. Here’s a simple set of commands you can use to get your SCR implementation rolling along nicely.
Before trying to configure SCR, be sure that your mailbox server has been configured properly first. That includes installing and configuring the Operating System and storage exactly the same as the SCR source (typically a CCR cluster). Here’s a few pointers:
- If you use volumes F, G, H, and I for two databases and two storage group logs…make sure you have that configuration on your SCR target.
- You should size the hardware identically to the SCR source, so use the same CPU type and speed, same amount of RAM, same server model, etc. where possible.
- Install Exchange using a custom setup and install the stand-alone mailbox server role.
- Leave the default mailbox storage and storage that Exchange setup installs, but be sure to remove the mailbox it created for you (if you were using an account without a mailbox). You’ll need these local mailboxes for Ops Mgr monitoring and routine testing purposes…just don’t create any real user mailboxes in them!
Here’s the commands you’ll need to run from the Exchange Management Shell to get things rolling:
Run from an Exchange server or management station on the same operating system version (although 32-bit or 64-bit does not matter) that does NOT have Exchange Server 2007 SP1 UR5 installed:
- Enable-StorageGroupCopy -Identity “SCR_source_server_name\Storage_Group_name” -StandbyMachine SCR_target_server_FQDN-ReplayLagTime x.x:x:x -TruncationLagTime x.x:x:x
- Be sure to see the cmdlet notes to understand the implications of ReplayLagTime and TruncationLogTime. The values are in days.hours:minutes:seconds.
- If you ever need to change the values configured for ReplayLagTime or TruncationLogTime, you’ll have to disable the copy and enable it over again anew.
- Here’s the issue with UR5.
Run from the SCR target server, after verifying that Active Directory has replicated (especially critical when your SCR target server is located in a different AD Site):
- Suspend-StorageGroupCopy -Identity “SCR_source_server_name\Storage_Group_name” -StandbyMachine SCR_target_server_FQDN
- This cmdlet is usually not required, but it’s good practice to run. The SCR copy is configured and in a suspended state following the issuance of the Enable-StorageGroupCopy cmdlet.
- Update-StorageGroupCopy -Identity “SCR_source_server_name\Storage_Group_name” -StandbyMachine SCR_target_server_FQDN
- This gets the full copy (full reseed) started.
- Resume-StorageGroupCopy -Identity “SCR_source_server_name\Storage_Group_name” -StandbyMachine SCR_target_server_FQDN
- This cmdlet is usually not required, but it’s good practice to run. The SCR copy is resumed following the completion of the reseed.
To check the SCR replication status for all SCR instances on an SCR target server, issue the following command:
- Get-StorageGroupCopyStatus -Identity “SCR_source_server_name\*” -StandbyMachine SCR_target_server_name
TechNet cmdlet references:
- Enable-StorageGroupCopy
- Suspend-StorageGroupCopy
- Update-StorageGroupCopy
- Resume-StorageGroupCopy
- Get-StorageGroupCopyStatus
Monitoring Exchange 2007 SCR with Ops Mgr 2007
I was a bit surprised to see that the most recent Management Pack for Exchange Server 2007 for Operations Manager 2007 didn’t understand the differences between CCR and SCR…and how those differences would impact the log queue depths for replication. So, if you’re going to implement SCR (or you already did), be sure to override the thresholds for the following monitors for your SCR targets:
- MSExchange Replication: ReplayQueueLength - sustained for 5 minutes - Red(>15)
- MSExchange Replication: ReplayQueueLength - sustained for 5 minutes - Yellow(>7).
Since the replay queue length is always going to be rather large due to the nature of how SCR operates (this value will never be less than 50 logs and will almost always be more than that), you’ll need to determine what the normal values of the replay queue depth are for your SCR targets. As an example, I have two SCR targets (from CCR sources) that routinely have replay queue depths of 300 - 400 logs with just a 1 hour ReplayLagTime value configured! See this TechNet article for more information configuring SCR.
I’d suggest making your “yellow” value at least 100 above your normal average replay queue depth and your “red” value at least 250 - 350 above your normal average. Make your overrides on the specific mailbox servers that are your SCR targets…not at the global level.
-
Translator
