SSPR client won't install on XP RRS feed

  • General discussion

  • I'm deploying a password-reset solution and have the portals up and running, and can install the client to Windows 7 machines via the command line (simulating a Configuration Manager deployment) but cannot get the client to install on our XP SP3 test machine (domain connected).

    The installer runs through but cannot start the service at the end. The msi installer log and the event log provide only the lightest of information pointing at a permissions issue:

    Event Type: Error
    Event Source: MsiInstaller
    Event Category: None
    Event ID: 11920
    Date: 20/08/2012
    Time: 16:48:45
    User: xxx\xxx
    Computer: VMSW02
    Product: Forefront Identity Manager Add-ins and Extensions -- Error 1920. Service 'Forefront Identity Manager Password Reset Client Service' (FIMPasswordReset) failed to start. Verify that you have sufficient privileges to start system services.

    For more information, see Help and Support Center at
    0000: 7b 36 36 33 42 45 44 45   {663BEDE
    0008: 32 2d 35 44 46 42 2d 34   2-5DFB-4
    0010: 32 32 43 2d 42 32 44 39   22C-B2D9
    0018: 2d 41 39 44 30 30 46 46   -A9D00FF
    0020: 39 35 31 31 34 7d         95114}  

    The service is trying to use NETWORK SERVICE to start and a domain admin performed the installation (not that I can imagine this making a difference).

    We did find one article that suggested it was a machine.config access issue, but after giving access to this to NETWORK SERVICE, it didn't resolve the issue.

    Has anyone seen anything like this?

    Tuesday, August 21, 2012 9:21 AM

