Clients and Server not communicating

I do not need a solution (just sharing information)

I have installed Symantec Endpoint Protection Manager 14.2 on Server 2016. I have created a client install for Windows 10 which installs without any issues, however the client never connects to the manger unless I configure the client IP to a static IP rather DHCP any suggestions on how to fix this would be much appreciated



How Microsoft Service Witness Protocol Works in OneFS

The Service Witness Protocol (SWP) remote procedure call (RPC)-based protocol. In a highly available cluster environment, the Service Witness Protocol (SWP) is used to monitor the resource states like servers and NICs, and proactively notify registered clients once the monitored resource states changed.

This blog will talk about how SWP is implemented on OneFS.

In OneFS, SWP is used to notify SMB clients when a node is down/rebooted or NICs are unavailable. So the Witness server in OneFS need to monitor the states of nodes/NICs and the assignment of IP addresses to the interfaces of each pool. These information is provided by SmartConnect/FlexNet and OneFS Group Management Protocol (GMP).

The OneFS GMP is used to create and maintain a group of synchronized nodes. GMP distributes a variety of state information about nodes and drives, from identifiers to usage statistics. So that Witness service can get the states of nodes from the notification of GMP.

As for the information of IP addresses in each pool, SmartConnect/Flexnet provides the following information to support SWP protocol in OneFS:

  1. Locate Flexnet IP Pool given a pool member’s IP Address. Witness server can be aware of the IP pool it belongs to and get the other pool members’ info through a given IP address.
  2. Get SmartConnect Zone name and alias names through a Flexnet IP pool obtained in last step.
  3. Witness can subscribe to changes to the Flexnet IP Pool when the following changes occur:
    • Witness will be notified when an IP address is added to an active pool member or removed from a pool member.
    • Witness will be notified when a NIC goes from DOWN to UP or goes from UP to Down. So that the Witness will know whether an interface is available.
    • Witness will be notified when an IP address is moved from one interface to another.
    • Witness will be notified when an IP address will be removed from the pool or will be moved from one interface to another initiated by an admin or a re-balance process.

The figure below shows the process of Witness selection and after failover occurs.


  1. SMB CA supported client connect to a OneFS cluster SMB CA share through the SmartConnect FQDN in Node 1.
  2. The client find the CA is enabled, start the Witness register process by sending a GetInterfaceList request to Node 1.
  3. Node 1 returns a list of available Witness interface IP addresses to which the client can connect.
  4. The client select anyone interface IP address from the list (in this example is Node 2 which is selected as the Witness server). Then the client will send a RegisterEx request to Node 2, but this request will failed as OneFS does not this operation. RegisterEx is a new operation introduced in SWP version 2. OneFS only support SWP version 1.
  5. The client send a Register request to node 2 to register for resource state change notification of NetName and IPAddress (In this example, the NetName is the SmartConnect FQDN and IPAddress is the IP of Node 1)
  6. The Witness server (Node 2) process the request and returns a context handle that identifies the client on the server.
  7. The client sends an AsyncNotify request to Node 2 to receive asynchronous notification of the cluster nodes/nodes interfaces states changes.
  8. Assume Node 1 does down unexpectedly. Now, the Witness server Node 2 is aware of the Node 1 broken and sends an AsyncNotify response to notify the client about the server states is down.
  9. The SMB CA feature forces the client to reconnect to OneFS cluster using the SmartConnect FQDN. In this example, the SMB CA successfully failover to Node 3.
  10. The client sends a context handle in an UnRegister request to unregister for notifications from Witness server Node 2.
  11. The Winess server processes the requests by removing the entry and no longer notifies the client about the resource state changes.
  12. Step 12-17. The client starts the register process similar to step 2-7.


How to Use Port Control Protocol in NetScaler?

This article describes how to use Port Control Protocol in NetScaler.


In today’s networks NAT device plays an important role providing IPv4 preservation, IPv6 migration, and security and thus the chances of packet translation happening in an end-to-end communication is quite high. In order to have control over these NAT devices, Port Control Protocol was developed (RFC – 6887). Port Control Protocol commonly referred as PCP enables applications and equipment to read/write explicit mappings between an external IP address, protocol and port, and an internal IP address, protocol and port. These explicit mappings allows inbound communication to reach the hosts behind a NAT or firewall.

Why PCP?

