Tivoli Software Distribution

This page details General problems and issues relating to Tivoli Software Distribution.

Experiences from the Field of using Software Distribution with Laptops [11/9/02]
"spawn_impl, could not spawn method as user ..." Error in Package Log file [14/7/02]

Experiences from the Field of using Software Distribution with Laptops

I was wondering if anyone out there had any "real world" experiences they'd care to share on using Tivoli Software Distribution to deploy to laptops. I know that SMS doesn't handle laptops very well (which is why MS are writing a new mobile client in Topaz), and was wondering if Tivoli handled things any better?

For example:

Can you tell Tivoli to only deploy to a laptop when it's connected through a link with a certain amount of bandwidth?

Can I force a distribution regardless of the connection type/speed (for example in the case of anti-virus updates)?

How well does Tivoli handle laptops moving between locations and potentially IP subnets/TMRs?

What about packages being interrupted mid-download?

If I move offices, is Tivoli clever enough to pull any new software from the office I'm sat in or will it always pull it from my "home" office?

Contributed By: Leon Adato, Gary Hamilton, Marc Remes
Can you tell Tivoli to only deploy to a laptop when it's connected through a link with a certain amount of bandwidth?
Tivoli has developed the Mobile Console in 3.7.1, Software Distribution 4.1 to handle the specific software delivery requirements for laptops. There's no way to 'only deploy when connected with certain amount of bandwidth' from an Administrator's point of view, but with the Mobile Console the user has the capability to defer a package distribution/installation when the operation comes in at an inconvenient time (in brief, it allows the user to say 'yes, send and install now', or 'send but don't install' or 'don't send now').

Once you send out a distribution, it is going to go from the Gateway to the Endpoint in compressed format without a whole lot of reflection on what the conditions are.

Can I force a distribution regardless of the connection type/speed (for example in the case of anti-virus updates)?
The Administrator can send 'hidden' distributions which the user doesn't see in the mobile client and therefore they can't interact with them (for example anti-virus update).

How well does Tivoli handle laptops moving between locations and potentially IP subnets/TMRs?
Mobile Endpoint support across TMRs would not be possible. The LCFD login would be rejected because the region number held in LCF.DAT would be different from the Endpoint Manager's.

In general, Tivoli's design is that the Endpoint will always talk to it's 'home' Gateway, regardless of where you've moved it. So if you build the PC in an office in Ohio, and then it travels to South Africa, the PC will try to connect to the gateway in Ohio. This is a feature, not a bug.

Within the same TMR, moving an Endpoint to it's nearest Gateway is relatively simple. If the PC moves between TMR's, things are more complex but we are able to do it in our environment (250,000 systems worldwide, many TMR's and even many separate Tivoli installations).

What about packages being interrupted mid-download?
Starting with Software Distribution 4.0, there is a feature (MDIST2), called 'checkpoint restart' which is basically having the distribution pick up where it left off, if it is interrupted for any reason.

The roam_endpoints parameter on the distribution command does kind of 'checkpoint/restart' across gateways. I don't know about crossing TMRs.

If I move offices, is Tivoli clever enough to pull any new software from the office I'm sat in or will it always pull it from my "home" office?
Yes and no (don't you love those answers). It depends on how you design the distribution. You have a couple of choices:

Distribute only a batch file, which says 'connect to this share on a local server, pull these files, install'. Of course, you don't get any of the support of checkpoint restart, use the mobile console, etc because all you are really doing is sending and launching a batch file. On the other hand, you could do all sorts of detection (line speed, bootup configuration, etc) based on your ability to script using VBS, perl, etc and you could really control what happens and when.
Starting in Software Distribution 4.1, you can specify an alternate location for the pickup of the distribution. This could be from a CD, a local server, etc.

Some other things to consider is that you have to 'tune' your Endpoint to make sure it connects in a dialup mode at all. Remember, if you dial up, the Endpoint could already be in 'isolation' mode because it has started and there was no network connection at that time. So depending on your timeouts, you are not guaranteed a connection to Tivoli each and every time a mobile endpoint connects to the network.

If a Gateway goes down and the Endpoint can't connect to anything else, it is said to be in 'isolation'. Once a Gateway comes back, the Endpoint re-connects and gets it's information in sync again. It's just a matter of cycles. If you look in LAST.CFG, you will see the following lines which indicate the cycle characteristics:

bcast_disable=1 - Set to 0, an endpoint will broadcast to any Gateway on the same IP segment for a login. Set to 1, it will only send a login request to the 'lcs.login_interfaces' gateway.

udp_interval=30 - How many seconds between a connection attempt

udp_attempts=10 - How many connection attempts to make

login_interval=300 - How many seconds to 'sleep' after you have tried the full number of udp_attempts.

So what happens, if the Endpoint can't connect to the gateway is this:

It tries to connect to the gateway 'udp_attempts' times, waiting 'udp_interval' seconds between each attempt. Then it sleeps for 'login_interval' seconds before trying the cycle all over again. Note that the above values are not typical.

"spawn_impl, could not spawn method as user ..." Error in Package Log File

I've got a very interesting problem with Software Distribution on Framework 3.7.1. To test Software Distribution I've sent the Software Package Editor to the TMR server and some other Endpoints in my environment. However, I've just tried to send Microsoft Office to a Windows 2000 Endpoint and it fails. If I look in the Package log file I can see the following error message:

spawn_impl, could not spawn method as user tivadmin

If I try sending the Software Package Editor to the same Endpoint it also fails with the same error. What I don't understand is why it's failing as it's worked fine on other Endpoints. "tivadmin" was the name of the account I installed Framework under.

Contributed By: Cliff Hobbs [MVP SMS]
The problem in this particular case was caused by the Windows 2000 machine being in a completely different domain to the TMR server and the other Endpoints that software had been successfully sent to previously. As the "tivadmin" account didn't exist either on the domain the Windows 2000 Endpoint was a member of, or locally on the machine itself, the distribution was failing.

To overcome this problem the following widmap command was used to reset the entry for the "w32-ix86" platform from "tivadmin" to "BuiltinNTAdministrator" (which is what it is set to by default under Framework 3.7B, whereas under 3.7.1 it's set to the ID of the account used to install Framework):

widmap add_entry root_user w32-ix86 BuiltinNTAdministrator

The package was re-distributed and worked correctly.