Customization and supportability

As we said before, a significant part of UAG's code is simple text files containing ASP, HTML, JavaScript, and other code. This means that in theory, you can open any of them with a text editor, and change whatever you want. A brave enough person might even attempt to decompile the UAG filter and mess around with that. However, this is not what this book is about, and the intention is not for you to take drastic measures or rewrite the product yourself. While nothing prevents you from changing any file on your own server, UAG was designed with a specific customization framework, which provides a clean mechanism to perform a supported customization.

What this means is that the team who designed the product intended for you to be able to customize certain files, but also that you should not touch any other files (and if that's not clear, most of the ASP pages have a friendly reminder in them too). We will discuss the technical aspects of this in a minute, but the point here is that whatever you do, you should consider the long-term repercussions of changes you make.

The challenge here is that if you change the files that are unsupported for customization, you run the risk of creating a problem with the code, and in that case, Microsoft's support personnel will not be able to decipher your code changes and work around/through them. Even if you are around to explain, they will most likely outright refuse to touch the server. Naturally, if you are a consultant implementing this customization at a customer's site, an issue might creep up weeks or months later, putting your customer in a tight spot.

Another concern is that UAG's own code may change with a future update, overwriting the changes you made or conflicting with them in a way that causes a problem. For example, with the release of SP1 for UAG, one of the default pages changed in a way that caused many servers who had an improper customization to that page to start showing a 500 error upon entry, which basically bricked those servers until the customization was reversed and redone from scratch. If you are an employee, such a situation could be unpleasant, but if you are an external consultant, this may even put you in a legal bind.

In other words, we strongly recommend you plan your work carefully, sticking with supported customizations, and it wouldn't hurt to also develop a detailed test plan. If the task is a contract, it would be also good to include a support plan as well, in case your code needs updating.