The FIM Self Service Password Reset deployment is explained very well on the following TechNet site: http://technet.microsoft.com/en-us/library/ee534892(WS.10).aspx More specific I was following the steps to implement delegation so that Helpdesk users can unlock people for SSPR. Although the guide is very detailed I had a minor issue with it. More specific during the execution of “Step H5: Create an MPR enabling helpdesk users to read password reset users”.

The problem I had was that when my Helpdesk test user click edthe search button in the portal to locate users, no results were retrieved. At least except for his own account.

The steps where things go wrong: In Resource Attributes, select Select specific attributes, and then enter Resource Type and DisplayName. Click the validate icon, and then click Finish. [EDIT: also select Resource ID see bottom]

In fact you should click the browse button, select users (search within) and then enter Resource Type & DisplayName and select both. This will ensure you get the attributes of the user class.

My source for this solution: Joe Stepongzi on http://social.technet.microsoft.com/Forums/en-US/ilm2/thread/a1bf7c7b-97d3-4d90-aeac-3a430a86a47a

In a following post I plan to explain how to enable the UI for Helpdesk users to be actually able to see the “Unlock Users” shortcuts as this is currently missing from the TechNet procedure.

[Edit 30/09/2010] I altered the title as I came upon a second minor issue:

Besides selecting Resource Type and DisplayName you also have to select the attribute Resource ID. When I left the Resource ID out, I got an access denied when clicking a user to view whether it’s locked or not. Enabling the MPR User management: Users can read selected attributes of other users” made it work. Well I didn’t wanted this policy to be enabled. I just wanted the Helpdesk to be able to unlock other users, not read all their attributes. So I started eliminating and finally got to the Resource ID attribute.

For other people who are blogging: there is a new version of Windows Live Writer (2011 beta) out there, it can be downloaded from http://explore.live.com/windows-live-essentials-beta

A screenshot of the new version, which looks a lot more like Word now:

I particularly like it they made the font stuff more accessible. I’m still suffering blurry images though. Must be something I do wrong in the process…

And besides the beta for the Windows Live suite, there is also a beta for Internet Explorer 9. I’m using it now for a few days and I’m pretty happy about it. It can be downloaded from http://windows.microsoft.com/en-us/internet-explorer/products/ie-9/home?os=win7&arch=b&browser=ie9

They merged the search box with the address bar, which is not a bad idea. And it comes very clean button-wise. Besides that you can now also link specific sites to your Windows 7 Taskbar. I use it for the 2-3 websites I visit a lot.

Thomas,
Happy Blogging & Surfing!

As the FIM Synchronization Service Manager does not have any out of the box scheduling capabilities, I have to create a script which can be run as a scheduled task to do regular synchronizations. There are a lot of examples out there for scripts, one of the examples can be found here: Technet ScriptBox: Using Powershell to start Run Profiles That’s actually where I based my script on. The script is not the subject of this post. Like with all scripts, logging is very important. If your script is going to be ran on a regular base, and production data is involved, logging cannot be let out.

For scripts like that I prefer two logging modes: debug & operational. Debug is switched off by default, but when switched on floods some text based log with as much output possible. Operational on the other side should be clear, concise and easy to check. The idea of receiving a mail when things go wrong is very nice, but I prefer to leverage the System Center Operations Manager (SCOM) tool a customer has to generate alerts based on event log entries. This way the complete IT staff is up to date when things go wrong and not just one mailbox which is flooded by alerts of a 1000 scripts.

The example below works on a Windows 2008 R2 server, but it will probably work on earlier versions as well. The result of my custom event log looks like this:

