Odd issue of User profile/desktop changes not sync to server 2025 and srever loading an old desktop when they login

Andre Bunting 20 Reputation points
2026-06-05T18:49:06.03+00:00

Good day,

This is odd, i dont see any errors in the folder replication log on the server. I have a user that when they log out, the changes they have made may it be a file or folder on their desktop or document folder is not syncing/replicating to the server. But when they log back in, the desktop/documents are not showing the recent changes.

I have checked the folder ntfs permissions and the user and admin have full control of the profile folder d:\profile$\bob.

The sync was working for a few weeks, so i dont know what happened.

Windows for business | Windows Server | Directory services | User logon and profiles
0 comments

4 answers

Sort by: Oldest
Most helpful Newest Oldest

  1. AI answer

    2026-06-05T18:49:33.5833333+00:00

    The described behavior matches a profile/desktop not being written back to the server profile share, typically due to permissions or profile load issues, even if basic NTFS checks look correct.

    Based on the available information, the following checks are supported:

    1. Verify the profile is not loading as a temporary or local profile
    • When the user signs in, confirm whether Windows is loading the roaming/server profile or a temporary/local profile.
    • If a temp/local profile is used, changes will never be written back to d:\profile$\bob and the server will continue to serve an older copy.
    • Event Viewer → Application log → source User Profile Service (or User Profile General) will show events like 1509/1504 indicating profile copy or sync problems.
    1. Check for access/permissions problems on profile data files
    • Profile load and sync can fail if key profile data files are read-only or have incorrect ACLs.
    • Ensure NTUSER.DAT and USRCLASS.DAT in the user’s profile (both in the default profile and in the user’s cached/local profile) are:
      • Not marked Read-only.
      • Assigned permissions so that the user account has Full Control.
    • If these files are read-only or the user lacks write permissions, profile load and save can fail silently or log only in the event log.
    1. Confirm NTFS and share permissions on the profile share path
    • For UNC paths used for profiles or offline files, all parts of the path must be accessible with appropriate permissions.
    • On the share and NTFS permissions for the root of the profile share and subfolders, ensure:
      • The user has at least Read/Write (Change) on their own profile folder.
      • Everyone is removed where recommended, and a security group containing the user is granted the required access.
      • Administrators may intentionally have no permissions on user data folders in some designs; confirm this matches your configuration and does not block the user.
    1. Check for profile load failures due to access denied or path issues
    • After the January 13, 2015 update that tightened checks on Ntuser.dat and Usrclass.dat, profile load failures can occur if access is denied to these files.
    • Use Process Monitor or event logs to see if there are ACCESS DENIED errors when the system tries to open UsrClass.dat or Ntuser.dat in the user profile.
    • If such access failures occur, the profile may not load or save correctly, causing the server copy to remain stale.
    1. Review roaming profile / sync events for access denied
    • For roaming profiles, events such as 1509 and 1504 (User Profile General) indicate when Windows cannot copy profile files back to the server due to access denied or other issues.
    • Look specifically for messages like:
      • “Windows cannot copy file … This error may be caused by network problems or insufficient security rights. DETAIL – Access is denied.”
    • These events confirm that changes on the desktop/documents are not being written back to the server profile path.

    If event logs show profile load failures, access denied to Ntuser.dat/Usrclass.dat, or roaming profile copy failures, correcting those permissions and attributes is required before changes will sync back to d:\profile$\bob and users will see their latest desktop/documents on next logon.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

  2. Tracy Le 11,615 Reputation points Independent Advisor
    2026-06-05T21:04:50.5+00:00

    Hi Andre Bunting.

    The issue of user profile changes failing to sync back to the server directory while reverting to an old configuration upon logging back in usually indicates that the system is currently processing a temporary or stale local cache mapping. Even if your NTFS security permissions are set to Full Control on the profile path d:\profile$\bob, Windows will silently ignore write backs during the logoff sequence if the state registry locks the session or treats it as an unauthenticated guest. To confirm this issue, you should have the user log in, open the Event Viewer on that machine, navigate to the Application log and filter for Event IDs 1509 or 1504 under the User Profile Service source, which will provide the explicit access denied or path constraint strings blocking the replication.

    Additionally, this silent sync failure frequently occurs if the core hives like NTUSER.DAT or UsrClass.dat within the target directory are marked with a Read-only system file attribute or have explicit ownership mismatches that suppress the logoff synchronization block. You can resolve this underlying cache error by navigating directly to the local profile repository, checking the file properties, ensuring the active account maintains explicit write authorization over those registry hives and validating that the client is not falling back to a temporary registry profile path.

    Hope this answer has brought you some useful information. If it did, please hit “accept answer”. Should you have any questions, feel free to leave a comment.

    Tracy.

    Was this answer helpful?

  3. Andre Bunting 20 Reputation points
    2026-06-09T19:45:32.2633333+00:00

    Is there any tool i can use to verify what else can be wrong ?

    Was this answer helpful?

    0 comments
  4. Tracy Le 11,615 Reputation points Independent Advisor
    2026-06-11T00:38:03.92+00:00

    Hi Andre Bunting,

    Seeing Event ID 1509 in the client event logs confirms there is a file access or locking conflict during logoff, and the fact that NTFS permissions are set to Full Control means the block is happening at a deeper system level. Even if ntuser.dat is not marked as read-only, this error frequently occurs because of Share Permissions on the network folder, or more commonly, because an active process, antivirus scanner, or backup agent is maintaining an open handle on the registry hive file during the logoff sequence. When a file lock is held, the User Profile Service cannot overwrite the existing file on the server path d:\profiles$\bob, causing Windows to silently discard the session updates and load the cached version on the next login.

    To verify exactly what else is wrong and identify the root cause, the most effective tool you can use is Process Monitor (ProcMon) from Microsoft Sysinternals. You should run Process Monitor on the user desktop, set a filter for the Path containing ntuser.dat, and then capture the activity during logoff or use the boot logging feature to see which specific application or process is returning a Sharing Violation or Access Denied result. Additionally, you should inspect the Share Permissions of the profiles share to ensure they match Full Control for Authenticated Users alongside your NTFS settings, and check if Windows Search Indexing or a third-party security agent is locking the profile files.

    Tracy.

    Was this answer helpful?

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.