If you’ve newly setup a network, you may go to Windows Explorer, look under ‘Network Neighborhood,’ and happily see that, sure enough, you can read what’s on the drives of every other computer in the network  Very neat.  You might think this is all that should be needed in order for ServiceDesk (or any other Windows-based application) to access those other drives.  In fact, you’d be wrong.  While Windows Explorer may be able to “see” and show you the other drives without further work, those drives will remain invisible to most applications absent a little thing called “Mapping.”

What is mapping?  Basically (and in a nutshell), it’s the process of designating from one computer that all or part of its drive is available for “sharing” with others, giving that shared offering a “Share Name,” then, from another computer, linking to that shared offering with a Drive Letter Designation.

How do you do this?

As a short answer, we might say this is not a ServiceDesk topic; it’s a Windows topic, so don’t bother us; look in your Windows documentation instead.  However, we’re a little nicer than that, and will here give you a brief “how to” (suitable at least for Windows 95/98; later Windows versions may slightly vary) as follows.

As a beginning matter, remember there are two major steps: first, making the wanted drive available for sharing from the computer you'll be using as FileServer (we'll assume here that it's that computer's Drive C:); and second, setting up any and every secondary computer to read from that FileServer's Drive C:.

To accomplish the first step (making the FileServer's Drive C: available to other computers), click on the Network icon in that computer's Windows Control Panel (accessed by clicking on Start, then Settings).  Under the Configuration tab, click on File and Print Sharing, and from there assure you're configured to allow others full access to your files.  Next, using either Windows Explorer or the My Computer utility of that computer, select Drive C:, then click on Properties in the File section of the Menu.  Now, under the Sharingtab, provide a Share Name (something simple like "DRIVEC" works fine).  Finally, select Full access, then click on OK.   Assuming your network is otherwise functional, your FileServer should now be ready to share the entire contents of its Drive C: with other computers.

For the second step, your other computers need not just to see the FileServer drive from across the network (a basic assumption in network functionality) but, more critically, will need a Drive Letter Designation with which to reference it.  This is the same kind of designation as in 'A:' for your floppy drive, for example, or as in 'D:' for your CD drive—only here you'll be using a different drive letter than any already used.  To assign this Drive Letter Designation at any workstation, first run Windows Explorer from that station.  In the left-hand column, locate the Entry labeled “Network Neighborhood.”  Click on it to expand and look within its contents.  Once you have there located the other drive that you wish to map locally (presumably the one being used as FileServer), right-click on it.  In the little drop-down menu which then appears, select “Map Network Drive.” Windows will then produce a little box in which you specify the particular drive letter you wish to assign.  Make your selection (we use S: as a reminder for Server, but you can select any letter not already used by an existing drive).  Also check to true the box labeled “Reconnect at Log on,” then click on OK.

Under Path type in the actual path for the drive—as revealed when you showed it expanded under Network Neighborhood over in Explorer's left column.  When typing in this path, use two back slashes before the computer's name, then one before the share name, with no spaces between (e.g., as setup in our office, we use \\SERVER\DRIVEC).

With this accomplished, you should now see the newly-mapped drive listed in Explorer's left column, in a direct line below (i.e., in the same hierarchy of listing) as My Computer.  But here, as opposed to the computer's mere name listing under Network Neighborhood, the description will include that all-important Drive Letter Designation.  It's in parenthesis following the description, and it's proof you've accomplished your task.

As final proof, you may run ServiceDesk, bring up the Settings form (Crtl-F1), and click the down-arrow in the box labeled ‘Drive Designation for ServiceDesk Network FileServer.”  The mapped drive should appear in the list.  Indeed, assuming that it was properly mapped, it must appear within this list.

Bear in mind this second part must be done on each and every computer that you’re using a workstation (i.e., each that will be reading the common ServiceDesk data files from elsewhere).  Simply because you’re mapped the shared drive to one station, it does not mean that the next station is similarly ready.  This work must be done on it too.

‍

For security reasons, some users have not wanted to make the entire contents of one computer’s Drive C: available to other stations in the network.  They’ve wanted, in other words, to limit the shared access to just the particular folder that contains the common ServiceDesk data files, while preventing shared access to anything else.  With the release of Version 3.8 (74), this is now possible.

To setup for this, go through the mapping process just as already described, except instead of designating all of Drive C: for sharing, designate only the \SD folder (which, obviously, will need to have been setup already on the applicable machine).

ServiceDesk copes with this different setup as follows.  Normally, when a full drive is shared, ServiceDesk looks for a root folder within that drive called \sd, and then for the various sub-folders (under \sd) that should be created when ServiceDesk is installed and first run.  The difference is, when you share the \sd folder itself, it does not show when ServiceDesk does it’s standard look for appropriate folder structure.  Instead, each of the sub-folders show as though they exist on a root level.  The solution, if ServiceDesk does not “see” an \sd folder on the root level of whatever drive is designated as FileServer, it looks for what’s normally the sub-folders, but on an apparent root level.  If it finds these, it assumes that it’s dealing with a folder-only shared situation, and reacts accordingly.

Until release of the same revision as mentioned above (3.8 (74)), it was always our expectation in ServiceDesk that each station would keep and use its own, local copy of various operating files, including the program file itself (servdesk.exe), the file that instructs the system in the wanted format for printing invoices (*******.prg), and each of the five CstmrDbase indexes.  The reason for this strategy is to maximize performance.  If a station has to go to the server for each of these files (and if multiple stations are going to the server simultaneously), there may be little delays and pauses as the server works to keep up with demand.

In general, the standard setup works very, very well.  However, the old-fashioned setup of  having a comparatively powerful central computer with relative “dumb” terminals connected is making something of a comeback, and at least one client has been found flirting with the idea of adopting such a system.  If this is the system, it becomes almost necessary to keep the operating files (as opposed to merely the data files) at one, central location.

Plus, there’s a practical advantage, for there’s some amount of overhead that goes into keeping up-to-date operating files on each of various machines.  Every time you update the main program file, for example, updated copies need to be transferred to each station.  When you create or revise that *******.prg file, each station needs its own copy.  When the CstmrDbase indexes are updated, each station needs its own set of copies.  And so on.

For reasons of these impetii, we’ve now made the system workable with a single set of Server-based operating files.  The trick to make it work is very simple.  From any station, simply run the particular servdesk.exe file that’s found on the server (rather than one that may or may not have been installed locally).  When started, ServiceDesk looks to see what particular drive it’s being run from.  It looks to thatdrive for other operating files—even as it continues to look locally for strictly local information, in particular the file that keeps track of each station’s local settings.

We do not yet know of anyone using this option.  If you choose to do so, please let us know how it works.