Guides Troubleshooting "Connection failed to Site Server"

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

mofcomp cmprov.mof

 

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

Latest Posts

How to Convert a Physical Computer to a Virtual Machine

Many organizations are implementing virtualization technology into their networks to convert physical computers to virtual machines (VM). This helps reduce overall physical hardware costs,...

HPE ProLiant DL380 Gen10: Rack Server Overview and Insight

The HPE ProLiant DL380 series has consistently been a market leader in the server space. The Gen10 released in 2017 further increased HPE's market...

Best Server Management Software & Tools 2021

Finding the best server management software tools for your organization can have a major impact on the success of your business operations. Manually handling...

IBM AS/400: Lasting the Test of Time

Some server operating systems (OS) were built to survive the test of time – the IBM AS/400 is one such system.  The AS/400 (Application System/400)...

What is Disaster Recovery?

The modern organization's heavy dependence on using data to drive their business has made having a Disaster Recovery (DR) plan in place a necessity....

Related Stories