Two utilities may be supplied with the kit that can be used to verify a configuration.
The SmPortalTest (SmPortalTest.exe on Windows) can be used to verify that SmPortal can communicate properly with a SiteMinder Policy Server. SmPortalTest communicates through the tunnel to the PortalTest service, running on a Policy Server.
SmPortalTest takes each of its command line arguments and transmits them to PortalTest. PortalTest merely reverses the passed string and returns it.
A typical execution, on a properly configured site, might look like:
>SmPortalTest abc Returned (4 bytes): "cba"
The string abc is passed and cba is returned. This indicates proper configuration.
A failure might be indicated thus:
>SmPortalTest abc Returned Error Code = -18 Message: "Unable to establish server's IP address"
For suggested solutions to possible error codes, see Connectivity Problems.
The PortalTest library must be installed on each server that you wish to test a tunnel to. Note that the SmTransact library as supplied with SiteMinder does not include a version of PortalTest.
We recommend that each agent configuration be tested using SmPortalTest. This is done by configuring the PortalTest service for each agent (in SmPortal.cfg), in turn, then executing SmPortalTest to make sure that that agent's configuration is valid.
Most arguments passed to SmPortalTest will be sent to the PortalTest library as stated above. However, SmPortalTest recognizes some special command line arguments.
The available arguments will be displayed when -? appears on the command line.
To specify a language other than English to use for error messages, use the ‑L option to specify the ISO code for the language, as in:
SmPortalTest -LFR
To specify a country other than the US to use for error messages, use the ‑C option to specify the ISO code for the country, as in:
SmPortalTest -CCA
Normally, SmPortalTest creates a single connection to the Policy Server and issues each service request to PortalTest on the same connection. This option tells SmPortalTest whether or not each service request (transaction) should be sent on the same connection or on a separate connection.
Isolation can be turned on or off and will affect all transactions appearing after the setting. For example,
SmPortalTest -I+ abc def -I- ghi jkl
will cause SmPortalTest to isolate the abc and def transactions. The ghi and jkl will be processed on the same connection.
There are three arguments that are used for automated testing. The -X option specifies the number of iterations to be used (the default is infinite). The -S option specifies the number of seconds to wait between each transaction and the -T option specifies that automated testing is to be used and can specify the size of each transaction. When using Automated Testing, the isolation setting is honored.
For example,
SmPortalTest -T
will perform automated testing using the default transaction size of 512 bytes. The test will be continued until Control-C is pressed. SmPortalTest will not wait between transactions. Transactions will not be isolated (since this is the default).
SmPortalTest -I+ -X15 -S3 -T256
This command line will perform 15 (the -X option) isolated transactions (the -I+ option), 15 seconds apart (the -S option), using a 256 byte buffer.
There is a 1K limit to the automated testing buffer at this time.
The -Q option can be used to qualify the service name used when referencing the SmPortal.cfg file. If -Q is used, it should be immediately followed by the desired qualifier.
SmPortalTest -Qghost abc -Qranger def
If -Q is used without a qualifier, no qualifier will be used.
SmPortalTest -Qghost abc -Qranger def -Q ghi
SmPortalVfy is a new utility supplied with SmPortal version 5.0 that verifies the entire SmPortal.cfg file. It will only work properly if SmTransact version 5.0 (or later) is installed on the Policy Server.
SmPortalVfy is typically invoked with no command line arguments. It will test each setting in the default SmPortal.cfg file and report the results.
The verification process consists of two phases. First, the utility cross checks all of the configuration to ensure that the settings make sense within the file. If any problems are detected, they are reported and the verification process stops.
The second phase actually tests each setting within the file by attempting to communicate with the component. SmPortalVfy will attempt to communicate with each server, each agent's server (as the agent), and each service (as the agent for each of the agent's defined servers) defined within the file.
SmPortalVfy may not detect that a server is unavailable during its initial checking. This is normal and depends on a number of factors. If a server is unavailable, it will definitely be detected when the agents are checked against that server.
Any error during the communications phase will terminate processing.
SmPortalVfy supports one optional argument that specifies a path to SmPortal.cfg. This can be used to verify a new SmPortal.cfg file before putting it into production.
APSPing is a new utility supplied with SmPortal version 5.0 that can test the connectivity to a single policy server, a service on that server, or an SmTunnel function housed by a service. It will only work properly if the (new) APSTransponder library is installed on the Policy Server.
Copyright © 2014 CA.
All rights reserved.
|
|