Current Scenario: I have a NAS Box, and a Windows 2003 Server that our recording software is on (Security Cameras). The software stores the data on the NAS box. Currently someone has to be logged in with valid credentials in order to keep the drive mounted (e.g. domain admin). I know you can mount the drive with a batch file, but this stores credentials in clear text and is not a good solution. I am looking for another way to get the drive to mount on startup without someone having to be logged in. I do have a generic account setup that has access to read/write to the drive but can't log-in interactively, this is the account I would like to use to mount it if any. Any suggestions?
Mount a network drive when windows starts up without being logged in
automountmountnetwork-attached-storagestoragewindows-server-2003
Related Solutions
If it's a clone as you say then you really need to run sysprep on it, just unjoining and rejoing the domain isn't enough to fix the SID issue AFAIK.
There are VMware docs that explain where to put the sysprep binaries on the VC server so that when you clone a VM that the cloning process can automatically run a sysprep on the new VM for you. Unfortunately the docs could be better at explaining exactly what to do, this link explains somewhat better.
Given the performance levels you are trying to hit then you should bear a couple of things in mind.
The earlier suggestion to format the drive holding your data set with an NTFS cluster size > 25k is a good one, 32k seems like a good choice for your use case. The purpose of doing this is to ensure you're avoiding have to deal with fragmentation if at all possible, and lowering the file system overhead associated with reading in a single file.
Also I'd suggest taking a look at your RAID stripe size. If the nature of your data set results in (mostly) sequential IO then a larger stripe size is more beneficial, if it's random then a smaller stripe size will be smarter, just don't make it any smaller than your files system cluster size. Given the description of what you're trying to do I'd say your IO profile is mostly random so a stripe size of 64k would be fine but it might be worth experimenting with.
What's very important is to make sure the partition is aligned - you will want to use Diskpart.exe on your systems, generally setting an alignment offset of 64k does the trick with standard cluster and RAID stripe sizes but a 1024k offset is used in Vista\Windows7\W2K8 as it will ensure alignment even with larger stripe & cluster sizes. There is a very good article on SQL server performance from Microsoft here that explains the reasons why this is important to do for high performance drives\arrays. The short version of this is that a poorly aligned partition can degrade IO performance by 15-30%.
For SSD's the same general rules apply but the underlying behavior of reads\writes is vastly different. Rather than dealing with 512byte disk sectors at the most fundamental level IO on SSD's uses much larger blocks. Reads tend to be in fixed page sizes of between 4k and 128k, writes involve buffering and large erase block sizes (in the megabyte range). The key thing for you (where read IO is important) is that you want to set your RAID stripe size to be a multiple of the read page size for the disk type you select (I think the Intel X-25's all use a 128k read block) and you want to set your alignment offset to some number that ensures it is greater than that. The standard recommendation of a 64k partition offset would be a poor choice if the SSD has a 128k read page size for example. Because of the asymmetric nature of SSD writes it isn't easy to optimize SSD RAID arrays for write performance but that's a whole 'nother story and involves lots of cache.
There's a nice article on optimizing SSD RAID here on the OCZForum, it's aimed at enthusiast setups but they get the general message right for anyone trying to roll their own SSD RAID from off the shelf kit as far as I can tell.
Finally if your read IO pattern is predominantly sequential the 8 15k drives can (in theory) hit somewhere in the ballpark of 800Meg/sec if not more. Two SSD's, even Intel X-25E's, will only hit about half that. I'd guess that your read IO pattern is biased enough towards random IO to negate this but under the right circumstances your 8 15k SCSI drives can be a lot faster than the two SSD's. This is borne out by your testing. Looking at those numbers though I'd say that some work with partition alignment and stripe sizes will help quite a bit.
Best Answer
What is the reason that you need to map a drive? Is it just so that you can store the user credentials? If the security PC can save to a UNC path (\\servername\share), then you could try running the service as a different user, one that has permission to access the share.
Let me know if I am on the right track here:
\\nasbox\SecurityFootage is where the files must be saved to, but they do not permit anonymous read/write access. So, at the moment, you map a network drive, (let's say M:), using credentials, and tell the security cameras to record there.
Because the security software runs as a service, you would prefer it if could just start automatically with the system, and write to the M: - but at the moment it can't because there's no anonymous access to \\nasbox\SecurityFootage
IF the scenario I've just described is accurate, then there is workaround:
This will mean that when the recording service starts it will be run under the account specified, and will thus have permissions to save to \\nasbox\SecurityFootage