Map Network Drive Without Logging In

I am assuming the program which needs the mapping runs as a service.

The way this kind of problem is usually handled is to create a little service that runs a batch file or vb script to map the drive.  The main difficulty is that drive mapping is not a global operation - it depends on your user context.  So only the same service that maps the drive, or other processes in the same security context, will see the mapping.
http://support.microsoft.com/kb/149984/EN-US/

Can the find a way to have the program/service which needs the mapping to execute a batch file or vb script?  

I'll have to find out more about this application then.  I can write a batch file that will use the net use command to map the drive, but I'm not sure about the username/security that will be needed.

To give you a brief description on the application, it uses an SQL database stored on the same server.  Users will run an executable through a share on this server.  The executable interacts with SQL as well as other stored documents.

I am going to have to try to figure out then what I will store where.  I may have to re-think using the NAS and trying to store everything locally.

I was also planning on doing something similar for a backup exchange server by using the NAS to store the database and other data, but since exchange needs to see a drive letter also, I will end up with the same issue most likely.

What about using the Windows Scheduler to kickoff a batch file.? The batch file will map a drive using the net use command. The scheduler has an option to run a task "When my computer starts".

You can also try the net use /persistent:yes parameter but I think that it's user specific and only kicks in after logging in.

net use x: \\servername\sharename

try that at the dos prompt.  If you get no errors, you're good -- just create a one-line batch file to run at startup.

I recommend Mike Lin's startup control panel, from which you can create (and manage) startup files.  http://www.mlin.net/StartupCPL.shtml

Note: to stop the above just type net use x:  /delete

The drive mapping issue can be resolved, but there are other reasons not to store an Exchange or SQL database on a mapped share.    See http://support.microsoft.com/kb/31717c3 and http://support.microsoft.com/default.aspx?scid=kb;en-us;304261

For your specific situation, you need to understand exactly what process is going to be accessing the network device:  is it SQLServer (e.g. is it a stored procedure running the application programs),  or is it a seperate service running the application?   The whole problem is that your mapping must be accessible to the right process, and so should proably be executed by the same process/service.

Have fun

If you want to map a drive to the machine at startup, map it as follows:
Open Notepad
Type
Net USE X: \\servername\share     Replace the servername with the name of the server, and the share with the name of the share.

File --> Save as
SQLmap.bat
Change filetype to all
Save the file in a basic scripts directory.
Copy the file.
In Administrative Tools --> Users and Computers, right click the OU in which the computers reside.
--> Properties --> Group Policy Tab
Create a new group policy and call it SQLscripts

Then, in Computer Configuration --> Windows Settings --> Scripts
Right click on Startup --> Properties --> Add button
Browse button
Right click in the window and paste the script
Click Open --> OK --> OK

The script will work after AD has replicated or after you from the cmd prompt on the workstation run gpupdate /force

The rel question here, though, is why doesn't the executable simply connect to the SQL server via a Named Pipe, ODBC, or by installing the SQL client on the workstations that need to connect?

It seems to me that the database can remain on the NAS.  The application should reside on the workstation; if not, the folder in which the application resides on the NAS should have local group permissions for the users as required.
Then, any user in the group who runs the app should be fine.

ONE MAJOR SECURITY NOTE: Do not include a runas in the script because the scripts reside in read only containers that prying eyes can find easily, and then a username and password will have run amuck.