NetScaler Gateway with Citrix Desktops & Apps

NetScaler Gateway with Citrix Desktops & Apps
The Ultimate How-To Guide for Successful Deployments Lucas Araujo Do you currently have only a StoreFront or Web Interface server in your Citrix environment, and have always considered deploying a NetScaler Gateway, but were afraid of policy configuration on the NetScaler or just not sure how it works? My name is Lucas Araujo, and I am a Readiness Specialist here at Citrix and I have been with Citrix for the last 4 years working in Tech Support. Majority of the NetScaler Gateway calls are on deployment or configuration. Working as both a Senior Tech Support Engineer and now working in Support Readiness, I have been involved in different deployment scenarios since version In this session, we are going to cover deploying the NetScaler Gateway and how easy it is with the improved wizard in version This guide is the ultimate how-to guide for successful deployments, and I believe you will be successful in deploying the NetScaler Gateway in your Citrix environment. Readiness Specialist May 2015

Agenda Traffic flow for NetScaler Gateway deployment scenarios
How policies and Smart Access filters operate as well as the configuration consideration for StoreFront Troubleshooting tips to identify common issues in NetScaler Gateway deployments Agenda As we go through this session, we will make sure to discuss what the traffic flow looks like in NetScaler Gateway deployment, what policies and configurations steps need to be setup for a Netscaler Gateway deployment throughout the wizard, and lastly I will go over how to improve troubleshooting NetScaler Gateway issues by isolate NetScaler Gateway traffic and the different type of main issues that exist

Tweet about this session with hashtag #SYN404 and #citrixsynergy

Traffic flow for NetScaler deployments

Physical Deployment Modes
One-Arm 1. User Request 2. User Request Public Private 4. Response 3. Response The NetScaler communicates and acts as a reverse proxy. It receives the user request to the virtual server IP, communicates with the server farm through the Subnet IP and returns the response to the client. So it is important to put the NetScaler where it can have access to both internal and external networks. This is the one-arm deployment and it is by far the most common. The NetScaler is usually deployed in the DMZ, where it be attached to a switch that has access to both the internal and external network. So with one arm deployment we utilize one interface which eliminates the risk of bridge loops. If we need to use more than one we can can utilize VLANs or utilize Link Aggregation to satisfy bandwidth requirements

Physical Deployment Modes
Two-Arm 1. User Request 2. User Request Public Private 4. Response 3. Response Two-arm is much less common, especially with NetScaler Gateway deployments. It serves to accommodate network topologies that need to pass traffic that is not destined for the NetScaler through. We can enable either Layer 3 mode to route the traffic or Layer 2 mode to bridge it. So really two arm mode is to accommodate topologies in situations where one-armed does not.

Published Application Enumeration Workflow
External DMZ Internal LDAP 389/636 NetScaler 443 80/443 StoreFront Once we physically or virtually deploy the NetScaler in the DMZ, lets see how the client, and backend server farm will communicate with it to launch your Citrix Desktop and Apps 1) User points browser to the NetScaler Gateway VPN Vserver 2) Pre-Authn EPA ActiveX control gets downloaded 3) If Pre-Authn EPA is successful, user gets the login page 4) NetScaler Gateway authenticates user against configured authentication server 5) If Post-Authn EPA policies are configured, EPA ActiveX is downloaded again 6) NetScaler Gateway sends a redirect to the SF/WI homepage 7) SF/WI returns a 401. After the 401 handshake is successful, NetScaler Gateway hands off previously collected EPA results to SF/WI 8) SF/WI then talks to the XenApp and returns application list to the user 9) User can now click on icons to launch published applications XenApp XenDesktop STA XML

Published Application Launch Workflow
External DMZ Internal XenApp XenDesktop 1494/2598 443 NetScaler 80/443 StoreFront Now that we have the applications enumerated, let’s see what happens during the launch process Following successful Authentication and EPA scan, the user is presented with the list of published applications User clicks an application icon SF/WI requests a ticket from the Secure Ticket Authority SF/WI sends a ticket to the user in a ICA ® file The ICA client launches and sends secure ICA traffic to NetScaler Gateway NetScaler Gateway validates the ticket against the STA The ICA session is established STA / XML 80/443 STA XML

Policies & Configuration
How Policies and Smart Access Filters operate & configuration considerations

