Hiding the UAG portal bar

The UAG portal is designed to let you publish multiple applications using a single public hostname, but many customers need UAG to publish only a single application, or simply don’t want to have the portal visible to their users, and have the users redirected to a specific application immediately after logon. The UAG User interface offers this option in a way that’s easy to see – you select an Initial Internal Application that is other than “Portal”:


Often times, the purpose of using this option is to present the user with an experience that hides UAG as much as possible, and for that, many users will also check-off the option “Display home page within portal frame”:


With this option set, the UAG interface is pretty-much tucked away and concealed, but this has a side effect that needs to be kept in mind. The UAG toolbar isn’t just for looks – it also runs some important scripts that affect the security of the site. For example, it is in charge of showing a notification that the session is about to time-out for inactivity. With it being hidden, the user may not become aware that his session is about to expire, and will only find out when he clicks a link and gets redirected to the login page.


In some circumstances, the result could be even more awkward. For example, if the published app uses frames, then action done in one frame may not affect the others, and so after a session expiry, one frame may remain with “old” content, while the user clicks a link in another frame and gets the UAG login page.

Before I go on and tell you how to get around that, it’s important to realize that hiding the portal frame is not the only way to get rid of it. UAG also supports “application-specific hostname” applications, sometimes referred to as “AAM-Like” applications. The way this works is by having you, the administrator; select a specific public name for one of the applications, and mapping it in DNS to resolve to the UAG Trunk’s public IP. For example, the portal may be published on “https://uag.contoso.com”, with the application published as “https://mail.contoso.com”. You need to configure your DNS to resolve these two names to the same IP, and if your UAG trunk is an HTTPS Trunk, then it’s certificate has to be a wildcard certificate (*.contoso.com) or a SAN certificate.

The application itself needs to be configured accordingly. If this is a generic web application, you need to use the “Other Web App(Application-specific hostname)” template, which has a special setting for you to let UAG know which public hostname this application will use:

clip_image008 clip_image010

When this is done, this is how it works:

As the user types https://mail.contoso.com in his browser, it resolves to the UAG’s external IP, and the request is received by the UAG. However, the request also includes the host-header, which tells UAG that the request was for that specific URL, and not to the portal hostname.

UAG uses the host-header to search it’s list of configured applications to find which one has that configuration, and will then retrieve data from that server (only after completing the login process, though, of course).

For some of the application template, this mechanism is mandatory. For example, CWA publishing and SharePoint publishing require that to be configured this way. You still can access those applications via the UAG portal, but if you look closely, these links actually point to the public hostname you defined. This is really nice, because you have the two options for the price of one – you can let your users access the application via the portal (by clicking on an app link), or directly, by typing-in the public URL. Naturally, they can also go to it from their Favorites folder or from a link that has been emailed to them etc)

Back to hiding the portal frame

As I said, just setting the portal frame to be off has some downsides, but there is another way to get this done. UAG uses CSS to control the way the portal frame looks, and it’s fairly easy to customize it to hide the frame without actually disabling it. This is discussed in the UAG Customization guide, alongside other ways to affect the appearance of the portal. The file in question is called Office.css, and it’s located at <UAG Folder>\Von\PortalHomePage\App_Themes\Office. As is always the case with UAG, you should not edit the original file. To make changes, copy the file to the <UAG Folder>\Von\PortalHomePage\App_Themes\CustomUpdate\Office folder, and then edit the file in CustomUpdate. Once you make a change to the file and save it, the change is applied immediately, so there’s no need to re-activate the configuration on UAG or to log-off/log-on again on the client.

You can make any changes to the CSS style sheet that suits your taste. For example, the style “display:none;” makes an element hidden from view, and changing the position and size styles (top, bottom, left, width, height etc) affects their position on the page. Note that setting the div#topStrip and div#toolbar (the frame is actually comprised of two separate ribbons) to hidden will just turn the top area of the screen to a clean white, but the app will still show-up in the area below it. To make the app stick to the top, you also need to change the location of the div#content element from Top:85px; to Top:0px;. You could move stuff around and even integrate your own unique elements to get your own company’s look-and-feel.

To make the entire frame invisible, you need to hide the following elements, and then move the content piece up, as noted earlier:

· div#topStrip

· div#toolbar

· div#footer

· .contentLeftSideBarCell

· .topLeftMarginGradient

· .topRightMarginGradient

· .bottomLeftMarginGradient

· .bottomRightMarginGradient

With these changes, the only thing you will see after logging in is the application list, or the application you have set as the initial app:


Blog post written by Ben Ari

Comments (2)

  1. Eric Raff says:

    Thanks for the post Ben. I have a follow up question for you on this.

    Our Intranet which is hosted in SharePoint 2010 is our "portal" (relative to the users perspective) as such we never want user to see the UAG portal page.

    In building the UAG Trunk, it does not look like I can have the trunks "Public host name" be the same thing as our intranets name.

    For example users access the intranet (internally) via intranet.example.com.

    We want to publish our intranet externally through UAG.

    I am constrained in UAG on the trunk setup that I MUST define a portal public host name which I make intranet.example.com

    However when I then try and publish the SharePoint 2010 application and set the public host name here, it reports: "AAM applications cannot be published when the host name matches the trunk host name, and the application path contains a forward slash '/'"

    Because of this scenario It appears that I MUST use an alternate name for my UAG Portal (uag.example.com) and then I can publish the SharePoint 2010 application using the intranet.example.com public name.

    If this is all true, then do you see any scenarios where the user could be sent to uag.example.com and be shown the UAG Portal page which is not desired at all. What if I simply did not setup a public DNS entry for uag.example.com to block anyone from ever getting there? Dangerous and "not supported"? 🙂

    Thanks for you input.


  2. lucy says:

    Great post from your hands again. I loved the complete article.
    By the way nice writing style you have. I never felt like boring while reading this article.

    I will come back & read all your posts soon. Regards, Lucy.

Skip to main content