Windows 11 24H2 Start Menu: Choose Persistent or One-Time Pins

Windows 11’s redesigned Start menu should not receive one organization-wide policy by default. IT should use persistent control for shared and frontline devices, a one-time pinning baseline for most managed knowledge-worker PCs, and full user choice where Start customization has little operational consequence.
Microsoft’s new controls make that tiered approach practical. The redesigned menu combines apps into a scrollable All section with Category and Grid views, while Windows 11 version 24H2 now supports policies that can suppress Category view and either seed or repeatedly enforce a JSON-defined pin layout.

Build the Governance Plan Before the Interface Arrives​

The immediate task is not deciding whether Category view looks cleaner than an alphabetical grid. Administrators need to classify devices according to how Start functions in the user’s workflow, then assign the least restrictive policy that still delivers a predictable launcher.
A workable deployment sequence is:

1. Inventory Windows 11 version 24H2 devices and confirm that they have the updates required for the intended policies.
2. Divide devices into shared or frontline PCs, tightly standardized task devices, managed knowledge-worker endpoints, VDI sessions, and user-directed systems.
3. Decide whether each cohort needs a persistent pin layout, an initial layout that users can later change, or no managed pins.
4. Decide separately whether Category view should remain available or be removed in favor of Grid.
5. Create and validate the JSON pin list on a pilot group before assigning it broadly through CSP or Group Policy.
6. Test the policy across sign-out and sign-in cycles, because that is where the difference between one-time and persistent pinning becomes visible.
7. Document which cohort owns subsequent Start changes: central IT, application owners, desktop engineering, or the user.

This separation matters. Pin enforcement controls the launcher’s curated shortcuts, while Hide Category view controls how the installed app inventory is displayed. Treating them as a single “Start menu lockdown” setting obscures two different governance decisions.
Microsoft introduced Group Policy support for the JSON-based Configure Start Pins policy in Windows 11 version 24H2 with KB5062660, OS Build 26100.4770, released as a preview on July 22, 2025. The equivalent policy can also be delivered through the Start Policy CSP.
Hide Category view arrived later for Windows 11 version 24H2 with KB5067036, OS Build 26100.7019, released as a preview on October 28, 2025. Microsoft’s documentation says enabling the policy removes Category as an available option and makes Grid the default.
Those requirements should be part of deployment targeting rather than assumed from the Windows 11 version label alone. A 24H2 device without the necessary servicing level does not provide the same policy surface as an updated 24H2 endpoint.

---

Shared PCs Need a Launcher, Not a Personal Canvas​

A shared workstation benefits most from consistent pins because the device is expected to present the same entry points to multiple people. If every sign-in can leave behind a different arrangement, support instructions become less reliable and the next user may inherit a launcher that no longer reflects the device’s purpose.
For these systems, applyOnce:false is the defensible default. Configure Start Pins then reapplies the JSON pin list at every sign-in, undoing user rearrangements and returning Start to the managed state.
That behavior fits reception desks, training rooms, lab systems, and other shared PCs where repeatability outweighs personalization. It also gives support teams a stable reference point: an instruction such as “open the pinned application from Start” continues to describe the managed experience.
Category view deserves a separate assessment. Hiding it may reduce variation by forcing everyone into the alphabetical Grid view, but it does not create a custom enterprise taxonomy. Microsoft generates the All section from installed applications, and the documented policy surface does not let administrators define, rename, or reorder Category groups.
That limitation is central to the decision. An organization cannot create categories such as “Clinical,” “Warehouse,” or “Approved Finance Tools” and expect Start to become a managed departmental portal. If Category’s automatic grouping does not suit the environment, Hide Category view is an opt-out control, not a category-management system.
Frontline devices may call for persistent pins for the same reason, although the need depends on how narrowly the PC is used. A task-oriented endpoint with a small set of important applications benefits from enforced placement; a frontline PC used for varied duties may become harder to use if every worker’s adjustments disappear at sign-in.

One-Time Pins Fit the Managed Knowledge Worker​

Most knowledge-worker deployments need a baseline rather than a permanent reset. IT can place required business applications in predictable positions without claiming lifelong ownership of every shortcut.
That is the purpose of applyOnce:true. The policy establishes the initial JSON-defined layout but does not reset later user changes at every sign-in. Employees can unpin applications they rarely use, add tools relevant to their role, and reorganize Start after the baseline has been applied.
This model offers a useful compromise for new-device provisioning and profile creation. Corporate applications remain discoverable on first use, but the Start menu can evolve with the employee’s working habits.
It also avoids an easily underestimated support problem. With applyOnce:false, a user may successfully rearrange pins during the day and then discover after the next sign-in that all changes have vanished. Unless the enforced behavior is intentional and clearly communicated, users are likely to interpret that reset as a roaming-profile failure, synchronization problem, or Windows bug.
One-time application requires its own operational discipline. Desktop engineering must decide when the baseline is considered delivered and how later revisions will reach existing users. The policy’s value is precisely that it stops reapplying the layout, so it should not be treated as a constantly updated software catalog.
For broader discussion of the interface itself, WindowsForum’s coverage of the Windows 11 24H2 and 25H2 Start redesign examines the scrollable layout, Category browsing, and changes to Recommended. The enterprise question sits one layer above that user-interface debate: whether the organization should preserve, initialize, or continuously override the user’s choices.

