New Teams in Master Image

Hi Paul.  We've been having the same issue and so far, we haven't found a solution. 

While this is not a solution, it's a work-around for my testing pools. I've not yet pushed to production because I too haven't found a way to leave have just the new Teams on the base image.

I ran into the same situation when I tried to have just the new Teams installed on both a new clean image and also where classic was removed, and new Teams was installed.

The only way I've been able to make new Teams work was to leave classic Teams installed. Then in the Teams admin center, made a custom update policy specified to my test user accounts which allows the user to toggle to new Teams. 

When using the test VM, it starts with Teams classic, then prompts for new Teams, which then works. It sometimes resets back to being classic first and prompting again. 

Since it's testing, I'm leaving it for now until I can find a way to make it work without classic being there. Not even a case with Microsoft has provided anything fruitful on this yet, which is disappointing and frustrating.

Personally I like to go lite in my images so 365 or Teams dont make the cut - I just run a scripted action after VM is created and I set that in the "VM Deployment" Tab.
I cannot see a reason why you would ever need to bake in something like that.

Thanks Phil, that's the best way to go about this I reckon - we'll do that. Thanks!

I have been informed by Microsoft that they are working on a KB fix for sometime in April. Also, once the KB is released they should update marketplace images with new Teams in May.

I came here seeking the same answer, what i've found so far is one i've got it installed via the bootstrapper in the golden image. Powered off and set as image then deployed to our test pool.  A specific registry status is adjusted and prevents it being installed properly.  If you edit the registry status after deployment then it works.  

However this is painful, as now i'm looking to registry update via gpo or some other method so it returns to status 0

See this article if you have the same thing...Teams installed but dimmed.

Riordan Glarvey you absolute star! By setting the "PackageStatus" to 0 or even deleting the key that seems to have resolved the greyed-out Teams issue on a provisioned machine. I'll test shortly in the Gold Image. Thank you.

I came here to say the same thing Grimsey, Paul (Atos)! That is the magic workaround! 
I had been pushing the new Teams install to the hosts post sysprep, but even that didn't work 50% of the time. This reg fix works 100%!

Awesome find Riordan Glarvey!

Changing the PackageStatus value to "0" does indeed work for me, but I'm not sure how to automate that so that I'm not logging into each freshly re-imaged host and changing that value and then rebooting it. The name of "MSTeams_xxxxxx" key isn't static because it depends on the exact version number of new Teams, so that might be hard to "program" to remove or edit.

So, if there is a GPO setting or some other hands-off method that can be done for this until there's a fix, I'm all ears. Thanks for pointing me here, Dustin Plank!

No problem. I'm testing this out right now, so take it for what it is (unknown working code)... (pasting it here also messed with formatting).

# Define the registry path $registryPath = "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModel\StateChange\PackageList" # Check if the registry path exists if (Test-Path $registryPath) { # Get all subkeys under PackageList $subkeys = Get-ChildItem -Path $registryPath # Iterate through each subkey foreach ($subkey in $subkeys) { $packageStatus = (Get-ItemProperty -Path $subkey.PSPath -Name "PackageStatus" -ErrorAction SilentlyContinue).PackageStatus # Check if PackageStatus is not null if ($packageStatus -ne $null) { # Set PackageStatus to 0 Set-ItemProperty -Path $subkey.PSPath -Name "PackageStatus" -Value 0 Write-Host "PackageStatus for $($subkey.Name) set to 0" } } } else { Write-Host "Registry path not found: $registryPath" }

The thought is I bet this could be ran as a scripted action on the host pool properties for the "Run Scripted actions when host VM is STARTED". 

For us, our hosts all scale-in, so when they "start up", it would quickly run this and should do it's thing.

Another approach would be to run this as a remediation script in Intune (no GPO here) to check for any value other than 0 and then set it to 0 if found otherwise.

Again still testing. For now on my few dev hosts, I'm just manually setting the key for now. Looking to the above to correct it automatically until Microsoft issues a proper fix.

Grimsey, Paul (Atos) Dustin Plank

I didn't consider that clearing the key resolves it aswell, correct it is a static reg key entry which requires maintaining when versions change.
Might try clearing the key PackageStatus at VM creation as a scripted action. Problem is, how do you Remove that Reg Key as it would be Dynamic with each version change.

