ADSM-L

Reply to Win95 Automated inst

1997-03-13 15:06:31
Subject: Reply to Win95 Automated inst
From: Mike Collins <ecollins AT VNET.IBM DOT COM>
Date: Thu, 13 Mar 1997 13:06:31 -0700
Hi Jerry and Mike,

This is a quick attempt to help people doing ADSM client/win32
server/NT silent installs.  Note that this may change in future
ptfs. We cannot provide the setup.rul source for a number of reasons.

I think the majority of issues are related to the handling of pre-ptf5
upgrade/cleanups so I will provide psuedocode here that should help.

Note that Mike Stewart's example of the options file was just an
example. ADSM Setup will not popup any dialogs if it finds an existing
options file. It silently keeps the existing one and adds a new one
with the extension of new -- dsm.new for example.

Hope this helps.  We'll update the associated readme info to include
this.  If you find something that is not correct or need further
clarification let us know and we'll see what we can do to help.

Regards,

Mike Collins
ADSM Development

====================================================================
ADSM Setup Branching Logic for silent installs

If you run setup using the -r switch (setup -r) it will generate a
silent install response file for you. InstallShield will name it
setup.iss and place it in your system directory.

In your setup.iss file you'll see a dlgorder stanza. SdWelcome should
always be the first dialog.  The dialog sequence between
SdOptionsButtons and SdFinish should be fairly repeatable --
exceptions would be when ADSM or Installshield provides a warning
dialog if some system or ADSM specific issue has occurred (dll in use,
installing a second copy rather than upgrading, etc).

Note that between the SdWelcome and SdOptionsButtons we check to see
if we should do an upgrade or not. Please refer to the psuedocode for
checkforupgrade() and cleanupoldclient() below and look for: AskYesNo,
AskOptions, and SdShowInfoList to see where optional dialogs may
occur. Note the for-loops in cleanupoldclient().

 ============================================================================
setup.iss response file psueducode segment

[DlgOrder]
Dlg0=SdWelcome-0        -- should always be first

checkforupgrade()       -- see if any ADSM component's been installed before

Dlgx=SdOptionsButtons-0 -- choose full, compact, or custom install
 ...                    -- depends on choice of full, compact, or custom
Dlgx=SelectFolder-0
Dlgx=SdStartCopy-0
Dlgx=SdFinish-0

 ============================================================================

checkforupgrade()
{
  - We determine if ADSM components have been installed by looking for
    the following registry keys. We started using the registry when
    we switched to Installshield (client PTF5, server GA)
  - server is similar but looks at components\server rather than
    components\baclient
  - hive is hkey_local_machine

  bBaseInstalled = exists( software\ibm\adsm\currentversion\components )
  bClientInstalled = exists( 
software\ibm\adsm\currentversion\components\baclient )

  if ( ( !bClientInstalled ) && ( !bBaseInstalled ) )
    if ( AskYesNo( "Look for old ADSM client Installations?" ) == YES )
      cleanupOldClient()
    endif
  endif
}

cleanupOldClient()
{
  - get list of all drives
  for each drive
    for each directory
      look for directories that contain both dscameng.txt and dsmc.exe
      if ( found )
        AskOptions( EXCLUSIVE,
          nCheck1 = Install ADSM into this directory?
          nCheck2 = Continue looking for directories with ADSM components?
          nCheck3 = Delete contents of this directory including subdirectories?
          nCheck4 = Stop looking for directories with ADSM components? )
        take appropriate action
      endif
    end for
  end for

 - look for old ADSM program folders

   if ( find groupname "ADSM 32-Bit Windows" )
     if ( AskYesNo( Would you like to delete this folder? ) == YES )
       deletefolder()
     endif
   endif

 - look for ADSM environment variables that are pointing to old install

  if exist( dsm_config, dsm_dir, dsmadmc_config, dsmadmc_dir, dsmg_dir )
    SdShowInfoList( warning message )
  endif
}

