BMR integration with SFW has always been a problem. The only SRT build that would work was the "Legacy SRT" process, itself a much longwer and distinctly complicated restore process.
Most clients making use of SFW have it to manage non-local drives/file systems. Those tend to be backed up by a separate policy and not part of the backup of the OS image itself. So the reality is that BMR is not in play for those data disks but BMR, by default, see all of the attached dirves and tries to work with them in a geeral overall manner.
That being the case, there is a small easy work around for this that alows for recovery of such cleints a the OS drive level. The mechanism is show in this article:
http://www.symantec.com/docs/HOWTO88823
When SFW software is installed, the OS drive, although not directly managed by SFW, has its volume manager key set to SFW for the entire system. The OS drive is not modified and works quite well using the normal Windows LDM service. The registry key entry that is described "tells" BMR to work against only the non-SFW drives and do so as if they were normal LDM drives. The SFW drives are recognzed as such by the bmrsavecfg process and are tagged as such and marked as "Restricted" by BMR. As such, they are not seen or manipulated in any manner during the recovery process. And, as the BMR confifguration file has been set up as normal LDM drives, normal 'bmrrst.exe' processing occurs at restore time. There is a special tag in the configuration file that has BMR keep the normal SFW software key in the restored registry. It also keeps teh drivepath definitons of the data drives in there as well. On reboot, this information has the client re-attach to them as a normal process. This is equivalent to dong a "Prepare To Restore" and choosing teh options "System Disk/Volumes only" and "make available non-restored volumes on non-restored disks after reboot". Basically do not remove any non-restored volumes from the 'fstab' file (or its equivalent).
Now, as I see thatthis is a VCS cluster situation, I want to add some additonal information. A little extra credit you might say. BMR is "cluster aware" of MSCS and VCS cluster for 'bmrsavecfg' purposes. It captures both the client's cluster identity and it's physical non-cluster identity (what it wouild look like of cluster servces were disabled). BMR will restrict any resource on the client that is shared by the cluster. During recovery, it will only recover all local (non-shared) resources. This is all discussed in my article:
BMR and cluster node restores
http://www.symantec.com/docs/HOWTO84852
OK, baseline, use the registry mod to allow for easy BMR client configuration capture and allow for restore usng the much more eficient 'Fast Boot/Fast Restore SRT" method.
BMR integration with SFW has always been a problem. The only SRT build that would work was the "Legacy SRT" process, itself a much longer and distinctly complicated restore process.
Most clients making use of SFW have it to manage non-local drives/file systems. Those tend to be backed up by a separate policy and not part of the backup of the OS image itself. So the reality is that BMR is not in play for those data disks but BMR, by default, see all of the attached drives and tries to work with them in a general overall manner.
That being the case, there is a small easy work around for this that allows for recovery of such clients a the OS drive level. The mechanism is show in this article:
http://www.symantec.com/docs/HOWTO88823
When SFW software is installed, the OS drive, although not directly managed by SFW, has its volume manager key set to SFW for the entire system. The OS drive is not modified and works quite well using the normal Windows LDM service. The registry key entry that is described "tells" BMR to work against only the non-SFW drives and do so as if they were normal LDM drives. The SFW drives are recognized as such by the bmrsavecfg process and are tagged as such and marked as "Restricted" by BMR. As such, they are not seen or manipulated in any manner during the recovery process. And, as the BMR configuration file has been set up as normal LDM drives, normal 'bmrrst.exe' processing occurs at restore time. There is a special tag in the configuration file that has BMR keep the normal SFW software key in the restored registry. It also keeps the drive path definitions of the data drives in there as well. On reboot, this information has the client re-attach to them as a normal process. This is equivalent to dong a "Prepare To Restore" and choosing the options "System Disk/Volumes only" and "make available non-restored volumes on non-restored disks after reboot". Basically do not remove any non-restored volumes from the 'fstab' file (or its equivalent).
Now, as I see that this is a VCS cluster situation, I want to add some additional information. A little extra credit you might say. BMR is "cluster aware" of MSCS and VCS cluster for 'bmrsavecfg' purposes. It captures both the client's cluster identity and it's physical non-cluster identity (what it would look like of cluster services were disabled). BMR will restrict any resource on the client that is shared by the cluster. During recovery, it will only recover all local (non-shared) resources. This is all discussed in my article:
BMR and cluster node restores
http://www.symantec.com/docs/HOWTO84852
OK, baseline, use the registry mod to allow for easy BMR client configuration capture and allow for restore using the much more efficient 'Fast Boot/Fast Restore SRT" method.