Removing "Recommended" from Start Menu on Windows 11 22H2 Pro

garlin

Moderator
Staff member
W11 users really hate the "Recommended" section from Start Menu, but there's no way in 21H2 to remove it. 22H2 EDU & Enterprise editions get a new GPO to hide the section, but nothing for Home or Pro users. The normal answer is to use valinet's ExplorerPatcher on GitHub.

While ExplorerPatcher is great for customizing W11 UI, it's a 3rd-party program.

SM03 inadvertently gave me another solution when he tested the GPO by switching Windows SKU's on his system. Start Menu only follows the GPO when Windows is reported as EDU or Enterprise. After confirming with Michael Niehaus' article on Virtual SKUs, I realized it was a trivial hack.

Windows 10 x64-2022-09-28-19-57-48.png

Windows 10 x64-2022-09-28-19-58-41.pngWindows 10 x64-2022-09-28-20-20-28.png

This workaround is very clean, but only works for 22H2 Pro editions (Professional, Professional Workstation). Sorry, no Home.
Users must be members of the Administrators group.

When users logon, Windows will run an elevated task to kill Start Menu, switch the SKU to ProEDU, restart Start Menu and switch back. There's a 2-3 second delay while Start Menu doesn't show any change. There is no need to update Settings, as the script does everything.

Install on a live system:
1. Extract the ZIP file.
2. Copy HideRecommended.ps1 & RunHide.vbs to C:\Scripts. If you change the folder path, edit RunHide.vbs & Schedule_RunHide.cmd.
3. Run Schedule_RunHide.cmd (once) to create a logon task.
4. If you want it changed now, run "powershell -ep bypass -file HideRecommended.ps1" as Administrator.

Install in Post-Setup:
1. Extract the ZIP file.
2. Create "sources\$OEM$\$1\Scripts" in the ISO folder. This maps to C:\Scripts. If you change the folder path, edit RunHide.vbs &
Schedule_RunHide.cmd
3. Copy both RunHide.vbs & Schedule_RunHide.cmd to the folder.
3. Add Schedule_RunHide.cmd to Post-Setup.

DO NOT ASK NUHI TO SUPPORT THIS. It's a safe hack, but not MS-supported.

- KMS doesn't support Home editions
- The script only works for Pro SKU's, but not Pro N. Stop using N editions.
- There's a short window while we're the "wrong" SKU, but typically not long enough to impact other features/services which check the SKU.
- Need a VBS wrapper to invisibly run PowerShell. Otherwise you see a flashing window.
- Since we're using SKU detection, this hack won't be broken by applying CU's.
- If you don't use More Pins, Start Menu leaves half the screen empty.
 

Attachments

  • HideRecommended.zip
    2.6 KB
Great, will try with NTL post, thanks garlin

EDIT/UPDATE:
One thing that happened & I noticed after running this script & restarting the OS,

it worked as intended in my main system within two user accounts (systemwide), but in both of the accounts, when I logged in, to check whether the script is working or not, in both the ACC, I got this message
1.png

Upon clicking on the sign-in button, juts re-entered the PIN, & this's gone simply.

Not sure whether this is related to this script or not, just sharing my experience & observation right after applying this script. Maybe some other users here can confirm after using this as per their exp.
 
Last edited:
garlin
Just tried with NTL, as you mentioned in 'Install in Post-Setup:', it did not work in actual windows installation in a system,
however, when I tried that same ISO installed in a VM, it worked,

here's the preset & log if you can identify the issue
& if you want, I can UL the full ISO that I made, let me know
 

Attachments

  • Preset 22H2.607 (Sep-22).xml
    26.9 KB
  • logs.zip
    63 KB
it worked as intended in my main system within two user accounts (systemwide), but in both of the accounts, when I logged in, to check whether the script is working or not, in both the ACC, I got this message
View attachment 8221

Upon clicking on the sign-in button, juts re-entered the PIN, & this's gone simply.

Not sure whether this is related to this script or not, just sharing my experience & observation right after applying this script. Maybe some other users here can confirm after using this as per their exp.
The script is very simple, it toggles you from Pro to ProEDU, and back. No other settings are touched.

