Integrating Win95 and Samba in detail (long)

[Louis Mandelstam]

On Fri, 3 Oct 1997, Luke Kenneth Casson Leighton wrote:

> > 1. A completely automated Win95+apps installation from the server, from a
> >    boot diskette (for setting up new PCs or fixing completely hosed ones)
> 
> how??? how???

I know how you feel ;-)

First I tried using Microsoft's msbatch.inf plan for automating setups,
with batch.exe and the like.

After spending probably about 2 months concentrating on this, scouring the
web, DejaNews, Samba archives, peers and the Win95 Resource Toolkit, I
came to the following conclusions:

1. Getting Win95 customizations done this way may be feasible, but for
   3rd-party applications, this doesn't work very well.  I was spending
   too much time diff'ing .reg files to find what an application changed
   to get a certain setting, then putting it in the .inf file (which is of
   course a different format than the .reg)

   Some applications had (their own) ways of automating install and
   default settings, some didn't - in which case I ended up making an
   archive with all the files they added to the system, and a .reg file
   with the registry settings they added.  These were then installed by
   using HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\...
   ...RunOnce\Setup\ entries (they get executed between the "first time"
   Win95 boot and the next.

   There were some things which I just couldn't get automated, including:
   1. Logging in at the Win95 "first boot" so that Win95 can access it's
      install tree on the server for the second install phase.  I
      couldn't e.g. get it to log in as guest automatically.  I did find
      a Win95 autoinstall web site (Bob Cerelli's) which gave a solution,
      but I couldn't get it to work at all, and his response was that the
      solution was what Microsoft had given him.

   2. We use 3COM EtherLink III PnP ISA (3c509b-TPO) ethercards on all the
      workstations - regardless of all the cards being set the same way,
      some workstations refused to autodetect the card in setup.exe, and I
      needed to specify it manually.  I could never find the reason - it
      happens every time on some machines, never on the rest.  

   3. Not a biggie, but the MS way of doing things requires acknowledging
      a dialog box at the end of the install, before the system is
      rebooted and ready for use.

   4. Possibly the biggest hassle of all, was getting the initial
      bootstrap of the install to work.
      I managed to get the MS client for DOS (3.0) to connect to the
      Samba server over NBT, run setup.exe with the .inf file, and take it
      from there.  However, getting all the little cracks the remained
      fixed took way too much dark magic in DOS to my liking.  Things such
      as adjusting the msbatch.inf(*) file for the correct netbios
      hostname took some really disgusting hacks - please don't think for
      one moment you can get the Win95 DHCP client to take the hn: bootp
      tag to be the netbios hostname.  I did find a bootp client for
      Win95 that would do this, but I rather liked the DHCP refresh
      feature and I wanted to keep it.   There were a LOT of these
      critters.
      (*) DO NOT call the file msbatch.inf per se if you think you're
          going to automate everything, especially if you are using Win95
          OSR2.  Call it anything else, or certain dialog boxes will keep
          coming to you no matter what you do.
          DO NOT expect this to be documented.
          Unbelievable.

2. Microsoft surely must have made it this complex/non-standard/inflexible
   in purpose.



SO I SAT DOWN.  TOOK A BREAK.  THOUGHT THIS WHOLE MESS OVER.

Arriving at a solution using the above method, left with cracks all over
the place, took me about 3 months.

My new solution is almost done, almost all of the problems are resolved
(and the rest should be solvable once I get to them) and it's taken me
only 2-3 weeks so far.

The install bootstrap is now a Linux boot disk, that NFS mounts a
directory on the server (I'll be changing this to SMB in due course),
copies some programs from the server to its local ramdisk, prompts for
OK(**) then formats C:, and extracts a .tgz containing the entire contents
of a working workstation's C: onto the hard drive (including the
registry), then sets the BIOS to boot C:,A:, then reboots.  QED.  *MAN* am
I pleased with this setup.  There were some tricky problems, like making
sure the IO.SYS etc files sit on the right spots on C: for the system to
find them at boot time, but compared to the dark mud I needed to mess
around in with Microsoft's stupid way of doing it, I was damn happy.

(**) should be unnecessary as soon as I have everyone running the first
     version of my new setup, since that should be the end of them finding
     ways to store stuff on C:, and thus I don't need to worry about
     asking for confirmation before wiping and redoing C: 

 2. A completely automated install as above, but initiated by the server.
> >    (for fixing less-than-completely hosed PCs, or upgrading the software
> >     on them or making other changed on the hard drives)
> 
> ditto!!!

Using a Linux boot image to start it all off really gives you a load of
flexibility.  Hint: loadlin.exe (dos-based Linux boot loaded)

> > 8. Automatic printer selection, per-workstation.  I expect I'll have to
> >    set up a table on the server with printer name to use for each
> >    workstation, and come up with a way to update the registry accordinly
> >    at boot time.  To make it fun, not all the printers are the same - but
> >    almost all understand PCL5.  I might be able to get rid of the rest if
> >    I have to.
> 
> how?

Dunno, still need to ponder this one.  I may end up trying to make a
single printer service on the Samba server, connect all workstations to
that service (so they all have the same setting) and let the server figure
out which printer should get the job.   Otherwise I may figure out a way
to feed an appropriate .reg file to the workstation from the server (at
boot time).   If I could find a way to let Linux exit back to DOS after
booting using loadlin.exe, I'd have a very simple way to do a lot
of boot-time things - since I could just get back into DOS and let the
Win95 boot continue from there (after modifying the registry in any way I
please).

> > Anyone know of a list/web site/newsgroup that covers these issues?  The
> > Win95 Resource Toolkit has offered very little help.
> 
> no.  perhaps one should be started!

Or perhaps there is sufficient interest on the Samba list to justify
keeping the discussion here?

BTW another point - all my workstations are not identical hardware-wise.
They are similar - same model ethercard and video card, all have one x IDE
drive and one 3.5" FDD, 16M RAM minimum, no funny cards in there etc, but
different motherboard models and IDE sizes.

This means that if you extract a Win95 tree made on one kind of machine
onto another, it'll detect different chipsets and the like at boot time,
install the new drivers, and reboot.  In some cases (IDE chipset is one),
Win95 also requires some user interaction to hold its hand during this
process - which is just not good enough.

I though I would have my Linux-based setup routine test the hardware to
determine which of a set of images needed to be installed, but that was
ugly - by accident a found a MUCH more convenient way:

1. Set up the tree on machine type A.
2. Create a source tree on the server, containing the image from machine
   A.
3. Now install the tree onto machine type B.
4. Boot, and let Win95 adjust to the different hardware.
   I assumed Win95 would be replacing drivers, it doesn't - it ADDS
   drivers.
5. Make a new source tree based on machine B
6. This new source tree will not require hardware re-detection if you now
   installed it on either type of machine.

I currently have 4 types of machine in my tree, and it installs just fine
on any of them, without any boot-time drivers installs.  The only
exception is the 3COM ethercard which I'm using in PnP mode.  PnP seems to
manage to notice that the particular ethercard it was talking to before is
now missing, so it removes the driver, then wants to install a new one
(guess what - it's on the other side of the network connection).

I solved this by creating the source tree on a machine where I've disabled
PnP on the ethercard and installing the driver accordingly.  Now a machine
with PnP enabled on the nic boots the tree for the first time, it first
connects to the server, then find that a PnP device is installed, and
replaces the non-PnP driver with a PnP one - without requiring a reboot,
loosing the connection to the server, or giving the user any change to
hose the process.  This may be specific to the card involved - it's the
only ISA PnP card I'm using.

> <br><b>  "Apply the Laws of Nature to your environment before your
>           environment applies the Laws of Nature to you"              </b>

Love it!

Regards

---------------------------------------------------------------|-----|--
Louis Mandelstam              Tel +27 83 227-0712   Symphony  /|\   /|\
Linux systems integration     http://sr.co.za       Research {   } {   }
Johannesburg, South Africa    mailto:louis at sr.co.za (Pty)Ltd {___} {___}