How To Access the Wizard?
When deploying NetScaler Gateway really the best place to start is to used the NetScaler Gateway wizard. To start the wizard, login and towards the bottom left corner there will be the following option for integrating with Citrix Products. Select this button and then the Getting Started button towards the bottom of the screen.

What is your deployment?
The next step is select your Citrix Integration Point. You have three options: Web Interface, StoreFront, and Web Interface on NS. I’ll be integrating with StoreFront and selecting continue

Create the Gateway The first step in the wizard is to create the Gateway virtual server by giving it a name, IP address, and port number. There’s also an option create a virtual server that will redirect users who didn’t type HTTPS in there web browser’s address bar

Bind SSL Certificate The next step in the Wizard is to bind the certificate You can select one already installed on the NetScaler Or, you can upload one right then and there

Select the Authentication Settings
The next step in the Wizard is to configure the authentication settings, the primary authentication is typically LDAP and once again you can choose an existing LDAP profile or configure a new one You also have the option to setup a Secondary authentication

Configure StoreFront Settings
Keep in mind that the StoreFront FQDN and the Use HTTPS options should be based on the StoreFront BaseURL A common mistake made is forgetting to specify the STA port

Enable Pass-through from NetScaler Gateway
Step 1 Let’s quickly go over the StoreFront integration steps and what you will need Step 1: Enable Single Sign-On Authentication on StoreFront This setting will allow StoreFront to evaluate the incoming HTTP request and perform the Authentication Callback if it determines that the user is coming from a Gateway

Add the Gateway Step 2 Step 2: In the StoreFront management console you will need to add a Gateway instance to associate with the StoreFront Store. Let’s go over each field Display name: This can be whatever you’d like, just keep in mind that end users WILL see this display name if they open their Receiver options to select a Gateway. NetScaler Gateway URL: This is the FQDN that end users will be accessing from the external network, end users should be typing this exact FQDN into their browser address bar. Receivers on mobile devices or windows and mac devices will automatically use this FQDN after it downloads this information from the StoreFront Store via the Store’s Discovery file. The logon type should match the authentication method configured on the Gateway. So if you have LDAP and RSA authentication, change this field accordingly. This information gets entered into the Discovery file also Callback URL: Whatever FQDN is entered in here, you should be able to open Internet Explorer on the StoreFront server and browse to this FQDN without certificate warnings and successfully load the logon page. If not, then Single Sign-On from the Gateway will most likely not work.

Add the Gateway Step 2 The last thing to configure is the Secure Ticket Authority (STA). This is the ticketing service used to securely launch an ICA session through the Gateway

Enable Remote Access Step 3
Once the Gateway is created, you’ll be able to bind it to the Store The first thing you’ll have to do is select ‘No VPN tunnel’. The Full VPN tunnel is not necessary, unless you have XenMobile App Controller publishing Internal Web Links that require a full VPN tunnel from the client to the Gateway, this requires different configuration (See CTX139319) Then you’ll select the Gateways to bind with the Store – you do have the option to bind multiple Gateways to a single Store And then select the Default appliance, in cases where you have multiple Gateways

Authentication Policy
What’s Gets Created? Let’s talk a bit more about the policies. We created a series of policies in the wizard, and we might have to look a bit more into them, if we configured them wrong. For authentication, I already had added a server, but this is what it looks like when adding a new server. Make sure to add in the correct IP and port information for your DC, as well as the domain information along with admin account being used to query the authentication attempts. The most common protocol used is LDAP, but in the case of dual factor authentication, you want to make sure that the correct authentication server that uses is matched here in the session profile. So for example, If you have primary authentication as your LDAP server, the credential index should be primary. This is because LDAP will be used for the SSO process. The credential index is set under the Client Experience tab on the session profile

Session Policy Receiver Session Policy Receiver for Web Session Policy
What’s Gets Created? Receiver Session Policy The session policy is what is in play after authentication. The wizard will go ahead and create and bind 2 session policies to the Gateway virtual server. One policy is for Receiver – with the Expression that looks for CitrixReceiver in the HTTP Header User-Agent OR the Referer HTTP header does not exist in the HTTP request The other policy is for the Web Browser which has a general ns_true expression. The thought here is that if the HTTP request does not meet the requirements for the Receiver policy, then the request MUST be coming from a Web Browser. On the right hand side, a Session profile is associated, that’s where the FQDN, sson domain, and ICA Proxy settings are configured Receiver for Web Session Policy

