hi, we recently ran into a problem with our sccm installation. our infrastructure is like this: windows 2003 domain, sccm 2007 (4.00.5931.0000), sql server 2005 in a 2 node active/active cluster with about 4 named sql instances running on different nodes/drives. at install everything worked out ok, the database was created successfully in the right place and everything was shiny for quite some time. then recently, due to patching and testing, the clusterinstances for our sql system changed nodes and hell broke lose. our site status turned red and couldn't be convinced to return to a green state. we narrowed down the problem to a point where we see that the SMS_<site code> directories on the clusternodes were created on harddrive-volumes which didn't belong to the clustergroup of theinstance the sccm-db is on and when sccm component manager tries to check for free space on these volumes it naturally fails as they're currently connected to the respective other node. as the sms services on the nodes also run from the original install-paths they also failed for one of the nodes which could be rectified by moving the directories to local paths and changing the registry entries for the respective services - this did help for the service to start, but didn't calm the component manager as he gets his path-information from somewhere else it seems. has anyone else experienced something like this or can someone guide me to a hint on how i could possibly solve this situation? best regards, andreas

Hello Andreas, Can you restateexactly what the problem is you're having (saying itdifferently)? I'm having a difficult time understanding what the issue(s) are and what you would like to resolve. Thanks

I'm gonna try, when SCCM is installed to a remote sql instance it not only installs the databases on that instance but also some local files on the database servers. These files are used for creating backups i suppose from looking at their names and a service is run from binaries in these directories. Now the paths in which these files reside (something like "<driveletter>:\SMS_<mp servername>")is configured somewhere for the component manager to check for free space on the volumes they are on. We installed our database to a named instance on aSQL cluster. The database is created and functioning ok, it resides on the correct named instance and in the correct cluster group, but the mentioned directories were created on totally different drives on the cluster nodes, which belong todifferent cluster groups and therefor can switch between nodes. when these drives (meaning the clustergroups these drives belong to) move from one node to another the component manager fails with the check for free space on these drives asit is looking for the resource on the wrong clusternode. This is where we are at now. Our site status summary turned red (failing to connect to \\clusternode_a\moved_drive_letter$\SMS_<mp_servername) and i'd like to know if there is any possibility of configuring these paths after installation so we can move them to a location thatis local to our clusternodes as it is them which are added as site systems not the named instance the database is on. Sorry if i can't be much clearer but english isn't my native language and the situation isn't exactly simple to describe, Andreas

This is a "feature" of the product. By default it will install the components on the disk with the most space. However, in a cluster scenario you want to make sure they are installed on a non shared disk on each node. Place an emptyfile named NO_SMS_ON_DRIVE.SMS at the root of each drive where you DO NOT want it to install the components and it will avoid using those drives i.e. place it on all drives except where you want it to install the components. This is only effective when it installs the components though so cannot be used to move them afterwards.

Thanks for the answer! So it's back to install from scratch for me as it seems. Sad that there still is no way to move these files or even some dialog to accept the "detected" destination paths during install but i guess we have to live with that. Another lesson learend the hard way. Best regards, Andreas

Do not install the role to the Virtual or cluster-name, but deploy the role to the a (or each) cluster node.Determine which cluster node you want to deploy the role and disconnect the shared storage from the node, thendeploy the role to the node. The shared drive will not be available for ConfigMgr to try to deploy files to it.

Was this information included in the SCCM documentation? I have the same issue in that when we installed ConfigMgr, we pointed the install to the Virtual Cluster SQL instance as the documentation states. We were running fine until we did a planned cluster failover. Now we are getting a critical site system status for ConfigMgr component server. I think this is due to components being installed on both cluster nodes, but on the active cluster node we had shared storage (which is not available when in passive mode) and that is where the components were installed. So...my question is this: Is there a way to resolve without having to do an entire reintstall?

...did you find a way to resolve that issue without reinstalling the entire software? Thanks. Melanie

I'm in the same situation. I'm waiting for a solution without re-installing.

I'm encountering this issue as well. Please add me to the list of people hoping for a solution without re-installation.

I don't know if there is a supported way to move them once installed. However, one thing you could do is move the database back onto the site server temporarily, or maybe onto another server, and then move it back to your cluster again. There are sections in the product documentation for how to move the database.

And I'm really, really bad at patience. I've tried something, and it looks like it might have worked. It appears that when the SCCM database was installed to the cluster, it installed some components for the SMS_SITE_COMPONENT_MANAGER to the local drive on the passive SQL node, and to one of my shared drives on the active node. (In the <drive_letter>MS_<SCCMServerName> directory.) It is apparently this that is causing errors when I failover the active node. 1. I copied the directory from the shared drive to the local drive on my server that HAD been the active node, which now passive. 2. In the registry on my SCCM Server, I tracked down - "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Components\SMS_SITE_COMPONENT_MANAGER\Multisite Component Servers\<name_of_ActiveSQLNode_during_installation>", and changed the Installation Directory from the shared drive to the local drive. It looks to me to have resolved the issue. I'd be curious if anyone else is looking at this from a test instance. Or if someone can comment whether this will break something I'm not yet contemplating. I'm still new to SCCM.

Good find. I did try this on my SCCM server that I have not put in production yet. I made the correction on the SCCM server there are also services that need to be change on the SQL server. I cannot remember the key, but I searched for the path. I also moved the files (I put everything to the C$ on the SQL servers). Everything is working. The backups have run successfully.

Hi,i've the same problem and trying to move the location of the sccm sql site backup service.Did you had any problems after you changed the registry key and copied the files to the local drive?How is your service executable (ImagePath) now listed in the registry? HKLM\System\CurrentControlSet\Services\SMS_SITE_SQL_BACKUP_<SiteServerName>Thanks a lot!

Hi, I had the same problem when I installed SCCM 2007 SP2 R2 to clustered SQL. This was very annoying and as Stuart James wrote this "feature" should be fixed. There should be dialog during the setup so you can choose where to create these folders. But let me tell you solution. 1. I created db called SMS_BGD. I put data and log files to drive T which is clustered. 2. After installation I had two different drives configured as site_backup_path (if I can call them this way) one for each sql node. Under Site System Status I had \\SQL_NOD1\v$\SMS_SCCMSERVER \\SQL_NOD2\r$\SMS_SCCMSERVER As Stuart James wrote V disk and R disk are disks with maximum free disk space and that's why they are chosen automatically during SCCM setup. SOLUTION: Change Service Path from Clustered Disk to local disk on Each Cluster Node . For instance (c:\SMS_SCCM-01) You have to open regedit from node name, not clustered name (my cluster name is SQL1 and node name is SQLNOD1) if you do not open this way you will not see Wow6432Node. HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\SMS\Tracing\SMS_SITE_SQL_BACKUP_SCCM-01\TraceFilename HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SMS_SITE_SQL_BACKUP_SCCM-01\ImagePath Then as Razmus wrote: In the registry on my SCCM Server, HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Components\SMS_SITE_COMPONENT_MANAGER\Multisite Component Servers\<name_of_SQLNodes> and changed the Installation Directory from the shared drive to the local drive for both SQL nodes. Then copy folder SMS_servername from "wrong" disk to new location. I restarted SCCM server, waited 15-30min and new path was in use. Regards from Serbia.

thanks Mladen, it saved me a lot of time...