I'm building a Windows 11 25H2 reference image in audit mode, installing several standard applications, and sealing it with sysprep /generalize /oobe /shutdown before deploying it through a ConfigMgr task sequence.
On Windows 11 24H2, I customized the default Start menu by copying a prepared start2.bin file and an empty settings.dat file into the Default user profile's Start menu experience package directory during deployment. The start2.bin configured the pins, while the presence of settings.dat prevented newly created users from seeing a "New" badge beneath nearly every application on their first login.
That approach no longer works correctly on 25H2. The pins from start2.bin are applied, and settings.dat is copied and populated during the first login, but most applications still show the "New" badge. Copying a populated settings.dat from a reference account does not help either. I also tested the newer Configure Start Pins policy with a LayoutModification.json file. It configures the pins successfully, but the New badges remain, and the local administrator account does not receive the policy-based pins even though the policy is assigned to the computer.
I do not want to disable New badges globally through the registry because I still want applications installed later to display as new. The behavior seems related to the redesigned Start menu category and grid views in 25H2; switching to List view makes the badges visible again. Is there a file, registry value, or other setting that can be placed in the Default profile during imaging to mark the baked-in applications as already seen while preserving New badges for future installations?
1 Answer
There does not appear to be a confirmed 25H2 equivalent to the old settings.dat workaround in the discussion. The fact that the pins are applied but the badges return suggests that 25H2 is tracking the initial application state differently, particularly with the redesigned category and grid views. Disabling the badges globally would work, but it would also prevent genuinely new applications from being marked, so it does not meet the requirement. At this point, the practical options seem to be accepting the first-login badges, continuing to test the new Start menu data and policy behavior, or waiting for Microsoft to document or fix the default-profile behavior.
That matches what I’m seeing. The old workaround still gets the pins into place, but it no longer marks the preinstalled applications as already seen. I’m specifically looking for a per-profile initialization method rather than a global setting, since future application installs should still receive the New badge.