Category View Is a Consistency Choice, Not an App-Control Boundary​

Category view groups applications by type, while Grid lists them alphabetically. Both are presentations of the All inventory generated from installed applications, not competing application allowlists.
That distinction prevents policy overreach. Hiding Category does not remove an installed application, block its execution, or transform Start into a restricted software catalog. It merely removes Category as a selectable view and makes Grid the default.
For knowledge workers, leaving Category available is generally the lower-friction choice. Users can decide whether automatic grouping or alphabetical scanning better matches how they locate software. IT gains little from suppressing that choice unless support, training, or task consistency depends on everyone seeing the same presentation.
There are still legitimate reasons to enforce Grid. An organization may maintain instructions based on alphabetical app names, operate shared workstations where predictable navigation is important, or find that automatically generated categories complicate rather than simplify application discovery.
The policy should therefore be justified by a workflow, not a preference from the desktop engineering team. “We prefer Grid” is weak governance; “our shared-device instructions require a stable alphabetical inventory” is an operational reason.
WindowsForum’s earlier examination of customization and enhanced user control reflects why the interface has attracted strong reactions. For managed environments, however, visual preference is secondary to whether a support procedure remains consistent across sessions and devices.

---

VDI Turns Sign-In Behavior Into the Main Test​

VDI requires careful validation because Start behavior intersects with profile lifecycle and session expectations. The relevant question is not simply whether a virtual desktop is persistent, but whether the organization expects each session to begin from a standardized launcher or preserve the user’s accumulated customization.
A tightly controlled pooled environment may justify applyOnce:false, especially when sessions are intended to feel interchangeable. Reapplying pins creates a known starting point regardless of where the user lands.
A user-oriented virtual desktop may be better served by applyOnce:true. If personalization is expected to persist, repeatedly resetting pins undermines that promise even when the rest of the profile behaves normally.
Testing must include at least one complete sign-out and new sign-in. Looking at Start immediately after policy delivery confirms the JSON can be processed, but it does not prove that the chosen enforcement model matches the intended experience.
Administrators should also test absent or removed applications. A pinning baseline is only useful when its entries correspond to the software actually delivered to that cohort. The Start policy should follow application assignment and device role rather than become a universal JSON file copied across every Windows deployment.

The Safest Default Is Selective Management​

The redesigned Start menu does not require IT to choose between total lockdown and total freedom. Its policies support three distinct operating models:

• Persistent enforcement is appropriate when every sign-in must restore a controlled launcher.
• One-time application is appropriate when IT wants to establish a corporate baseline while allowing later customization.
• No pin policy is appropriate when users already receive applications through other managed workflows and Start arrangement has no support or operational value.

Hide Category view can then be layered onto any of those models where a standardized alphabetical presentation is required. It should not be enabled merely because pinned applications are managed.
The largest risk is assigning persistent JSON pinning to all managed PCs because it appears administratively tidy. That choice transfers ownership of everyday launcher organization to IT and creates an ongoing obligation to maintain a layout suitable for every role.
The opposite risk is ignoring the new controls until the redesigned Start menu reaches users. Shared and task-oriented devices may then adopt a presentation that support teams have not documented, while administrators lose the opportunity to test policy behavior before it affects production sign-ins.
A pilot should therefore compare the three governance models, not just Category against Grid. If IT can state who owns the launcher after deployment—and what should happen at the next sign-in—the policy choice is probably sound. If that answer remains unclear, the organization is still debating appearance when it should be defining control.

---

References​

1. Primary source: learn.microsoft.com
   
   

   Start Policy CSP | Microsoft Learn

   Learn more about the Start Area in Policy CSP.

   learn.microsoft.com
2. Primary source: WindowsForum
   
   

   Windows 11 Start Menu Update: Customization and Enhanced User Control | Windows Forum

   Windows 11 is once again refining its user experience with a fresh update to the Start menu that puts customization and app management at the forefront...

   windowsforum.com

 

[ChatGPT]

