We've several hundred users. I've started using kix for basic drive / print mapping tasks (and hope to expand on this). However, the @UserID variable doesn't equate to the users' home directory value. i.e John Smith needs a mapping to \\Server\J.Smith$
This is the same for every case. Any help in simplifying this task would be much appreciated.
#140105 - 2005-05-2110:25 PMRe: Personal drive mapping issue
NTDOCNTDOC Administrator
Registered: 2000-07-28
Posts: 11634
Loc: Space
Hello Benjamin and welcome to the board.
Well I'm sure we can assist you, but it would have been much easier if all your user directories were named exactly as the userid is. Since the're not you now have to manipulate any code you use to match the pattern used.
1. What Server OS? 2. What network structure - NT4 or AD? 3. What version of KiXtart are you using? 4. What are the client desktop OS involved?
Please explain in detail what makes up the USERID and what makes up the HOME FOLDER structure.
Using SPLIT,InStr,SubStr etc with @FullName, @USERID will probably help you out. Please give us solid examples of the layout and answer the above questions and I'm sure we can quickly get you going in the right direction.
#140106 - 2005-05-2212:43 AMRe: Personal drive mapping issue
NTDOCNTDOC Administrator
Registered: 2000-07-28
Posts: 11634
Loc: Space
1. Would not recommend using a PERIOD in the user's folder name either. 2. Would not create all the shares off the root of a volume or drive. Better to have something like D:\USERS and then create all user folders and shares under D:\USERS 3. Would also use USERID as the name of the folders
Here is some example code that assumes the @FullName is setup with FIRST -space- LAST There is no error checking or validation either which might be required if there is a typo in the user's @FullName description.
Thanks Doc & thanks for the prompt response. In answer to your questions;
1. What Server OS? = Windows 2003 SP1 2. What network structure - NT4 or AD? = Single Domain AD Forest 3. What version of KiXtart are you using? = The latest (KiX2001.423) 4. What are the client desktop OS involved? = Mixed 2000/XP (mostly 2K SP4)
The user folders have been created on a large volume of the File Server as E:\UserData\J.Smith and subsequently shared with a $. I'm not adverse to the idea of spending time today (Sunday) removing the shares and renaming if I must but a 'shortcut' would be preferred. I'm most interested in the logic of your last response. Is there a way to log scripting issues / failures etc.?
Also, by Full Name, I can confirm that Display Name attribs are present? (is this what you mean)?
I'll prepare my rename and permissions batch files (using csvde & excel) whilst I await your reponse in case you recommend going with best practices from the outset ;-)
Why even bother to share them out individually? A single share one level up (E:\UserData\)would suffice. Best practice would be for them to match @UserID.
Alternately, you could set them in the user's profile instead of mapping them in KiX.
_________________________
Give a man a fish and he will be back for more. Slap him with a fish and he will go away forever.
#140110 - 2005-05-2209:01 PMRe: Personal drive mapping issue
NTDOCNTDOC Administrator
Registered: 2000-07-28
Posts: 11634
Loc: Space
Personally don't agree with Les on the single folder share, yes it can and should be controlled by NTFS permissions... however I know that dropping into a main share folder for your home directory and being presented with 1,000+ folders is a pain to get to yours. Yes you could create shortcuts to take you there, but if using that route then there would be no need to even map a drive for the user in the first place. But the reason you do it is to make it easier for your users and cut down on the helpdesk calls. Many users don't have a clue how to create a shortcut or map a drive like it or not and you can't personally spend the time with each and every user training them.
Well now that you have folder names that don't match @UserID without seeing or knowing the specific pattern it makes it difficult to suggest a method for logging errors or how to do the rename in the first place. However it sounds like you have everything correct except for not using the @UserID in the first place.
We use hidden shares as well but with the $ appended to the user's login ID and setup from user's profile and not in the script. I do use a script though to set that as well.
The good thing is that once the user folders match @UserID it will make large scale changes much easier to automate in the future. That being said, I would still not recommend setting up USERIDs like this: John.Smith (JSMITH, or Jmiddle-initialSMITH, or JSMITH01 would be better) etc... But that is a personal preference on my part.
Just remember as the size of the organization scales up, each nuance might cause additional Administrative effort on your part. Many (not all) of the recommendations by Microsoft that you see or learn in a class are born out of at least some type of real experience. Unless you specifically know why you're deviating from their recommendation then you should probably adhere to it. If you don't have the personal experience yet, but you think that some recommendation is invalid then check or ask in one of the many MVP sites on the Web or even here in the General forum. There are many good experienced Admins that either Moderate or frequent this site.
Err.. Ahemm... Exuse me? I didn't say you needed to map to that single share, only that you don't need to setup thousands of freaking shares! The days of all those hidden shares are gone with the old Wintendos!
Often, in larger organizations, there are several authentication systems that each have their limitations and unless you deploy an expensive single sign on (SSO) system, you will have to come up with a standardized UserID that fits the lowest common denominator. I think many organizations go with First initial followed by X number of chars of the Last name followed by a numeric sequence in case of duplicates.
_________________________
Give a man a fish and he will be back for more. Slap him with a fish and he will go away forever.
Also, for audit trail purposes, some companies will not allow a name change in their UserID so users must stay with the same signon from hire to retire. That can make for some disgruntled workers in the case of bitter divorce, having to keep their ex-spouse's name.
_________________________
Give a man a fish and he will be back for more. Slap him with a fish and he will go away forever.
#140113 - 2005-05-2209:38 PMRe: Personal drive mapping issue
NTDOCNTDOC Administrator
Registered: 2000-07-28
Posts: 11634
Loc: Space
I agree with the SSO and the once you have an ID it can't change (don't agree with the idea in general but I know that legislation and other factors are involved for many Companies). As for the USER folder being gone/dead I disagree. A user directory has nothing to do with that and rather depends a lot more on the type of business you work in. I would guess that many companies have no need whatsoever for a user folder - Medical, maybe MFG, etc... But that does not mean that it has gone away for thousands of other companies or has been replaced by some new magical technology or method. It is a place to store user data when and where applicable to the Company needs.
Don't forget that there are many Countries that don't adhere to any of these recent draconian regulations either.
Registered: 2000-01-24
Posts: 4946
Loc: Leatherhead, Surrey, UK
Benjamin,
I'll just elaborate on Les' suggestion, and give a couple of reasons why it is a better way of doing things.
In the bad old days of Win9x, the only way to get access to a shared resource was to map a drive letter to it. This meant that if you had 500 users and you wanted each of them to have a drive letter which mapped to their home drive you had to have 500 network shares.
Now, that's an awful lot of overhead both in management by support staff and for the file server to manage.
If you don't need to support Win9x however, there is a better option. NT, XP Windows 2000 / 3000 all support deep mapping. (Not sure about ME - anyone?)
Deep mapping allows you to map a drive to a folder within a share. This is how you do it.
On your file server, create a directory "users", and share it as "users$". Set folder and share permissions such that all you users can access it but not add/change/delete anything in in.
Within this folder create the invividual home directory (jsmith), and change the folder permissions such that only the user (and administrators) can use it. Do not share this directory.
Now, you can map John Smith's H: drive: Code:
Use H: \\fileserver\users$\jsmith
You only have one share to worry about.
Mapping this way gives an added benefit. In my organisation we also map a drive letter to the top level \\fileserver\users$ share for all our users. This is because where staff are on (say) maternity leave it is easy to give permissions to the folder to allow their managers access to their data without mucking about with the structure.
If you do have to support some Win9x clients then of course you can still share out the users directories in those specific cases.
The only drawback to this is that where the login id matches the share name you are effectively divulging the login IDs of all your users which might be a security concern in some companies, but to be honest the mail global address list provides this level of information anyway. It is also not much less secure than using "hidden" shares, which of course aren't hidden at all.
Registered: 2002-09-04
Posts: 75
Loc: McMinnville, OR, USA
I use the following syntax to map my users home folders: Code:
use H: /d; use H: @HOMESHR + \ + @USERID; connect to user's home share
Windows NT and up allow for mapping of nested folders within shared directories. i.e. \\server\deptshare$\username where DEPTSHARE$ is the share and USERNAME is a sub folder (which is not shared)
