Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1430
  • Last Modified:

Automatically mounting network share and TrueCrypt containers on Windows Server 2003.

We have a TrueCrypt container on a NAS containing a network share. The network share can be mounted using the Net Use command properly (the machine mounting it is running Windows Server 2003 Small Business Server). Permissions are, for now, set to all access for everyone for the share. The TrueCrypt container can be properly mounted through a single command-line command. We realize this is insecure; once we get this working, this is a temporary setup that will be secured, we just have to get this working for a brief time.

Mounting the share works properly with the net use command, and mounting the TrueCrypt container located on the share from the command line works properly. We want the share itself to be automatically mounted on boot and the TrueCrypt container on the share also mounted on boot (again, for security reasons, this is temporary but needs to be in place for a brief time). We have created a logon script (assigned through Group Policy to the Windows Server in question) that uses net use to mount the share then executes the TrueCrypt command to mount the TrueCrypt container.

If we disable the logon script (so that it doesn't run automatically on machine boot), log into the machine, and run the script manually, it works perfectly (mounts the share using net use, then mounts the TrueCrypt container using TrueCrypt.exe on the command line), indicating th script should work fine. However, if we assign it as a startup script, it doesn't work. When we assign the script as a Startup script to the machine, reboot the machine, log in, and check to see if everything mounted properly, the share itself will be mounted, but the TrueCrypt container won't.

We notice that when the known-good script is assigned as a Startup script to the machine, while the share does mount (and, again, the TrueCrypt container doesn't, despite the script being known-good), the share is listed as "Disconnected Network Drive". We can open Windows Explorer and navigate to it (and are able to view the files on the share, etc), but in Explorer the label associated with the drive (next to the drive letter) is "Disconnected Network Drive" and if "net use" is executed by itself at the command line (to list all currently attached network shares and the like), net use reports that no shares are mounted (despite the fact that we can navigate to it in Windows Explorer and see the files within.

We have tried setting a Group Policy parameter (under Administrative Templates) that is supposed to delay script execution until the network is initialized, but it seems to have no effect.

We assume the issue to be related to Windows not having the network fully initialized to properly and completely mount the share through a logon script. Is there a way to delay Windows to ensure that a net use command that mounts a network share will only execute when the network is fully initialized? Is whatever user context that Windows attempts to mount the share in (we assume it to be a System account) when executing the net use command in the logon script an issue, and if so, is there a way to specify what user account the logon script runs under?

Thank you very, very much in advance for your assistance. If further detail is required, I will be happy to post it.
0
VLib
Asked:
VLib
1 Solution
 
marek1712Commented:
Maybe you could do something with this share?
E.g.:
net use Z: \\server\some_share
cd z:
and then mount the conainer.
Alternatively you could implement wait command for ~20s and then mount:
http://malektips.com/dos0017.html
0
 
coredatarecoveryCommented:
Are you using certificate like files for the mount?
0
 
McKnifeCommented:
Hi.
You could define a scheduled task, then you could set a user account to execute the TC script.
0

Featured Post

Cyber Threats to Small Businesses (Part 2)

The evolving cybersecurity landscape presents SMBs with a host of new threats to their clients, their data, and their bottom line. In part 2 of this blog series, learn three quick processes Webroot’s CISO, Gary Hayslip, recommends to help small businesses beat modern threats.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now