I'm assuming not many people on this forum use SMS, but just in case;

I'm trying to install SMS 2003 on a Dell server with W2k Pro Server OS, SP4, with MSSQL7sp3. The server is on a NT4 domain. The server was our old SMSv2 server, which I have removed using the control panel function.

I've installed SMS 2003 using standard security, with the install files on the second partition and the database on the primary partition, as the secondary has the most room. I've also installed the admin console on the server. It is the only sms site, and installed as primary.

When I open up the admin console the connection to the site database fails, and the connection wizard seems pretty useless to provide any help. It appears that is looking for the database at \\server\root\sms\site_... But the database is at \\server\c$\smsdata. (I cant move it to root, as this seems disabled on this machine).

I can only think that old registry entries from the v2 install are causing errors, as the book I spent £30 of my own money on is no help. That said I'm reluctant to format the beast, as it holds the site's Software directory.

Could anyone with experience of setting up SMS 2003 let me know if I've missed anything.

Dani AI

Generated

This problem is almost always a WMI / SMS Provider issue — the Admin Console talks to the site through the WMI namespace (for example \server\root\SMS\site<sitecode>), not by browsing a file share. Seeing \server\root\SMS\site... in the connection wizard means the console is trying to reach the SMS Provider (which then talks to SQL), so a misplaced or corrupted provider/WMI namespace will make the console fail even when the database files themselves are fine. (learn.microsoft.com)

Quick checklist to try before a rebuild (these map to Microsoft troubleshooting steps):

  1. Examine the logs on the site server: SMS\Logs\AdminUI.log and SMSProv.log for provider errors. (ftp.zx.net.nz)
  2. Use WBEMTest locally on the site (run wbemtest) and connect to \\<site_server>\root\sms. Enum Classes → SMS_ProviderLocation → Instances and check the NamespacePath value; if you find entries for old site codes delete them (and delete matching __Namespace.site_xxx entries). (jeffpar.github.io)

Check permissions and DCOM: confirm the SMS Admins group has Enable Account and Remote Enable on Root\SMS and Root\SMS\site_<sitecode> (use wmimgmt.msc → Security). Also verify DCOM defaults (Enable Distributed COM, Authentication = Connect, Impersonation = Identify) and, if Server 2003 SP1 or XP consoles are involved, add console users to Distributed COM Users or adjust the anonymous/DCOM limits per the KB. These settings are common causes of connect failures. (learn.microsoft.com)

If you see provider‑load errors (WMI 0x80041013 / Smsprov failures) you may need to re-register the provider and recompile provider MOF files: stop SMS services and WMI, regsvr32 /u Smsprov.dll then regsvr32 Smsprov.dll (replace with hotfix file if required), run mofcomp on failing MOF if advised, then restart services. If the provider binary is missing dependencies you may need to copy the required VC runtime files into the SMS\bin\i386 folder first. If none of this repairs the provider, a clean reinstall or the full rebuild used is the last resort. (ftp.zx.net.nz)

If helpful: capture AdminUI.log and SMSProv.log excerpts and the NamespacePath values from WBEMTest before making changes — they show exactly what the console is trying to use and make any fixes reversible. ’s point about learning SMS is spot on; these WMI/provider tasks are the usual troubleshooting steps for this exact symptom. (learn.microsoft.com)

Rebuilt server today, its working now.

Anyone need some help with SMS 2003 I'm your man.

You are the man,

I learned sms on my own by puschasing a cbt from

Sms is getting very big and I have a friend making 80.00 per hour contracting.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.