<%NUMBERING1%>.<%NUMBERING2%>.<%NUMBERING3%> PRTG Manual: Auto-Discovery
The PRTG auto-discovery is a great way to automatically create a sophisticated and concise set of sensors for your complete network. It is mainly suitable for LAN discovery because it involves a lot of SNMP and WMI.
PRTG already runs a quick initial auto-discovery as soon as you finish the installation of PRTG to automatically show you several available devices in your network.
You cannot use this feature with local probes in PRTG on demand. You can use this feature on remote probes.
How Auto-Discovery Works
The PRTG auto-discovery process has three stages:
- Step 1
Scanning a network segment for devices using Ping (for groups only).
- Step 2
Assessing the device type for all devices discovered in Step 1 (using SNMP, WMI, and other protocols).
- Step 3a
Creating sensor sets that match the discovered device types of step 2. This is done based on built-in device templates with recommended sensors for many device types.
Step 3b (optional)
Creating sensor sets using device templates that PRTG users created (see Create Device Template section).
You can use the auto-discovery on group level for a range of IP addresses, or for individual devices that you have created manually. You can run the auto-discovery just once, on demand via the context menu, or scheduled every hour, day, or week. Running the auto-discovery daily or weekly on group level automatically creates new devices when they are connected to the network and adds according sensors. As soon as PRTG discovers new devices or sensors, it will create notifying Tickets (which are mailed to the PRTG system administrator user by default).
Please be aware of the following restrictions of the auto-discovery:
- PRTG cannot discover devices that cannot be pinged, because Step 1 uses pings. If, for example, a firewall blocks echo requests, PRTG cannot discover a device behind it.
- Please define authentication settings for Windows Systems, Linux (SSH/WBEM) Systems, VMware/XEN Servers, SNMP Devices, Database Management Systems, and Amazon CloudWatch to fully benefit from the power of this feature. We recommend that you define these settings in the Root group.
- If a device has more than one IP address, it may show up more than once in the discovery results, even though PRTG tries to identify these situations.
- If a device already exists on the same probe, the auto-discovery will skip this device and not create a duplicate. If a device with the same IP address as a found device already exists on another probe, it will be added to the probe where the auto-discovery runs nevertheless. This is because new remote probes might run in another network.
- Auto-discovery on group level will not create new sensors on devices that already exist in PRTG but only on newly discovered devices. If you want to automatically add sensors to an existing device, please run the auto-discovery on this device.
- Using frequent auto-discoveries of large network segments can lead to performance issues. Because of this we recommend that you only schedule regular auto-discoveries where necessary. For detailed information, see this Knowledge Base article: Why can automatic auto-discoveries evoke performance issues?
- PRTG automatically adds suitable device icons to discovered devices. PRTG uses a device's MAC address for this purpose, which it determines via ARP (Address Resolution Protocol). This only works via IPv4 and not with IPv6. Usually, ARP works only in the local network unless your router supports ARP and you configure it accordingly.
- If you use Multi-Edit to automatically create sensors using specific device template(s), the Auto-Discovery is not automatically started. To manually start the Auto-Discovery, right-click the individual devices and select Auto-Discovery | Run Auto-Discovery.
HTTP sensors indicate the access type to the target device with their names (HTTP, HTTP (8080), and HTTPS). This approach helps to distinguish HTTP sensors if the auto-discovery adds more than one instance to a device.
Run Auto-Discovery Now
You can run an auto-discovery at any time for a group or a device. To do so, right-click the object to analyze and select Run Auto-Discovery from the context menu. PRTG immediately starts searching for new objects that can be added to the device tree. If you use it for an auto-discovery group, PRTG will add devices with according sensors, if found. If you use it for a device, PRTG will add new sensors, if found. You can always see in the corresponding page header bar when PRTG ran the last auto-discovery on a selected group or device.
The auto-discovery will also re-add devices or sensors you have manually deleted. If you do not want this, please create objects manually only.
Creating an Auto-Discovery Group
There are several ways to start auto-discovery:
- Select Devices | Add Auto-Discovery Group from the main menu bar. To start an automatic detection of devices and sensors in your network an assistant will appear, leading you through two steps.
- For faster setup, you can select Add Auto-Discovery Group... in the context menu of a probe or group to which you want to add the new group. This will skip step 1 and lead you directly to step 2.
This documentation refers to the PRTG System Administrator user accessing the Ajax interface on a master node. If you use other user accounts, interfaces, or nodes, you might not see all of the options in the way described here. If you use a cluster installation, note that failover nodes are read-only by default.
Add Auto-Discovery Group Dialog
- Step 1
Please choose a probe or group you want to add the new group to. Click Continue.
- Step 2
Add auto-discovery settings as described below.
Add Auto-Discovery Group Settings
|
Group Name
|
Enter a meaningful name to identify the group. The name will be shown by default in the devices tree and in all alarms.
|
Tags
|
Enter one or more tags. Confirm each tag by hitting the space, comma, or enter key. You can use tags to group objects and use tag-filtered views later on. Tags are not case sensitive. Tags are automatically inherited.
|
|
Sensor Management
|
Select the method for automatic network discovery. Choose between:
- Automatic device identification (standard, recommended): Detect mainly based on Ping, SNMP, and WMI. This option works fine for most installations.
- Automatic device identification (detailed, may create many sensors): Detect in a more detailed way and create more sensors. This option uses all standard device templates for auto-discovery. It is suitable for small network segments and whenever you want to monitor the maximum number of sensors available.
- Automatic sensor creation using specific device template(s): Manually define the device templates used for auto-discovery. From the list below, select one or more templates.
|
Device Template(s)
|
This option is only visible if you enable using specific device templates above. Choose one or more templates by adding a check mark in front of the respective template name. You can also select and deselect all items by using the check box in the table head. PRTG will use the selected templates for auto-discovery on the current device. Choose from:
- ADSL
- Amazon Cloudwatch
- Buffalo TeraStation NAS
- Cisco ASA VPN
- Cisco Device (Generic)
- Dell EqualLogic
- Dell MDI Disk
- DNS Server
- Environment Jacarta
- Environment Poseidon
- FTP Server
- Generic Device (PING only)
- Generic Device (SNMP-enabled)
- Generic Device (SNMP-enabled, Detailed)
- HTTP Web Server
- Hyper V Host Server
- IPMI enabled devices
- Juniper NS Device
- Linux/UNIX Device (SNMP or SSH enabled)
- Mail Server (Generic)
- Mail Server (MS Exchange)
- Microsoft Sharepoint 2010
- NAS LenovoEMC
- NAS QNAP
- NAS Synology
- NetApp
- NTP Server
- Printer (HP)
- Printer Generic
- RDP Server
- RMON compatible device
- Server (Compaq/HP agents)
- Server (Dell)
- Sever Cisco UCS
- Server IBM
- SonicWALL
- SSL Security Check
- Switch (Cisco Catalyst)
- Switch (Cisco IOS Based)
- Switch (HP Procurve)
- UNIX/Linux Device
- UPS Health (APC)
- UPS Health (Generic)
- UPS Health (Leibert)
- VMware ESX / vCenter Server
- Webserver
- Windows (Detailed via WMI)
- Windows (via Remote Powershell)
- Windows (via WMI)
- Windows IIS (via SNMP)
- XEN Hosts
- XEN Virtual Machines
Once the auto-discovery is finished, PRTG will create a new ticket and list the device templates that it used to create new sensors. The ticket will not show templates that were not applied.
|
Discovery Schedule
|
Define when PRTG will run the auto-discovery. Choose between:
- Once: Perform auto-discovery only once. PRTG will add new devices and sensors once. If you select this option, you have to start the auto-discovery manually, it will not run automatically.
- Hourly: Perform auto-discovery for new devices and sensors every 60 minutes.
Please use this option with caution! Frequently executed auto-discoveries might cause performance issues, especially when large network segments are scanned every hour.
- Daily: Perform auto-discovery for new devices and sensors every 24 hours. The first auto-discovery will run immediately, all other discoveries will start at the time defined in the Auto-Discovery Settings section of the System Administration—Monitoring settings.
- Weekly: Perform auto-discovery for new devices and sensors every 7 days. The first auto-discovery will run immediately, all other discoveries will start at the time defined in the Auto-Discovery Settings section of the System Administration—Monitoring settings.
|
IP Selection Method
|
Define how you want to define the IP range for auto-discovery. Choose between:
- Class C base IP with start/end (IPv4): Define an IPv4 class C address range.
- List of individual IPs and DNS names (IPv4): Enter a list of individual IPv4 addresses or DNS names.
- IP and subnet (IPv4): Enter an IPv4 address and subnet mask.
- IP with octet range (IPv4): Enter an IPv4 address range for every IP octet individually. With this, you can define very customizable IP ranges.
- List of individual IPs and DNS names (IPv6): Enter a list of individual IPv6 addresses or DNS names.
- Use computers from the active directory (maximum 1000 computers): Search in the active directory for computers to perform auto-discovery.
Define your active directory domain in advance in the system administration. See System Administration—Core & Probes.
Only subnets with up to 65,536 IP addresses can be discovered! If you define a range with a higher number of addresses, discovery will stop before it is completed.
|
IPv4 Base
|
This field is only visible if you select Class C network detection above. Enter a class C network as IP base for the auto-discovery. Enter the first three octets of an IPv4 IP address, for example, 192.168.0
|
IPv4 Range Start
|
This field is only visible if you select Class C network detection above. Enter the IP octet of the class C network specified above from which PRTG will start the auto-discovery. This will complete the IP base above to an IPv4 address. For example, enter 1 to discover from 192.168.0.1.
|
IPv4 Range End
|
This field is only visible if you select Class C network detection above. Enter the IP octet of the class C network specified above at which PRTG will stop the auto-discovery. This will complete the IP base above to an IPv4 address. For example, enter 254 to discover up to 192.168.0.254.
|
IPv4/DNS Name List
IPv6/DNS Name List
|
This field is only visible if you select the IP list option above. Enter a list of IP addresses or DNS names which the auto-discovery will scan. Enter each address in a separate line.
|
IPv4 and Subnet (IPv4)
|
This field is only visible if you select the IP and subnet option above. Enter an expression in the format address/subnet, for example, 192.168.3.0/255.255.255.0. You can also use the short form like 192.168.3.0/24 in this example. PRTG will scan the complete host range (without network and broadcast address) defined by the IP address and the subnet mask.
|
IP with Octet Range
|
This field is only visible if you select the octet range option above. Enter an expression in the format a1.a2.a3.a4, where a1, a2, a3, and a4 are each a number between 0-255, or a range with two numbers and a hyphen like 1-127. All permutations of all ranges are calculated. For example, 10.0.1-10.1-100 results in 1,000 addresses that PRTG will scan during auto-discovery.
|
Organizational Unit
|
This field is only visible if you select active directory above. Enter an organizational unit (OU) to restrict the active directory search to computers that are part of this OU. Just enter the name of the OU without any other term (so without "OU" in front). If you leave this field empty, there will not be any restriction.
Make sure that the OU contains a host. If the OU is empty, you will receive an error message.
If you have sub-OUs, consider the correct syntax in the format Y,OU=X: OUs that are part of another OU have to be listed together with their parent(s). Enter the sub-OU followed by ,OU= and the name of the parent OU.
Examples:
- Assuming that the organizational unit 'Y' is part of the OU named 'X'. Then the syntax would be Y,OU=X
- For three OUs 'X', 'Y' part of 'X', and 'Z' part of 'Y', the syntax would be Z,OU=Y,OU=X
The order is important, sub-OUs have to be listed left of their particular parents!
|
Name Resolution
|
Define how to monitor newly discovered devices. This affects only new devices. The setting for existing devices will remain unchanged. Depending on your selection the IP Address/DNS Name field of an added device shows the DNS name or IP address which PRTG uses to access the target device. Choose between:
- Use DNS names (recommended): Monitor newly discovered devices via their DNS names (if available).
- Use IP addresses: Monitor newly discovered devices via their IP address.
We recommend that you use the default value.
This setting does not affect how PRTG shows the devices in the device tree.
|
Device Rescan
|
Define if you want to add devices that already exist in your PRTG installation also to the currently selected group. Choose between:
- Skip auto-discovery for known devices/IPs (recommended): Do not re-scan known devices or IP addresses, only add devices with new IPs or DNS names when auto-discovering. PRTG will not add devices that are already included elsewhere in your configuration, for example, in other groups.
- Perform auto-discovery for known devices/IPs: Re-scan devices with known IP addresses with every auto-discovery. This option will add devices that already exist in other groups also to this group and runs the auto-discovery on the newly added devices.
The auto-discovery will not run on devices that already exist in this group. If you want to run the auto-discovery for an existing device, you have to start the auto-discovery on this device.
We recommend that you use the default value.
|
Inherited Settings
By default, all following settings are inherited from objects higher in the hierarchy and should be changed there, if necessary. Often, best practice is to change them centrally in the Root group's settings. To change a setting only for this object, disable inheritance by clicking the check mark in front of the corresponding setting name. You will then see the options described below.
If you have not set credentials yet, set them now before starting the auto-discovery to fully exploit the power of this feature!
|
Domain or Computer Name
|
Define the authority for Windows access. This is used for Windows Management Instrumentation (WMI) and other Windows sensors. If you want to use a Windows local user account on the target device, enter the computer name here. If you want to use a Windows domain user account (recommended), enter the (Active Directory) domain name here. If not explicitly defined, PRTG will automatically add a prefix in order to use the NT LAN Manager (NTLM) protocol. Do not leave this field empty.
|
User
|
Enter the username for Windows access. Usually, you will use credentials with administrator privileges.
|
Password
|
Enter the password for Windows access. Usually, you will use credentials with administrator privileges.
|
|
User
|
Enter a login name for the access via SSH and WBEM. Usually, you will use credentials with administrator privileges.
|
Login
|
Define the authentication method to use for login. Choose between:
- Login via Password: Provide a password for login. Enter below.
- Login via Private Key: Provide a private key for authentication.
PRTG can only handle keys in OpenSSH format that are not encrypted. You cannot use password protected keys here. In the text field, paste the entire private key, including the "BEGIN" and "END" lines. Please make sure the according public key is provided on the target machine. For details, please see Monitoring via SSH.
|
Password
|
This field is only visible if you select password login above. Enter a password for the Linux access via SSH and WBEM. Usually, you will use credentials with administrator privileges.
|
Private Key
|
This field is only visible if you select private key login above. Paste a private key into the field (OpenSSH format, unencrypted). Usually, you will use credentials with administrator privileges.
If you do not insert a private key for the first time, but change the private key, you need to restart your PRTG core server service in order for the private key change to take effect! For details, please see Monitoring via SSH.
|
For WBEM Use Protocol
|
Define the protocol to use for WBEM. This setting is only relevant if you use WBEM sensors. Choose between:
- HTTP: Use an unencrypted connection for WBEM.
- HTTPS: Use an SSL-encrypted connection for WBEM.
|
For WBEM Use Port
|
Define the port to use for WBEM. This setting is only relevant if you use WBEM sensors. Choose between:
- Set automatically (port 5988 or 5989): Use one of the standard ports, depending on whether you choose unencrypted or encrypted connection above.
- Set manually: Use a custom port. Define below.
|
WBEM Port
|
This setting is only visible if you enable manual port selection above. Enter the WBEM port number.
|
SSH Port
|
Enter the port number to use for SSH connections.
By default, PRTG uses this setting automatically for all SSH sensors, unless you define a different port number in the sensor settings.
|
SSH Rights Elevation
|
Define the rights that you want to use to execute the command on the target system. Choose between:
- Run the command as the user connecting (default): Use the rights of the user who establishes the SSH connection, as defined above.
- Run the command as another user using 'sudo' (with password): Use the rights of another user with a password required for sudo to run commands on the target device, for example, as root user.
- Run the command as another user using 'sudo' (without password): Use the rights of another user without a password required for sudo to run commands on the target device, for example, as root user.
- Run the command as another user using 'su': Use the rights of another user with su to run commands on the target device.
|
Target User
|
This field is only visible if you choose sudo or su above. Enter a username to run the specified command as a user other than root. If you leave this field empty, you will run the command as root. Ensure you set the Linux password even if you use a public or private key for authentication. This is not necessary if the user is allowed to execute the command without a password.
|
Password Target User
|
This field is only visible if you choose to run the commands using su or sudo with password above. Enter the password for the specified target user.
|
SSH Engine
|
Select the method you want to use to access data with SSH sensors. We strongly recommend that you keep the default engine! For now, you still can use the legacy mode to ensure compatibility with your target systems. Choose between:
- Default (recommended): This is the default monitoring method for SSH sensors. It provides best performance and security.
- Compatibility Mode (deprecated): Try this legacy method only if the default mode does not work on a target device. The compatibility mode is the SSH engine that PRTG used in previous versions and is deprecated. We will remove this legacy option soon, so please try to get your SSH sensors running with the default SSH engine.
You can also individually select the SSH engine for each SSH sensor in the sensor settings.
|
|
User
|
Enter a login name for access to VMware and Xen servers. Usually, you will use credentials with administrator privileges.
|
Password
|
Enter a password for access to VMware and Xen servers. Usually, you will use credentials with administrator privileges.
Single Sign-On (SSO) passwords for vSphere do not support special characters. Please see the manual sections for VMware sensors for details.
|
VMware Protocol
|
Define the protocol used for the connection to VMware and XenServer. Choose between:
- HTTPS (recommended): Use an SSL-encrypted connection to VMware and XenServers.
- HTTP: Use an unencrypted connection to VMware and XenServers.
|
Session Pool
|
Define if you want to use session pooling for VMware sensors. Choose between:
- Reuse session for for multiple scans (recommended): Select this option to use session pooling. With session pooling, a VMware sensor uses the same session as created in advance to query data and needs not to log in and out for each sensor scan. We recommend that you choose this option because it reduces network load and log entries on the target device, resulting in better performance.
- Create a new session for each scan: If you select this option and disable session pooling, a VMware sensor has to log in and out for each sensor scan. We recommend that you use the session pooling option above for better performance.
|
|
The settings you define in this section apply to the following sensor types:
|
Port for Databases
|
Define which ports PRTG will use for connections to the monitored databases. Choose between:
- Set automatically (default port, recommended): PRTG automatically determines the type of the monitored database and uses the corresponding default port to connect. See below for a list of default ports.
- Define one custom port valid for all database sensors: Choose this option if your database management systems do not use the default ports. Define the port for database connections manually below. If you choose this option, PRTG will use the custom port for all database sensors.
If you choose the automatic port selection, PRTG uses the following default ports:
- Microsoft SQL: 1433
- MySQL: 3306
- Oracle SQL: 1521
- PostgreSQL: 5432
|
Custom Database Port
|
Enter the number of the port that PRTG will use for database connections. Please enter an integer value.
All database sensors on this device will use this port to connect.
|
Authentication Mode
|
- Windows authentication with impersonation
- SQL server authentication
|
User
|
|
Password
|
|
Timeout (Sec.)
|
Enter a timeout in seconds for the request. Please enter an integer value. If the reply takes longer than this value defines, the sensor cancels the request and triggers an error message. The maximum timeout value is 300 seconds (5 minutes).
|
|
Access Key
|
Enter your Amazon Web Services (AWS) access key. Please see the corresponding Amazon CloudWatch sensor documentation to learn more about the rights that are required for querying AWS CloudWatch metrics.
|
Secret Key
|
Enter your Amazon Web Services (AWS) secret key. Please see the corresponding Amazon CloudWatch sensor documentation to learn more about the rights that are required for querying AWS CloudWatch metrics.
|
|
SNMP Version
|
Select the SNMP version for the device connection. Choose between:
- v1: Use the simple v1 protocol for SNMP connections. This protocol only offers clear-text data transmission, but it is usually supported by all devices.
SNMP v1 does not support 64-bit counters which may result in invalid data when monitoring traffic via SNMP.
- v2c (recommended): Use the more advanced v2c protocol for SNMP connections. This is the most common SNMP version. Data is still transferred as clear-text, but it supports 64-bit counters.
- v3: Use the v3 protocol for SNMP connections. It provides secure authentication and data encryption.
When using SNMP v3 you can only monitor a limited number of sensors per second due to internal limitations. The limit is somewhere between 1 and 50 sensors per second (depending on the SNMP latency of your network). This means that using an interval of 60 seconds limits you to between 60 and 3000 SNMP v3 sensors for each probe. If you experience an increased Interval Delay or Open Requests with the Probe Health Sensor, distribute the load over multiple probes. SNMP v1 and v2 do not have this limitation.
|
Community String
|
This setting is only visible if you select SNMP version v1 or v2c above. Enter the community string of your devices. This is a kind of "clear-text password" for simple authentication. We recommend that you use the default value.
|
Authentication Type
|
This setting is only visible if you select SNMP version v3 above. Choose between:
- MD5: Use Message-Digest Algorithm 5 (MD5) for authentication.
- SHA: Use Secure Hash Algorithm (SHA) for authentication.
The type you choose must match the authentication type of your device.
If you do not want to use authentication, but you need SNMP v3, for example, because your device requires context, you can leave the field Password empty. In this case, SNMP_SEC_LEVEL_NOAUTH is used and authentication deactivated entirely.
|
User
|
This setting is only visible if you select SNMP version v3 above. Enter a username for secure authentication. This value must match the username of your device.
|
Password
|
This setting is only visible if you select SNMP version v3 above. Enter a password for secure authentication. This value must match the password of your device.
|
Encryption Type
|
This setting is only visible if you select SNMP version v3 above. Select an encryption type. Choose between:
- DES: Use Data Encryption Standard (DES) as encryption algorithm.
- AES: Use Advanced Encryption Standard (AES) as encryption algorithm.
AES 192 and AES 256 are not supported by Net-SNMP because they lack RFC specification.
The type that you choose must match the encryption type of your device.
|
Data Encryption Key
|
This setting is only visible if you select SNMP version v3 above. Enter an encryption key here. If you provide a key in this field, SNMP data packets are encrypted using the encryption algorithm selected above, which provides increased security. The key that you enter here must match the encryption key of your device.
If the key you enter in this field does not match the key configured on the target SNMP device, you will not get an error message about this! Please enter a string or leave the field empty.
|
Context Name
|
This setting is only visible if you select SNMP version v3 above. Enter a context name only if it is required by the configuration of the device. Context is a collection of management information accessible by an SNMP device. Please enter a string.
|
SNMP Port
|
Enter the port for the SNMP communication. We recommend that you use the default value.
|
SNMP Timeout (Sec.)
|
Enter a timeout in seconds for the request. If the reply takes longer than the value you enter here, the request is aborted and an error message triggered.
|
|
HTTP Proxy Settings
|
The proxy settings determine how a sensor connects to a given URL. You can enter data for an HTTP proxy server that sensors will use when connecting via HTTP or HTTPS.
This setting affects monitoring only and determines the behavior of HTTP sensors. To change proxy settings for the core server, please see System Administration—Core & Probes
The SSL Certificate Sensor and the SSL Security Check Sensor do not support HTTP proxies, but you can configure connections via SOCKS proxies in their sensor settings.
|
Name
|
Enter the IP address or DNS name of the proxy server to use. If you leave this field empty, no proxy will be used.
|
Port
|
Enter the port number of the proxy. Often, port 8080 is used. Please enter an integer value.
|
User
|
If the proxy requires authentication, enter the username for the proxy login.
Only basic authentication is available! Please enter a string or leave the field empty.
|
Password
|
If the proxy requires authentication, enter the password for the proxy login.
Only basic authentication is available! Please enter a string or leave the field empty.
|
|
User Group Access
|
Define which user group(s) will have access to the object that you are editing. A table with user groups and rights is shown; it contains all user groups from your setup. For each user group you can choose from the following access rights:
- Inherited: Use the settings of the parent object.
- None: Users in this group cannot see or edit the object. The object does not show up in lists.
- Read: Users in this group can see the object and review its settings.
- Write: Users in this group can see the object, as well as review and edit its settings. However, they cannot edit access rights settings.
- Full: Users in this group can see the object, as well as review and edit its settings as well as edit access rights.
You can create new user groups in the System Administration—User Groups settings.
|
Click the Continue button to save your settings. If you change tabs or use the main menu, all changes to the settings will be lost!
Auto-Discovery in Progress
While auto-discovery is running you may experience a lower system performance as usual, because PRTG works in the background to discover your network. Depending on the IP ranges defined (up to 65,536 addresses), the discovery may run up to several days before it is complete. You can review the status of the discovery process as follows:
- In the device tree, behind the group or device name, you will see a percentage value showing the progress of auto-discovery.
- During auto-discovery, the web interface will display a box in the lower-right corner that shows the number of active auto-discovery tasks.
- To stop a running auto-discovery, right-click the group or device, and select Pause | For 5 minutes... from the context menu. PRTG will pause monitoring for 5 minutes and stop auto-discovery tasks.
Related Topics
More
Knowledge Base: Why can automatic auto-discoveries evoke performance issues?
Ajax Web Interface—Device and Sensor Setup—Topics
Other Ajax Web Interface Sections
Related Topics