Smart Access SmartAccess is something we mentioned before, and really this is a concept, not specifically a policy. It allows us flexibility in giving a certain application set to users based on their group membership. There is a couple of settings we need to make sure are configured. The first one is the basic settings of the Gateway Virtual Server, you will want to edit this and make sure that ICA Only is not selected. Next we need to navigate to our XenApp and make sure the computer policy has Trust XML enabled. Afterwards, select the application properties of the application you are using. Go to the access control, and add the filter. The farm will make your Virtual Server name, and the filter will be your session policy. Since we have two policies, we will need to add two filters.

Troubleshooting

Troubleshooting: Potential Issue Areas
External DMZ Internal Problem Types: LDAP Authentication Security Event Log on DC (LDAP or IAS) NetScaler Authorization NSIP App Enumeration App Launch 1- SF/WI Site Settings 2- SF/.WI Trace 3- Event Log StoreFront SNIP or MIP VIP 1- Auth Svr Settings 2- NS Trace 3- aaad.debug STA path on SF/WI 1- Auth Settings 2- NS.log XenApp XenDesktop 1- XML Settings 2- STA Logging 3- CDF Tracing 1- ProfileSettings 2- NetScaler Trace 3. Certifcate Usually when we troubleshoot issues with NetScaler Gateway deployments, its important to identify initially what type of problem is occurring. We have so many moving parts and without doing this troubleshooting can be time consuming. So a couple of questions to ask? Can we authenticate? Is the application icon appearing or enumerating? Is there traffic issues or issue the application able to launch? So if there are authentication issues, we have a couple of different places we need to check. First we need to confirm that our auth server settings are correct. We can further verify this via nstrace or aaad.debug. We also need to make sure that our firewall rules are set properly. When it comes to authentication, the NetScaler will use the NSIP for communication with the LDAP server. Lastly we can check the event viewer on the DC. Inner FW Port Rules: DNS (UDP) - 53 LDAP /LDAPS (TCP) - 389/636 HTTP: 443,80 NS Admin (TCP): 3010, 3008 ,22 Xen (XML/HTTP/HTTPS): 8080, 80, 443 ICA: 1494, 2598 Outer FW Port Rule: 443,80* (HTTP/TCP) CDF Tracing 1- NS Trace 2- STA Monitor (newnslog) 3 - Licensing LDAP /LDAPS (TCP) - 389/636 nssslvpn.txt Ports and IP rules nssslvpn.txt Ports and IP rules ICA file - ID Ports and IP rules

External DMZ Internal Security Event Log on DC (LDAP or IAS) Problem Types: LDAP Authentication NetScaler NSIP StoreFront SNIP or MIP VIP 1- Auth Svr Settings 2- NS Trace 3- aaad.debug XenApp XenDesktop So if there are authentication issues, we have a couple of different places we need to check. First we need to confirm that our auth server settings are correct. We can further verify this via nstrace or aaad.debug. We also need to make sure that our firewall rules are set properly. When it comes to authentication, the NetScaler will use the NSIP for communication with the LDAP server. Lastly we can check the event viewer on the DC. Inner FW Port Rules: DNS (UDP) - 53 LDAP /LDAPS (TCP) - 389/636 HTTP: 443,80 NS Admin (TCP): 3010, 3008 ,22 Xen (XML/HTTP/HTTPS): 8080, 80, 443 ICA: 1494, 2598 Outer FW Port Rule: 443,80* (HTTP/TCP) LDAP /LDAPS (TCP) - 389/636

Failed to Authenticate
When authentication fails, there’s not much information presented to the client, other than their credentials were rejected.

Aaad.debug root@ns# cat /tmp/aaad.debug Wed Aug 6 16:07:47 2008
/home/build/rs_81_58_1/usr.src/usr.bin/nsaaad/../../netscaler/aaad/naaad.c[359]: process_kernel_socket call to authenticate user :ica, vsid :716 /home/build/rs_81_58_1/usr.src/usr.bin/nsaaad/../../netscaler/aaad/ldap_drv.c[40]: start_ldap_auth attempting to auth /home/build/rs_81_58_1/usr.src/usr.bin/nsaaad/../../netscaler/aaad/ldap_drv.c[291]: receive_ldap_bind_event receive ldap bind event /home/build/rs_81_58_1/usr.src/usr.bin/nsaaad/../../netscaler/aaad/ldap_drv.c[551]: receive_ldap_user_search_event built group string for ica of: notepad /home/build/rs_81_58_1/usr.src/usr.bin/nsaaad/../../netscaler/aaad/naaad.c[1142]: send_accept sending accept to kernel for : ica However the first place I am checking is aaad.debug. Now this is a tool within the CLI. Login via SSH, hit shell and then navigate to /tmp and cat out aaad.debug. It will display authentication requests in real time, so all you have to do is get it running and recreate the issue that we saw in the previous slide. This is the sample of it working. You see we receive the send accept from the authentication server to the NetScaler. The NetScaler is not responsible for authenticating, but the LDAP server and we will accept or reject based on what we receive.

