And another error for today....when doing an Export on a FIM MA - to get data to Active Directory (another very basic scenario): "There is an error executing a web service object creation request. Type: Microsoft.ResourceManagement.WebServices.Client.PermissionDeniedException Message: Fault Reason: Policy prohibits the request from completing. Fault Details: <RequestFailures xmlns="http://schemas.microsoft.com/2006/11/ResourceManagement" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"></RequestFailures> Stack Trace: at Microsoft.ResourceManagement.WebServices.ResourceFactoryClient.Create(Message request) at Microsoft.ResourceManagement.WebServices.ResourceFactoryClient.Create(Create createBody) at Microsoft.ResourceManagement.WebServices.Client.ResourceTemplate.CreateResource() Inner Exception: Policy prohibits the request from completing." And I have already download the powershell script from http://social.technet.microsoft.com/Forums/en-US/ilm2/thread/559143af-3171-46db-90c7-4bbd92889cf2 And guess what the answer was to the script: "Your current MPR configuration meets all the requirements". Anyone have any more ideas please? oh and I am running an up to date operating system and FIM 2010 Update 1.

Hey S.Kwan! Have you tried doing a "Explore" on the MPR page, to see which MPR the request hits ? Also. Have you done any changes to the FIM Portal schema ?

What is the object type you're trying to export? I suggest doing a search under MPRs for that object type and check all MPRs that relate to the Built-In Sync account. If it's a new object type (other than user or group) you'll have to create an MPR for it.http://www.wapshere.com/missmiis

What is the object type you're trying to export? I suggest doing a search under MPRs for that object type and check all MPRs that relate to the Built-In Sync account. If it's a new object type (other than user or group) you'll have to create an MPR for it. http://www.wapshere.com/missmiis I am doing the 'person' object - and am following the FIM 2010 MOC labs (from course 50382). Its a simple 'get a user from FIM Portal to MV to AD scenario. The Administrator and Built-in Sync account have been filtered as per lab.

Hey S.Kwan! Have you tried doing a "Explore" on the MPR page, to see which MPR the request hits ? Also. Have you done any changes to the FIM Portal schema ? How do I see which MPR the request hits? And no, the FIM schema is out-of-the-box standard

1. Go to Management Policy Rules. 2. Go to "Explore" at det top. 3. Chose "A requestor or a target resource". 4. Use "Built-In Synchronization Account" as Requestor, and choose a user that you are trying to update in the "Target Resource" field. 5. Check "Create resource", "Modify a signel-valued attribute". 6. Check "Only permission granting Management Policy Rules". 7. Hit next and show the results..

remikset, so my first question is: what did I just do? what is this used for? secondly, here are the results of the above process: sync account can delete and update expected rule entry resources sync account controls detected rule entry resources sync account controls sync configuration resources sync account controls users it synchronizes All are set as follows: grant right - yes disabled - no authentication workflows - no authorization workflows - no action workflows - no does this give you any clues? which Policies must be set in order to get data from FIM Portal to AD? thanks

Have you enabled the MPR that grants the Sync Service full control of users and edited that MPR so that it's set to "All Attributes" on the second or third tab?My Book - Active Directory, 4th Edition My Blog - www.briandesmond.com

Hi, Just went through all the MPR dealing with "Synchronization: Synchronization account...." and made sure they are all enabled, and that 'all attributes' are selected - and the "Failed Modification via Web Services" error is now gone. However I still do not know which specific MPR fixed the issue. so thank you for that...however where can I find actual guidance from Microsoft as to what the settings meant to be per MPR to get it all working? we are basically looking for guidance on how to get FIM working...so the document we have been using is from technet (http://technet.microsoft.com/en-us/library/ff686263%28WS.10%29.aspx)...but we cannot find anywhere in that document a reference to modifying existing MPRs just as what you recommended. Can this 'how-to' document be perhaps updated please?

Hey, The how-to is correct for the given scenario in my opinion. IF you create a custom attribute in the Portal, and want to export from the MV to the attribute in the Portal, THEN you'll have to update the "sync account controls users it synchronizes" MPR. Perhaps some of the exotic attributes which are linked to users in the Portal Schema are not in there by default. It might be a good idea like Brian suggests to just say "all attributes" for this specific MPR. But I think out of the box you can export data to the FIM Portal withouth adjusting this MPR. Besides, you are trying to provision Users from FIM to AD. What data/attributes are you trying to export towards the FIM Portal? This will give us an insight as to why it is (was) failing. Regards, Thomashttp://setspn.blogspot.com

sure, here you go: samaccountname userprincipalname displayname employeeID department givenname title mobile facsimiletelephonenumber telephonenumber sn objectSid cn pwdlastset useraccountcontrol unicodePWD dn

You're trying to export unicodePWD from the metaverse to the FIM Portal? I don't understand why you would do that, and would definitely recommend you try dropping that one. Another that jumps out is pwdlastset - I don't think that's in the default MPR. Unless you've modified the "Synchronization: Synchronization account controls users it synchronizes" MPR to allow "All Attributes" you're going to have to individually specify the ones you want to export.http://www.wapshere.com/missmiis

Hi, these are the attributes I have configured in the AD Sync rule (Outbound attributes). unicodePWD is set to "P@$$w0rd" (initial flow only) pwdlastset is set to '0' (initial flow only) This is in order to ensure that all new user accounts in AD have a password set to "P@$$w0rd" and the password must be changed at first logon. And after I changed the MPRs (as mentioned above) the system works now, and I have tested the new AD accounts and the password settings also work...there's light at the end of the tunnel ;-) just seems to be a very long learning curve...thanks for your patience everyone.