Conference pcbuoa::server_works

231.0. "ServerWorks v2.2 tips and things to know." by SUTRA::16.192.160.138::Bats (Speeding, speeding, I'm always speeding) Thu Mar 20 1997 10:54

	During a few weeks of RoadShow through Europe and installing a lot
	of Prioris servers for Cebit I bumped into a few nice issues with
	the ServerWorks integration suite. Since I'm not completely new
	on this front, I worked around it. Since I doubt that everyone
	has had the same exposure to this field I wanted to share my
	experiences. Customers were VERY impressed with our product suite.
	Especially when they find out that this comes all for free!
	I'll forward the same info the right people so that hopefully
	same of these areas can be fixed our documented (especially for 
	our partners, who can not access our internal information sources).


	1. Under Windows NT you need to have a mice driver loaded.
	   Some of our systems had no keyboard or mouse installed, since
	   they were on display PODs. However they were powered on, so we
	   could monitor them via ServerWorks Manager.
	   The SNMP agent won't start since the Host Resource agent of Server
	   Works fails to load. Removing that one from the extension agent
	   list in the registry will make it work.
	   Real solution was to boot the systems with a mouse and keyboard
	   connected and remove them afterwards.

	2. When the ServerWorks agents are installed, it also installs the
	   ClientWorks DMISL and DMI Remote Access.
	   Very often these go into a permanent loop, causing the CPU (or one
	   of them) to be for 100% busy.

	3. Several times on Prioris ZX, HX and MX machines, I got the ClientWorks
	   part of the installation to report to me that this was not a server,
	   so the installation of the DMI part failed.
	   Often I would find that only the DECSSM keys was created.
	   No SWLLIND, SWLLLIM or SWLLSKA keys could be found.
	   Then I would reinstall it, and a second time it would create the 
	   second key. Obviously also the ClientWorks install now worked.
	   (What parameter is used for ClientWorks setup to install in "agent"
	    mode? I know that swconsole causes it to ignore the local desktop
	    characterics, so that you can use ClientWorks to be integrated
	    with ServerWorks, without bothering with the local desktop chars.)

	4. When used in a clustered environment, I cannot get the ServerWorks
	   Alarms around cluster groups failover to be sent, and therefor 
	   received at the management station. 
           In the eventlog however I do see a message that the Cluster Management
	   Agent was not able to sent a message regarding a failover.
  	   These alarms were set from different Management stations, which were
	   all active, with all the components running, to different clusters.
  	   (Yes, we showed a few NT Clusters at Cebit, Prioris and Alpha based)
	   Using the SNMP Trap tool, however I can select the ntcltransition
	   trap (or something like that) which works without a hitch.
	   So customer were happy during the demos, since the alarms were
	   received at the management station.
	   Other alarms set via the ServerWorks Alarm tool worked ok.

	5. The SWCC v1.1 installation proposes you to be installed in the
	    \Program Files\swcc directory.
	   If you do this you find that the integration part puts the directory
	   locations in the swextomm.ini file to look like:
	   \Program\swcc\swcc.exe
	   Obviously this is wrong.
	   I didn't look into to it, but it seems that the app launcher of
	   ManageWorks restricts you to directory names of 8 characters.
	   On the German version of Windows NT or 95, the \Program Files
	   directory is called \Programme.
	   Not expecting any problems when SWCC proposed to install it into
	   \Programme\swcc (No spaces in the directory name), I found to my
	   suprise that afterwards ManageWorks was not able to find the exe.
	   Changing the directory location to \swcc or \Progra~1\swcc solved
	   these problems.

	6. The ClientWorks v2.3e kit is supposed to solve the SMS integration.
	   It does for a large part. No I don't need to correct around a thousand
	   errors spit out by the SMS Data Loader. There's one nasty one
	   remaining. Whoever tested this, obviously did not try this with 
	   other timezones. At least not for a CET time zone. The CET timezone
	   is -1 of GMT. The times that are recorded in the MIF file are however
	   written like the following:
	   ......--60 where 60 seems to mean the deviation in minutes from
	   GMT. Obviously this should be -060. Changing the 4-5 lines in the
	   MIF files to -060 from --60 will make SMS swollow correctly the
	   MIF files.
	  
	7. Related is that the ClientWorks installation done during the 
	   ServerWorks agent install, seems to be based on the older versions
	   of ClientWorks. The mif files created with MifMaker with this version
	   contain again a ton of errors, making SMS refusing to read any info
	   about the Server machines.
	   (And I've no idea how to launch the v2.3e version on a server, making
	    it to see this machine as a specific Prioris, since then the only
	    option you get is Generic Prioris server. After that I can not find
	    and system specific information in the ClientWorks MIFs or via the
	    DMISL. I edited the files, which contained several times doubles
	    field definitions, and values to point to non existing variables in
	    the previously defined tables)
 
	8. The Mylex installation kit as included does not work for Windows NT
	   4.0. For this you need to obtain the v2.05 kit from the Mylex web.
	   (The server part that is)

	This was all done with brand new hardware.
	Several ZX6000, HX6000, MX6000, SW2.2A CD-ROM (that's what the CD-ROM
	label says looking from a DOS prompt), the ClientWorks v2.3E kit from
	the BBS. The NT Cluster software used was v1.1 (final). 

	Pjotrr

    We'll be responding to each individual problem as it gets answered.
    The only problem I remember being answered before was your number 3.
    This was answered in note 222.4. A patch is available for the
    installation.
    
    Keep looking for more replies on this note.
    

    This is almost certainly *not* related to ServerWORKS.  The fact that
    he's not seeing any computers in the browse list can be from one of
    several conditions:
    
    not waiting long enough for the browser list to be created on his NT
    domain (the browse list can take a while to get created after a machine
    reboots)
    the NT machine running ServerWORKS console has not been added to the
    browse list or has been explicitly deleted from the browse list
    
    There could be other problems with the NT primary domain controller. 
    If he's in a non-domain environment, we'd need more info to figure out
    what's happening.  But I still think that it's not related to SWORKS
    2.2.
    
    -George
    

	This must be a reply to another note.
	

	Pjotrr

    Sorry, it should be reply to 230. It has been copied. Thanks

    Rich,

    Do you have any news re. the DMISL service looping ?

    Tech support Valbonne has received several reports on this problem from
    customer installations here. Since this happens soon after the
    installation of ServerWORKS, it gives a really bad first impression...

    Thank you,
    Peter.

    The new dmisl.exe can be obtained from \\jules\public on
    \cworks\drops.
    Please use that until next Client Works release.
    
    Rich