Persisting a Network share drive to a letter

Hi,
One of our application server boxes (Windows 2003 Enterprise SP2) needs to
have a connection to a network file share as the applications running on
this box read files that are present in the file server.

When i login to the app server box and create a drive letter (e.g) X: and
map ito the network share \\myfileshare.domain.com\sharename. It is good.
When I logout and log back in using the same user id and password that was
used to create the network drive, i don't seem to have that drive connected
automatically.

I tried NET USE X: \\myfileshare.domain.com\sharename password /USER:userid
/PERSISTENT:YES and did not get the desired results.

The user account for this operation has local admin privileges as well.

What am i missing in this process and is there any other way to make this
happen?

Thanks in advance for your time and help,
VC

You may want to create a logon script to map the driver.

--
Bob Lin, MS-MVP, MCSE & CNE
Networking, Internet, Routing, VPN Troubleshooting on
http://www.ChicagoTech.net
How to Setup Windows, Network, VPN & Remote Access on
http://www.HowToNetworking.com
"VC" <(E-Mail Removed)> wrote in message
news:%239H3LB$(E-Mail Removed)...
> Hi,
> One of our application server boxes (Windows 2003 Enterprise SP2) needs to
> have a connection to a network file share as the applications running on
> this box read files that are present in the file server.
>
> When i login to the app server box and create a drive letter (e.g) X: and
> map ito the network share \\myfileshare.domain.com\sharename. It is good.
> When I logout and log back in using the same user id and password that was
> used to create the network drive, i don't seem to have that drive
> connected automatically.
>
> I tried NET USE X: \\myfileshare.domain.com\sharename password
> /USER:userid /PERSISTENT:YES and did not get the desired results.
>
> The user account for this operation has local admin privileges as well.
>
> What am i missing in this process and is there any other way to make this
> happen?
>
> Thanks in advance for your time and help,
> VC
>

Forget "Net Use"

Open Windows Explorer and navigate to the network location.
Go to the address bar and Select/Copy the Path
Select the Tools Menu then select "Map Network Drive"
Choose the Drive Letter, and Paste the Folder path in
Check the Reconect box

It should persist the connection.

User must stay logged into the console,...logging out disconnects the
drive,...but it should reconnect when logging back on.

Programmers and the Applications they write need to come out of the dark
ages and stop making their Apps dependent on drive letters for their data
path. The days of doing things with Drive Letters should have died with the
days of Novell. They need to use UNC pathes.


--
Phillip Windell
www.wandtv.com

The views expressed, are my own and not those of my employer, or Microsoft,
or anyone else associated with me, including my cats.
-----------------------------------------------------

"VC" <(E-Mail Removed)> wrote in message
news:%239H3LB$(E-Mail Removed)...
> Hi,
> One of our application server boxes (Windows 2003 Enterprise SP2) needs to
> have a connection to a network file share as the applications running on
> this box read files that are present in the file server.
>
> When i login to the app server box and create a drive letter (e.g) X: and
> map ito the network share \\myfileshare.domain.com\sharename. It is good.
> When I logout and log back in using the same user id and password that was
> used to create the network drive, i don't seem to have that drive
> connected automatically.
>
> I tried NET USE X: \\myfileshare.domain.com\sharename password
> /USER:userid /PERSISTENT:YES and did not get the desired results.
>
> The user account for this operation has local admin privileges as well.
>
> What am i missing in this process and is there any other way to make this
> happen?
>
> Thanks in advance for your time and help,
> VC
>

Hi Phillip & Robert,
Thanks for taking the time to answer my question. Appreciate it much.
That was a pretty powerful wakeup call to use UNC names instead. I will look
into that option from our apps. I presume we should not run into any issues
to read/write to UNC names from .NET/CSharp applications.

