Search

Cannot install SQL 2008 in a Geographically Dispersed Cluster by JohnToner

Closed
as Won't Fix Help for as Won't Fix

5
0
Sign in
 to vote
Type: Suggestion
ID: 366673
Opened: 9/8/2008 10:03:19 AM
Access Restriction: Public
0
Workaround(s)
This is similar to the feedback you've already received about this issue in feedback item 331910. The installer blocks SQL installations in geographically dispersed cluster because geographically dispersed clusters REQUIRE that the cluster disk resources have dependencies on "other" resources that control access to the disks.

The installer should not be so picky about the cluster disk dependencies. Worry about setting up SQL dependencies and let the cluster admins worry about setting disk configurations.

This issue causes unnecessary support calls to both Microsoft and to geographically dispersed cluster vendors
Details (expand)
Product Language
English

Category

Setup

Proposed Solution

Make SQL installer less picky about disk configurations. Stop looking at the disk dependencies and worry about the application dependencies instead.

Benefits

Faster Development
Improved Installation

Other Benefits

 
File Attachments
0 attachments
Sign in to post a comment.
Posted by Microsoft on 2/9/2010 at 1:50 PM
We are resolving and closing this issue with previous comments provided. Please check the configurations of dependencies as outlined before in case you run into the same issue.

Thanks,
Max Verun
SQL Server
Posted by Microsoft on 1/8/2009 at 4:46 PM
We had a similar problem reported by another vendor and found out that the storage class property was not set properly by the vendor.

In SQL Server setup, we do not look at the physical storage resource type. We always use CLUS_RESCLASS_STORAGE flag when looking for storage resources and checking dependencies. So if you are getting blocked, most probably your resource must not have that flag set.

If the resources on both sides of the dependencies are CLUS_RESCLASS_STORAGE, then they should not be blocked. Any graph made of just CLUS_RESCLASS_STORAGE should pass the check.

What to look for is either the resource not being CLUS_RESCLASS_STORAGE or some non storage resource references some resource in the dependency graph. We walk the entire graph to make sure it has only CLUS_RESCLASS_STORAGE. So even if the dependencies directly connected to the disk resource are all valid but if the replication solution is referenced by some service that whole chain will be disqualified.

Could you check this flag for your storage resources? You need to ensure it is set per our guidance here.

Thanks,

Max Verun
SQL Server
Posted by Microsoft on 10/2/2008 at 9:11 AM
This is by design currently as I mentioned in the previous reply. If you have more information on your particular configuration, please let us know and attach the logs. I am moving this issue to next release for re-consideration pending your additional feedback.

Thanks,

Max Verun
SQL Server
Posted by Microsoft on 9/12/2008 at 5:35 PM
For RTM release, we relaxed this requirement last minute. If there are dependencies already set across cluster disks, we allow them, provided:

1. All the disks are within the same group
2. There are no other external dependencies to the selected disks (such as for DTS)

We would like to take a look your configuration. Could you attach the cluster.xml file located in Setup logs folder %ProgramFiles%\Microsoft SQL Server\100\Setup Bootstrap\LOG. It is located in the Datastore folder for your particular setup logs folder.

Thanks,

Max Verun
SQL Server
Posted by Edwin vMierlo on 9/10/2008 at 9:01 AM
folks,
this is pretty limiting, this need to be sorted ASAP

a disk with a dependency on another resource is a valid cluster configuration, and SQL should not care about this, other than the disk is in the correct cluster/application group.
Sign in to post a workaround.
© 2013 Microsoft Corporation. All rights reserved. Microsoft Connect Terms of Use | Trademarks | Privacy Statement