I tested this on a MS account-enabled user (with PIN), and don't get this screen. What's important to note: switching only happens after you logon, it doesn't interfere with startup services unless those are delayed until when it overlaps with logon.
 
garlin
Just tried with NTL, as you mentioned in 'Install in Post-Setup:', it did not work in actual windows installation in a system,
however, when I tried that same ISO installed in a VM, it worked,
You have two copies. Last one wins. Check the path inside the script.
Code:
                        <Item type="Command">
                                <Path>C:\Windows\Scripts\\Schedule_RunHide.cmd</Path>
                                <Params>/Q</Params>
                                <Index>4</Index>
                        </Item>
                        <Item type="File">
                                <Path>D:\ISO\Windows\W11\Test\sources\$OEM$\$$\Scripts\Schedule_RunHide.cmd</Path>
                                <Params>/Q</Params>
                                <Index>5</Index>
 
You have two copies. Last one wins. Check the path inside the script.
Code:
                        <Item type="Command">
                                <Path>C:\Windows\Scripts\\Schedule_RunHide.cmd</Path>
                                <Params>/Q</Params>
                                <Index>4</Index>
                        </Item>
                        <Item type="File">
                                <Path>D:\ISO\Windows\W11\Test\sources\$OEM$\$$\Scripts\Schedule_RunHide.cmd</Path>
                                <Params>/Q</Params>
                                <Index>5</Index>
yes, two entities because first I added as FILE in the NTL post setup, when it didn't work then on 2nd try I also included the 'Schedule_RunHide.cmd' as both
1. Command
2. File

hence two entries in my PRESET

& about PATH you said/asked, here's the screenshot of the configured path

1. SS of RunHide.vbs

1.png

2. SS of Schedule_RunHide.cmd
2.png

Also, attaching the whole $OEM$ folder if you wanna check

I don't see anything wrong here, still not working in a real machine, but as said earlier, while tested on VM, it is working. Did you check this on VM or on a real system?
 

Attachments

  • $OEM$.zip
    1.5 KB
For my script, VM wasn't the real issue. The question you're really asking, "Did you run this on an activated system?"

I failed to do that. My normal practice is to avoid adding extra details to any test image, which includes licensing. Replacing the working product key with a generic KMS key also deactivates your license.

After searching, I found Matthew Carras' Get-ProductKey function which finds the correct key for digital licenses. Unfortunately I don't have a recent OEM system to validate those examples (maybe some volunteers out there?).

The updated script will now restore your existing license when it's present. Download it from the original post.
 
garlin
Ok, I'll test the updated script today & that too with 22622.601 ISO as we're discussing about another matter in another thread here & you suggested using officially available UUP ISO, so gonna test this with 22621.601 Pro only this time to see whether both issues can be solved in one shot or not.

will update soon.


update:

just tested, not worked, the same win ENT 22622.601 installed & the updated script is not effective as well
SS Here
1.png

preset & log attached if you wanna ck
 

Attachments

  • log.zip
    56.7 KB
  • Pro 22H2.601 with V2 Script (Sep-22).xml
    26.8 KB
Last edited:
The script does nothing unless you're on Pro, and build 22621 or later.

NTLite recognizes this image as PRO -- but winver reports it as ENT. My script works off what PS's Get-WindowsEdition returns, and I would bet it agrees with winver.
 
The script does nothing unless you're on Pro, and build 22621 or later.

NTLite recognizes this image as PRO -- but winver reports it as ENT. My script works off what PS's Get-WindowsEdition returns, and I would bet it agrees with winver.
yes, that may be the cause for this,
since the GPO originally works in the ENT edition along with EDU, can you modify the script to work with ENT as well besides the Pro version?

Works on 22623.730.
UUP made, right?
I guess I need to figure it out first why ENT is being installed on Pro ISO in my case, then have to test the script.
But since you are saying this is working on 22623.730, & I believe this is on real hardware/system, not any VM
so guess the script is working nevertheless,

