locked
SCCM 2012 R2 setup fails with no access to "admin" shares on SQL Cluster RRS feed

  • Question

  • SQL Server 2012 SP 1 (plus all latest updates) on a Windows Server 2012 R2 Failover cluster (and running fine for my WSUS db and SCOM 2012 R2 dbs - and yes the SQL collation is correct).

    The SCCM 2012 R2 Prinary site is to be installed on a Windows Server 2012 R2 server, passes all checks and prerequisites (only reporting a warning for SQL memory assignment as they are VMs on Hyper-V with dynamic memory so it says they are running too low on memory - but this a non issue).

    The setup routine proceeds until the actual real portion of the setup (when you press "Begin Install"), then hangs until it finally reports an error that the setup cannot find an NTFS volume on the SQL Server (the SMS Provider component is to be installed on the Primary Site Server as this is a cluster, so it is not that).

    The problem is that the setup appears to be trying to find an NTFS volume on the cluster by using the \\virtual server name\admin$ share.  Now you can obviously attach to the admin$ share on each node by name \\server1\admin$ and \\server2\admin$  but you cannot attach to \\server3\admin$ (which used to actually open whichever node is actively holding that virtual server name [server3] and VIP as was in much earlier versions of Windows clustering), this looks like a change in the setup of SCCM 2012R2 as there is no need to check for NTFS volumes on the SQL cluster as no SCCM components are being installed there.

    This can't be an unusual setup just using the latest versions of everything in a simple two node SQL cluster for the SCCM db, this has to be a SCCM 2012 R2 setup issue as the platform is fine for SCOM 2012 R2 and WSUS usage.


    • Moved by TorstenMMVP Tuesday, October 22, 2013 10:47 AM moved to Site and Client Deployment ...
    • Edited by Mike.Brannigan Tuesday, October 22, 2013 11:44 AM
    Tuesday, October 22, 2013 10:16 AM

Answers

  • An entire identical environment was built but using iSCSI for the shared storage and the setup continued as per expected and installation was complete.

    There is evidently a problem with the setup attempting to query the file format (for whatever reason) of the SQL Serve database store and SMB shares are not providing a valid results whereas "attached" drives like iSCSI or Fibre Channel are OK.

    I have logged a bug report with Microsoft about this.

    Mike

    Thursday, October 24, 2013 2:34 PM

