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…

Today a colleague of mine was installing SCCM. One of the steps involved adding a service account (domain user) to the “Log on as a service” User Right on a given server. This can be done through GPO or locally using secpol.msc. After clicking apply the following error popped up: An extended error has occurred. Failed to save Local Policy Database.

In this case I cheated by taking an other User Right (Create a token object) as I didn’t wanted to screw my security configuration. Because after clicking ok and reloading the security policy, both the IIS APPPOOL\DefaultAppPool and IIS APPPOOL\Classic .NET AppPool are gone! And you can’t re-add them as the error pops up. To get them back you can first uninstall IIS and then install IIS. Or perhaps the first workaround I describe next can be applied…

I could easily reproduce this on an other server. Someone also logged this at MS connect: https://connect.microsoft.com/WindowsServerFeedback/feedback/details/557506/local-security-policy-editor-error-when-changing-log-on-as-a-service-privilege?wa=wsignin1.0

The description:

After installing Exchange 2010, it added the IIS APPPOOL\DefaultAppPool and IIS APPPOOL\Classic .NET AppPool identities to the "Log on as a service" privilege. When you try to add another principal to the "Log on as service" privilege an error occurs when saving. When you close the local security policy editor, reopen it and look at the "log on as service" privilege, the "DefaultAppPool" and "Classic .NET AppPool" identities did not save.
You can re-add the IIS APPPOOL\DefaultAppPool and IIS APPPOOL\Classic .NET AppPool identities to the "Log on as service" privilege, but when you try to save the changes an error occurs and they are not saved.

The workaround my colleagues found was to add the service account to the User Right by cheating a little bit. Being a member of the local administrators they configured a given service to “log on” as that specific account which in turns add the account the “log on as a service” User Right upon clicking apply. All this from within the services.msc console. And that seemed to do the trick.

An other possible workaround is to add your service account before you install the IIS components, as it’s the IIS role installation which adds these accounts in the first place.

While setting up Self Service Password Reset (SSPR) in FIM 2010 I initially encountered some problems so I started verifying my configuration. One of the more elaborate configuration steps of the SSPR functionality is the configuration of DCOM and WMI. The FIM scriptbox has some PowerShell scripts who can do it for you: WMI and DCOM (Brad Turner) Nevertheless I choose to do it manually.

If you’re in doubt whether your FIM Service account has all the required permissions you can perform the following steps:

1. Make sure your FIM Service account has “allow logon locally” on your FIM Synchronization Server, this is just so we can do the “runas /u cmd”. Besides that this is not a required privilege for SSPR to work.
2. Start a cmd and execute: runas /u:domain\fim_svcacct cmd
3. In the new cmd, execute: WBEMTEST
4. An utility which looks like this will be launched:
   
5. Connect to root\MicrosoftIdentityIntegrationServer
6. Click Query…
7. Execute this query: select * from MIIS_CSObject WHERE Domain='domain' and Account='fim_svcacct'
   
8. Double click the result and copy paste the MaGuid and PartitionGuid to a temporary notepad window. You can easily copy them by selecting the property and choosing “Edit Property”.
     
9. Back to “Query….”: execute the following query:SELECT * FROM MIIS_ManagementAgent WHERE guid='{ma guid}'
10. You should see your AD MA
11. Get the __PATH of that object (e.g. \\FIMSERVER\root\MicrosoftIdentityIntegrationServer:MIIS_ManagementAgent.Name="AD")
12. Back to WBEMTEST, choose “Execute Method”
13. Type the entire path from (11)
14. Change the Method to “GetServerStatus”
     
15. Click “Edit In Paramaters…”
16. Change PartitionGuid: Edit Property –> Not null –> {partition guid} –> save property –> save object
17. Execute
18. You should see success as return value:
    
19. Don’t forget to edit out the parameter!