BTW, I tried to use 22623.730 via NTL before making my earlier ISO & comment here, but it seems NTL still doesn't recognise/support 22623 ISOs & after loading the WIM, there're many windows settings & features missing & not showing inside NTL, so I skipped, just to be safe.
 
Last edited:
garlin,

Update:

I installed those same 607 & 601 ISO (that I made earlier & reported here) in other systems where Win11 installed as Pro correctly.
so regarding the ENT version, that seems to be a system-specific error (I'll test that in more systems to confirm)

But to note, on the other system where 601 & 607 both installed as Pro as intended, your script didn't work in either of those systems
I checked the scheduled tasklist after rebooting once just right after the fresh install, 'HideRecommended' task is created & listed/showing over there, but not running on user login. When I manually select that task & run, then it worked (obviously)

I'm gonna create another ISO & this time, integrate your script in both NTL post section, machine + users,
will update here.


UPDATE 2: My bad, earlier, I added the earlier script (v1) by mistake, just realised, now on the same ISO, I added your updated script (v2) & made another clean install, and it worked as intended since 1st boot.

Just a suggestion to you, you if can make changes & this HideRecommedation script can be run in Enterprise Edition as well, then it would be great.
 
Last edited:
I skipped Enterprise because you said it didn't need support.
that GPO is only locked by Win SKU payroll, and can't be activated without Windows SE, EDU & ENT editions. Tried & Tested.

- Pro Edition pretending to be Enterprise (SKU swap) obeys the GPO
- Enterprise Edition ignores the GPO

Added one more line to recognize Enterprise. G, N and G/N versions are unsupported.
 
I skipped Enterprise because you said it didn't need support.


- Pro Edition pretending to be Enterprise (SKU swap) obeys the GPO
- Enterprise Edition ignores the GPO

Added one more line to recognize Enterprise. G, N and G/N versions are unsupported.
ENT supports that GP natively along with ProEdu & Edu,

I suggested adding that support for ENT SKU further in the script because of these two reasons:

1. In ENT version that policy is not activated/enabled by default, by default it is disabled in GPE, if you add ENT SKU support in your script so anyone using ENT, that policy can be activated even without any manual intervention i.e. activation/enabling that policy via GPE

2. by any chance if Pro version is installed as ENT for anyone (like my case we're discussing), then also this script gonna support & work as well.

Thanks for adding, I'll test that later.
 
Does the solution above still work?
I am doing all the steps, but I still see the recommended section.
 
I am on 22H2 22621.1344
Since ExplorerPatcher doesnt work anymore, I am looking for an alternative way to disable the Recommended section.

When I enter the code [powershell -ep bypass -file HideRecommended.ps1] in the powershell, I am getting this:

Get-WindowsEdition : The requested operation requires elevation.
At C:\Scripts\HideRecommended.ps1:87 char:16
+ $CurrentSKU = (Get-WindowsEdition -Online).Edition
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: :)) [Get-WindowsEdition], COMException
+ FullyQualifiedErrorId : Microsoft.Dism.Commands.GetWindowsEditionCommand

Exception calling "ContainsKey" with "1" argument(s): "Key cannot be null.
Parameter name: key"
At C:\Scripts\HideRecommended.ps1:90 char:5
+ if ($Build -lt 22621 -or $KMS.ContainsKey($CurrentSKU) -eq $false) {
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: :)) [], MethodInvocationException
+ FullyQualifiedErrorId : ArgumentNullException

Set-ItemProperty : The requested registry access is not allowed.
At C:\Scripts\HideRecommended.ps1:99 char:1
+ Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\Exp ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : PermissionDenied: (HKEY_LOCAL_MACH...indows\Explorer:String) [Set-ItemProperty], Securit
yException
+ FullyQualifiedErrorId : System.Security.SecurityException,Microsoft.PowerShell.Commands.SetItemPropertyCommand
 
I tried once again, but the gap is still there:

Zrzut ekranu 2023-03-01 180637.png

I must restart explorer.exe ~1-2 times upon every boot, to make the gap disappear.
 

Attachments

  • Zrzut ekranu 2023-03-01 180637.png
    Zrzut ekranu 2023-03-01 180637.png
    54.5 KB
Back
Top