I’ve been testing an UAG setup where the trunk is either authenticated using Active Directory or Active Directory Federation Services. For this particular setup I had both configured some months ago. Now I wanted to reconfigure my trunk from AD to ADFS again. When I tried to activate the configuration  I was greeted with the following error:

In words: Failed to run FedUtil from location C:\Program Files\Microsoft Forefront Unified Access Gateway\Utils\ConfigMgr\Fedutil.exe with parameters /u "C:\Program Files\Microsoft Forefront Unified Access Gateway\von\InternalSite\ADFSv2Sites\secure\web.config".

In the event log I saw the above error. Now I started trying the most obvious things like a reboot, but all in vain. I also tried creating a completely new trunk, but that didn’t work out either. Finally I started thinking that some patch was being uncool. I verified the updates and I saw a patch round had occurred a few days ago. I uninstalled all patch from that day, and after a reboot I was able to activate the configuration again! Now you’re probably hoping for me to tell which specific patch is being the culprit? Well for now I don’t know that yet… But here’s the list of patched I uninstalled:

• http://support.microsoft.com/?kbid=2524478
• http://support.microsoft.com/?kbid=2603469
• http://support.microsoft.com/?kbid=2604115
• http://support.microsoft.com/?kbid=2608658
• http://support.microsoft.com/?kbid=2621146
• http://support.microsoft.com/?kbid=2621440
• http://support.microsoft.com/?kbid=2637518
• http://support.microsoft.com/?kbid=2639308
• http://support.microsoft.com/?kbid=2647753
• http://support.microsoft.com/?kbid=2653956
• http://support.microsoft.com/?kbid=2655992
• http://support.microsoft.com/?kbid=2656373
• http://support.microsoft.com/?kbid=2656411
• http://support.microsoft.com/?kbid=2658846
• http://support.microsoft.com/?kbid=2659262
• http://support.microsoft.com/?kbid=2667402
• http://support.microsoft.com/?kbid=2676562
• http://support.microsoft.com/?kbid=2677070
• http://support.microsoft.com/?kbid=2679255
• http://support.microsoft.com/?kbid=2685939
• http://support.microsoft.com/?kbid=2686831
• http://support.microsoft.com/?kbid=2690533
• http://support.microsoft.com/?kbid=2691442
• http://support.microsoft.com/?kbid=2698365
• http://support.microsoft.com/?kbid=2698707
• http://support.microsoft.com/?kbid=2699779
• http://support.microsoft.com/?kbid=2705219
• http://support.microsoft.com/?kbid=2709630
• http://support.microsoft.com/?kbid=2709715
• http://support.microsoft.com/?kbid=2709981
• http://support.microsoft.com/?kbid=2712808
• http://support.microsoft.com/?kbid=2719857
• http://support.microsoft.com/?kbid=2719985
• http://support.microsoft.com/?kbid=2729094
• http://support.microsoft.com/?kbid=2731847
• http://support.microsoft.com/?kbid=2732052
• http://support.microsoft.com/?kbid=2735855
• http://support.microsoft.com/?kbid=2741355

There are a lot…. Good luck! I still might have hit something else, but I sure did try a few reboots before actually going the uninstall-patches route… And that one definitely did it for me.

Tip #1 (IIS): appcmd and IIS bindings:

Some more IIS (configuration) awesomeness: you can easily view the bindings for an IIS site using the following command:

• appcmd list site /site.name:”MySite”

Now obviously just viewing isn’t that cool, but you can also set them! This is extremely useful for those environment where you have work according to “Development –> Test –> Acceptance –> Production” or other variances. I hate doing the same task (manually) multiple times.

So here’s how you can “push” your bindings to a site called “MySite” in IIS.

Syntax option #1: just a host header available on all IP’s (*):

• appcmd set site /site.name:”MySite” /bindings:”http://mysite.contoso.com:80”,”http://mysite:80”

Syntax option #2: a host header bound to one specific IP:

• appcmd set site /site.name “MySiite” /bindings:”http/192.168.50.11:80:mysite.contoso.com”,”http/192.168.50.11:80:mysite”

Mind the difference in the bindings parameters syntax: e.g. http:// <> http/

Now what if you want to change one specific binding to an other value?

• appcmd set site /site.name:"MySite" /bindings.[protocol='http',bindingInformation=':80:mysite.contoso.com'].bindingInformation:192.168.50.11:80:mysite.contoso.com

In this example I changed the binding which was listening on all IP address to only listen on a specific IP address.

Or what about adding a binding witouth modifying existing bindings?

• appcmd set site /site.name:"MySite" /"+bindings.[protocol='https',bindingInformation='192.169.16.105:443:mysite.contoso.com’]

