RE: [TMF4.1.1] lowlevel command to obtain endpoint ip address on NAT enabled TME

Hi Dean,

uhm....insteresting! That was queit
a mouthful of PROS. Could you, and/or anyone else on the list who has utilized
or has some experience on enterprise-q please comment on the CONS of the
sofware. Also can you precisely run thru how enterprise-q would resolve
a situation like the one I am having, and also how it would verify and
even in some instances attempt a best effort means to resolve missing ITM
required software components from TMA targeted servers. 
Thanking you,
Napo

***************************************************************
JPMorganChase - Systems & Service Management Tools Engineer
Tel: 614-213-8599
Pager: 888-636-2381
"If you look in your dictionary, you'll find that the meaning of the
word 'single' is not single!" - UNKNOWN
************************************************************* 


Joel N Mokoetle

tme10@xxxxxxxxxxxxxxxxxxx Sent by: owner-tme10@xxxxxxxxxxxxxxxx 02/25/2005 01:45 PM Please respond to tme10

To:        tme10@xxxxxxxxxxxxxxxx         cc:                 Subject:        RE: [tme10] [TMF4.1.1] lowlevel command to obtain endpoint ip address on NAT enabled TME

Napo-

You may be interested in 'enterprise-q'.  It includes an Endpoint
installation
mechanism that initiates automatically from Windows Domain Login.  enterprise-Q
comes with a utility called 'DomainLogin.exe' that gets invoked from Windows
Domain login script.  DomainLogin.exe collects the USERNAME, COMPUTERNAME,
OS,
WIN-DOMAIN, DNS-DOMAIN, IP, MAC, NET-DEFAULT-GATEWAY, and the status of
any LCF
running on the box.  This info is sent to the 'enterprise-q' server,
which
starts the 'DomainLogin' transaction.

The DomainLogin transaction stores this information in a database, and
then
processes the enterprise-q DomainLogin rules you've defined for installing
the
Endpoint.  If so determined by your rules, the EPInstall transaction
is queued
and initiated to install the Endpoint.  It even works in a hub/spoke
architecture, where you set up rules to determine which spoke TMR to queue
the
EPInstall transaction.

The EPInstall transaction processes the enterprise-q EPInstall rules to
determine the Proxy Endpoint, the Account to use, the Gateway to assign,
and
all the parameters needed to install the Endpoint, such as the Installation
Directory, Share Name, Port Number, BCast Disable, Wake-on-LAN, etc, etc.
 If
the Endpoint object already exists in the TMR, you can optionally configure
the
EPInstall transaction to remove it.

When the Endpoint logs into the Gateway, the EPLogin transaction gets queued
and
initiated with all the information from Endpoint Login Policy (e.g. Endpoint
Version, Interp Type, Tivoli GW, etc.) . The EPLogon transaction processes
rules for Upgrading the Endpoint, Migrating the Endpoint, Subscribing the
Endpoint, etc.  When so determined, EPUpgrade, EPMigrate, Subscribe,
etc.
transactions are queud and initiated.

All this happens automatically, and is tracked, reported (real-time and
historical), and retried automatically as well.  It's been used for
years to
install thousands of Endpoints, so it's well proven.  And the next
release will
include rules for queuing any other enterprise-q transaction from EPLogin,
such
as Inventory, Software Distributions, Tivoli Tasks, ITM profiles, ACP profiles,
etc.

Please let us know if you have any questions or need additional information.
You can see screen shots of setting up the rules from our web site at
'http://www.enterprise-q.com/rd/rd_overview.html'.

Thanks,
Dean Leonard
703-404-3000
www.enterprise-Q.com


Quoting joel_n_mokoetle@xxxxxxxxxxx:

