Starting WebSphere sMash on Windows 7. UnsatisfiedLinkError, ZSO could not be located ...arch=x86_64

( All opinions are my own and does not reflect my employer's point of view. There could be better ways of doing stuff than written below, but what I have written below got me working again)


The WebSphere sMash is an IBM Application server that helps in building web applications faster, and lets users concentrate on writing business logic. More on this can be found at http://www.projectzero.org/


Having been used to running this on Windows XP -32 bit, when I was working on sMash - I had to face some challenges when I migrated the WebSphere sMash to Windows7 ( yes, I got a new Laptop running Windows 7)
So, when I tried to start up WebSphere sMash - it would not come up.
That's when I realized that  I needed to do some digging up.

My blog here says about how to start the sMash on Windows 7 OS.
Basically,you need to be pointing to the 32 bit JVM in order to get this right.  Once you initialize and also reconfigure the resolved. properties -then the application  should start up fine.

Authoring fixlets - Some Search Patterns in Relevance.

( All opinions are my own, and does not reflect my employer.)
 Ramblings on how to create some fixlets on BigFix.

Background: Big Fix is an IBM application used to deploy patches, upgrade or install rules and can monitor servers/clients that needs this patch - It will automatically inform the client and the client will do a pull (versus a push of the patch from the server ) which is more effective.

Up until IBM bought this, it was called Big Fix and now it is Tivoli End Point manager.

A fixlet is a composition of Rules, Actions and Relevance that describes the patch or an install on the client.

Once this fixlet is deployed with the above, TEM will constantly monitor the clients and deploy them.
My blog here shows a sample on how to write fixlets using different relevance rules on TEM ( Tivoli End Point Manager -Previously called Big Fix )

Note : I am only showing the different relevance rules that can possibly be applied to check if the rpm is present.

Note : Here I am interested in "expect"

Snapshot shows how a relevance is written - that identifies the clients as Linux:

Picture :
One other way to deploy is to identify a specific server on which the package will be deployed.

Picture 3:

Picture 4: Once this is identified - User will write appropriate action scripts to deploy the package.

Creating a fixlet to identify deployment of NMA agent from Big Fix Server.

All opinions are my own and does not reflect that of my employers.

NMA is the network montoring agent - an agent developed by IBM that helps in detection of servers on the network and report on their characteristics.

Big Fix is an IBM Application that is being used to detect clients that need patches/ installation of software or bringing servers upto sync on new releases.
Big Fix is also called Tivoli Endpoint Manager after IBM bought it over.
So references to TEM or Big FixServer are one and the same.

In this blog I will briefly describe how to deploy the NMA agent on remote clients.
I'd assume that the the agent is already available on the Big Fix server and can be used to deploy.

Create New Fixlet. 

Creating the relevance rules - this means that the relevance rules have to be true in order for the agent to be deployed.

 
Create a script that will be executed on the remote client once the relevance rule is satisfied.

A sample Relevance Rule to check if the Tivoli NMA agent is installed or
not in Big Fix.
Relevance:

Action :

How to Unistall and Install Big Fix Server on Windows.

References to Big Fix means - IBM Tivoli Endpoint Manager.

Here I talk about my experiences on removing and reinstalling the Big Fix Server that was already installed on the Windows platform and things I learnt in the process.

Very Important - Just do not remove the Big Fix from the Add/Remove programs - how ever... Uninstall both the Big fix and the Microsoft SQL server folders and application from the Add/Remove programs.

One other thing I noticed was, the Tivoli Endpoint Manager (Big Fix Server) after installation did not recognize the older Clients ( in my case  the Unix clients) that were recognized before the removal, so I had to uninstall the clients manually in order for the TEM server to recognize them.
rpm -e BESAgent and let the TEM Server rediscover it again.

Picture : Uninstall of the application in progress:

 

Picture :
Removal of the folder/directory structure - in other words - cleaning out.
 

 


Since I was experimenting with this - I had to select the Evaluation Version.

 

 

I accepted the defaults - no changes here.

 

Picture :
Set password for the TEM administrator.

 

Picture:
 

 

Picture below : If this happens it means the Microsoft SQL Server was not removed completely, this leads to the TEM failure. So in this case I'd go back and clean out the SQL installation - both from the Add/Remove and also clean out the SQL directory folder structure and then restart all over.
 ( Do not abort the installation , however finish this installation - remove, clean out and reinstall )

 

 

Hope this helps who is going thru similar situation.

Big Fix Server and deploying Fixlets.

Big Fix is an IBM Product  that specializes in keeping track of clients downstream, that need patches/updates and does it as and when required.

In other words, Big Fix maintains a list of clients ( or as I like to call them 'servers downstream' ) and tracks them periodically and when a user wants to deploy a new patch or an install , then Big Fix looks at a few things like Relevance, and performs some actions and sees to it that the remote servers get the patches.

Several attractive features of the Big Fix makes this operation smooth and simple and requires no manual intervention. The One I found interesting is the "Relevance" feature, which is a rule (or a set of rules ) that tells things like what type of a server, what type of an OS and what range of IP address and things like that . Once these conditions in the rule are met - then Big Fix Server issues a UDP request to the clients ( or servers downstream) that the patch/update is required.
The client(s) then initiate a request and pulls down the patch or an update, and completes the operation.

Some snapshots can be seen in next blog.