Windows 11 24H2 organizations should use persistent Start pins on predictable shared devices, apply a one-time baseline on most individually assigned PCs, and leave defined exception groups user-managed. WindowsForum user reports on the 24H2 pinning choice make the practical point: one organization-wide Start policy is rarely the right answer because the reset behavior matters more than the pin list itself.
Configure Start Pins can place approved apps and shortcuts in a defined order through JSON. The administrative decision is whether Windows reapplies that definition after each sign-in or applies it once and preserves the user’s later edits. Persistent reapplication fits shared, task-specific endpoints. A one-time baseline gives users a usable first-day layout without treating ordinary personalization as a policy violation.
WindowsForum coverage of Start menu testing has also repeatedly focused on user control, app management, and frustration with clutter. That makes pinning policy a support and workflow decision, not merely a configuration task. IT can make required tools easy to find while still deciding where employees should retain control of the layout.

The Decision Is About Reset Behavior, Not Pinning Capability​

Microsoft documents Configure Start Pins as a policy that can replace the current or default Start pinned-app list with a JSON-defined list. The JSON specifies the items and their order. The policy is available through Group Policy and the Policy CSP, with both device and user targeting available.
For Group Policy, Configure Start Pins is available on Windows 11 version 24H2 with KB5062660. Confirm that prerequisite before building a rollout around the setting; earlier Windows 11 releases do not expose the GPO.
The important configuration choice is Apply once:

• Apply once = Disabled: the pin definition is reapplied at sign-in. This is the persistent mode.
• Apply once = Enabled: Windows applies the definition once, then preserves the user’s subsequent pinning, unpinning, and ordering changes. This is the one-time baseline mode.

In Group Policy Management Editor, go to either:
Computer Configuration or User Configuration
> Administrative Templates
> Start Menu and Taskbar
> Configure Start Pins
Enable the policy. In the policy’s Options section, paste the JSON into the Configure Start Pins field, then set Apply once to Enabled for a one-time baseline or Disabled for persistent sign-in reapplication.
For Policy CSP deployments, such as a custom Intune profile, supply the JSON string to the Configure Start Pins policy value and configure the corresponding Apply Once value: 1 for one-time application and 0 for persistent application. Use device-scoped CSP targeting for shared endpoints and user-scoped targeting when the layout should follow a person across eligible devices.
Do not treat the two modes as a cosmetic difference. Persistent mode can restore the approved layout after every sign-in. One-time mode is designed to establish the initial corporate layout while allowing the employee to make it their own.

Choose the Mode by Device Behavior​

WindowsForum reports specifically recommend persistent control for shared and frontline devices and a one-time baseline for many individually assigned systems. That is a useful starting point, but organizations should validate it against their own users rather than apply role labels as universal rules.

Device type	Recommended targeting	Reset mode	Validation test
Shared or task-specific PC	Device	Persistent: Apply once = Disabled	After a user rearranges or removes a pin, sign out and sign in; the approved order must be restored.
Individually assigned standard work PC	User, or device when assignment is stable	One-time: Apply once = Enabled	After a user rearranges or removes a pin, sign out and sign in; the user’s edits must remain.
Specialized or exception group	Usually user, or leave unconfigured	User-managed unless a defined baseline is required	Confirm the group can complete its normal workflow without required tools being obscured or repeatedly restored.

Shared reception stations, training-room devices, service counters, and other tightly defined endpoints are examples of systems that may benefit from persistent mode. The next person using the device should see the same approved launch points in the same order. In that situation, a user moving or removing a pin can affect another user’s ability to begin work.
A one-time baseline is often better for an employee’s primary laptop or desktop. IT can pin required tools initially, but users can later move a browser, add a project app, remove an unused item, or organize their work around their own habits. The goal is not to abandon standardization; it is to distinguish application availability from Start menu personalization.
Exception groups should be deliberate. Developers, executive support staff, users with established accessibility workflows, and other specialized populations are examples—not automatic exemptions. Before leaving Start unmanaged, test task predictability, shared sign-in behavior, and application-set consistency. A group with a highly consistent workflow may still benefit from a baseline, while a group with varied tools and individualized navigation may not.

Supply a JSON Definition That Matches the Target Device​

A usable Configure Start Pins deployment requires more than “create a JSON definition.” The JSON must be pasted into the Configure Start Pins text field in the GPO, or sent as the Configure Start Pins string value in the Policy CSP profile. It should reference only apps or shortcuts that are already deployed on every targeted device.
This minimal example pins one organization-managed shortcut:

{
  "pinnedList": [
    {
      "desktopAppLink": "%ALLUSERSPROFILE%\\Microsoft\\Windows\\Start Menu\\Programs\\Contoso Support Portal.lnk"
    }
  ]
}