In my edited teams scripted action I have:

# Remove PackageStatus Dimming Key
Get-Item HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModel\StateChange\PackageList\MSTeams_24074.2321.2810.3500_x64__8wekyb3d8bbwe | Remove-Item -Force -Verbose

To further add to the pain, I unfortunately ran into another roadblock with the teams outlook add in msi.
Seems like by using the bootstrapper method it "should" also install the add in for teams integration for Outlook.

I do note that Nerdio has recently come up with a new scripted action for teams that now includes the teams meeting add-in so will be testing that today.

Building on Dustin Plank's script I think it is possible to correct this in a single Scripted Action when deploying NEW Teams to a Nerdio Desktop Image. Well, sort of.

In the Scripted Action install and configure NEW Teams as you wish but have it create a Scheduled Task that corrects the Registry item when the VM starts. This only works if you can easily determine a provisioned machine from the temporary image creation VM. So you might exclude "-tmp" for example. In our environment we have predictable netbios names so I've used that.

# Do not indent the $scriptFile!!
$scriptFile = @'
<#

Authors: Paul Grimsey
Date: 24 April 2024

Purpose:

Create a PowerShell script which ensures that NEW Teams functions correctly when embedded in a Nerdio Desktop Image

This addresses the "greyed-out" Teams issue on the Start Menu. The URL below gives background:

https://learn.microsoft.com/en-au/windows/win32/appxpkg/troubleshooting?redirectedfrom=MSDN#applications-dont-start-and-their-names-are-dimmed

#>

    # Check that machine is a provisioned machine
    if ($env:COMPUTERNAME -match 'WVS' -or $env:COMPUTERNAME -match 'WVD') {

    # Define the registry key path
    $registryKeyPath = "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModel\StateChange\PackageList\MSTeams_24033.813.2773.520_x64__8wekyb3d8bbwe"

    # Function to continuously monitor the registry value
    function Monitor-RegistryKey {
        $startTime = Get-Date
        $timeout = New-TimeSpan -Minutes 10
        
        # Continue monitoring until timeout
        while ((Get-Date) -lt ($startTime + $timeout)) {
            $currentValue = (Get-ItemProperty -Path $registryKeyPath -Name "PackageStatus" -ErrorAction SilentlyContinue)."PackageStatus"
            if ($currentValue -ne 0) {
                Write-Host "Detected change in PackageStatus. Setting it to 0..."
                Set-ItemProperty -Path $registryKeyPath -Name "PackageStatus" -Value 0
            }
            
            # Sleep for 5 seconds before checking again
            Start-Sleep -Seconds 5
        }
        
        Write-Host "Monitoring completed."
    }

    # Start monitoring the registry key
    Monitor-RegistryKey
}
            
'@
        
        # Create the  "C:\Windows\WVD Automation Operations" folder if it does not exist
        if (!(Test-Path -Path "C:\Windows\WVD Automation Operations")) {
            New-Item -Path "C:\Windows\WVD Automation Operations" -ItemType Directory -Force
        }

        # Create the PS item "C:\Windows\WVD Automation Operations\WVD Automation Operations - NEW Teams - Correct Greyed-Out issue.ps1"
        $scriptFile | Out-File "C:\Windows\WVD Automation Operations\WVD Automation Operations - NEW Teams - Correct Greyed-Out issue.ps1" -Force

        # Create Scheduled Task to run PS item above

        if (!(Get-ScheduledTask -TaskName "WVD Automation Operations - NEW Teams - Correct Greyed-Out issue" -ErrorAction SilentlyContinue)) {

            $jobname = "WVD Automation Operations - NEW Teams - Correct Greyed-Out issue"
            $script =  "C:\Windows\WVD Automation Operations\WVD Automation Operations - NEW Teams - Correct Greyed-Out issue.ps1"
            $action = New-ScheduledTaskAction -Execute "$pshome\powershell.exe" -Argument  "-file ""$script"" "
            $trigger = New-ScheduledTaskTrigger -AtStartup
            $settings = New-ScheduledTaskSettingsSet -StartWhenAvailable -AllowStartIfOnBatteries -DontStopIfGoingOnBatteries -RunOnlyIfNetworkAvailable -DontStopOnIdleEnd
            Register-ScheduledTask -TaskName $jobname -Action $action -Trigger $trigger -RunLevel Highest -User "SYSTEM" -Settings $settings
        }

