The ConfigMgr (Don't you worry, SMS 2003 works exactly the same) Provider is somewhat of an unknown component when it comes to designing hierarchies. For people who haven't got a clue what the provider is; it's the WMI engine responsible to talk to the DB etc (root\sms_site_XXX).

You can control where the Provider gets installed in the installation sequence when doing a ConfigMgr install, or if you are installing it unattended, use the SDKSERVER=SERVERINUPPERCASE value in your answer file. For Primary sites, the SDKSERVER means where the Provider goes, for the AdminUI, it means what server to point at, makes sense as the Admin console talks to the provider. By default the Provider goes onto the SQL box, and if that is not allowed for some reason, it can be on the ConfigMgr box itself. But did you know that the Provider actually could be on a completely different server?

So what are the main reasons to have your Provider on anything but the SQL Server (Which is the default)?

• Installing ConfigMgr SQL DB in a cluster (The provider can't be on the cluster so normally goes onto the ConfigMgr box instead)
• You have a vast army of chipmunks connecting with their ConfigMgr consoles, over a thousand I would say...
• You want to create a weird setup that is tricky for ISV's to detect and support
• You are a bit dim...

As we see above, there are a couple of instances where the Provider might end up in a few different places...

Andreas Hammarskjöld | System Deployment Practice Lead | 1E Ltd |
andreash@1e.com | www.1e.com