Why This FortiClient Upgrade Fails More Often Than It Should
Upgrading endpoint security software should be routine. In reality, FortiClient upgrades—especially minor version jumps—can expose deep-seated Windows Installer issues that have been quietly lurking on systems for years.
One particularly frustrating example is MSI Error 1723, which commonly appears when upgrading FortiClient 7.2.2.0864 to 7.2.3.0929. I’ve seen this error surface repeatedly across managed enterprise environments, VDI images, and even well-maintained laptops that otherwise appear healthy.
The reason it’s so frustrating?
The error message is vague, the installer rolls back without meaningful logs by default, and the fix is deceptively simple—once you know where to look.
This article explains why Error 1723 occurs, what it actually means, and how to fix it properly, based on real-world troubleshooting rather than generic advice.
Understanding MSI Error 1723 in Plain English
The full error message typically looks like this:
Error 1723. There is a problem with this Windows Installer package. A DLL required for this install to complete could not be run. Contact your support personnel or package vendor. Action CA_InstallFCTServices, entry: MSI_InstallFCService, library: C:\Windows\Installer\MSIFAAA.tmp
The solution is really simple but can be quite frustrating to troubleshoot. The error relates to either a problem with the Windows Installer service or a specific DLL and permissions to the DLL on installation. If you follow one of the possible solutions below the installation will then be successful.
Despite the wording, this is rarely a FortiClient bug.
What’s Actually Happening
MSI Error 1723 occurs when:
- A custom action DLL embedded in the MSI cannot execute
- Windows Installer cannot load or run temporary DLL files
- Permissions or profile corruption block execution
- The Windows Installer service is improperly registered
In the case of FortiClient, the failure usually happens while installing or upgrading FortiClient services, not during file copy.
Why FortiClient 7.2.3 Triggers This Error
FortiClient 7.2.3 introduced changes to service handling and driver installation. During the upgrade process, the installer:
- Extracts DLLs to the Windows Installer temp cache
- Executes custom actions under the current user context
- Interacts with system-level services and drivers
If any of the following are broken, the upgrade fails:
- Corrupt Windows Installer registration
- Locked or restricted
%TEMP%directory - Profile-level permission issues
- Antivirus intercepting DLL execution
This is why the same installer may:
- Fail on one machine
- Succeed immediately on another
- Work perfectly after a user profile change
Solution 1: Verify Windows Installer Is Healthy (Often Overlooked)
Many systems technically have Windows Installer installed—but it may be outdated, damaged, or partially deregistered.
Why This Matters
FortiClient relies on modern MSI behavior, especially during service installation. Older or broken Windows Installer components can’t reliably execute custom actions.
What to Do
- Confirm Windows is fully patched
- Ensure Windows Installer is enabled:
services.msc- Verify Windows Installer is not disabled
- If managing older systems or golden images, ensure Windows Installer 4.5+ is present
Real-world tip:
I’ve seen this issue most often on machines that were upgraded in-place from older Windows builds or cloned from outdated images.
Solution 2: Fix Temp Folder Permissions (Most Common Root Cause)
This is the fix that solves most Error 1723 cases, yet it’s rarely documented properly.
Why Temp Permissions Break MSI Installs
During installation, Windows extracts temporary DLLs to:
C:\Users\<username>\AppData\Local\Temp
If the current user:
- Doesn’t own the folder
- Lacks execute permissions
- Has inherited restrictions
…the MSI fails when it tries to run the DLL.
How to Fix It
- Log in as the affected user
- Navigate to:
C:\Users\<username>\AppData\Local - Right-click Temp → Properties
- Go to Security → Edit
- Add the current user explicitly
- Grant Full Control
- Apply and close
Additional Best Practices
- Temporarily disable antivirus during install
- Avoid installing from network shares
- Copy the installer locally first
From experience:
Endpoint security software is particularly sensitive to temp folder restrictions because it executes low-level components early in the install.
Solution 3: Re-Register Windows Installer (Surprisingly Effective)
If permissions look correct and the error persists, Windows Installer itself may be incorrectly registered.
Why This Works
Over time, registry cleaners, failed updates, or third-party software can break MSI service registration.
Steps to Re-Register MSI
- Open Run (Win + R)
- Execute:
msiexec /unreg - Press Enter
- Open Run again
- Execute:
msiexec /regserver - Reboot the system
- Retry the FortiClient upgrade
This resets the Windows Installer service without affecting installed applications.
Advanced Troubleshooting (When the Basics Don’t Work)
If you’re dealing with stubborn systems or enterprise rollouts, consider:
Run the Installer with Logging
msiexec /i FortiClient.msi /l*v install.log
Search the log for:
Return value 3CA_InstallFCTServices
Try a Clean Removal
- Uninstall FortiClient completely
- Reboot
- Remove leftover services and drivers
- Reinstall 7.2.3 fresh
Test with a New User Profile
If it installs successfully under another profile, the issue is profile corruption, not FortiClient.
Lessons Learned from the Field
After dealing with this issue across multiple environments, a few patterns stand out:
- MSI Error 1723 is almost never the vendor’s fault
- User profile health matters more than most admins realize
- Temp folder permissions break silently over time
- Antivirus products can interfere even when “disabled” at a policy level
Understanding these patterns makes future troubleshooting significantly faster.
Final Thoughts
MSI Error 1723 during a FortiClient 7.2.3 upgrade is a classic example of Windows Installer fragility surfacing during security software updates. The fix is rarely complex—but it does require knowing where Windows hides its problems.
If you manage endpoints at scale, I strongly recommend:
- Auditing temp folder permissions in baseline images
- Validating MSI health before large upgrades
- Documenting this issue internally—because it will happen again
From my early days on the helpdesk through roles as a service desk manager, systems administrator, and network engineer, I’ve spent more than 25 years in the IT world. As I transition into cyber security, my goal is to make tech a little less confusing by sharing what I’ve learned and helping others wherever I can.