App can’t access file on server if local login; ok if network admin logs in

Topic

New Reply

Sure would appreciate some help with this. We have several log in “kiosks” running CheckPoint software on Windows XP at our Church for registering for classes. One of the “kiosks” the Checkpoint software will cannot access the needed file. If I log in as a local user/admin and try to start the app, it says file H: etc. can’t be found. I can see it on “computer”. Its there, I can open it. If I log in as the Network Admin, it can see it. None of the other five “kiosks” have a problem, they were set up identically and the problem “kiosk” was working.

I greatly appreciate any help with this.

Ihor43us

Reply | Quote

Replies

Are the kiosks set up from a common image? Can you re-image the troublesome computer?
Do the kiosks auto-login?
What login do you use on the other computers?
Have the kiosks been upgraded via Windows Updates recently?
What version of Windows?
What server software?
Domain or workgroup?

cheers, Paul

Reply | Quote

Are the kiosks set up from a common image? Can you re-image the troublesome computer?
Do the kiosks auto-login?
What login do you use on the other computers?
Have the kiosks been upgraded via Windows Updates recently?
What version of Windows?
What server software?
Domain or workgroup?

cheers, Paul

Paul, thank you for the quick reply and apologies for the slow response – I am trying to get answers from the site, I won’t be there until Sunday.
We are running Windows XP so no updates and if there were, all would be effected.
We are running AC so Domain.
We are using the same login for all Kiosks. The process is to log in to Windows XP (nice to see that field again) and click on the CheckPoint icon on the desktop. On the recalcitrant kiosk we get a window saying it could not locate drive D: etc. When I look at “computers” I can see the drive and open it.
When we log in as the Network admin, and click on the icon it opens up the application. It might have something to do with the AD permissions but I do not know where to look.

Reply | Quote

I assume H: is a mapped drive letter to a network resource.

On the one having an issue verify that the H: drive is still mapped. May need to recreate the H: drive mapping.

You may want to change to using the UNC path so it is not depending on a mapped drive letter.

Reply | Quote

I assume H: is a mapped drive letter to a network resource.

On the one having an issue verify that the H: drive is still mapped. May need to recreate the H: drive mapping.

You may want to change to using the UNC path so it is not depending on a mapped drive letter.

Thanks Boyd, but since we can access if we log using the network login it seems to me that the mapping is OK. It hinges on how the DC sees the two logins. The puzzling thing is it was working…….

Reply | Quote

but since we can access if we log using the network login it seems to me that the mapping is OK.

That is not true. Each user has their own mapping unless you are using logon scripts to always map the drive letters. Which I recommend.

TIP: Swithing to UNC paths would solve the issue.

Reply | Quote

That is not true. Each user has their own mapping unless you are using logon scripts to always map the drive letters. Which I recommend.

TIP: Swithing to UNC paths would solve the issue.

Did not know that – thanks.

Please clarify “UNC paths”.

TIA

Reply | Quote

Hi
UNC = universal naming convention.
A convention whereby the path explicitly references the computer name \computernamesharefilepath
Note the leading double slash.

This link might help.

Cheers
G

Reply | Quote

@geofrichardson geofrichardson is offline , thanks for jumping in with your helpful explanation.

Another way to think of it is this: a mapped drive letter is like a shortcut for part of the path of the full UNC path.

Example:

UNC full path:

\computernamesharedatabasesmydb.accdb

map H: to \computernameshare

so the path would becomes: H:databasesmydb.accdb

Using the UNC is the full path without the drive letter shortcut.

I have also see issues with the TCP/IP settings to the DNS set net properly. Using the the IP to the server has neer failed for me. (Note: I also use static IPs.) For UNC paths I prefer this method. Example: \192.168.1.10sharedatabasesmydb.accdb

Reply | Quote

Rather than change anything yet, work out why you get the error message.
1. At what point do you get the error message?
2. What do you run at logon?
3. Is there a logon script that maps drives / runs things?
Use MS Autoruns to view the start up items.

cheers, Paul

Reply | Quote