Remote Desktop Session Disconnection Issue

Published on Tuesday, December 21, 2010 in , ,

In the project I’m currently involved in, we have several virtual machines installed with Windows 7 as the operating system. These workstations are used as administration workstations to manage the server infrastructure. Every once and a while someone would get disconnected from their terminal server session. By simply reopening the session they could continue their work. We stumbled upon the following KB article: KB2083411 The article states:

When the policy is refreshed (by default, every 90 minutes, or manually through GPUPDATE), the policy settings are deleted and then reset. During this period, the configuration on the server is temporarily valid. Therefore, all sessions may be disconnected

Because we were enabling remote desktop through GPO, this was the exact issue we were having.  We could reproduce it by executing gpupdate in a remote desktop session. The disconnection would not occur every time, but every once in a while. To be more precise when enabling remote desktop through group policies (Allow users to connect remotely using Terminal Services ), the following registry key is set:


The workaround suggested in the KB article is to set the registry key fDenyTSConnections below HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server to a value of 0. Basically this is just enabling remote desktop through the registry instead of through the GUI.

If you have to do this on a lot of workstations there are a few options. We first thought to just deploy this using our desktop deployment solution (SCCM). However a colleague of mine had the great idea to just try setting it using group policy preferences. Whenever group policies are being refreshed, everything below HKLM\SOFTWARE\Policies is erased and reset, but group policy preferences operate in an other way. Whenever you set something with group policy preferences, it’s set forever, unless you check the option “remove this item when it is no longer applied”. For some additional information on the differences between GP policy setting and GP preference settings.

Here are also some related topics on the TechNet forums: http://social.technet.microsoft.com/Forums/en/winserverGP/thread/10fb967c-c6c8-480b-8d30-70f0da15cdba and http://social.technet.microsoft.com/Forums/en/winserverGP/thread/cd94ea99-a843-4781-bbcf-7538182511c9


Error Selecting A Certificate When Configuring NPS

Published on Monday, December 20, 2010 in ,

A colleague of mine was trying to configure the NPS (Network Policy Server) role on two Windows 2008 R2 servers (domain controllers) in order to allow the wireless clients to be authenticated. One of the requirements for Protected EAP is a certificate on the server hosting the NPS role. He told me has was seeing a certificate in the personal store of the computer, but he kept receiving the following error: Cannot configure EAP: A certificate could not be found that can be used with this Extensible Authentication Protocol. when trying to select a certificate.


We found out that the NPS role doesn’t like the new Domain Controller Authentication certificate which is supposed to be more or less equivalent to the domain controller certificate from the past.

I’ve configured this a few times in the past, and whenever we were combining the NPS role with a DC I always used the “domain controller” certificate present on the DC. This works just fine. If nobody changed the default auto-enrollment settings in the domain, they should look like this:



A Windows 2008 R2, Enterprise Certificate Authority will have the following templates published by default, I highlighted the relevant ones for Active Directory: Domain Controller, Domain Controller Authentication and Directory Email Replication.


This was different for Standard SKU Windows 2008/2003 Enterprise CA’s, they only had the “domain controller” certificate listed. This was because standard SKU’s couldn’t use V2/V3 templates. You can see the difference in versioning between these templates in the template management mmc. Smaller than 100 means it’s a V1 template:


Here is how the local certificate store of a domain controllers looks like when no auto-enrollment options are configured:


As you can see there’s only one certificate available based on the Domain Controller template. Even without autoenrollment configured a domain controller will try to enroll for such a certificate. This is hardcoded in the domain controller. Just like an EFS client will try to retrieve an EFS certificate. My colleague wasn’t having one certificate though, he was seeing two:


The reason these were enrolled is because auto-enrollment was configured like this:


The checkbox “Update certificates that use certificate templates” enables autoenrollment for issuance of certificates that supersede issued certificates (TechNet: Configure Certificate Autoenrollment). Because both the Domain Controller Authentication and Directory Email Replication templates are configured to supersede the domain controller certificate, a domain controller will no longer have a certificate based on the domain controller template.


