Handling First-Launch Overwrites
Many Windows applications create default configuration files and registry entries the first time they start. If user-level settings are imported before the application has run for the first time, the first-launch routine overwrites the restored data with defaults. This is the most common cause of failed restores.
Why This Happens
When a user logs into a new or reset profile, the following sequence occurs:
- Windows creates the user profile folder structure.
- Logon scripts, startup items, and scheduled tasks begin running.
- Applications launch (either automatically via startup entries or when the user opens them).
- Each application checks for its configuration. Finding none, it runs a first-launch wizard or creates default files.
If AppProfileSafe imports user settings during step 2 (before applications run), the restored files are in place when the application starts in step 3. However, many applications do not check whether the files already exist — they unconditionally overwrite or regenerate them.
Applications with Aggressive First-Launch Behavior
| Application | First-Launch Behavior | Recommended Approach |
|---|---|---|
| Microsoft Outlook | Creates a new mail profile under HKCU\Software\Microsoft\Office\...\Outlook\Profiles. Launches the account setup wizard. | Import after Outlook has been opened and closed at least once. Alternatively, pre-import the Outlook profile registry keys — this can skip the first-launch wizard entirely if the mail server configuration is already present. |
| Mozilla Firefox | Creates a new profile folder under %APPDATA%\Mozilla\Firefox\Profiles with a random name. Writes profiles.ini. | Import after Firefox has been opened once. The import overwrites the newly created default profile folder contents. Firefox picks up the restored data on next launch. |
| Google Chrome | Creates the Default profile in %LOCALAPPDATA%\Google\Chrome\User Data. Writes Preferences, Bookmarks, etc. | Import after Chrome has initialized once. Chrome handles missing or replaced files gracefully and regenerates any structural files it needs. |
| Microsoft Teams | Downloads and caches user data on first sign-in. Creates %APPDATA%\Microsoft\Teams with configuration and cache files. | Import Teams settings only after the initial sign-in and cache population completes. Teams regenerates cache files but preserves imported configuration. |
| Microsoft Office (general) | Runs Office First Run Experience (FRE). Sets up licensing, telemetry, and default settings in the registry. | Let Office complete its FRE before importing. The import overwrites FRE-generated defaults with the backed-up settings. |
| Adobe Acrobat Reader | Creates registry keys under HKCU on first launch. Writes default preferences. | Import after first launch. Low risk — Acrobat Reader's first-launch is non-destructive to most settings. |
The General Rule
Let the user log in, wait for all applications to start at least once, then run the import. A delay of 2–3 minutes after logon is usually sufficient for most environments. The import then overwrites the freshly created defaults with the backed-up settings. Applications pick up the restored configuration on their next launch.
Implementation
Add a timeout before the CLI import command:
:: Wait 2 minutes for first-launch routines
timeout /t 120 /nobreak > nul
:: Then import
AppProfileSafe.CLI.exe --import ^
--manifestFile "\\server\backups\%COMPUTERNAME%\%USERNAME%\Manifest.xml" ^
--apps "Firefox-User,Office-User,Chrome-User" ^
--unc-credential-store --silentMode --ignoreRestorePointLimit
For a more robust approach, see the marker file pattern in Deployment Methods for User Import.
Application-Aware Phased Import
For environments with particularly sensitive applications, split the import into phases:
| Phase | Apps | When |
|---|---|---|
| 1 — Immediate | Line-of-business apps, custom tools (no first-launch conflict) | At logon, no delay needed |
| 2 — After initialization | Firefox, Chrome, Acrobat (simple first-launch) | After 2 minutes |
| 3 — After user interaction | Outlook, Teams (account setup required) | After user has signed in and closed the app once |
Phase 3 is best handled as a self-service step — the user runs a batch file after completing their initial Outlook/Teams setup.
What About the Machine Import?
Machine-level settings (HKLM, ProgramData) are typically not affected by first-launch overwrites. First-launch routines operate in the user's context and write to HKCU and user profile folders. The machine import can safely run before the first user logon.
See Also
- Restore: Fresh Client Build — The full restore sequence with timing
- Deployment Methods for User Import — Delivery mechanisms for the delayed import
- Understanding Execution Contexts — Why user imports must run in the user's session