One of the things I noticed during my latest UAG project is that users seemed to be redirect to some sort of error page. In short: if they logged on to a SharePoint site published over UAG and then had their session time out, after click “ok”, they’d be presented with the “You have attempted to access a restricted URL” error.

Using the UAG web monitor, I was able to get a more specific error:

A request from source IP address x.x.x.x, user to trunk secure; Secure=1 for application Internal Site of type InternalSite failed because
the URL /InternalSite/SessionTimeout.asp?site_name=secure&secure=1 must not contain parameters. The method is GET.

So I started investigating the URL Set of the trunk where I was seeing the issue. I could indeed see that the rule didn’t not expected (allowed) parameters. The rule in question was for the URL /InternalSite/SessionTimeout.asp

I peeked around, and I found out that the rule /InternalSite/setpolicy.asp had these exact two parameters. This made adding them to our rule pretty easy, just click each parameter and chose the copy (and paste) option.

After pasting the rules we needed to perform some minor modifications:

• Change the rule to Handle (instead of Reject) parameters
• Modify the Existence to Optional

Save and activate the configuration and now your users shouldn’t be presented with this unexpected message.

I’m currently involved in a project where we publish multiple SharePoint sites using UAG 2010. These SharePoint sites require users to be authenticated using claims. These claims are provided from an AD FS 2.0 farm. When we first applied SP2 for UAG in our lab we noticed that our Single Sign On experience was broken. When we visited a SharePoint URL, we expected to be greeted with the UAG logon form followed by the SharePoint site itself.

Here’s the UAG logon form:

However, after choosing login we saw the following login form. It was fixed to our “ADFS” server we defined in UAG. No matter what credentials we entered, we didn’t got past this form.

After reverting the virtual machine its snapshot, yes I took one! ; ) I could see that SSO was working again as expected. So I switched back the snapshot to where SP2 was installed and started troubleshooting. I tried several things, but nothing worked. So in the end we logged a case with Microsoft. One of the things I had tried, and which the engineer asked me to do as well was the following:

This was how I set it up the authentication of one of the SharePoint sites initially:

This is how he asked me to set it up:

After changing this setting, we got rid of the second form, but now we got an additional “basic authentication” login popup…. After sending over some debug logs and so the engineer suggested to revert back the snapshot to before installing SP2 and to try reinstalling SP2. And I still have no idea why, but everything worked after reinstalling SP2.

Bottom line: when publishing a site which uses claims for authentication, you shouldn’t specify AD FS as an SSO server for the published site. The web application will redirect the user to the ADFS service, and UAG handles SSO towards the ADFS service. But with UAG 2010 pre SP2 either approach worked fine so I didn’t questioned this.

Here you can see an other (unrelated) change in the ADFS configuration when using claims based authentication for the UAG trunks. Before you had to explicitly check “allow unauthenticated access to the web server”. After SP2 the check box is gone.

Recently I had a customer where they had a Certificate Authority in a lab environment and one in a production environment. At first sight both seemed to function correctly. However SCOM (System Center Operations Manager, a monitoring solution) was showing various events of application pool crashes for both environments. The application pool belonged to the CA Web Enrollment pages. When investigating the the Event log on those machines we found the following events to be recurring:

In words:

Faulting application name: w3wp.exe, version: 7.5.7601.17514, time stamp: 0x4ce7afa2
Faulting module name: scrdenrl.dll_unloaded, version: 0.0.0.0, time stamp: 0x4a5bc7f2
Exception code: 0xc0000005
Fault offset: 0x000007fef9402594
Faulting process id: 0x10b4
Faulting application start time: 0x01cdee76c8747cfb
Faulting application path: c:\windows\system32\inetsrv\w3wp.exe
Faulting module path: scrdenrl.dll
Report Id: 795f74be-5a8c-11e2-8b2c-005056ac0079

And also:

In words:

A process serving application pool 'DefaultAppPool' terminated unexpectedly. The process id was '4276'. The process exit code was '0xff'.

The events were recurring, but not very exact. Sometimes it was about every 5 minutes, but sometimes it was once an hour, or even once a day. They only thing we could say that it occurred at least once a day. Besides those events, I couldn’t find anything out of the ordinary on those machines. So off to plan B: google gave me this: TechNet Forums: Prolific number of Windows error reports pertaining to 2008 R2 certificate services.

This seemed to match my problem exactly. I tried the suggestion: removed the CA web components/IIS, reboot, reinstalled. Quickly the events reappeared. The Second thing I noticed here was that SCOM was also involved. Of course, it could be the causing it or the one noticing it….  Disabling the SCOM agent didn’t help. So I started digging deeper. I started looking at the IIS logs. I could see that whilst the CA isn’t visited that regularly, still a lot of requests where logged at frequent intervals. The user agent of the request was mentioning SCOM, so it was pretty obvious this was part of some monitoring configuration.

I asked the guy responsible for SCOM, and besides the regular host based monitoring, they also added URL monitoring (for /certsrv). After disabling this URL monitoring the events stopped occurring. So somehow SCOM doesn’t plays to nice with its requests. I’m not sure why it causes the application pool to crash, maybe it’s something which has to be fixed on the Certificate Authority side, but I’m glad at least I found out WHAT was causing it!

Recently I came across the following error when trying to import a FIM Synchronization Server configuration:

In words: Failed to connect to the specified database. The extension operation aborted due to an internal error in FIM Synchronization Service.

Not only was I seeing this when importing the configuration, but also when manually trying to create a FIM MA. Whilst it says it has problems trying to connect, it has nothing to do with either the database or FIM Service base address. Even filling in random stuff results in this error immediately. So something had to be wrong with the Synchronization Service or the management console.