The requirements for an EAP certificate are specified in KB814394: Certificate requirements when you use EAP-TLS or PEAP with EAP-TLS. The reason the NPS console doesn’t seems to accept it, is because the Subject is left empty in the Domain Controller Authentication certificate:


I have no idea why they did this, my guess is that they duplicated the domain controller template and forgot to set it. It can be easily set to the domain controller name in a duplicated template:


My advise would be to create a custom template for the NPS servers. This way you can ensure your NPS configuration never becomes invalid because the domain controller certificate is replaced.

P.S. When testing auto enrollment, make sure to execute a gpupdate /force, a gpupdate without the /force doesn’t seem to trigger the auto enrollment process.



FIM SSPR: Password History Enforcement Testing Trickiness

Published on Wednesday, December 15, 2010 in ,

As explained in FIM 2010 SSPR Enforces Password History FIM 2010 can now be configured to enforce the password policies configured in the domain. After implementing this, the first thing you want to do is grab a test account and start testing. You’ll be happy to see the following message after trying to perform a reset with a password which was used before:


It says: “The password you entered does not comply with the security policy. Please choose a new password or check with your system administrator for details on the password policy requirements”.  So you go on and try a different password. One which hasn’t been used in the past of course. Still the above message appears. Now I’ll be damned, my SSPR is broken! But is it?

There seems to be a simple explanation: as stated in KB2386717 (The "Enforce password history" and "Minimum password age" Group Policy settings do not work when you reset the password for a Windows Server 2008 R2-based computer) not only the Password History is enforced, also the Minimum Password Age is enforced. Meaning you can only reset a password once a day for example. In the screenshot I altered this (temporarily) to 0 days so I could reset a password multiple times. But in our actually policy the Minimum Password Age is 1 day, in the screenshot below I temporarily disabled it by setting it to 0.


This is actually a pretty nasty setting when testing SSPR. Well if the error would say “you can only reset your password once a day, please contact an administrator” that would be a lot better. Of course FIM is not to blame here, this is Active Directory. Whenever you try to change your password at the ctrl-alt-del screen, you’ll get the same message popping up. I can imagine you don’t want to give to much information in your errors as to avoid malicious people being pointed in the good directions…


Access Denied Using An Alias

Published on Monday, December 13, 2010 in , , , , ,

To be completely honest this subject has been blogged a lot in the past. However just this Friday I helped a colleague which was having issues setting up DNS aliases for SQL. He seemed to have troubles connecting his Management Studio to SQL. And today I could use the information again when working at a customer which was having issues authenticating to his webserver. So I believe this is still solid information to spread.

So if you hit google with "disableloopbackcheck windows 2008 R2” you get quit some results. And if you search the official KB articles, this registry setting is referenced a lot when dealing with Access Denied errors locally on a machine. All these scenario’s have one thing in common: someone or some service is trying to access a service under an alias and this from on the machine itself.

Simple example scenario: you set up Active Directory Certifcate Services and you choose “pki.contoso.com” as an alias for your Certificate Authority server. After configuring this record in DNS, you try to access this website http://pki.contoso.com/certsrv on the CA itself in vain. After trying to provide correct credentials multiple times it just fails. You are getting that nasty “HTTP Error 401.1 – Unathorized You do not have permission to view this directory or page using the credentials that you supplied”.  Accessing this from a remote workstation using the same credentials works just fine.


If this is your problem, are it sounds similar, then this is your solution:

And the list goes on. The workaround is very easy and active immediately: just create a REG_DWORD called DisableLoopbackCheck below HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa and give it a value of 1

One of the articles actually references the DisableStrictNameChecking registry key. I remember setting this one when accessing a share didn’t worked when using an alias. Must but it’s older brother. Here’s an explanation: kb281308: Connecting to SMB share on a Windows 2000-based computer or a Windows Server 2003-based computer may not work with an alias name The reason we’re probably hearing this one a lot less is because since SMB 2.0 (Windows 2008 and up)  this is no longer required.


OCS 2007 R2 Client: Outlook Update Is Needed Notification

