Have set up SSPR as per instructions and importedAD users into portal.Can register and get through auth gate either using portal or add-in.But password reset fails with the error "Password reset activity could not find MV record for user"I'm guessing it needs an attribute brought into FIM DB which I don't have?FIM attributes which are populated are: accountname, displayname, objectsid, domain, MVobjectID, dnADMA direct SAMAccountName -> MV AccountName -> FIM MA direct AccountnameADMA direct SAMAccountName -> MV DisplayName -> FIM MA direct DisplaynameADMA directObjectSid -> MVObjectSid -> FIM MA direct ObjectSidADMA adv constant "DOMAIN" -> MV Domain -> FIM MA direct DomainMV objectid -> FIM MA direct MVObjectidFIM MA sync rule mapping -> dn

hm.. first time to see such error. If you create the user in AD and flow it to FIM, it should have been properly joined already when you install FIMServer, is the hostname for FIMSync correctly entered? check C:\Program Files\Microsoft Forefront Identity Manager\2010\Service\Microsoft.ResourceManagement.Service.exe.config also, right before you see "Password reset activity could not find MV record for user", there should be an INFO trace like "WQL: ......." does that look right? (you might need to turn on verbose tracing to see that)

Theentry immediately before the errorwas:<duration stage=processqueryresults query="/*" [objectid= 'FIM connector spaceID of user'] milliseconds=0>I've turned verbose on in the resourcemanagementservice.exe.config - will post WQL when I get it.resourcemanagementservice.exe.config is:resourcemanagementclient resourcemanagementservice base address="hostname"resourcemanagementservice externalhostnameis ="hostname"microsoft.resourcemanagement.webservices.resourcemanagementservice - add baseaddress=http://localhost:5725microsoft.resourcemanagement.webservices.securitytokenservice - add baseaddress=http://localhost:5726I guess I should mention I have onlytried from the FIM server itself, I will install PW addin onthe DCand see if the error still occurs from there.

<add key="synchronizationServerName" value="FIMSERVER" /> how about this? is this pointing to the correct sync server? doesn't really where you try it it's the PWResetActivity talking to the Sync engine

yep synchronizationservername value is also set to hostname of FIM server.WQL from verbose trace is: WQL:SELECT * FROM MIIS_CSObject WHERE (Domain='domain' AND Account='fdagg001') or (FullyQualifiedDomain='domain' AND Account='fdagg001') or (Domain='domain' AND UserPrincipalName='fdagg001') or (FullyQualifiedDomain='domain' AND UserPrincipalName='fdagg001')Where fdagg001 was selected user and domain is domainTried from DC but the RC1 password add-in doesn't seem to support Windows 2003 server (RC0 worked okay) don't have another box in the domain to test from.I've found some DCOM errors at the same time - network service did not have local activation perms.The GUID comes back to IIS WAMREG Admin service - which has custom security not defaults - only administrators and system.I'm guessing maybe network service or the fim servcie account should have perms to IIS WAMREG Admin?

there are a few things u should try 1. FIMService service account should be a member of FIMSyncPasswordSet group if not, add him, restart Sync and FIMService (in that order) 2. in Introduction to Password Reset doc, there are a few steps around WMI/DCOM, you need those steps if FIMService and FIMSync are on separate machines

Fim service account already was a member of both these groups.Had already done WMI/DCOM steps. Single Machine.Tried opening WBEMTEST, connecting to root\cimv2 and using plugging the WQL query in.This returned an "Invalid Class" error - could this be the problem?If I enumerate classes there is no MIIS_CSObject class.

Sorry, i am not an expert in WMI so can't answer that question. Something we can try to narrow down the error: 1. Did you follow the setup guide below and "deny access to this computer from the network" ? If yes, try to revert them 2. Stop the firewall 3. Try putting FIMSyncService and FIMService service accounts as local admin. Restart FIMSync, restart FIMServer. See if that fixes the issue. And would you mind copy and paste the exact error from FIMService log? As well as the DCOM error? Thanks Configure the service accounts running the FIM 2010 server components in a secure manner There are two service accounts used to run the FIM server components. They are called the FIM Service service account and FIM Synchronization Service service account in this guide. The FIM MA account is not considered a service account and should be a regular user account. To configure the server(s) running the FIM server components in a secure manner, the service accounts should be restricted. The easiest way to do this is by running Local Security Policy from Administrative Tools, navigate to Local Policies\User Rights Assignment and add the service account to the policy. Use the following restrictions on the service accounts: Deny logon as a batch job Deny logon locally Deny access to this computer from the network The service accounts should not be a member of the local administrators group. The FIM Synchronization Service service account should not be a member of the security groups used to control access to FIM Synchronization Service (groups starting with FIMSync, e.g. FIMSyncAdmins).

