Classical and declarative Provisioning
so do you at any time perform any LDAP lookups to see if the name already exists in AD? How do you deal with the potential of a duplicate username?
February 16th, 2011 7:24pm

Search the forum/internet for "findMVutils" or "unique account generation". It has been explained several times before here on the forums. In short: you can query the MV with "findMVutils" (or something like that). IMO that's the preferred way. I don't like calling external sources from within rules extensions. Regards, Thomashttp://setspn.blogspot.com
Free Windows Admin Tool Kit Click here and download it now
February 16th, 2011 7:26pm

The issue we have is that there are some AD accounts that will never land up in the MV...which leads me to believe we have to do an LDAP lookup on the samAccountName before the username is generated...so we cannot query the MV, but AD instead....hence external code might be necessary?
February 16th, 2011 7:33pm

Hi, So when provisioning new users in AD, we need to include some logic for username conflict resolution (pity its not in FIM already, since I assume everyone needs this feature). So for that we need to write classical provisioning code, right? This code would then set the samaccountname and initial DN. Can we then use the new declarative method to populate the remaining user attributes? If both can coexist, are there any gotcha's we need to be aware of? thanks
Free Windows Admin Tool Kit Click here and download it now
February 16th, 2011 7:48pm

What I do: Our accountNames are based on first + last + number. First and Last are contributed by our HR MA. For this MA we have a rulesextension which generates a unique accountname in the accountname attribute in the MV. Using FIM Declarative provisioning, we then provision users in AD based on this accountname field. This way you don't have to write any provisioning code yourself. The FIM Service uses the generated accountName and does its magic. You can perfecly mix classical and declarative rules. I myself always pick declarative unless it's a rules extension. As an alternative you could use a custom workflow for this too...http://setspn.blogspot.com
February 16th, 2011 8:30pm

if you miss some accounts in MV you won't be able to keep them as members of the groups managed by FIM
Free Windows Admin Tool Kit Click here and download it now
February 16th, 2011 8:31pm

if you miss some accounts in MV you won't be able to keep them as members of the groups managed by FIM
February 16th, 2011 10:20pm

evgeniy, your group comment is valid, but its not a problem in our scenario. I basically need to know if declarative rules and classic code can co-exist...can I for instance use classic code to determine the uniqueness of a username and set that, and then use the new methods to flow thru the rest of the attributes? secondly, if there are some users that only exist in AD and not necessarily MV - I guess we have to use an external script to verify username uniqueness - and there is no new tweak in FIM to perform this function? thanks
Free Windows Admin Tool Kit Click here and download it now
February 17th, 2011 12:36am

evgeniy, your group comment is valid, but its not a problem in our scenario. I basically need to know if declarative rules and classic code can co-exist...can I for instance use classic code to determine the uniqueness of a username and set that, and then use the new methods to flow thru the rest of the attributes? secondly, if there are some users that only exist in AD and not necessarily MV - I guess we have to use an external script to verify username uniqueness - and there is no new tweak in FIM to perform this function? thanks ps. cant seem to find anything on 'findMVutils'. Also searching for 'unique account generation' does not find any satisfying posts...we have however come across Tools4FIM though.
February 17th, 2011 12:49am

Sorry, my findMVutils was close but not that close... it's FindMVEntries Check: http://social.technet.microsoft.com/Forums/en-NZ/ilm2/thread/64bd95b2-287a-42da-be91-427c3dc55020 http://social.technet.microsoft.com/Forums/en-US/ilm2/thread/9e80a271-7ae7-4206-aec0-ce6a08600912 http://social.technet.microsoft.com/Forums/en-CA/ilm2/thread/db020ec8-683d-4949-8e84-b4e5b724ff5b However the FindMVEntries method assumes all accountNames are present in the MV, which you said in your environment is not the case. It's not advised to query external datasources from rules extensions which are triggered when the Sync Profiles run, however you could build a custom workflow in FIM which does this functionality. And to answer your question: "I basically need to know if declarative rules and classic code can co-exist" => Yes they can.http://setspn.blogspot.com
Free Windows Admin Tool Kit Click here and download it now
February 17th, 2011 7:16pm

Do not use classic provisioning code to accomplish this, write a WF activity to query AD and the FIM Service instead. The distinct benefit here is that the process is async and will not stall the sync engine while provisioning. You wire up your WF to a policy that is triggered whenever your user is ready to be provisioned to AD. I've done this on Create or using a Transition-In policy and can do it in the same workflow that you use when you add the Sync Rule to the user. The only issue we've had with this approach is when the queries to AD have timed out (90 secs) but we suspect an infrastructure problem here as nothing should take that long to resolve against AD. A solution here would be to trap timeouts in the WF and use the Delay activity to persist the WF for a period of time and then retry. Again, because the process is async, you can wait for hours before retrying and not compromise your sync performance.Brad Turner, ILM MVP - Ensynch, Inc - www.identitychaos.com [If a post helps to resolve your issue, please click the "Mark as Answer" or "Helpful" button at the top of that post. By marking a post as Answered or Helpful, you help others find the answer faster.]
February 21st, 2011 4:21am

