Windows 11 in-place upgrade content

Hi @JasonWalker thanks for the quick reply!

Err…I’m trying to understand if there’s a way to curate the current report, because at least for 3 of that machines I know the it doesn’t block if running the installer.

1 Like

Hi @DiogoSousa – I know that we had some scenarios where machines with exactly 4GB of RAM were reporting a little less. The latest version of the analysis should have a fix for this.

Also, these are Microsoft requirements but it does seem like not all of them will block the actual upgrade. I have seen scenarios with WDDM 1.1 and 1.4 where the upgrade went through.

2 Likes

Hi there! :slight_smile: thanks for the reply.

Just to be sure, where can I see my analysis version? And…do I need to open a support case to update? (if applicable)

Best Regards,
Diogo Sousa

The analysis in the BES Inventory and License site should be up to date. If you downloaded your analysis here, check if the relevance for the “Memory Check” property states:

(if (it >= 4096) then "PASS" else "FAIL - Current memory in MB: " & (it as string)) of (if (it > 128) then ( ((it / 32) * 32) + (if (it mod 32 > 16) then 32 else 0) ) else it) of (size of ram /1048576)

My analysis was directly added by HCL support but…you’re right! :slight_smile:
It’s already updated! Didn’t noticed that! :slight_smile:

Thks!

You can use this guide to customize Windows 11 settings.

I have a lot of machines that are failing the WDDM check based on the analysis. It seems that the issue is that we have “Citrix Indirect Display Adapter” which reports WDDM 1.3, but the main display adapter reports WDDM 2.7. Does the analysis need to be changed to look for the main adapter which seems to be indicated by: Device Type: Full Device (POST).

Is there an upgrade available yet for the Citrix driver, and have you tried upgrading one yet / did it continue to function? Windows 11 claims to require at least WDDM 2.0; I’m not sure whether the installer itself would block the upgrade, whether the upgrade would work with your main display but cause problems with the Citrix; or whether everything would go fine. I’d be very hesitant to second-guess the published requirements though, I think we should at least provide the indication that you’re in a questionably-supported area.

I upgraded to the most current version of Citrix Workspace, and it is still WDDM 1.3.

@mbartosh – are you able to share your [BES Client folder]\win11-eligibility\dxdiag.txt file here just for reference?

I uploaded the file after renaming it to .jpg. I don’t know if it uploaded.

@mbartosh – hmm, don’t think it did. Maybe email it directly to us or use blockquote inside your post? Thank you!

The file is likely too large to post to the Forum…@mbartosh we may need to ask you to open a support incident so you can attach the file to the ticket.

Case CS0398940 has been created, and the dxdiag.txt uploaded.

3 Likes

What we found from our Citrix guys was the older (at least in ltsc branch) workspace 1912 & receiver products did not support Windows 11. Workspace supported Windows 11 beginning in 2203 (for ltsc). We found during our upgrade tests that unfortunately Citrix did not build removal of the older wddm driver into their upgrade path & subsequently created a post script in Powershell to remove the older wddm driver. Removing the old wddm doesn’t seem to affect the functionality of the newer workspace client fwiw but ymmv…

2 Likes

Hi Nuchtman, can you post the URL to the Powershell script that removes WDDM 1.3?

@mbartosh
Attached is a script we’ve run to clear the Citrix driver off the systems.
YMMV & this is provided with no warranty/support so proceed at your own risk. :slight_smile:

#RemoveCitrixDevices.ps1


#Function:  Write-Log
#Usage:     Write-Log Message LogLevel
#Purpose:   Takes a message and log level passed as arguments and writes to a log
function Write-Log {
    [CmdletBinding()]
    param(
        [Parameter()]
        [ValidateNotNullOrEmpty()]
        [string]$Message,
        [Parameter()]
        [ValidateNotNullOrEmpty()]
        [ValidateSet('Information','Warning','Error')]
        [string]$Severity = 'Information'
    )
    $Time = (Get-Date -f "MM/dd/yyyy - hh:mm:ss tt")
    $Msg = $Time + "," + $Severity + "," + $Message
    "$Msg"  |  out-file  "$scriptLog" -Append -encoding UTF8
 }
 
