Sooo….. Anyone out there using AppFlow on their Citrix Gateway? Well there was a bug identified in the 13.0 Build 36.27. This bug…. This bug made sure that the setting to disable AppFlow globally was not respected. If you disabled it there, nothing happened. Example, if you had an AppFlow policy dumping the data to MAS (Management Analytic Server), it would still see it as enabled unless you disabled the policy explicitly. The PPE (packet processing engine) would still crash and cause it to fail-over repeatedly between an HA configured pair of Gateways. This took about a week to find and a bit longer to fix as we had to wait until the release of 13.0 Build 41.20 to completely resolve the issue. Below are the pictures of the settings and the versions. So if you are running 13.0 Build 36.27, upgrade IMMEDIATELY! Here is the link to the firmware version to save you! AppFlow Fix!
Have several new articles I’m prepping to release as well as a subscribe option! Sorry it has been dark for a bit. Just trying to get everything written the way I want it before publishing! I’ve got a write-up on configuring the Citrix Gateway (still Netscaler to me) for forward SSL proxy, configuring SSSD for Linux CentOS 7.6, and maybe a thing or two about some oddities with some Citrix Gateway version 13. Ran into an issue with AppFlow that was a reported bug back in the 10.5 nCore days. It hit and it hit hard. It didn’t respect the global disabling feature. But, more on that in the upcoming article! But, a foreshadow…. they fixed it in the current September release of the nCore firmware!! So if you had the first iteration, upgrade it now!!
There’s something afoot at the Circle K… So I’m sure you’ve had some fun getting the Linux VDA to work on XenApp 7.15LTSR or the newer 1906.2 pr 1909. Well…… it is a bit of a challenge. I have had some difficulties myself. It kind of felt like nailing Jell-O to a tree or lighting a flameproof candle. But…. I did manage to get it working. There are some caveats to this though. I have only been able to get it to work with Winbind and if there isn’t a define UPN set in the AD profile for the user. I’m working to resolve the issues with SSSD, then it would support the UPNs.
However, on with the show!
First off, you need to get a base install of CentOS 7.6 with Server GUI option ticked on the install. After the base install, you will have to get some files downloaded and ready to install.
(https://drive.google.com/open?id=1IFqZKOstw_mxKiSD5hcrS_uhZp2UOMGa)
I just happened to upload the files that you need to get it all sorted and working.
After you have the base install finished, you will need to do the needful with the steps below. The order matters as there are dependencies. You can follow the step-by-step in the Citrix Easy Install for the start of the setup and make sure to select Winbind for this one. As soon as I get SSSD working, then I will post the update to this.(https://docs.citrix.com/en-us/linux-virtual-delivery-agent/current-release/installation-overview/easy-install.html)
Here are the steps!
- Install LinuxVDA with (sudo yum localinstall -y LinuxVDA-1903.el7_x.rpm).
- Run the install script from /opt/Citrix/VDA/sbin/ (sudo ./opt/Citrix/VDA/sbin/ctxinstall.sh) *if you run into issue, use cd /opt/Citrix/VDA/sbin/ and then enter sudo ./ctxinstall.sh*
- Install webkitgtk with (sudo yum localinstall -y webkitgtk-2.4.9-1.2.x86_64.rpm)
- Install ICA client with (sudo yum localinstall -y ICAClient-rhel-19.3.0.5-0.x86_64.rpm).
- Copy over .pem files to /opt/Citrix/ICAClient/keystore/cacerts (sudo cp /home/user/Downloads/entrust_g2_ca.pem /opt/Citrix/ICAClient/keystore/cacerts) and /opt/Citrix/ICAClient/keystore/intcerts (sudo cp /home/user/Downloads/entrust_l1k.pem /opt/Citrix/ICAClient/keystore/intcerts). *only if you are using Entrust certs*
- Run (sudo ./opt/Citrix/ICAClient/util/ctx_rehash) to apply cert. * if you run into issue, use cd /opt/Citrix/VDA/ICAClient/util and then enter sudo ./ctx_rehash*
- Copy over color.pkla to /etc/polkit-1/localauthority/50-local.d/ (sudo cp /home/user/Downloads/color.pkla /etc/polkit-1/localauthority/50-local.d/)
- Setup machine catalog and delivery group on Citrix Studio.
- Go back to Linux machine and enter sudo shutdown -r now to reboot.
With that, you now have the words of Rufus and the code for time travel plugged in. Be excellent to each other!
Sorry for not having the content up in the month of June. It has been crazy busy all around! I have some pics to post from Synergy. I’m posting up my article about installing Linux VDA on 7.6 CentOS and all the fun getting it to work. I have it working with Winbind but no dice on SSSD as of yet. Should have it posted sometime tomorrow. Get your reading goggles ready!
Headed down to Synergy 2019 in Atlanta! First time getting to go there and looking forward to meeting other engineers and learning and sharing the Citrix experience!
Welcome back to the same bat time, same bat channel. We recently migrated SiteManager over to a new 3.18a version and to our new enterprise Citrix farm. Almost everything work perfectly, except that it didn’t. We ran into some fun with a single port. SCCP. Not sure if it is using SCCP or just port 2000, but it stopped some functionality. So if you have your DPS server on a different subnet, make sure to have this port open!
Looks like another fun day in the wild world of virtualization. After having setup a new enterprise farm, you typically try and copy over your policies from your known good farm. Well….. Sometimes this works well. Sometimes it does not. What is worse, is when you build an entirely new infrastructure and have it on its own subnet and then things start to break after you move user over. It appears that the default setting of “Direct connections to print servers” is enabled even if you don’t define it (it was enabled as it was copied from the old farm policy). Hmmmm. How could this bite me?
Well, let’s delve into that, shall we!? Several users were reporting that their printers and TWAIN scanners were not mapping. I checked and verified this. On some users, it wouldn’t map at all. Some it was a slow mapping. I checked the logs on the servers. Nothing to be found there. I engaged Citrix for this. We checked all the settings and policies over (extremely helpful TRM we have! He really is amazing!) So I ran into Google’s rabbit hole. After some soul searching, I mean searching for the answer, I came across this: https://support.citrix.com/article/CTX203252. This explains users have the same issue in a cloud situation. This reminded me that we had moved subnets (again, you’d think that would’ve been in the forefront of my mind since we had other firewall related issues which I will talk about in another post). So I explicitly disabled the setting and it worked immediately.
Since I have found this, now it is time to review the rest of the default policies and see if any of the rest of them need explicit disabling.
Ran across this video explaining Adaptive HDX transport. Rather good video that I wanted to share so that the people can get the information. Going to delve deeper into this new protocol that is delivering ICA over UDP versus TCP. Might have some more information on it in a future post!
So you have have SiteManager and you want to virtualize this app into Citrix. You may have noticed there are some caveats with. One of the issues that we encountered (we’ve been running this for several years across several versions now), is that you have to be creative to separate users because of the reporting port that is needed.
When a user logs in, it creates a port based on the INI file. That works all fine and well until player two enters the arena. So….. We had to utilize a set of scripts to create this separation of user space and create the random port per user. We’ve tried these in powershell and VB script. There wasn’t any performance difference or ease of configuration from what we found. I’ve added the scripts below so that you can more easily onboard this app into XenApp.
This launching script you will point in Citrix Studio is the one below. It is a batch script .bat.
REM TransportLaunch
@echo off
start /wait C:\SMAPP\FileshareMapDrives.vbs
start /wait C:\SMAPP\SmappUpdateINI.vbs
start /B /D Y:\SMAPP318-CTXTST\ C:\SMAPP\smapp.exe
This one will run and call the other visual basic scripts that actually do the work.
The first work script is to map the drive we are going to store the smdb file and the smapp.ini file that will contain the random port number.
'FileshareMapDrives checks "fileshareserver" fileshare share for the user's app configuration directory.
'If it is not there, it creates it and maps the "M" drive in the citrix session to it.
DIM fso, MyFile, strCurrentLine, strPortNum, strNewPortNum, strUserName, CitrixServer
'Determine which Citrix server you have attached to.
Set WSHNetwork = CreateObject("WScript.Network")
' CitrixServer = WSHNetwork.ComputerName
CitrixServer = "fileshareserver"
Set fso = CreateObject("Scripting.FileSystemObject")
' Retrieve logged in username
strUserName = WSHNetwork.UserName
' Determine if the user's directory exists. If not create it
If fso.FolderExists("\\" & CitrixServer & "\fileshare\" & strUserName) THEN
Else
fso.CreateFolder("\\" & CitrixServer & "\fileshare\" & strUserName)
End If
' Map new Drive for the INI file
On Error Resume Next
WSHNetwork.MapNetworkDrive "M:", "\\" & CitrixServer & "\fileshare\" & strUserName
If Err.Number <> 0 Then
On Error GoTo 0
WSHNetwork.RemoveNetworkDrive "M:", True, True
WSHNetwork.MapNetworkDrive "M:", "\\" & CitrixServer & "\fileshare\" & strUserName
End If
On Error GoTo 0
'wscript.sleep(5000)
'wscript.echo "Maps are done"
'SmappUpdateINI
DIM fso, MyFile, strCurrentLine, strPortNum, strNewPortNum, strUserName, CitrixServer
After the above script runs, it will have your location mapped to point the smapp.exe file to the smapp.ini file it will need to load. Next up, the smappupdate.ini script, which is also a visual basic script.
Set fso = CreateObject("Scripting.FileSystemObject")
If fso.FolderExists("M:\SMAPP318-CTXTST") THEN
' wscript.echo "M:\SMAPP318-CTXTST exists"
Else
fso.CreateFolder("M:\SMAPP318-CTXTST")
' wscript.echo "M:\SMAPP318-CTXTST did not exist and I just created it"
End If
' Determine if the directory SMAPP318-CTXTST exists. If not create it
If fso.FileExists("M:\SMAPP318-CTXTST\SMDBL00.DB") Then
Else
fso.CopyFile "\\sharelocation\SMAPP318-CTXTST\SMDB\SMDBL00.DB", "M:\SMAPP318-CTXTST\", True
End If
If fso.FileExists("M:\SMAPP318-CTXTST\SMAPP.INI") Then
Else
' Open the file. Change the path to where you have your file saved.
Set MyFile = fso.OpenTextFile("\\sharelocation\SMAPP318-CTXTST\SMDB\SMAPP.INI", 1, TRUE)
' Create a temp file to copy into.
Set fs1 = fso.CreateTextFile ("\\sharelocation\SMAPP318-CTXTST\SMDB\Temp.txt",True)
fs1.close
Set MyFile2 = fso.OpenTextFile ("\\sharelocation\SMAPP318-CTXTST\SMDB\Temp.txt", 8)
' Copy each line into the temp file.
Do Until MyFile.AtEndOfStream
Line = MyFile.ReadLine
' Increment the port number by 1.
If InStr(1,Line, "Status Monitor Port=",1) Then
strPortNum = Right(Line, 5)
PortNum = CLng(strPortNum)
PortNum = PortNum + 1
strNewPortNum = Cstr(PortNum)
MyFile2.WriteLine("Status Monitor Port=" & strNewPortNum)
else
MyFile2.writeline line
End If
Loop
Set MyFile = nothing
Set MyFile2 = nothing
' Copy the temp file over original file and create a backup copy (UserName.bak).
fso.CopyFile "\\sharelocation\SMAPP318-CTXTST\SMDB\Temp.txt", "\\sharelocation\SMAPP318-CTXTST\SMDB\SMAPP.INI", true
fso.CopyFile "\\sharelocation\SMAPP318-CTXTST\SMDB\Temp.txt", "\\sharelocation\SMAPP318-CTXTST\SMDB\" & strUserName & ".BAK", True
fso.CopyFile "\\sharelocation\SMAPP318-CTXTST\SMDB\Temp.txt", "M:\SMAPP318-CTXTST\SMAPP.INI", true
' MyFile2.Close
' Set MytFile2 = nothing
fso.DeleteFile "\\sharelocation\SMAPP318-CTXTST\SMDB\Temp.txt"
End If
With these three scripts, you should be able to run SiteManager in your XenApp environment!
Hello and good morning. These are the adventures of the starship…. wait. That’s right. Wrong channel. Wrong show.
So….. I decided to upgraded to Fedora 29 ( really really nice btw) at the end of October. Everything was hunky and even dory one would say. Except for something. Something very painful. I tried to use my Citrix Receiver to connect. And what happened pray tell? It wouldn’t connect. Some people have had success with loading additional libraries and finagling around to get it working. I have not as of yet. I’m waiting for a new release of the Linux Receiver instead of battling this one. I’ve seen on some forums that this is a common issue with Fedora and the receiver. So you may want to hold out on upgrading to Fedora 29 until this issue is resolved.
Update 03/27/19 – Instead of fighting the battle of waiting and fighting, I have skipped past fixing this for now and went the way of HTML5 client. Looks like a viable option for this! I’ll be posting about the HTML5 client soon!