Jerry Lawson writes:
 > ---------------------------- Forwarded with Changes 
 > ---------------------------
 > From: INTERNET.OWNERAD at SNADGATE
 > Date: 3/12/97 10:57AM
 > To: Jerry Lawson at ASUPO
 > *To: *ADSM-L at SNADGATE
 > Subject: Reply to Win95 Automated inst
 > -------------------------------------------------------------------------------
 > First I want to thank Mike Collins and Mike Dile for the documentation on
 > Setup - the guy who asked me to post the original question is very happy
 > and thinks we have a controlled enough environment (at least in his area)
 > to handle the task - he has the challenge of replacing all of our level 3
 > Win95 clients before DST comes back! :-)
 >
 > As Mike Stewart pointed out - the branches in the install process causes
 > problems - I have the feeling as I documented the manual process that I had
 > not hit all of the possible paths yet, and this seems to confirm it, as I
 > have not yet seen anything about DSM.OPT in the install process.  I did
 > find one curve, though that was bothersome.... I had installed a level 3
 > client in the standard directory, but on my D drive, so I had all the code
 > in D:\ADSM32.  When I ran the upgrade to install level 6 in recording mode,
 > the install process told me where the code was, and I did not change
 > anything.  When I inspected the script afterward, I was surprised to see my
 > own directory (D:\ADSM32) in the ISS file.  I had hoped that because I had
 > not overridden anything in the install process, that the install would go
 > to whereever the install process found the installed code.
 >
 > Jerry Lawson
 > jlawson AT thehartford DOT com
 >
 >
 > ______________________________ Forward Header 
 > __________________________________
 > Subject: Reply to Win95 Automated inst
 > Author:  INTERNET.OWNERAD at SNADGATE
 > Date:    3/12/97 10:57 AM
 >
 >
 > *** Original Author:  ADSM-L @ MARIST - ** Remote User **; 03/12/97 12:15am
 >
 > >
 > Jerry Lawson writes:
 >  > A guy in my department has been working on automated installs of the Win95
 >  > clients.  We have followed the instructions in the ReadMe file with the
 >  > level 6 client, and have used the Setup -r command to build an setup.iss
 >  > file for use in the silent install, which we have also successfully done.
 >  >
 >  > My guy's question?  We have several different scenarios for installation -
 >  > each will have a different setup.iss file.  But since the file must be in
 >  > the same location as the setup.exe we were wondering if there were any
 >  > options available with the Setup program - an option that allows to point
 >  > to an iss file with a different name?
 >  >
 >  > Jerry Lawson
 >  > jlawson AT itthartford DOT com
 >
 > Hi Jerry,
 >
 > Here is some additional information regarding the use of
 > installshield. See the -f1 parameter below to specify alternate .iss
 > .
 > .
 > .
 > *** Comments From: STEWAJM - Stewart, Mike; 03/12/97 09:14am
 >
 > We are running into a similar problem in trying to automate
 > a local setup.  We are finding silent mode difficult to
 > work with the ADSM setup.
 >
 > The problem we are running into is that silent mode wants
 > a fixed, ordered sequence of dialog prompts.
 >
 > However, the ADSM install can branch off and display
 > different sequences of prompts.  This means that we have
 > to generate a new response file for each potential branch.
 > Then we have to predict which way the ADSM install will
 > branch for a given machine, and start setup pointing to
 > the appropriate response file.
 >
 > For example (and I'm not positive this is one of the
 > problem areas, but just as an example):
 >
 > If ADSM finds a pre-existing DSM.OPT file, it
 > throws up a dialog asking if it should use the old OPT file.
 >
 > This means we have to generate an installshield response
 > file to handle the dialog sequence where there is no OPT file,
 > and another to handle the dialog sequence where there is an
 > OPT file.
 >
 > Then, when starting setup.exe we have to detect whether or
 > not an OPT file exists, and then start setup pointing to
 > the correct response file.
 >
 > For every "optional" dialog or prompt we have to generate a
 > new response file, and try to detect before starting setup
 > which path will be taken so we can know what response file
 > to point setup to.
 >
 > This is pretty unruly.  We'd be alot happier just to have
 > the setup rules file so we could modify it to local
 > specifications.  (Many other vendors make their
 > rules files available.)
<Prev in Thread] Current Thread [Next in Thread>