Thanks,
VC
"Phillip Windell" <(E-Mail Removed)> wrote in message
news:uZHR$(E-Mail Removed)...
> Forget "Net Use"
>
> Open Windows Explorer and navigate to the network location.
> Go to the address bar and Select/Copy the Path
> Select the Tools Menu then select "Map Network Drive"
> Choose the Drive Letter, and Paste the Folder path in
> Check the Reconect box
>
> It should persist the connection.
>
> User must stay logged into the console,...logging out disconnects the
> drive,...but it should reconnect when logging back on.
>
> Programmers and the Applications they write need to come out of the dark
> ages and stop making their Apps dependent on drive letters for their data
> path. The days of doing things with Drive Letters should have died with
> the days of Novell. They need to use UNC pathes.
>
>
> --
> Phillip Windell
> www.wandtv.com
>
> The views expressed, are my own and not those of my employer, or
> Microsoft,
> or anyone else associated with me, including my cats.
> -----------------------------------------------------
>
> "VC" <(E-Mail Removed)> wrote in message
> news:%239H3LB$(E-Mail Removed)...
>> Hi,
>> One of our application server boxes (Windows 2003 Enterprise SP2) needs
>> to have a connection to a network file share as the applications running
>> on this box read files that are present in the file server.
>>
>> When i login to the app server box and create a drive letter (e.g) X: and
>> map ito the network share \\myfileshare.domain.com\sharename. It is good.
>> When I logout and log back in using the same user id and password that
>> was used to create the network drive, i don't seem to have that drive
>> connected automatically.
>>
>> I tried NET USE X: \\myfileshare.domain.com\sharename password
>> /USER:userid /PERSISTENT:YES and did not get the desired results.
>>
>> The user account for this operation has local admin privileges as well.
>>
>> What am i missing in this process and is there any other way to make this
>> happen?
>>
>> Thanks in advance for your time and help,
>> VC
>>
>
>

"VC" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Hi Phillip & Robert,
> Thanks for taking the time to answer my question. Appreciate it much.
> That was a pretty powerful wakeup call to use UNC names instead. I will
> look into that option from our apps. I presume we should not run into any
> issues to read/write to UNC names from .NET/CSharp applications.

Ok. Well I didn't expect you were the developer, didn't mean to be insulting
or anything. I admit I do tend to beatup on the developers
sometimes,..sorry :-)

But the App should be more dependable by using UNC paths though, if you can
get that done. The UNC path does not need to maintain a constant connection
state and should be able to work if you run the App as a "service" when no
user is even logged into the machine.

Drive letters require a constant connection to maintain the mapping which
are then subject to time-outs and unexpected disconnections that may not
reconnect gracefully. They also require a "user" to be interactively logged
into the Desktop,...the mappings are also unique to each user profile, so it
always has to be the same user,...and they become disconnected if the user
logs out. I heard there was a way to do them without a logged in user, but
it seemed convoluted to me and "just asking for trouble" in my opinion.

If you ever switch to some kind of database connection instead of a file
connection avoid using a DSN. They depend on mapped drive letters and
suffer from the same problems. Use instead what has become known as
"DSN-Less Connection",...they connect/disconnect on the fly as needed. I've
messed with some of these very issues when working with some ASP Classic
stuff (not ASP.net),...But I'm not a developer and so I should not venture
too far out of my "area" and make a fool of myself. :-)

--
Phillip Windell
www.wandtv.com

The views expressed, are my own and not those of my employer, or Microsoft,
or anyone else associated with me, including my cats.
-----------------------------------------------------

Hi Phillip,
Thanks for the detailed followup and extra tips. It is much appreciated.
No offense with your earlier feedback either. I took it as constructive
feedback, even though I am not the actual developer who has coded or has to
maintain that UNC piece. It is a bit more interesting how I got into this...
I own one Unix based app that is reading from a network mount (the mount is
actually mapped to the same NFS drive that the .NET app is supposed to
write). The .NET group was having issues in providing me files in that
UNC/NFS drive and I wanted to understand the various options that can be
utilized for this functionality.... hence this post.... But I learned a few
good items already because of this post and it was worth it.

Thanks again, I will have them try this out and post the outcome...

Cheers!!!
VC

