Back Up and Restore Windows 10 Start Menu Layout with PowerShell

If you’ve spent hours arranging tiles on the Windows 10 Start menu, the prospect of losing that layout during a feature update is infuriating — but there’s a practical, built‑in way to export and later restore your Start layout on modern Windows 10 builds without relying on the old TileDataLayer folder: use PowerShell’s Export-StartLayout to produce a LayoutModification.xml and copy it back into the user shell folder, then clear the CloudStore cache so the Start menu re-reads the file.

Background — why TileDataLayer stopped being the answer​

Before Windows 10 version 1703 the Start menu’s tile state was largely stored in a Jet database under %LocalAppData%\TileDataLayer\Database (the vedatamodel.edb model). Administrators and power users learned to back up and restore that folder to preserve pinned tiles, but Microsoft changed the implementation in and after the Creators Update: the tile database model moved away from TileDataLayer and the Start layout is now represented in the user’s CloudStore (registry) and in cache database files — and Microsoft’s documented tooling for Start layouts (Export-StartLayout / Import-StartLayout) exports and consumes a LayoutModification.xml template instead. This change made the old TileDataLayer backup approach unreliable or useless on modern builds.
The practical consequence: if you’re on Windows 10 version 1703 or later, backing up the TileDataLayer folder is not a dependable method. Instead, you should export the layout to an XML file with PowerShell and use the XML to restore the per‑user layout after an upgrade, image deployment, or profile replacement.

---

What the built‑in method does (quick overview)​

• Export-StartLayout reads the current user’s Start layout and produces an XML file describing tile groups and pins.
• Copying that XML into the user’s shell folder as LayoutModification.xml tells the Shell to treat it as the layout template for that user.
• Clearing the CloudStore cache (the per‑user registry entries that hold the currently-active tile cache) forces the Start system to rebuild its in‑memory/tiled cache from the LayoutModification.xml, which makes the exported tile arrangement show up again. Restarting Explorer / Shell finalizes the change.

This approach uses only built‑in PowerShell and registry operations — no third‑party tools — and it’s what many sysadmins and community guides recommend for Windows 10 (1703+) environments.

---

Step‑by‑step: Back up your Start menu layout (per user)​

• Open PowerShell with Administrator rights (right‑click PowerShell and choose “Run as administrator”).
• Run the export command (this writes LayoutModification.xml into the current user’s Local AppData):
  Export-StartLayout -Path $env:LOCALAPPDATA\LayoutModification.xml
  This produces a single XML file containing the Start layout for the currently logged‑in user.
• Copy the XML to safe storage: external drive, OneDrive, network share, or an image capture step. Treat it like any other configuration artifact — keep versioned copies if you plan iterative tweaks.

Why use $env:LOCALAPPDATA? Exporting into the user’s local profile makes it straightforward to restore later from the same per‑user location (especially useful in scripted upgrades or run‑once tasks). You can also export to any path you prefer (for example C:\Layouts\LayoutModification.xml) — the XML is portable.

---

Step‑by‑step: Restore a saved Start layout​

If you have LayoutModification.xml for a user in %LOCALAPPDATA% (or you copy it there), run this PowerShell snippet as the user (or as an elevated script run in that user context) to restore the layout:
If((Test-Path $env:LOCALAPPDATA\LayoutModification.xml) -eq $True) {
Copy-Item $env:LOCALAPPDATA\LayoutModification.xml $env:LOCALAPPDATA\Microsoft\Windows\Shell\LayoutModification.xml -Force
Remove-Item 'HKCU:\Software\Microsoft\Windows\CurrentVersion\CloudStore\Store\Cache\DefaultAccount*$start.tilegrid$windows.data.curatedtilecollection.tilecollection' -Force -Recurse
Get-Process Explorer | Stop-Process
}

• Copy-Item places the XML into the per‑user Shell folder where Start expects a LayoutModification.xml file.
• Remove-Item deletes the CloudStore cache fragment that represents the tile grid, forcing the Start infrastructure to re‑read the XML. Some guides use narrower keys (a single root node) while others clear the entire CloudStore cache in more recent builds; use the narrower delete first and escalate to the full CloudStore key only if necessary.
• Stopping Explorer (or restarting the shell experience host) triggers the rebuild and applies the layout; you’ll see the taskbar and desktop elements disappear briefly while Explorer restarts.