You can see I have an “Application and Services Logs” log (FIM Run Profiles Task") where I can write events too. Besides the log I also have a event source so I can know which application/script logged the events. How do we get this? Quit simple, open up regedit and:

1. Create a key with the name of your custom event log below HKLM\SYSTEM\CurrentControlSet\Services\eventlog\
2. Create a key with the name of your custom event source below HKLM\SYSTEM\CurrentControlSet\Services\eventlog\YourEventLog
3. Create a REG_EXPAND_SZ (Expandable String Value) with the following value in it:
   1. For x64 OS: C:\Windows\Microsoft.NET\Framework64\v2.0.50727\EventLogMessages.dll
   2. For x86 OS: C:\Windows\Microsoft.NET\Framework\v2.0.50727\EventLogMessages.dll
4. Reboot the server. Don’t leave this step out or your events won’t be displayed correct.

The result should look like this:

Don’t worry about the referenced .NET 2.0 folders, I’m pretty sure they’ll stay there for backwards compatibility. I verified the v3.0 and v3.5 folders and they don’t contain this DLL, so it’s absolutely necessary you pick those. You might wonder why you need to reference a DLL which seems to come from the .net framework. This DLL is in fact an easy way to make sure the Event Viewer knows how to translate your events. A lot of applications have their own DLLs so you can see events in a localized language, or when writing event x, you get the message y. However all we want is to write custom messages to the log, and that’s just what this DLL is meant to do: you pass it a string, and it logs that as the event. If you’d leave out the DLL, your messages would look like the screenshot below, stating that “The description for Event Id x from source Y cannot be found. Either the compontent that raises this event is not installed on your computer or…”

And to finalize this post an example how to log to this event log using PowerShell. I’m pretty sure you can easily do this with VBscript or .net as well. First I prepare a string which will contain the message to displayed in the event entry. I mixed ‘ and “ for a specific reason: strings surrounded by ‘ and ‘ will have their PowerShell variables not resolved. String surrounded with “ and “ will resolve. The “`r`n” will make sure the content following will be printed on a new line.

$eventMsg =  'Scheduled Task to run FIM Synchronization Profiles blocked because $maintenanceModeEnabled is set to true.' + "`r`n" `
+ 'Alter the script so that $maintenanceModeEnabled is set to false if regular syncs should be performed again.' + "`r`n"`
+ "The script: $script"

And the we write to the event log:

write-eventlog -logname "FIM Run Profiles Task" -Source "FIM Run Profiles Task" -Message $eventMsg -EntryType "Information" -EventId "1"

The logname and Source are self-explanatory we created them in the registry editing steps. The Message parameter contains the string which will be used in the entry. The EventId can be chosen as you like it. As for the EntryType the following values are valid: Error, Warning, Information, SuccessAudit and FailureAudit.

Thomas,
Happy Logging!

How does FIM SSPR handles multi-domain environments?

The FIM's Password Reset Activity (Action Activity) will:

1. Try to find the CS object by matching domain + username
2. Use WMI to make a SetPassword call

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')

Source:http://social.technet.microsoft.com/Forums/en-US/ilm2/thread/28fcfc43-54f6-4f8e-9602-21663d11a250

What happens when a user resets his password?

In fact this action is very similar to an administrator right-clicking your account in ADUC and choosing reset password:

A FIM SSPR reset will:

1. Reset your password
2. “Uncheck” User must change at next logon
3. “Check” unlock the user’s account

Especially the last one is very interesting, whenever a user locks his AD, he can unlock himself! So the SSPR feature can be used for more than just forgotten passwords. Maybe this is obvious, but I had no idea.

As I started playing around with the Self Service Password Reset functionality of FIM, which is explain nicely in Password Reset Deployment Guide, I encountered an error during the registration phase.

First the Welcome screen popped up, where I clicked next.

And got greeted with a vague error: An error was encountered. Please call helpdesk or your system administrator for further assistance. As I am the administrator myself I started troubleshooting, again…

Not much in the event logs (client nor server), so I started looking on the FIM Forums (TechNet) and found the following procedure to enable logging for the Password Reset Client Service:

1. Open an elevated prompt and run the following commands:
   1. copy "%ProgramFiles%\Microsoft Forefront Identity Manager\2010\Password Reset Client Service\pwdmgmtproxy.exe.config"  "%ProgramFiles%\Microsoft Forefront Identity Manager\2010\Password Reset Client Service\pwdmgmtproxy.exe.config.bak"
   2. notepad "%ProgramFiles%\Microsoft Forefront Identity Manager\2010\Password Reset Client Service\pwdmgmtproxy.exe.config"
2. In the configuration file notepad opened, perform the following changes:
   1. Look for the element:  <source name="Microsoft.ResourceManagement" switchValue="Warning">
   2. And change "Warning" to "Verbose"
   3. Look for the element: <add initializeData="C:\Logs\PwdMgmtProxy.svclog"
   4. And change to <add initializeData="c:\Program Files\Microsoft Forefront Identity Manager\2010\Password Reset Client Service\PwdMgmtProxy.svclog"
3. Now perhaps pretty obvious, but notepad has no syntax coloring, so i forgot this at first: remove the <!—and –> which actually comment the configuration settings
4. Ensure NT AUTHORITY\Network Service has Write permission to "%ProgramFiles%\Microsoft Forefront Identity Manager\2010\Password Reset Client Service". You can right click the folder, and edit the NT Authority\Network Service it’s entry, give it modify
5. Restart the Password Reset Client service.

Now try registering again and reproduce the error. Now you could open the PwdMgmtProxy.svc log using notepad, it would look like:

Happy troubleshooting…….! But there is an alternative, a typical Visual Studio installation comes with an utility called SvcTraceViewer. If you copy the log file to a machine with Visual Studio installed, it will be a known file extension and your troubleshooting will look a lot better:

By altering the logging options, we’d even got an entry in the application event log, so all the hassle with the log file was not really necessary. But perhaps for more advanced issues it could come in handy.

Basically what happed in this specific case is that somewhere in the installation of the FIM Portal/FIM Service I entered a wrong URL (well the wrong DNS suffix, damn all those lab environments!). There are several places to look for URLs used by FIM:

1. Search in the registry on the client or the FIM Portal/Service: all was fine
2. Search in the database of the FIM Service: all was not fine:

/****** Script for SelectTopNRows command from SSMS  ******/
SELECT TOP 1000 [ServicePartitionId]
      ,[ServicePartitionName]
  FROM [FIMService].[fim].[ServicePartition]

Gave me:

We could try altering the value in the database… But we’re not gonna do that, it’s unsupported and might leave your database in an inconsistent state. To be completely honest, I did and it didn’t acted as it should :) Thanks god it’s a lab environment.