> Hi Brain,
>
> Your strategy does sound good, but I don't think it quiet answers
my
> dilemma. I am designing an automated endpoint installation solution.
Part
> of this solution involves running pre-install prerequisites (i.e.
run
> before allowing TMA code for installing an endpoint to execute on
the
> target machine). One of these pre-install prerequisites is ensuring
there
> isn't an endpoint instance in the TME bearing the same name as the
FQDN
> name of the target machine. A cgi script does this instance check
through
> the Tivoli Web Access component, and if it does find an endpoint instance
> for the machine a person is trying to install the TMA code on, it
adds
> that problem to a report to feedback to the installer for further
> analysis. Now within this entry of the report, I would have wanted
to
> include the IP ADDRESS of the endpoint instance found as part of the
> record. And that so far seems not possible using Tivoli commands,
at least
> that's what I've gathered based on the great feedback the LIST has
bounced
> on me.
> The solution pulls down the TMA code from a central store to the target
> machine only when all the pre-install prereqs have been performed
and are
> successful. The above is one check the many checks we don't want to
allow
> the TMA code to be installed on the target machine before its satisfied
> because that leads to a lot of other problems as I am sure you have
> experienced with your Tivoli environments.
> Hopefully the above is clear.
>
> Thanks for your input,
> Napo
>
> ***************************************************************
> JPMorganChase - Systems & Service Management Tools Engineer
> Tel: 614-213-8599
> Pager: 888-636-2381
> "If you look in your dictionary, you'll find that the meaning
of the word
> 'single' is not single!" - UNKNOWN
> *************************************************************
>
>
> Joel N Mokoetle
>
> "Duffy, Brian \(OFT\)" <Brian.Duffy@xxxxxxxxxxxxxxx>
> Sent by: owner-tme10@xxxxxxxxxxxxxxxx
> 02/25/2005 10:03 AM
> Please respond to tme10
>
>         To:     <tme10@xxxxxxxxxxxxxxxx>
>         cc:
>         Subject:        RE:
[tme10] [TMF4.1.1] lowlevel command to obtain
> endpoint ip address on NAT enabled TME
>
>
> Joel -
>
> The way that we handle these sort of situations is with a "penalty
box".
> When new machines login to the TME, we first leave them assigned to
the
> intercepting or seed gateway in the Hub region (ie penalty box). Then
we
> check various things on the endpoint (dns resolution, are apps that
break
> Tivoli on the endpoint, etc) and migrate the machine to its proper
gateway
> in one of the spoke regions.
>
> The advantage of this technique is that we can run tasks and check
for
> more problems than you can with allow_install policies. The disadvantage
> is that there is a lag between when an endpoint initially logs into
the
> TME and when it is actually assigned to its actual gateway to utilize
> Tivoli services.
>
> You could easily use something like this to verify the IP or even
MAC
> address of workstations to find duplicate machines.
>
> Brian Duffy
> brian.duffy@xxxxxxxxxxxxxxx
>
>
> From: owner-tme10@xxxxxxxxxxxxxxxx [mailto:owner-tme10@xxxxxxxxxxxxxxxx]
> On Behalf Of joel_n_mokoetle@xxxxxxxxxxx
> Sent: Thursday, February 24, 2005 5:22 PM
> To: tme10@xxxxxxxxxxxxxxxx
> Subject: RE: [tme10] [TMF4.1.1] lowlevel command to obtain endpoint
ip
> address on NAT enabled TME
>
>
> Thanks for your thoughts Ed. There are various ways that can be determined
> to get the IP Address "if" the endpoint's lcfd service/deamon
is running
> on a machine! But let's consider a scenario where, there's no TMA
code at
> the endpoint machine or the lcfd is not running, only the instance
exists
> in the TME. My question is based on this scenario.
>
> Kindly,
> Napo
>
> ***************************************************************
> JPMorganChase - Systems & Service Management Tools Engineer
> Tel: 614-213-8599
> Pager: 888-636-2381
> "If you look in your dictionary, you'll find that the meaning
of the word
> 'single' is not single!" - UNKNOWN
> *************************************************************
>
>
> Joel N Mokoetle
>
> "Napier, Ed" <Ed.Napier@xxxxxxxxxxxxxxxxx>
> Sent by: owner-tme10@xxxxxxxxxxxxxxxx
> 02/24/2005 04:34 PM
> Please respond to tme10
>
>         To:        tme10@xxxxxxxxxxxxxxxx
>         cc:
>         Subject:        RE:
[tme10] [TMF4.1.1] lowlevel command to obtain
> endpoint ip address on NAT enabled TME
>
>
>
> Why not just create a task that ran a command (ipconfig) to tell you
what
> the IP address is.  Then execute the task on the endpoint.  The
IP address
> should be in the STDOUT.
>
> Ed
>
>
>
>
> From: owner-tme10@xxxxxxxxxxxxxxxx [mailto:owner-tme10@xxxxxxxxxxxxxxxx]
> On Behalf Of joel_n_mokoetle@xxxxxxxxxxx
> Sent: Thursday, February 24, 2005 4:26 PM
> To: tme10@xxxxxxxxxxxxxxxx
> Subject: Re: [tme10] [TMF4.1.1] lowlevel command to obtain endpoint
ip
> address on NAT enabled TME
>
>
> Thanks Gary/Jason. From Gary's explanation, the IP of an endpoint
instance
> in a NAT enable TME is not available from any object database or registry
> on the TME. Your explanation does make sense, unfortunately it only
> confirms my fears! Looks like I'll have to abandon the thought, unless
> someone comes up with some magical way of achieving the objective(
to
> provide the installer with more information for further analysis
> when/where needed).
>
> Thanks for all your swift assistance gents. Keep well and on track.
>
> Napo
>
> ***************************************************************
> JPMorganChase - Systems & Service Management Tools Engineer
> Tel: 614-213-8599
> Pager: 888-636-2381
> "If you look in your dictionary, you'll find that the meaning
of the word
> 'single' is not single!" - UNKNOWN
> *************************************************************
>
>
> Joel N Mokoetle
>
>
> Gary Hamilton <HAMILGAR@xxxxxxxxxx>
> Sent by: owner-tme10@xxxxxxxxxxxxxxxx
> 02/24/2005 03:33 PM
> Please respond to tme10
>
>        To:        tme10@xxxxxxxxxxxxxxxx
>        cc:
>        Subject:        Re:
[tme10] [TMF4.1.1] lowlevel command to obtain
> endpoint ip address    on NAT enabled TME
>
>
>
>
>
>
>
>
> So you are asking for the real address of the endpoint that is on
the
> other
> side of a NAT firewall?
>
> This information would not be available to the Endpoint Manager. In
a
> configuration like this, you would be using the name of the endpoint
to
> communicate with it, and the name is converted by the appropriate
naming
> service to an IP address, which will be converted to the real address
when
> it passes through the firewall.
>
> An IP address may be stored in the Endpoint Manager database, but
this
> address is very likely to be the NAT'd address, not the real one.
Is this
> the IP address you are asking for?
>
>
> Gary R. Hamilton
> Team Leader
> Senior Software Engineer
> IBM Software Group - Tivoli Software (UK)
> Global Response Team - Europe/Middle East/Africa
> +44(0)1753-780-988
> mobile: +44(0)780-820-3714
> e-mail:hamilgar@xxxxxxxxxx
> ____________________________________________
> AskTivoli -  http://www-3.ibm.com/software/sysmgmt/products/support/
> Web PMR submission - http://www-3.ibm.com/software/support/probsub.html
>
>
>
>            joel_n_mokoetle@b
>            ankone.com
>            Sent by:      
                     
                     
To
>            owner-tme10@lists  
      <tme10@xxxxxxxxxxxxxxxx>
