Veeam Backup Fails: VSS Writer Errror 0x800423f4 (Azure AD Connect) – New 31/10/2017

This is an updated post about the issue with Veeam backup failures. The original post is here.

This can be fixed by using the following script and using it as a pre-script before backup.


stop-service -displayname "Microsoft Azure AD Sync"
$FQlogonaccount = Get-WmiObject -Class Win32_Service | ? { $_.displayname -match "Microsoft Azure AD Sync"} | select Startname
$split = $FQlogonaccount.startname.Split("\"[0])
$username = $split[1]
$sqlprocess = Get-WmiObject -Query "Select * from Win32_Process where name = 'sqlservr.exe'" | Select Name, Handle, @{Label='Owner';Expression={$_.GetOwner().User}} | ? { $_.owner -match $username} | select handle | Out-String
$sqlpid= $sqlprocess.Split("`n")[3]
Stop-Process -id $sqlpid -force
start-process -filepath "MsiExec.exe" -argumentlist "/f {6C026A91-640F-4A23-8B68-05D589CC6F18}" -wait
Start-Service -displayname "Microsoft Azure AD Sync"


  1. Save the script as ps1 file. Put somewhere in the Veeam server.
  2. Right-click the backup task and choose “Edit”
  3. Choose “Guest Processing” -> “Enable application-aware processing” -> “Applications”
  4. Choose the one VM that have AAD tool installed and click “Edit”
  5. Go to “scripts” -> “Require successful script execution”, then locate the script we just created.
  6. Now you’re done.

21 thoughts on “Veeam Backup Fails: VSS Writer Errror 0x800423f4 (Azure AD Connect) – New 31/10/2017”

  1. Hello, thanks for your useful post.
    We have some servers with installed Azure AD Connect and we need repair MS SQL Express LocalDB approximately once per month. But last week I need repair it three times in one week. Do you know whether Microsoft releases updates of Azure AD Connect client so frequently?

  2. You can update the SQL VSS writer by using any full installer for SQL and selecting “Upgrade from SQL 2005, 2008…” then follow the wizard and reboot, or select “New SQL Server Stand-alone installation…”and selecting only This can fix the ADSync backup as well as break the backup for other SQL instances if there are any on the same server so better take a test backup right after doing this and rollback if any other strange things happen.Another option is to move ADSync database to a SQL Express or Standard instance on the same server or another server:

  3. Great post and script. I tried the script manually (line per line) but when executing the MSIEXEC-part I get a popup about applications that should be closed before continuing the install. (I can get the screenshot to you if you want, it mentions many services like DHCP server, Event log, ..)

  4. I’ve followed your instructions but the backup still fails stating:

    Script finished execution with unexpected exit code: 1

    More specifically, if I run it line by line, the stop-service command returns:

    stop-service : Service ‘Microsoft Azure AD Sync (ADSync)’ cannot be stopped
    due to the following error: Cannot open ADSync service on computer ‘.’.

    If I run powershell as admin, the command works. The backup job runs with guest OS credentials for a user that has admin rights so I’m not sure what else would be required to make this succeed. It seems like the script would require elevation but I don’t see a way for Veeam to achieve this.

    Any ideas?

  5. I am an IT systems administrator for many clients, and several of my clients started having issues with Veeam backups (all seeming to relate to VSS errors and Azure AD Connect). Thank you for the PowerShell script provided above.

    I ran the PowerShell on two different virtual servers for two different clients, and the Veeam replication (for one client running Windows Server 2012 R2) and the Veeam backup (for the other client running Windows Server 2012) work after the script. That said, the virtual server running Windows Server 2012 (not R2) rebooted after the script ran, whereas the virtual server running Windows Server 2012 R2 did not reboot after the script ran. I checked the event log for the Server 2012 (not R2) virtual server and found a relevant event in the system log regarding the reboot due to the script. I’ll post it as a sub-comment to this comment.

  6. Log Name: System
    Source: User32
    Date: 11/6/2017 9:18:55 AM
    Event ID: 1074
    Task Category: None
    Level: Information
    Keywords: Classic
    User: SYSTEM
    Computer: [serverName].[ADdomainName].COM
    The process msiexec.exe has initiated the restart of computer [serverName] on behalf of user NT AUTHORITY\SYSTEM for the following reason: No title for this reason could be found
    Reason Code: 0x80030002
    Shutdown Type: restart
    Comment: The Windows Installer initiated a system restart to complete or continue the configuration of ‘Microsoft SQL Server 2012 Express LocalDB’.
    Event Xml:




    No title for this reason could be found
    The Windows Installer initiated a system restart to complete or continue the configuration of ‘Microsoft SQL Server 2012 Express LocalDB’.

  7. @John K.
    Have you tryed to launch the “Repair” via Gui in “Installed programs”? Because with windows 2016 it ask me to reboot after the Repair, so probably scripting it will reboot immediately.
    Another thing is that running another Repair after the first Repair, it ask me to close 2 other applications installed, but before the repair there was no problems regarding other applications…

  8. @Manuel Dal Bianco
    I have tried running “Repair” for “Microsoft SQL Server 2012 Express LocalDB” under “Programs and Features.” What’s odd is that repairing that program causes some of my clients’ servers to reboots, whereas it can be repaired on other clients’ servers without rebooting. I agree that the script is probably rebooting the servers as if I had run the “Repair” command (at least for the servers that require a reboot after “Microsoft SQL Server 2012 Express LocalDB” is repaired).
    I have not tried to “Repair” the program a second time. I’ll try that tonight after-hours (so that I can restart the server if necessary.

  9. I did as suggested but that then it fails with “Script finished execution with unexpected exit code: 1”

    Looking at the event log on the VM to be backed up, I can see the process happen and complete so I’m not sure why it thinks the script is failing.

    I have instead resorted to using a scheduled task to run your script two minutes before the backup. This isn’t ideal as it’s something else to change if we ever more our backup window but it will do for now.

  10. Thanks so much for this info, I don’t use Veem but this same issue is occurring with my Macrium Reflect backups and I’ve been trying to fix it for months, reboot allows it to run for a few days. In regards to your script, I know if does more then stop start, but for me I just made a “NET STOP ADSync” and “NET START ADSync” batch file to run before and after the backup.

  11. In case you’re wondering why this happens:
    – ADSync launches an SQL Server Local DB under it’s own user account
    – The User Profile Service thinks ADSync is no longer logged on, and unloads the registry
    – SQL Server though still has handles to the registry, but they’re invalid now

    Detailed explanation:

    In short: Computer Configuration->Administrative Templates->System->User Profiles->Do not forcefully unload the user registry at user logoff

  12. I found that reinstalling the sql express database isn’t needed if:

    Before creating the snapshot you stop the microsoft azure ad sync service (pre-freeze)
    After snapshot is created, start the service again (post-thaw)

    I added the backup service account start & stop rights with this tool:

    Found this tool via this blog:

  13. I believe I have confirmed a solution that I found on other support threads. It appears the issue is resolved by changing the “Log On” account for the “SQL Server VSS Writer” service from “Local System account” to a domain administrator account. It may work for a simple local administrator account, I just haven’t tested it. I made this change on a few servers for different clients, and backups have worked for the past couple of weeks without having to reboot the servers (or run the script, which reboots some of the servers) before backups run.

Leave a Reply