Unable to access Storefront through NetScaler Gateway and getting ” Could reach the page ” error.

– After upgrading to 12.0 build 58.15 , unable to access the Storefront server through NetScaler Gateway and getting ” Could reach the page ” error.

NOTE: On NetScaler Gateway Session profile, the Storefront URL is configured with Storefront Load balancing server IP.

– If Storefront Load balancer IP is replaced with Actual Storefront Server IP, then Storefront is accessible through NetScaler gateway.

In the following nstrace screenshot, we could see that the Storefront Load balancer has sent Export cipher in the Server Hello. For which, we could see a FATAL Error message from NetScaler gateway Vserver.

User-added image


  • No Related Posts

SRM 4.0.1 Block ChargebackSP: Chargeback by Group doesn’t show all the groups

Article Number: 493197 Article Version: 2 Article Type: Break Fix

ViPR SRM,ViPR SRM 4.0,ViPR SRM 4.0.1

Customer couldn’t see any data under chargeback by group report. We have created several groups using Group Management UI -> Block Chargeback Grouping, but the metrics devtype=UserDefinedGroup are not created

Metrics coming from the passive host discovery were pushed to the Load Balancer Arbiter, and not the Load Balancer Collector

the filter PTF-GROUP-Tagging is set to skip on the LBA (default config) so the metrics cannot be tagged with the nodegrp property

The nodgrp property gets tagged on the metrics coming from the PassiveHost discovery.

Reconfigure the CISCO Solution Pack to send the data to the Load Balancer Collector (localhost)

Step 1: Go to SRM GUI >> centralized-management>> SolutionPacks >> Infrastructure >> Cisco MDS/Nexus Switch >>then open Data collection component

User-added image

Step 2: expand the Data Collection >> validate the Hostname or IP address to send data to localhost.

User-added image

Step 3. Click reconfigured button to save the change.

Step 4: when it has been reconfigured. Please waiting the Chargeback block task run completed. The task will run at 12:00AM every day.


  • No Related Posts

Error: “HTTP/1.1 Internal Server Error 43554” When Logging to NetScaler

>> NetScaler Gateway vserver is configured, while getting error “http:// internal service error”

>> Verified the configuration on NetScaler the address in published application was not correct. Correct the address.

Web Browsers –>Web Interface Address: https:<Ip or FQDN of SF Server>/citrix/<StoreName> Receiver: Web Interface Address: https:<Ip or FQDN of SF Server>

>> Also check the policy hit command the session profile policy is also getting hit.

nsconmsg -d current -g pol_hits

>> Created the new test gateway server on the storefront server.

>>Storefront address was incorrect in Session profile.

You can traverse to Session Profile by following this path,

NetScaler Gateway > Virtual Servers > Edit virtual server > Session Policies > Select Session Policy and Click Edit Session Profile > Published Applications > Web Interface Address > Edit the address to the correct one.

Example Configuration,

User-added image


  • No Related Posts

Netscaler VPX 1000 – Azure – Slowness getting through Netscaler.

With 12.0 builds, we have changed default yield behavior for PE vCPUs. vCPU will not yield to hypervisor, even though if there is less/moderate traffic in 12.0 build, which was not the case for 11.1 builds. That’s the reason, VPX vCPU is always 100% on hypervisor. However, vCPU is allocated to management core might not be 100%.

NetScaler yields PE vCPUs to hypervisor in sparse/moderate traffic cases. Since we have observed Tx overflow/congestion, it’s somewhat related to scheduling, we thought not yielding vCPU helps in improving the situation.

– set ns vpxparam -cpuyield NO

Upgrade to 12.0.53.X+


  • No Related Posts

Netscaler GSLB is answering queries for Vserver that are Down.

When the GSLB vserver is down, with all the corresponding gslb services in the down state, the DNS query response can have the IP addresses of the down GSLB services. This is by design/expected behavior.

However, you can configure the GSLB virtual server to send an empty down response (enable EDR on GSLB Vserver). When this option is set, a DNS response from a GSLB virtual server that is in a DOWN state does not contain IP address records, and this prevents clients from attempting to connect to GSLB sites that are down.


Configuring a GSLB Virtual Server to Respond with an Empty Address Record When DOWN

A DNS response can contain either the IP address of the requested domain or an answer stating that the IP address for the domain is not known by the DNS server, in which case the query is forwarded to another name server. These are the only possible responses to a DNS query.

When a GSLB virtual server is disabled or in a DOWN state, the response to a DNS query for the GSLB domain bound to that virtual server contains the IP addresses of all the services bound to the virtual server. However, you can configure the GSLB virtual server to in this case send an empty down response (EDR). When this option is set, a DNS response from a GSLB virtual server that is in a DOWN state does not contain IP address records, but the response code is successful. This prevents clients from attempting to connect to GSLB sites that are down.

Note: You must configure this setting for each virtual server to which you want it to apply.

To configure a GSLB virtual server for empty down responses by using the command line interface

At the command prompt, type:

set gslb vserver<name> -EDR (ENABLED | DISABLED)


> set gslb vserver vserver-GSLB-1 -EDR ENABLED Done 

To set a GSLB virtual server for empty down responses by using the configuration utility

  1. Navigate to Traffic Management > GSLB > Virtual Servers.
  2. In the GSLB Virtual Servers pane, select the GSLB virtual server for which you want to configure a backup virtual server (for example, vserver-GSLB-1).
  3. Click Open.
  4. On the Advanced tab, under When this VServer is “Down,” select the Do not send any service’s IP address in response (EDR) check box.
  5. Click OK.


  • No Related Posts