>            .us.ibm.com    
                     
                     cc
>
>                    
                     
                     
 Subject
>            24/02/2005 17:10    
     [tme10] [TMF4.1.1] lowlevel command
>                    
                 to obtain
endpoint ip address on
>                    
                 NAT enabled
TME
>            Please respond to
>                  tme10
>
>
>
>
>
>
>
>
>
> Can someone please tell me the low level (i.e. objcall,idcall,etc.)
> command
> to obtain the IP ADDRESS of an endpoint on a Tivoli Management Environment
> that has NAT enabled? I need the IP as registered in on the TMR.
>
> Thanking you in advance,
> Napo
>
> ***************************************************************
> JPMorganChase - Systems & Service Management Tools Engineer
> Tel: 614-213-8599
> Pager: 888-636-2381
> "If you look in your dictionary, you'll find that the meaning
of the word
> 'single' is not single!" UNKNOWN
> *************************************************************
>
> This transmission may contain information that is privileged, confidential
> and/or exempt from disclosure under applicable law. If you are not
the
> intended recipient, you are hereby notified that any disclosure, copying,
> distribution, or use of the information contained herein (including
any
> reliance thereon) is STRICTLY PROHIBITED. If you received this
> transmission
> in error, please immediately contact the sender and destroy the material
> in
> its entirety, whether in electronic or hard copy format. Thank you.
>
>