Cortex XDR with Citrix App Layering and MCS

[BocoIP]

We're in the process of installing a new setup with Citrix App Layering (Full User layers) and MCS. I've followed the suggestions here on non-persistent installation (VDI_ENABLED=1); even though our setup technically is sort of persistent (because of the Full User layers), it's still Golden Image-based and therefore needs to be VDI enabled. And this works fine as long as I'm editing the OS layer (which is the only supported layer, according to the same documentation), with Cortex XDR showing up in the dashboard as installation type VDI, with a golden image ID. But when I publish an image based on this layer, it is no longer a VDI type, but rather a Standard installation type, and the golden image ID is missing.

While this technically works, and the endpoints get policy updates and show up in the dashboard ok, they're being duplicated at every boot, with the "old" instance remaining as Disconnected. So after for example five boots of a VM, I have one Connected and 4 Disconnected endpoints in dashboard. As far as I understand, this is exactly what the VDI_ENABLED=1 flag is supposed to remedy, but as it gets lost in the publication process, these are behaving like they're standard installations.

My guess is that this is something that's set in the registry, which we (according to the support document) have added as an exception to Citrix App Layering: 

Add the Cortex XDR agent to the Citrix App Layering exclusion list.

Add the following entry to the Windows Registry:

HKLM\SYSTEM\CurrentControlSet\Services\Unirsd\ExcludeKey

[REG_SZ] = "\Registry\Machine\System\Cyvera"

I have tried looking around in those registry settings, but can't find what the VDI_ENABLED=1 part would be. So does anyone know what I need to include to get this working? Or is there something else I've missed or misunderstood?

[jcandelaria]

Hi BocolP,

Its not in the registry to check whether the agent is flag as vdi. Its on agent_settings.db. You have to use cytool command "cytool persist print agent_settings.db" then you will be able to see if the machine is installed as vdi and you will also see the golden image agent id. 

Your issue is most likely during the publication process where it doesnt take the OS base layer configuration changes of the image. I would suggest once you edit the OS image (install xdr as vdi enabled), save it first then edit again then do whatever task then save it again then publish. You can double check the setting by using the cytool command above to check if it has the right setting. If it has then you can publish again. 

If its still not taking it, then something is reverting the OS level changes you made during the publication.

[BocoIP]

Hi Jcandelaria,

Thanks for the info on the settings location. I created a new version of the OS layer, booted that up, and ran cytool persist print agent_settings.db on it. According to the output, it is VDI enabled: true and I can see a Golden image ID as well as a Golden image name. So the OS layer itself is still VDI enabled, as it should be.

But when I then start up a standard App layer with that same OS layer (or rather the previous version, but with nothing changed in between it's effectively the same), it is not VDI enabled and no golden image info exists. If I look at the Agent installation time (with cytool persist print agent_settings.db), I can see that the App layer's agent has an installation time of when I created the layer version, which is not the same as the installation time on the OS layer. So it would seem like it's sort of "reinstalling" the agent when the OS layer is used elsewhere, and at that point it gets some default settings which do not include VDI enabled settings.

I then created a new empty App layer with that OS layer, and in there the agent again is VDI enabled. So it would seem that my App layer breaks this installation somehow. Perhaps there are some Cortex components installed on that layer, maybe as a result of an update or something like that. I will have to try to set up that layer with an OS layer version without Cortex installed, so I can uninstall whatever is on the App layer.

Thank you for pointing me in the right direction! I will report back when I have more conclusive info, just in case someone else has this problem further down the line.

[jcandelaria]

Hi BocolP,

Yes please update the thread so anyone in our live community can use this thread as a future reference if scenario exist.

[BocoIP]

It appears I forgot to update the thread with my findings, so here's the same message I recently sent to someone who had the same issue:

Yes, we did manage to solve this. The problem seemed to be that we had updates happening in the wrong layer. We had Cortex installed in the OS layer, as per the instructions, but it had then auto-updated itself in another App layer, which then broke the installation, as we now had Cortex installed in two different layers.

If you're having similar problems, try isolating the installation so that you only have Cortex installed in the OS layer, and then remove all traces of Cortex from the App layer(s). I think I actually reinstalled my App layers from scratch just to get rid of Cortex (as conventional uninstall did not work, as it was installed in two layers). You could probably also uninstall Cortex from the OS layer in a new version, use that version for the App layer, and then uninstall Cortex from the App layer (as it will then be the only version in use), and then scrap the OS version and use the one with Cortex still installed, with the newest App layer version which now doesn't have its "own" Cortex.

To keep this from happening in the future, we have now created a policy in XDR Dashboard to not update the App layers, by creating a dynamic group including "Endpoint Name Contains CITRXAL" and "Endpoint Name !=*198000", which effectively picks up all App layers which are not the OS layer (198000). Your numbers might vary, I'm not sure if these are set or dynamic.

I hope this will help you get back on track with this. If you have any other questions, I'm happy to help if I can.