Published on Thursday, December 9, 2010 in

At my company (RealDolmen) we use Microsoft OCS for internal communication. I’ve been using Office 2010 for a while now, and one of the things that bugged me is that the OCS client kept complaining about a required update (KB936864). This is a bit odd as this hotfix is for Outlook 2007 and is not applicable to Outlook 2010. After using my google skils I found the following TechNet thread:


The above notification can be easily fixed with uninstalling the “Microsoft Office Access database engine 2007” software.



Windows 7 & Reverse Lookup DNS Registration

Published on Thursday, December 2, 2010 in

Update [27/06/2013]: new information regarding the topic: Windows 7 & Reverse Lookup DNS Registration [Update]

In my current project we have an Active Directory domain where we use Windows DNS servers with domain integrated DNS zones. For the reverse lookup zones we configured secure only updates. As the DHCP servers in this environment are Linux based we would like the clients to update their PTR records themselves. Updating the PTR records means a client registers his name and IP in the reverse lookup zone.

As we noticed that only Windows 7 workstations with a static IP were being registered we started troubleshooting. As an AD guy I was 100% confident we could get this done using GPO’s. However in the past I have seen strange behavior with the GPO settings below Administrative Templates\Network\DNS client section, and today was just the same. Getting this done is not that obvious.

Below Computer Configuration > Policies > Administrative Templates > Network > DNS Client there is a setting called “Register PTR Records”. One could think that this is pretty easy to configure, enable, throw a gpupdate in and off we go. The setting with some additional info:


