rvthost
asked on
HQ users going back and forth to jobsite - alias objects and drive mappings
Netware 6.5. SP5 environment, OUs broken down by geographical location. We have a large jobsite that is joining the WAN and will have a local Netware server, in a separate OU. The users that are going to the jobsite will bounce back and forth between the jobsite and other locations (OUs). Instead of creating multiple user objects for a user, it seems an alias object in the jobsite OU may be the way to go to simplify the password issue. When using the alias object, what is the best way to control login scripts so that the headquarter scripts don't run, but rather the scripts written on the jobsite OU? Perhaps a combination of detecting which subnet the user is logging in on? While at the jobsite, the user should map the local server. When back at HQ, map their traditional server. The user will manually change their context as needed, no problem there. What's the best way to accomplish this? Thanks!
ASKER
For the most part, the users at the jobsite would not need to access resources back at the home site. Actual user home directories are not much of an issue; the data in question is all in a shared location since it contains job related info. So I guess the objective is to minimize anything that would force the user to cross the WAN link.
Most of the login scripts are done at the container level, mapping to a specific server "shared" folder. We do have Zenworks, no roaming profiles. Majority of these jobsite users will be laptop users. I'm certainly open to any best practice suggestions.
Most of the login scripts are done at the container level, mapping to a specific server "shared" folder. We do have Zenworks, no roaming profiles. Majority of these jobsite users will be laptop users. I'm certainly open to any best practice suggestions.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Great idea on the DHCP with the Context option, didn't know we could do that :) Yes, the Netware box will be providing DHCP for its local subnet.
Zen is no problem, already accounted for that. And our user licenses are good to go. Thanks for the advice!
Zen is no problem, already accounted for that. And our user licenses are good to go. Thanks for the advice!
There are many ways to do this, and some of it depends on how your tree is structured, how your resources get allocated and how these users connect to the different sites - mobile (carry a laptop) or roaming (log in wherever on a local PC already on-site.) Another factor to consider is whether or not you use ZENworks.
Aliases might help but not the way you think. An alias object is simply a pointer to the "real" object in another container. If the "real" object has a login script defined to it, that login script will run. If you don't use a profile login script, the alias object's container login script should run.
Would you want to have separate home directories that these roaming users would have to keep track of themselves? Are there any resources at the home site they'd need access to while at the jobsite? All that needs to be considered.
How are your login scripts done?