Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Westi on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Establishing connection to network share

Status
Not open for further replies.

theniteowl

Programmer
May 24, 2005
1,975
US
I have a .VBS script that backs up our log files from one server and stores them on a network share.

We log into the server with a local account but access to the share is through a domain account.
If a connection has not already been established to the share my script will fail with an error indicating the id or password is not valid.
The server knows the credentials to use for the share connection but apparently the FileSystemObject does not determine if alternate credentials are to be used and tries to use the logon credentials.

If you manually open a connection to the share the server will automatically pass the correct credentials and my vbs script will work perfectly. But if the server is rebooted the connection is no longer there and someone would have to manually intervene before the log backup script will work.

Any ideas on how to make sure the correct credentials are used, or how to ensure the connection is established prior to the FileSystemObject attempting the connection using the wrong credentials?

I might be able to get away with putting a shortcut to the share folder in startup so when the server boots it opens the share and authenticates. It just seems a work around approach and a script approach would be cleaner.

Anyone?

At my age I still learn something new every day, but I forget two others.
 
Another workaround approach, but possibly not reprehensible. Add the requirement to create a persistent mapped drive to the share and then access the share through the mapping. This is the only thing I am aware of without getting in to some Windows API stuff.

 
Another workaround approach, but possibly not reprehensible. Add the requirement to create a persistent mapped drive to the share and then access the share through the mapping. This is the only thing I am aware of without getting in to some Windows API stuff.

Fixed drive mappings are what we are getting away from.
The problem is that with Server 2003 SP1 + drives mapped with alternate credential no longer cache those credentials so if a connection is lost you have to manually intercede to re-establish the connection.
You can store the info under Stored Usernames & Passwords but for some reason nobody has been able to determine, every month when we reboot the servers those drive mappings end up causing account lockouts on the domain account.
We log into the box with a local ID but have to establish the mappings with a domain ID. The domain account ends up getting locked out 4-5 times during the monthly reboot of the servers which is annoying but it also occasionally happens on it's own. When the account locks out our applications on the server fail because they cannot access the shares they use for input/output and it results in production outages and 3:00am calls to us to fix it.

I am going to try setting up Stored Usernames & Passwords to save the credentials and then setup a shortcut to the drive in the Startup folder to force a connection to the share. It's a work-around but it's better than nothing.


At my age I still learn something new every day, but I forget two others.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top