ForeFront for Exchange scanners not showing as updated
I recently had one of my Hub Transport servers running ForeFront for Exchange Server 2007 SP1 start behaving strangely. It was reporting that the scanner updates for “Norman Virus Control” and “AhnLab AntiVirus Scan Engine” as being over a week old, even though the most current definitions were on the disk in the correct location and the ini file (update.ini) indicated the correct version both in the ini file and within the ForeFront console. This, of course, caused OpsMgr to send quite a few emails about the out of date definitions.
Trying to force a manual update did no good, neither did restarting the relevant services. The solution, delete the update.ini file and then force a manual update process. You can find the current (extracted) scanner defintion files in the following location:
C:\Program Files (x86)\Microsoft Forefront Security\Exchange Server\Data\Engines\x86\scanner\Bin
Exchange Server 2007 SP1 Update Rollup 7!
Wow, that was quick! (I just got SP1 UR6 installed on all my servers a week ago).
Update Rollup 7 for Exchange Server 2007 SP1 has been released. The full list of fixes and updates is documented in MS KB 960384, but I think a lot of people will be happy to see this one specific item corrected:
- 961281- An error is returned when you enable SCR from any source in a child domain after you install Exchange Server 2007 Service Pack 1 Rollup 5
You can get the update here and get to updating! 
Data Protection Manager 2007 error ID 998
I’m currently doing some testing with Exchange Server 2007 and Data Protection Manager 2007 on Hyper-V. As I needed several VMs for the testing, I just installed one and then used NewSID to change the VM SID and name before joining each one to my test domain. Later, upon attempting to configure a new protection group on DPM for one of the Exchange servers I got this error:
The operation failed because of a protection agent failure.
Retry the operation.
ID: 998
Details: Unknown error (0×80042318) (0×80042318)
After checking the usual suspects, including the required VSS patch on the Exchange server to be protected and examining the Event Logs on the Exchange Server I found lots of VSS errors with Event ID 12302 on the Exchange server.
Tt turns out the problem is actually with using NewSID…it doesn’t play well with VSS. The solution’s pretty simple once you find it–here’s one place it resides. The steps are as follows:
- Stop the Microsoft Shadow Copy Provider & Volume Shadow Copy Service.
- Export the contents of the HKLM\Software\Microsoft\EventSystem key to a .reg file (as a backup).
- Delete the HKLM\Software\Microsoft\EventSystem\{26c409cc-ae86-11d1-b616-00805fc79216}\Subscriptions key. (Just delete the Subscriptions subkey; leave the EventClasses key.)
- Restart the server.
- Run the “VSSADMIN LIST WRITERS” command, which should procude output similar to that shown below.
This causes the VSS entries in the HKLM\Software\Microsoft\EventSystem\{26c409cc-ae86-11d1-b616-00805fc79216}\Subscriptions key to be rebuilt when the writers initialize.
If that does not resolve the problem, check the Sysinternals forum link mentioned above for more steps.
Activate SCR Target via EMS script
If you’ve got SCR installed and are using the Database Portability model described in “Standby Continuous Replication: Database Portability“, here’s a useful Exchange Management Shell that scripts the entire activation process. Just change all of the noted fields to match your source and target servers and even add additional storage groups/databases to the script if you like.
Be sure to triple check your entries and TEST IN A LAB ENVIRONMENT before unleashing this production!
Activate-SCRTarget.zip (1.6 KiB, 663 hits)
Exchange Server 2007 SP1 UR6 = No problems
I finally had the chance to update the rest of our Exchange Server 2007 SP1 servers to UR6 tonight and there were no problems at all. Even the .NET native image portion went fairly quickly. WIN!
Adding Exchange Administrators fails with error 00000525
Just as a quick reminder (because, oh…I forgot myself), if you have Exchange Server 2007 installed in a child domain in a parent/child domain forest then your Exchange security groups are going to be located in the parent (root) domain. So, if you want to add new Exchange Administrators using the Add Exchange Administrators wizard from the EMC or the Add-ExchangeAdministrator cmdlet in the EMS, you need to be an Enterprise Administrator if you’re trying to perform the add from the child domain. If not, you’ll get this error:
Summary: 1 item(s). 0 succeeded, 1 failed.
Elapsed time: 00:00:00Add-ExchangeAdministrator
FailedError:
Active Directory operation failed on dc21.root.local. This error is not retriable. Additional information: The specified user does not exist.
Active directory response: 00000525: NameErr: DSID-031A0F80, problem 2001 (NO_OBJECT), data 0, best match of:
”The object does not exist.
Exchange Management Shell command attempted:
Add-ExchangeAdministrator -Identity ‘company.local/SystemUsers/Service Accounts/ServiceAccount42′ -Role ‘ServerAdmin’ -Scope ‘XHT10A’Elapsed Time: 00:00:00
Here’s one newsgroup post with this error, I’m sure there are others as well.
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
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
