https://worldofeuc.com logo
Join Slack
Powered by
This message was deleted.
# citrix-vad
s
This message was deleted.
n
Answered my own question: "Check that the system clock is in sync between this machine and the delivery controller. "
r
Where did u see that at? Just curious
n
It's just weird that we never saw this issue in months of QA testing. Almost done sealing the image after resync'ing the time now, so hopefully it's as simple as that.
m
I’ve seen this so often, had a machine that was waaaay out in tthe template and it took forever to sync time with the domain after booting up. Had to fix NTP in the master image before they would all register properly.
n
Sync'd time in the image, still broken. Citrix Studio policies aren't applying at all, but it's random. Love it.
m
is it contacting the domain successfully?
n
Seems to be. Hell, I can login. AD GPOs process, but Studio doesn't.
And DDC registration is goofy.
Seeing the following in my event logs:
Copy code
The Citrix Desktop Service is re-registering with the DDC: 'New Auto ListOfDDCs / ListOfSIDs, registered DDC not in new list
m
do you have auto update on?
or have you removed any DDCs ever?
I’ve seen issues where it tries to hit the first DDC in the list, but that got decomed
n
Yes, we have AutoUpdate allowed (via AD GPO)
Same DDCx we've always had in Prod.
m
dunno, I’d double check your list of DDCs/SIDs and make sure it’s still correct
maybe change the order if it’s having issues
n
Well, this was fun. The decision was made to restore everything to 7.15 tomorrow and run through the 1912 upgrade.
r
Wait, a roll back? What happened other than the time.
n
We've spent the entire day on the phone with Citrix. Just random DDC issues - either it wouldn't register, or would become disconnected, etc. The biggest tell was Citrix policies not applying.
When we went through the 1912 upgrade initially, we went through the automatic DB upgrade (one of the final steps). Then we upgraded the last DDC. Opened Studio a few minutes later, and it was prompting us to update the site again.
r
Damn man. What 7.15 are u on?
n
LTSR CU2
Oh, and those issues were completely random.
Our DDC issue was similar to this, actually: https://citrixguyblog.com/2017/03/08/xendesktop-studio-gets-stuck-in-mandatory-upgrade-loop/ @Julian Mooren: When you saw this, did you have multiple DDCs for the upgrade?
j
It was a two DDC environment
n
We upgraded 2 of ours, did the schema update, then the final DDC. We'[re thinking of doing 1 DDC tomorrow, then immediately updating the schema, then updating the other 2 DDCs.
j
Which upgrade path? Didn’t read the whole thread. What’s your issue ?
n
7.15 LTSR CU2 to 1912. Basically followed Citrix's recommended path, but ran into a site upgrade loop when we got to the DDCs at the end. It eventually went through after a few reboots and retries, but we had random DDC issues with my W10 VDAs, with the main symptom being Citrix policies in Studio not applying.
j
Sounds like fun.. You went back to CU2?
n
We have 2 sites, so we just put this entire site in maintenance mode and enabled the other site. Going to restore the DB tomorrow and try again.
r
I have a upgrade in two weeks. I'm a little concerned now
n
Hopefully this goes better tomorrow.
j
Updated a customer yesterday from CU3 to 1912. No issues at all. But you will never know before.
r
So I assume you will just go through the same process? Anything different you might do?
j
If you are coming from <= 1811, I would always update to 1909 and then 1912. Had problems during one of my first upgrades. Database crashed during site upgrade. Even most of the 7.15 CU2-3 environments I update to CU5 first, afterwards 1912.
👍 1
n
That's one thing we may change - going to CU5 first, and then 1912.
r
Yea, I will do CU 5 first. Hope it goes better for you Nick
n
If it doesn't, you'll hear me screaming from your couch.
r
hahaha
Nick, how did it go?
n
Open your windows and you'll hear me screaming.
Upgraded from CU2 to CU5, then to 1912. All smooth. Same issues with Citrix Studio policies not being applied consistently. The weird thing is that after 1-2 reboots, we can't get one of the "failed" VDAs to ever fail again. It's almost like there's some corruption or something in the DB that is fixed by the VDA registering a 2nd time after the upgrade. I was able to get Scout traces and a ProcMon log over to Citrix, so I'm hoping they can find something.
r
Damn man. Well hopefully they point out what is jacked up.
n
I'm testing now, but so far it looks like if I power up all VDAs, and then reboot them, they appear to work as normal. I have no idea why that would be, but I'm testing everything now, and policies are applying - including new policies that I created in 1912.
r
Wtf? Just started working all of a sudden 😑
Wondering what happens when u shut some down.
n
I've been rebooting all VDAs constantly. It seems as though after the 2nd reboot, everything works as expected.
Open in Slack
PreviousNext
Powered by