Skip to main content

UAG Basic Customization, Part 1

In one of my previous posts I have referenced a couple of good resources on the subject of UAG customization: 
TechNet resource "Customizing Forefront UAG" is a good starting point, and there’s a book that was just published that covers this very topic – “Mastering Microsoft Forefront UAG 2010 Customization” by Erez Ben-Ari.
Much is possible when it comes to customizing and extending UAG, and this is when you would need to refer to those materials mentioned above and to study them carefully; but in some cases only basic customization may be desired, like changing default logon page (say edit the title and add a standard security banner). This post aims to cover those basic changes. So, let's say we want our default logon page to look somewhat like this:
And here are the things we would need to do:
Please, note that all file locations mentioned in this article are installation defaults and may differ from locations you have selected during the installation.
  • Under C:\Program Files\Microsoft Forefront Unified Access Gateway\von\InternalSite\Languages\ locate an appropriate language file, in our case en-US.xml, and copy it to C:\Program Files\Microsoft Forefront Unified Access Gateway\von\InternalSite\Languages\CustomUpdate.
  • Open en-US.xml file in the \CustomUpdate folder using Notepad and perform the following edits (based on the above sample):
    1. <String id="2" _locID="2"> - desired title 
    2. <String id="4" _locID="4"> - desired system security message
    3. <String id="5" _locID="5"> - desired support information
    4. <String id="1" _locID="1"> - desired password self-service information
  • To change the default message displayed when users log off modify the following:
    • <String id=3" _locID"3"> - desired LogOff message (for example: Thank you for using Company XYZ Remote Access Portal)
  • Save the changes in en-US.xml (remember to always use customization file under \CustomUpdate, and not the original one)

Comments

Popular posts from this blog

Skype for Business and VTC Interoperability

Skype for Business (SfB) has a very, very strong potential, I have written about it in my previous post. I can't think of any other platform that shows as much promise in terms of bridging personal and business communications as well as unifying different modes and mediums. And all of this may have started with a strategic acquisition of Skype by Microsoft in 2011.

That said, the road ahead is not without challenges. For example, interoperability with other platforms. Making SfB work with existing Video TeleConferencing (VTC) systems, many of which represent significant capital investments in organizations' infrastructure, could be of a particular importance.

After reading statements like Skype for Business is based on Session Initiation Protocol (SIP) standards and supports H.264 (MPEG-4 video coding standard) one can come to a quick conclusion that integration and/or interoperability with other VTC solutions is easy or nearly automatic. Unfortunately, the industry is not qui…

PoSh Disable and Move AD Users

A quick and easy way to disable user accounts and move them into designated OU:

Import-Csv "C:\TEMP\users.csv" | ForEach-Object { `      $u=$_."sAMAccountName"; $l="Disabling and moving: " +$u; write-output $l; `      Get-ADUser -Identity $u | `      Disable-ADAccount -PassThru | `      Move-ADObject -TargetPath "OU=Disabled Users,OU=Organization,DC=domain,DC=local"
Input is provided via a CSV file:
users.csv (username) sAMAccountName  jdoe1  jdoe2  jdoe3  jdoe4  jdoe5  

To generate input file run something like this, review and edit as necessary:
Search-ADAccount –UsersOnly –AccountInactive –TimeSpan 180.00:00:00 | `      where {$_.enabled} | `      Get-ADUser | `      select sAMAccountName | `      Export-Csv -Path "C:\TEMP\users.csv"

WordPress displays weird characters

Sometimes after a database conversion (e.g. from MySQL to MariaDB) or due to encoding issues a situation might arise when WordPress is showing weird characters. A quick way of remedying the situation would involve examining the pages to discover a pattern (what characters are being substituted, in the example below the apostrophe was replaced by â€™) then running an queries against the database to reverse the effect. Here's a quick example (common tables that store content):



UPDATE wp_posts SET post_content = REPLACE(post_content, 'Â', '')     UPDATE wp_posts SET post_content = REPLACE(post_content, '’', "'")     UPDATE wp_postmeta SET meta_value = REPLACE(meta_value, 'Â', '')     UPDATE wp_postmeta SET meta_value = REPLACE(meta_value, '’', "'")     
Please, keep in mind that to permanently resolve the issue you would need to get to the root of the problem and may need to adjust encoding, run a databas…