P.S. appcmd is an executable which you can find in the c:\windows\system32\inetsrv directory.

Tip #2 (SQL), is SQL Full Text Search installed?:

One of the prerequisites when installing the FIM Service is that the SQL Full Text Search feature is installed on the SQL Instance hosting your database. There’s two easy ways to see if this is the case:

• Using the services.msc mmc: check if there’s a service name SQL Server FullText Search ([instance]) where [instance] will be the name of your instance
• Using the following SQL query: IF (1 = FULLTEXTSERVICEPROPERTY('IsFullTextInstalled')) print 'INSTALLED' else print 'NOT INSTALLED'

My source: serverfault.com: How to detect if full text search is installed in SQL Server

Tip #3 (Visual Studio): auto-increment version info:

When you create a class in C# or your preferred language you might want to have some version information on the DLL you build. There’s an easy way to configure your solution/project to auto-increment the build version every time you compile your project.

You can do this by directly editing the AssemblyInfo.cs below the properties.

// Version information for an assembly consists of the following four values:
//
//      Major Version
//      Minor Version
//      Build Number
//      Revision
//
// You can specify all the values or you can default the Build and Revision Numbers
// by using the '*' as shown below:
// [assembly: AssemblyVersion("1.0.*")]
[assembly: AssemblyVersion("1.0.*")]
//[assembly: AssemblyFileVersion("1.0.0.0")]

In words: make sure to set the AssemblyVersion to something like “1.0.*” or “1.0.0.*” and comment the AssemblyFileVersion line. As I tested around a bit I noticed the following things:

• the AssemblyFileVersion does not work with the *
• If the AssemblyFileVersion is not commented the AssemblyVersion is ignored and the AssemblyFileVersion “wins”.

Some more background information:

• Marc Charbonneau’s Blog: Auto-incrementing build numbers in Visual Studio
• stackoverflow.com: How to have an auto incrementing version number (Visual Studio)?
• MSDN: AssemblyVersionAttribute Class

Tip #4 (Certificate Authority): RPC traffic check

Often when playing around with certificates I’m hitting gpupdate like hell in order to retrieve auto-enrollment. But if you want to make sure your CA is actually reachable from a given endpoint over RPC/DCOM you can easily check this using the certutil utility. This utility is available out of the box.

• certutil -ping -config "ca-server-name\ca-name”
• Example: certutil –ping –config “SRVCA01\Customer Root CA”

A while ago I did a basic install of UAG and enabled both Firewall and Web Proxy logging to SQL. I configured a trunk and published an application. Now one month later I checked the size of the SQL database which holds the logging information. It was 1,4 GB… Not really special, but taking into account that during that month I visited the published application like 5 times or so, it’s a lot…

So just out of curiosity I tried finding out if there were any records being logged which I didn’t care about.

In the database I did a select top 1000 rows and just glared at the rule names:

At first sight I saw a lot of [System] rules. To be honest I really don’t care if my UAG servers are accessing the SQL server configured for logging, or if they contact Active Directory for authentication. So I executed the following query:

This would delete all entries related to the logging configured in the TMG System Policy rules. Here’s the size before and after:

Before:

After:

So I only won like 122 MB. Not really as much as I’d expect. After looking at the SQL data some more I executed this query:

This would delete all events logged because the request was denied by the “default deny” rule in TMG. Now the database lost another 880 MB! Now we’re talking!

So it seems to me that a large amount of data is related to the “default deny” rule in TMG. If you feel like you don’t need this information, you could disable the logging for this rule in the TMG console:

However this seems to be impossible:

There’s some articles explaining a way around this, but I don’t like those. In troubleshooting times you might want to have logging enabled again for this rule. I feel more like setting a checkbox then start importing and exporting the configuration of a TMG server in a production environment. Here’s an example of an article explaining how to alter the default rule: ISAServer.org: Tweaking the configuration of Forefront TMG with customized TMG XML configuration files

So what I did, for now, is to create my own rule which is positioned just in front of the default deny rule. It’s almost exactly the same, but it has logging disabled:

Whether or not this is a good Idea you have to see for yourself. It all depends what you want the logs for. If you want to have statistics about your published applications this might be fine. If you want statistics about the amount of undesired traffic hitting your UAG’s you might want the default behavior. If you still feel you need some but not all of the default deny rule logging here’s some additional idea’s: configure a deny rule in front of the rule we just created, but now configure it to actually log requests. In this rule you can specify to only log requests concerning HTTP(S) traffic. Or only log requests hitting the external interface. This would avoid all the chitchat which is happing on the LAN side.

