Re: Backup Restore The WMI repository
Dafna Lohan
In all cases, the WMI service automatically starts when the first management application or script requests connection to a WMI namespace. For more information, see Starting and Stopping the WMI Service.
WMI is a core component of the Windows operating system that allows developers and IT administrators to write scripts and applications to automate certain tasks. Winmgmt.exe is the service that allows WMI to run on your local computer. For more information on using WMI, see Using WMI. If you have received an error message regarding winmgmt.exe, see WMI Troubleshooting. For more information on Winmgmt.exe, see Using WMI Management Tools.
Causes WMI to back up the repository to the specified file name. The filename argument should contain the full path to the file location. This process requires a write lock on the repository so that write operations to the repository are suspended until the backup process is completed.
Manually restores the WMI repository from the specified backup file. The filename argument should contain the full path to the backup file location. To perform the restore operation, WMI saves the existing repository to write back if the operation fails. Then the repository is restored from the backup file that is specified in the filename argument. If exclusive access to the repository cannot be achieved, existing clients are disconnected from WMI.
Moves the Winmgmt service to a standalone Svchost process that has a fixed DCOM endpoint. The default endpoint is "ncacn_ip_tcp.0.24158". However, the endpoint may be changed by running Dcomcnfg.exe. For more information about setting up a fixed port for WMI, see Setting Up a Fixed Port for WMI.
The level argument is the authentication level for the Svchost process. WMI normally runs as part of a shared service host and you cannot increase the authentication level for WMI alone. If level is not specified, the default is 4 (RPC_C_AUTHN_LEVEL_PKT or WbemAuthenticationLevelPkt).
Performs a consistency check on the WMI repository. When you add the /verifyrepository switch without the argument, then the live repository currently used by WMI is verified. When you specify the path argument, you can verify any saved copy of the repository. In this case, the path argument should contain the full path to the saved repository copy. The saved repository should be a copy of the entire repository folder. For more information about errors returned by this command, see the Remarks section.
Performs a consistency check on the WMI repository, and if an inconsistency is detected, rebuilds the repository. The content of the inconsistent repository is merged into the rebuilt repository, if it can be read. The salvage operation always works with the repository that the WMI service is currently using. For more information about errors returned by this command, see the Remarks section.
The repository is reset to the initial state when the operating system is first installed. MOF files that contain the #pragma autorecover preprocessor statement are restored to the repository.
The WMI repository, also known as the CIM repository, is not just a single file, but a collection of files within the Repository folder that work together as a database. When you use the /backup switch to backup the repository, the resulting backup is a single compressed file.
WMI returns the error ERROR_INTERNAL_DB_CORRUPTION (net helpmsg 1358) if a verification operation indicates that the repository is not in a consistent state. This error can be returned from any command which performs repository verification, such as /verifyrepository or /salvagerepository.
If WMI returns error messages, be aware that they may not indicate problems in the WMI service or in WMI providers. Failures can originate in other parts of the operating system and emerge as errors through WMI. Under any circumstances, do not delete the WMI repository as a first action because deleting the repository can cause damage to the system or to installed applications.
1. one of my app layers had office runtimes installed which addded some folders in C:\Windows\Microsoft.NET\assembly\GAC_MSIL\Microsoft.VisualStudio.Tools.Office.Runtime.Internal, when publishing the image, the visual studio runtime shows as installed but the files from that layer are missing, it always was fine previous publishes..
We had the issue here too. First noticed when Ms Visual Studio 2019 AppLayer not merged/composited correctly, This caused Vda registrations to fail as a missing entry in GAC_MSIL (Microsoft.VisualStudio.Diagnostics.ServiceModelSink) which is referenced in 'C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\machine.config' caused the BrokerAgent to fail. Initially we implemented a workaround to remove from the machine.config.
Does your Layer Export work in 2206? It always tells me there is not enough space 0GB left. I think it is an issue with the appliance because the published machines in 2206 does not work with or without Machine OS Tools. Machine is full of errors and not registering to DDC.
@Bodo. Saw issues with registration too, and ran this to determine GAC_MSIL was the cause --> Citrix Health Assistant - Troubleshoot VDA Registration and Session Launch. @Nick - Never tried that. Just rolled back Build tools, and appliance to 2204. Now a happy man after 40 hrs of troubleshooting multiple builds ?
The build they provided quick testing shows to have resolved both my issues with GAC folder and citrix WMI classes missing. Will do more tests to make sure it didnt break anything else but first look is good.
Do we just need to submit a ticket to get access to the private fix? I'm caught between a rock and a hard place, because I can't restore from backup at the moment, but need to move forward with my next image.
I submitted a ticket with Citrix and asked for the private fix, referencing everything above, and they told me that the WMI issues were fixed with the 2206 build and that I didn't need any private fix. Okay then. Guess it was a good thing I was able to restore my appliance from backup, so I'll hang out on 2204 until the next release.
WMI is a comprehensive and versatile system for monitoring nearly all aspects of a Windows system. However, as it is very complex and based on a complex communications protocol (DCOM), it tends to be more error prone. Here is what you can do if you keep getting errors that indicate problems with the WMI system itself.
This article tries to offer some help for the first two cases, the network problems are discussed in What are the most common errors when monitoring WMI?, section "WMI Connection-Based Errors", and in PRTG WMI error messages, section "WMI Timeout Errors".
The easiest way to get WMI back on track is to restart the system. Very often, this helps to get the monitoring up and running again. As PRTG uses the WMI systems on both sides of a connection, you have these two options:
If you encounter problems with non-existing counters after installing/restarting software products or virtual machines, a restart of the WMI services might help. In the example, we use example service names for problems with Hyper-V virtual machines.
Performance counters can be disabled via the Windows registry. Should this happen after a Windows update or the installation of a software package, search in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services branch for Disable Performance Counters. If you find one or more entries set to "1", set them to "0".
One case where this helped is with the Windows Process sensor, where setting this key in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PerfProc\Performance branch brought sensors in the Down status back online.
All WMI counters are defined in text files, the so-called MOFs. If restarting the respective system did not help, you could try to rebuild the counters by compiling the MOFs anew. This can be done via standard Windows means:
A pretty lengthy procedure can be found in Microsoft's knowledge base: Manually rebuild performance counter library values. Make sure that you read and understand the Important section in the article before you start.
As software that features its own WMI performance counters, PRTG dynamically adds these counters during its setup process to the WMI system. Some of these counters, however, might get lost. So, one possible solution might be to re-install this specific software.
Basically, this option reinstalls everything that is needed for WMI, so you very likely need the installation disks / folders of your Windows version, or a slipstreamed disc, if a service pack has been installed.
If you encounter the error message WMI: Generic failure., the WMI repository might be corrupted, or some other system files are corrupted. Try to restore a previous backup first, if possible, and see if this helps.
7fc3f7cf58