With DHCP the internal IP address varies often and thus the external IP address/port also changes frequently. While hosting a service on a server behind firewall or NAT, this frequently changing external IP address/port posts a challenge. Below are the list of problems faced commonly in a NAT environment.


  • Hosting of web services in private network lead to Dynamic DNS issues (change in NAT IP during reallocation of IP)
  • Need to Monitor/Access Home Gateway (HG) devices from outside/office
    • No control over NAT and firewall
    • Have to raise a request to service provider for static mapping
  • Internet of Things (Rapid growth of HG)
    • Keep alive messages takes bandwidth consumption
    • Battery consumption on mobile devices


PCP comes to rescue here by providing the below mentioned support to overcome the above mentioned problems.

  • PCP clients can get updated mappings from NAT device using PCP
  • Give controls to applications/devices at HG
    • Whenever it wants to act as service, it can request its upstream devices
    • Applications decide when the session at upstream devices should terminate

Primary Uses cases for DDNS with PCP

PCP Communication

Port Control Protocol (PCP) keeps device (PCP client) and NAT/CGN server (PCP server) dynamically aware about the change in both internal and external IP address and port number. NetScaler should be able to receive PCP request from any client and provide appropriate response for them.

User-added image

PCP works in a client server model over UDP and uses various OPCODEs are used for performing PCP operations. In NetScaler PCP server can be used with NAT44, NAT64 and DS-Lite.


iOS 11 MDM-enrolled Device Issues with XenMobile in Cluster Mode

Update: This issue has been resolved in 10.8 RTM.

You will need to modify your NetScaler load balancer configuration to use Source IP persistence for all NetScaler MDM load balancers e.g. virtual servers set up for ports 8443 and 443.

For XenMobile Service customers, Citrix Cloud Ops will be performing this configuration change as a maintenance operation, so no action is necessary by customers.

Please refer to this article for more details on Source IP persistence –

The configuration change can be made either through the command-line or the NetScaler GUI.

  • Here are example commands to set Source IP Persistence:
set lb vserver _XM_LB_MDM_XenMobileMDM_172.16.30.62_443 -persistenceType SOURCEIP

set lb vserver _XM_LB_MDM_XenMobileMDM_172.16.30.62_8443 -persistenceType SOURCEIP
  • Here is a screenshot of the GUI to set Source IP Persistence:
User-added image

If Source IP persistence is already configured on NetScaler and your XenMobile environment has more than 10,000 devices being managed by a XenMobile cluster, plus if network address translation (NAT) is enabled on an appliance such as F5 or a firewall fronting the NetScaler before the XenMobile Server, please monitor the NetScaler and XenMobile for CPU and memory usage. If NetScaler or XenMobile server resources are consistently pegged at 80% of the CPU or memory usage over a long period of time, please contact Citrix Technical Support for further assistance.


How to Enable Subscriber Aware Session Termination in NetScaler?

This article describes how to enable subscriber aware session termination in NetScaler.


In today’s environment, subscribers who goes to internet through Large Scale NAT (LSN, also called Carrier Grade NAT—CGNAT) terminates connections and creates new connections frequently. In such a dynamic environment, it is important for the CGNAT device to identify if the subscriber session is closed and free the resources allocated for the specific subscriber session. In CGNAT context, the NAT resources like IP address, port block (if Port Block Allocation is enabled) shouldbede-allocated so that they can be used by other subscribers. Considering the scale at which subscribers go through the service provider network, this plays a vital role in optimally using NAT resources and has significant impact in CGNAT device performance.

How to configure subscriber aware session termination in NetScaler?

User-added image
In earlier implementation, when a subscriber is using a CGNAT session ,on receiving Radius-Accounting-Stop message, portblock of the public IP is kept open even after the subscriber is disconnected. It uses LSN session idle time out to deallocate the NAT resources which lead to non-utilization of these resources till the idle timer expires. NetScaler enables service providers to optimally use CGNAT resources by supporting subscriber based session termination.

NetScaler will now be able to close LSN session when Radius-Accounting-Stop message is received for the Framed-IP.

Subscriber Aware Session Removal is an LSN global setting for controlling subscriber aware session removal. With this enabled, whenever the subscriber information is deleted from subscriber database, sessions corresponding to that subscriber will beremoved. If this setting is disabled, subscriber sessions will be timed out as per the idle time out settings.