The ACS tool tests applications to ensure that there will not be
monitoring issues such as:
Failures in the monitored application.
Changes in behavior of the monitored application.
Performance degradation during monitoring of the
application
Each rule that ACS tests against is associated with a real
problem that can take place when the monitored object does not pass
the rule discovery scan. The scan is oriented towards finding
signatures considered to be unsafe from a uX compatibility
standpoint. If an application passes the tests, then it is likely
that none of the problems above will occur and the application will
be fully covered by monitoring.
ACS will check applications that are being added for monitoring,
and can also be used to re-check monitored applications. If errors
are found, users can view a Knowledge Base article which describes
the problem, and choose to resolve the issue by applying filters to
avoid encountering the issue while monitoring.
The ACS utility is accessible when either adding applications
for monitoring or to analyze applications that have already been
added:
Adding Applications for Monitoring
On the Application Server with the uX compatible Intercept
Agent is installed:
Start
Programs
AVIcode Intercept Studio
Intercept Management Console
Right-click the 'Web Applications' node
Choose 'Add Web Application' from the menu
The list of valid applications that are enabled for monitoring
through the Intercept Management console will populate the list of
available applications. If the list is long, enter any part of the
name of the element to search for in the 'Search for Applications'
field (search results will be highlighted on the fly as you
type). Select the application to monitor.
Click OK
A pop-up message will appear that notifies you that the
application has been added for monitoring, and that the Application
Code Scan utility will be launched. Please read the
Application Code Scan utility section of this manual for more
information.
Analyzing Applications
In the Application Server with the uX compatible Intercept
Agent is installed:
Start
Programs
AVIcode Intercept Studio
Intercept Management Console
Right-click any application in the list
Choose 'Analyze' from the menu
Click Yes on the confirmation
pop-up that warns that the ACS processing may take some time to
run.
The "Scan results" view at the top of the window shows the list
of rules that were applied to the application. The "Scan results"
view generalizes the results for each rule and determines the
status for each rule:
Success: if all results for the rule are successful
Error: if at least one result has an error status
Warning: if there are no error results and at least one
result has warning status
Information: if there are no errors or warning results and at
least one result has an information status
Unknown: if the scan results view cannot determine a
rule status or the rule result status
For each rule that is applied, a View link is provided for viewing the associated
Knowledgebase article that describes the problem that is being
scanned for and how to manually correct the issue.
By clicking on any rule in the "Scan results" view, the
"Incompatible resources" view at the bottom of the window will be
populated with the scan results for that rule. These results
provide the exact file and line number where the problem
occurred.
If errors are found, they may be resolved by removing from
monitoring those specific areas that have issues. Users may do any
of the following to resolve issues:
Select the Resolve link for
specific rule failures in the "Incompatible resources" pane
Select the Resolve link for any
rule in the "Scan results" pane. This is the equivalent of
selecting Resolve for all results in
the "Incompatible resources" pane
Click the Disable uX monitoring for
this application button, which will remove the application
from the list of monitored applications
The scan report may also be saved for future analysis in XML
format via the Save scan report
button.
Scan Rules Knowledge Base
Knowledgebase for rule: Client scripting code overrides
standard objects/functions
The potential incompatibility issue found: "The
Application client code contains override(s) of standard
objects/functions"
Description: Overriding
standard objects or methods may cause issues with uX
compatibility
Severity level: Warning
Critical environments:
N/A
Resolution/Mitigation options:
General: It is highly
recommended to review the application code that is considered to be
incompatible.
You have the option to disable uX Monitoring for the
application to prevent the unexpected behavior caused by uX
Monitoring incompatibility.
uX Monitoring can be disabled via the Intercept uX
Management Console or "Disable Application from uX
Monitoring" button in the ACS Utility. The Rule Specific: There are
2 options for handling the potential incompatibility associated
with this particular Rule.
To begin with, you can manually apply a check - see
option A, or you can resolve the potential issues by
choosing option B.
A. Manually check
compatibility: In order to check if a page is compatible or
not, please, do the following.
Produce the steps for first 5 .aspx pages considered to be
incompatible. If no incompatibility issues has been found in the
.aspx files for this rule, try the 5 most popular
application pages:
Ensure that uX Monitoring is turned OFF.
Close all instances of Internet Explorer browser.
Open a single instance of Internet Explorer browser (version
7.0 or 8.0).
Select Menu "Tools" -> "Internet Option" -> "Advanced"
tab page.
Set browser settings (changes take effect after restarting
Internet Explorer):
Enable script debugging.
Enable notifications about every script error.
Navigate to a page, wait for it to load.
Check if errors appeared on the page:
If there are errors, note this fact for the step 12. Typically,
if the application fails without uX Monitoring, the exceptions are
expected to occur with uX Monitoring applied as well.
If there are no errors, go to step 8.
Close all instances of the Intercept uX Management Console
Turn uX Monitoring Client-Side Tracing ON by doing the
following:
Navigate to [drive]\Program
Files\AVIcode\Intercept\Agent\[version-number]\Configuration\Standard\CSM.action.config
(Please note that on x64 installation, the server agent and its
associated configuration files may be found under "Program Files ",
while other components will be under "Program Files (x86)"). Open
the file for editing.
Set the ss: agentDiagnostics tag attrubutes:
Set enable="true".
Set ip and mask corresponding to the client ip/subnet of the
test PC the application pages will be browsed from.
Set ss: appdomains\ss: errorLoggingMode tag attrubutes:
set mode="alert".
Save the changes, close the editor
Launch a single instance of the Intercept uX Management
Console, turn uX Monitoring ON (!!! Pay attention to the
application filter groups. "Client IP Address Filtering" is
expected to be added in order to filter all requests).
Navigate to a page, wait for it to load.
Check that no errors appeared on the page:
Test is PASSED if both/and:
There are no/[the same] errors as were without uX
Monitoring.
Test is FAILED if both/and:
There are [any errors]/[more errors than were without uX
Monitoring].
uX Client Trace Logging notifies that there were calls of
standard functions/constructors:
window.showModalDialog function call.
window.XmlHttpRequest constructor call.
window.ActiveXObject constructor call.
window.alert function call.
window.prompt function call.
window.confirm function call.
!!! A failed test is a reason for
disabling uX Monitoring for the page or even for the whole
application. See option B for details.
B. Disable problem
pages from monitoring: Use the "Resolve" link
in the "Action" column of the entry (corresponding to the
rule in Scan results list) to apply the resolution suggested
for this incompatibility type.
The resolution suggestion is based on the
following:
If there are incompatible resources of the following file
types:
dll - assembly file
master - MASTER page
ascx - web control
js - JavaScript file
... - files hold content of the same types but with
extensions that differ from those mentioned above
, the resolution option will be Disabling uX Monitoring for the
application, because there is no ability to exclude monitoring only
for these particular resources.
If there are 25 or more incompatible resources of the following
file types:
aspx - web page
... - files hold content of the same types but with
extensions that differ from those mentioned above
, the resolution option will be Disabling uX Monitoring for the
application, because applying so many filters in uX Monitoring
configuration may cause some performance overhead for the monitored
application.
Otherwise, the resolution option will be Applying filters in uX
Monitoring configuration not to monitor incompatible pages.
Knowledgebase for rule: Web page contains an ASP.Net
Substitution Control definition
The severe incompatibility issue found: "The
Application pages contain Asp.Net Substitution Control Defined"
Description: The uX Custom
Action uses the Response.Filter property to supply monitoring of
server pages. If a web page contains an ASP.Net Substitution
Control definition, changing the Response.Filter property is
prohibited, because it causes a corrupted response.
Severity level: Error
Critical environments: IIS 7.0
and higher
Resolution / Mitigation options:
General: It is highly
recommended to review the application code that is considered to be
incompatible.
You have the option to disable uX Monitoring for the
application to prevent the unexpected behavior caused by uX
Monitoring incompatibility.
uX Monitoring can be disabled via the Intercept
uX Management Console or the "Disable Application from uX
Monitoring" button in the ACS Utility. The Rule Specific: there are
options to disable monitoring for the incompatible pages or disable
monitoring for the whole application.
Use the "Resolve" link in the
"Action" column of the entry (corresponding to the rule in
Scan results list) to apply the resolution suggested for
this incompatibility type.
The resolution suggestion is based on the
following:
If there are incompatible resources of the following file
types:
dll - assembly file
master - MASTER page
ascx - web control
... - files hold content of the same types but with
extensions that differ from those mentioned above
, the resolution option will be Disabling uX Monitoring for the
application, because there is no ability to exclude monitoring only
for these particular resources.
If there are 25 or more incompatible resources of the following
file types:
aspx - web page
... - files hold content of the same types but with
extensions that differ from those mentioned above
, the resolution option will be Disabling uX Monitoring for the
application, because applying so many filters in uX Monitoring
configuration may cause some performance overhead for the monitored
application.
Otherwise, the resolution option will be Applying filters in uX
Monitoring configuration not to monitor incompatible pages.
Knowledgebase for rule: Web page contains charset changing
instruction
Description: This meta tag is
expected to be the first on the page right after <!Doctype>
and <html> tags. In the case of uX monitoring, the tag
becomes positioned after the uX injected code, so the page
rendering process may become wrong (may slow-down the loading or
have other effects).
Severity level: Warning
Critical environments:
N/A
Resolution/Mitigation options:
General: It is highly
recommended to review the application code that is considered to be
incompatible.
You have the option to disable uX Monitoring for the
application to prevent the unexpected behavior caused by uX
Monitoring incompatibility.
uX Monitoring can be disabled via the Intercept
uX Management Console or the "Disable Application from uX
Monitoring" button in the ACS Utility. The Rule Specific: There are
2 options for managing the potential incompatibility, associated
with this particular Rule..
To begin with, you can apply a manual check - see
option A, or you can always resolve the potential issues by
choosing option B.
A. Manually check
compatibility: In order to check if page is compatible or
not, please do the following.
Produce the steps for first 5 .aspx pages considered to be
incompatible. If no incompatibility issues has been found in
.aspx files over this rule, try the 5 most popular
application pages:
Ensure that uX Monitoring is turned OFF.
Close all instances of Internet Explorer browser.
Open a single instance of Internet Explorer browser (version
7.0 or 8.0).
Select Menu "Tools" -> "Internet Option" -> "Advanced"
tab page.
Set browser settings (changes take effect after restarting of
Internet Explorer):
Enable script debugging.
Enable notifications about every script error.
Navigate to a page, wait for it to load.
Check if there are errors or a slow-down appeared on
page:
If there are errors, note this fact for the step 10. Typically,
if the application fails without uX Monitoring, the exceptions are
expected to occur with uX Monitoring applied as well.
If there are no errors, go to step 8.
Close all instances of the Intercept uX Management Console
Launch a single instance of the Intercept uX Management
Console, turn uX Monitoring ON (!!! Pay attention to
application filter groups. "Client IP Address Filtering" is
expected to be added in order to filter all requests).
Navigate to a page, wait for it to load.
Check that no errors appeared on the page:
Test is PASSED if both/and:
There are no/[the same] errors as were without uX
Monitoring.
Test is FAILED if either/or:
There are [any errors]/[more errors than were without uX
Monitoring].
Page rendering slow-down is experienced.
!!! A failed test is a reason for
disabling uX Monitoring for the page or even for the whole
application. See option B for details.
B. Disable problem
pages from monitoring: Use the "Resolve" link
in the "Action" column of the entry (corresponding to the
rule in Scan results list) to apply the resolution suggested
for this incompatibility type.
The resolution suggestion is based on the
following:
If there are incompatible resources of the following file
types:
master - MASTER page
... - files hold content of the same types but with
extensions that differ from those mentioned above
, the resolution option will be Disabling uX Monitoring for the
application, because there is no ability to exclude monitoring only
for these particular resources.
If there are 25 or more incompatible resources of the following
file types:
aspx - web page
... - files hold content of the same types but with
extensions that differ from those mentioned above
, the resolution option will be Disabling uX Monitoring for the
application, because applying so many filters in uX Monitoring
configuration may cause some performance overhead for the monitored
application.
Otherwise, the resolution option will be Applying filters in uX
Monitoring configuration not to monitor incompatible pages.
Knowledgebase for rule: Web page contains VBScript code
The severe incompatibility issue found: "Web page
contains VBScript code"
Description: uX monitoring
code is JavaScript code. There is couple of issues typical for
pages with mixed scripting language.
Severity level: Error
Critical environments:
Internet Explorer 7.0 and 8.0
Resolution / Mitigation options:
General: It is highly
recommended to review the application code that is considered to be
incompatible.
You have the option to disable uX Monitoring for the
application to prevent the unexpected behavior caused by uX
Monitoring incompatibility.
uX Monitoring can be disabled via the Intercept
uX Management Console or the "Disable Application from uX
Monitoring" button in the ACS Utility. The Rule Specific: there are
options to disable monitoring for the incompatible pages or disable
monitoring for the whole application.
Use the "Resolve" link in the
"Action" column of the entry (corresponding to the rule in
Scan results list) to apply the resolution suggested for
this incompatibility type.
The resolution suggestion is based on the
following:
If there are incompatible resources of the following file
types:
master - MASTER page
ascx - web control
... - files hold content of the same types but with
extensions that differ from those mentioned above
, the resolution option will be Disabling uX Monitoring for the
application, because there is no ability to exclude monitoring only
for these particular resources.
If there are 25 or more incompatible resources of the following
file types:
aspx - web page
... - files hold content of the same types but with
extensions that differ from those mentioned above
, the resolution option will be Disabling uX Monitoring for the
application, because applying so many filters in uX Monitoring
configuration may cause some performance overhead for the monitored
application.
Otherwise, the resolution option will be Applying filters in uX
Monitoring configuration not to monitor incompatible pages.
Knowledgebase for rule: Web page contains compatibility view
changing instruction
Description: This meta tag is
expected to be the first on the page right after <!Doctype>
and <html> tags. In the case of uX monitoring, the tag
becomes positioned after the uX injected code, so the page
rendering process may become wrong (may slow-down the loading or
have other effects).
Severity level: Warning
Critical environments:
N/A
Resolution/Mitigation options:
General: It is highly
recommended to review the application code that is considered to be
incompatible.
You have the option to disable uX Monitoring for the
application to prevent the unexpected behavior caused by uX
Monitoring incompatibility.
uX Monitoring can be disabled via the Intercept
uX Management Console or the "Disable Application from uX
Monitoring" button in the ACS Utility. The Rule Specific: There are
2 options for managing the potential incompatibility, associated
with this particular Rule..
To begin with, you can apply a manual check - see
option A, or you can always resolve the potential issues by
choosing option B.
A. Manually check
compatibility: In order to check if page is compatible or
not, please do the following.
Produce the steps for first 5 .aspx pages considered to be
incompatible. If no incompatibility issues has been found in
.aspx files over this rule, try the 5 most popular
application pages:
Ensure that uX Monitoring is turned OFF.
Close all instances of Internet Explorer browser.
Open a single instance of Internet Explorer browser (version
7.0 or 8.0).
Select Menu "Tools" -> "Internet Option" -> "Advanced"
tab page.
Set browser settings (changes take effect after restarting of
Internet Explorer):
Enable script debugging.
Enable notifications about every script error.
Navigate to a page, wait for it to load.
Check if there are errors or a slow-down appeared on
page:
If there are errors, note this fact for the step 10. Typically,
if the application fails without uX Monitoring, the exceptions are
expected to occur with uX Monitoring applied as well.
If there are no errors, go to step 8.
Close all instances of the Intercept uX Management Console
Launch a single instance of the Intercept uX Management
Console, turn uX Monitoring ON (!!! Pay attention to
application filter groups. "Client IP Address Filtering" is
expected to be added in order to filter all requests).
Navigate to a page, wait for it to load.
Check that no errors appeared on the page:
Test is PASSED if both/and:
There are no/[the same] errors as were without uX
Monitoring.
Test is FAILED if either/or:
There are [any errors]/[more errors than were without uX
Monitoring].
Page rendering slow-down is experienced.
!!! A failed test is a reason for
disabling uX Monitoring for the page or even for the whole
application. See option B for details.
B. Disable problem
pages from monitoring: Use the "Resolve" link
in the "Action" column of the entry (corresponding to the
rule in Scan results list) to apply the resolution suggested
for this incompatibility type.
The resolution suggestion is based on the
following:
If there are incompatible resources of the following file
types:
master - MASTER page
... - files hold content of the same types but with
extensions that differ from those mentioned above
, the resolution option will be Disabling uX Monitoring for the
application, because there is no ability to exclude monitoring only
for these particular resources.
If there are 25 or more incompatible resources of the following
file types:
aspx - web page
... - files hold content of the same types but with
extensions that differ from those mentioned above
, the resolution option will be Disabling uX Monitoring for the
application, because applying so many filters in uX Monitoring
configuration may cause some performance overhead for the monitored
application.
Otherwise, the resolution option will be Applying filters in uX
Monitoring configuration not to monitor incompatible pages.
Knowledgebase for rule : Web page has call(s) of
HttpWebResponse.End() method
The potential incompatibility issue found: “Web
page has call(s) of HttpWebResponse.End() method”
Description: The uX Custom
Action uses the Response.Filter property to supply monitoring of
server pages. If user code calls method Response.End(), there could
be problems with a correct content of response returned to
browser.
Severity level: Warning
Critical environments:
N/A
Resolution/Mitigation options:
General: It is highly
recommended to review the application code that is considered to be
incompatible.
You have the option to disable uX Monitoring for the
application to prevent the unexpected behavior caused by uX
Monitoring incompatibility.
uX Monitoring can be disabled via the Intercept
uX Management Console or the "Disable Application from uX
Monitoring" button in the ACS Utility. The Rule Specific: There are
2 options for managing the potential incompatibility, associated
with this particular Rule..
To begin with, you can apply a manual check - see
option A, or you can always resolve the potential issues by
choosing option B.
A. Manually check
compatibility: In order to check if page is compatible or
not, please do the following.
Produce the steps for first 5 .aspx pages considered to be
incompatible. If no incompatibility issues has been found in
.aspx files over this rule, try the 5 most popular
application pages:
Ensure that uX Monitoring is turned OFF.
Close all instances of Internet Explorer browser.
Open a single instance of Internet Explorer browser (version
7.0 or 8.0).
Select Menu "Tools" -> "Internet Option" -> "Advanced"
tab page.
Set browser settings (changes take effect after restarting of
Internet Explorer):
Enable script debugging.
Enable notifications about every script error.
Navigate to a page, wait for it to load.
Check if there are errors or a slow-down appeared on
page:
If there are errors, note this fact for the step 10. Typically,
if the application fails without uX Monitoring, the exceptions are
expected to occur with uX Monitoring applied as well.
If there are no errors, go to step 8.
Close all instances of the Intercept uX Management Console
Launch a single instance of the Intercept uX Management
Console, turn uX Monitoring ON (!!! Pay attention to
application filter groups. "Client IP Address Filtering" is
expected to be added in order to filter all requests).
Navigate to a page, wait for it to load.
Check that no errors appeared on the page:
Test is PASSED if both/and:
There are no/[the same] errors as were without uX
Monitoring.
Test is FAILED if either/or:
There are [any errors]/[more errors than were without uX
Monitoring].
Page rendering slow-down is experienced.
!!! A failed test is a reason for
disabling uX Monitoring for the page or even for the whole
application. See option B for details.
B. Disable problem
pages from monitoring: Use the "Resolve" link
in the "Action" column of the entry (corresponding to the
rule in Scan results list) to apply the resolution suggested
for this incompatibility type.
The resolution suggestion is based on the
following:
If there are incompatible resources of the following file
types:
dll - assembly file
, the resolution option will be Disabling uX Monitoring for the
application, because there is no ability to exclude monitoring only
for these particular resources.
If there are 25 or more incompatible resources of the following
file types:
aspx - web page
... - files hold content of the same types but with
extensions that differ from those mentioned above
, the resolution option will be Disabling uX Monitoring for the
application, because applying so many filters in uX Monitoring
configuration may cause some performance overhead for the monitored
application.
Otherwise, the resolution option will be Applying filters in uX
Monitoring configuration not to monitor incompatible pages.
Knowledgebase for rule: Web page has call(s) of
HttpWebResponse.Flush() method
The potential incompatibility issue found: "Web
page has call(s) of HttpWebResponse.Flush() method"
Description: The uX Custom
Action uses the Response.Filter property to supply monitoring of
server pages. If user code calls method Response.Flush(), there
could be problems with a correct content of response returned to
browser.
Severity level: Warning
Critical environments:
N/A
Resolution/Mitigation options:
General: It is highly
recommended to review the application code that is considered to be
incompatible.
You have the option to disable uX Monitoring for the
application to prevent the unexpected behavior caused by uX
Monitoring incompatibility.
uX Monitoring can be disabled via the Intercept
uX Management Console or the "Disable Application from uX
Monitoring" button in the ACS Utility. The Rule Specific: There are
2 options for managing the potential incompatibility, associated
with this particular Rule..
To begin with, you can apply a manual check - see
option A, or you can always resolve the potential issues by
choosing option B.
A. Manually check
compatibility: In order to check if page is compatible or
not, please do the following.
Produce the steps for first 5 .aspx pages considered to be
incompatible. If no incompatibility issues has been found in
.aspx files over this rule, try the 5 most popular
application pages:
Ensure that uX Monitoring is turned OFF.
Close all instances of Internet Explorer browser.
Open a single instance of Internet Explorer browser (version
7.0 or 8.0).
Select Menu "Tools" -> "Internet Option" -> "Advanced"
tab page.
Set browser settings (changes take effect after restarting of
Internet Explorer):
Enable script debugging.
Enable notifications about every script error.
Navigate to a page, wait for it to load.
Check if there are errors or a slow-down appeared on
page:
If there are errors, note this fact for the step 10. Typically,
if the application fails without uX Monitoring, the exceptions are
expected to occur with uX Monitoring applied as well.
If there are no errors, go to step 8.
Close all instances of the Intercept uX Management Console
Launch a single instance of the Intercept uX Management
Console, turn uX Monitoring ON (!!! Pay attention to
application filter groups. "Client IP Address Filtering" is
expected to be added in order to filter all requests).
Navigate to a page, wait for it to load.
Check that no errors appeared on the page:
Test is PASSED if both/and:
There are no/[the same] errors as were without uX
Monitoring.
Test is FAILED if either/or:
There are [any errors]/[more errors than were without uX
Monitoring].
Page rendering slow-down is experienced.
!!! A failed test is a reason for
disabling uX Monitoring for the page or even for the whole
application. See option B for details.
B. Disable problem
pages from monitoring: Use the "Resolve" link
in the "Action" column of the entry (corresponding to the
rule in Scan results list) to apply the resolution suggested
for this incompatibility type.
The resolution suggestion is based on the
following:
If there are incompatible resources of the following file
types:
dll - assembly file
, the resolution option will be Disabling uX Monitoring for the
application, because there is no ability to exclude monitoring only
for these particular resources.
If there are 25 or more incompatible resources of the following
file types:
aspx - web page
... - files hold content of the same types but with
extensions that differ from those mentioned above
, the resolution option will be Disabling uX Monitoring for the
application, because applying so many filters in uX Monitoring
configuration may cause some performance overhead for the monitored
application.
Otherwise, the resolution option will be Applying filters in uX
Monitoring configuration not to monitor incompatible pages.
Last update: Monday, December 13, 2010
10:36:38 AM
Please read the
Application Code Scan utility section of this manual for more
information.
Success: if all results for the rule are successful
Error: if at least one result has an error status
Warning: if there are no error results and at least one
result has warning status
Information: if there are no errors or warning results and at
least one result has an information status
Unknown: if the scan results view cannot determine a
rule status or the rule result status