All replies

  • I've seen exactly the same issue on windows 8 rtm. i guess its not about the permissions. service just fails to start for other reasons... probably. after failing to install sspr client on windows 8 i successfully installed sspr client on windows 7... same distro, same environment. so i guess its OS\client issue, not permissions.

    Tuesday, August 21, 2012 10:25 AM
  • We fired up Process Monitor and collected a log. Filtering by PwdMgmtProxy.exe and ACCESS DENIED as a result value, I see 359 counts where it can't make changes to the registry.

    We moved the computer into an OU where there were no group policies in effect in case any policy was restricting the service but got no change.

    I don't know if the access denied messages are acceptable or not, but I presume not, so we'll go and see if we can it permission to make such changes and see if that helps.

    Tuesday, August 21, 2012 1:07 PM
  • Just for the record we are having same issue. Trying to find more info on why. Getting ready to call Premiere support if I can't find an answer soon.

    If of any interest I also installed FIM under Domain Admin account.

    Note these logs just prior to service start error:

    MSI (s) (68:04) [09:27:25:295]: Executing op: ServiceInstall(Name=FIMPasswordReset,DisplayName=Forefront Identity Manager Password Reset Client Service,ImagePath="C:\Program Files\Microsoft Forefront Identity Manager\2010\Password Reset Client Service\PwdMgmtProxy.exe",ServiceType=16,StartType=2,ErrorControl=32769,,,,StartName=NT Authority\NetworkService,Password=**********,Description=Forefront Identity Manager Password Reset Client Service)

    MSI (s) (68:04) [09:27:25:465]: Executing op: CustomActionSchedule(Action=SetServiceRecoveryActions,ActionType=3073,Source=BinaryData,Target=CAQuietExec,CustomActionData="C:\WINDOWS\system32\sc.exe" failure FIMPasswordReset reset= 86400 actions= restart/6000/restart/6000/""/0)

    MSI (s) (68:04) [09:27:25:715]: Executing op: ServiceControl(,Name=FIMPasswordReset,Action=1,Wait=1,)

    MSI (s) (68:04) [09:27:56:716]: Product: Forefront Identity Manager Add-ins and Extensions -- Error 1920. Service 'Forefront Identity Manager Password Reset Client Service' (FIMPasswordReset) failed to start. Verify that you have sufficient privileges to start system services.

    Error 1920. Service 'Forefront Identity Manager Password Reset Client Service' (FIMPasswordReset) failed to start. Verify that you have sufficient privileges to start system services.

    • Edited by GPD Tuesday, August 21, 2012 3:58 PM
    Tuesday, August 21, 2012 3:51 PM
  • System Notes:

    This is a clean build of XP SP3 with all updates.

    I am logged into the machine as Domain Admin(I have tried regular account as well)

    I am able to install on Windows 7 x64 machines. Have not tried Windows 7 x86 machine yet as we have none in our environment.

    The log files and events tell me nothing useful as far as tracking down the cause.

    Update: Did find this based on event ID : 7000

    Seems vaguely related to either Exchange or SQL

    • Edited by GPD Tuesday, August 21, 2012 6:00 PM update
    Tuesday, August 21, 2012 4:09 PM
  • Thanks GPD. Glad to hear it's not just me having problems. Please share the outcome if you speak to Microsoft.
    Tuesday, August 21, 2012 4:19 PM
  • Quick question; to make sure I have my SPN configured correctly, I need clarification.

    The online docs state conflicting info for the SQL SPN.
    I have it set to the DB service account and the info seems  to state that but it also seems to state setting on the sql DB server. Which is correct? And if I have it wrong then why does it work for Windows 7?

    MSSQLsvc/<SQLDatabase Server>

    SQL Database Account

    • Setspn –S MSSQLsvc/ corp\sqldatabase
    • Setspn –S MSSQLsvc/app1:1433 corp\sqldatabase

    SPN required for the FIM Service database.  Allows clients the ability to locate an instance of SQL.

    • Edited by GPD Tuesday, August 21, 2012 6:40 PM
    Tuesday, August 21, 2012 6:39 PM
  • as far as i know setting spn for sql is not needed for fim 2010 r2 to work. at least at my test lab sspr, rich client, portal, service and synch service work fine without spn for sql.
    Tuesday, August 21, 2012 6:50 PM
  • I added an SPN for the database server domain account and it didn't do any harm. Better to have too many than too little, as I found out.
    Wednesday, August 22, 2012 11:02 AM
  • For what it's worth, I've found the FIM 2010 R2 SSPR add-ins to install and function properly on XP SP3 without any obvious issues (via the regular installer, haven't tried CLI).  NETWORK SERVICE is the correct service identity.

    You might consider turning on tracing from PwdMgmtProxy.exe.config.  I don't think SPNs would come into play at all right now -- the password reset proxy has nothing to do at startup w.r.t. interacting with other services.

    Wednesday, August 22, 2012 6:58 PM
  • Update:

    I have called Premier and he is looking at logs.Meanwhile, I continue to attempt to track it down down.

    One thing I have noticed is the failure is always on the Network Service acct.

    I am running the portal as SSL on port 444. I have bound the pwreg and pwreset headers in IIS to port 443.

    While I wait I am going to take the portal back down to port 80, non secure and see what happens.

    I know little about certs but the pwreg and reset cert were created using 64bit encoding.

    Connection to 32 bit issues? I don't know.

    • Edited by GPD Thursday, August 30, 2012 12:39 AM
    Friday, August 24, 2012 3:11 PM
  • None of the FIM Server-side conditions should prevent the password reset proxy service from starting--it would only stop password enrollment and reset from functioning.  More likely is a system policy that restricts the accounts that can logon as a service, bad NTFS ACLs, or the like.  I would also review the ACLs on the service itself just in case.
    Friday, August 24, 2012 3:21 PM
  • Well, as promised, here are the results of my time spent with Premiere support.

    Still broke and both of us are stymied.
    They are literally stumped and I was one step away from being escalated to development. company did not want to spend anymore hours on the issue so I had to cut it off with Premiere support.
    Our final decision? Anyone with XP does not get the client. They will have to wait until we get them upgraded to Windows 7.

    Was hoping to return with good news.

    PS: Steve, we checked all of that but thanks for the tip.
    • Edited by GPD Thursday, August 30, 2012 12:40 AM
    Thursday, August 30, 2012 12:36 AM
  • I would put my money on a GPO security / user rights setting as the cause...

    FYI, the "failure" bit in the logs is just the service configuration for action to take on failure (retry, reboot the machine, custom action, etc.).

    Mind posting the results of "sc sdshow FIMPasswordReset" ?

    Thursday, August 30, 2012 4:47 PM
  • I had a similar problem with XP at one site which didn't show up anywhere else.

    It turned out nothing to do with permissions, but that the service wasn't starting up in time. I increased the ServicesPipeTimeout value and it worked

    Friday, August 31, 2012 9:14 AM
  • Has anyone managed to find a resolution for this issue yet?

    I'm trying to install the R2 client on XP, however the service refuses to start. Increasing thr ServicesPipeTimeout registry key hasn't made a difference.

    I've installed an XP virtual machine in my demo VM environment and the R2 agent installed fine, so I'm wondering if it could be some sort of group policy setting affecting the NT Authority\Network Service account, which is what runs the service.

    Thursday, October 4, 2012 9:51 AM
  • Further update - we increased the ServicesPipeTimeout value to 3600000 (1 hour in milliseconds) and that allowed the agent to install eventually. However the Password Reset Service still takes 3-5 minutes to start up, so when a desktop is booted up the SSPR service is unavailable for that amount of time.

    We've solved this particular issue for now by deploying the R1 agent instead, but obviously we lose the ability to enforce answer length and uniqueness for the XP/R1 clients, which is less than ideal.

    Anyone have any ideas of what could be causing the R2 agent to be so slow to start up, but not the R1 agent?

    Friday, October 5, 2012 9:36 AM
  • Total guess here, but is the workstation able to connect to the Internet? I've seen applications and services that use Authenticode being slow because they timeout doing a CRL check at startup.

    Frank C. Drewes III - Architect - Oxford Computer Group

    Friday, October 5, 2012 12:55 PM
  • Made sure the account/machine had access to the Internet, didn't help. 

    Service still failed to start during the install.  

    Initially, bumping the ServicesPipeTimeout value up seemed to fix the issue, but now I have a machine where the bumped value doesn't make a difference.

    Installing Self-Service Client included in FIM 2010 R2 SP1 distribution.

    Is there anyone who has had progress on this issue? 

    Tuesday, April 2, 2013 2:27 PM
  • Anybody ever get anywhere with this?

    We've just started our FIM client deployment and have exactly this issue on Windows XP machines  :-(

    Tuesday, July 22, 2014 2:29 PM