https://worldofeuc.com logo
Join Slack
Powered by
This message was deleted.
# citrix-netscaler
s
This message was deleted.
a
this is the workspace error for reference
l
Its a tough one. The netscaler is failing to talk to the vda. Firewall ports all open etc...? Is it definitely working for another user pre upon change?
j
Did you change the UPN or did you change to using UPN? If change is to UPN, watch your session profile on the ADC
👍 1
a
I'll double check but pretty sure we just changed the fields in AD and okta from initials to a different format ( for nothing on the fas servers or on the netscaler. Even weirder if I sign in via Sf for a while or enough times NOW I can get in via netscaler fine but if I spin up another machine it will go through the same pattern... So it's almost like a weird pattern thing or timings of some sort
The only other test over tried with this new image is with a test account that doesn't go through okta/fas so maybe not the best comparison
l
How many storefronts do you have? Can you check they are all synced correctly?
j
If it’s FAS or auth related it’s usually pretty vocal - and verbose in its logging - I feel like it might be a red herring if the logs aren’t complaining
a
Yup confirmed we only changed the User Logon Name and User Login Name (pre-win2000) in the AD account tab from our initials previously now to a format that matches our email
2 SF servers. and its so random......i just spun up 4 machines in that (2 from this new image/catalog, 2 from an older existing one we're using for app dev ) and 2 failed to launch through the netscaler and 2 went right in
I should say also i just started looking at this and opened a Citrix ticket so have not gotten too far into logs beyond the VDA ones so far and those are pretty generic just saying user / deny
SF servers last synced back in april ....shouldn't have been any changes but i just sync'd up again from primary to secondary so i can see how that goes
no luck same deal. i do see a normal event id 105 for my login on the FAS server so all looks fine there so i guess it could narrow things down to the Netscaler since i can get in if i go through SF directly?
l
Potentially but your authentication has worked, you've got your resources which means the VDA is then either not there or cannot sign you in due to credentials. In any case, it should prompt you for credentials. I'd check the events logs at that specific time on the Storefront, Controllers and VDA. Have you tried a Scout trace?
a
SF / Controllers dont show anything that i can see and the VDA only shows this. not a scout trace yet but support wants me to get CDF traces from all controllers, SF servers, remote VDA and wireshare on SF
Odd that it works every time through SF but yup since it EVENTUALLY works through NS on a VDA throws me....almost like it eventually caches something on the VDA and then its good just for that one
l
Have you checked the STA setup???
Is it the same store internally and externally?
a
Same store yup
c
when your using OKTA and FAS you cant have a SSO domain under published apps on the session profile on the Netscaler you should of fully delegated credential validation to the NS on the SF store as well as well as enabled FAS on the SF store
if you not using saml and citrix fas and not using okta and just want to sign into the netscaler with UPN i also got as guide for that as well :) https://c4rm0.wordpress.com/logon-to-netscaler-using-userprinciplename-instead-of-samaccountname/
a
thanks i'll take a look at those! if this was working fine prior to my UPN change wouldn't that indicate that its mostly setup correctly though? we've had our OKTA/FAS setup on our netscaler for over a year now
c
sorry didn't read whole thread looking at the error unknown client error 0 is typically 1495/2598 not open from snip to vda nstcpdump.sh host x.x.x.x and port 2598 from the cli will tell you if its FW related x.x being IP of your vda. What do have added as Trusted domains on the SF store ? what is the sso domain on your session profile on the NS ? Is there no errors in the SF delivery services log / DDC logs at time of failure ?
also another thing to check is what the application username format is set to on the Netscaler saml app within the okta portal/tenancy this screen here
a
cool let me check all that out. i know our trusted domain is "soc" on SF for sure...the netscaler part i'll dig into a little later (i dont do as much in that setup). part i cant get past is if i just keep trying EVENTUALLY i get in through the netscaler and once i do once i'm good on that machine going forward almost like it now cached something on that specific vda. and in some cases if i spin up a new VDA i get lucky right off the bat and it works right away
c
one other thing what type of licensing are you using ? per user / per device ? i would fire up udadmin and check your licenses as seen it in past where it issues licenses to both samaccoutname/upn for the same user so you could be out of licenses
a
We have user based licensing.. we are currently in the overdraft I believe actually (working on that) but nowhere near hitting the grace period limit. Would going directly to SF not be affected by something like that if it was the culprit?
Also thank you for the help here!
c
diff accounts or same account ? licenses are assigned to user/device for 90 days so if diff user would require new license .... you get a 10% overdraft with per user/licenses but if your out of licenses the 15 day supplementary grace period kicks in. The error you posted Connection Validation Failed on domain for user reason "Deny" is often caused by licensing issues hence why it might be worth checking
a
Well that's an interesting point... So we own 450 use licenses (so about 490 with the 10% buffer) and just had a flood of new contractors last minute which sent us into the red overdraft.... About 470 in use so working on that with our account team). Is imagine I have both my old 3 initial upn and my new first initial/last name one in the udadmin list. Could that be the issue maybe? If we're still in the overdraft and not in the grace period should that matter? Obviously want to get back out of grace asap
l
User message is usually "Access Denied" when the user gets through. As its a generic error its worth checking though.
a
so i cleared out my old UPN from the list and a few old/unused ones and we are still over a bit but not in a grace period so i'd think thats not the culprit (hopefully). if i try and connect through the netscaler from inside our network i see this error on the vda application log (trying from the outside shows no records on the vda so not even getting that far).
and to make things more confusing now , my test account thats had the same upn that it always had is having the issue too on this new setup too so maybe a bigger issue
sorry you're all going to be sick of me here but could it be something in the Win10 image contributing? i just tried with an older Win10 image we use for app dev and that worked fine w/ my account (external using NS). I did a fairly standard 1912 VDA install like usual
maybe totally off but could this possibly be a dns issue? only reason i ask is I deployed a couple of new desktops and my client internally could ping the new desktop by name but another random server of mine (my PDQ server) could not until i did a flushdns a couple of times and could connect to it. then i was fine. thinking if THAT server had an issue could others possibly too? ddc's and sf seem to be able to hit it ok so wondering if maybe the NS is having a similar issue since EVENTUALLY i am able to connect to the desktop through it
l
Can you run Get-BrokerSite and post the output please chap?
You have DNSResolutionEnabled set to true so yes, dns could be your issue.
a
if we set that to false, do we need to restart any services/server to complete the change? it almost seems like it would be BETTER to have that as false and just use IP to eliminate DNS as a possible culprit wouldnt it?
l
It should be fine to change this value and no restarts are necessary. When you launch from storefront, save the ica file and open it up. It should have a machine name in there for the vda. Change this entry and check it again and you should then see an ip instead. After doing that, repeat your external testing.
a
awesome thanks! no risk of that dropping any connections or anything i assume right since it only affects newly launched sessions (and since i can change it back right away). also last thing any worry about clients that connect directly to SF from inside our network if i change that? only reason i ask is i saw this posted on Carls page
l
Do you use the HTML receiver for Storefront?
No impact to currently connected users. Basically when the controller decides which vda is the vda for the user, it responds with either an ip or name dependent on this setting. Storefront then generates the ica file you consume to connect.
a
well sort of i guess......internally we have our chromebooks go to the same url as we use externally but if they are in the building / on our network it routes them basically to SF (load balanced on the NS) and the chromebooks use the workspace for chrome which i believe is just a glorified HTML5 client
l
Yep. That is true. Ping me the link for carls article and ill have a read.
It should not matter as the htlm5 receiver works fine with ip. I can lab that bit for you though.
a
awesome thank you for your help! i'm just not IN our office to actually test so makes me nervous. https://www.carlstalhood.com/virtual-delivery-agent-vda-7-14/ i just did a search on there for. DnsResolutionEnabled. so maybe out of context for what we are doing
7 Views
Open in Slack
PreviousNext
Powered by