This example is valid only if IT deploys a shortcut named Contoso Support Portal.lnk to this exact location on every target device:
C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Contoso Support Portal.lnk
The shortcut can point to a web portal, a locally installed line-of-business application, or another approved resource. What matters is that the shortcut exists before the pin policy is evaluated and that its name and path are identical across the targeted devices.
A practical rollout sequence is:

1. Deploy the application or managed shortcut first.
2. Verify the shortcut exists at the exact path on a representative target device.
3. Paste the JSON into the enabled Configure Start Pins GPO, or place the same JSON string in the CSP profile.
4. Set Apply once to Enabled or Disabled according to the device tier.
5. Assign the policy only to devices or users that have the required application and shortcut set.
6. Run the sign-out/sign-in validation test from the decision table.

For a GPO pilot, device targeting is usually clearer for shared PCs because the layout belongs to the endpoint regardless of who signs in. User targeting can be more appropriate for individually assigned PCs when the organization wants the baseline associated with a particular employee. Avoid overlapping user and device policies with conflicting JSON definitions unless the precedence and intended result have been tested.

App and Shortcut Consistency Is the Quiet Failure Point​

Microsoft’s implementation requirement is significant: apps and shortcuts referenced in the managed layout must exist locally and in the same locations on every targeted device. A pin policy cannot compensate for inconsistent application deployment.
That requirement should influence both the JSON and the targeting strategy. If one device group has an approved application, another group uses a different package, and a third group has no access to the tool, they should not all receive the same pin definition simply because they are part of the same department.
Build layouts around deployment reality:

• Use a common JSON only when every referenced target is installed or created consistently.
• Create separate layouts when application sets differ by image, site, security boundary, or job function.
• Use a managed all-users shortcut when a direct application reference would vary between deployment methods.
• Validate the local path on an actual target device, not only on the administrator’s reference machine.

WindowsForum discussions about Start menu customization often center on the visible interface, but deployment failures are frequently less visible: a missing shortcut, a changed file path, or an application that arrived after the pin policy. Keep application deployment and Start configuration in the same pilot plan.

Pilot Against a Clear Acceptance Criterion​

The initial layout is not enough to prove the policy works. Every pilot should include both the first sign-in experience and the behavior after the user changes the layout.
For persistent targets, the acceptance criterion is straightforward: after a user pins, unpins, or reorders an item, then signs out and signs back in, the approved pinned items and order must be restored.
For one-time targets, the criterion is the opposite: after the initial layout is applied, a user’s pinning, unpinning, and ordering changes must remain after a sign-out/sign-in cycle.
Test these criteria with people who perform the actual work on the devices. Organizations should specifically assess:

• Whether tasks are predictable enough to justify a fixed layout.
• Whether multiple people use the same Windows sign-in endpoint.
• Whether every targeted device has the same application and shortcut set.
• Whether users can find required tools without needing the layout to be permanently reset.
• Whether the support team can explain why a given group receives persistent, one-time, or no pin management.

A short pilot with these tests is more useful than a broad rollout based solely on job titles. The policy should match how the endpoint is used, who uses it, and whether a consistent launch surface is operationally necessary.

Frequently Asked Questions​

Does Configure Start Pins prevent users from changing Start?​

No. Users can make changes during their session. The important distinction is whether the policy is reapplied at sign-in. With Apply once = Disabled, the approved pins return after the next sign-in. With Apply once = Enabled, later user edits remain.

Where do I set persistent versus one-time behavior in Group Policy?​

Open Configure Start Pins under Computer Configuration or User Configuration > Administrative Templates > Start Menu and Taskbar. Enable the policy, paste the JSON into the Configure Start Pins field, then set Apply once to Disabled for persistent reapplication or Enabled for one-time application.

Can I use this GPO on Windows 11 releases before 24H2?​

Microsoft states that the Configure Start Pins GPO is available on Windows 11 version 24H2 with KB5062660. Confirm the OS version and update level before expecting the setting to appear.

Should every employee receive the one-time baseline?​

No. It is often a good default for individually assigned work PCs, but it should not replace testing. Shared devices may need persistent pins, while specialized groups may need a user-managed Start layout.

Why must pinned targets be identical across devices?​

The policy depends on the referenced apps and shortcuts existing locally in the same locations. If a shortcut or application is absent on some targets, the layout is no longer dependable. Target the JSON only where its required app set has been deployed consistently.

---

References​

1. Primary source: learn.microsoft.com
   
   

   Start policy settings | Microsoft Learn

   Learn about the policy settings to configure the Windows Start menu.

   learn.microsoft.com
2. Primary source: WindowsForum
   
   

   Windows 11 Start Menu Update: Customization and Enhanced User Control | Windows Forum

   Windows 11 is once again refining its user experience with a fresh update to the Start menu that puts customization and app management at the forefront...

   windowsforum.com