"Phillip Windell" <(E-Mail Removed)> wrote in message
news:%(E-Mail Removed)...
> "VC" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> Hi Phillip & Robert,
>> Thanks for taking the time to answer my question. Appreciate it much.
>> That was a pretty powerful wakeup call to use UNC names instead. I will
>> look into that option from our apps. I presume we should not run into any
>> issues to read/write to UNC names from .NET/CSharp applications.
>
> Ok. Well I didn't expect you were the developer, didn't mean to be
> insulting or anything. I admit I do tend to beatup on the developers
> sometimes,..sorry :-)
>
> But the App should be more dependable by using UNC paths though, if you
> can get that done. The UNC path does not need to maintain a constant
> connection state and should be able to work if you run the App as a
> "service" when no user is even logged into the machine.
>
> Drive letters require a constant connection to maintain the mapping which
> are then subject to time-outs and unexpected disconnections that may not
> reconnect gracefully. They also require a "user" to be interactively
> logged into the Desktop,...the mappings are also unique to each user
> profile, so it always has to be the same user,...and they become
> disconnected if the user logs out. I heard there was a way to do them
> without a logged in user, but it seemed convoluted to me and "just asking
> for trouble" in my opinion.
>
> If you ever switch to some kind of database connection instead of a file
> connection avoid using a DSN. They depend on mapped drive letters and
> suffer from the same problems. Use instead what has become known as
> "DSN-Less Connection",...they connect/disconnect on the fly as needed.
> I've messed with some of these very issues when working with some ASP
> Classic stuff (not ASP.net),...But I'm not a developer and so I should not
> venture too far out of my "area" and make a fool of myself. :-)
>
> --
> Phillip Windell
> www.wandtv.com
>
> The views expressed, are my own and not those of my employer, or
> Microsoft,
> or anyone else associated with me, including my cats.
> -----------------------------------------------------
>
>

Hi Phillip,
Good news. I got the ocnfirmation from the Counterpart(s) that they were
able to read/write to the UNC name from within their .NET apps.

Appreciate your insights and time in this regard,
-VC

"VC" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Hi Phillip,
> Thanks for the detailed followup and extra tips. It is much appreciated.
> No offense with your earlier feedback either. I took it as constructive
> feedback, even though I am not the actual developer who has coded or has
> to maintain that UNC piece. It is a bit more interesting how I got into
> this...
> I own one Unix based app that is reading from a network mount (the mount
> is actually mapped to the same NFS drive that the .NET app is supposed to
> write). The .NET group was having issues in providing me files in that
> UNC/NFS drive and I wanted to understand the various options that can be
> utilized for this functionality.... hence this post.... But I learned a
> few good items already because of this post and it was worth it.
>
> Thanks again, I will have them try this out and post the outcome...
>
> Cheers!!!
> VC
>
> "Phillip Windell" <(E-Mail Removed)> wrote in message
> news:%(E-Mail Removed)...
>> "VC" <(E-Mail Removed)> wrote in message
>> news:(E-Mail Removed)...
>>> Hi Phillip & Robert,
>>> Thanks for taking the time to answer my question. Appreciate it much.
>>> That was a pretty powerful wakeup call to use UNC names instead. I will
>>> look into that option from our apps. I presume we should not run into
>>> any issues to read/write to UNC names from .NET/CSharp applications.
>>
>> Ok. Well I didn't expect you were the developer, didn't mean to be
>> insulting or anything. I admit I do tend to beatup on the developers
>> sometimes,..sorry :-)
>>
>> But the App should be more dependable by using UNC paths though, if you
>> can get that done. The UNC path does not need to maintain a constant
>> connection state and should be able to work if you run the App as a
>> "service" when no user is even logged into the machine.
>>
>> Drive letters require a constant connection to maintain the mapping which
>> are then subject to time-outs and unexpected disconnections that may not
>> reconnect gracefully. They also require a "user" to be interactively
>> logged into the Desktop,...the mappings are also unique to each user
>> profile, so it always has to be the same user,...and they become
>> disconnected if the user logs out. I heard there was a way to do them
>> without a logged in user, but it seemed convoluted to me and "just asking
>> for trouble" in my opinion.
>>
>> If you ever switch to some kind of database connection instead of a file
>> connection avoid using a DSN. They depend on mapped drive letters and
>> suffer from the same problems. Use instead what has become known as
>> "DSN-Less Connection",...they connect/disconnect on the fly as needed.
>> I've messed with some of these very issues when working with some ASP
>> Classic stuff (not ASP.net),...But I'm not a developer and so I should
>> not venture too far out of my "area" and make a fool of myself. :-)
>>
>> --
>> Phillip Windell
>> www.wandtv.com
>>
>> The views expressed, are my own and not those of my employer, or
>> Microsoft,
>> or anyone else associated with me, including my cats.
>> -----------------------------------------------------
>>
>>
>
>