The odd thing was that I didn’t had this error when migrating from Development to Test or Test to Acceptance. So what was off with the Production server?! After a bit of googling I stumbled upon this post:

TechNet Forums: FIM 2010 R2 Error when creating FIM MA

Well I can tell you, I wasn’t going to install .NET 4.0 on the Dev, Test, Acc environment just because a fresh installed FIM server was behaving odd. After looking around on the server and verifying all installed updates I couldn’t find anything specific until I verified the installed software. Seems that somewhere in the staging process of the server the “Microsoft .NET Framework 4 Client Profile” got installed. I didn’t saw it on the other servers, so I went forward, uninstalled, rebooted and voila!

I’m not sure whether a lot of people will stumble on this, but for those that do, I hope this post helps!

In one my current projects I had to configure a TFS deployment for my customizations I wrote for AD FS and FIM. Setting up a deployment (build) in TFS seems pretty straightforward. The most complex thing I found was the xaml file which contains the logic to actually build & deploy the solutions. I picked a rather default template and cloned it so I could change it to my needs. You can edit such a file with Visual Studio which will give you a visual representations of the various flows, checks and decisions. After being introduced to the content of such a file by a colleague of mine I was still overwhelmed. The amount of complexity in there seems to shout: change me as little as you can.

As I have some deployments which require .NET DLL’s to be deployed on multiple servers I had some options: modify the XAML so it’s capable of taking an array as input and execute the script multiple times, or modify the parameters so I could pass an array to the script. I opted for the second option.

My first attempt consisted of adding an attribute of the type String[] to the XAML for that deployment step. In my build definition this gave me a multi valued parameter where I could enter multiple servers. However in my script I kept getting the value “System.String[]” where I’d expect something along Server01,Server02 This actually made sense, TFS probably has no Idea it needs to convert the input to a PowerShell array.

So I figured if I use a String parameter in the build and if I feed it something like @(“Server01”,”Server02”), which is the PowerShell way of defining an array.

Well it did, but not exactly like we want it. The quotes actually screwed it up and it was only available partially in the script. So we had to do some magic. Passing the parameters to the script means you pass though some vb.net code. This is some simple text handling code, and all we need to do for this to work is add some quotes handling magic. Here’s my test console application which tries to take an array as input and make sure I got the required amount of quotes on the output.

Here’s the TFS parameter section where we specify the arguments for the scripts. The magic happens in the “servers.Replace” section. We’ll ensure that quotes “survive” be passed along to the PowerShell script.

String.Format(" ""& '{0}\{1}' '{2}' {3} "" ", ScriptsFolderMapping, BuildScriptName, BinariesDirectory, Servers.Replace("""", """"""""))

In the GUI this goes into the “Arguments” field:

This allows us to configure the build definition like this. Which is actually pretty simple. Just put the array as you’d put it in PowerShell.

P.S. Make sure to either copy paste or count those quotes twice ; )

I’m currently setting up a FIM solution where the users should be preregistered for Self-Service Password Reset (SSPR). Their email address will be managed in a system outside of FIM, and will be pushed to the correct attribute in the FIM Portal: msidmOneTimePasswordEmailAddress. After some googling I quickly realized that in order for the user to be properly registered, flowing the mail attribute wouldn’t be enough. So Register-AuthenticationWorkflow to the rescue! Using this PowerShell cmdlet you can perform the proper registration from within an administrator perspective. In order to automate this, I combined this with a custom PowerShell activity in the Portal. This activity will execute a PowerShell script with some parameters (attributes from the FIM Portal object) upon execution.

The trigger: whenever the msidmOneTimePasswordEmailAddressattribute is modified, the workflow will be executed.

The script (I left out some logging):

Param($domain,$name,$mail)
Add-PSSNapIn FIMAutomation

try{
    $template = Get-AuthenticationWorkflowRegistrationTemplate –AuthenticationWorkflowName "Password Reset AuthN Workflow"
    $usertemplate = $template.Clone()
    $userTemplate.GateRegistrationTemplates[0].Data[0].Value = $maill

    Register-AuthenticationWorkflow -UserName "$domain\$name" -AuthenticationWorkflowRegistrationTemplate $userTemplate
}
Catch {
    $errorDetail = $_.Exception.Message;
}

However calling this script from within a workflow seemed to result in the following error:

Unexpected error occurred when registering Password Reset Registration Workflow for DOMAIN\USER with email address EMAIL, detailed message: The type initializer for 'Microsoft.ResourceManagement.WebServices.Client.ResourceManagementClient' threw an exception.

In the event log I found the following:

In words:

Some where I found a forum thread or a wiki article which suggested you modified the FIM Service configuration file. The file is located in the FIM Service installation folder and is called Microsoft.ResourceManagement.Service.exe. The section we need to modify:

• Before: <resourceManagementClient resourceManagementServiceBaseAddress=”fqdn” / > Depending on your installation it can also be localhost.
• After: <resourceManagementClient resourceManagementServiceBaseAddress=”http://fqdn:5725” / >  Depending on your installation use FQDN or localhost.

After retriggering my workflow I now receive the following error:

In words: GetCurrentUserFromSecurityIdentifier: No such user DEMO\s_fim_service, S-1-5-21-527237240-xxxxxxxxxx-839522115-10842

This is easily resolved by adding the FIM Service as a user in the Portal. I’d make sure it’s filtered in the FIM MA or double check no attribute flows can break this AD Account.

Check the following URLs for some more background:

• TechNet Forums: One Time Password Pre-Registration during account provisioning?
• Microsoft TechNet: Programmatic User Registration

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.