group policy for mapped drives

Lynne Desrochers · April 24, 2015, 04:27:52 PM

We use Applied's attachments for all of our scanning. For years we've had a login bat file that mapped our drives. We have a new tech company that wants to move away from the bat file, so on the new workstations they didn't add it to the user profile. Instead they mapped the S: drive to the individual users scanning folder. Now when those users scan and attach, the item does not automatically delete. Can someone shed some light on how this set up (probably through Group Policy) so that we can get our new users scanning without having to delete the items afterwards.
Thank you.

Hans Manhave · April 24, 2015, 05:44:39 PM

I believe that is in TAM. At the main menu, Tools, System setup, E-filing. Add the S: drive and/or folder to the setup and that should take care of it.

Jeff Golas · April 27, 2015, 10:43:21 AM

If it was done via Group policy, there's a couple ways to map drives, but the current way is in Group Policy (find the policy), then go into User Config > Preferences > Windows Settings > Drive Maps.

Jeff Zylstra · April 27, 2015, 11:14:23 AM

Quote from: Lynne Desrochers on April 24, 2015, 04:27:52 PM
We use Applied's attachments for all of our scanning. For years we've had a login bat file that mapped our drives. We have a new tech company that wants to move away from the bat file, so on the new workstations they didn't add it to the user profile. Instead they mapped the S: drive to the individual users scanning folder. Now when those users scan and attach, the item does not automatically delete. Can someone shed some light on how this set up (probably through Group Policy) so that we can get our new users scanning without having to delete the items afterwards.
Thank you.

There is a check mark box in TAM Main Screen - Tools - System - Settings, "E-Filing, Delete Files after Routing". Check and see if that is marked or not. If it is marked and it is still not deleting, then I'm thinking it may be a permissions issue, but that doesn't make sense unless permissions were somehow changed as well, or a new folder was created for these attachments. Just adding a new workstation would not do that since this folder resides on a server share which doesn't have anything to do with the workstations themselves.

And are you sure that batch files were copied to each machine to map this drive? Ours uses a similar setup to map this drive, but it done through Active Directory Users and Computer. Under each user's "properties" screen, there is a "profile" tab that specifies where that user's profile is stored and also what logon script runs, if any, when the user logs in. I think the scripts are stored in the %Username%\Scripts\Logon folder, or the %SystemRoot%\Sysvol\Domain\Policies folder. If you're on a workgroup instead of a domain, this may not apply, however.

Jeff Golas · April 27, 2015, 01:00:17 PM

If anyone is running a somewhat newer domain, I highly recommend switching from login scripts to Group Policy Preferences for mapped drives. Much better!

Mark · April 27, 2015, 02:52:17 PM

I do like Group Policies, but they can get messy. I will stick to my bat files for a while yet

Lynne Desrochers · June 03, 2015, 03:32:25 PM

It's a month later and they still have yet to resolve this issue. Can anyone share exactly how they are mapping the drive in group policy. Here's how it was working, we have a shared drive of S: under S: i have set up: S:\Scanning\usersname. In applied I told it to automatically delete when they attach from S:\Scanning. When my old users go to attach something they have to look for their name under the scanning folder. The new users still have to browse and find the right folder to get to their attachment and then it does not delete when they attach in applied.
Can anyone shed some light on this for me?
Thanks!

Jeff Golas · June 03, 2015, 03:54:01 PM

Well in Applied, you should just have them browsing to s:\, then map S as \\server\scanning\%username%, and have each folder match the users actual domain username.

So on the sever, you would have...

\\server\scanning\user1a
\\server\scanning\user2b
\\server\scanning\user3c

On the client side, user1a logs in and gets their S drive mapped as \\server\scanning\user1a

so his S drive would be mapped to the user1a folder.

Clear as mud? (Corrected typo above - meant to say \scanning\user1a)

Jeff Zylstra · June 03, 2015, 04:28:44 PM

Ours is done pretty much as Jeff said. In our case, each user has a "J:" drive that is mapped to \\Servername\EFiling\%UserName%. Then the "J:" is put in the TAM Homebase as indicated on the "system setup" screen below.

I would do 2 things. First, open Windows Explorer on a "new" user and an "old" user and see what drive letters are appearing, and exactly where those drive letters are mapping out to on the server. Second, I would actually watch someone scan a document who is having an issue. Check and see if they are checking the box to delete the file after they attach it.

A side note.... We are going through a HIPPA privacy procedure update, and I am noticing that some of my CSRs are using the J: drive to store scanned files. That is a no-no for "protected health information" because it is not encrypted while in that state. Btw, PHI is anything that has a name with ANY kind of health information attached like auto or Work comp claims, etc..... Even a name and the name of a doctor or doctor's office is considered PHI. The fines are pretty expensive, so just be aware. If anyone is interested, we completed a fairly lengthy HIPPA policy that I would be happy to share. Just PM me with your email address.