The better way is to keep searching where it was originally set. So I ended up in the following location: C:\Program Files\Microsoft Forefront Identity Manager\2010\Service with the Microsoft.ResourceManagement.Service.Exe.config file:

Update it, restart the FIM Service, the database gets fixed and the SSPR error goes away! Afterwards I found out that whether I manually edit it in the DB, or alter it in the configuration file, an extra ServicePartition is added in the DB. Perhaps a work around is to stop the FIM Serivce, alter both the configuration and the db and start again. But if you want to keep your configuration supported: try re-running the FIM setup. During the setup you should be able to provide the URL and get your self back on track. If this is not the case it’s probably advised to call in some help.

With thanks to Paul Williams for the advanced logging procedure: http://social.technet.microsoft.com/forums/en-us/ilm2/thread/34B61A17-F0A8-4FCC-9525-0ED96E51420B

P.S. If you want to trigger the self service password registration wizard to start, you can simply execute mspwdregistration -all

Some of the functionality of FIM is presented towards end-users. As such it might be desired to present that in the native language of the users. FIM provides two language packs: one for the FIM Portal and one for the FIM client add-ins. Some of the information I will provide below can also be be found at: http://technet.microsoft.com/en-us/library/ff512688(WS.10).aspx Installation will not be covered here.

To me it wasn’t clear what is looked after when determining the language. It’s explained on TechNet quit good, but I found that out afterwards. There are 4 places where you can configure a language which is relevant to FIM:

• System display language
   
  
• User display language
  
• User regional settings
  
• User IE language settings (Tools –> Internet Options –> General: languages)
   
  

There are 4 FIM interfaces where the language is shown in the user his language:

1. In the ctrl-alt-del experience: when clicking “reset my password”
2. After logon, when password registration kicks in (or mspwdregistration –all is executed)
3. When browsing the portal
4. When clicking “register for password reset” in the portal, the registration wizard is started
   

For the ctrl-alt-del experience, the only language that matters is the system display language. This actually makes sense as the user is not logged in yet. The first problem with this is that a user requires administrative privileges to alter this setting. The second one is that when users share a workstation, the system language is shared. So it’s hard to have a user be able to reset his password in his own language.

