Quite recently I was at a customer where they had an SDX setup with single instances and needed to be upgraded and converted to an HA setup.
Well easy does it I created the instances on the second SDX and started creating HA sets. Numerous went fine and then one started giving errors. Could not propagate from the primary and after checking SSH/SCP access this would fail as well. I logged in through the console of SDX/SVM and saw that the sshd daemon wasn’t starting anymore. (On a side note all of the original SDX instances were upgraded in regard to the exploit of last December)
After some troubleshooting I came across the following discussion article: https://discussions.citrix.com/topic/405628-unable-to-connect-to-adc-nsip-version-121-and-130-using-sshsftp
The discussion referred to an support article regarding false positives and an SSH vulnerability:
After checking the sshd_config file and commenting out the following:
The sshd daemon started again and the HA propagation and synchronisation started instantly. I’ve had this on several other instances as well and they all needed the above commenting out of the lines.
Hope it helps!
While doing some lab work I came across an issue that the Domain Admin accounts could not register on the manageotp site while Domain Users could. This got me figuring it out.
For the use of Native OTP on the ADC we need to use an bind account for Active Directory which has the appropriate write permissions on the userParameters value of the users.
When we delegate control of the exact write permission of the userParameters everything is fine for normal users but administrator accounts won’t work. When we use a service account with full blown domain administrator permissions as the bind account then it works.
After some researching I came across this old article which explained the behavior:
Long story short, if any user is also a member of a high privileged group the AdminSDHolder protection will prevent this. There is a way that inheritance can be enabled but this is mostly not recommended as you will open up a whole lot of extra security risks.
If it isn’t needed then just delegate control of the needed permissions otherwise use an bind account with domain admin permissions.
For some in depth knowledge of AdminSDHolder and it’s workings see the following article:
Fun quick fact that I’ve encountered when deploying a ADC Gateway GSLB setup for a customer! You only have to enroll once with the nFactor/Native OTP on one of the ADC’s. (when having a Active Directory Domain across multiple datacenter sites)
The setup of choice:
- Two ADC appliances in HA set on each site
- GSLB enabled in active/passive mode for the Gateway across both sites
- Native OTP enabled and active as the way for authentication
- Active Directory Domain across two sites
There is no difference in configuration whatsoever because the magic of Native OTP depends on Active Directory.
Configure each ADC identically with the nFactor/Native OTP setup and enable GSLB and you’re done. I must admit at first I thought that I would need to enroll at both gateways independent but happily this is not the case.
For the configuration steps see common examples as below:
Quite recently I’ve deployed a POC setup for a customer who wanted to leverage NVIDIA vGPU for their XenDesktop environment. In regards to all the prerequisites being met the VM’s wouldn’t boot when trying to test this on the base build of vSphere 6(the latest version that could be downloaded from the site) and the dedicated hardware.
After some time troubleshooting the issue was in the base build of VMware which was downloaded from the site. It included a hotfix which in turn would kill the vGPU support / integration. The resolution was updating the host to the latest level of patches. (the host at first was standalone being prepped to be inserted into the cluster of the customer, once joined update manager could do the rest)
For reference see the following articles:
Hope this helps!
Quite recently I came across an issue when deploying a VPX instance on VMware 6.5, which resulted in a bug of the VPX image and underlying physical hardware.
For reference the following hardware was backing the hypervisor:
Intel(R) Xeon(R) Gold 5118 CPU @ 2.30GHz
VMware ESXi, 6.5.0, 7967591 with vSAN
NetScaler VPX 12.0 57.24nc
When deploying the VPX appliance it will get the default VM version 7 which needs to get upgraded to VM version 11/13 to support VMXNET3 NIC interfaces, well easily said and done configured the setup and booted the appliance and got stumped with the following error:
right.. that’s a beauty.. after some troubleshooting and migrating the host to another host/cluster it started booting. Migrated it back and crashes.. reimported the appliance let it stay at hardware level 7, and upgraded it to 11 and still works, went to 13 again and crash.. Ok so this is not a user error :).
Logged a case with Citrix support and after some time got the reply this is in regards to a known issue with Intel Xeon Gold processors. The resolvement should be in NetScaler 12.1 build which is expected to release Q3 this year.
For now the workaround is to keep it at level 11, as a reference case# 77116209 can be used to log the same if it applies to your setup.
With the release of NS12.1 49.23.nc for NetScaler and NMAS you can now upgrade to the latest hardware level and everything works as expected. Also the default dashboard view won’t give any error of any kind in regards to the undefined message which would popup.
Came across a very peculiar issue at a customer in regards to the values:
- Max Login Attempts
- Failed Login Timeout
As soon as a value has been put in you could not reset it to the default value of 0, not from the GUI or CLI it would just not accept it as a value
After a support case and some days further the solution is maybe simple but I didn’t had it in mind, the simple unset command on the vpn vserver in regards to the maxloginattempts resolves it.
Hope it helps you out as well.
UPDATE: https://support.citrix.com/article/CTX234177 got published for this
We all know it, the once in a while “it’s slow logging on..” and then it gets dropped at the escalation desk for a resolution. So I got the call for troubleshooting this issue. Since I knew from previous experiences that uberAgent is the troubleshooting tool you will want for this I contacted them and requested the consulting license at https://uberagent.com/ (thanks to Helge Klein) did the installation of Splunk / Uberagent and got myself a monitoring baseline to work with. A little background on the setup:
- vSphere 6.0
- XenDesktop 7.15 / MCS – Windows 8.1 & Windows Server 2012 R2
- RES WorkspaceManager 10.1.300.1
The problem was at times users would have a profile initialization of 90 seconds! and at times the user shell would hang..
After a period of two weeks I would have my baseline with uberAgent and filtered out that this would be random very early start of the day or just after break time. No funny business whatsoever in the environment and no lack of resources e.g. iops or cpu/memory exhaustion, drilling down in some user trending with uberAgent I came to a somewhat recurring user base that experienced the issue. Ok! That helps and after that I could reproduce it with the useraccounts in question displaying the following screen:Dropped this in the resrockstars.slack.com group and got a quick reply from Dennis van Dam in regards to traceviewer and came to the following:This in turn pointed me out to the following support article:Problem resolved and a happy customer! Hope this helps you out as well.
HOWTO: Create a trace file
When I started to rebuild my lab I came across the most strangest thing when configuring my NetScaler’s again. First a little background regarding my setup:
VMware ESXi 6.5u1 Hypervisors
NetScaler VPX 1000 Platinum Appliances
Distributed vSwitches with vlan trunks enabled
Dedicated NSVLAN for management (tagged)
Data transport vlan tagged
Whilst configuring and setting op the first and secondary nodes I’ve let the default appliance imports intact, that is 2vcpu and 2gb of ram and changed the E1000 nic’s to VMXNET3 and upgraded the VM compatibility format to the latest level. Nothing wrong here and started configuring both appliances with their NSIP’s respectively. Created the HA set and all was well.
Then it was time to put in the second nic which I’m going to use for my data transport with all vlan tagged interfaces and ip’s. Gave both appliances a shutdown and configured the nic’s accordingly (so it seemed at the time it was late ?)
First node came back flawlessly but the second node wasn’t reachable anymore.. So put open the hypervisor console and I saw error messages regarding the nic and that the instance had crashed. When I would log in with the nsroot account I would get nsnet_connect prevents logon… Well ok.. that one was familiar to me with in mind the switch of E1000 and VMXNET3 devices (had this when upgrading a customer’s setup and that was the VM compatibility level, because you will need the latest build to be able to use VMXNET3, the default appliance level isn’t enough) but I’ve got both appliances up to date… I thought what the !%!@% and logged in with the nsrecover username to be able to login to the shell and dig in deeper. Thank god that worked and I was able to run the command ns_hw_err.bash which will check for any hardware error. And yes I instantly got the nic not present and reachable message. Looked at the configuration of the nic’s and a nice homer simpson moment the nic in question was still a E1000.. right… so turned it off and removed the nic, re-added it with the same MAC and presto all is well again.
Moral of the story double check your network settings when using VMXNET3!!!!
Recently I got involved at a customer location which was going to use Remote PC catalogs in combination with their XenDesktop / XenApp 7.15 environment. This was no problem whatsoever to configure but on closer testing I encountered a bug that when you create for example a delivery group called “Windows 10 Remote PC” and adding more than one desktop the second, third and so on would get the published name of the local computer name e.g. WSDELL34951 which doesn’t comply with a standard name. The following can be observed for the delivery group name:Normally you would see at “PublishedName” an empty value, to correct this take a note of the “Uid” number and put in the following command:In this case my id was 4, and voila this will correct the name in StoreFront like in the following screenshot:
For the Multi Licensing part this needs to be done at the same level in powershell, see the following article:Multi-type licensing
In the previous screenshot you will see:
“LicenseModel” & “ProductCode” these need to be compliant with their respective edition of XenApp or XenDesktop license model, management is then per delivery group and not applicable for the entire site anymore. This would be a default for every new delivery group that will be created unless like in above screenshot you will add the “LicenseModel” & “ProductCode”
Hope this helps!
Finally had some time to implement the NetScaler Secure Web Gateway in my lab. I’ve put together a small document with my findings attached here: NFTL_TF_NSWG
comments or questions please let me know.