Troubleshooting: Content and Localization Verbiage Changes Are Not Taking Effect

Version Affected: All
 
 

Overview

After modifying verbiage in the Content and Localization editor, the changes do not take effect — either the save appears to succeed but login pages and the admin console still show the old text, or the resource compile step visibly fails. In other cases, opening or saving Content and Localization throws a Server Error page outright instead of failing silently.

This error has seven possible causes:

• See Cause 1 - The resource compiler fails to rebuild MFA.SecureAuth.Resource.dll because a file it depends on is missing, corrupted, or permission-restricted.
• See Cause 2 - A Group Policy Object (GPO) is blocking MSBuild.exe from running.
• See Cause 3 - The RSA MachineKeys folder does not have the permissions the SecureAuth Admin identity needs.
• See Cause 4 - A verbiage change was copied to another server manually, and an old Language_en.resx file is still being referenced.
• See Cause 5 - (SecureAuth0) Another process is holding a lock on the resource DLL.
• See Cause 6 - Leftover checksum files in the Resource folder make the Content and Localization page throw an XML error.
• See Cause 7 - A modified language .resx file contains an unclosed HTML tag inside a verbiage value.

These causes are not related, so a fix for one cause will not resolve the others.

 

In this article

• Cause 1: The Resource Compiler Fails Due to Missing or Corrupted Files
• Cause 2: A GPO Is Blocking MSBuild.exe From Running
• Cause 3: The RSA MachineKeys Folder Has Incorrect Permissions
• Cause 4: A Manually Copied Verbiage Change References an Old Language File
• Cause 5: Another Process Is Locking the Resource DLL (SecureAuth0)
• Cause 6: Leftover Checksum Files in the Resource Folder
• Cause 7: A Malformed Tag Inside a Language Resource File

Cause 1: The Resource Compiler Fails Due to Missing or Corrupted Files

SecureAuth stores each realm's Content and Localization verbiage in .resx files under D:\SecureAuth\ResourceCompiler. Whenever a verbiage change is saved, SecureAuth runs MSBuild.exe to compile those .resx files into MFA.SecureAuth.Resource.dll. If a file this compile step depends on is missing or corrupted, or if file permissions on the Identity Provider (IdP) are broken, the compile fails and the DLL is never rebuilt — so the saved change never reaches the login pages or admin console.

To resolve this:

1. Run Reset File Perms and Shares (under Start > All Programs > SecureAuth on the IdP) to restore the file and folder permissions the compiler needs, then try saving the verbiage change again.

2. If the verbiage change still doesn't take effect, open Command Prompt as Administrator and run the applicable command to compile manually so you can see the actual error:

   "C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe" "D:\SecureAuth\ResourceCompiler\MFA.SecureAuth.Resource811.csproj" /p:Configuration=Release

    

3. Look for the red error text immediately above Build FAILED to identify what's missing.
   
   
    
4. If the error references Properties\AssemblyInfo.cs and the ResourceCompiler folder has no Properties folder, as shown below, create the folder and place AssemblyInfo.cs inside it.
   
   
   
   
    
5. If the error instead references a missing *.resx or *.Designer.cs file, restore that file from a backup or from a working SecureAuth server on the same version.
6. If the error instead reads Access Denied to 'FileName', run Reset-File-Perms.bat (found in D:\MFCApp_Bin\Extras), then try the build command again. If the error still persists, go to the file named in the error, right-click it, go to Properties > Security > Edit, and confirm NETWORK SERVICE has Modify, Read & Execute, Read, and Write permissions enabled.
7. Run the build command again. A Build succeeded message confirms the fix — the verbiage change will now be reflected.
   
   

Cause 2: A GPO Is Blocking MSBuild.exe From Running

Some environments apply a Group Policy Object (GPO) or software restriction policy — such as AppLocker — that prevents unrecognized or non-allowlisted executables from running. If MSBuild.exe is blocked this way, the resource compile step never runs. Unlike Cause 1, no files are missing and no compiler error appears — the verbiage change simply never takes effect.

To resolve this:

1. Attempt to run the manual MSBuild.exe command shown in Cause 1, step 2.
2. If the command is silently blocked, is denied without producing normal MSBuild output, or Windows reports that it was stopped by policy, check with your domain administrator whether a GPO or software restriction policy is restricting MSBuild.exe on the IdP.
3. Add an exception so MSBuild.exe can run on the IdP.

Cause 3: The RSA MachineKeys Folder Has Incorrect Permissions