All replies

  • Minor update - taking out the SCC 2012 R2 disk and using a SCCM 2012 SP1 produces exactly the same result - the setup cannot locate an NTFS volume on the SQL Server (obviously trying to access it by name which is the cluster projected name and VIP, where the Admin shares are no longer accessible by that method since a change made by Microsoft in an early version of Windows Failover Cluster I think around the 2008 R2 time frame).

    Surely someone has SCCM 2012 R2 against a fully patched SQL Server 2012 SP1 cluster on Windows Server 2012 R2.

    Tuesday, October 22, 2013 4:00 PM
  • Have you examined the setup log to see the explicit detail of what its trying to access?

    If this verifies what you've said above, you've most likely found a bug and should contact CSS. Note also the dmin share access by virtual name goes back further than Server 2008 R2 even: http://social.technet.microsoft.com/Forums/windowsserver/en-US/69088b08-42a5-4b7a-bde3-ebdab2f1492c/admin-share-access-denied-via-cluster-name?forum=winserverClustering


    Jason | http://blog.configmgrftw.com

    Wednesday, October 23, 2013 5:35 PM
  • Hi,

    Yes h setup log is not much help the last few entries are related to the SQL server setup bits but give no real clue

    INFO: 'SQL-03.bujinkan.shinobi.com' is a valid FQDN.  $$<Configuration Manager Setup><10-23-2013 13:34:33.583-60><thread=3052 (0xBEC)>
    INFO: Read SQL Data and Log file Path from script file if specified.  $$<Configuration Manager Setup><10-23-2013 13:34:33.583-60><thread=3052 (0xBEC)>
    INFO: SQL Data file Path not specified, using default.  $$<Configuration Manager Setup><10-23-2013 13:34:33.583-60><thread=3052 (0xBEC)>
    INFO: SQL Log file Path not specified, using default.  $$<Configuration Manager Setup><10-23-2013 13:34:33.583-60><thread=3052 (0xBEC)>
    INFO: This isn't a named instance SQL Server.  $$<Configuration Manager Setup><10-23-2013 13:34:33.583-60><thread=3052 (0xBEC)>
    INFO: SQL Server instance name (pSetupInf->SqlInstName):   $$<Configuration Manager Setup><10-23-2013 13:34:33.583-60><thread=3052 (0xBEC)>
    INFO: SQL Server master database (pSetupInf->SqlMasterDB): master  $$<Configuration Manager Setup><10-23-2013 13:34:33.583-60><thread=3052 (0xBEC)>
    INFO: Site SQL Server database name (pSetupInf->SqlDatabaseName): CM_SHI  $$<Configuration Manager Setup><10-23-2013 13:34:33.583-60><thread=3052 (0xBEC)>
    INFO: Site SQL Server computer name (pSetupInf->SqlServer): SQL-03.bujinkan.shinobi.com  $$<Configuration Manager Setup><10-23-2013 13:34:33.583-60><thread=3052 (0xBEC)>
    INFO: Site SQL Server Data File Path (pSetupInf->SqlDataFilePath):   $$<Configuration Manager Setup><10-23-2013 13:34:33.583-60><thread=3052 (0xBEC)>
    INFO: Site SQL Server Log File Path  (pSetupInf->SqlLogFilePath):   $$<Configuration Manager Setup><10-23-2013 13:34:33.583-60><thread=3052 (0xBEC)>
    INFO: Site SQL Server service port : 1433  $$<Configuration Manager Setup><10-23-2013 13:34:33.630-60><thread=3052 (0xBEC)>
    INFO: Site SQL Server SSB port : 4022  $$<Configuration Manager Setup><10-23-2013 13:34:33.630-60><thread=3052 (0xBEC)>
    Removed SQL alias SQL-03.bujinkan.shinobi.com successfully.  $$<Configuration Manager Setup><10-23-2013 13:34:33.760-60><thread=3052 (0xBEC)>
    INFO: Registered type SQL-03.BUJINKAN.SHINOBI.COM MASTER for SQL-03.bujinkan.shinobi.com master  $$<Configuration Manager Setup><10-23-2013 13:34:33.775-60><thread=3052 (0xBEC)>
    INFO: Registered type SMS Master for SQL-03.bujinkan.shinobi.com master  $$<Configuration Manager Setup><10-23-2013 13:34:33.775-60><thread=3052 (0xBEC)>
    INFO: Registered type SQL-03.BUJINKAN.SHINOBI.COM CM_SHI for SQL-03.bujinkan.shinobi.com CM_SHI  $$<Configuration Manager Setup><10-23-2013 13:34:33.775-60><thread=3052 (0xBEC)>
    INFO: Registered type SMS ACCESS for SQL-03.bujinkan.shinobi.com CM_SHI  $$<Configuration Manager Setup><10-23-2013 13:34:33.775-60><thread=3052 (0xBEC)>
    INFO: SQL Connection succeeded. Connection: SQL-03.BUJINKAN.SHINOBI.COM MASTER, Type: Unsecure  $$<Configuration Manager Setup><10-23-2013 13:34:33.775-60><thread=3052 (0xBEC)>
    INFO: SQL Server SQL-03.bujinkan.shinobi.com is clustered.  $$<Configuration Manager Setup><10-23-2013 13:34:33.775-60><thread=3052 (0xBEC)>
    INFO: Enough free disk space.~  $$<Configuration Manager Setup><10-23-2013 13:34:33.996-60><thread=3052 (0xBEC)>
    INFO: Checking Active Directory, domain controller for domain BUJINKAN is \\DC-01  $$<Configuration Manager Setup><10-23-2013 13:34:34.122-60><thread=3052 (0xBEC)>
    INFO: SQL Server version detected is 11.0, 11.0.3128.0 (SP1).~  $$<Configuration Manager Setup><10-23-2013 14:02:34.309-60><thread=3052 (0xBEC)>
    Setup has detected that there is not an NTFS drive on the remote SQL Server SQL-03.bujinkan.shinobi.com, the SQL Server must have at least one NTFS drive.~~~~  $$<Configuration Manager Setup><10-23-2013 14:02:34.309-60><thread=3052 (0xBEC)>

    As you can see it looks all good (connections, checks etc) then suddenly after almost exactly 30 mins from the second to last post and the last it repeats what is on the on screen dialog about there not being an NTFS volume on the SQL Server. (SQL-03 is the cluster projected name of my SLQ Servers SQL-01 and SQL-02)

    Is there any way to get more verbose logging from the setup engine?

    Mike

    Wednesday, October 23, 2013 6:35 PM
  • No to the verbose logging during setup to my knowledge.

    Is the account you are using to install ConfigMgr a local admin on all nodes of the SQL cluster?


    Jason | http://blog.configmgrftw.com

    Wednesday, October 23, 2013 7:57 PM
  • Hi,

    Yes the account being used for installation of SCCM is a member of the Domain Admins group and therefore a member of the local Administrators group on each cluster node (also explicitly a member of the group too), also the potential SCCM server's machine account is also a member of the local Administrators groups on each node (as well as full sysadmin within SQL Server) just to be sure.

    Mike

    Wednesday, October 23, 2013 8:43 PM
  • Hmmm, given that many folks have installed on a failover cluster since 2008, I'm not so sure the admin share issue is the culprit.

    Do you have other security software in place that could be getting in the way?


    Jason | http://blog.configmgrftw.com

    Wednesday, October 23, 2013 8:59 PM
  • Interesting question.

    They are running the built in Firewall and Forefroint Endpoint Protection 2012 (all latest updates).

    I am currently removing both and will retest.  NOTE: On an identical remote stand-alone server (with Windows Firewall and FEP)  the install happens without issue - so this really does look like something related to clustering

    As an aside I have also installed SCVMM 2012 R2 database to the same cluster today - no issues.  So this is definitely something related to the specifics of the SCCM 2012 R2 setup and clusters

    Mike.

    Wednesday, October 23, 2013 9:08 PM
  • With all security software removed from the cluster nodes and restarted - setup still fails as above with unable to find NTFS formatted volume on the sever (by its cluster projected name) after a 30 minute "hang"

    Mike

    Wednesday, October 23, 2013 9:28 PM
  • I have a thought.

    The SQL Server Cluster is using an SMB Share from another Windows File Sever as the "shared" storage location where SQL Server has placed the DATA folder and where the db and log  files reside.  This is a fully supported SQL 2012 config.

    I wonder if the SCCM setup process is being too clever and trying to ascertain the format of the file system hosting the SQL database and log storage paths, which it would not be able to tell as these are SMB share from elsewhere and certain API calls will not return an NTFS file system type, unlike a "mounted" volume such as a LUNs or iSCSI target where the "disks" appear native/attached and their format is easily queryable.

    Anyone like to comment on my hypothesis ?

    Wednesday, October 23, 2013 9:38 PM
  • An entire identical environment was built but using iSCSI for the shared storage and the setup continued as per expected and installation was complete.

    There is evidently a problem with the setup attempting to query the file format (for whatever reason) of the SQL Serve database store and SMB shares are not providing a valid results whereas "attached" drives like iSCSI or Fibre Channel are OK.

    I have logged a bug report with Microsoft about this.

    Mike

    Thursday, October 24, 2013 2:34 PM
  • An entire identical environment was built but using iSCSI for the shared storage and the setup continued as per expected and installation was complete.

    There is evidently a problem with the setup attempting to query the file format (for whatever reason) of the SQL Serve database store and SMB shares are not providing a valid results whereas "attached" drives like iSCSI or Fibre Channel are OK.

    I have logged a bug report with Microsoft about this.

    Mike

    Has this issue been addressed by the product team yet?

    I believe I may be running into this issue.  Using SQL Server 2012 SP1 in two node cluster using SMB shares for data/log files.

    When installing SCCM 2012 R2 get to the data/log file location screen and the browse buttons are greyed out and you can't enter the path manually either.

    Monday, February 10, 2014 7:30 PM