SME requires SnapDrive for quiesce\snapshot functionality. SMBR technically does not if purchased directly from ONTRACK (at least at some point in the past, the NetApp version required connectivity to a LUN on a Filer via API calls - which I'm under the impression was performed by SnapDrive).

Typically, the issue with SnapDrive connecting to LUNs created manually is with the mapping - SnapDrive looks for mapping done with a 'viaRPC' in front of the igroup names, which is not there if done manually. Forcibly unmapping via filerview and remapping via SnapDrive is typically sufficient to fix this.

That said, I have used neither 2008 nor SnapDrive 6, so things may have changed quite drastically...

FWIW, I've used snapdrive extensively for years and it's been a huge time saver and life saver for me.

Glenn

________________________________

From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Leeds, Daniel Sent: Thursday, July 10, 2008 10:44 PM To: toasters@mathworks.com Subject: Exchange iscsi luns and Snapmanager/SMBR without snapdrive

asking the community while i wait on the official netapp answer.

are either Snapmanager for Exchange or the Single Mailbox Restore products absolutely tied to or unable to function completely if snapdrive is not present?

in short, this "easy to use" gui tool has wasted enough of our time already and I do not need anything other than the ontap command line and about 15 minutes to provision the proper igroups and luns requested by our Exchange admins and another minute to bring them up via the microsoft iscsi interface format them and put them under the microsoft cluster services control.

one last tidbit, although assured this would work fine, any luns that were created from the filer were completely unable to be seen, utilized, or managed via snapdrive. they had to be deleted and provisioned through the snapdrive interface which is not familiar to us and not behaving as shown to us by netapp. even support seemed to be perplexed although it was indicated that perhaps this was due to the servers being 2008 Server and the snapdrive version 6.

anyhow im only just clarifying if there is any fundamental dependency between snapdrive and the exchange snapshot tools.

:)

-- Daniel Leeds Manager, Storage Operations Edmunds, Inc. 1620 26th Street, Suite 400 South Santa Monica, CA 90404

310-309-4999 desk 310-430-0536 cell

first off, thanks for all the responses. as usual toasters is quick and reliable.

the issue we had was snapdrive 6 was unable to manage or utilize our iscsi luns that were setup manually from the ontap command line.

this turned into an all day affair with several support calls made by one of our storage admins and the actual exchange admins not being able to do anything on this new cluster setup. this may sound absurd to many since alot of netapp shops are heavily windows based and the filers/storage is managed by the same windows admins. so why would anyone create luns on the command line instead of using snapdrive which simplifies lun management?

a brief background and why a minor detail caused all of this aggrivation. hopefully this will help someone else who might experience this scenario or something similar.

1) we are virtually an all UNIX environment with nearly all storage accessed via NFS and a couple iscsi luns with all filer administration and configuration done via ssh on the ontap command line. filerview is disabled and all the unix iscsi luns are provisioned via the command line and manually mounted on the unix host, partitioned, and filesystems created via the standard unix utilities for each unix variant.

2) a previous exchange cluster did not utilize snapshots and was backed up via the corporate standard in place at that time and thus not only were the luns created manually but they had no space reservation or snapshot reserve and thus no requirement for snapdrive.

3) as we now intend to utilize snapshots with Exchange we had netapp provide a list of recommended versions of the snapshot software based on the windows version and also sat down with a few netapp SE's to validate everything and demo the snapdrive interface and setup. this is where the fun begins as one team with a unix background and only command line administration interact with the Exchange and windows snap products SE and customer implementation engineers--speaking the same language but with different dialects. in a nutshell we asked if snapdrive could manage and "import" existing luns created via the command line. the answer was yes but with one important exception that normally is part of the standard manual provisioning. the luns cannot be mapped and no existing igroups can be utilized by snapdrive. to further compound the confusion the support engineers did correctly advise our admins to unmap the existing luns but without explaining the reason why and only after a couple other troubleshooting steps were suggested that did not work. so our admin was able to eventually get the luns visible in snapdrive but felt like it was more trial and error and did not associate the mapping as the root cause since he was also instructed to delete and recreate luns which worked.

4) the netapp recommended procedure is to utilize snapdrive to create and manage your luns and the correct supportable solution. not being familiar with the product or interface and due to scheduling we did not have an onsite resource to assist us with using snapdrive. we wanted to utilize our usual lun provisioning standards and skills while still utilizing snapdrive to manage mounts and snapshot integration later on in the interest of getting the exchange admins the storage as quick as possible. it was the right approach for us and is fully supported but not the recommended procedure and thus not easy for normal support channels to pick up on the one subtle step that renders manual luns from working with snapdrive.

wow, alot longer than intended but a good experience to share in my opinion. and no we have nothing against snapdrive or windows administration tools :)