Anyone run into "Agent Error" status due to CtxUvi...
# citrix-vad
m
Anyone run into "Agent Error" status due to CtxUvi when upgrading from CVAD 2203 CU4 to newer? Very erratic occurence of it. Difficult to nail down
👀 1
d
Yes. We had a ticket, but ours mostly cleared up after a change of AV vendor. There is also this thread about it: https://community.citrix.com/topic/253093-agent-error-after-upgrade-to-2203-cu5/ We have our internal documentation to quick fix it:
✅ 1
m
That's definatley the problem, who did you switch from and to if you don't mind me asking?
d
Switched from Defender to CrowdStrike. Also, Citrix did tell us that this is actually intentional when there is some issue detected in the CtxUvi processes to prevent black screens. If users can't log in, there won't be any black screen issues.
m
That makes perfect sense as we have multiple networks, and the network this is occuring on? Defender is on it
We have another mirrored network, but it's running Trellix, and we're at 2203 CU6, no issues.
d
Citrix also said that AV appears to be one of the primary triggers of this happening, but there could be other causes as well. Interesting to see that you have it on the Defender network as well. Good to know there is some correlation to our experience as well.
m
Citrix indicated to us it's likely group policy, however, we could find no trace of group policy casualty. We pressed Citrix support for specifics on other impacted customers who had deteremined culprit GPO and what the GPO/s were, which Citrix could not provide (which I thought curious as it begs the question is it a GPO that should be enabled that Citrix doesn't want to advertise compatibility issues with?). We abandoned the CU5 upgrade and chalked it up to CU5 "buggyness", however, CU6 also shares the problem so we have to skin this cat. Defender is in passive mode on the impacted network with Trellix running active. The group policy fix in fact doesn't work for my bunch as whatever is happening behind the scenes to flip that DWORD, also simultanesouly impacts our smartcard service which I presume is probably tied to the ICAs, so end users can't re-authenticate if they disconnect and attempt to reconnect to a session. Sounds suspeciously similar to https://support.citrix.com/s/article/CTX269693-smartcard-device-is-disconnected-from-i[…]hile-renewing-the-certificates-on-smart-card?language=en_US
j
Interesting. I wonder what the differences are between the UviEnabled value and UviStatusDisabled values are? What if you set/create the UviEnabled value and make sure it's set to 1? Does this help?
Copy code
Set-RegistryKey -Key "HKLM:\SYSTEM\CurrentControlSet\Services\CtxUvi" -Name "UviStatusDisabled" -Value "0" -Type DWord
        Set-RegistryKey -Key "HKLM:\SYSTEM\CurrentControlSet\Services\CtxUvi" -Name "UviEnabled" -Value "1" -Type DWord
m
I don't have a registry key for UviEnabled... Curious, is it a -force option or something for Citrix API hook handling? Think continue with fault?
j
1. Create that value if it doesn't exist. 2. Once the CtxUvi service starts when the VM starts, make sure nothing is changing under the "HKLM\SOFTWARE\Citrix\CtxHook\AppInit_DLLs\<hook name>" registry structure, which will cause issues. 3. Make sure you are applying all the correct antivirus exclusions as recommended by Citrix, such as " %SystemRoot%\System32\drivers\CtxUvi.sys".