LDN - Luminis Developer Network

If you already have duplicates between Banner and Active Directory, you will have to decide who gets to 'keep' their login name if you want to maintain this data in Banner (and I agree that staff will put up a bigger fuss on this than students, so it will probably be the student account that changes).

Ideally, you will want to have Banner generate the login name/Third Party ID value before the A.D. accounts are created, and then use this to create the A.D. login credentials. As mentioned earlier, Banner has validation checks in place that will ensure that no duplicate names are assigned.

Keep in mind that this validation check includes changes to a person's Third Party ID - so if Mary Smith (msmith) for some reason gets a new login name (msmith2), no-one else can use msmith as this is captured into the audit table tied to the GOBTPAC table. So unless you clean out the entries in the audit table (which SGHE recommends you not do for audit purposes), you'll have to assign Mary Smith yet a different name that is not taken. You could run cross-sql's against both tables to delete out the specific records, but this then affects your auditing trail for this activity.

Oh, and you're not restricted to 8 characters for the login name length - the GUAPPRF form in Banner General 7.4 now allows you to set how long this generated value will be (up to 32 characters max I think). If you're on an earlier version, you'll have to modify the pl/sql function that generates this value. I know that some schools have even go so far as to modify the generated login name format specified in the function to match what they currently have in place (ie - first name.lastname).

   Alice Kim

The duplicates you are just going to have to cope with, probably by changing the ID's for some of your students. I would make the following additional comments.

1. We went to 32 character usernames as previously described in this thread.
2. You state "These accounts are created in AD before anything is keyed into Banner. " Well, we used to do the same thing. We don't any more. The only way to allow Banner to manage the namespace for AD accounts is to allow Banner to manage the namespace for AD accounts. That's one of the humongous cultural shocks of integrating Banner, Luminis, and AD. It is now the case for us that AD accounts cannot be created until the person is in GOATPAD in Banner. So our HR office *has* to put people into Banner before an AD account can be created. They don't have to put everything about the person into Banner, but they have to enter enough to get the Third Party ID generated in GOATPAD. The HR office previously only worried about getting new hires into the system before the first payroll run after they were hired.
3. The exception to #2 for us is newly hired adjunct faculty (part-time faculty). They are often hired and are teaching before HR even knows about them. So we adopted a procedure whereby one Dean and his secretary can put enough information about a person into Banner to get them the Faculty role without the Employee role, and to get them their GOATPAD entry. HR still has to "hire" the part-time faculty before they are paid, etc., but we *have* to have the GOATPAD entry for newly hired part-time faculty more quickly than the HR office can respond.
4. Obviously, items #2 and #3 beg a serious Business Process Analysis. The paperwork flow that we use to hire people is pretty crazy, but it's the way it is for historically practical reasons. I'm hoping that in time we can leverage the Banner project to rationalize the paperwork flow we use to hire people and to make it an electronic workflow.
5. Entry of new students into Banner and AD is much more automated, except that it is the case even with students that they *have* to have their AD account before they can do anything on our campus. Our Admissions office has historically been informally "holding" student applications by not entering all their data, thereby in Banner preventing their GOATPAD entries from being created. Now with Banner, Admissions has to fully enter the student, then use the Banner mechanism to put the student on hold. Again, this was a major cultural shock which begs a serious Business Process Analysis.
6. Finally, previous to Banner/Luminis, we had a different username format for students than we had for faculty/staff. We didn't necessarily "have to have to" change this procedure. We could have changed the script that Banner uses to generate the userid (indeed, we already changed it to go from 8 to 32 characters). But with people very fluidly changing roles from student to employee, from employee to student, and with people having all kinds of multiple roles, it made sense to me at least to have one big, common namespace with the same userid format for everybody. That way, when a person's role(s) changed, their userid didn't have to change. And a lot of security and permissions in Luminis and Banner are role based, so this approach works very well. I'm the VP, so I could make this decision. I think it's fair to say that the SysAdmins who take care of our AD, our Exchange server, our Luminis server, etc. did not agree with this approach. It created some very challenging practical and technical problems for them in the short run. But I'm persuaded that it was the right decision for the long run.