Scripting and Automation Options

No network-logon is complete without some form of automation  to establish the user's working-environment. For instance, although the logon-process establishes the user's rights to access certain folders on the server, it does nothing  to provide an easy route-of-access to those files, such as a drive-letter or shortcut. . Thus, while a network could in principle get-by without a logon-script, it  would be a very user-unfriendly place, calling for user to know the ins-and-outs  of accessing all sorts of obscure resources by way of complex and hard-to-remember procedures. The logon-script makes those resources easy to access.

MyLogon supports  the time-honoured  method of providing  a logon-script, which is to use a batch-file.  Any function which can be called from a batch-file is also available, of course.  AutoIt, KixStart or VBS extensions are of course supported if launched from the batch-file.

New to Version 2 is the ability to use a logon-script with a syntax similar to .ini files.   This has the advantage of much faster execution, and no DOS-style black screen  while it executes. At the moment this is still under development,  and not all options available to batch-files are included in the new-style script.  Most commonly-required ones are, though.  The script will be treated as a new-style one if its extension is .ini or .mls (MyLogon Script)  Otherwise it will be launched in a console window, in the standard manner.

User-specific  actions:

Batch-files have access to the usual environment variables, plus  %user% and %computer% - which represent the name of the network user and machine respectively. These may be used to connect-to a "home folder"  for either a specific user or computer.

A typical example script:

Automatic Cleanup Feature:

If our hypothetical user has insufficient rights to access the accounting-files, then the S: mapping  won't appear in 'My Computer' even though it's in the logon-script, and so the user won't be left with un-openable disk shortcuts. Therefore you can add all your drive-mappings to one MyLogon script without this leaving confusing clutter.  This feature - unavailable in the Microsoft logon - eliminates the need to maintain individualised logon-scrips for most small sites, potentially saving a huge amount of admin-work. It is controlled by the ShareCleanup option of MyLogon.ini.

Notes

 In Net Use commands it is not necessary to add "persistent: no"  to each line.  You may if you wish add "/yes"  for Windows 9x compatibility of the script.

The script must not contain a  net use * /delete command,  though specific mappings may be deleted.

Version two does not reserve any driveletters for its own use. However, note that with the prevalence of USB memory these days, the use of driveletters lower than H: for network purposes is probably not advisable.

Synchronizing Time

To correct the workstation's clock you could use the Windows Time Service, but a far simpler approach is to include a command:


in the batch-script. This will synchronize the workstations with the server each time they log-on. The server does not need to be running any special software for this to work. The server's own time can be obtained from an external atomic source using Windows Time, or one of a number of freeware utilities.

Note: Time-synchronization an internal feature in the latest release, where a .mls script is used.

Multiple Servers - and accessing peers within a domain.

Where trust-relationships exist between multiple servers, you must  ensure two things are correct. The logondomain value must be correctly set  in mylogon.ini. This must point to the authentication-server's domain.  Also the script must use the correct syntax for shares.  Shares on the authentication-server need no special treatment, but  those on trusted servers should be in the following format:


So, for example we might map a share  in the master server, and one on a trusted server like this:


The @ or (@echo off for multiline instructions) command serves to prevent the credentials being visible onscreen. Note that there is no space between @ and the next character.  Because this method (invisibly) types the password in plaintext into the console window, it is not entirely ideal from a security point of view. The new script syntax offers a more sophisticated solution.  (see later)

The new script syntax.

MyLogon now permits the use of "ini-style" logon scripts. These are text files with the extension of ".mls" or ".ini" which would normally reside in the server's netlogon share. Optionally the script may be called from another location, by supplying a full UNC path. For very small networks with no 'real' server, the script may alternatively be placed in the local machine's MyLogon folder, in which case it should be referred-to in the settings with the "local:" prefix, for example "local:myscript.mls"

Note: There is no compulsion to use this new system, conventional scripts will work as previously.

The ini-style script has a number of section-headers, in square brackets. Within these sections, properties and their values are given as pairs separated by an equals (=) sign. The order of the sections in the file does not determine the order of their execution.

[RunBefore]

This section lists the programs to be launched before the drive mappings are established. Its syntax matches that of the Run or RunWait sections, see later. On most sites this section will be rarely used, but it's included for completeness.

[Mappings]

The heart of the script, and the place where the drive-letter that users see will be created. Each drive-mapping is created by way of a "Driveletter=Sharename" entry on a separate line. The driveletter must be followed by a colon, and the sharename may be either a full, valid UNC path, or as a shorthand entry the name of a share on the master server will also be accepted. 

Optionally, the driveletter may be replaced by a descriptive name, with no colon. This creates a share with no matching driveletter, but which should be accessible by its UNC name, or from Network Places. This format is useful mainly for shares used by the machine itself (e.g access to antivirus-update folders for the AV program's own use) that the user need not see on the desktop.

Examples:

H: = \\netserver\salesfolder

U: = \\netserver\homes\%user%

V: = \\netserver\machines\%computer%

Q:=medical

(The last one will connect the Q: drive to the medical share on whichever server the user was first authenticated-to, allowing for a very easy-to-understand syntax on small sites.)

[Run]

Lists programs to be launched after the mappings have been established. (Which is most-often the required action) - Programs are run concurrently, without any pause in the script. The entries consist of a descriptive name, an equals sign, and the UNC or local path to the file. Note that the user may be granted control of the machine whilst these programs are still in the process of launching.

Example:

[RunWait]

Similar to Run, but programs are launched sequentially, and each must complete before the next is launched. Beware that a program added to this section, but which never completes, could cause the machine to hang-up. It should therefore only be used for programs which must execute in a specific order.

Multiple Servers

With the new syntax, no special action is needed for trust-relationships, other than to ensure that the correct domain is specified in the  network-section of MyLogon.ini.

Macro substitution

In the above sections, the value part of any statement can contain either of the macros %user% or %computer% - in which case the real value of that variable will be substituted at logon-time. The username referred-to here is that entered into MyLogon. This allows for the access of user-specific home folders as shares, or machine-specific data. This also applies to conventional batch scripts, where %user% and %computer% (lowercase) are available as environment variables.