Ok, so if this is written into the workflow - then we should be able to use the new declarative provisioning methods to populate AD. Would this be an 'action' workflow? where do we actually append / insert the code? would it be raw workflow code or vb.net / C# code? thanks
Free Windows Admin Tool Kit Click here and download it now
February 21st, 2011 4:56am

Ok, so if thi is written into the workflow - then we should be able to use the new declarative provisioning methods to populate AD. So what would this workflow actually call - some form of a script I presume?
February 21st, 2011 4:59am

Ok, so if this is written into the workflow - then we should be able to use the new declarative provisioning methods to populate AD. Would this be an 'action' workflow? where do we actually append / insert the code? would it be raw workflow code or vb.net / C# code? thanks It'd be an action workflow. You would need to build this using Visual Studio using WWF and either VB.Net or C#. I have on my todo list a blog post on how to write a username generating activity but I've just been slammed so I've got no idea when I'm going to get it done.My Book - Active Directory, 4th Edition My Blog - www.briandesmond.com
Free Windows Admin Tool Kit Click here and download it now
February 21st, 2011 3:10pm

Correct, the Action WF would implement the same code that you would have inserted into the provisioning logic but would be writing back to the //Target/AccountName property of the user. WF gives you greater flexibility with long running and external processes. You can find some help in the SDK here: http://msdn.microsoft.com/en-us/library/ee652258.aspx I know Microsoft is working on more examples of how to use the building block activities and there are some excellent posts by others sharing their expertise on writing FIM WF: http://www.wapshere.com/missmiis/ http://www.idmcrisis.com/ http://c--shark.blogspot.com/ Oxford has published some of their WF for general consumption, one of which will help you generate an accountname, but it's not clear whether or not it's searching the FIM Service, AD or both. http://toolsforfim.com/ Ensynch will be sponsoring a hand-on workshop at TEC this year where will spend half a day building a custom WF in FIM. No boring lecture, real hands on. :) Brad Turner, ILM MVP - Ensynch, Inc - www.identitychaos.com [If a post helps to resolve your issue, please click the "Mark as Answer" or "Helpful" button at the top of that post. By marking a post as Answered or Helpful, you help others find the answer faster.]
February 21st, 2011 3:43pm

Correct, the Action WF would implement the same code that you would have inserted into the provisioning logic but would be writing back to the //Target/AccountName property of the user. WF gives you greater flexibility with long running and external processes. You can find some help in the SDK here: http://msdn.microsoft.com/en-us/library/ee652258.aspx I know Microsoft is working on more examples of how to use the building block activities and there are some excellent posts by others sharing their expertise on writing FIM WF: http://www.wapshere.com/missmiis/ http://www.idmcrisis.com/ http://c--shark.blogspot.com/ Oxford has published some of their WF for general consumption, one of which will help you generate an accountname, but it's not clear whether or not it's searching the FIM Service, AD or both. http://toolsforfim.com/ Ensynch will be sponsoring a hand-on workshop at TEC this year where will spend half a day building a custom WF in FIM. No boring lecture, real hands on. :) Brad Turner, ILM MVP - Ensynch, Inc - www.identitychaos.com [If a post helps to resolve your issue, please click the "Mark as Answer" or "Helpful" button at the top of that post. By marking a post as Answered or Helpful, you help others find the answer faster.]
Free Windows Admin Tool Kit Click here and download it now
February 21st, 2011 3:43pm

so one last question on this topic: I see that it is not really recommended that we do an LDAP lookup to AD from FIM to determine whether the username is unique (since some TEMP users will only exist in AD). Therefore, should we rather first import these TEMP users into the MV, and then do a username lookup in the MV, before creating the new user? thanks
February 22nd, 2011 9:31am

I would not confuse the issue by attempting to store these unmanaged users in the MV simply to facilitate searches but the approach will work. I personally believe it's ok, leveraging WF, to execute your search against AD and the FIM Service independently in order to look for conflicts. You are looking in AD to find unmanaged conflicts and in the FIM Service to find conflicts that have yet to be exported to AD. The union of those two results should give you your answer.Brad Turner, ILM MVP - Ensynch, Inc - www.identitychaos.com [If a post helps to resolve your issue, please click the "Mark as Answer" or "Helpful" button at the top of that post. By marking a post as Answered or Helpful, you help others find the answer faster.]
Free Windows Admin Tool Kit Click here and download it now
March 7th, 2011 8:14am

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics