In my last article on User’s drive mapping, I had explained why we need drive mapping to the shared locations and how we can implement it using VBScript.
In this article I will explain what care we need to take when mapping any particular drive to the shared location. I will end the article with a scenario that I came across many times while doing drive mapping to the shared location.
When you are creating/designing the VBScript for the mapping logic make sure that you should not use
- the pre-defined user mapped drives like the drives for Floppy disk [like A drive], CD ROM [like E drive], Users data [like M drive], Roaming profile[like X drive], main drives [like C, D drives] etc. so before implementing the VBScript, make sure that which drives are available for mapping purpose.
Scenario: Suppose you have an application AppA, you have a requirement that this application should be able to access five different shared locations through the mapped drives.
Implementation: To implement it you have selected M, N, O, P and Q drives. Let’s say that M drive at user’s machine is already mapped for the user data.
You have designed you VBScript based on the above drives. Once you are done and when you had published that VBScript in XenApp, your user will complain that they are able to use/access all the shared locations except the one location that they mentioned in the requirement document.
Troubleshooting: Now as a XenApp administrator, you should get the information from your system administrator that what drives at user’s machine are mapped to some pre-defined locations. Like in above case M drive that XenApp Admin selected, is already mapped to the user’s data and so he should not have used/mapped it to any location. Now he has to modify the VBScript to point to the available drives. Once done, users will be “happy happy joy joy” and will be able to access all the required shared locations.