Exchange Geek's Weblog

I'm a Geek!

Archive for June, 2010

Crypto API fix KB KB974571 can break your OCS 2007 R2 install

Posted by Milind Naphade on 15/06/2010

I was installing OCS 2007 R2 yesterday on one of the servers which is a Windows Server 2008 R2 machine, I faced a problem activating the OCS EE server during the installation. Everything looked good until I started adding the server into the pool I configured. The add server to pool wizard couldn’t complete with an error in OCS deployment log.

[0xC3EC78D8] Failed to read the Office Communications Server version information. This can happen if the computer clock is not set to correct date and time. 

This error was totally unexpected when I knew that I had the clock setup correctly. Turns out it is a known problem while installing OCS 2007.

Normally when we install any server application we run windows updates so that the OS is fully updated with latest patches. However, for installing OCS 2007 or OCS 2007 R2 you have to little careful. An update described in KB974571 causes failures in OCS setup during the server activation.

Resolution:

IF you encounter such problem then you must uninstall KB974571 from the computer where you are installing OCS and install it after you have completed the installation. Wait… you are not done yet. You also have to apply the fix from the same KB in order to keep your OCS server running after activation of services.

Read more about this at KB974571

You can download the OCSASNFix.exe from Here. Which fixes the problem after installing the hotfix. Remember, this fix does not work unless you have an OCS installed on the computer. It is a simple command line utility you have to run from an elevated command prompt window.

Advertisements

Posted in OCS 2007, Setup | 6 Comments »

Installing Exchange 2010 SP1 (beta) on DAG members

Posted by Milind Naphade on 11/06/2010

Microsoft released another feature packed exchange update for exchange 2010. The service pack 1 (beta) for exchange 2010 contains many newly added features and fixes to identified bugs.

Installing SP1 on a standalone exchange 2010 server is not a very big deal but when it comes to applying an update or service pack on clustered servers exchange always needed a special procedure. This blog post discusses the steps that you need to follow while installing service pack 1 on a server which is a part of a DAG.

The steps are as below:

  • Identify which server you want to update first. This is normally a server which hosts only passive copies of databases. You may also have a situation where all DAG members host at least one active copy of any database. In such situations follow the next step.
  • This step can be skipped in future if MS comes with some solution and consolidates the hotfix in exchange installer itself. Download and install hotfix KB981002. This hotfix requires a system reboot. :-).
  • Another hotfix required for the OS is http://www.microsoft.com/downloads/details.aspx?FamilyId=87f72529-d316-42e8-bf77-a46951f66dda&displaylang=en. This can be downloaded when you run windows update. If you have run windows update lately then it is not required.
  • Once you have identified the server where you want to update first; suspend activation for the database copies on the server being updated.
  • Open EMS and run

Get-MailboxDatabaseCopyStatus -Server E1402 | Suspend-MailboxDatabaseCopy -ActivationOnly -Confirm:$False -SuspendComment "Install  SP1 for Exchange 2010"

E1402 is my server name in the DAG you must replace it with your server name.

  • Then the next step is to switch over the server being updated to another server. To switch over the server open EMC and locate the server being updated under Server Configuration –> Mailbox.
  • Highlight the server and then select Switchover Server from the actions pane. Refer the image below:

image

  • Select Automatically choose a target server. If you want to specify a target server manually then you can use the browse button by selecting Use the specified server as target for switchover option button

image

  • Close all MMC instances open on the server including EMC.
  • Now extract the SP1 installer from the file you downloaded to a convenient location and run the setup.exe

image

  • Select the languages to be installed and click on Install Microsoft Exchange Server Upgrade link on the page.
  • After you accept the license agreement installer runs a BPA check as usual.

08

  • Now you are ready to upgrade. You may not see that warning abut SMTP send connector if you have it configured correctly.

image

  • Here you can see that the SP1 is going through the Org Preparation one more time. You can read about the AD changed SP1 makes here. It is important that you review these changes as your organization may have custom schema extensions depending on the existing exchange 2010 schema extensions.

image

That greenery looks good 🙂

Alright, now you can simply resume the suspended database copies on this server by running

Get-MailboxDatabaseCopyStatus -Server E1402 | Resume-MailboxDatabaseCopy

You can also perform the database switchovers as necessary using EMC after this.

And simply repeat these steps for all other servers in the DAG.

Please note: It is highly recommended that you perform the backup of your AD servers before applying Exchange Service Packs.

