Is anyone using crowdstrike with App Layering? If so any tricks to installing it? Are you using an App Layer or the platform layer. I assume using the VDI=1 directive but are there any guids to uninstall?

Yup. Have it in it's own layer. VDI=1 NO_START=1 is a requirement, BypassLayerCheck is also needed so you don't have to reboot the layer after install. Else you have to rip some registry keys before finalizing. HKEY_LOCAL_MACHINE\SYSTEM\CrowdStrike\{9b03c1d9-3138-44ed-9fae-d9f4c034b88d}\{16e0423f-7058-48c9-a204-725362b67639}\Default\AG HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CSAgent\Sim\AG

Thanks Paul Appreciate it

Good to know, Paul. We're currently battling CS with App Layering.

Has anyone seen that the CrowdStrike service wont autostart with a timeout but then if you logon and start it it works.

@Paul Brown, dumb question because we can't get a good answer from our own CS team. We're building our image using CS in a Platform layer (not important here) using the VDI=1 switch. We compile the image, and then use a PVS boot script to switch that disk to Private mode, boot it and edit it by performing a few tasks, then shut it down and switch the vDisk to Standard. We are doing nothing to CS during that time it's cracked open. Should we be? CS can't answer that question for us.

lol its obviously all your fault Nick

i disagree

@Nick Panaccio sorry for late response had internet issues all day. Every time you reopen a master image you have to rip out the above reg keys before sealing up again. Beware that your cyber team may have reg modification polices in place that stop you. You will need to explain you’re helping them by not polluting their console with duplicate entries and that they should allow the gold image machines to make this change. Also whatever policy is in place on the final running machines should have auto updates disabled (if the machines are non persistent) for the same reasons. This info came from CS directly. They used to have a video explaining it. Here’s a copy cached on internet archive http://web.archive.org/web/20211101161019/https://crowdstrike.wistia.com/medias/he1qicxcft

Ah damn, video doesn't play. Appreciate the other info, though - CS finally admitted that most of their clients disable autoupdate (which our in-house CS team vehemently denied).

Any time you boot an image CS will start, tattoo those registry keys with a unique ID (if they do not exist), and then attempt to check in. That's why on reseal the reg keys need deleting. The CS policy the master image machines are in need Tamper Protection Disabled, else you cannot delete them. For Non persistent Citrix machines of any type we have two Crowdstrike console policies: One targets the master images, allows us to uninstall / install new versions and allows us to clean up the above mentioned keys. Since we use AppLayer for 90% of our images we don't often need to unseal images, but we do have a workload in Azure that we perform this process on. The Citrix production policy has all the screws turned, since our cyber team be like that. Everything will work "fine" without doing any of this. It's really just a courtesy cleanup to make the CS portal not fill up with bad data. If your cyber team are being jerks spin up a couple thousand non-persistent VMs from that image, then reboot them a few times. They'll come round pretty soon.

So if we don't clean it up it'll inconvenience them? Say no more.

Sorry to rekindle this thread but we’re fighting CrowdStrike in a layered image. We’re following all the steps mentioned in this thread and thought we had a functional install until we started experiencing random VDA reboots. Turns out that if CrowdStrike and FSLogix using Cloud Cache coexist a session logoff can trigger a reboot. We don’t have the issue using FSLogix VHD locations. We have parallel cases open with CrowdStrike and Microsoft. In troubleshooting we were asked to create a persistent image, and that all the recommended FSLogic exclusions are in place. Ironically with the persistent image, we’re not experiencing the issue. ATM, we’re in belief the persistent machine has the exclusions cached to the machine. If we leave the non-persistent machine online for a yet-to-be-determined amount of time, it also doesn’t have the issue. All I can get from CrowdStrike to verify the exclusions are replicated to the machine… “Once you have confirmed installation is complete, leave the VDI image online long enough to ensure all sensor files and/or any changes made to policies have been applied” ClownStrike has suggested that the policy is replicated to the machine once it’s no longer talking to http://Ifodown01-b.cloudsink.net What are you guys doing to verify the CrowsStrike exclusions are included in your app layer?

I have never heard of this being required before.

From a CrowdStrike internal document…

But is your layer ever in a state that policy would apply?

They do but it can take up to an hour, no bueno if you’re also trying to do auto-scale.

An hour is kind of ridiculous

So, right now we’re pursuing trying to bake the policy in the install and haven’t done so successfully yet.

I don’t see how that document flies in an MCS scenario as there’s no need for the master to be on the domain. But it concerns me that from what you are saying, there is a window of time (up to an hour!) where policy is not applied. Will bring that up to our internal team and see what they say.

I’ve also asked for clarity on the domain membership requirement, I’m hopeful that a domain-joined provisioned layered image is sufficient.

CS? Now I know why I woke up angry. When we build our layer with CS installed, our guys are letting the image just sit for 20+ minutes while it waits to pull down all relevant policies, as they were told there was no way to force this.

I guess I don’t mind having to wait, my problem is, how do you know when it’s done?

That I couldn't tell you. I think our guys have CS console access and they check there.

Coming back to this. I have a meeting scheduled with our cyber team to discuss, as the vendor documentation seems to contradict itself. There is the above linked document "*How to install or update the Windows sensor on a non-persistent gold image, VM, or VDI template*" which details a requirement for the template machine to be domain joined and left running for an indeterminate period of time for policy to apply. Both of which are not the norm for building MCS masters. Then there is the document i think most of us more closely align to "*Installing/Updating the Falcon sensor for Windows with VMWare Linked or Instant Clones*" which, aside from the heavy VMware bias, is pretty much how MCS works, and how we have been building since day one. This has the additional flag of NO_START=1 and does not detail the requirements to have the master image domain joined, or left running for a period of time, which makes sense, since the software itself is not running because of the NO_START flag. But does that introduce a delay of x time where the machine is not protected until it pulls down policy.....?

FWIW, in our MCS images, our install switch is CID=#SID# GROUPING_TAGS="CS_Sux" ProvNoWait=1 NO_START=1

ProvNoWait=1 is an interesting new twist.