thinking about it, the solution seems to be to start again. turn provisioning off, import/sync from AD but projection only (empty metaverse). import/sync from SQL with projection/join.
That will let AD fill the metaverse with "futures", students who existed last year but haven't reached a stage this year that lets them appear in SQL. SQL will then project new ones and join to existing ones.
it fills the metaverse with potential junk that may never disappear but there is no other way for mim to adopt "futures" as they will almost certainly have different DNs when they appear in SQL. The join on SQL sync will let an account be joined to its "future".
after that initial load, turn provisioning back on and do not allow AD to project. All object management will then come from SQL either via projections or joins to "futures". Any manual updates to "futures" in AD is not mim's problem, it will overwrite them once it joins. The authoratative source is SQL.
so initially, AD will put lots of empty glasses on the table. SQL will add lots of full glasses and fill lots of empty glasses too (filling the futures). Over time, the SQL syncs will fill more and more glasses but AD will never put more glasses on the table.
but that won't prevent manual creations in AD destroying exports for those accounts as as the sql sync will duplicate them as the DNs will be different.
it's like having a therapist!
cheers,
Alistair
________________________________________
From: Discussion for MS IDM tools liks ILM and FIM <[log in to unmask]> on behalf of Alistair Young <[log in to unmask]>
Sent: 27 August 2020 09:39
To: [log in to unmask]
Subject: Re: Delta sync before export
Warning. This email did not originate from the University.
You should only open any links or attachments if you are certain this email is genuine and the content is safe.
Warning. This email contains web links and originates from outside of the University.
You should only click on these links if you are certain that the email is genuine and the content is safe.
I'm using the recommended pattern of only projecting/joining from SQL and only ever joining from AD.
AD contains student accounts from last year. SQL only contains accounts from this year. When the initial load of mim is done, the account hadn't reached a state that made it appear in SQL so its AD account stayed in the AD CS without being joined as it didn't exist in the metaverse.
The account then reaches a state in the SRS that means it appears in SQL, goes into the metaverse but in a state that means it has a different DN from the one in AD. I suppose a join before export won't fix it anyway as the sync from SQL will cause it to be duplicated in AD CS as the DN is different.
Is it best to load the metaverse from AD first and let SQL join, then let SQL take over? But that won't fix the problem if someone manually creates an account in the wrong place in AD before it gets into the SQL MA.
cheers,
Alistair
________________________________________
From: Discussion for MS IDM tools liks ILM and FIM <[log in to unmask]> on behalf of Andy Swiffin (Staff) <[log in to unmask]>
Sent: 27 August 2020 09:30
To: [log in to unmask]
Subject: Re: Delta sync before export
Warning. This email contains web links and originates from outside of the University.
You should only click on these links if you are certain that the email is genuine and the content is safe.
OK. I'll bite.
How would something that you have just sync'd to the metaverse from SQL exist in AD prior to you exporting it to provision it?
Andy
-----Original Message-----
From: Discussion for MS IDM tools liks ILM and FIM <[log in to unmask]> On Behalf Of Alistair Young
Sent: 27 August 2020 09:23
To: [log in to unmask]
Subject: Delta sync before export
CAUTION: This email originated from outside the University of Dundee. Do not click links or open attachments unless you recognise the sender's email address and know the content is safe.
I'm like a bus today, nothing for ages then two come along!
Initial load and first manual run of full import/sync to everything and all joins an exports are fine. Then the trouble starts with scheduled runs.
All the docs and examples have the flow:
SQL MA full import
SQL MA delta sync
AD MA export
AD MA delta import
AD MA delta sync
but this causes constraint-violation when an account in SQL MA appears but already exists in AD MA with a different DN. Because there's no delta sync before export, there's no join and the newly appeared account gets duplicated in the AD MA CS and the export fails.
Is it best practice to do:
SQL MA delta sync
AD MA delta sync (to make sure new objects in SQL MA are joined to existing ones in AD MA) AD MA export AD MA delta import AD MA delta sync
thanks,
Alistair
########################################################################
To unsubscribe from the MICROSOFT-IDENTITY list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=MICROSOFT-IDENTITY&A=1
This message was issued to members of www.jiscmail.ac.uk/MICROSOFT-IDENTITY, a mailing list hosted by www.jiscmail.ac.uk, terms & conditions are available at https://www.jiscmail.ac.uk/policyandsecurity/
The University of Dundee is a registered Scottish Charity, No: SC015096
########################################################################
To unsubscribe from the MICROSOFT-IDENTITY list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=MICROSOFT-IDENTITY&A=1
This message was issued to members of www.jiscmail.ac.uk/MICROSOFT-IDENTITY, a mailing list hosted by www.jiscmail.ac.uk, terms & conditions are available at https://www.jiscmail.ac.uk/policyandsecurity/
########################################################################
To unsubscribe from the MICROSOFT-IDENTITY list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=MICROSOFT-IDENTITY&A=1
This message was issued to members of www.jiscmail.ac.uk/MICROSOFT-IDENTITY, a mailing list hosted by www.jiscmail.ac.uk, terms & conditions are available at https://www.jiscmail.ac.uk/policyandsecurity/
########################################################################
To unsubscribe from the MICROSOFT-IDENTITY list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=MICROSOFT-IDENTITY&A=1
This message was issued to members of www.jiscmail.ac.uk/MICROSOFT-IDENTITY, a mailing list hosted by www.jiscmail.ac.uk, terms & conditions are available at https://www.jiscmail.ac.uk/policyandsecurity/
|
