|
|
|||||||
I have just few questions on the use command. When I map a drive with the logon script all of my drives show up in My Computer in the following format: sharename on 'servername' (drive letter). Example var_rpt on 'Paragonrpt' (R:). However, one of our drives consistently maps correctly, BUT shows up as 'Network Drive (T:)' in My Computer. Sometimes it will show up correctly in My Computer. Could this be caused by the way I map the drive? Here's how I map: Code:
Is that a good way, or should I be mapping persistent? Also, I have noticed that in some examples people delete the drive first, then re-map it. Does it make a difference in the way you map? |
||||||||
|
|
|||||||
Just curious...Are you running SymantecAV? |
||||||||
|
|
|||||||
does this behavior only affect the T drive? and the T drive is a similar share on same server as R: and V: which do not have this effect? |
||||||||
|
|
|||||||
No to symantec. We're running Panda. T seems to be the only drive with this effect. |
||||||||
|
|
|||||||
also, is this on one wksta or multiple? it looks like windows sees the drive different. one could try to fix this by deleting the label keys from the registry... say: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints Remove the T key and reconnect the drive. not sure does this help. what more I think about this, it smells like a server thing. |
||||||||
|
|
|||||||
The reason I brought up Symantec is most of my customers have Symantec Corp Ed on their pcs. One of them has been experiencing the same thing you are describing, but it never causes any issues, so we just let it be. However, one of my other customers had a similar problem, except we could not remove the mapped drive, nor could we re-add it. It was like it was deleted, but still existed. Anyway, it turns out it was a bad install of SAV. Once we removed SAV, we were able to remap the drive, and then reinstalled SAV and everything worked properly again. |
||||||||
|
|
|||||||
This issue occurs on multiple workstations. It doesn't really effect anything, I was just wondering why. So, does it have anything to do with my original question? Does it matter how you map a drive? Is one way better than the other? Persistent or Not Persistent? Delete or No delete before the mapping? |
||||||||
|
|
|||||||
You should delete before you map or else you cannot be sure of what is mapped. No point in mapping persistent if it is mapped on every logon. |
||||||||
|
|
|||||||
Agreed. Never did understand why people do persistent mapping when they map during logon with a script. Either map it once and be done with it and don't do it in your script, or don't persistent map it. Yes, you should ALWAYS unmap or at least test if it's mapped or not. Maybe a user mapped it in which case your mapping would probably fail. |
||||||||
|
|
|||||||
Your code is overly optimistic. You don't check if any fail. You sould always use the /persistent switch on delete and why do you both shell out to NET to delete and also delete with the KiX USE command? |
||||||||
|
|
|||||||
I set up the kix delete command, and it didn't seem to delete the Z drive. That's what I shelled to the net use. I thought that I read that kix use can only delete drives it makes. Does 'use z: /delete /persistent' do something special? If the mapping does fail, what can you do about it during the logon? I can understand un-mapping before you attempt the map. That protects you from the dumb users, but how does catching an @error help? Go check through logs? I think I'm missing something. |
||||||||
|
|
|||||||
I guess the action would be commensurate with the error. If there is no consequence to the error, then no point in checking. |
||||||||
|
|
|||||||
Does 'use z: /delete /persistent' do something special? |
||||||||
|
|
|||||||
It will delete the Z: drive. Beware that is you have Win9x machines, deleting the Z: drive in the logon script is not advised. |
||||||||
|
|
|||||||
so, this is not your script but you got some relic from a previous admin. k, then I can say my first thoughts... it's really silly (if not worse) to go messing with Z: drive. as silly is also using the command line version of use when you are inside kixtart script. |
||||||||
|
|
|||||||
Basically Z got moved to Y. They had mapped Z on the PCs from within windows. I did the 'use z: /delete' but it had no effect - the drive wouldn't disconnect. That's why I added in the shell to the dos net use. It's only temporary. However, I guess a 'use /delete /persistent' is different than just a 'use /delete'. |
||||||||
|
|
|||||||
yes, persistent connections don't get disconnected without the persistent switch. |
||||||||
|
|
|||||||
That seemed like a long way to go to get that answer! Thanks! I'll try this, and see if the original problem goes away. (My Computer odd name) Code:
Maybe that'll help out. |
||||||||
|
|
|||||||
BTW, there are a couple of MAPDRIVE() UDFs that allow you to apply a custom label to a mapped drive. Also, usrrs can change the label of the mapped drive as well. Jens |
||||||||
|
|
|||||||
mapdrive or even Label() |