Starting in SecureAuth IdP 9.x, the Admin realm runs under an IIS Application Pool identity rather than the local account used in earlier versions. That Application Pool identity needs access to the RSA key container under C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys to complete a verbiage save. If the Application Pool identity lacks that access, the save fails without a clear error in the SecureAuth UI.

To resolve this:

1. On the IdP, go to C:\Windows\Temp and rename or remove the file .NETFramework,Version=v4.5.AssemblyAttributes.cs, shown below. This file can go stale and interfere with the operation.
   
   
    
2. Try updating the verbiage again.
3. Only continue to the next steps if the verbiage update still doesn't work after step 2 — and make sure you have a backup or snapshot of the machine first.
4. Go to C:\ProgramData\Microsoft\Crypto\RSA, right-click MachineKeys, and select Properties > Security.
5. Grant the local Administrators group Full Control on this folder.

We no longer recommend adding permissions beyond this at the MachineKeys level, since it can change the available Cryptographic Service Provider (CSP) for your certificates. If the existing permissions are non-standard for another reason, capture a screenshot and contact SecureAuth Support before making further changes.

Cause 4: A Manually Copied Verbiage Change References an Old Language File

When a Content and Localization change is copied to another realm or server manually — for example because FileSync isn't available between the servers — it's common to rename the existing Language_en.resx to Language_en.resx.old before copying in the new one. The target server's SecureAuth UI keeps referencing the old file, so the change takes effect after authentication but is not reflected back in the Content and Localization editor itself.

To resolve this:

1. From the source (staging) server with the correct configuration, copy both D:\Secureauth\SecureAuthx\Resource\Language_en.resx and D:\Secureauth\SecureAuthx\bin\MFA.SecureAuth.Resource.dll to the target server's realm.
2. Save the change in the SecureAuth UI on the target server.
3. Do not leave a Language_en.resx.old file in the Resource folder. If you want to keep a backup of the original, move it to a different directory instead.

For reference, the Content and Localization editor exposes each verbiage string as a labeled field:

Cause 5: Another Process Is Locking the Resource DLL (SecureAuth0)

On SecureAuth0 (Cloud), version 9.3 and later, the SecureAuth Cloud Transport Service can hold a lock on MFA.SecureAuth.Resource.dll. When this happens, Windows reports that the file is in use, and the compiler cannot overwrite it with the new verbiage, so the change never takes effect.

To resolve this:

1. Open Services.msc.
2. Locate and stop the SecureAuth Cloud Transport Service.
3. In the Admin Console, save the verbiage changes.
4. Start the SecureAuth Cloud Transport Service again.

Cause 6: Leftover Checksum Files in the Resource Folder

Clicking Content and Localization on the realm's Overview tab can fail with a Server Error page reporting System.Xml.XmlException: Data at the root level is invalid. Line 1, position 1. This happens when the realm's Resource folder contains leftover checksum files — with extensions .sha1, .sha256, or .md5 — alongside the .resx verbiage files. The Content and Localization editor reads every file in the Resource folder as XML, and these checksum files are plain text, not XML, so the read fails.

To resolve this:

1. Go to the affected realm's Resource folder.
2. Delete any files with the extensions .sha1, .sha256, and .md5.
3. If multiple realms are affected, run the following PowerShell script to remove these file types from the Resource folder of every realm at once:

$Directory = 'D:\SecureAuth'
$Folders = Get-ChildItem -Path $Directory -Recurse -Include Resource -Depth 2
foreach ($Folder in $Folders) {
    Get-ChildItem -Path $Folder -Include ('*.sha1','*.sha256','*.md5') -Recurse | ForEach-Object { Remove-Item $_.FullName }
}

Cause 7: A Malformed Tag Inside a Language Resource File

Updating the Resource files from the Admin Console can fail with a Server Error page reporting a System.Xml.XmlException similar to "The 'p' start tag on line X position Y does not match the end tag of 'value'". This happens when one of the realm's modified language .resx files contains a verbiage value with an HTML <p> tag that was never closed. Because .resx files are themselves XML, an unclosed tag inside a verbiage value breaks the file's XML structure, and the resource file update fails.

To resolve this:

1. On the IdP, go to D:\SecureAuth and search for .resx files, sorting by date modified — the most recently modified file is the most likely culprit.
2. Open that file in a text editor and locate the line and position the error message points to.
3. Find the unclosed <p> tag inside the affected <value> element and either close it or remove it.
4. Save the file and try the update again — if it still fails, the error message will point to the next malformed tag, if any.

Opening Content and Localization in the Admin Console for the affected realm will surface the same error, which can help confirm which realm's .resx file is the source.

SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.