https://worldofeuc.com logo
Join Slack
Powered by
I'm not sure if this belongs better here or the 36...
# citrix-vad
a
I'm not sure if this belongs better here or the 365/Intune channel but here goes. Prepping our Windows 11 image and our VM's are joined to our on-prem domain and we have them hybrid Azure AD joined as well and having an issue w/ new vm's auto joining the azure side until a user actually signs in first. the issue is when they first sign in, its not fully joined yet so a bunch of stuff doesn't work right (onedrive silentaccountconfig, Edge sign in, 365 licensing, etc). I have this taken care of already and curious if anyone has any experience in this or advice? https://support.citrix.com/article/CTX475187/windows-11-vda-machines-stuck-at-initializing-for-azure-ad-or-hybrid-azure-ad
n
Ha - yes, we dealt with this, too. I can't recall how we addressed it - but give me a few to look back. We did not follow Citrix's guideline to the letter, but they did say what I came up with was fine.
a
awesome appreciate it! really just hoping we can spin the VM's up and first logon shit just works 🙂
n
We don't use OneDrive here yet, so all I can really account for is O365 and Edge, which both worked fine once implemented.
a
really what i look for is when i see one of the keys under Enrollments have all this data , i'm good w/ everything
that tells me it will (eventually) show up in Endpoint Manager and everything passes through how it should
n
You're leaving AzureAD as part of your sealing process on the master image, right?
a
hmm i hadn't actually. maybe that is part of it. how do you handle that just so i can test the same way?
n
dsregcmd /leave right before shutting down your sealed image
a
ok cool i figured but just in case you had additional steps. i'll test that to make sure
n
I have a little logic built into my sealing script to check the status of it once running the command, and if it's still joined, the script will exit with an error and won't automatically shut down
a
oh sweet. ya anything you have that you guys do for that sealing and the join part would be fantastic. no rush so whenever you have time
n
Copy code
/Write-ToLog "Leaving Azure AD"
Start-Process "dsregcmd" -ArgumentList "/leave" -NoNewWindow -Wait -PassThru | Out-Null
$dsregcmd += Invoke-Command -ScriptBlock { dsregcmd /status } -ErrorVariable TaskError 2>$Null
$i = New-Object -TypeName PSObject
$dsregcmd | Select-String -Pattern " AzureAdJoined : *" | ForEach-Object {
	Add-Member -InputObject $i -MemberType NoteProperty -Name (([String]$_).Trim() -Split " : ")[0] -Value (([String]$_).Trim() -Split " : ")[1] | Out-Null
}
If ($i.AzureAdJoined -eq "YES") {
	Write-ToLog "Error: Failed to leave AzureAD" -ErrTrap $True
	Exit 888
}
a
from what i see my base image is not joined actually
n
We are addressing that Citrix article you posted by creating that value via computer GPP.
We had a lot of issues trying to go the Scheduled Task route, and this was the only method that worked 100% of the time.
a
awesome thank you! i think i could just add that key in via the base image too
n
There was a reason we couldn't do this in the base image
a
so either the GPP or manually adding in the base image would handle that.....do you do anything w/ the join part of it?
n
Maybe it was the MCS provisioning process, but it was wiped on a provisioned VM
a
ahh good call. i'll watch for that
n
Nope, we let it join as part of the built in Windows scheduled task
a
so for you guys, if you spin up say 5 vm's and they are sitting idle for a week before someone first logs into them will they not join until that user first signs in or after they are just online
thats the part we are struggling with
n
Pretty sure it's a 2-part process. The computer joins at boot, and then the user logging in completes the join process
👍🏻 1
a
ok so when the vm is created and boots that part is good and after sign in its good.
as long as its all finished and ready when they are first in i'm good so i'll have to mess w/ it.....maybe its that AzureAD key missing i bet
n
Keep in mind that if you do go the route of the Citrix article with the Scheduled Task, there are more steps (which Citrix left out of that CTX article): https://docs.citrix.com/en-us/citrix-virtual-apps-desktops/2305/install-configure/machine-identities/hybrid-azure-active-directory-joined.html#c[…]s
Depending on your VDA version, that is.
a
oh damn i didnt know that thank you! so basically they are saying disable the built in method for joining and throw their script from the article in there instead to do it
n
I swear the verbiage has changed on that page. Now it says W11 22H2 only, and VDA 2212 or earlier. We had the issue in W11 23H2/2203, which met the patch conditions. At any rate, simply adding that GPP value resolved it for us.
I guess the easiest way to validate is to spin up an image using your current master and checking that registry value. If it doesn't match, try the GPP route.
a
ok ya same here.....w11 2203
cool so JUST doing that and letting windows do its thing helped for you (ignoring the CTX script)
n
Yep, that's all I did.
a
awesome thank you for your help! i'm gonna test both methods to see what works here. appreciate the help! that was driving me nuts
n
Any time, hopefully this resolves it for you. I spent multiple days testing every scenario, including creating my own PS scripts to configure this, and the GPP was the winner.
a
thats super helpful going into this!
so the other 2 keys that eventually get in there (type, user). do you know if its any issue if they are in there in the base image (assuming it sticks)
image.png
n
Honestly, no idea
a
no problem. i'll leave them out then
n
Yeah, I wouldn't manually add anything. If it's there, leave it
a
sweet thanks!
well so far at least, that AzureAD and Virtual Machine reg key persisted from the base to provisioned MCS persistent vm
I think i need to do a manual Azure AD sync to make sure the compute object is out there first
d
dont want to hijack this thread but confirming this also requires Azure CBA for SSO to work as it needs the PRT?
n
Yeah, I'm sure our AAD guys have a sync setup. I forget the timespan, though.
Dunno about that. We use Okta Silent Activation where we are, so no PRTs involved.
m
The dedault timespan for EntraId Sync is 30min. If you use BISF you can delay the start of desktop service by 30min so you should be good. IIRC the userCertificate Attribute of the computer object changes on every boot so the machine have to re-register itself in EntraID and therefore you have to wait for the sync kicks in…
a
for our setup we are MCS persistent if that matters. i figured whenever we spin up a new machine we kick off a manual azure scan so we're ok there.
i wonder if i throw the new LTSR vda on this if it will help simplify things
2 Views
Open in Slack
PreviousNext
Powered by