= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
This MIXED.ZIP package should be unzipped with the -D parameter, so 
that all the directories are recreated in their original structure.
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

Important!    What is the purpose of this package ?
= = = = = = = = = = = = = = = = = = = = = = = = = =
This package is an attempt to document the methods that we use to
automatically maintain the workstation's network drivers, applications,
and various other workstation files.

Files that you may need that you are not included...

   NUTL?    -  Hopefully, these files, were included with the latest
               N-Utilities release.
   NCAP??   -  Latest version is  NCAP12.EXE
               User tool for setting their 'printer redirection'.
               Saves the settings to a configuration file.
   NLOG??   -  Latest version is  NLOG12.EXE
               Allows the user to login using just their 'short' network
               name.

   For those with a HelpDesk staff...  get:
   N4PA??   -  Latest version is  N4PA12.EXE
               Allows the helpdesk staff to change user passwords without
               giving them 'admin-like' privleges.


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

Please send bug reports (or suggestions) to: 

   Compuserve:    75600, 2274.
   Internet:      dcollins@fastlane.net

If you have access to Internet... then try:
   (I'll try to have the latest versions of my utilities there.)

   http://www.fastlane.net/homepages/dcollins

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

The purpose of this package, to aid other Network administrators in setting
standards, batch files, and utilities, to make the 'maintenance' of 
workstation network drivers and miscellaneous files painless.

For example, whenever, we receive a newer mouse driver, VLMUP*, Windows 3.1
patches, we can easily distribute these files to all our workstations.
(we usually test them for a week or two, on one server, before we copy it
to other servers (and our other sites).

However, for more complicated installs (or basically anything to do with a 
Window's will fall under this) such as Lotus Smartsuite, Novell's WIN2NCS, 
CorelDraw, pc/anywhere Windows, SPSS for Windows, Oracle client, we use a 
package called WinInstall 4.0.  They can be contaced at (301)270-4458.  
Compuserve 71371,635.

For the 'normal' cycle of file updates, I think, you will find the below
methods to be very helpfull.

Below is 'map' of the system login scripts that we use, and just about
everything else, that we use to maintain the workstations at the main HQ
network:

Equipment used for the Main HQ Network:
   A mixed environment of Netware 3.11 and Netware 4.10 servers on a
   FDDI backbone.  A few dedicated servers for running Palindrome backup/
   restore, Novell SAA, Novell HostPrint, Novell GMHS 2.0d, Novell Connect 
   2.x, and a MHS-utility gateway Office Logic Clerk.
   Throw in some T1 and partial-T1s, and about 7 additional servers at
   (Light Rail) construction sites...
   (For this package, I am concentrating on the Main HQ Network, even
    though, almost all sites are the same in regards to the files below)
   Apps:  Lotus SmartSuite, Office Logic Email, and other apps.

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
ok, onward thru the files....
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

The make up of the files in this package are:


This subdirectory:
   AUTOEXEC.BAT & CONFIG.SYS
      . These  files are the 'default' settings that we use for all
        workstations.  As necessary, we will turn on the EMM386.EXE
        memory manager. (or items such as Pirmavera Expedition)
      Standards:
      . Do not use MemMaker.exe.  It causes more problems than it solves,
        and it hardcodes the app size, which makes it dificult to 
        automatically update the files like MOUSE.EXE.
        Instead, use environment variables to load certain network drivers
        high.  Everything else, such as MOUSE.EXE, CDROM drivers, MSCDEX,
        use the basic 'LoadHigh'.  VLM drivers do an excellant job and
        loading it modules into UMB and Extended Memory.
      . Do not use a buffers size larger than 256K for smartdrv.exe, unless
        you have a really good reason and alot of memory.  (Standard machines
        are 4meg, with an increasing number to be 8meg to get decent 
        performance with Window's 'suite' applications.)

   DIR.TXT
      . A simple directory tree of the make up of the location used for
        the utilities and the relevant batch files.
        Since, I can't include all the network drivers or patches, the 
        DIR.TXT file illustrates where the files would have gone.

Subdirectory:   \LOGIN              (equal to SYS:LOGIN)

   This subdirectory has one file:   NLOGIN.EXE

   This file should be copied to Netware 4.10 servers only.

   See the NLOGIN.TXT for more information.

Subdirectory:   \PUBLIC             (equal to SYS:PUBLIC)

   Basically, on Netware 4.10 server, we point each container's login
   script to refer to the login script on the 'local' fileserver.

   LOGIN.SCR and SERVER.SCR are meant for Netware 4.10 servers only.
   We use the same LOGIN.SCR on all servers.
   Whereas, SERVER.SCR is unique for each server, since it sets the
     'Current Server' that the login script is actually executing on.  
     There is no current way to get this from the Netware Login.exe app.

Subdirectory:   \PUBLIC\AUTOEXEC    (equal to SYS:PUBLIC\AUTOEXEC)

   We map a search drive to this location.  We place utilities and other
   items that we need.   We try to not place any items in the SYS:PUBLIC
   subdirectory, because this may cause problems with a future Netware
   upgrade.   (also, this method is alot neater and organized)

   Basically, the system login script will execute a batch file 
   (normally, STARTUP* out of this subdirectory depending on circumstances)
   These files are designed to be copied on to all our servers.
   We use the 'cookie-cutter' philosophy alot!   The only server centric
   file, is the SERVER.SCR file located in the sys:public subdirectory.

Subdirectory:   \PUBLIC\ROBOT       (equal to SYS:PUBLIC\ROBOT)

   We keep utilities, configurations, and batch files here that we don't
   want in a search path.  (so, they won't be called accidently by the
   user)

Subdirectory:   \PUBLIC\ROBOT\INBOUND   (equal to SYS:PUBLIC\ROBOT\INBOUND)

   All users have Read-write to this subdirectory.  Why?  Various batch
   files and other things apps (such as Net Inc's NetMenu) write log
   and events files to this subdirectory.

Subdirectory:   \PUBLIC\ROBOT\OUTBOUND   (equal to SYS:PUBLIC\ROBOT\OUTBOUND)

   This is the location of the 'root' for all files / subdirectories that
   are 'officially available' to be written to the workstation.
   (We sometimes place some of the 'outbound' files in a subdirectory under
   SYS:LOGIN to make it easier to distribute files without the need of
   logging in.)

Subdirectory:   \PUBLIC\ROBOT\OUTBOUND\VLM  

   Main 'root' directories for VLM-related drivers.
   In this case, we have the subdirectories NET and WINDOWS.
   (by name, they will 'mirror' to actual subdirectories on the 'normal'
    workstation.)

   C:\NET      - is where the network drivers are located.
   C:\WINDOWS  - is where Windows 3.1 is installed.
   
   Also, on a local workstation, we have a subdirectory named C:\@@UTL.
   it is the location, that we keep utilities and batch files on the
   workstation.  We have C:\@@UTL in the search path.
   (This way, we keep the C:\DOS subdirectory clean for DOS itself,
    to avoid conflicts, corruption, and problems from DOS upgrades.)

Subdirectory:   \PUBLIC\ROBOT\OUTBOUND\VLM\NET

   Files to be copied to the C:\NET subdirectory

Subdirectory:   \PUBLIC\ROBOT\OUTBOUND\VLM\WINDOWS

   Files to be copied to the C:\WINDOWS subdirectory


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

Well, I guess, thats about it.... please start dissecting the various
batch files and utilities.   Use what you need and fits your needs.

I hope that you will find at least something of interest from this package!


Network with BOTH 3.1x and 4.10 servers
=======================================

   If you have a network with both 3.1x and 4.10 servers, then you may find
   yourself in trying to support a NDS login attempt regardless of which 
   server the workstation first attached to.

   Perhaps, the best method to do this is to copy the LOGIN.EXE and support
   files from the Netware 4.10 server to all Netware 3.1x servers.

   For example:   Your 3.11 server is S-311 and your 4.10 servers if S-410.
   The batch may look something like this:
     MAP H:=S-311/SYS:
     MAP I:=S-410/SYS:
     FLAG H:\LOGIN\LOGIN.EXE N
     FLAG H:\PUBLIC\LOGIN.EXE N
     MD H:\LOGIN\NLS
     MD H:\PUBLIC\NLS
     NCOPY I:\PUBLIC\LOGIN.EXE H:\PUBLIC
     NCOPY I:\LOGIN\LOGIN.EXE  H:\LOGIN
     NCOPY I:\PUBLIC\NLS\*.*   H:\PUBLIC\NLS /S/E
     NCOPY I:\LOGIN\NLS\*.*    H:\LOGIN\NLS /S/E
     FLAG  I:\LOGIN\LOGIN.EXE  ROSH
     FLAG  I:\PUBLIC\LOGIN.EXE ROSH


Neat commands to know:
======================

   To document the trustee settings for all subdirectories on a volume.
      RIGHTS /T/S >RIGHTS.TXT
   From this you can use an editor to create a batch file to make similar
   trustee assignments on a 'new' server.
   Better yet, download TRST4X.ZIP from NOVUSER on Compuserve.  It has an
   utility to document trustee assignments on a 4.x server, and can create
   a batch file, if you are creating 'new' cookie-cutter servers.

   NLIST.EXE
   Enough said.  There are alot of parameters in NLIST.EXE to keep you busy
   for awhile.  Novell documentation gives you some hints on it, but it
   is a good idea to use the basic syntax and experiment.


DART Directory Tree
===================

   Basically, at anytime, there are 're-organizational' changes being made.
   Due to this and a few other reasons, we designed our Netware 4.10 tree,
   first for the location and then the server name that the user is located
   on.  Each of the 3 'main' locations are in physically different areas of
   the city connected thru T1s.   Next OU level is the Server name.
   We based our 'replica' ring at the 'location' level.
   For 'orgtree' groups, we attempted to stay as 'high' as possible.
   The main groups are named Finance, Operations, Executive, Police, Rail,
   Engineering, Construction, Planning, ...  A user is a member of one
   of these groups.   Since, a group object is normally localized to a 
   server, we have the 'group objects' located in OU=servername container
   that they belong in.
   For 'Group' objects such as Everyone, Exit-To-Dos, No-Login, pc/Anywhere,
   FormTool, Expedition, CostControl, Queue-Operator, Local-P3, Grainger,
   Cobra, Byers, AWHost, Extra, ...  they are located at the O=DART container
   since 'anyone' may be a member of the group.

   In the map below, the server and volume objects for servers Mercury,
   Jupiter, and Earth are located in the OU=RESOURCES container.
   The Bindery context for server Mercury is:
       .Resources.HQ.Dart ; .Mercury.HQ.Dart ; .Dart

    O=DART
        |
        OU=HQ
        |   |
        |   OU=Earth
        |   OU=Mercury
        |   OU=Jupiter
        |   OU=Resources
        |
        OU=SI
        OU=ED
        ...


Basic Theories:   (ok, they are IMHO attitudes)
===============================================

  . 1st: A network environment is always under-staffed with the needs of the 
    network resources and the users.   By 'standardizing' and enforcing basic 
    network philosophies, it will make your job alot easier.
    (if you think, you are adequately staffed, then add the words 'Windows' 
    and 'Client/Server'.  If you are still fine... got any openings? (grin))
  . 2nd: Cost of software and hardware is looked at more than the 
    continual maintenance and support costs of the item.  Sure that new
    printer is fast and efficient, but how in the h#ll do you get the latest
    printer drivers to each of the users.  And, upgrade them next month,
    when you find the driver bugged.
    But, if its expensive, is it really better?  Maybe not.
  . 3rd: Beware of the marketing hype.  Shortly after installing that gem
    of a new GUI application, you may find the task of bug fixes and the
    lack of 'enterprise' design will only do one thing:  empire building.
    Take for example: DOS.  Do you hire employees to troubleshoot problems
    in DOS?  I didn't think so.   You add Windows, and then need more staff.
  . 4th: Tech support by the manufacturer.  If you are a government entity,
    you already discovered that the vendor won the bid, was the winning low
    bid because they didn't have good technical support.  (If you do try
    to 'demand' good tech support then you will be in trouble with the 
    'equal opportunity' folks because it limits the vendor bid base.)
    If you are like us, then you will find Compuserve about the best source 
    of technical support, for alot of network vendors are located there.  
    Internet newsgroups are not bad, but there is alot more noise than
    signal.
    You can find other collegues like yourself envolved with similar 
    environments.  Also, you can find a number of dedicated and qualified 
    volunteers in the various Novell forums.
    Don't get me wrong.  There are alot of very good vendors out there.
  . 5th: The better that you staff your helpdesk area, the more that users
    will call seeking help.  (Lets face it, if a normal person comes across
    a problem that he doesn't know the answer and knows that he can call
    HelpDesk to answer it quickly, dig into the books or rely on 'immature' 
    online help.  What do you think he will do?
    But, on the other hand, your normal user is not a paid to be computer
    guru.  If the user is stuck (even how to format margins), then wouldn't
    it be best to have the IS helpdesk answer it, so that the user can get
    on with they are paid for?
  . 6th:  Don't use individual login scripts unless you really have too.
  . 7th:  Try to standardize on a common network card and workstation
    environment.  Again, the more understaffed you are, the more important 
    this is.  My recommendation is the NE2000.  It is not a fast card, but 
    most widely supported. (and cloned to death)  We have gotton very
    good support from NetWorth and Eagle.  Whereas, Microdyne discontinued
    some cards and their support for them.
  . 8th:  When looking at an application, see if it was designed for a 
    network environment.  If so, then perhaps, the author put parameter 
    switches and/or additional documention in the package to help you.
  . 9th:  Before buying it.  Have you actually installed the package on  
    your environment?  Anotherwards, ignore 'Marketing Hype'.
    Instead, go to user (like NUI) and professional (like NPA) groups, and 
    ask folks that are actually it in the trenches.   You can find 
    individuals that will talk about their conquests and suffering all week 
    long. (and a few with more knowledge then you can get in the press rags)
    (and well... just as unbiased.)
  . 10th:  Have you ever wondered why the only other environment that the 
    word 'user' is spoken, is when the subject matter is 'Drugs'?
  . 11th:  Hmm, does that then make us, 'Computer Pushers' ?
  . 12th:  Ok, you heard enough of my BS.  Have a good day.



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



Disclaimer:
===========

  Please apply all standard disclaimers here.  This utility is meant to
  help you... not destroy your environment or waste your time.  If you
  use any material contained within then you are responsible and not me.

  This utility is meant to help the network administrator maintain his
  network.  Its not full proof.  It fits our needs. (though we are
  constantly 'upgrading' it to maintain newer applications and needs.
  If this blows up your network, or causes any harm, I am not responsible.
  You will need to take all necessary precautions to protect your resources.

  This utility uses only standard API calls from official Novell SDK
  releases and is compiled using Microsoft C/C++ version 7.0.  

  If you wish to include any of the utilities found in this ZIP file
  in a publication, please ask first.  Thank You

  If you wish to distribute this package to your friends, distribute the 
  original compressed file since it has all the files.   Further, do not 
  break the files up and post them individually.

Thanks:
=======

   Thanks to Mark Norton.  (the other Network Administrator at DART)
   The utilities are compiled using the Novell SDK.
   Contact Novell at 800-RED-WORD to subscribe to Novell's SDK.
   If you are a Network 'professional' and have some programming ability
   then I would suggest that you get a copy of the Novell SDK or the 
   equalivant if you are using Visual Basic.
   (then, you can 'roll' your own utility to suit your needs)

WhoAmI:
=======

   Darwin Collins, works at Dallas Area Rapid Transit in Dallas, Texas USA. 
   Voice 214-749-3022.  My real job pays me to be a Network Administrator, 
   but I love to program. 

   I have been writing programs since 1980.  My first published utility
   was called 'Graphic Writer' published in SoftSide in August 1982.
   You could find a variety of my earlier utilities published in books 
   such as 'LAN Desktop Guide To Troubleshooting' by Rick Segal, and 
   'NetWare Unleashed Vol 1 and 2' from SAMS Publishing.   
   My only commerical attempt, is a product called 'Office Logic Clerk',
   which is a MHS-compatible (SMF-70,SMF-71) super utility (Alphapaging, 
   dlists, file librarian/requestor, ...) marketed by LAN-ACES Inc. in 
   Houston, TX.  800-LAN-ACES.  They have a email groupware product
   called Office Logic Email which is pretty neat!

[end]
