GuidesClients with Incorrect Network Information

Clients with Incorrect Network Information





by Dana Daugherty

While this article is
technically related more to networking than SMS, it could save
you some headaches. You never know, it may show it’s ugly head
in your enterprise.
The article describes
a problem we experienced with SMS clients automatically
uninstalling themselves. We take you step-by-step through the long
process of identifying the network issue, troubleshooting the
problem, and eventually finding a solution.

THE
PROBLEM

We were experiencing
a problem where SMS clients were uninstalling themselves. Not
all clients, just those installed on Windows 98 machines; and
not all 98 machines were exhibiting this behavior, either.
Being that the client relies so heavily on the subnet
information, it didn’t take long to figure out that our real
problem was a network issue.

 Win 98
workstations were not communicating with DHCP servers
properly, which resulted in the clients using default class A
(255.0.0.0) and default class B (255.255.0.0) subnet masks. In
our organization we have a default class B network address and
use a class C subnet mask.

Our network address
was 150.77.0.0 with a subnet mask of 255.255.252.0. The
clients IP address was 150.77.28.105. The client with this
problem would think his address was 150.77.0.0 or 150.0.0.0,
depending on which subnet mask it picked up.

This issue only
seemed to cause problems in my world because the workstation
could communicate with everything on the network just fine.
Let’s say the client above, 150.77.28.105, was installed at a
site with a SMS Site Boundary of 150.77.28.0. And let’s say it
picked up the 255.255.0.0 mask. As soon as it would log on
with this erroneous address it would uninstall itself. It did
this because it could contact another site with this network
address (150.77.0). Not cool! If the above client picked up
the 255.0.0.0 subnet mask it would uninstall itself within 30
days because it logged on with a network address that was not
in the boundary of any of my sites.

SMS WORKAROUND:
CLITRAVL to the RESCUE!

It was apparent to
me, after a couple of days of trouble shooting, that I had to
do something to stop these clients from uninstalling
themselves. From the SMS 2.0 Support Tools, Clitravl.exe
emerged as an option.

Basically, Clitravl
is a command line interface utility for turning Travel Mode on
and off. It also can turn user prompts off. User prompts are
one of the most unattractive aspects of Travel Mode. Turning
Travel Mode on gives a client the ability to travel to other
SMS sites andor networks with no SMS sites without an
automatic uninstall of the SMS client
software. 

As a workaround, I
implemented clitravl.exe on all machines in the domain using
an SMS package. I also created a SMS Installer wrapper for
SMSMan.exe that would call clitravl.exe with the appropriate
switches.

With this approach, I
had the bases covered. Current clients wouldn’t uninstall themselves. Travel
Mode would be applied as we ran the install for clients that
had already uninstalled themselves and for new client
installs.

For more information
on Clitravl.exe and the client uninstall behavior take a look
at my article
on Clitravl.exe

TROUBLE
SHOOTING

This problem was
extremely difficult to trouble shoot. It would happen very
sporadically. Using WINIPCFG we could, of course, see the
subnet mask the workstation picked up. Also in the Lease
Expiration box there was no date. If we would select release
and then select renew, the workstation would pick up the
proper IP information. The SMS client could then be installed.
So while we could cause the workstation to function properly,
we could not recreate the problem.

After implementing
Clitravl.exe to all clients we could begin to locate more
workstations with this issue. In their respective collections
clients would have a NO in the Client orand Assigned columns.
Prior to using Clitravl, clients would just uninstall
themselves and we would have no way of finding them.

I worked with
seasoned veterans from our network management department for
weeks on this issue. We used Netmon, and NAI Sniffer to
capture and analyze packets. We opened a case with Microsoft
and worked directly with their network and Win 98 engineers.
They came to the conclusion that our ghost images were
corrupt. This theory was never proved though. Several months
went by with no solution.

THE
SOLUTION

Recently, after some
new features came available, we decided to upgrade the code on
our Bay Networks Baystack 450T switches. We moved from image
code version 1.3.0 to 3.1.0.2. These switches are used at all
of our sites. After our pilot site was upgraded we noticed
that there were consistently 0 SMS clients at this site
showing as not assigned.

We then decided to
continue upgrading the remainder of the Baystack switches.
Once we did this, low and behold, no more client network
issues.

Until this point, we
really had no reason to upgrade these switches. As far as we
knew they were operating properly. With the exception of the
SMS client problem, there were no issues. The solution was
really quite simple. It was staring us in the face all along
— we just didn’t know it. 

CONCLUSION

In reality, this
problem didn’t need to occur for so long. Unfortunately, the
limited resources of our IT staff had something to do with it.
If we had the necessary IT staff members to complete the work
required, someone could have focused on the issue. Then we
would have experienced a more timely solution.

Some of the best workarounds and
utilities are located in the SMS 2.0 Tools and the Microsoft
Back Office Resource Kit (BORK).  Without the use of CliTravl.exe our
SMS implementation was not only unreliable, it was dead in the
water. While the documentation for some of these tools is
sketchy, at best, they can be a big help. By visiting news
groups and Web sites like this you can find
creative, real world uses for these utilities.

As I said, we were
able to keep the SMS client installed on the machines
experiencing this problem using Clitravl.exe. Unfortunately,
the software and hardware inventory was dumped from the
database. The cause of this is now evident. There was no SMS
Server code to support inventory being sent from a client with
a network address outside its Site Boundary. A hot fix is now
available for this issue. For more info on this hot fix and
using Site4c.exe take a look at this article on supporting
mobile clients
.

Latest Posts

Related Stories