As usual I didn’t figured this out all by myself. The procedure was found at http://social.technet.microsoft.com/Forums/en-US/ilm2/thread/618a78ae-e150-4269-a2eb-5ccc40229e7e and originally provided by Anthony Ho. It’s more or less a copy paste of his information. Thanks Anthony!

After installing the FIM Password Reset Extensions on a Windows 7 x86 client I started seeing massive amounts of the event 7000 on the client in the system application log:

The Diagnostic Service Host service failed to start due to the following error:
A privilege that the service requires to function properly does not exist in the service account configuration. You may use the Services Microsoft Management Console (MMC) snap-in (services.msc) and the Local Security Settings MMC snap-in (secpol.msc) to view the service configuration and the account configuration.

Opening services.msc I could see the service in question:

On a client without the Password Reset Extensions:

A quick bing didn’t got me much, a lot of unrelated stuff. Because we are in an environment with the Windows 2008 Security guidelines implemented (the Enterprise Client model, http://technet.microsoft.com/en-us/library/cc264463.aspx ) I started suspecting the EC model. After a lot of reboots and an unhealthy amount of coffee I got the GPO pinpointed which seemed to block the service from starting: Win7 EC Desktop Policy. Finally I got to the setting which caused all my grief, it looked like this:

But it should look like this:

There is a known issue with the GPMC client when you copy/restore GPO’s which have a reference to NT Service\WdiServiceHost: Event 1202 with status 0x534 logged on Windows Server 2008 R2 domain controllers after modifying security policy It should have thrown those evens on the clients as well, perhaps I missed them because of the massive event 7000 entries. In fact we do have the hotfix installed, but because we can’t work with some dedicated management stations to manage the server infrastructure it’s hard to get all endpoints patched with this specific hotfix. I Prefer some dedicated terminal servers with all management tools on them. The reason we copy GPO’s around is because we got several lab environments and we have to keep them in sync from time to time.

So all in all this was not an issue caused by FIM, but other people might suffer from the same problem.

One of the changes in Windows 2008 was the audit policy configuration. In the past we had a limited granularity:

In Windows 2008 we had a lot of extra categories, but these had to be configured using the command-line tool “auditpol.exe”:

While it was nice, it always was a pain in the ass to get configured, if you wanted to deploy it in mass, you had to go fiddle around with scripts and scheduled tasks. Just like the Microsoft Enterprise Client security baseline did. It seems starting from Windows 2008 R2 and Windows 7 you can now configure this the “regular” graphical way. Both the Local Security Policy client and the Group Policy Management Console are now capable of displaying and configuration these settings:

And:

For some extra information: http://technet.microsoft.com/en-us/library/dd692792(WS.10).aspx

Using both the basic audit policy settings under Local Policies\Audit Policy and the advanced settings under Advanced Audit Policy Configuration can cause unexpected results. Therefore, the two sets of audit policy settings should not be combined. If you use Advanced Audit Policy Configuration settings, you should enable the Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings policy setting under Local Policies\Security Options. This will prevent conflicts between similar settings by forcing basic security auditing to be ignored.

While troubleshooting FIM Portal stuff I happen to visit the “requests” section sometimes, often you get some decent feedback about which MPR is blocking you. I had noticed that the time of the requests was behind my time. Perhaps something obvious for other, but rather by coincidence I stumbled upon the “Portal Configuration” in the “Administration” section of the FIM portal. This will allow to configure the time zone the times in the portal are displayed in.

Just click it and choose the extended attribute tab.

Then you can click the browse button. By altering the “Search Within” to “All Resources” and typing “GMT” (as an example) you can easily get an overview of all GMT options. Pick the one you require and your good to go! No more requests which display as hours in the past. An IIS reset might be required, I was doing a lot of resets and restarts so I’m not sure whether is was required :)

While adding a new attribute to our FIM Portal Schema I seemed to have stumbled upon a new issue. I could create the attribute and the binding just fine. The logical next step would be to alter the Synchronization Engine MPR regarding its access to the new attribute.  However my new attribute was nowhere to be found. Back to the schema administration then! I searched it and indeed couldn’t find it. Tried navigating to where it alphabetically was supposed to be and it was there.. Well that’s odd… I tried searching an other attribute I created weeks ago and that worked out just fine…