1. yes I did - will try and revert that and let you know.2. firewall has always been off.3. will try this too, after 1.Will geterror from FIMService log.I fixed the DCOM error by changing the DCOM perms on IIS_WAMREG Admin. Not sure if I still have original error, but will look.Name: Forefront Identity ManagerSource: Microsoft.ResourceManagementDate: 2/11/2009 10:33:38 a.m.Event ID: 3Task Category: NoneLevel: ErrorKeywords: ClassicUser: N/AComputer: RetailFIM.x.y.zDescription:Password Reset Activity could not find Mv record for user.Event Xml:<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> <System> <Provider Name="Microsoft.ResourceManagement" /> <EventID Qualifiers="0">3</EventID> <Level>2</Level> <Task>0</Task> <Keywords>0x80000000000000</Keywords> <TimeCreated SystemTime="2009-11-01T21:33:38.000Z" /> <EventRecordID>249410</EventRecordID> <Channel>Forefront Identity Manager</Channel> <Computer>RetailFIM.retail.x.y.z</Computer> <Security /> </System> <EventData> <Data>Password Reset Activity could not find Mv record for user.</Data> </EventData></Event>

Source: Microsoft-Windows-DistributedCOMDate: 30/10/2009 4:31:03 a.m.Event ID: 10016Task Category: NoneLevel: ErrorKeywords: ClassicUser: NETWORK SERVICEComputer: RetailFIM.x.y.zDescription:The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID {61738644-F196-11D0-9953-00C04FD919C1}to the user NT AUTHORITY\NETWORK SERVICE SID (S-1-5-20) from address LocalHost (Using LRPC). This security permission can be modified using the Component Services administrative tool.Event Xml:<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> <System> <Provider Name="Microsoft-Windows-DistributedCOM" Guid="{1B562E86-B7AA-4131-BADC-B6F3A001407E}" EventSourceName="DCOM" /> <EventID Qualifiers="49152">10016</EventID> <Version>0</Version> <Level>2</Level> <Task>0</Task> <Opcode>0</Opcode> <Keywords>0x80000000000000</Keywords> <TimeCreated SystemTime="2009-10-29T15:31:03.000Z" /> <EventRecordID>11955</EventRecordID> <Correlation /> <Execution ProcessID="0" ThreadID="0" /> <Channel>System</Channel> <Computer>RetailFIM.x.y.z</Computer> <Security UserID="S-1-5-20" /> </System> <EventData> <Data Name="param1">application-specific</Data> <Data Name="param2">Local</Data> <Data Name="param3">Activation</Data> <Data Name="param4">{61738644-F196-11D0-9953-00C04FD919C1}</Data> <Data Name="param5">NT AUTHORITY</Data> <Data Name="param6">NETWORK SERVICE</Data> <Data Name="param7">S-1-5-20</Data> <Data Name="param8">LocalHost (Using LRPC)</Data> </EventData></Event>

Just want you to know we haven't forgotten you. I am still awaiting the result from your side after trying (1) and (3)

Thanks - neither 1 nor 3 worked...Currently trying another fresh install, but still have the old one if you have any other ideas....

hm.. after doing (1) reverting local seciruty policy, did you perform a "gpupdate /force" ??

Nope, but did reboot. Will try gpupdate /force also.

Fim service account already was a member of both these groups. Had already done WMI/DCOM steps. Single Machine. Tried opening WBEMTEST, connecting to root\cimv2 and using plugging the WQL query in. This returned an "Invalid Class" error - could this be the problem? If I enumerate classes there is no MIIS_CSObject class. Thinking a bit more, i don't think u are having DCOM/WMI error... because the only error you see is "Password Reset Activity could not find Mv record for user." Normally if you have security/permission issue, there would be an exception Let's try this 1. runas /u:domain\fim_svc cmd 2. WBEMTEST 3. connect to root\MicrosoftIdentityIntegrationServer 4. select * from MIIS_CSObject WHERE Domain='...' and Account='...' That should return nothing... since u have an error saying no Mv object found Now, find the Mv object that corresponds to the user fdagg001 and find the MvGuid. Then 1. select * from MIIS_CSObject WHERE MvGuid='{12345-......}' 2. You should see two CS objects, one in FIM CS and another one in AD CS. 3. Double click the one in AD CS. Inspect the object, i bet the Domain is <null> If my assumption is correct, your AD CS object doesn't have a domain set

