VMware vCenter Site Recovery Manager 4.1.1 is a maintenance release that resolves issues identified in previous Site Recovery Manager releases.

This maintenance release of SRM was released the same day that vSphere 4.1 Update 1 was released.   

** NOTE: You must upgrade vCenter to 4.1 Update 1 before you upgrade SRM to 4.1.1.  And the upgrade itself can only upgrade SRM 4.1 installs and NOT SRM 4.0 installs. **

There are a number of important fixes in this update.  Known issues resolved in this release of Site Recovery Manager include:

• SRM Fails To Complete Installation And Configure Firewall Ports

  It is possible to install SRM into environments that use firewalls. For SRM to complete necessary communications, ports must be opened in the firewall. In the past, these ports were not opened. These ports are now opened.

• Network Connection Problems May Make Service Restart Necessary

  In some cases, network connections between SRM servers were lost. If a configuration change was made and a connection was lost, it was necessary to restart the SRM service for the changes to be applied. Configuration changes are now applied as expected, and no restart is required.

• SRM Service Failed To Start Due Malformed XML

  If a database field contained a string that was exactly 256 characters, the last character could be omitted. In cases where the field contained XML data, the last character of the XML close token was lost, resulting in an XML parse exception being thrown. Strings are now properly read from the database, regardless of item length, thereby eliminating this issue.

• Disconnection Errors Occur In Environments Using Firewalls

  Due to the way connections were managed, disconnection errors sometimes occurred when using SRM in an environment with a firewall. To resolve this issue, a timeout option has been added. By adding <WaitForUpdatesTimeout> to the vmware-dr.xml file, SRM is configured to wait for the specified number of seconds before closing the connection. The default value is 900, which equals 15 minutes. If disconnection errors are occurring in an environment with a firewall, set the <WaitForUpdatesTimeout> value to be less than the firewall timeout on connections.

• Database Tables Are Lost During Installation Rollbacks

  It is possible to complete an upgrade or installation using an existing database. In some cases, if an installation or upgrade failed, during the rollback process, the existing database was deleted. Databases from previous installations are now kept if a rollback is required.

• NFS Volumes Can Be Mounted On Different Hosts With Different IP Addresses Without Warnings

  If different IPs are used for mounting the same NFS share on different hosts, problems could occur. In the past, SRM did not display warnings about this case. Warnings are now displayed.

• SRM Service Encounters Problems With Duplicate Entries For A Volume

  When multiple datastores are created in very rapid succession over a short period of time, vCenter Server may provide SRM with duplicate information about the new datastores. This might have occurred, for example, if one hundred datastores were created in one second. In the past, this created problems, but SRM now handles this information as expected.

• Unregistered Windows Firewall Results In Installation Rollback

  In Windows Server, in the case where Windows Firewall is unregistered, SRM installation could fail, resulting in installation rollback. This did not apply to windows hardware firewalls or software firewalls provided by other vendors running on a Windows machine. This issue has been resolved, so installation now completes as expected.

 The release notes can be found here.  And you can download the update here.