Posted in Exchange 2010, Setup | 2 Comments »

Exchange Server 2010 SP1 beta available for download

Posted by Milind Naphade on 07/06/2010

MS Exchange team just announced the availability of Exchange Server 2010 SP1 beta. The update can be downloaded from Microsoft Download Center (Microsoft Exchange Server 2010 SP1 Beta)

This download is a prerelease of a stable download hence not recommended to be installed on the production servers unless you thoroughly test it in lab environment.

Enjoy testing!! 😉

Posted in Exchange 2010, News | Comments Off on Exchange Server 2010 SP1 beta available for download

Exchange Server 2010 Shadow Redundancy

Posted by Milind Naphade on 07/06/2010

Exchange 2007 was launched with a completely new design and product architecture and showed up with a whole new concept of bifurcated server roles which were a part of a single server installation in Exchange Server 2003. These server roles were wiz. Mailbox Server Role, Hub Transport Server Role, Client Access Server Role, Edge Transport Server Role and Unified Messaging Server role (this was a completely new feature that exchange 2007 supported. Earlier version of exchange did not have any native support to unified messaging and relied on third party products).

With these bifurcation of functionality in terms of server roles; exchange server 2007 also introduced new concepts of high availability for mailbox databases very well known as CCR, LCR, SCR. These HA features made sure that once an email is delivered to a mailbox on the database, it remains safeguarded against any data loss even in case of a complete database or server failure.

Transport Dumpster:

With highly available mailbox servers, email messages are safe once they are delivered to the database; protecting email messages in transit was another challenge. As a safety measure against any data loss for the message in transit, exchange 2007 hub transport server introduced another new feature called transport dumpster which is nothing more than a queue of messages that is maintained by the hub transport server. This queue contains the email messages which were recently delivered to the mailboxes protected by mailbox HA solution like CCR. These messages are retained in the database until they reach the age limit configured by the administrator. In case of a failover the clustered mailbox servers request all hub transport servers in the site to resubmit emails messages from transport dumpster. This mechanism prevents the loss of emails during the failover but it didn’t have the capability to handle the emails in transit between transport servers.

Shadow Redundancy uses notifications:

To make sure that least amount of data is lost in the form of in transit email messages; Exchange 2010 adds a new feature of the transport component called Shadow Redundancy. This is just like transport dumpster but except the deletion of messages from transport database is not completed until the transport server verifies that all of the database copies in DAG are successfully updated. Shadow Redundancy keeps tack of messages which have been delivered and replicated to all database copies in a DAG. This is achieved by maintaining a copy of messages being sent to database copies in a DAG and requesting a notification that it has been replicated to all database copies in DAG. The copy of messages is held in the mail.que database until the HT server receives a notification that the transaction log representing that particular message has been replicated to the primary target database and has also been successfully replicated to other copies. Once the notification is received the transaction log representing the message is truncated to make sure that the mail.que database contains only those messages which have not yet been replicated.

Shadow Redundancy Manager (SRM) and Heartbeat:

The initiating transport server issues and XQUERYDISCARD message to the target server and in response the target server returns a discard notification. This is known as the heartbeat. Once the heartbeat is received from the target; the Shadow Redundancy Manager uses this heartbeat to determine the availability of the primary target server for which the shadow messages are queued. Heartbeat time out is 300 seconds by default which is subject to 3 consecutive retries to the destination server. If the initiating server cant establish a connection to primary target within the heartbeat timeout the initiating server determines that the destination is not functional then resubmits the shadowed messages to next available server. If there is any chance of message duplication due to this approach then Exchange 2010 message de-duplication features takes the charge and removes them so that users don’t see duplicate messages in their mailboxes.

In short, Shadow redundancy is not the transport dumpster but an extension to SMTP service which works tightly with the transport dumpster. Shadow Redundancy is enabled by default and is used as far as both servers in a SMTP session support it. You can use Set-TransportConfig –ShadowRedundancyEnabled:$False. It uses discard notifications to remove only those messages from dumpster which has been delivered and successfully replicated across all database copies in a DAG.

Shadow Redundancy is the transport component and can only be managed using EMS, there is no GUI to administer it.

Microsoft Technet has a detailed article which discusses the various scenarios and the ways Shadow Redundancy works: You can read it here

Posted in Exchange 2010, Transport | Comments Off on Exchange Server 2010 Shadow Redundancy