IMPORTANT: Change to UserNameStore that affects Active Directory

I have been making some major database revamps to the UserNameStore database, to make it – hopefully – more efficient, and manageable, by you guys. Once I get the tools in place to manage it.

As part of that, as well, as being able to track users in AD, I have associated AD account existence with a flag in the database. that field is called “inAD” In most cases, no one will see this, unless they are looking at the database itself.

In laymon’s terms, what that means, is that I am attempting to track every single user (for now, in the STUDENT and STUDENT2 domain) within the database. for instance if User A gets added to the database, but doesn’t have an AD account created yet, the flag on the “inAD” field would be set to 0 (or FALSE), once that user gets added to AD, that flags gets set to 1 (or TRUE)

The reason I am doing this, is to try to make the scripts I write more efficient, and be able to get more information about a user without having to reach out to Aeries, or to AD constantly. If I can manage to understand the Aeries add/remove process of students, and keep Aeries and my database accurate at all times, then this system will make things easier over all, and especially on the long run when more complex things come up.

What does this mean to you –> the person who is potentially managing users in AD.

What this means, is that changes that can be made to an AD account manually are now very very limited, because every change made in AD is tied to some tracking field in the database. This will be inconvenient for those of you who are used to willy nilly remove and add users in AD, once the tools are in place, this should not be a problem, as everything will get updated via the tools. Hopefully once I get to my goal, we won’t even need the tools, as everything will be 100% automated.

What should i NEVER change?

• The user First Name, Last Name, Description Field
• The user account status (if it’s disabled, do not enable it straight from Active Directory).
• Do not change the value of the field in the Telephone – Notes, in Active Directory
• Do not change the username
• Do not change any group memberships
• Do not change logon scripts

Are there any exceptions?

Yes, in short. Any account that does NOT have a PermID is excepted from the above, as it is not tracked in the database.

Though I prefer to keep the number of generic accounts to a minimum, these can be created without worrying about the status of the database.

Please bare with me as I go through this process, as it’s quite complex and convoluted, and undoubtedly, I’m going to run into snags, but we’ll get the resolved as we go.

What to notify Georges about?

• If you find that there are issues with users that you know are supposed be in AD after a user import, please let me know.
• If I told you that I ran a process to update students, and you still regularly run into accounts that are not updated or don’t have all their components (i.e: Security Group Memberships, correct OU, correct home folder), please let me know.
• If any results of any tools you use regularly are off, or seem to have old data (i.e: 2008-2009), please let me know. I have made an effort to change all those scripts, and I have changed the system so that not as many changes will be required to switch Aeries databases in the future.

Anything else left over, that you still have questions about, please let me know. It’s a lot to take in, and I’m planning to work with mike to have a staff meeting at some point to explain the system in more detail, and answer any questions that you may have, as this is quickly becoming the core of a lot of things we do.