Aaad.debug root@ns# cat /tmp/aaad.debug Wed Aug 6 16:03:49 2008
/home/build/rs_81_58_1/usr.src/usr.bin/nsaaad/../../netscaler/aaad/naaad.c[359]: process_kernel_socket call to authenticate user :ica, vsid :716 Wed Aug 6 16:03: /home/build/rs_81_58_1/usr.src/usr.bin/nsaaad/../../netscaler/aaad/ldap_drv.c[40]: start_ldap_auth attempting to auth /home/build/rs_81_58_1/usr.src/usr.bin/nsaaad/../../netscaler/aaad/ldap_drv.c[291]: receive_ldap_bind_event receive ldap bind event Wed Aug 6 16:03: /home/build/rs_81_58_1/usr.src/usr.bin/nsaaad/../../netscaler/aaad/ldap_drv.c[551]: receive_ldap_user_search_event built group string for ica of: notepad /home/build/rs_81_58_1/usr.src/usr.bin/nsaaad/../../netscaler/aaad/naaad.c[1198]: send_reject sending reject to kernel for : ica Now in this example we see a failure occurring. We see the last line displaying a reject that we received. Now there are a couple of main reasons why we will fail The server settings are incorrect or network issues Bad password Invalid username By looking at the text we see this most likely to be a bad password. Why? Well we see that it reached the server, and was able to search though it. This eliminates the first issue where server settings are incorrect. We would see an invalid credentials message after the initial auth attempt. Second, we know that this is not a invalid username as the ldap was able to return the group membership of this user. If it was so, we would receive an user not found error prior to the reject.

External DMZ Internal Problem Types: LDAP Authorization NetScaler StoreFront SNIP or MIP VIP 1- Auth Settings 2- NS.log XenApp XenDesktop Authorization policies are not commonly deployed, but can be troubleshooted pretty easily. Outside of firewall rules, we can check the ns.log to see if they are being applied. Inner FW Port Rules: DNS (UDP) - 53 LDAP /LDAPS (TCP) - 389/636 HTTP: 443,80 NS Admin (TCP): 3010, 3008 ,22 Xen (XML/HTTP/HTTPS): 8080, 80, 443 ICA: 1494, 2598 Outer FW Port Rule: 443,80* (HTTP/TCP) nssslvpn.txt Ports and IP rules

Grep ns.log # grep sac /var/log/ns.log Aug 1 16:00:37 <local0.alert> /01/2008:23:00:37 GMT ns 1958 : SSLVPN HTTP_RESOURCEACCESS_DENIED : Context - User sac - Total_bytes_send Remote_host - Denied_url GET / - Denied_by_policy "SAC" - Group(s) "N/A" Aug 1 16:01:33 <local0.alert> /01/2008:23:01:33 GMT ns 2018 : SSLVPN HTTP_RESOURCEACCESS_DENIED : Context - User sac - Total_bytes_send Remote_host Denied_url GET /cvpn/hHBFHmhttp:// /citrix/NSG - Denied_by_policy "SAC" - Group(s) "N/A" Aug 1 16:01:34 <local0.alert> /01/2008:23:01:34 GMT ns 2019 : SSLVPN NONHTTP_RESOURCEACCESS_DENIED : Context - User sac - Client_ip Nat_ip "Mapped Ip" - Vserver :443 - Source : Destination :139 - Total_bytes_send Total_bytes_recv 0 - Denied_by_policy "SAC" - Group(s) "N/A" Aug 1 16:07:07 <local0.alert> /01/2008:23:07:07 GMT ns 2077 : SSLVPN HTTP_RESOURCEACCESS_DENIED : Context - User sac - Total_bytes_send Remote_host Denied_url GET /cvpn/9nVti7http:// /citrix/NSG - Denied_by_policy "SAC" - Group(s) "N/A" This can be accessed from the shell and all you have to do is grep for the user name or authorization policy. In this case, we see the policy denied. You can then make a decision to either relax the authorization policy or remove it all together for it to work. Grepping ns.log is helpful and goes beyond just auth policies. You can use to verify along with the nsconmsg to confirm that policies are being applied

