Tivoli - Where to Start? 5

[SpaceCoast]

We have a small site (about 150 users) and would eventually like to use Tivoli for installing software/patches on our users' systems, and for doing software and hardware inventory. We have the software, we have the manuals (boy, do we have manuals!), and we have some systems we can use for testing. We'll be going to training in a few weeks for this software, but would like to set up a testbed network to play with and familiarize ourselves before we go. Where do we begin?

Keep in mind that we would like our setup here to be as basic as possible and include very few "layers" due to the small number of client systems. We already have a testbed network set up and can add additional systems as needed. So far, it's just two Windows 2000 Server systems. One is set up as the PDC for the domain and the other is going to be the first Tivoli management system. We're about to add a third system with XP to be our "client." Are any more systems needed for this test setup or can the one server (the one that's NOT the PDC) provide all the Tivoli management and distribution functions?

What software needs to be installed on which system for the most basic of setups?

 

[rblue]

Our configuration in our development environment consists of one TMR Server and one TEC/Database Server. We're a little bigger company so we actually have application teams that stage the software packages from their servers.

Given the size of your environment, I would say that there's no harm in staging software packages off of the TMR server, but you will need to maintain a good amount of storage.

At Minimum, I would recommend the two server configuration for the sake of stability and scalability. In this configuration, you could theoretically support 2000 endpoints, although you would possibly suffer a good deal of performance degradation.

 

[patlim88]

I agree. We have a test network set up with the same scenario. 1 machine serving as the TMR and one as the endpoint. A good idea is to set up a test database on a machine and let it serve as a database server. Also are you using the the new Tivoli Config manager beacuse if so it will install everything you need onto to the TMR server(ie, Framework, rim objects gateway and so on) Be careful though because installing the framework and other items manually make for good pratice . However you will need to install the Software package editor onto and endpoint which is relatively easy. One tricky things is rim objects. configuring these properly will greatly make testing easier.
For a very simple setup install The Framework on the TMR server and then a gateway and then the Software Dist. product.

 

[ladato]

Looking over your initial requests, I am struck by the fact that you don't really *need* Tivoli for 150 user site.

Now don't get me wrong, I love Tivoli (God knows working on it has helped add value to my kids' college fund for the last 5 years!), but it's definitely a big-guns tool.

To give you a process overview of what you are facing, even on a small scale:

Set up a TMR - this is likely going to be a Windows server box. If you are thinking of Linux I believe it would be a bigger headache than you need. And a Win TMR can handle the load of 150 systems.

You didn't mention whether these systems were all in one place or spread across multiple sites. If it is multiple sites, you *may* want/need to set up other ManagedNode/Gateways.

A quick note about installations. You are going to have to install *and* patch. Tivoli does not have a final-version installation. In many cases you have to install APPx version 4.0, patch to version 4.1, then install one ore more subsequent patches. You will need to do this for the TMR and any other managed nodes. And if you install/reinstall a managed node later, you will STILL need to do the install-patch-patch again process.

Once you have the TMR and/or MN's set up with Tivoli Framework, you will need to set up a database server (unless you already have one. Tivoli supports the major players - Oracle, DB2, MS SQL. But not the freebies - MySQL, etc. Having a database is required for Inventory and if you want to maintain software distribution history (not to mention TEC, but you didn't say you needed that).

Once your TMR and DB is set up, you can then install Inventory and/or Software Distribution. Once again, the process is install, patch, repatch.

*AND* document document document!! You want to document the process of installations because there are some specific settings you will have to pick, and if you are following best practices you will first install in a lab and then replicate the process in production. You want to make sure you are implementing the same way in both places.

