Join or sign in Register for your free TechRepublic membership or if you are already a member, sign in using your preferred method below. Use Your Email Use FacebookUse Linkedin

Login scripts and AD Design

Locked

I’m looking for the best way to map my printers and netowrk drives on our new ActiveDirectory.
We have a pretty straightfoward architecture.

4 Companies under the same Domain.
13 Sites under each company
0 to 10 Divisions under each site
0 to 5 Departments under each division
X users under each department

What I intended to do is create security groups like this

Company_Site_Divison_Sales_Rep (8 persons in this group)
Company_Site_Divison_Sales_Secretary (1 person in this group)
Company_Site_Divison_Sales_Managemet (1 person in this group)

Then include those 3 groups in Company_Site_Division_Sales

Then include this group in Company_Site_Divison. Etc, etc.

My OU structure now stops at the Site level (i.e.: Company1 – Site1, Company1 – Site2, etc.)

1. Is this a good way to manage security?
2. How should I go around to map my printers and network drives?

I’ve read about GPO filtering but it looks like a lot of maintenance. I was thinking about writting one script and applying it to the domain with a GPO and in the script test to determine group membership until I trickle down to the lowest group. Is this going to slow down my logon process a lot?
Or should I just drill down the GPO to the Rep, Secretary and Management level and apply the script directly on the OU? I’m a bit lost here.

Thanks for any input.

Topic

Reply To: Login scripts and AD Design

In reply to Login scripts and AD Design

As far as the login scripts, try signing up for the Microsoft Windows Scripting site (http://groups.msn.com/WindowsScript) and looking up their login script section. They have a VB script that uses an HTML page as sort of a GUI Login Results window during the login process. Also, since it is VB script, you can map drives, printers, etc to the user/group/site level (however you want,… I use it on a very small network and map drives, printers based upon user levels).

As far as the design, if I remember correctly it is not a good idea to set your OU’s as a site, but rather have the OUs as departments (i.e. Sales OU in Company1_Site1_Division1, etc). I’d follow up on the changes in recommendations based upon Windows 2003 domain architecture (there are a few due to original recommendations that were flawed in Windows 2000 design recommendations). I took a design course some time ago, but haven’t used the skills for a long time now, so you know what they say,… use it or lose it.

Hope some of this helps.

Reply To: Login scripts and AD Design

In reply to Reply To: Login scripts and AD Design

I’m still confused 🙁 Ill go take a look at Windows Scripting site, but what worries me right now is how I should handle the script issue. 1 script with test on security group, or multiple script binded to OU? I have more a design problem then a syntax problem.

Any more thoughts on my design issues?

Reply To: Login scripts and AD Design

In reply to Login scripts and AD Design

Well, ya know, there just isn’t enough info to make a suggestion.

If this was for AT&T’s sales force who is constantly on the road, scripts would do well.

If this was for AT&T secretaries at the Hoboken MN office, 3rd floor and their printer down the hall in the mail room, I wouldn’t use a script.

Reply To: Login scripts and AD Design

In reply to Reply To: Login scripts and AD Design

same with mapped drives. If the sales force who is constantly flying around the country, scripts would work well.

If it’s the secretary or database grunt sitting in front of a screen all day, I wouldn’t use a script.

There are many different ways to design an Active Directory network. There are many variations to OU structure that mimics functional department setups. What is always true in designing networks is: make it simple, make it flexible, design with growth in mind.

Reply To: Login scripts and AD Design

In reply to Reply To: Login scripts and AD Design

Let’s say I sacrifice my roaming user for now. What would you do for the secretary or the DB grunt? I was under the impression that OU were there only to apply policies and deleguate control.

I dont have any policies or controls to deleguate at the department level, but I do have map drives and to connect printers at the department level.

Could I just ignore OU and use security groups instead?

Reply To: Login scripts and AD Design

In reply to Login scripts and AD Design

Use the A-G-DL-P or with multiple domains in which users need access and your running Windows in Native move A-G-U-DL-P

Ou’s are containers to collect objects like users and computers in which to apply a Group Policy. Group Policies are to manage the user environment.

For printers, I would just share the printer. Remove the everyone group. Then create a security group and add those users who need access to that printer to that group. If that printer is down the hall in the copy room and it’s the only one around, make it their default printer.

Roaming users, well…..make printers available in AD. Allow the user to search AD for a printer they can use where ever they are.

Mapped drives are a little more tricky in that typically those are to shares somewhere and its best to run DFS if your going to do mapped drives. That way no matter where they are you can connect. [different domains]. Users need to log on to the domain it’s located].

Reply To: Login scripts and AD Design

In reply to Reply To: Login scripts and AD Design

left a step out. You add the security group as those who can have access to the shared printer but I think you get the drift.

DFS solves a lot of sins in mapped drives in a AD environment. Even across multiple domains.

[Author]

Replies