This message was deleted.

What about creating a new configuration set, add a couple of VDAs to that config set, and set "Switch to Service Agent" in WEM\Advanced Settings\Configuration\Agent Switch\? 🤷‍♂️

We can't (won't?) go that route because of how we have everything configure. We have multiple datacenters in each config set, so we need to cutover one at a time. Creating a config set for each to do that just wouldn't be feasible. Plus, these being non-persistent, I think that switch would get reverted at reboot.

Thats fair 🙂 What about installation parameter Cloud=1, has that been set? Otherwise I would it just keeps trying on-prem.

So if you take a couple of non presistent vms and place in a separate OU and only apply the update inside the WEM GPO ADMX to use the CCL. Add that ou inside the WEM service for bound agents. It goes back to on Prem WEM?

It has not been set, no - the initial installation was for on-prem. We figured we could modify something in the registry to point to Cloud, but it definitely seems like something else is needed. I ran procmon when I ran AgentConfigurationUtility switch -c, but it didn't seem to actually modify any flat files, nor did it do anything in the registry.

The reason I ask I had a hard time moving to the WEM service after being on Prem. For one client, I copied the golden image and update the agent switch that Daniel mentioned and deployed a couple separate and that did the job. But it was a bit of work.

Ray, we haven't been moving devices out of their OUs. What we've been trying is probably dirty, and I imagine that simply updating the image is going to be the path forward. I really just need to ensure that adding that CloudConnectorList reg value to a VDA that's using on-prem WEM doesn't blow anything up.

I would image if you could update the switch in the registry that may help on the handful. But I’m throwing out things now

Ray, HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Norskale\Agent Host\CloudAgent 0 or 1

Hmm, this may be an oversight by me when I filtered the ProcMon log. Didn't think to look in HKLM\System

or a strange location to place it 🙂

let's see if that does it

If your WEM configuration have been moved, then I would uninstall AppLayering, create a new golden image with Cloud=1 CloudConnectorList=cc1.nick.panaccio,cc2.nick.panaccio and start migrating a couple of VDAs. Your on-prem WEM would be removed from the equation, when doing it this way and your migration would be alot smoother, considering AppLayering isn't part of it 🙂 But let's see what Citrix says.

Don't think they're getting rid of AL just yet, but they can easily generate a new image with the latest WEM Service agent installed.

Thanks @Daniel Madsen for the location. @Nick Panaccio you will get this sorted out man, you're a sharp dude.

FWIW, my testing all looks successful (using my existing WEM agent pointed to on-prem). Add the CCL reg key, modify that Cloud=1 value, bounce the WEM service... bam, connects to WEM service, and the two local DBs are updated within 10 minutes. Need to validate the actual cutover by getting a new image with WEM Service agent installed, but this looks good. Even if it's not an officially supported method.

This is actually good to know, because many times I have went the long route. This will allow the same images to be used and allow you to control things at a lower level.

I'll report back with my findings.

@Nick Panaccio As we discussed yesterday, although not an official way to do the agent switch, but good to know the result. 😀

Still waiting on an image that has WEM Service agent pointed to cloud in it, but initial testing with an on-prem agent is looking good. I add the CloudConnectorList reg value to an on-prem agent and it still works as expected. I then stop the WEM service, change CloudHost to 1 in the registry, and start the WEM service and it connects to WEM Service in the cloud. About 15 minutes later, it is a fully functional client.

Maybe through in a "Refresh cache" and "Refresh agent host settings", when it's connected to WEM Service. Then you hopefully, doesn't have to wait 15 minutes.

Nah, I definitely have to wait 10 minutes or so for that to work. If you try it right away, you get 'notification failed' messages.

Dropping my 5 cents into the discussion 😁 What about a BISF startup script which removes the WEM Cache on the WC Disk? I usually avoid moving anything (apart from Eventlogs and Pagefile) to the WC disk.

I have no say in BISF, though I did just find out that we are still storing the local cache on the OS disk. Plan is for the new image to have it moved to WC so that upon first start, everything is literally starting fresh.

If you're moving it to the WC make sure to create a startup trigger via BIS-F to recreate & refresh the cache

I've done that in the past, but we have no intention of doing that unless there's a need.

I understand not having control in certain things. Which makes you find other ways to successfully achieve the desired outcome. But BIS-F would really help you. But if it’s not something you can do. Then go back to the older scripts you used to manual recycle the cache, although I have to say I had not had many issues with cache like I used to. If I do, then I used BIS-F, if a client says no, then I go back to the delete and refresh the cache upon startup. But it takes about 2-5 minutes at times for the agents. The only reason I move it, is because when the WEM service goes offline for whatever reason(which I haven’t seen yet) the WEM cache on a presistent drive will still drive that last configuration settings for any configuration you have defined .Where on a c Drive if the WEM services was to go down, then upon reboot it can’t pull anything down to cache. Al though I would say 98% of the cache issues on refresh citrix worked out.

My team has no control over the image build for non-persistent. Honestly, I'm good with that now. This stuff is all on them, and while I make suggestions, it's on them to go with them or not. At the end of the day, they're responsible for it.

Well, the good news is they have you to guide them. Hopefully they listen to you.

In case this helps anyone else, this is what I have done in our lower environments to migrate from on-prem WEM to WEM Service: 1. Enable the Discover Citrix Cloud Connectors from CVAD service policy on all target VDAs ahead of the move a. This policy will not affect on-prem WEM agents, and will only be used when the WEM agent is pointed to Cloud 2. Deploy a new image with WEM Service Agent 2309.1 installed, pointed to Cloud 3. Upon booting up, the VDAs use the configured Cloud Connectors to find their WEM config set and register That GPO setting made things 100% easier compared to manually entering CCs, especially in our environment where specific OUs use specific CCs. We use item-level targeting GPPs to apply the ListOfDDCs, which is what I was going to do earlier, but no longer. This method works beautifully.

Blog it 🙂