In my 15 years of working with Citrix ADCs (formally NetScalers) and helping hundreds of customers integrate ADC into their environment, one question always comes up – who is going to be responsible for supporting and managing this seemingly complex new system? The answer is not always clear.

One view is that the ADC is a Citrix branded product, so obviously, this is a component for delivering apps and desktops and should fall on the Citrix administrators. The other perspective is that the Citrix ADC is like all other networking devices, i.e., switches and routers, making up the data center; the ADC is a networking appliance and must be managed by the networking side of the house.

A Citrix ADC in your environment shouldn’t introduce management headaches. Citrix has focused a considerable amount of the development of the ADC on its simple manageability features. The problem is that many organizations are not taking advantage or are not aware of the timesaving and ease of manageability features offered by Citrix ADC.

Here are 7 things customers get wrong managing the Citrix ADC

1.    Using the nsroot account for everything

The nsroot account comes pre-configured on the Citrix ADC and is used to access the configuration utility during the initial installation of the appliance. The nsroot account has full system access to the entire ADC, the underlying shell, and is used by internal services to establish ADC to ADC communication. However, if you’re using the nsroot account to log in to the ADC for day-to-day administration tasks, you’re using it wrong.

It’s better to think of the nsroot account as a backdoor to logging into the system when other methods fail. The nsroot account should be tightly controlled, with knowledge of the password extremely limited to only higher-level administrators in the organization. Instead, you should create your nsroot-like system accounts, or use an external directory service, such as LDAP, RADIUS, or TACACS, to grant administrative access to the appliance.

While the nsroot account can’t be disabled or deleted, the rights of the account can be applied to any system user account, and the password changed. Not only are you securing the nsroot account and who has access to it, but you now require individual administrators to have their own account, making it much easier to determine who among the IT staff is in the system making changes.

2.    Not Preventing nsroot Account Spoofing

By default, the nsroot account is set to allow external authentication. That means if you have configured any authentication policies, such as an LDAP policy, and bound it to the system, the ADC will first check the external authentication source for a nsroot account before trying the local account. This introduces potentially a very dangerous oversight where someone could create a nsroot account in the external directory and login to the system with full access using that account instead of the local nsroot account. The good news is that it is very easy to prevent such a situation. Simply disable external authentication on the nsroot account.

3.    Not Managing a High Availability (HA) Pair by the SNIP Address

In an HA pair, almost all configuration changes are made on the primary and propagated to the secondary. When managing two Citrix ADC systems that are set up in an HA pair, there is no need to log on to the secondary system unless you’re configuring something under the network node in the configuration utility, installing a license, or troubleshooting HA itself. In addition, all system-owned IP addresses, except for the NSIP, are owned by and present on both systems.

The best way to manage the Citrix ADC is to use the SNIP, ensuring that whichever system is the primary will be the system that answers. And you won’t have to worry about or keep track of which system is primary and which system is secondary.

4.    Not Enabling Audit Logging

The audit logging feature enables you to log the Citrix ADC states and status information collected by various modules in the kernel and the user-level daemon. For audit logging, you could use the SYSLOG standard, the native NSLOG protocol, or both. The SYSLOG standard is used for audit logging and events, while the NSLOG is more proprietary and is used for performance counters and debugging. These logs are, by default, stored locally. However, most customers tend to miss configuring an external server to store logs and, as a result, limit the number of logs that can be retained for troubleshooting purposes.

Configuring external logging servers ensures you maintain historical data for much longer than the system limits. Additionally, most external logging servers give you the functionality of sending notifications when certain log levels are triggered, whether by email, SMS, or other means – something the ADC does not provide.

5.    Not Enabling Simple Network Management Protocol (SNMP)

Like the audit logging feature, configuring the SNMP feature typically gets overlooked. Think about how often you are faced with service outages, certificates expiring, performance issues, and other surprises. Often the first indication of a problem comes from a user who has reported the issue to the company’s help desk, but there is a better way to be notified so that the user may never have experienced the issue in the first place.

SNMP has several alarms that are already configured to auto-fire when certain conditions and thresholds are met. But these alarms don’t do anything unless you’ve configured an SNMP Manager and a trap destination. Not configuring SNMP means you lose a lot of visibility into the health of the system and that when issues occur, there is no notification sent so that an administrator can address the issue, hopefully before a user encounters a problem.

6.    Not Using the Command Line Interface (CLI)

If you’re not akin to using the CLI when configuring and troubleshooting the Citrix ADC, you’re missing some features that make both tasks easier. While some view using the CLI versus the Graphic User Interface (GUI) for configuration as a matter of preference, there are some major differences between the two that an administrator should note.

Most configuration tasks in the GUI require multiple entities to be configured, which means many clicks in and out of the available menus and options. It’s easy to get lost in the GUI and tasks, such as creating a load balancing virtual server, as this requires servers, services, virtual servers, and other entities to be configured and bound, which takes longer than in the CLI.

The CLI is designed to make troubleshooting the ADC easier. However, not all commands are available in the GUI, such as the commands for debugging. There also tend to be more bugs in the GUI than in the CLI. Some tasks that may throw errors in the GUI may work fine when configured via the CLI. If a configuration is not being maintained or not working as it should, try setting it up via the command line to see if the issue is simply a bug in the GUI.

7.    Not Implementing Citrix Application Delivery Management (ADM)

The Citrix ADM is an essential tool to make many day-to-day management tasks easier, whether you have a single ADC system or a data center full of them. The Citrix ADM is available on-prem and as a cloud service. If you have at least one Citrix ADC, it makes no sense if you have not also implemented Citrix ADM.

Most of what the ADM offers is technically free and doesn’t require any additional licensing other than your Citrix ADC license. You have an unlimited ability to manage the ADCs in your environment, including configuration jobs, backups, and viewing logs and reports. Analytics monitoring is also free up to 30 virtual servers, which for most, is plenty. If you need more, licenses can be purchased in packs of 10. The Citrix ADM can be used as a centralized management platform to automatically deploy configuration jobs to any ADC on your network