The second item, the initial registration which automatically starts at first logon, follows the system display settings of the user. The portal clearly follows the regional settings of the user. And finally, the registration wizard, when triggered from the portal, also follows the regional settings of the user.

Now the problem I have with the language packs is that, although they include “Dutch”, they only do this for nl-NL and not for nl-BE. Just like they include “French”, they only do this for fr-FR and not for fr-BE. As a small country we are being discriminated! ;) Below is how the FIM language packs work out for me, regardless the fact that nl-BE and fr-BE are not supported:

1. In the ctrl-alt-del experience: when clicking “reset my password”
   -> Works: the system display language is "Dutch” or “French”
   -> There is no relation to the Netherlands (NL) or Belgium (BE) in the display language settings, so this makes sence
2. After logon, when password registration kicks in (or mspwdregistration –all is executed)
   -> Works: seems to follow the user display language (“Dutch” or “French”)
   -> There is no relation to the Netherlands (NL) or Belgium (BE).
3. When browsing to the portal
   -> Magically works: although the regional settings are set to nl-Be or fr-BE, the portal is displayed in the correct language
4. When clicking “register for password reset” in the portal, the registration wizard is started
   -> Does not work: possible workaround: add nl-NL or fr-FR as the primary language in the portal. From then on, the wizard will be shown in the user his language… But I don’t like this solution.

The languages which are supported are listed at the following URL, now I understand why they mentioned specific countries between brackets: http://technet.microsoft.com/en-us/library/ff512688(WS.10).aspx Note there is also a difference for the client add-in versus the Portal languages. For neither Belgium (FR/NL) is supported, but for the portal they work just fine.

P.S. The language of the actual questions can be localized by using multiple workflows/MPRs and sets based on a region or language attribute. This has nothing to do with the language settings on the system.

Today I got an issue which got me pretty frustrated. I’m definitely not going to admit how long it took me to get this one solved. Some background information: in the project I’m currently participating in we have several lab environments. One for the Exchange guys, one for the SCCM boys and one for AD/FIM/SCOM. Besides that we got also an acceptance environment before we hit production with our stuff. One thing off having multiple environments is you have to keep them in sync. One of the things to sync is the GPO’s. Yesterday we did a refresh in our acceptance environment by deleting all policies over there and running our PowerShell script which creates, links and imports the settings.

The consequence: today they asked me if something had been changed, remote desktop to the virtual Windows 7 clients no longer seemed to work. Euh, changed? anything? Oh, we might have done something to the GPO’s, but would that be related? Of course it was :) Here is a screenshot of what we were seeing (The connection was denied because the user account is not authorized for remote login):

Fixing remote desktop, now that would be a quicky:

1. Is the remote desktop enabled? yes
2. Is the firewall allowing remote desktop? yes
3. Is the user trying to use RDP member of the Remote Desktop Users? yes (at least Domain Users are, so …)

So all seemed fine. But I didn’t start to despair, I verified

1. The GPO which adds the “Domain Users” to the Remote Desktop Users
2. RSOP.msc
3. Secpol.ms
4. GPresult /R
5. Rebooted
6. Rejoined the client to the domain
7. …

And then, 5 minutes before I had to leave for my train, I finally saw it:

Notice anything funny? The Remote Desktop Users Group has gotten an evil twin brother! Now this makes our GPO look suspicious. Especially with the “Built-in” which is in the group name, that’s not supposed to be there… So off to our group policy preference which configures this. I simply deleted the entry and recreated it. Now the proper group was being updated…

This is how we transfer GPO’s: we first take a backup of all GPO’s in the source domain using the GPMC, and then we use the following PowerShell cmdlets, an example:

import-gpo -backupgponame "GPO_C_Workstation Settings_v1.0" -targetname "GPO_C_Workstation Settings_v1.0" -path "$rundir" -createifneeded
$gpoName = "GPO_C_Workstation Settings_v1.0"
new-gplink -name "$gpoName" -target "ou=computers,$departmentDN" | set-gplink -order 1

What was happening is that when using the import-gpo cmdlet, it used the “Remote Desktop Users (built-in)” as a string for a new group, in stead of detecting it as a well known group. Because the description was not set using GPO, my attention never got drawn to the original “Remote Desktop Users” group…