I’ve got a setup where an UAG array logs into a remote SQL. I’m still wondering how other people handle the database size. I’ve got a very small SQL agent job which runs once a week and deletes all records older than a month. The size of the database is still pretty large: somewhere around 150 GB. A while ago the job seemed to have problems to finish successfully. We also saw the log file of the database growing to a worrying size: 160 GB. FYI: the database was in simple recovery mode.

Each time I started the job I could see the log file filling up from 0 GB all the way to 160 GB and then it stopped as we set 160 GB as a fixed limit. We did this (temporary) to protect other log files on that volume. Here’s the SQL script (query) used in the cleanup job:

DELETE

FROM FirewallLog

WHERE logTime < DATEADD(MONTH, -1, GETDATE())

As you can see it’s a very simple query. The problem lies in the fact that SQL tries to perform this as one transaction. I hope I get the terminology right btw. A SQL database in simple mode should reuse log space quite fast. If I read correctly, about every minute a checkpoint is issued and it will start overwrite/reusing previously written bits in the log file. Now the problem with my query is that its seen as one large transaction and thus needs to be written away entirely in the log file. Hence the space is not reused during the execution. Here's a script which I found online and which does the job way more gently. In my example WebProxyLog is name of the table I’m targeting.

DECLARE @continue INT

DECLARE @rowcount INT

SET @continue = 1

WHILE @continue = 1

BEGIN

--PRINT GETDATE()

SET ROWCOUNT 10000

BEGIN TRANSACTION

DELETE FROM WebProxyLog WHERE  logTime < DATEADD(MONTH, -1, GETDATE())

SET @rowcount = @@rowcount

COMMIT

--PRINT GETDATE()

IF @rowcount = 0

BEGIN

SET @continue = 0

END

END

This script will have the same outcome, but it will delete records in chunks of 10.000 records at a time. This way each transaction is limited in size and the SQL server can benefit from the checkpoints being issued and can thus reuse database space. Using this approach my logging space was somewhere between 0 and 7 GB during the execution of this task. The ideal value for the maximum amount of records deleted at once might differ depending on your situation. I tend to execute this on calmer moments of the day and thus a bit of additional load is not that worrying.

Bonus tip:  you can easily poll for the free space in the log files using this statement:

DBCC SQLPERF(LOGSPACE);

GO

For a customer of mine we’ve setup a UAG which is configured as a Relying Party of an AD FS 2.0 server. This means the trunk itself is configured to use ADFS as it’s authentication server. It seems that upon accessing any application of this trunk we are redirected to the AD FS server, as expected, but UAG greets us with an error page containing "The URL you have requested is too long." For this setup we are publishing the AD FS server over that exact same trunk. So to be more precise, UAG is acting as an AD FS proxy as well.

UAG version in place: UAG 2010 SP3 U1

Here's some more background information regarding this specific issue: TechNet: UAG ADFS 2.0 Trunk Authentication fails: The URL you have requested is too long.

The error:

In words:

The URL you have requested is too long.

Navigate back and follow another link, or type in a different URL.

In the end we opened up a case with Microsoft and they came back with this registry key:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\WhaleCom\e-Gap\von\UrlFilter]
"MaxAllHeadersLen"=dword:00020710

In order to properly apply this setting:

• Set the key
• Activate the UAG configuration
• Perform an IIS Reset

The actual value is for testing only, for a real production environment I would start with 8192 (bytes), watch out, the key is in HEX, and slowly move up until I feel I have a confortable marge.

Lately I had to reinstall a UAG server which is part of a two node array. The OS disk got corrupted somehow so a reinstall was necessary. When I wanted to rejoin the newly installed server to the UAG array I got the following error: “This server cannot join the array.” The procedure to add a UAG server to an array is explained in detail here: TechNet: Joining a server to an array

Whilst the procedure is very basic, it’s really important you don’t miss these items:

• Do not join a server to an array during Forefront UAG installation using the Getting Started Wizard.
• Ensure that the Forefront UAG Management console is closed on the array manager server

Also you might have to start some TMG services which are stopped during the initial (failed) attempt to join the array. This article is rather short and if you follow the documentation carefully you shouldn’t run into it. But somehow I did and I couldn’t find much for this error message. So here it is for future reference.

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&amp;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.

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.

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.

A few days ago I was setting up an UAG which has a trunk configured with anonymous authentication so that I could publish our FIM Self Service Password Reset page. I think I tried to outsmart UAG because this was I was getting over and over again:

In words: 500 – Internal server error.

I said to myself “how hard can it be?!”. After some time I started thinking that removing the default Portal entry which is added to the trunk wasn’t a good idea. I didn’t need it as my users will go directly to the SSPR site, but it seems like UAG needs it very badly! Just re-add it, activate the config and everything should start working.

To conclude: even if you don’t need it, better leave it in place.

Very recently I started toying around with UAG (Unified Access Gateway)  2010. Right after installing and following step 1 of the wizard (select your Internal Network) I decided to change my subnets. Changing network adapters to another subnet is easy, however my UAG configuration fun was halted for some reason:

In words:

The UAG configuration cannot be retrieved from Forefront TMG storage. An error has occurred and UAG will close. Check that TMG services are running. If the UAG server is a domain member, verify connectivity to the domain controller.

Luckily I know TMG (Threat Management Gateway). The UAG manages this TMG instance for you by letting you complete various wizards. I couldn’t access the UAG console but the TMG console launched just fine. This allowed me to change the Internal Network definition:

After a reboot I was able to launch the UAG console. Promptly it presented me the following question:

In my opinion that should rather be an OK box than a yes/no prompt as the no option sounds rather unpleasant…

And now we’re off the discover what’s UAG all about!