Erro 58tm1

Welcome to Microsoft Q&A Forum! 

Based on your description, the error (58tm1, an unexpected error occurred) in an RDS and FSLogix Office 365 container environment is typically caused by identity/token or profile container inconsistencies, not the RDG/RDS infrastructure itself. The common causes can be:

• ODFC conflicts with another profile solution: When using Office 365 containers (ODFC) without full FSLogix profile containers, the environment must ensure that no other profile solution is managing the same Office-related folders. Otherwise, conflicts can occur and lead to sign-in or token issues.
• Token/SSO initialization timing issues: In multi-session environments, Office apps rely on user profile + token data stored in the FSLogix container. If the container or identity components are not fully initialized during logon, users may receive generic errors like this, and retrying often succeeds.
• Concurrent sessions: FSLogix/OneDrive data does not support multiple simultaneous sessions using the same user profile. If the same user connects to multiple RDSH hosts, it can cause authentication or file-lock related failures.]
• Outlook/Office configuration mismatch: Incorrect cached/online mode or ODFC setup can cause instability

I would like to share the following recommended solutions that may help you.

1. Ensure only one profile solution handles Office folders (exclude those paths from other roaming profile tools)
2. Confirm no concurrent sessions for affected users
3. Verify FSLogix version is up to date (older builds had login/token initialization issues)
4. Check FSLogix profile logs on affected sessions for token errors
5. Validate Outlook mode (Online vs Cached) and ODFC configuration consistency across hosts
6. Confirm both RDSH servers have identical configuration (GPO, FSLogix version, exclusions, AV rules)

I hope this information is helpful and thank you for choosing Microsoft Q&A to raise your concern. 

Ross Nishuler

If you can't locate the redirections XML file manually, it is likely being deployed centrally through a Group Policy Object or defined directly in your server's registry. You can pinpoint the exact network or local path by opening the Registry Editor on one of your RDSH nodes and navigating to the HKLM\SOFTWARE\FSLogix\Profiles key. Look for a string value named RedirXMLSourceFolder, which will contain the definitive directory path where your environment's XML file is hosted. You should also verify your Active Directory Group Policies under the FSLogix Profile Containers administrative templates to see if a path is specified there.

It is also possible that your terminal farm was configured without a custom redirections file. If you check the registry and confirm no XML file is in use, then FSLogix folder exclusions are not the root cause of your issue. In that scenario, the path-not-found error is strictly a localized corruption of the Windows authentication cache. You should bypass the environment-level configuration checks and immediately proceed with deleting the Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy and TokenBroker folders from the affected user's local AppData directory to force a clean token rebuild.

Hope this helps :)

VP

Hi Ross Nishuler,

The error code 2147942403 means a path-not-found exception, and the 58tm1 tag points to a failure within the Web Account Manager during the Office 365 authentication process. In an environment utilizing FSLogix on remote desktop session hosts, this indicates that the Azure AD Broker Plugin is either corrupted or its necessary directories are being aggressively excluded by your redirections configuration as users roam between nodes. When the broker can't locate its stored identity tokens or the plugin files themselves, the sign-in prompt crashes.

To permanently resolve this across the terminal farm, you must verify that your FSLogix redirections XML is not excluding the Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy folder. For users who are currently stuck with the error, you will need to clear the corrupted state by having them sign out completely to release any file locks. Next, navigate to their profile path at %LOCALAPPDATA%\Packages\ and rename or remove both the Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy and the TokenBroker directories. Once those directories are cleared, the operating system will rebuild a fresh cache during the next logon attempt, which forces a clean request for identity tokens from Microsoft Entra and eliminates the path-not-found exception without requiring a complete wipe of the user's profile container.

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

VP

Error 58tm1 in this scenario is consistent with issues where Microsoft 365 Apps (Office 365) is running on Remote Desktop Session Hosts with FSLogix profiles and the Office container, and the Office apps fail unexpectedly when trying to load the user profile or Office data from the container.

Based on the provided environment details and the available information, focus on these areas:

1. Verify FSLogix profile and Office containers
   1. Confirm FSLogix is actually enabled and configured for both Profiles and ODFC containers on the RDSH servers. If FSLogix isn’t enabled, Windows may fall back to local or temporary profiles, which can cause random Office failures.
   2. Check for old, temporary, or local profiles for the affected users. If users are getting temporary or local profiles instead of their FSLogix containers, Office may fail during initialization.
   3. Ensure the remote SMB storage hosting the FSLogix containers has sufficient capacity and good performance. If the storage is full or slow, containers may fail to attach, leading to sign‑in or app‑startup errors.
2. Check for profile/container lock or concurrent use
   1. Confirm that affected users do not have another active or hung session on a different RDSH using the same FSLogix profile container. FSLogix by default allows only a single connection per container and maintains an exclusive lock.
   2. If a previous session did not sign out cleanly, the container can remain locked and subsequent sign‑ins can fail or fall back to temporary profiles, which can surface as unexpected Office errors.
   3. Consider enabling CleanupInvalidSessions to automatically clean up invalid sessions, but be aware of the known issue where this setting can affect ODFC containers in specific FSLogix versions; ensure the FSLogix version is updated if using this setting.
3. Investigate temporary/local profile conditions
   1. If PreventLoginWithFailure or PreventLoginWithTempProfile is enabled, FSLogix uses frxshell.exe to block sign‑in when the profile fails to attach. In remote app scenarios, this may not fully block sign‑in, and users can end up with temporary profiles.
   2. Review FSLogix logs for the affected users to see whether the profile failed to attach due to storage permissions (for example, “Access denied”) or because the profile is in use on another computer.
   3. If local profiles exist on the RDSH servers, FSLogix by default honors them instead of attaching the FSLogix profile. This can cause inconsistent behavior between users. If appropriate, enable DeleteLocalProfileWhenVHDShouldApply after carefully reviewing which local profiles exist, as this setting deletes local profiles at sign‑in.
4. Validate storage permissions and Kerberos configuration
   1. Ensure SMB storage permissions for the FSLogix containers are configured correctly so that the RDSH computer accounts and users have the required access. Misconfigured permissions are a common cause of profile attach failures.
   2. If the environment is being updated to newer Windows Server builds (including the April 2026 update), ensure that the file shares hosting FSLogix containers are configured to use AES‑SHA1 for Kerberos, as older RC4‑only configurations can cause access issues and profile failures.
5. Check container size and capacity
   1. Verify that the Office/FSLogix containers for affected users have not reached their configured maximum size (SizeInMBs). Containers with insufficient free space (less than ~200 MB) can fail to attach, which can cause Office to fail during startup.
   2. If necessary, increase SizeInMBs and then, during off‑hours, mount the container and remove unnecessary data so that it can compact on sign‑out.
6. Review third‑party security software
   1. If any third‑party firewall or intrusion prevention systems are installed on the RDSH servers, temporarily disable them and reproduce the issue to see whether they interfere with FSLogix’s file system drivers or SMB access.
   2. Ensure recommended antivirus file and folder exclusions for FSLogix are in place so that profile and Office containers are not blocked or delayed during attach.

In practice, for users seeing error 58tm1:

1. Check FSLogix logs for those users to confirm whether their profile and Office containers attached successfully.
2. Confirm there is no concurrent session using the same container and that no stale lock remains; if necessary, clean up invalid sessions.
3. Validate SMB storage permissions and available capacity, and ensure containers are not full.
4. Confirm that local or temporary profiles are not being used unexpectedly, and adjust FSLogix settings (DeleteLocalProfileWhenVHDShouldApply, PreventLoginWithTempProfile) as appropriate for the environment.

These checks address the most common FSLogix‑related causes of intermittent Office failures in RDSH farms.

References:

• Troubleshooting issues with old, temporary, or local profiles
• Troubleshooting issues with container locked or in use
• Known Issues
• Troubleshooting issues with long or failed sign-ins
• Error when opening the Click-to-Run version of an Office program or suite on a terminal server