Making network drives available to Windows services
Background
Windows services running under the "Local System" account are defined by the system to have no network access. (See service properties screenshot below.)
The problem here is not with user names, passwords, or startup timing; the problem is that services running under the "Local System" account are not able to see network drives, by definition. That is part of the Windows design.
Secure but read-write access to network drives must occur through a different, specific user context. Furthermore, what you map as a local drive from your Windows session is independent of what the service sees, as it is running in a completely different user environment. (Think: multiple concurrent logins here, and the service is running as "Local System" before you log in.)
There are some workarounds to this problem, but they are often complex, and either unreliable or awkward in one way or another. FirstClass customers have sorted this out using a variety of approaches, sometimes simply by not running the FirstClass server as a Windows service.
Direct support in 8.2
However, the best solution is for the service in question to directly support mapping network drives, using credentials supplied by the administrator.
In FirstClass 8.2, the FirstClass Server for Windows directly supports this, through a "volumes.cfg" file, placed in the FCServer folder (with FCS.EXE).
This is the first part of a longer-term approach to divorcing the server from the physical restrictions (such as drive letters) that are currently part of the requirements for server volumes. See the volumes.cfg example format below.
Because this so dramatically resolves this awkward problem for Windows services, but also a generally useful feature on all platforms, the OS X and Linux servers will also support the same mechanism for mounting volumes in a future server, although this is not supported as of 8.2. There are existing solutions for OS X, and similar simple script solutions work on Linux as well.
Using volumes.cfg
This configuration file is a simple text file formatted as keyword=value pairs (like a Windows INI file, and similar to the inetsvcs.cf file or the server's NETINFO file).
To create auto-mounting volumes for the FirstClass server, first you must create a [Config] section. Currently, there are two keywords that can be used there.
• The first [Config] keyword is Mounts, which is the number of volumes to mount. For example, Mounts=2.
For each of those drive mounts, create a [MountN] section, where 'N' is an index, from 1 to Mounts. In the example above, it would be [Mount1] and [Mount2]. In each of those sections, provide the remote UNC path of the volume to mount, the local mount point (drive letter), and the user ID and password for that remote server.
• The second [Config] keyword is Primary, which allows you to tell the FirstClass server that the primary FCNS volume is not the same volume where the executables folder is found. This allows you to start the FirstClass server on a local volume, for example from a Windows service, then have it mount a volume that it will use as the primary FCNS volume.
The [Volumes] section is optional, and not needed for most installations. It allows you to override (specify) the FirstClass name for the mounted volume. This is what is displayed in the Volumes list on the administrator's Desktop. The primary volume must be called "Master" (OS X) or "master" (Linux), so that example is also used here in this Windows example file.
The format is VolumeName=MountAsName.
The label before the '=' is the volume name to use; the drive path after the '=' corresponds to the MountAs name from one of the Mount sections that follow (or a local drive path). The [Volumes] section is not needed unless a Primary= option is specified, but in that case, the specified volume name must be available after mounting.
Example volumes.cfg file
[Config]
Mounts=2
Primary=Master
[Volumes]
Master=F:\
[Mount1]
Mount=\\server\firstclass
MountAs=F:
User=server\me
Password=secret
[Mount2]
Mount=\\server\mirror
MountAs=M:
User=server\me
Password=secret
This example file uses colors to attempt to better illustrate the relationship between the entries. For example:
• The Mounts=2 directive shows that the server expects to find two Mount sections, Mount1 and Mount2.
• The volume name specified in the Primary= line must exist in the [Volumes] section, and must match the name specified (Master).
• On Windows, the path of the volume (F:\) follows the Master= line and corresponds to a MountAs name in one of the mounts.
This would mount two network volumes (firstclass and mirror), from the server file server, as drives F: and M:, respectively.
Furthermore, the Primary directive tells the server to look for the primary FCNS folder under \\server\firstclass (which is mounted as F:). This allows the core server to start from a different disk volume than the volume containing the primary FCNS. This is most useful for Windows services, allowing the FirstClass server to be installed on the Windows system volume, but then
mount a network volume for use as the primary FCNS volume.
 NotesWindows has a limitation that all drives mapped from any given server to a given machine must use the same user credentials.
You must specify the authentication domain (typically the file server name) in the User field with a backslash before the actual user ID is specified (see the example above).
| 