When we help a customer with an issue like this the first question would be: “What did you change?” Then they’d say “Nothing”. However I have to admit, “Nothing” is definitely not the case here… I do recall moving the FIM databases to another server myself… yesterday... In fact we moved from a standalone SQL server to the newly designed SQL failover cluster.

Having a SQL expert around I figured I’d get a head start moving everything swiftly by asking some advise. I’m aware that moving databases to a new server also includes pre-creating the associated logins and the FIM installed SQL jobs had to be transferred somehow as well! I got pointed to “SQL Server Business Intelligence Development Studio” and got some guidance. My migration solution looked like this:

Now that looks like a sexy solution! Just drag and drop, fill in some source/target information, check some checkboxes and we were good to go. This mini-project would first transfer the logins, then copy the selected databases, leaving the old one in place and finally migrated all Jobs. All I had to do was enable the right jobs and all was fine.

Obviously we stopped all FIM related services during the transition. After moving the database to it’s new location we updated the following registry key:

• key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\FIMService\
• Value: DatabaseServer

And started the FIMService again. The portal seemed to act just fine. Users were in it, I could provision new users, search users,… All in all this seemed a smooth transition! Time for a coffee.

Because our portal behaved nicely, and in fact we didn’t got any FIM errors, besides no search results for the new attributes, we started thinking SQL might be the culprit. Using SQL profiler we captured the query used by FIM to search an attribute. We searched twice: once for a findable attribute, once for a new one. The query was approximately 700! lines… Now that’s a giant haystack…

We pointed our FIM Portal to the “old” database and tried to reproduce our issue. No problem there, so we definitely started blaming our new shiny SQL. Perhaps a recent SQL update or so… A colleague of mine, who knows SQL a lot better than me, suggested me to compare the standalone versus the failover cluster SQL server settings. He provided me the following commands:

• sp_configure 'show advanced options',1
• reconfigure
• sp_configure

The first one will make sure the advanced options are shown also, the second command will configure this option while the sp_configure will finally provide an overview of all settings. We then exported the results to excel and compared both SQL server settings. All seemed to be equally apart from some new options on the cluster.

After comparing the SQL server settings we went on by comparing the database settings of the FIMService database both on the working SQL and on the non working SQL (cluster). We issued the following commands:

• select * from sys.databases where name = 'FIMservice'

Again we go a lot of values and exported this information to Excel, using some Excel Foo (If(Column1=Column2),True,False)) we finally found a difference! The is_fulltext_enabled value was 1 on the working SQL but 0 on our cluster. To display this value:

• select is_fulltext_enabled,name from sys.databases

The command on our standalone SQL showed the following:

Versus the SQL cluster:

Now everywhere we looked online it said that since SQL 2008 the Full-Text Indexing was enabled by default and didn’t need to be altered (Technet: How to: Enable a Database for Full-Text Indexing (SQL Server Management Studio). Well our databases hadn’t! Creating a new database on the cluster indeed showed up with Full-Text Indexing enabled. We then tried to move the FIM Service database using a SQL backup restore from the standalone to the cluster and that showed up as Full-Text Indexing enabled too! Damn my swift my migration tool! So we attached our “faulty” database again and searched the Full Text Catalogs folder. It was there, and it actually had stuff in there which related to the query we gathered at the very beginning. This started looking good!

Right-clicking the database and viewing the Files section it showed us that Full-Text Indexing was enabled for the database. It was checked and grayed out…

So back to the command line stuff to enable the Full-Text Indexing:

• use FIMService
• exec sp_fulltext_database 'enable'

And a screenshot:

And finally our attributes get found again. Now this was a fun day!
Thanks Jeroen for your SQL knowledge and courage troubleshooting this with me :)

Thomas ‘I’ll never move a database again’ Vuylsteke