External DMZ Internal Problem Types: LDAP 1- SF/WI Site Settings 2- SF/.WI Trace 3- Event Log App Enumeration NetScaler StoreFront SNIP or MIP VIP 1- ProfileSettings 2- NetScaler Trace 3- Certificate XenApp XenDesktop So let’s say authentication and authorization are not the issue. Well is the application enumerating? Can we see its icon? Well if so we can check the profile settings we have configured. We can check the XML settings on XenApp. On Web Interface and StoreFront we need to check the configuration settings. Event Viewer is also really helpful in diagnosing issues. Verify the firewall ports once again. In this case we usually need 8080 or 80 access to XenApp and 80 or 443 access to WI/SF. We have already stepped through profile and servers settings up earlier, and as with everything a NS trace will really help. Well lets say you’ve gone through your config, and everything checks out, and maybe your Wireshark skills are lacking, what are some other possibilities to check? Inner FW Port Rules: DNS (UDP) - 53 LDAP /LDAPS (TCP) - 389/636 HTTP: 443,80 NS Admin (TCP): 3010, 3008 ,22 Xen (XML/HTTP/HTTPS): 8080, 80, 443 ICA: 1494, 2598 Outer FW Port Rule: 443,80* (HTTP/TCP) 1- XML Settings 2- STA Logging 3- CDF Tracing nssslvpn.txt Ports and IP rules

openssl x509 -noout -modulus -in certificate.crt
Verify private key openssl x509 -noout -modulus -in certificate.crt openssl rsa -noout -modulus -in privateKey.key openssl req -noout -modulus -in CSR.csr Maybe you haven’t been able to get the cert installed yet and skipped that part in the wizard. If you continue to have issues, you might need to verify that your private key is the right one that was generated for the CSR and then the cert. You would be surpised how many times, keys get lost. We have three openssl commands that we can run to verify the following. A modulus will be returned that should match across the different files.

Verify the Certificate Chain
The certificate will be used as WI or SF has to trust it. It needs to have the proper linking with the intermediate cert. Using in this example It verifies the FQDN being used and most importantly, the Certificate Chain This example shows a properly configured certficate chain, indicated by the blue links You can verify the chained certificates by opening up the Certificate itself and looking at the Intermediate certs under the Certification Path tab Also, taking care of this now will help avoid issues with Mobile devices launching ICA sessions through the Gateway

Priority of Policies Priority Order
User (highest priority) Group Virtual Server Global (lowest priority) The numerical priority takes precedence regardless of where the policy is bound. If the policy that is bound to the Gateway virtual server, created with the wizard, is not being hit, then you’ll need to verify the policy priorities on the NetScaler. Policies will be applied in 4 levels – to the User, which is the highest priority, then Group, Virtual Server, and Global level which is the lowest priority. However, no matter at what level the policy is bound, the policy with the highest priority will always take precedence. Keep in mind, the lower the number, the higher the priority. Priority Number

How To See Policy Hits pol_hits Policy(LDAP) pol_hits Policy(PL_WB_ ) Verify that you’re hitting the right policy with the nsconmsg command in a SSH session. This tool shows which authentication policy you’re hitting also – so the first policy the user gets is the LDAP policy. So you can use this tool to verify which authentication policy the end user is hitting when the user firsts accesses the logon page If authentication is successful, then the session policy will need to be applied right after.

External DMZ Internal Problem Types: LDAP NetScaler App Launch STA path on SF/WI StoreFront SNIP or MIP VIP 1- NS Trace 2- STA Monitor (newnslog) 3- Licensing XenApp XenDesktop Lastly when applications aren’t launching, we need to turn our attention to a couple of places. We need to make sure the STA paths are correct on both NS and WI/SF. One important note is that they need to match. This can cause launching issues if not, due to the fact that the NetScaler might not know of a STA that might be issuing tickets and added in StoreFront. The Firewall rules need to be checked and lastly we need to potentially do a network trace to verify where the flow is breaking. Inner FW Port Rules: DNS (UDP) - 53 LDAP /LDAPS (TCP) - 389/636 HTTP: 443,80 NS Admin (TCP): 3010, 3008 ,22 Xen (XML/HTTP/HTTPS): 8080, 80, 443 ICA: 1494, 2598 Outer FW Port Rule: 443,80* (HTTP/TCP) CDF Tracing ICA file - ID Ports and IP rules

