Updated April 2022
The astute reader will have noticed that we rather glossed over the issue of drive mappings in the preceding discussion. Indeed, the essence of a network installation is setting up drive mappings so that each workstation can reference shared directories on the server. It is assumed that the installer will have enough expertise to create those drive mappings using the standard Windows procedures. However, there are a couple of subtleties worth mentioning here.
First, the server must "share" the drive that will hold the files common to all of the workstations. This much is obvious. However, although it may be desirable, it is not absolutely necessary that the workstations actually create a drive mapping to it. Instead, you can use the UNC (Universal Naming Convention) notation to reference the server and share name instead of the mapped drive letter. For example, assuming the server’s machine ID is "BIGBOY", and A-Shell is installed in the directory C:\VM\MIAME, you might share that directory as "MIAME" and then refer to it from all machines on the LAN in various contexts, including the install program, as \\BIGBOY\MIAME.
This technique has the advantage of eliminating the need to define a drive mapping to the server for every workstation, and eliminates any possibility of different workstations ending up with different mapped drive letters. If you decide to use the more traditional mapped drive letter approach, it is strongly recommended that you choose a relatively high drive letter (like X:) to reduce the possibility that you run into a workstation that has so many devices mapped that the desired letter is already taken up.
The only known disadvantages to using the UNC name of the server rather than creating a drive mapping are that you may experience a delay the first time you try to connect —while a dynamic network connection is established—and in some cases, such as after a period of inactivity, some servers may begin to drop UNC connections. This could cause a problem if the inactive application had files open.
Another subtlety to note is that since data transfer over the network is subject to bottlenecks, it is often desirable for performance reasons to define one or more devices (logical disks) that reside on each local workstation for the purpose of holding print files, temp files, that don’t need to be shared. This assumes that the application provides an option of where to send different categories of files, such as DSK1: for the master data files, DSK2: for print files, etc.
Note that whenever sharing directories, it is strongly advised—for both performance and security reasons—to share the smallest directory tree that includes all the necessary subdirectories. In other words, instead of sharing the entire C: drive, share the directory that contains miame.ini and the DEVICE directories beneath it.
