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 :)