Although the policy came through just fine, even after a reboot, my client was not registering his PTR record… So I used my 24/7 available free of charge consultant-helpline called google. I stumbled upon the following topic (http://social.technet.microsoft.com/Forums/en/w7itpronetworking/thread/3a1c9334-54ba-4845-b7c0-ef8ce5454276) where L Ravie Kumar [MSFT] states:

The behavior of Client not registering PTR record by default is modified prior to Windows7 (mostly during Vista time) and is the intended behavior. The Dhcp Server is responsible for performing PTR record registration on behalf of client. Incase if dynamic DNS registration is not enabled on Server (because of which Server doesnot do PTR registration), Client can trigger registration,if "Use this connection's DNS suffix in DNS registration" is selected in adapter properties.

After checking “Use this connection’s DNS suffix in DNS registration” in the advanced TCP/IP settings all went fine. The record appeared in the reverse DNS zone as expected. Even without the above GPO setting configured. I do think you can use the GPO if you want to fine-tune the registration behavior as it contains 3 options.


So all we have to do is implement this in bulk. I haven’t found a way to do this by GPO, I might have missed it though. I thought GPO preferences would be the easiest way, but this setting is located below HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters\Interfaces\{GUID}\RegisterAdapterName and the GUID is different for each system… So no luck there.

The following command can be executed in order the check the required option:

netsh interface ipv4 set dnsservers name="Local Area Connection" source=dhcp register=both

In our environment we deploy all workstations using SCCM so the above is definitely a reasonable solution.


FIM: Updating Set Fails/ Timed Out

Published on Monday, November 29, 2010 in

What I will be describing has been explained before to be honest:

However I want to add some additional context information. The issue I was seeing is that with a FIM Portal setup, which has quit some objects in it’s database, certain actions failed. I got the generic FIM Service error when trying to add some conditions to a dynamic set. The errors you receive might differ. Perhaps it’s the generic “an error has occurred”, or you get “Access denied”, or like shown below: Timed out.


In the Event log some errors are displayed as well:


The Portal cannot connect to the middle tier using the web service interface.  This failure prevents all portal scenarios from functioning correctly. The cause may be due to a missing or invalid server url, a downed server, or an invalid server firewall configuration. Ensure the portal configuration is present and points to the resource management service.

And in the Forefront Identity Manager log:


The description for Event ID 3 from source Microsoft.ResourceManagement cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.

If the event originated on another computer, the display information had to be saved with the event.

The following information was included with the event:

Requestor: urn:uuid:7fb2b853-24f0-4498-9534-4e10589723c4
Microsoft.ResourceManagement.Service: System.NullReferenceException: Object reference not set to an instance of an object.
   at Microsoft.ResourceManagement.WebServices.RequestDispatcher.CreateRequest(CreateRequestDispatchParameter dispatchParameter)
   at Microsoft.ResourceManagement.WebServices.RequestDispatcher.CreateRequest(UniqueIdentifier requestor, UniqueIdentifier targetIdentifier, OperationType operation, String businessJustification, List`1 requestParameters, CultureInfo locale, Boolean isChildRequest, Guid cause, Boolean doEvaluation, Nullable`1 serviceId, Nullable`1 servicePartitionId)
   at Microsoft.ResourceManagement.WebServices.RequestDispatcher.CreateRequest(UniqueIdentifier requestor, UniqueIdentifier targetIdentifier, OperationType operation, String businessJustification, List`1 requestParameters, CultureInfo locale, Boolean isChildRequest, Guid cause, Boolean doEvaluation)
   at Microsoft.ResourceManagement.WebServices.ResourceManagementService.Put(Message request)

The handle is invalid

As Darryl explained, and this is has been added in the troubleshooting guide  as well, you can extend certain timeouts. A general advice: take a backup copy of configuration files you edit. I tend to copy them and change the extension to .dateOfToday.bak or something like that.

For starters we have the web.config for the WSS site hosting the FIM Portal. Typically this is located below c:\inetpub\wwwroot\wss\VirtualDirectories\80\web.config but of course this might be environment specific. If you look for the following part in the web.config you can add “timeoutInMilliseconds” to the resourceManagementClient line.

<resourceManagementClient requireKerberos="true" resourceManagementServiceBaseAddress=
http://fimsvc.contoso.com:5725 timeoutInMilliseconds="360000" />

An other location where you can adjust timeouts is the FIM Service configuration file. This file is typically located in: "c:\Program Files\Microsoft Forefront Identity Manager\2010\Service\” and is called Microsoft.ResourceManagement.Service.exe.config. Look for the following lines:

  <resourceManagementClient resourceManagementServiceBaseAddress="fimsvc.contoso.com" timeoutInMilliseconds="360000" />
  <resourceManagementService externalHostName="fimsvc.contoso.com" dataReadTimeoutInSeconds="180" dataWriteTimeoutInSeconds="180" />

In this example I added dataReadTimeoutInSeconds="180" dataWriteTimeoutInSeconds="180" to the resourceManagementService line as well as timeoutInMilliSeconds=”360000”. This will ensure the FIM Service waits long enough when writing or reading data from SQL. After changing the above configuratin files, make sure to perform an iisreset and a restart of the FIM Service!

Besides modifying these timeouts, it’s also advised to regularly update the statistics and rebuild the indexes of your FIM Service Database. To conclude: a TechNet article with addition information regarding the mentioned parameters: TechNet: Registry Keys and Configuration File Settings in FIM 2010


Waking Sleeping Beauty

Published on Sunday, November 28, 2010 in , , ,

I wanted to test something involving Exchange so I opened my d:\Virtual Machines folder on my system and searched for something with exchange on it. I found MBX01 and booted the VM. Oddly I couldn’t log on using my domain admin. It got an error saying the password was wrong. So I logged on using the local administrator. In the event viewer we can see that the machine has been offline for a year + 7 days. However according to AskDS: Machine Account Password Process a machine which is offline for a long period of time should be able to connect to the domain without issues.  Either way, if you got the following events in your event log:


NETLOGON, Event ID 3210

This computer could not authenticate with \\DC01.home.local, a Windows domain controller for domain HOME, and therefore this computer might deny logon requests. This inability to authenticate might be caused by another computer on the same network using the same name or the password for this computer account is not recognized. If this message appears again, contact your system administrator.

GroupPolicy, Event ID 1129

The processing of Group Policy failed because of lack of network connectivity to a domain controller. This may be a transient condition. A success message would be generated once the machine gets connected to the domain controller and Group Policy has succesfully processed. If you do not see a success message for several hours, then contact your administrator.

TerminalServices-RemoteConnectionManager, Event ID 1067

The terminal server cannot register 'TERMSRV' Service Principal Name to be used for server authentication. The following error occured: Access is denied.

Then I would suggest you reset the machine account password as a possible solution. KB325850: How to use Netdom.exe to reset machine account passwords of a Windows Server domain controller has a nice explanation on how to perform this procedure. The following command can be used:

netdom resetpwd /s:dc01.home.local /ud:home\tvl /pd:*

The command is run on the server which is having issues and the dc01.home.local is a reachable DC. home\tvl is a user with enough privileges in AD to reset the password for the given computer. /pd:* will ensure the command prompts for the password. To finalize the procedure, reboot the server.


As a possible alternative solution: you can re-join the server to the domain. I prefer the password reset though, seems cleaner. When rejoining a server to the domain I like using the following trick: instead of the traditional workgroup,reboot, domain & reboot again, I just change the FQDN of the domain into the NetBIOS name of the domain. Hence I only have to reboot the server once and the server never left the domain…



FIM: Troubleshooting Codeless Provisioning

Published on in

One of the coolest features in FIM 2010 is the declarative provisioning. It allows you to do a lot of things by simply clicking together the desired items from within the Portal. The alternative is the “classical rules extensions”. This requires writing .net code to extend the possibilities of an MA. I prefer the declarative provisioning. I’m not saying you should abandon classical all the way though. I’m using the following logic to decide between them:

  1. Can it be done from within the Portal (using normal Synchronization Rules)
  2. If not: can it be done by writing a rule extension to be used in the MA
  3. If not: can it be done by writing a workflow to be used in the Portal

I’ve never done 3 to be honest. Most attribute flows and transformations I can manage by defining flows in the Portal. Creating a unique account name I do with a rules extension. I tend to take the best of two worlds. Some people, often seasoned MIIS/ILM folks, still prefer to use classical rules extensions because of the debugging options. I can’t blame them, with the declarative rules you’re sometimes left alone in the dark. So here are some checks to do when your MA of choice is just refusing to show those “provisioning adds” you desire.

This is how it looks when it’s not working, you run your import and synchronization profiles and no “provisioning adds” are being shown. All you see is some EAF’s back to FIM flowing “Not applied” for the “SynchronizationRuleStatus” attribute. And then you say: What, Not applied? Why? How? It sure as hell isn’t my fault, I did it all by the book!


So here is my list of things to check when it’s just not working. It’s not rocket science, but you might have that “Aaah” moment with one of these.

1. Did you check “Create resource in external system


2. Do you have at least one “Initial Flow Only” flow configured? Even if you want to have all attributes flowed all the time, you should have at least one “Initial Flow Only” flow. Just add the same flow twice and check it once to have the desired effect if you want the attribute to be flowed always.


3. Is the Outbound Synchronization Rule being added to the object? If it’s not, it’s very likely something is wrong with the definition of the MPR. Or your object isn’t part of the correct set. Or it was already part of set before you created the MPR. Run on policy update might help you here. Verify the provisioning tab of the object:

No SR present:


SR pending:


4. Is the ERE present in the ExpectedRuleList attribute for the object in the Connector Space (CS) of the FIM MA? If it’s not, something is wrong with the import or the selected attributes of the FIM MA.


5. Is the ERE present in the ExpectedRuleList attribute for the object in the Metaverse? If it’s not, something is wrong with the synchronization or IAFs of the FIM MA.


6. Did you enable "Synchronization Rules Provisioning” in the Options for the Synchronization Manager. If it’s not checked, declarative provisioning will be disabled.


If you got all these covered, you should see the desired result:


And the update of the SynchronizationRuleStatus attribute:


This post was writing after providing all of the above as possible solutions for the following thread: http://social.technet.microsoft.com/Forums/en-US/ilm2/thread/1aa13147-e16c-4e99-a7da-76e3c9e8c10d


FIM: Enforce Uniqueness For Attribute In Portal

Published on Wednesday, November 24, 2010 in

One of the problems you might have is that you want to restrict your Portal Users/Admins to enter the same value twice for a given attribute. Examples might be the account name or employee id. Jorge has a nice article on how to configure this: http://blogs.dirteam.com/blogs/jorge/archive/2009/12/10/checking-uniqueness-of-an-attribute-in-fim-2010-during-the-create-process.aspx

One of the remarks was that this only works for Resource Control Display Configurations (RCDC’s) in create mode. However on the forum (http://social.technet.microsoft.com/Forums/en-US/ilm2/thread/cc51ca7a-908c-40bf-ae10-f47711dd321b) I read that  it would also work in edit mode. So I went ahead and tested. After clicking a user and trying to alter the Account Status (a non-unique enforced attribute) I get the alert for the Account Name attribute (unique-enforced in the RCDC). So it seems that however when only changing one attribute in edit mode, all attributes are checked anyhow. I guess that’s the reason why using the “UniquenessValidationXPath” is not supported/does not work for RCDC’s in edit mode.


Conclusion: RCDC’s cannot enforce the uniqueness of an attribute in edit mode.

Related topics:


WSS Killer Security Update

Published on in

As I was toying with RCDC’s in my lab environment I was performing iisresets occasionally. Never had any issues. However when implementing my changes in the Acceptance environment one of the nodes of my FIM Portal servers failed to display the portal after an iisreset. Luckily Jorge blogged about this in June, and I remembered the article. The article of Jorge:

I went on and checked the installed hotfixes, and the one mentioned by Jorge (KB983444) wasn’t there:


However I saw that a new hotfix became active at the time (day) of my iisreset: KB2345304. It’s pretty clear this hotfix supersedes the previous one. It also mentions this exact issue in the KB article so the solution presented by Jorge still works. Just wanted to warn people out there, this hotfix sneaks in with WSUS/SCCM distributed updates and still seems to cause troubles like in June. My advise would be to install it during the build of your FIM Portal servers although I’m not sure whether a following hotfix won’t possibly break it again…

Thomas, who killed my WSS?!, Vuylsteke

P.S. Not 100% sure if it’s related, but the “SharePoint Services Search Refresh” time job was suddenly enabled again at the same time the hotfix came active… This caused an error and warning every 5 minutes in the event log… This can be disabled in the central administration: operations: timer job definitions section.


FIM SSPR: Password History Enforcement Implementation: SSL Error

Published on Monday, November 22, 2010 in ,

This post is intended for those stumbling upon this exact error. It’s not particular hard to troubleshoot if you watch the System Event log on the FIM Synchronization Server. There’s no AD integrated Certificate Authority in the lab environment where I’m implementing the enforcement of password history. Therefore trusting the root CA, which issued the certificate for the DC, has to be done manually. If you don’t add the certificate of the root CA to the trusted root certificates on the FIM Synchronization Server, the following errors will be shown:

In the Application Log: FIMSynchronizationService Event ID 6328

The server encountered an error while attempting to perform a set/change  password operation.
"BAIL: MMS(2528): dnutils.cpp(1329): 0x800700b7 (Cannot create a file when that file already exists.): Cannot add partition DC=DomainDnsZones,DC=contoso,DC=com to the list because it already exists at position 15
BAIL: MMS(2528): dnutils.cpp(1329): 0x800700b7 (Cannot create a file when that file already exists.): Cannot add partition DC=ForestDnsZones,DC=contoso,DC=com to the list because it already exists at position 16
ERR: MMS(2528): utils.cpp(907): Failed getting registry value 'ADMADoNormalization', 0x2
BAIL: MMS(2528): utils.cpp(908): 0x80070002 (The system cannot find the file specified.): Win32 API failure: 2
BAIL: MMS(2528): utils.cpp(963): 0x80070002 (The system cannot find the file specified.)
ERR: MMS(2528): session.cpp(1502): ldap_connect (timeout= secs and  usecs) failed
BAIL: MMS(2528): session.cpp(1504): 0x8007003a (The specified server cannot perform the requested operation.)
BAIL: MMS(2528): admaexport.cpp(2683): 0x80231109 (Cannot connect to the server you have specified.)
ERR: MMS(2528): admaexport.cpp(3160): Unable to set the password.
BAIL: MMS(2528): admaexport.cpp(3168): 0x80231109 (Cannot connect to the server you have specified.)
ERR: MMS(2528): ma.cpp(9099): ExportPasswordSet failed with 0x80231109
Forefront Identity Manager 4.0.3561.2"



And in the System Log: Schannel Event Id 36882

The certificate received from the remote server was issued by an untrusted certificate authority. Because of this, none of the data contained in the certificate can be validated. The SSL connection request has failed. The attached data contains the server certificate.



FIM Build Overview

Published on Friday, November 19, 2010 in

The FIM team did it’s best the past few days to put some KB articles out there making the hotfixes available and perhaps even more important explaining what was fixed and which features were added!

build 4.0.2592.0 (RTM)

build 4.0.3531.2 (Update 1): http://support.microsoft.com/kb/978864/

build 4.0.3547.2: http://support.microsoft.com/kb/2028634/

  • Several fixes
  • Alternative to DirSync permissions for AD MA account: “ADMAUseACLSecurity” registry key
  • Adds back a checkbox on the AD MA to enable an account to be unlocked when a password is synchronized
  • CPU usage remaining at 98% after AD MA doing exports

build 4.0.3558.2: http://support.microsoft.com/kb/2272389

  • Several fixes
  • SSPR QA gate can be extend with a link to the data policy of the organisation through the use of the “PrivacyLink” registry key
  • Attribute precedence/recall with the FIM MA now works as it should

build 4.0.3561.2: http://support.microsoft.com/kb/2417774

  • Several fixes
  • Support to apply the password history policy

build 4.0.3573.2: http://support.microsoft.com/kb/2417774

  • Several fixes
  • Support to apply the password history policy
  • Solved the export-change-not-reimported issue when the recycle bin is enabled
  • Asynchronous export for FIM MA

P.S. all rollups are cumulative so you don’t have to install them all. Just pick RTM and your build of choice.

I’m definitely awaiting for a fix for the group membership issue with the recycle bin turned on.

[Update 1/02/2011] Made some changes to include the latest build (4.0.3573.2)

[Update 27/03/2011] I will not be updating this blogpost any more. For the latest FIM 2010 build info check: TechNet Wiki Article: FIM 2010 Build Overview


FIM SSPR: QA Gate Policy URL

Published on Thursday, November 18, 2010 in ,

As mentioned by Anthony in the following topic on  the TechNet forums: FIM Password Client Branding? there is a new setting made available to customize the QA gate. When users are registering for SSPR they have to answers various questions, some might be bothered what will happen with the answers. By setting a registry key you can now explain your policy regarding the SSPR functionality or regarding their answers. I assume you need build 4.0.3561.2 or higher for this to work.

[Update] As stated by Anthony in the comments: build 4.0.3558.2 or higher is ok.

This is how the registration QA looks like without the key set:


This is how the registration QA looks like with the key set:


How to configure this? On each client which has the SSPR add-ins installed you have to create a registry value below the following key:

  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Forefront Identity Manager\2010\Extensions\GatePlugins\45C4D8BB-D34C-453d-8346-C9061A2A1E4C
  • New String (Reg_SZ) with the following name: PrivacyLink
  • The value for the entry: http://yourwebserver/policylocation


You can easily achieve this with group policy preferences, or just use the FIM 2010 Group Policy Templates.

With thanks to Anthony Ho for the formation.


A security package specific error occurred(1825)

Published on Wednesday, November 17, 2010 in , , ,

A while ago I wanted to view the event log of a server. For this task there is no need to log in using remote desktop. However when I fired up the event log viewer and tried to connect to the NetBIOS name of my server I got the following error:


Using remote desktop I could connect just fine to the server. At least that’s what it looked like. Locally I could open the event log without issues. But I saw events which couldn’t possibly be logged on this server. And then it came clear, there was an IP conflict! To be honest it’s a lab environment so these things can happen occasionally.

The reason this fails is because my client (my administration pc) asks AD for a Kerberos Ticket for server x whilst when connecting I’m actually presenting this Kerberos Ticket to server y. This results in a server receiving a ticket encrypted with a password other than it’s own. Result: the above error.

Thomas, we should have updated the CMDB, Vuylsteke


Recovering or Installing an additional FIM Service instance when using Update 1

Published on Tuesday, November 9, 2010 in

One of the possible topologies for the FIM 2010 solution is having your FIM Portal and FIM Service load-balanced across two (or more) servers. In the backend the FIM Service uses the same database for both nodes. However since FIM 2010 Update 1 (KB978864) has been released, installing such a topology got a bit trickier. I will explain the scenario were one node is damaged, no backup exists (woopsie), so we have to re-install the server. In fact this can al be done without data loss as the  data resides on the SQL server in the back. For this scenario I will use a single SQL server as it doesn’t matter. It could be a clustered SQL server as well. The topology to start from is the following:


We got two nodes with the FIM Service/Portal at version RTM + Update 1. This means the database is configured for RTM + Update 1. The version of the FIM Service DB can be found in the table called fim.version in the version column. Now suppose we want to reinstall the second node from scratch.


So we got the server team deploy a shiny new 2008 R2 VM and we take our FIM Service setup, go next, next, use existing database and start installing. And then the setup fails. Oh bloody hell. The error shown is not that obvious but if you dig deeper you’ll see it querying the aforementioned FIM.version table before stopping the install.


So what to do? One of the tips I got over at the TechNet forums, was to install the additional node using a temporary database and afterwards re-run the MSI but choosing the change option and pointing to the original DB. I assume this is the only supported way to change the DB. You could also start editing registry keys, but this is probably not supported. So you start the FIM Service setup and in stead of “using the existing database” you provide a name like “FIM Service TEMP”… Oi, Stop!

The FIM Service install for the initial setup added some jobs to the SQL Agent configuration which are run on a scheduled base. We wouldn’t want anything happen to them! Two of the four jobs are disabled, but these seem to be called from the other two jobs. In the screenshot below you can see them. Make sure to temporary rename them. I appended “REN”. As the jobs call each other by name (I think), this might temporary break those jobs. And then proceed with the installation to the FIM Service TEMP DB.


Now your good to go:


This is how the SQL jobs look like after installing a second FIM Service to the same SQL SERVER. You can can see that the same jobs are added again. I can tell you for sure if you don’t rename those jobs, the only remaining jobs will be those for the FIM Service TEMP DB we installed.


As these jobs have references to the actual database, this would break things for sure.


But we got it all covered and RTM is installed so we can continue updating the TEMP DB to the RTM + U1.


Almost there, just relaunch the FIM Service MSI and choose the change option. It’s now possible to point it to the original shared database and finish the setup without problems.


All we have to do now is deleted the temporary database, deleted the jobs added by installing the temporary FIM Service and rename the old jobs back to normal.

In fact the above scenario is almost identical to installing an additional node. As for installation from the ground up there’s an additional possibility: you can install both servers at RTM level with the same database, and then you’ll be able to upgrade them both to Update 1 without issues. The real issue is that you can’t install an RTM Service to a RTM + U1 database.

I can imagine someone having two FIM Service instances point to the same SQL for a lab and production FIM Service instance. When you want to have 2 FIM Service instances use the same SQL Server you’ll have to do some trickery. First you’ll have to rename the jobs, and afterwards you’ll have to make sure the renamed job reference each other with the new name. Upgrading this to newer versions might even be trickier. So the second issue is that you must pay attention to your SQL jobs when installing an additional FIM Service DB on a SQL Server which already hosts a FIM Service DB.

Note: as for the FIM Synchronization server I was able to install an active/standby (2 node) setup using the same database without the above problems. The FIM Synchronization Service seems to be capable of installing a RTM Sync Service to a RTM + U1 database.