OK, so now you have your Tivoli software and your database set up. You now need to start doing some Tivoli design work. You need to set up Policy Regions and Profile Managers, have a solid naming convention in mind (trust me, it's not something you want to have to fix later on!), etc. You may also need to set up the endpoint policy scripts (which means UNIX shell programming or Perl programming). Depending on where the target matchines are located, you might also need to do some repeater (Tivoli repeater, not network repeater) tuning so that the network team doesn't show up at your desk with pitchforks and torches screaming for your entrails on a stick.

Once this is set up, you can look at the process of installing the "endpoint" code on each of your 150 PCs. This can be done in a variety of ways, but sneakernet is obviously your last choice - that's why you wanted Tivoli in the first place, right? Not only do you need an installation plan, you need a re-installation plan. Along with this you might want to consider how you will maintain the "health" of the Tivoli environment - how does Tivoli (and you) know when a machine has been retired, stolen, or just offline for an extended period? How will you handle it? How will new machines get detected and have Tivoli installed? etc etc etc etc.

All of that having been done (and deployed), you can now start doing ongoing regular inventory and software distributions.

Another thing to keep in mind is that Tivoli has very little in the way of meaningful reporting - both the historical reports and the distribution status reports. So you will need to devise ways to show management (or even just yourselves) that Tivoli is working, what it has captured, and where you can improve or fix processes.

In that respect, you should have some information on your environment as it stands today. How long to perform inventory, installation, upgrade and migration activities, etc. Otherwise it will be very hard to show the bean-counters that Tivoli (or any ESM package) has actually brought value to the company.

It's important to keep in mind that Tivoli (and CA Unicenter, and to an extent the mid-level packages like SMS, BMC, and NetIQ are not shrink-wrap, off-the-shelf-and-it-works type apps. They require planning and design on the front end, customization during the rollout, and maintenance, management and administration *of the tool itself* throughout its lifecycle.

The upshot of all of this (and it is admittedly a rambling, off-the-top-of-my-head-at-8:00am kind of essay) is that all of this effort makes sense for a 3,000 - 250,000 system environment because that much effort will be needed regardless of the tool you select. The expectation is that there will be people dedicated to the ESM tool (and nothing BUT the tool) forever and ever and always, amen. But for 150 machines (especially if they are all in one facility), you may be able to achieve a faster implementation and greater functionality with another tool, not to mention being able to get back to other responsibilities which are likely not going to be handed off to another staff member.

While it is true of most posts here, it still bears repeating: The facts expressed here belong to everyone, the opinions belong to me. The distinction is yours to draw.

I welcome questions, comments, concerns and requests for clarification.

Leon
adatole@yahoo.com


Leon Adato (adatole@yahoo.com)
Measure what is measurable,
And make measurable what is not so.
- Galileo

 

[TheOtherKiwi]

Thats a great summary and I wish someone had given me this advice when I started however...there is always a however...tell me if I am wrong but are Tivoli people the least likely to share, mean spirited bunch you have ever dealt with?

Looking at this sad forum, and compare the number of replies on other forums and you gotta say, Tivoli people just don't share...and this reflects my experence out on the field...its like the experience is so hard won, that when people come to ask a question they just get fobbed off with some wishy-washy bull - no full and frank answers here.

Is it just me, or what? Give it up guys and gals, you will not gain in power by remaining silent, you will only gain the scorn of others.

 

[ladato]

Happliy, this is not at all true! The challenge you are facing is that there is another listserver that accounts for about 90% of all the Tivoli traffic, users, questions, etc.

If you go to:

http://publib-b.boulder.ibm.com/Redbooks.nsf/Portals/TivoliCustom1

You will be able to sign up for the IBM-sponsored "tme10" list. Here you will find experts in the field, tivoli technicians, etc.

The archive for this list, by the way can be found at

http://tme10.uio.no/Apps/Tivoli-List.nsf/main?OpenView

The problem you are encountering is that this list has been so good for so long, nobody really spends much time on this list or the one found in Yahoo. Hence your feeling of abandonment.

I have found, in actuality, that I get fast, comprehensive, and creative answers on this list as a rule, not an exception.

I'm glad my comments could help. In regard to talking to getting answers from people, I will agree it's hard to get a straight answer to most "beginner" type questions - how big a server should I buy; how should I set up my repeaters; can I use Tivoli for sending out service packs; etc.

The problem is that the answer is nearly always "it depends". It depends on the IT culture. On the level of PC standardization, On the robustness of your network infrastructure. On your personal ability to code solutions, build packages, and correlate separate bits of information into a logical set of data. And on a million other factors.

Ask instead "Have you ever accomplished xxx with Tivoli?" If the answer is yes, then the next question is "Can you tell me about that experience?" (followed quickly by "and let me buy the next round of drinks&quot ;-)

If you haven't checked into Planet Tivoli (now part of IBM's larger yearly conference), you will want to set aside time and money to go. There you will make connections and learn things that you couldn't find out anywhere else. The good, bad and ugly as they say.

Feel free to keep the conversation going here, or to jump onto the "regular" tme10 list for more answers.

Leon

Leon Adato (adatole@yahoo.com)
Measure what is measurable,
And make measurable what is not so.
- Galileo

 

[hcaballero]

I have been invited by IBM to attend Planet Tivoli, but I have to justify the cost, so is it really worth attending, and how much did it benefit you from attending?

Thanks,

 

[ladato]

My humble opinion is that this event is VERY worthwhile on several levels.

First, you get a chance to meet Tivoli techs. If you are smart, you will build relationships you can fall back on later in the year ("hey Fred - hope you are doing good since we talked in Philly last month. If you have a chance could you look over this design?&quot.

Second, you meet other people in the trenches, doing the same things you are doing. If you know how to network (not the computer type), then you will build a list of peers who again can be counted on to help you out in times of trouble (and of course, this is a two-way arrangement).

I should mention it doesn't hurt your career options that you find out which companies are using Tivoli and potentially seeking talent.

Finally, you meet vendors - both the Tivoli development staff and 3rd party folks. You might find a utility you realize you can't live without; or you might hear about a piece of functionality you can really use in your environment.

There is nowhere else you can get that kind of opportunity and exposure. Nowhere. So in my opinion it is *at least* as worthwhile as attending classes (which, by the way, are offered during this event).

Hope that helps.
Leon

Leon Adato (adatole@yahoo.com)
Measure what is measurable,
And make measurable what is not so.
- Galileo

 

[nm9204]

the best way i have found to set a test enviroment is using VM-Ware, need a load of ram but it's great, i have a PC with 1GB of ram and a 60GB HD, On this Pc I have VM-Ware, inside this VM-ware i have 3 win2k servers, on one of those i have a TMR server, 1 TEC server with Mssql, 1 INV server with Mssql and 2 linux servers and a couple of win2k workstations, thay can all talk to each other, all in VM, on one PC!

set this up, once all has been tested and installed, then copy all settings to the real system, I also have a test system with 1 w2kserver and on it I have a TMR, TEC,INV, Mssql all together, good if you have a small network!!!!

regards

Nigel