|
Babysteps...
The likelihood of a full grown perfect provisioning system
dropping into your lap is almost as unlikely as a duplicate GUID being created.
So start small, this is what I have always done when growing up systems. Usually
I would ask for permission to spend time on building a system, be told not only
no but hell no and I better not catching you working on that so I spend an hour
here and there after work building it in a skunkworks fashion. I did that at one
Financial company for managing the NT4 resource domain and rolled out a real
rough looking tool to the support people, didn't tell any of the management who
told me not to do it. The support people loved it, my team of 3 people loved it.
Everyone was far more productive because everything was verified and logged and
didn't require contacting a DA to get the work done. Eventually the management
was like, hey how did you guys get so productive so I showed my boss the site
and he told me to make it look pretty and then a month or two later he announced
to everyone that the group had thought up, designed, and built a brand new
way of managing the environment. Most of the folks were like yeah, the group of
joe is the one, the rest of you didn't have anything to do with it except trying
to stop him. ;o)
Anyway, that whole thing grew up out of scripts. I started
scripting each individual task that we as DAs had to do. At first the scripts
did the work and logged it all so we didn't need to use the GUI, as that freed
up time then the scripts were modified to do data validation and then make
changes. Then I added reporting to it so say you requested a quota increase for
someone, it validated the quota values, changed the quota, then updated the
reporting database to reflect the new quota. Ditto for software delivery stuff.
Then I threw up a web site on a NT4 workstation and set up a basic auth system
that used windows auth and backended into an Access database to retrieve authz
info. Slowly I added the scripts to the web site and let the support analysts
use them.
It wasn't the greatest but it was such a stellar leap over
what had come before and really helped stabilize our data collection and
tracking capability not to mention making folks more efficient because they
could say get a queue restarted or purged without having to chase down one of
three domain admins who really didn't give a crap if a print queue was working
or not.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Clay, Justin (ITS) Sent: Tuesday, June 13, 2006 9:11 AM To: [email protected] Subject: RE: [ActiveDir] OT: RUS Al,
I think that’s great advice. I wish we really had a provisioning system, like MIIS or something similar. We have 22,000 users and they’re all maintained by hand, which is horrible.
We have considered using a custom attribute to tag employees as well. We’re definitely going to be using employeeType in the near future to at least identify service accounts and contractors/vendors. I think we might end up tagging other custom attributes as well. We currently tag a custom attribute with the user’s Exchange quota limit so that our Exchange guys can use that attribute to set mailbox limits.
Since we’re on the topic of UPNs, how are additional UPNs created and managed? There are about 15 additional UPNs in our UPN dropdown list that were created long before I was here, and honestly we don’t need them. I believe at some point the previous admin was going to have a separate UPN for each department, such as police.domain.com, fire.domain.com, sheriff.domain.com. I’m not sure what the thinking behind that was (although I’m sure there was a reason) but we have no use for them at this point. How can I remove them or modify them?
From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Al
Mulnick
I think it's a really good idea to clean up the UPN's. However, I think it worth noting that you may want to have a look at the process that provisions the users and creates those upn's. Just to make sure you don't end up doing the work over and over again.
I realize upn alone will work, but I think it would be a good idea to consider tagging the user objects' custom attributes with some identifying information as well. It may be that in the future you'll want to sort on different attributes and you may or may not be in a situation where upn is flexible enough.
Al On 6/13/06, Clay, Justin (ITS) <[EMAIL PROTECTED]> wrote: We have 1 AD forest with 5 total domains. They are "sister" domains and they don't share a namespace. For instance we have one domain for our Police Department, one for the Sheriff Department, one for the Public Schools, etc.
As for Steven's suggestion for UPN, we were hoping to use that, but it looks like we'll have to do a lot of cleanup before we can. There's a lot of incorrect UPNs in our directory.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Al Mulnick Subject: Re: [ActiveDir] OT: RUS
There're probably too many definitions of the word "domain" to really give good advice. Can you expand that question?
On 6/12/06, Clay, Justin (ITS) < [EMAIL PROTECTED]> wrote: Would there be an easy way to write a RUS policy that stamped the email addresses based on what domain each user was in? This seems like it would be easy, but I don't see any attribute that I can get the domain from with an LDAP query.
Please tell me I'm missing something obvious!
Justin
Clay
|