This restore sequence is the same approach used by community experts and proven in lab testing — it works for the vast majority of pinned desktop apps and UWP tiles, but it can miss or partially break a very small number of tiles in edge cases (see troubleshooting below).

---

Why the CloudStore delete is necessary​

Modern Windows keeps an in‑memory and on‑disk cache of pinned tiles and tile metadata under the CloudStore registry structure (HKCU\Software\Microsoft\Windows\CurrentVersion\CloudStore). Even if LayoutModification.xml is present, the active cache can override or shadow it. Removing the relevant CloudStore cache entries ensures the shell rebuilds the tile grid from the XML rather than continuing to use stale cached values. Be conservative: delete the specific tilegrid entry first; deleting the entire CloudStore key will force a full rebuild but can remove other cached UI state and should be tested.

---

What this method handles well — strengths​

• Native tooling: Uses Microsoft PowerShell cmdlets and built‑in shell behavior; no external utilities required.
• Per‑user accuracy: The exported LayoutModification.xml reflects that user’s layout (groups, tile order, desktop app pins) and can be applied back to that user’s profile to recover most pins.
• Scriptable: Works well in image builds or scripted upgrade flows: Export layouts ahead of a mass upgrade and copy them back in a RunOnce or logon script. This makes it scalable for enterprise migrations.
• Minimal downtime: The visual effect is limited to a momentary reload of Explorer; no full sign‑out or reinstall is usually necessary.

---

Known limitations and risks — what can go wrong​

• Missing or broken tiles: Some reports and tests show that a small number of tiles (especially certain Settings or special UWP tiles) may appear as “blank” or nonfunctional after restore and require manual unpin/pin to fix. This is a known, low‑frequency issue with how some tiles are represented in the XML vs. the CloudStore cache. Plan for a few minutes of manual fixes after a restore.
• Version differences and Windows 11 changes: Microsoft’s Start layout tooling and behavior have evolved across feature updates and notably between Windows 10 and Windows 11. Import-StartLayout/Export-StartLayout semantics changed and some cmdlets are deprecated in Windows 11 documentation; if you manage mixed environments (Win10 + Win11), test on each target OS. Don’t assume the method works identically across major versions.
• Registry deletion risk: Removing CloudStore keys is invasive: deleting the wrong subtree can affect other Start or tile state. Always test scripts in a VM and prefer targeted removal of the specific tilegrid key before deleting broader CloudStore entries. Maintain backups (export HKCU branches) before destructive operations.
• Taskbar pin persistence issues: In some environments, copying LayoutModification.xml to the Shell folder has been reported to interfere with taskbar pin changes (pins appear to temporarily work but disappear after reboot). This indicates the taskbar uses its own cache/registry entries; expect separate management tasks if you need taskbar pins to be strictly preserved. Test end‑to‑end.
• Roaming/profile solutions (FSLogix / roaming): If you use profile containers or roaming profiles, the restore timing and cache interaction change. FSLogix, profile containers, and cloud‑based roaming can preserve their own caches and may not accept a LayoutModification.xml overwrite without special handling. Plan separate tests for VDI and roaming profile scenarios.

If a claim encountered in community posts (for example, “TileDataLayer will never come back”) lacks an official Microsoft statement, treat it as a practical observation rather than a vendor commitment. Always check Microsoft’s docs for the current, authoritative behavior.

---

Troubleshooting checklist (if a restore doesn’t look correct)​

• Confirm the LayoutModification.xml file is well‑formed and adheres to the required schema. XML comments can break the layout file — remove comments before applying.
• Ensure the file is in the exact per‑user shell folder: %LOCALAPPDATA%\Microsoft\Windows\Shell\LayoutModification.xml. Copying to the default user only affects new profiles; for an existing user you must copy into their LocalAppData.
• First try deleting the specific CloudStore tilegrid cache node (the narrow Remove-Item path shown above). Only if that fails, consider clearing a larger CloudStore subtree after testing.
• Restart Explorer or the relevant shell package (Stop-Process Explorer or restart ShellExperienceHost) after making changes so the layout gets reloaded.
• If a particular tile is present but nonfunctional (no icon, doesn’t open), unpin it from Start and pin it again manually; many users report this resolves individual UWP tile edge cases.
• Test with a small set of apps first and validate in a single non‑production account before rolling out to many users.

---

Enterprise deployment recommendations​

