FIM 2010 RC1 Self Service Password Reset Registration Error

In my last post, I discussed an issue with creating the FIM Service MA when you are building an all-in-one demo environment.  This is another one of those issues.   My single VM is a Server 2008 machine, so in addition to FIM 2010 RC1, it has AD DS, Exchange 2007, SQL 2008, SharePoint Services, and Visual Studio 2008.

If you are unaware, Exchange 2007 creates a self-signed computer certificate during install and uses that for securing its connections by default.  In my case, Exchange 2007 was installed prior to FIM so the certificate was there when I installed FIM.  During the FIM install, it recognizes the certificate’s presence and uses it for the Security Token Service (though that’s not very clear).

The issue I ran into was during registration for Self Service Password Reset.  The user was prompted to register, confirmed their identity by re-entering their password, and answered the gate questions.  Immediately up submitting the answers, I received the following error:

An error was encountered. Please call helpdesk or your system administrator for further assistance.

After some digging on forums I discovered this post regarding the certificate.  After copying the self-signed certificate to the “Trusted People” store, I was able to successfully register for SSPR.

FIM Service Management Agent Creation Error

I recently began building a FIM 2010 RC1 VM for testing/demo purposes.  This is an all-in-one Server 2008 machine, so in addition to FIM 2010, it has AD DS, Exchange 2007, SQL 2008, SharePoint Services, and Visual Studio 2008.

FIM 2010 recommends three FIM related user accounts:

• FIM Synchronization Engine
• FIM Service
• FIM Management Agent

I created the accounts and set up the Sync service without issue.  After installing the FIM portal and service, I went to set up the FIM Service Management Agent, but received the following error:

Failed to retrieve the schema.

Failed to connect to the specified database or Forefront Identity Manager Service. Please check the specified database location, service host address, and account information.

I double checked all of my information (and even re-installed the FIM Service to verify the settings I used when installing it), but nothing seemed to be wrong.  I enabled all success and failure auditing on the DC, and found the following event when I retried the information:

Log Name:      Security
Source:        Microsoft-Windows-Security-Auditing
Date:          10/13/2009 11:19:43 AM
Event ID:      4625
Task Category: Logon
Level:         Information
Keywords:      Audit Failure
User:          N/A
Computer:      FIM.lab.loc
Description:
An account failed to log on.

Subject:
    Security ID:        LAB\FIM_sync
    Account Name:        FIM_sync
    Account Domain:        LAB
    Logon ID:        0x130e4c

Logon Type:            2

Account For Which Logon Failed:
    Security ID:        NULL SID
    Account Name:        FIM_ma
    Account Domain:        LAB

Failure Information:
    Failure Reason:        The user has not been granted the requested logon type at this machine.
    Status:            0xc000015b
    Sub Status:        0x0

Process Information:
    Caller Process ID:    0x168c
    Caller Process Name:    C:\Program Files\Microsoft Forefront Identity Manager\2010\Synchronization Service\Bin\miiserver.exe

Network Information:
    Workstation Name:    FIM
    Source Network Address:    -
    Source Port:        -

Detailed Authentication Information:
    Logon Process:        Advapi 
    Authentication Package:    Negotiate
    Transited Services:    -
    Package Name (NTLM only):    -
    Key Length:        0

Note the “The user has not been granted the requested logon type at this machine” message.  In my case, the server is a DC, so that account has no rights to log on.  Once I put the account into the domain local Administrators group, the MA creation process proceeded just fine.

Forefront Identity Manager (FIM) 2010 RC1 released

The long awaited RC1 for FIM 2010 was released yesterday.  Microsoft has promised an upgrade path from RC1 to RTM.  No upgrade path exists for any of the betas or RC0.

Get the bits at http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=4bb3f16b-27f8-4c1d-922f-2c7b522d9ad6.

Using Messenger accounts with non-Microsoft SMTP Domains in LCS/OCS With PIC

UPDATED 03.18.09:  This does not work correct with Office Communicator 2007 R2 RTM.  The workaround for this can be found here.  Also, the list of MS domains has expanded to include live.com and its variants.  See the KB article referenced below for the full list.

 

I'm not sure if the subject on this post even makes sense, but it's the best I could come up with.  Essentially the issue is that even though you have LCS or OCS set up with Public IM Connectivity (PIC) you can't add contacts that use MSN/Live Messenger unless they have a Microsoft SMTP domain for their account.  The valid MS domains (as of the latest update on the KB article) are:

• hotmail.co.jp
• hotmail.co.th
• hotmail.co.uk
• hotmail.com
• hotmail.com.ar
• hotmail.com.tr
• hotmail.de
• hotmail.it
• hotmail.fr
• messengeruser.com
• msn.com
• simpatico.ca
• passport.com
• passporthotmail.com
• webtv.com

I think it's safe to assume the live.com and all the country specific variations of it are on that list as well, but I haven't tested those.

But, you can set up a Messenger account with any SMTP domain you want.  If you add them in to the LCS/OCS client, they simply don't work.  I may be an idiot, but for the longest time I thought that's just the way it was.  Then today I stumbled across a KB article that describes how to do it.  It's a matter of manipulating the IM address of the contact you want to add.  It's not very obvious, and it would be nice to see the OCS client/server catch these and fix them for you, or at least tell you the proper format.

So I know user@gmail.com is a Messenger user, and I want to add them to my OCS client, the address should be entered in the following format:

user(gmail.com)@msn.com

Odd, but hey it works.  Check out the full KB article here.