Overview and Symptoms 

The backup engine uses Microsoft VSS to perform backups of open files and also to backup the system state. VSS consists of providers (which provide volume snapshot functionality), writers (application components that ensure the integrity of their data before a snapshot is taken, such as Exchange or SQL), and requestors (such as backup application).

One of the VSS writers that comes with Windows is the WMI Writer. WMI is an acronym for Windows Management Instrumentation and is part of the operating system. If the WMI system files or the WMI database become corrupted, the WMI VSS writer can fail and prevent open file backups and system state backups from happening. In these cases, errors will be visible in the backup log, windows application or system log, and/or the ntbackup log files such as:

• WMI: Initialization failure
• WMI Writer has reported error 0x800423f3.

Resolution 

WMI is part of the operating system, and as such we do not have direct control over it and are unable to recommend steps for an exact fix. That being said, we have learned from experience certain procedures will resolve the above issue. The steps are in this article are for Windows 2003 or SBS 2003 only. For assistance on other operating systems, please contact Microsoft support.

Note that if you are having trouble with system state backups, please use the software updater to update to version 3.7.3, and then retry the system state backup by right clicking on the Backup Now button on the system status page and choosing Backup System State. If a problem still occurs, and the logs indicate that it was a WMI writer failure, then continue and follow the steps in this article.

Note that the steps below are from this forum thread, and are provided "AS IS" with no warranties of correctness.

Procedure #1: VSS hotfixes 

The first thing to check is to make sure that all VSS hotfixes are installed, especially on Server 2003 or SBS 2003. 

After installing the hotfixes and rebooting, if the issue still occurs try the next procedure.

Procedure #2: Check connectivity to WMI Service and security permissions 

1. Start. Run. wmimgmt.msc
2. Right click on WMI Control (Local) and choose properties.

If WMI is running properly, then you should be able to browse WMI properties, such as the server operating system version and WMI version number. Now that you are connected, you can verify that permissions are setup correctly. In the WMI service browser that you just opened: 

1. Click on the Security tab.
2. Expand Root and highlight Root/MicrosoftExchangeV2. Click the Security
   tab. A sample of "good" permissions is:
   
   Administrators - Full inherited
   Everyone - Inherited
   Execute method - Provider write, Enable account
   Local Service - Inherited
   Execute method - Provider write, Enable account
   Network Service - Inherited
   Execute method - Provider write, Enable account
   
   
3. Expand Root\CIMV2\Applications and highlight Exchange. Click the
   Security tab. Again - a sample of "good" permissions:
   
   Administrators - Full inherited
   Everyone - Inherited
   Execute method - Provider Write, Enable account
   Local Service - Inherited
   Execute method - Provider write, Enable account
   Network Service - Inherited
   Execute method - Provider write, Enable account

If making sure permissions are set correctly doesn't work, or if you can't connect to the WMI service, proceed to the next procedure.

Procedure #3: Check WMI classes and namespaces using WBEMTEST.exe

The purpose of this procedure is to see if the appropriate WMI classes are registered. If any are not registered properly, or you have errors during the below process, try registering them using the next procedure.

1. Start. Run. wbemtest.exe
2. In the WbemtestTester application click the Connect button.
3. In the Namespace field type in: root\cimv2\applications\exchange. Then click the Connect button. 
4. Click the Enum Classes... button. Do not enter a superclass name. Click the Recursive option, and then click OK.

Note that there should be 59 objects (for Exchange 2003 only). Click the Close button when finished.

1. In the WbemtestTester application click Connect again. 
2. In the Namespace field type in: root\microsoftExchangeV2. Then click the Connect button.
3. Click the Enum Classes... button. Do not enter a superclass name. Click the Recursive option, and then click OK.

Note that there should be 74 objects (for Exchange 2003 only). Click the Close button when finished.

Procedure #4: Re-register Exchange WMI DLLs, Namespaces, and Classes

If you get a failure such as an invalid namespace or invalid class error when performing the above procedures, then you will need to recreate the WMI Repository.

1. Stop the WMI service and rename the repository folder (WMI database) by opening a command prompt (start, run, cmd) and entering the following commands one by one: 
   
   cd %windir%\system32\wbem
   if exist "repository.old" rmdir /s/q "repository.old"
   net stop winmgmt /y
   rename "repository" "repository.old"
   net start winmgmt
   
   
2. The above commands will cause WMI to rebuild the repository. After executing the above commands you should wait a few minutes (5 minutes or so) before proceeding, in order to give the rebuild process a chance to complete.
   
   
3. Open another command prompt, and execute the following commands:
   
   cd %windir%\system32\wbem
   mofcomp exwmi.mof
   mofcomp -n:root\cimv2\applications\exchange wbemcons.mof
   mofcomp -n:root\cimv2\applications\exchange smtpcons.mof
   mofcomp exmgmt.mof

If this procedure does not resolve the issue, please proceed to the next one.

Procedure #5: Rebuild the WMI repository 

1. Stop the Windows Management Instrumentation service (use start, run, services.msc).
2. Use Windows explorer to open the %windir%\System32\Wbem\Repository folder.
3. Delete all of the files that are in the %windir%\System32\Wbem\Repository folder.
4. Restart the computer. The files that were deleted are recreated when the computer restarts.

The Windows Management Instrumentation service will start automatically when you restart the computer.

If this procedure does not resolve the issue, please proceed to the next one.

Procedure #6: Further attempts to repair the WMI repository 

This is a last resort attempt to repair the WMI repository:

1. Open a command prompt (start, run, cmd) and run the following commands:
   
   cd %systemroot%\system32
   regsvr32 /n /I userenv.dll
   cd wbem
   mofcomp scersop.mof
   mofcomp rsop.mof
   mofcomp rsop.mfl
   net stop winmgmt /y
   net start winmgmt
   gpupdate /force
   
   
2. Retry the backup and/or system state backup to see if the error still occurs.

Conclusion 

If the above steps do not resolve the issue, please contact Microsoft support for further assistance. The problem is in the WMI component in the operating system and is unable to be fixed by the backup software. Microsoft support will likely suggest to run a repair install of Windows in order to repair all of the corrupt WMI DLL files and the WMI repository.