https://worldofeuc.com logo
Join Slack
Powered by
This message was deleted.
# citrix-vad
s
This message was deleted.
r
Check the listoffddc and see if it's updating. Or update it reboot and see.
j
check the 3 usual suspects? like ray said, listofddcs, gpo, personality.ini?
m
I updated 2 of the 3 and it still pulls it from somewhere when the desktop service restarts
I didn’t think this was an mcs machine, I’ll have to check now
so auto update is supposed to check if the initial configuration method changed, which it did, and then skip getting the ddcs from the site, but it’s not doing that and it looks like it’s pulling them from the citrix policy and it’s overwriting the listofddcs reg entry
r
Just for shits and giggles. Update listofddc, run gpupdate and see if it gets put back
m
yeah it does
I’ll have to tell them to move this machine to a new OU
j
local policy edit and forget it's there ftw
⤴️ 1
j
You can disable auto update of controllers via Citrix policy - i did this in most deployments and set them via GPP
👍 2
r
I can't remember which is which. I recall studio has a auto update but then I remember if using the GPO Citrix mmc has one. Just can't recall which is which at the moment.
s
all the above, and check this path - ram across this a few times in the past - https://support.citrix.com/article/CTX216883/vda-attempting-to-register-to-an-old-or-decomissioned-ddc-after-upgrade
l
Ive been dealing with this as well. If its an MCS persistent, check the personality.ini in c:\. That will override the policy or registry. If its not MCS, check the savedlistofddcs.xml in c:\programdata\citrix\pvsvmagent\brokeragentinfo (I think thats it). Ive also found that it can be a pain if you try to use cloud connectors in a different zone/RL than your host connection, so make sure they match.
If its PVS based, the savedlistofddcs.xml could be on the cache drive, so check there too.
s
path is correct. references in article above. key is editing with ps exec need to be local system. all items in this thread should sort you out though. Good suggestions Brian
r
Use the autoupdate policy set to prohibited. Otherwise the vda uses the cached listofsids and not the listofddcs.
👆 3
👍 2
r
Do you need to add a delay on the broker service? Or will it register fine after disabling the update policy and enabling list of ddc?
r
I you may need to reboot twice to be sure
m
Yeah the auto update feature is great in theory but I seem to run into stuff like this a lot
I've been bitten before where people have rebuilt DDCs because they got ransomwared and nobody ends up connecting to the new one because that list of sids never gets updated properly
j
The feature works fine, it’s a chicken egg scenario a lot of the time and an ordering of what kicks in when. Hence there is the option to turn it off via policy if the need is there, I personally turned it off in pretty much every cloud deployment ever and the same for site migration projects on prem
m
Ahhhh the @James Kindon image…
m
I'm trying to do the same thing as Mike but with a on-prem MCS to cloud connector MCS machine. I know delivery controllers were specified during the VDA installation. I created a GPO to set the ListofDDCs registry value and it applies, but the broker service must start faster than the registry value can apply. On boot, the VDA registers with the on-prem delivery controllers. If I restart the broker service, it correctly registers with the cloud connectors. I think I'm going to have to re-configure the VDA to look for the ListOfDDCs instead of specifying them as manual.
r
Yep to use gpo you want to install with do it later. You could do things like start the desktop service with a script that first does a gpupdate but thats kind of a hack.
👍 1
m
I’ve moved this machine to a whole new OU and it’s STILL pulling policy off the old delivery controllers…
l
what is in the personality.ini file?
I think you are fighting information ON the VDA rather than FROM somewhere else.
m
there isn’t one, it’s not an MCS machine
l
Oh, i thought thats what you meant by a "cloned machine" - so it's essentially a standalone VM with no provisioning mechanism in it? anything in the PVSVM folder for a savedlistofddcs.xml?
m
the reg key under policies is recreated every time the desktop broker is restarted, doesn’t this mean it’s getting it from Citrix policy?
l
interesting, that is one i have not seen before - it recreates the regkey? very odd
m
yeah, there’s no pvsvm because it’s not an mcs machine
so I’m at a loss as to how it keeps coming back, because it doesn’t show up in gpresult either
it’s totally ignoring the listofDDCs key in the non policy location too
r
Even after you set the update policy in studio to not update?
m
how does it know where to get the policy from if I delete the reg keys though?
it shouldn’t know how to auto update
ok, so I stopped every single citrix service and restarted them and now it’s fine
something was stuck I guess
r
Weird. Very strange
m
omg nooo, it did it again
wtf is going on
r
m
[HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\VirtualDesktopAgent\State] “RegisteredDdcFqdn”
it’s that
if you clone a server and don’t clear that out, it keeps going back to that server
the problem with the citrix pages are they don’t mention those other keys at all
r
That is a new key to me.
m
so now it’s not pulling policy from the old farm, but it’s not registering either…
r
Can you remove that VDA and start fresh?
m
I’m going to have to
this is insane
I deleted every reg key in that article
it keeps coming back
r
Wow that’s crazy. I would run the VDA cleanup. Then login and just make sure nothing is prestaging those keys.
m
this is insane, the DDC doesn’t live anywhere in the registry, the group policy cache locations are all cleared, autoupdate is off in citrix policy, the C:\ProgramData\Citrix\PVSAgent\LocallyPersistedData\BrokerAgentInfo folder is gone, it’s not an MCS machine so there’s no personality.ini file and yet IT STILL TALKS TO THE OLD FARM
I’m dying to know where the setting is
r
As much as it may be painful. Procmon time to see wtf is happening
m
yeah, it’s driving me insane
r
What version is the old farm? Just curious
m
7.15
r
Okay, so not terribly old
I was thinking before 7.15 maybe there is some crazy setting we missed
I hate procmons. Only because I suck at it
m
it’s CseEngine that’s doing it
it thinks there’s a policy somewhere
the insane thing there are no citrix policies defined
r
Cse like gpp pushing something down?
m
yeah
omg, the vda cleanup tool won’t even run on this
far out, even after running the cleanup utility an re-installing the new VDA, it still connects to the old farm
time to open a support case I guess
l
what if you put a host file entry in for the old controllers pointing to home
m
Oh my. I see the email from the unsuspecting frontline support agent now. “What have you tried?”
m
trying the host file now, going to reboot
l
its not a local policy set on the VDA with the citrix GPO add in added, is it?
m
that would still show up in the registry, I did a full search of the registry for the address and it doesn’t exist
it’s getting it from somewhere else
so a cache file or something
l
it wouldn't be stored in the machine.pol file?
m
it’s the citrix policy engine that’s writing the reg key
it might be, I just deleted the group policy cache too
omg, it’s still finding it
I give up
l
what does rsop say?
m
nothing
it doesn’t show the server names at all
l
wow
m
there is no citrix policy at all other than turning off auto update
so I just cannot work out where this is coming from
j
Have you cleared this? C:\ProgramData\CitrixCseCache
m
yes
r
I’m having issues as well. Not exactly like yours but similar. The Citrix Docs respectively need a bit of work around the VDA registration part. They do a good job in troubleshooting why it’s not registered in most cases. But really miss when adding more delivery controllers. They talk about it taking 90 minutes to update the cache locations but say nothing about needed to delay the desktop services to enforce registration (unless I missed it)There are so many little hacks folks do to make it work that the doc seem to not have. Am I wrong?
r
DAssuming MCS did you use the autoupdate prohit settings first so that the listofsids cache is not used.
That normally does work.
Of course that assume the VDA was installed wiht do it later. If not then you need to reinstall the vda wiht do it later
r
I will get back to you, I need to lab this out. I am going off what I client is saying. First I need to confirm they are following what you said on disabling auto update, then update listofDDCs. even if that was not done, the VDA cache would get update after 90 minutes from what I am reading with the extra DDCs. is that accurate in your experience Rob?
The VDA was installed with the manual option listing the DDCs.
r
In my experience hou ghen have to uninstall and do it later or change it with the reinstall
12 Views
Open in Slack
PreviousNext
Powered by