Very good!
Good luck with all of it.


--
Phillip Windell
www.wandtv.com

The views expressed, are my own and not those of my employer, or Microsoft,
or anyone else associated with me, including my cats.
-----------------------------------------------------

"VC" <(E-Mail Removed)> wrote in message
news:ubm1D%(E-Mail Removed)...
> Hi Phillip,
> Good news. I got the ocnfirmation from the Counterpart(s) that they were
> able to read/write to the UNC name from within their .NET apps.
>
> Appreciate your insights and time in this regard,
> -VC
>
> "VC" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> Hi Phillip,
>> Thanks for the detailed followup and extra tips. It is much appreciated.
>> No offense with your earlier feedback either. I took it as constructive
>> feedback, even though I am not the actual developer who has coded or has
>> to maintain that UNC piece. It is a bit more interesting how I got into
>> this...
>> I own one Unix based app that is reading from a network mount (the mount
>> is actually mapped to the same NFS drive that the .NET app is supposed to
>> write). The .NET group was having issues in providing me files in that
>> UNC/NFS drive and I wanted to understand the various options that can be
>> utilized for this functionality.... hence this post.... But I learned a
>> few good items already because of this post and it was worth it.
>>
>> Thanks again, I will have them try this out and post the outcome...
>>
>> Cheers!!!
>> VC
>>
>> "Phillip Windell" <(E-Mail Removed)> wrote in message
>> news:%(E-Mail Removed)...
>>> "VC" <(E-Mail Removed)> wrote in message
>>> news:(E-Mail Removed)...
>>>> Hi Phillip & Robert,
>>>> Thanks for taking the time to answer my question. Appreciate it much.
>>>> That was a pretty powerful wakeup call to use UNC names instead. I will
>>>> look into that option from our apps. I presume we should not run into
>>>> any issues to read/write to UNC names from .NET/CSharp applications.
>>>
>>> Ok. Well I didn't expect you were the developer, didn't mean to be
>>> insulting or anything. I admit I do tend to beatup on the developers
>>> sometimes,..sorry :-)
>>>
>>> But the App should be more dependable by using UNC paths though, if you
>>> can get that done. The UNC path does not need to maintain a constant
>>> connection state and should be able to work if you run the App as a
>>> "service" when no user is even logged into the machine.
>>>
>>> Drive letters require a constant connection to maintain the mapping
>>> which are then subject to time-outs and unexpected disconnections that
>>> may not reconnect gracefully. They also require a "user" to be
>>> interactively logged into the Desktop,...the mappings are also unique to
>>> each user profile, so it always has to be the same user,...and they
>>> become disconnected if the user logs out. I heard there was a way to do
>>> them without a logged in user, but it seemed convoluted to me and "just
>>> asking for trouble" in my opinion.
>>>
>>> If you ever switch to some kind of database connection instead of a file
>>> connection avoid using a DSN. They depend on mapped drive letters and
>>> suffer from the same problems. Use instead what has become known as
>>> "DSN-Less Connection",...they connect/disconnect on the fly as needed.
>>> I've messed with some of these very issues when working with some ASP
>>> Classic stuff (not ASP.net),...But I'm not a developer and so I should
>>> not venture too far out of my "area" and make a fool of myself. :-)
>>>
>>> --
>>> Phillip Windell
>>> www.wandtv.com
>>>
>>> The views expressed, are my own and not those of my employer, or
>>> Microsoft,
>>> or anyone else associated with me, including my cats.
>>> -----------------------------------------------------
>>>
>>>
>>
>>
>
>