Clients with Incorrect Network Information

By ServerWatch Staff (Send Email)
Posted Apr 2, 2003


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 and\or 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 or\and 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.

Page 1 of 1


Comment and Contribute

Your name/nickname

Your email

(Maximum characters: 1200). You have characters left.