Back to my other question on this thread
How do people handle files that are in use by users during a live image?
Example User A has FileX, FileY and FileZ open during a live image of their home directory on the server.
- FTK Imager says that the file could not be processed because it was in use.
- I have been individually copying those files to a local drive folder and then imaging that folder again.
I don't understand how you're even getting such a message. Imager is designed to specifically get around any issues with open files. That's why it can copy out registry files on a running system. It doesn't use the Windows API, so file permissions should not be relevant.
Are you adding your evidence to Imager as a physical device (logical if you have to because of encryption, for example)? The only situation I can envision you getting such a message is if you are adding the contents of a directory, which throws you back into using the Windows API.
Bryan
Yes, it happens when the image is taken of a contents of a directory/folder. Happened recently when doing a networked shared drive. Generally the file that errors out includes a ~*.TMP with it - which means the file is open. If I wait till the user has closed the file and reimage that folder, it works.
-=Art=-
Bryan
Yes, it happens when the image is taken of a contents of a directory/folder. Happened recently when doing a networked shared drive. Generally the file that errors out includes a ~*.TMP with it - which means the file is open. If I wait till the user has closed the file and reimage that folder, it works.
-=Art=-
But how are you ADDING what it is you want to image? If you are imaging a share on a server, for example, you should be doing the image on the server. Add the server's physical drive and then select the appropriate share for adding to a custom content image. Imager is still addressing the device physically and won't have "in use" problems. It won't matter if those .tmp files are open or not, Imager will get them without throwing off an error.
It sound's like you might be trying to image via a mapped drive on a client? There are times when you might be forced to to that, but most of the time you can probably get the files at the server and do away with the issue you're having.
It sound's like you might be trying to image via a mapped drive on a client? There are times when you might be forced to to that, but most of the time you can probably get the files at the server and do away with the issue you're having.
I wouldn't expect law enforcement to adopt this approach, but on internal corporate investigations it happens quite frequently. The most common reason for it is that the client wants to avoid getting their IT team involved.
Yes, in this case, the mapping was done directly to a server share (like K) and then that share was imaged.
The method you suggest would would work if the physical data drives were on the server, but does not work (or does it?) with a NAS or SAN device that is on the network.
IT generally does not want us in the server room with physical access to the server.
I'm open to suggestions… always….
Thanx
-=Art=-
As a corollary to this
Does running FTK imager from a thumbdrive slow down the process as compared to running it from the laptop/server - all other things being equal.
Can anyone suggest an alternative to FTK Imager for these kind of mapped drive acquisitions ?
Yes, in this case, the mapping was done directly to a server share (like K) and then that share was imaged.
The method you suggest would would work if the physical data drives were on the server, but does not work (or does it?) with a NAS or SAN device that is on the network.
IT generally does not want us in the server room with physical access to the server.
I'm open to suggestions… always….
As a corollary to this
Does running FTK imager from a thumbdrive slow down the process as compared to running it from the laptop/server - all other things being equal.Thanx
-=Art=-
I'm not totally sure if there is a speed difference or not running from a thumb drive vs a hard drive, but my sense is that there is not. I guess you'd have to test it.
It's been a while since I've done a SAN, but I'd still try to start with the server the SAN is hanging on, regardless of what the IT guys want. This is your client or your company, right? If you can't add the physical drive, try the logical . . . anything but the contents of a folder.
With live server acquisitions I have had the most problems with Exchange files. You can often get around this using NTBackup, it might work on other files.
I thought I had a speed difference with USB but have not confirmed it.
So… adding a Logical drive - like K and then choosing the specific folder as a Custom Content Image would bypass the locked files problem?
Also, would doing it this way give me more fileslack and unallocated etc from within that folder itself?
Next time we will be more forceful in getting to the physical machine - this was a client and I didn't realize it would be an issue.
Live n Learn…
I'm not totally sure if there is a speed difference or not running from a thumb drive vs a hard drive, but my sense is that there is not. I guess you'd have to test it.
It's been a while since I've done a SAN, but I'd still try to start with the server the SAN is hanging on, regardless of what the IT guys want. This is your client or your company, right? If you can't add the physical drive, try the logical . . . anything but the contents of a folder.
Greetings,
EnCase Enterprise will handle remote server collections quite well. The price is a bit steep, but if you happen to have it around then just install the servlet, fire up EE, and wait.
You could use F-Response plus anything other than FTK Imager.
You could use EnCase rather than FTK via a mapped drive.
-David