Troubleshooting “Connection failed to Site Server”

A.Stokes

One of the biggest problems that I’ve
seen has been the almost monthly lost connection to a site server. I’m ashamed
to admit that my troubleshooting technique in this area has been “reboot and
pray”.

One of the biggest problems that I’ve seen has been the almost monthly lost connection to a site server. I’m ashamed to admit that my troubleshooting technique in this area has been ‘reboot and pray’.

Well,
after this failed, I decided to brush off the trouble shooting skills and dig
in. After some research in Technet, the SMS newsgroups, and every other resource
I had at my disposal, I was still unable to connect to the site server. It
finally took a call to Microsoft to get the information necessary to fix the
problem. 

When
troubleshooting a connectivity problem to a site server, you have to start with
the basics. Do you actually have network connectivity to the server? 
This is the most basic problem and one I have seen actually stump a few
people. It’s so easy to dig right in to an application problem and ignore the
physical layer. SO, get that out of the way. Ping it.

Once
you’ve established that the server is up and running, you need to go in a
little deeper.

There
are 3 areas of consideration when troubleshooting access to the SMS provider and
the site server. 

1.                   
Do you have the necessary privileges to the SMS provider on your site
server?

2.                   
Do you have the necessary security rights to the database?

3.                   
Do you have the necessary privileges as far as WBEM is concerned?

4.                   
Is WBEM working? 

Area
one is an easy one.  In order for
you to have access to the SMS provider on your site server, you need to be a
member of the

Local
SMS Admins group on your site server. I’ve found it is much easier and cleaner
to add a global group from your domain to the local SMS Admin group rather than
adding specific users. It makes administration a little easier.  

Area
two is a question that can be answered with another question. Were you able to
access the site server before? If so and barring the possibility another
administrator has removed those rights, you most probably have rights to the
database. You learn in SMS that having access to the SMS provider is not enough
to allow you to get into the database. Each area of SMS in the Administrator
console carries its own specific permissions. This allows you to tailor the
Administrator console for each user/administrator. For example, you may wish to
give one administrator access to a group of machines for Remote Tools and deny
another. I’ve found this useful in our organization where we have a group of
technicians responsible for a specific grouping of clients. 
Modifying the permissions for each collection allows the technician
access to their particular users and no one else.  

Area
three is answered using a utility called wbemperm. This neat little utility is
located in your %windir%system32wbem directory.

By
using wbemperm, you can determine who has the rights to access the server via
wbem. At a minimum, the local SMS Admin group has access to the server with the
following permissions; Execute Methods , Enabled, and Schema Access Level: Write
Instance  

After
you have verified the first 3 conditions, test your connection to the database
by using the wbemtest utility located in the same place as the wbemperm utility.
One thing that took me a while to realize is that you don’t need a password. I
couldn’t get it to connect to any of my site servers until I entered all of
the information except for the password.  

If
wbemtest doesn’t work, pay attention to the error message it gives you. Most
of the connectivity problems I have found that didn’t involve a security issue
have been due to a WBEM problem. If you get the error “Invalid namespace”,
then you know that you have a problem with WBEM. Another way of testing your
connectivity to the site server is by using the “smsextract” query in the
supportability files. This will also tell you if there are any problems
connecting to the site.

 If
you have gotten this far and not found the problem, the only thing left to do is
to rebuild the namespace.

Recompiling
the mofs located in the smsbini386 directory will rebuild the namespace.

This
has to be done on the site server itself. Open a command prompt and go to the smsbini386
directory. Once
there, enter the following commands:

mofcomp
smsprov.mof

mofcomp
sms_schm.mof

mofcomp
smsstub.mof

mofcomp
pollprov.mof

mofcomp
netdisc.mof

mofcomp
cpprov.mof

Recompiling
the mofs will rebuild the name space. Once this is done, you should once again
have connectivity to your site server.