Be careful when renaming files when you put them in CustomUpdate

Remember when you customise any file and place it in CustomUpdate to use the same filename, only appending the trunk name and 1 or 0 (for https or http) to the name and nothing else. If you so change the filename, update the rules in the trunk Advanced Settings URL Set: find the rule that affects the file you changed, copy it (placing it directly below) and modify the new rule to include your filename. GIYF when it comes to Regex++ expressions used in UAG if you are using strange filenames.

You need to modify every trunk if you change a major file like login.asp if they all use that file. If you have a custom naming convention so each trunk has its own version of the file, you might be able to write one rule that matches all your names and use that in each trunk, or you might have to write a rule from scratch on each trunk.

[GIYF: Google is your friend]

(Offtopic) Using RemoteApp - signing a cert for your Terminal Server

Just fixed an annoying, off topic problem with Terminal Services behind UAG

Current Task: Publish a RemoteApp through UAG

Problem: I generated a certificate on my own Windows Server 2008 CA but it is not suitable for use with Remote Desktop

Solution: see http://blogs.msdn.com/b/rds/archive/2010/04/09/configuring-remote-desktop-certificates.aspx

Contains a WMI script that converts the file to be suitable for Remote Desktop. Note the cert must be signed, and in the terminal server personal certificates store

Customising InternalError.asp

If you want to customise InternalError.asp and place a copy in CustomUpdate (as you would with other files) and you change the path of the error page (under the trunk Advanced Settings) to this new file, you will find you get an HTTP 500 error. Remember when entering the path in the Advanced Settings that it (bizarely) requires /InternalSite/CustomUpdate/InternalError.asp

You need to do two things to get this to work

- In the URL Set tab of the trunk Advanced Settings, browse down the rules until you find the InternalSite rule for InternalError.asp. Change the rule from /internalsite/internalerror\.asp to read /internalsite/(customupdate/)?internalerror\.asp
[if you have renamed InternalError.asp, make a copy of the rule above instead of editing it, put it under the one above, and amend the file name too. The out-of-the-box rules do not allow you to change filenames of most files]

- the InternalError.asp page references the files in InternalSite\inc directly. This means that when run it cannot find any of the inc files it needs. The answer is to create a 'symlink' - which is a very UNIXy thing to do but it possible in Windows too. Open a command prompt in Administrator mode, and change directory to [your UAG directory]\von\InternalSite\CustomUpdate. Run the command 'mklink .\inc ..\inc'

Apply your config and this should now work

Adding links to a Portal that point outside (eg Google)

I had a need recently to add links to external sites eg Google onto a UAG portal. I thought it was obvious and it was just me, its really not...

Thanks to Ran who answered with a solution

http://bit.ly/9mCwQ8 {social.technet.microsoft.com}

This can also be used to link between UAG trunks manually

---

Follow these steps:

1. Add a new application to your portal trunk, using the type Other Web App (portal hostname)

2. On the Web Servers step of the Add Application Wizard, in the Addresses list, enter a dummy hostname address

3. On the Portal Link step of the wizard, in the Application URL, delete the automatically created URL and instead enter the actual URL of the external site to which you want to direct your users.

4. Choose YES on the "The application URL is not valid. Illegal server address" error message.

5. Complete the wizard and activate the configuration

Some notes:

- You will get some activation warning messages about the dummy server address you entered in step 2 above not being resolvable.

- You probably should select the option to open this site in a new browser window, otherwise, when accessed, the site will be contained in a frame within the UAG portal, and your users will get a Security Warning if the external application link points to an HTTP address, while your portal is accessed via HTTPS.

HTH,

-Ran

Strange Problem: 500 errors when using Login.asp in CustomUpdate - *FIXED* (Beware of the slashes)

I have a strange issue, that I have logged on the Technet forums (http://bit.ly/9ptWzS) and am logging with MS Support shortly
When you login to a trunk with valid credentials, everything works fine, and you get to the site behind the UAG with no errors.  However logins with invalid credentials to the domain result in a 500 error page - not the Login.asp page you would expect to see saying "Authentication failed" or similar - but a plain page that just has the ASP 500 error text.  Neither is the 500 error page the one that exists in the UAG von folders, and I have disabled IE from showing me a 'nice' version of errors.  The URL in IE when the 500 page is showing is:
https://mytrunk.mydomain.com/uniquesig323ea943fa68b62274545754478452/uniquesig0/InternalSite/Validate.asp
The error text on the page is:
"An error occurred on the server when processing the URL. Please contact the system administrator.
If you are the system administrator please click here to find out more about this error."

Customising UAG - InternalSite / Login.asp

One of the first requirements I addressed was the customisation of the login pages of the site.  Initially, Microsoft support stated that customisation was not permitted, later dismissed by Professional Services, and on the contrary was encouraged by them.

The aim of this post is to give a very high level summary of what I did – the aims of the work were:

o   to corporately brand the page properly and completely remove the UAG branding. 

o   to ensure consistent look and feel to corporate standards

o   to make a first attempt of customising UAG

I then got MS PS to verify how I went about the task to be sure I did it right.

I make a lot of assumptions here about basic knowledge of UAG as I could write forever, but within the first hour or two of customising a deployment these assumptions will be second nature.

Essential skills: good understanding of HTML; javascript and (classic) ASP are a benefit but you can just go around them otherwise

Raison d'etre

So...a new blog starts here.  But why?

I have recently started a project to create a Microsoft UAG deployment, with a specific requirement of delivering reverse proxying of published web sites, but with added security over a TMG solution.  No Direct Access, no Microsoft applications, just proxying.  And infomation on this is thin at best

Many would say that TMG would have acheived what I needed, I won't argue either way here.

But why the blog?  Well, to be honest I needed somewhere to keep information that I have found about UAG, and a blog I hope will allow others to use what I have found.  Microsoft have only a handful of people who understand UAG - though those people are very knowledgable - and I have struggled to get information on getting UAG to work how I want it to.

I have found lots of sites that have valuable information, for both IAG and UAG.  But I also have found a lot of gaps.  When I find a solution to these gaps, I will post it.  When I find a good site, I'll post that too.

With any luck, someone going down the same path as I have will find this reference useful