How to Use the Authentication Feature of a NetScaler Appliance with a Load Balancing or Content Switching VServer on the Appliance

This article describes how to use the authentication feature of a NetScaler appliance with a Load Balancing or Content Switching virtual server on the appliance.


To complete this task, the NetScaler appliance must have license for the Load Balancing, Content Switching, and Authentication, Authorization, and Auditing (AAA – Application Traffic) features.


  • No Related Posts

Vulnerability in Citrix NetScaler Application Delivery Controller and NetScaler Gateway leading to arbitrary code execution and host compromise

This vulnerability has been addressed in the following versions of Citrix NetScaler ADC and NetScaler Gateway:

• Citrix NetScaler ADC and NetScaler Gateway version 12.0 Build 57.24 and later

• Citrix NetScaler ADC and NetScaler Gateway version 11.1 Build 58.13 and later

• Citrix NetScaler ADC and NetScaler Gateway version 11.0 Build 71.24 and later

• Citrix NetScaler ADC and NetScaler Gateway version 10.5 Build 68.7 and later

Citrix NetScaler ADC and NetScaler Gateway version 10.1 are not planned to be updated as part of remediating this issue. Customers on version 10.1 should plan to move to a later version to receive the latest security updates.

These new versions can be downloaded from the following locations:



Citrix strongly recommends that customers using affected versions of NetScaler ADC and NetScaler Gateway to upgrade to a version of the appliance firmware that contains the fixes for this issue as soon as possible.


  • No Related Posts

Re: Is it possible to rerun a policy action?

Hhm – good point.

Yes, you can define a workflow which will only run a clone action. And it will work.

However, my personal favorite is scripted cloning

– easy to configure

– easy to change

– much more flexibility

– you can use much more mminfo parameters to select your save sets precisely

– you can specify a storage node (load balancing)

– you can add other criteria as a specific retention date

– and it is valid for all NW versions 😉

Then schedule such script via in cron/task scheduler. Done.

We have used this method for years.


  • No Related Posts

How to Configure the GSLB Static Proximity Feature in a NetScaler Appliance

This article contains information about configuring and troubleshooting the static Global Server Load Balancing (GSLB) feature on a NetScaler appliance.



A NetScaler appliance with the GSLB feature directs DNS requests to the GSLB site with the best performance. When a client sends a DNS request, the appliance identifies the site with the best performance and sends the IP address of the site to the client. The appliance decides by using the Metric Exchange Protocol (MEP), GSLB policies, and GSLB methods supported by the appliance. The GSLB methods are algorithms that control how the appliance load balances the client requests across the distributed data centers.

You can configure the GSLB feature based on the round trip time (RTT), static proximity, or a combination of the two.

Static Proximity

The static proximity feature uses an IP address-based static location database. This database contains GeoIP address and the information of the location to which the site belongs. When a user visits the website, GeoIP address can determine the information such as country, region, city, and longitude/latitude. The database used to implement the static proximity method often contains information of all the GSLB sites. The appliance uses this database to determine the proximity between the Local DNS (LDNS) of the client and the GSLB sites. The appliance sends the IP address of a site that is closest to the client.

Note: In the static GSLB database the locations consist of an IP address range and up to six qualifiers for this range.

In order to use static proximity feature you have to upload the database on the appliance. The custom database is stored in ns.conf, and a static third party database or the database of the appliance is stored in the /var/netscaler/locdb directory, by default.

Static Proximity When using a NetScaler Appliance

A client sends a request for a domain to access an application by using resources such as internet, email, or VPN. The client requests for www.example.com by using the browser. The information for this website is stored at two different data centers, Site A and Site B. If the IP address for the domain is not found in the local cache, then the browser sends a request to the client LDNS server.

If the LDNS server does not have an IP address for a requested domain, then it sends a query to a NetScaler appliance that is configured as the authoritative DNS server for the domain.

When the appliance receives the request from the client LDNS, the appliance uses the static database to determine if the IP address and the location information of the client exists.

The appliance then sends the IP address of the nearest data center to the client and the client browser displays the web page.


  • No Related Posts

FAQ: How to Verify Hardware Health Status on NetScaler MPX?

Q: How to verify hardware health status on NetScaler MPX?

A: stat system -detailcommand to display the current health attributes of different NetScaler hardware component.

For a list of health attributes and their recommended value ranges, refer to Citrix Documentation – Hardware Health Attributes.

Run the following commands to check on NetScaler (deprecated) :

> shell

root@Netscaler# ns_hw_err.bash

WARNING: DO NOT run the ns_hw_err.bash script on a FIPS Netscaler. This script contains commands that can cause a FIPS Netscaler to hang or crash, requiring a power cycle to recover.

NOTE: The ns_hw_err.bash script was intended for Netscaler Tech Support use only. As such, it can sometimes report false positives that should be ignored. Examples of false positives are cavium card timeout recoveries and SMART Old-Age warnings. Both of these conditions are considered normal and are not indicative of a hardware failure, nor do they require an RMA.

In lieu of the script above, RECOMMENDED method of performing a health check on a Netscaler is to generate a tech support file (from the GUI or by running show techsupport from the CLI) and uploading the resulting support.tgz file (in /var/tmp/support) to https://cis.citrix.com for analysis. CIS will analyze the file and generate a report detailing the Netscaler’s health and also providing suggestions for improvement.


  • No Related Posts