#==============================================
# MAIN
#==============================================
$logpath = $Env:ProgramData + '\Logs'
#$scriptName = $MyInvocation.MyCommand.Name
$scriptName = "RemoveCitrixDevices"
$scriptLog = "$logpath\$scriptName.log"
if (-Not (Test-Path -Path $logpath))
{
    New-Item  $logpath -ItemType Directory -ErrorAction Stop
}
#create log directory if not exists
#Write-Host "Starting $scriptName.ps1..."
Write-Log "Starting $scriptName.ps1..." 'Information'
Write-Log " " 'Information'
try {
    Write-Log "Remove any Citrix Indirect Display Adapter(s) from PNPUtil..." 'Information'
    foreach ($dev in Get-PnpDevice -FriendlyName '*Citrix Indirect Display Adapter*') {
        pnputil /remove-device $dev.InstanceId /subtree /force |  out-file  "$scriptLog" -Append }
}
catch {
    Write-Log "Error removing device via PNPutil" 'Error'
}
try {
    Write-Log "Remove any Citrix Systems driver(s) from PNPUtil..." 'Information'
    foreach ($oemdriver in ((PNPUtil /Enum-Drivers /class Display |
    Select-Object -Skip 2) |
    Select-String -Pattern 'Class Name:' -Context 3,4) |
    ForEach {
        [PSCustomObject]@{
            PublishedName = $PSItem.Context.PreContext[0] -replace '.*:\s+'
            OriginalName  = $PSItem.Context.PreContext[1] -replace '.*:\s+'
            ProviderName  = $PSItem.Context.PreContext[2] -replace '.*:\s+'
            ClassName     = ($PSitem | Select-String -Pattern 'Class Name:') -replace '.*:\s+'
            ClassGUID     = $PSItem.Context.PostContext[0] -replace '.*:\s+'
            DriverVersion = $PSItem.Context.PostContext[1] -replace '.*:\s+'
            SignerName    = $PSItem.Context.PostContext[2] -replace '.*:\s+'
        }
    }  | Where-Object { $_.ProviderName -like "*Citrix Systems*"}) { pnputil /delete-driver $oemdriver.PublishedName /force |  out-file  "$scriptLog" -Append }
}
catch {
    Write-Log "Error removing driver via PNPutil" 'Error'
}
try {
    Write-Log "Initiate device scan via PNPUtil..." 'Information'
    pnputil /scan-devices |  out-file  "$scriptLog" -Append
}
catch {
    Write-Log "Error scanning devices via PNPutil" 'Error'
}
try {
    Write-Log "Disable any Citrix Indirect Display Adapter(s) via PNPUtil..." 'Information'
    foreach ($dev in Get-PnpDevice -FriendlyName '*Citrix Indirect Display Adapter*') {
        pnputil /disable-device $dev.InstanceId /force |  out-file  "$scriptLog" -Append}
}
catch {
    Write-Log "Error disabling device via PNPutil" 'Error'
}
#Write-Host "Completed $scriptName.ps1."
Write-Log "Completed $scriptName.ps1." 'Information'
Write-Log "==================================" 'Information'
exit 0

it isn’t clear to me if you need all display adapters to be WDDM 2.0 or greater or if you just need the primary physical adapter to meet that requirement. If just a single one at WDDM 2.0 or greater is required, then that could be checked from the dxdiag like this:

Q: exists maxima whose(it >= "2.0") of (it as trimmed string as version) of following texts of firsts "WDDM" of lines containing "Driver Model:" of files "win11-eligibility\dxdiag.txt" of parent folders of data folders of client
A: True
T: 9.770 ms
I: singular boolean

But if ALL display adapters must meet that requirement, then that is not actually correct and would report success where there is actually a failure.


Interesting. I did some digging and it seems that checking for “DirectX Version: DirectX 12” is actually incorrect, because that just means that DirectX 12 is available from a software perspective. It is actually checking that “DDI Version: 12” OR “Feature Levels: 12” to be sufficient for you to have a physical graphics card that is actually DirectX 12 compatible. This suggests the NVidia GT 730 which is still being sold today would NOT qualify because it has a feature levels of 11_0

The test logic is here: https://github.com/rcmaehl/WhyNotWin11/blob/f7b7597afb42b720e4fcdaf4343829a390f77491/includes/_Checks.au3#L108-L133


If you have a system that we report is NOT compatible with Win11 due to GPU, I would be curious what WhyNotWin11 says and if it agrees or not.

Bigfix is reporting that 1700 machines in our environment are not Windows 11 compatible because of the video card memory. WhyNotWin11 is reporting they are ok.

Additionally, there are about 2000 machines that are reporting they pass the CPU test when they do not because they are less than 8th Gen Intel processors.

The Windows 11 compatibility test in Bigfix is a good idea, but it is not accurate.

1 Like

In closer analysis of logic in WhyNotWin11, it seems that it’s checking for existence of “WDDM 2” (or 3) and “DDI Version: 12” OR “Feature Levels: 12” anywhere in the probe file. That’s potentially incorrect as you can have a card that provides one and not the other.

As far as processors are concerned, please note this comment: Windows 11 in-place upgrade content

However this was a while ago and it might be time for us do change this check and look at the actual processor list.

1 Like