Dustin Plank

Great, thanks for that.
Has anyone found since deploying teams new, that the end points show a Red Banner message "We weren't able to connect. Sign in and we'll try again"  But still has teams being fully functionally, join, chat and call people?

Also show an update and Exclamation icon, that updates teams, restarts and never appears after?

This is ofcourse using the new msix bootstrap which should/does include keeping the teams install and allowing updates to occur.

We're finding even with the New Teams scripted action set to install when VM is created, Teams auto start is hit and miss. It is so odd.

We think FSLogix 2210 hotfix 4 might help. It has many Teams-related fixes 
https://techcommunity.microsoft.com/t5/fslogix-blog/announcing-release-date-for-fslogix-2210-hotfix-4/ba-p/4129512

I just tested the new Nerdio scripted action that contains the Outlook Addin.  MS Teams installs and works correctly, however the Outlook Addin is still missing.  I tried running the msiexec.exe command manually on my session host and it just pops up the msiexec options window.  This indicates to me that some of the parameters being passed in the command are not correct for my version.  

Has anyone else tried the new scripted action?

Mikki Vestal I have tested the script and found that I needed to add "start-sleep -seconds 180" at line 106 (prior to the add-in install). It seems that the WindowsApps folder isn't available as quickly as the script runs.
Note- testing in a different environment had the timing extended to 5mins.

Thanks for the info Dan Burton.  I'll give this a try.

Adding "start-sleep -seconds 300" did the trick for me.  Thanks, Dan.

I can't seem to see the new scripted action which contains the Outlook add-in, what's it called please? I can see the New Teams scripted action (the one we've been using with mixed results).

That's the same script, it's been updated to include the Outlook add-in.  It's named "Install Microsoft Teams (new)"

Has anyone been able to figure out how to remove (or clear) the key or value using a script even when the version number of new Teams changes? I thought with the newest version of FSLogix, 2.9.8884.27471, that this would be fixed (https://techcommunity.microsoft.com/t5/fslogix-blog/announcing-general-availability-for-fslogix-2210-hotfix-4/ba-p/4140133), but even with this new version, the program is still greyed out. And yes, I'm using the latest version of "Install Microsoft Teams (new)", which was modified on Nerdio on April 23rd. This is just beyond frustrating!

TheITKid I'm with you, still getting this issue and I've been chasing Microsoft about it. Will let you know if I hear anything.

Microsoft have pushed back the end of life date for Old Teams to October 1^st 2024 at least.

I appreciate it, Grimsey, Paul (Atos). I'm so glad I never took classic Teams out of the image because at least the users have something stable to work with while this gets figured out. Ridiculous.

I just can't get New Teams to auto start consistently for everyone who signs into the host. I have the New Teams scripted action installing the app when host is created. Is anyone else having this problem? If I launch Teams manually it works fine, it just won't auto launch for everyone.

Hi Paul Faulkner - It may not be an ideal workaround, but you could try adding the teams executable path to the run key Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run

This could be added to the image or via scripted action on the host.

https://learn.microsoft.com/en-us/windows/win32/setupapi/run-and-runonce-registry-keys

Thanks

Hi, 

Strangely enough the Teams Addin script has stopped working all of a sudden, its not picking up the variables from the machine it is installing on, basically they are empty, so when it attempts to install the Addin, the version is missing. If I pull the script out of Nerdio and run it on the machine it works fine. I suspect its something to do with Azure's customscriptextention module than anything else, thought it was isolated but its happening at 3 customer sites, tested another script and that is also not able to pull in endpoint variables.   I'm hoping its not just me.

Kevin Halstead that seems to be working fine for me, just tried now. Did you add this into the scripted action?
add "start-sleep -seconds 180" at line 106 

Hi Paul,

Thanks for your feedback, I think this is more of an Azure backend update than anything else, as the scripts were working last week. It seems it cannot query the machines anymore from the customscriptextention in Azure, which Nerdio utilises. If you run the script manually on the machine it works fine. I'll most likely raise this as a case to Microsoft so they can double check.

MS have finally fixed the custom script extension and runs correctly.