Event ID 63 occurs when you run the Microsoft System Information program from Office 2007 or from Office 2003

After you run the Microsoft System Information 7.0 (MSInfo32.exe), if you view the Application log in the Event Viewer, there may be one or more instances of the warning Event ID 63: Note A Windows Management Instrumentation (WMI) provider is a software component that behaves as a mediator between the Common Information Model (CIM) storage component and the managed object. The provider handles data requests for the managed object and sends data from the managed object to the CIM object manager component (CIMOM).

This issue occurs if the following conditions are true:

• You are running 2007 Office system or Microsoft Office 2003 Service Pack 1 (SP1) on a Microsoft Windows XP Service Pack 2 (SP2)-based computer.
• You are logged on to the computer with an account that has elevated permissions, such as the Administrator account.

This Warning event is generated because of the updates that are included in Windows XP SP2. This Warning event is generated when an instance of the OffProv11 provider is started.

We do not recommend that you try to configure the provider to use a more restricted account, because the OffProv11 provider is already configured to use SelfHost. Additionally, the OffProv11 provider must be configured to use the LocalSystem account because the OffProv11 provider is an interactive service.

This behavior is by design.

The WMI provider subsystem runs individual providers in specific COM servers based on their required security level. Only administrators can register providers and configure their required security level, and only trusted providers should be configured to use the LocalSystem account. This Warning event behaves as an audit record to indicate that the provider is running with the permissions of the LocalSystem account.

Some of the WMI changes that are included in Windows XP SP2 are designed to help reduce issues that might occur between different hosting models when these hosting models load providers. Different hosts might include Microsoft Internet Information Services (IIS), a Windows service, or an enterprise service. To start a provider, each host starts a new process that is named WMIPRVSE. The WMIPRVSE process loads the actual provider. When you use different hosting models, the WMIPRVSE process is started by using different Windows credentials. Therefore, the provider that is loaded, such as the OffProv11 provider, tries to load Mngcli.exe to gain access to shared memory by using these different credentials.

WMI security

WMI security is based on namespace security.

The WMI infrastructure maintains a list of users who have access to a specific namespace. You can set this list by using a WMI application or by using script. You can also change namespace security by using the WMI Control component. For additional information about how to set WMI user security or about how to set WMI namespace security, visit the following Microsoft Web sites.

Setting user securitySetting namespace security

DCOM configuration

DCOM security is an authentication and impersonation setting. Authentication means that one process identifies itself to another process. Typically, authentication uses password identification. DCOM authentication levels range from "no authentication" to "per-packet encrypted authentication." Impersonation identifies the authority that a client grants a server to call different processes. During a security verification, the server impersonates the client who requests access to the particular resource. DCOM impersonation levels range from "no identification" to "full delegation."

Shared provider host process

WMI resides in a shared service host with several other services. To avoid stopping all the services when a provider fails, providers are loaded into a separate host process named Wmiprvse.exe. More than one process with this name can be running. Each process can run under a different account with different security.

The shared host can run under one of the following accounts in a Wmiprvse.exe host process:

• LocalSystem
• NetworkService
• LocalService
• LocalSystemHostOrSelfHost

The LocalSystem account

The LocalSystem account is a predefined local account that is used by the service control manager (SCM). This account is not recognized by the security subsystem. It has extensive permissions on the local computer, and acts as the computer on the network. Its security token includes the NT AUTHORITY\SYSTEM security ID (SID) and the BUILTIN\Administrators SID. These accounts have access to most of the operating system objects. The name of the account in all locales is ".\LocalSystem." The name, "LocalSystem" or "ComputerName\LocalSystem" can also be used. This account does not have a password. If you specify the LocalSystem account in a call to the CreateService function, any password information that you provide is ignored.

A service that runs in the context of the LocalSystem account inherits the security context of the SCM. The user SID is created from the SECURITY_LOCAL_SYSTEM_RID value. This account is not associated with any logged-on user account. This behavior has the following security implications:

• The HKEY_CURRENT_USER registry hive is associated with the default user, and not the current user. To access another user's profile, impersonate that user, and then access the HKEY_CURRENT_USER registry hive.
• This service can open the HKEY_LOCAL_MACHINE\SECURITY registry hive.
• This service presents the computer's credentials to remote servers.
• If this service starts a command prompt and runs a batch file, the currently logged-on user could stop this batch file by pressing CTRL+C. The currently logged-on user would then have access to a command prompt that is running under LocalSystem permissions.