I configured a FIM 2010 R2 for Self Service Password Reset using Email OTP. This is documented quite well on TechNet. However when my test user provided the OTP and entered a new password he got greeted with an error:

In words: An error has occurred. Please try again, and if the problem persists, contact your help desk or system administrator. (Error 3000)

In order to explain when this issue occurred:

1. I Provided the username
2. I Received the OTP in my mailbox
3. I Entered the OTP in the form
4. I Provided a password in the form
5. I Clicked Next

In order to solve this I tried/verified the following items:

• FIM Password Reset site debug logging (Paul Williams: Troubleshooting the FIM 2010 R2 Password Registration and Reset Portals )
• WMI permissions (my blog: FIM: SSPR: Verify WMI Permissions )
• Added AD MA account to Domain Admin (blunt, but just to see if there’s no permission issue)
• Added FIM Svc account to Local Admin (blunt, but just to see if there’s no permission issue)
• Reboot server/services
• Checked if password management was enabled on AD MA
• Checked if objectSID, accountName & Domain were present in MV
• Check if FIM Service account was member of FIMSyncPwdReset group

Besides the user being confronted with an error in his browser I also noticed the following events in the event log.

• Log: Forefront Identity Manager
• Source: Microsoft.ResourceManagement
• Level: Warning
• Text: System.Workflow.ComponentModel.WorkflowTerminatedException: Exception of type 'System.Workflow.ComponentModel.WorkflowTerminatedException' was thrown.

• Log: Forefront Identity Manager
• Source: Microsoft.CredentialManagement.ResetPortal
• Level: Error
• Text: The error page was displayed to the user.

  Details:

  Title: Error

  Message: An error has occurred. Please try again, and if the problem persists, contact your help desk or system administrator. (Error 3000)

  Source:

  Attributes:

  Details: System.InvalidProgramException: Error while performing the password reset operation: PWUnrecoverableError

• Log: System
• Source: Microsoft.CredentialManagement.ResetPortal
• Level: Error
• Text: Microsoft.IdentityManagement.CredentialManagement.Portal: System.Web.HttpUnhandledException: ScriptManager_AsyncPostBackError ---> System.InvalidProgramException: Error while performing the password reset operation: PWUnrecoverableError

• Log: System
• Source: Microsoft.CredentialManagement.ResetPortal
• Level: Error
• Text: The web portal received a fault error from the FIM service.

  Details:

  Microsoft.ResourceManagement.WebServices.Faults.ServiceFaultException: DataRequiredFaultReason

• Log: System
• Source: Microsoft.ResourceManagement
• Level: Error
• Text: mscorlib: System.UnauthorizedAccessException: Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))

  at System.Runtime.InteropServices.Marshal.ThrowExceptionForHRInternal(Int32 errorCode, IntPtr errorInfo)

  at System.Management.ManagementScope.InitializeGuts(Object o)

  at System.Management.ManagementScope.Initialize()

  at System.Management.ManagementObjectSearcher.Initialize()

  at System.Management.ManagementObjectSearcher.Get()

  at Microsoft.ResourceManagement.PasswordReset.ResetPassword.ResetPasswordHelper(String domainName, String userName, String newPasswordText)

Besides the above entries I also stumbled upon this one:

In words: The program svchost.exe, with the assigned process ID 684, could not authenticate locally by using the target name RPCSS/fimsyncdev.contoso.com. The target name used is not valid. A target name should refer to one of the local computer names, for example, the DNS host name.

Try a different target name.

As far as I could tell this entry did not got logged when a user attempted a reset or when the service got restarted, but it was logged a few times nevertheless.

After seeing this one it finally came clear: I like to use a DNS alias to target the FIM Synchronization Server when installing the FIM Service bits. This makes it easier when I have to activate my cold standby FIM Synchronization server. Typically you got two options for creating an “alias”:

1. An A record
2. A CNAME record

Scenario 1 is very much the preferred scenario when working with web applications. It makes registering your SPN’s way more logic as you just add them to the service account (the application pool identity). However here we have a special version of this scenario. The password reset relies on WMI/DCOM and it should be authenticated to those in order to successfully execute a set password. The WMI/DCOM stuff doesn’t run as a service account, it’s a service which runs under the local system account. Even if I would add my alias as an SPN on the computer account of the active FIM Sync server I would have to modify this SPN when activating my cold standy server.

So long story short: if you feel like using an alias for your FIM Synchronization Server is interesting, use a CNAME. Normally I do in this scenario, but for this specific customer it slipped through and caused me some hours to figure it out.  On the other hand I learned something about DCOM and it’s authentication stuff.