This message was deleted.

Looks like I might have the same issue

Fuckin hell, I guess that makes me a little happier.

It's actually a colleague of mine experiencing the issue

When this happens, I have to run VDA cleanup utility, and then still manually delete C:\ProgramData\Citrix\XenDesktopSetup

The customer have 600 WIndows comptuers with RemotePC enabled

My admin install finished successfully.

in what context are you running the task sequence? Local admin?

I have done so many VDA upgrades over the years, and have never seen this behavior.

Both

Fail: Logged in with non-admin account, PowerShell is launched as Administrator and run in that context

How about the SCCM task sequence, is this running in the local user context?

I highly doubt it, but also don't know. That's another team entirely.

Hmm

This is what I get for commenting that I never have VDA upgrade issues here.

The /noresume cmdline switch should prevent the runonce registry entry though

We don't use that switch.

Yes, I think that's the idea

How the hell do you use SCCM to upgrade the VDA then without a task sequence?

I don't know. I don't have very much experience with SCCM

I honestly can't recall how that works. I would expect the /noreboot switch to not require any of that, though.

I have seen the VDA installer spitting out an exit code of 3010, if I remember correctly, even though it installed correctly

In our logs, the final entry in the log file was 'pending reboot', and nothing afterwards

Yes, it looks like it happens because of a Visual C++ install

Now I wonder if we have to make that package a prerequisite package in SCCM. That would be so dumb.

I had to upgrade c++ first then to the vda upgrade

Damnit

But with sccm it seems to always work best to remove the vda clean up upgrade the pre reqs then reinstall the vda. Might also need a reboot in there

I don't see any way of doing it without a task sequence then. I have seen the VDA cleanup utility require 3 reboots to complete - like on my own VM just now.

In sccm there should be sn exit code if you need to reboot. And yes def needs a task sequence. Its not a simple upgrade due to the prereq requirements. You can roll those out separately then it’s usually a much easier upgrade.

Yeah, the SCCM guys sent me a screenshot of the TS. Looks like VDA cleanup is being run 4 times, with 4 total reboots, so I don't think that part of the process is the issue. Getting a few VMs back to 1912 so that they can add VC++ back to the TS post-cleanup to see if that yields different results.

Has in-place upgrade of the VDA ever been good? It seems like there has always been issues

Honestly, I never really had an issue with 1912 and earlier that I can recall. 2203 for us has been a mess with upgrades.

When we were doing tons of remotepc installs the key was getting the prereqs installed before trying the vda. The issues always seemed to be when the vda had to do the prereq upgrades. No prereqs and it worked fine.

A little late to this party... Sorry if what I say has already been said, I only skimmed through this whole thread. The VDA cleanup utility provides a return code to know if a restart is required or not, so can be scripted to restart as many times as needed, which I do in my deploy script. I use the /noreboot /noresume flags in my VDA deployment so I control the entire process in my script because Citrix doesn't seem to do things consistently, and depending on what pre-reqs are needed there may be more restarts required. My script manages the entire process. I always use a local admin account where the account is granted admin rights on the local machine during script run and uses Autologon to manage the process. Autologon and Admin rights are cleared at script end.

If adding VC++ as a separate step doesn't resolve this for us, I'm going to suggest using /noresume and having them kick that process off via the TS.

Normally C++ out of date

@Rob Zylowski: There's no hard requirement for VC++ 2015-2019, right? We're going to attempt to use a newer 2015-2022 package.

I think that would work.

Just to close the loop on this, that seemed to work. Here's our new process (via Task Sequence in SCCM): 1. Run VDACleanupUtility 2. Reboot 3. Run VDACleanupUtility 4. Reboot 5. Run VDACleanupUtility 6. Reboot 7. Run VDACleanupUtility 8. Reboot 9. Install VC++ 2015-2022 10. Reboot 11. Install VDA 12. Reboot

Wouldn't it be great if we didn't need the VDA Cleanup Utility?

david rose absolutely

Sure thing :P

I just told the SCCM team, and I'm pretty sure that I could hear them slamming their keyboard. 😂

Sounds fun. Certainly sounds like they didn't run to completion and are not using -noresume in the command line. I know I script the process using -noresume and do my own checks to rerun the process until it completes successfully or fails and notifies.

We aren't using /noresume, correct. I think I'm going to have to get them to change this up, because this isn't working. That said, it's 2023 and Citrix still can't build an installer that fucking continues after a reboot automatically, without having somebody login?

I'm not using SCCM. I have a PowerShell script which I have posted a "cleaned" version in the past that I can share, but I have re-written it since then to cut it down a bunch (removed a lot of unneeded steps that removed 6.x for upgrades in the past mostly) and I think I have the VDA Cleanup utility functioning better since then, since Citrix added a return code. If you want either, I can probably spend some time doing a quick cleanse of the current script to share.

Nah, it's all good. I had our SCCM team just add a step to run the local path post-VDA install, and added some more reboots. Damn thing is going to be take 8 reboots to upgrade a VDA now... insanity.