Tuesday 26 October 2010

Customising the portal is complicated

For info, a summary of my thread on the UAG forums re customising the portal: (http://bit.ly/cXr8kf)

Question: I am trying to customise the layout of the portal pages - I know of the changes in Technet etc to hide the left bar, top har, toolbar etc, but I want to rearrange the look of the whole page. However, I am having an almighty battle with changing the DIVs' positioning in CSS (no help from IE & Firefox layout differences!).

I have spent a couple of hours on this, playing with DIV positioning etc, but not really in huge depth as every change I made caused odd effects. DIVs within tables within DIVs etc...I spent about an hour trying to stop the main content window overflowing off the bottom of the page acheiving only some loss of sanity

Has anyone made wholesale changes to the layout of the Portal? Does it work well or are there gotchas?

And is this beyond the support boundary for UAG (the technet article is unclear on how far you can go)

Ben Ari MSFT: As for supportability, customizations beyond what the documentation instructs are not supported.

Ran MSFT: The boundaries of supported web-content customizations in UAG are actually simple to define: if you can do it in a CustomUpdate customization, then it's supported. Another supported customization is for some very specific resources where the UAG management console allows you to specify a new file, instead of the default one (i.e. the Login and the Error page). Other than these, other changes are not supported. True, there is nothing stopping you from modifying one of the default files that UAG comes with, but besides those changes not being backed-up, and not being replicated across UAG array members, they are also not supported.

Ran MSFT: ... the CSS is customizable via a CustomUpdate folder, and so is the .master file. You can find references to these under the http://technet.microsoft.com/en-us/library/ff607389.aspx section, and to be more specific, customizing the Standard.master file is mentioned in these articles: http://technet.microsoft.com/en-us/library/ee861154.aspx and http://technet.microsoft.com/en-us/library/ee861172.aspx

SuperNaraen: We've had to revamp the layout. Here is our experience.

At first we tried to change the css. It turned out to be very involved. So, we dropped that approach.

Then we tried the other extreme, to completely create our own portal web application that would paint the UAG links (Can't locate the article (by Tom Shinder?) right now, which described how to do it for IAG. We found that article very helpful). We found that we were investing a lot of time getting functionality like logoff, timeout behavior etc that comes bundled with the portal.

We have now settled on a hybrid approach. We published our custom portal web application within the portal frame. We then hid the headers and the navbar from the portal frame completely. This is giving us the best of both worlds.

Issues with .inc files with custom ASP scripts

Another strange one...if you modify an ASP page (eg logon.asp) I found that there can be problems with that script accessing inc files, as the links in the script seem to assume that the inc folder is in the same folder as the script - which of course it is until you make your own version.

What happens is that the script will not find inc files properly when it runs and strange things happen. What it needs is the inc files to not be in von/InternalSite/inc but be in von/InternalSite/CustomUpdate/inc

One answer is to copy all of the files that are in von/InternalSite/inc to a new folder von/InternalSite/CustomUpdate/inc. This fixes the problem nicely. However, when you update a file you need to remember to update it in both places. And UAG will not back this folder up either.

The best answer is to create a soft link (aka symlink in UNIX) in the CustomUpdate folder to the inc folder. What this does is create a link in the file system so rather than have a copy of the inc folder under CustomUpdate you actually have the real folder instead. Google symlinks to understand more about how this concept works

In windows, you use mklink to create a soft link. From the InternalSite folder run the following command

mklink /D ./CustomUpdate/inc ./inc

You should see a new folder in CustomUpdate, which should contain everything in inc. In Explorer it is shown as a shortcut (the folder has a little arrow)