Thanks Anthony Not in office today so will probably have to try Monday.BTW -Idid look previouslyat the AD CS object viasync service console - management agents - AD MA - search connector space, and it didshow a domain attribute foruser object.

Managed to get in eventually (HyperVConsole over RDP over Citrix over Mobile Datacard isn't the speediest) Can connect to root\microsoftidentityintegrationserver in WBEMTESTQuery returns nothing (as expected)Will post mvguid query result in aminute....

Okay now we're getting somewhere. Query with mvguid returns 2 objects as expected - 1 from AD MA and 1 from FIM MA Both domain and account attributes are null for BOTH objects. But if I do a CS search from Sync Service Console, both accountname and domain are populated for AD MA CS and FIM MA CS. Guess it's something to do with a difference between how the WMI MIIS_CSObject gets populated compared to how the CS is displayed in Sync Service Console. I'm guessing something is screwed with my attribute flow and/or inbound synch rule??FYI my fresh install does not have this problem, although set up pretty much the same. (Although it does have an ma.cpp class not registered error which seems to be preventing connection to AD for pw reset - I'll post a thread on that separately if I can't figure it out soon)

Ok, if you read through this, you will realize my lack of knowledge on FIMSync, and i somehow contradict what i said before Domain isn't an attribute in AD. I double check my test machine, my user in AD MA CS does NOT have an domain attribute, it's there in MV and FIM MA CS though. And to be honestly, i am not too sure how that works exactly. See if anyone else here can help

Just asked Rob. That WMI search doesn't search the actual CS object. It perform a DsCrackNames to find the Dn, and from the Dn, it find the CSObject. He is suspecting the DsCrackNames is having some issues. Would you mind trying to refresh schema on the AD MA, as well as doing a full import? They might fail if DsCrackNames isn't working properly.The FIM Password Reset Blog http://blogs.technet.com/aho/

This has occured again - this time in our production deployment. I have logged a premier call but wonder if you have any more details about how to troubleshoot dscracknames ?? On test instance wmi query works with mvguid (Select * from MIIS_CSObject where mvguid='mvguid') OR domain and account (Select * from MIIS_CSObject where domain='domain' and account='username'). Either query returns 2 entries - 1 for AD MA, 1 for FIM MA. On prod instance wmi query works with mvguid only NOT with domain and account. Returns 2 entries - 1 for AD MA, 1 for FIM MA. Test AD MA CS Object has attributes for account, domain, userprincipalname which Prod AD MA CS Object does not - this is probably why the query with domain/account fails. The join, provisioning and attribute flows etc are the same so why does the Test CSObject have these and the Prod CSObject not have them?

so to re-phase your question, you wonder why in production, your AD CS Object doesn't have account,domain,UPN. Question 1: is the user created in FIM, then flow out to AD? or the other way around? I bet you have existing users in AD already... if that's the case, i would double check #1, what attributes are flown in, #2, the attribute flowThe FIM Password Reset Blog http://blogs.technet.com/aho/

Users are in AD already. I could create flow rules for these attributes, but I don't have them in test and it works anyway!? So my question is more "Where does MIIS_CSObject get domain, fqdn, upn, account from" ? It doesn't seem to get them from visible connector space attributes through flow rules. My test instance (where SSPR works) doesn't have these attributes in the AD CS or the MV for the user objects, and doesn't have them defined in attribute flows, but they ARE present in the WMI MIIS_CSObject for the users. Prod has the same user attributes as Test in the AD CS and the MV for each user, but doesn't have domain, fdqn, upn in the users' WMI MIIS_CSObject.

You support contact is already working with you to address this issue. Let's take this offlineThe FIM Password Reset Blog http://blogs.technet.com/aho/

Sure - will post resolution when we find it in case others strike the same issue.

This is caused by using an AD MA account name which exceeds 16 characters. All FIM functions apart from the Password Reset WMI call handle this correctly, but the PW reset call does not, and does not produce a specific error message. Workaround is to use shorter account name.

I just tested the 2010 R2 SSPR portal with a 20-character account name and it worked without any difficulty. However, this is after quite some struggle with the WMI service, all due to an incorrect credential in the AD MA--which borked DsCrackNames--which was not appropriately logged anywhere. (It's a test environment, thus failures of the AD MA to run had not already bubbled to the surface.) Had a moment of clarity upon reading other notes in this thread that the WMI search does not actually search the connector space per se with the query terms... a bit surprising. On a somewhat related note, it is IMHO more sensible to add the FIMService account to the local DCOM Users Group, in place of adjusting the Component Model cpanel settings.