• Test across representative builds: If you manage a fleet running multiple feature updates (1703, 1803, 1903, etc.), run the restore process on at least one machine per build to detect variations. Microsoft has changed behavior between versions and Windows 11 further diverges.
• Prefer per‑user scheduled export before upgrades: Schedule Export-StartLayout to run for each user prior to large upgrades, saving LayoutModification.xml into the user’s LocalAppData (or to a secured network share) so a per-user restore is possible automatically at first logon after upgrade. Jose Espitia’s community workflow automates this approach.
• Use run‑once or logon scripts carefully: Deploy the restore script via RunOnce or a logon task that runs in the user’s context (so the script writes into the correct %LOCALAPPDATA%). Avoid running as SYSTEM unless you redirect file locations appropriately.
• Document rollback and backup: Always store a copy of the user’s exported XML in a separate location (cloud or network share) and keep copies for at least one upgrade cycle. If you need to undo a change, you can restore the prior XML or rebuild the profile from backups.
• Avoid destructive CloudStore deletes without backups: Export the target HKCU\Software\Microsoft\Windows\CurrentVersion\CloudStore branch before removal so you can restore the registry if needed. Test the effect of a CloudStore clear in a pilot group before broad deployment.

---

Practical tips and gotchas​

• Use Export-StartLayout with the -UseDesktopApplicationID switch when you rely on desktop application shortcuts to ensure the XML uses DesktopApplicationID rather than a path. This helps portability when deploying to machines where folder paths vary. Verify the Microsoft docs for the correct switches for your Windows build.
• When editing LayoutModification.xml by hand (for scripted deployments), keep to the schema order Microsoft expects — LayoutOptions, DefaultLayoutOverride, RequiredStartGroupsCollection, and so on — or the file may be rejected. The docs explain the required tag order.
• Don’t rely on Import-StartLayout as a per‑user restore mechanism in all cases. Import-StartLayout is designed for image customization and can be limited or deprecated for certain Windows versions; the Copy-Item into the per‑user shell folder is the more reliable per‑user path for restoring an existing user’s exported layout.
• Watch for XML comments: community reports indicate that XML comments can break the layout file on some builds; avoid comments in production XML templates.

---

When to use this method and when to accept manual work​

This XML export/restore approach is excellent for:

• Preserving pinned desktop apps across upgrades and image refreshes.
• Automating Start layout recovery in enterprise migrations where many users have custom pin layouts.

Expect to manually re‑pin a very small number of special tiles (Settings, some UWP tiles) in rare cases. The manual cost is small compared with rebuilding entire Start menus from scratch. Keep realistic expectations: while the XML method covers the large majority of common pin types, the Start Menu’s mix of UWP, system, and desktop shortcuts means absolute, pixel‑perfect fidelity isn’t guaranteed across all Windows feature updates.

---

Security and safety checklist (do not skip)​

• Backup HKCU registry keys before deleting CloudStore entries. Export the branch with reg export or a PowerShell-backed registry export.
• Run all destructive scripts in a test VM first. Confirm the user experience after a restore.
• Keep copies of LayoutModification.xml in an access‑controlled location. Don’t leave restore XML files writable by arbitrary users on shared machines. Treat these files as configuration assets.

---

Conclusion — practical, imperfect, and the best available approach​

Backing up the Windows 10 Start layout without TileDataLayer is not only possible — it’s the recommended approach for modern Windows 10 builds: export a user’s layout with Export-StartLayout, store LayoutModification.xml, copy it back into the per‑user Shell folder when you need to restore, clear the CloudStore tile cache, and restart the shell. This method uses built‑in tooling, scales for scripted deployments, and recovers the majority of pinned tiles reliably.
That said, it’s not a magical fix for every tile in every environment. Expect to encounter a small number of quirks — blank windows for certain UWP tiles, taskbar pin persistence issues in complex environments, and variations across Windows builds — and mitigate those with testing, backups, and conservative registry operations. Where absolute, enterprise‑grade consistency is required, combine this method with careful testing on each target build, and maintain a simple playbook for manual fixes so helpdesk staff can finish any edge‑case restores in a few minutes.
The net result: you can confidently reduce the pain of rebuilding Start menus after upgrades — automate the export step, keep the XML safe, and use a tested restore script to get users back to a familiar Start layout with minimal disruption.

---

Source: AddictiveTips How to Back Up the Start Menu Without TileDataLayer in Windows 10