1:47:12 (CITRIX) SERVER line says HOSTNAME=cag, hostid is HOSTNAME=ns
License.log 1:47:12 (CITRIX) SERVER line says HOSTNAME=cag, hostid is HOSTNAME=ns 1:47:12 (CITRIX) Invalid hostid on SERVER line Users of CAG_SSLVPN_CCU: (Error: 2 licenses, unsupported by licensed serv Before discussing wireshark and the flows, licensing can be a problem area when it comes to deploying and is taken into consideration at the application launch step. If we leave it in SmartAccess mode, we take advantage of the policy engine on the NetScaler but we will use universal licenses. If you notice that certain users can launch and others can’t, this can point to your environment not being properly licensed. Apply the license and reboot. Make sure the Global Auth settings are changed to the proper number of licenses, and if it isn’t being applied, drop into the shell and navigate to /var/log and analyze the license.log. This will indicate why the license isn’t being applied, whether it’s a wrong hostname, or it is expired.

Wireshark After verifying the STAs matching and licensing, let’s get a network trace, and open it up in WireShark. Make sure to start it with a packet size of 0, so the data is not truncated.

STA Ticket Response STA ID STA Ticket
We will want to search for the STA IP and follow the TCP stream. We should see the following in the body of the layer 7 traffic. The STA server then responds with its STA ID and the Ticket number This information gets added in the ICA file that gets sent back to the client STA Ticket

Analyze the Default.ica Values
40 = Port 2598 10 = Port 1494 STA ID STA Ticket We can download the ICA file to match this. Now to avoid complicating a deployment, its recommended to try this out with one STA server to isolate the issue, and make sure its not the service that is failing. Here’s a snippet of 2 key values in the ICA file The Address = the first value is the number 40 – which tells the Gateway that we want to use Session Reliability and instructs the Gateway to communicate to the back end server over port 2598 If Session Reliability was disabled, it would show 10, which would force the Gateway to use port 1494 The second value is the STA server ID, this is how the Gateway knows which STA server to reach out to in cases where there are multiple STA servers Then there’s the STA ticket ID that’s being held on the STA server which has the session information that StoreFront provided

NetScaler Gateway and STA
STA ID You can verify that the STA server is reachable and the ID that it is returning back to the NS. The STA ID should match across. If the STA IDs are mixed, isolate one STA server on SF and step through them if one is failing. If you get mixed results with applications launching and failing, it could be a problem with the service on the XenApp server. Use the STA server that is consistent. UP State

Citrix Insight Services
If you continue to have questions with your deployment, and things do not appear stable. Upload a techsupport file to taas.citrix.com or Citrix Insight Service. The NetScaler tech support bundle, sometimes referred to as the collector file, is one of your very best resources in analyzing the health of your NetScaler appliance, and the site that we have corrected is very straight forward and let you know if you are encountering any networking issues such as conflicting Ips, or a hardware failure, or a crash file.

Resources How To Configure NetScaler Gateway with StoreFront – Deployment Guide How To Troubleshoot Authentication on NetScaler - CTX114999 How To Troubleshoot License Issues – CTX11644 How To Verify Policy Hits on NetScaler - CTX138840 How To Enable STA Logging on XenApp - CTX120589 How To Capture nstrace from NetScaler CLI - CTX120941 NetScaler + Wireshark – Citrix Blog Resources we used during troubleshooting. Make sure to download this deck and use these when deploying your NetScaler Gateway.

Questions? Alright, who has the first question on how to make turn your NetScaler Gateway into a successful deployment

Before you leave… Conference Surveys are available online at starting Thursday, May 14 at 9:00 a.m. Those who provide feedback by 6pm, Friday, May 15th will receive: $20 Amazon e-gift card Name entered in a drawing for a free Trip to Synergy 2016 (5 chances) Download presentations starting Monday May, 18th from the My Event Planning tool

NetScaler Gateway with Citrix Desktops & Apps

Similar presentations

Presentation on theme: "NetScaler Gateway with Citrix Desktops & Apps"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

NetScaler Gateway with Citrix Desktops & Apps

Similar presentations

Presentation on theme: "NetScaler Gateway with Citrix Desktops & Apps"— Presentation transcript:

Similar presentations

About project

Feedback