événement d'instance de création WMI ne reçoit pas

Question

Je suis inscris pour l'événement de création d'objets pour de surveiller les déploiements « SMS_UpdateGroupAssignment » classe, extrait de code est ci-dessous:

_dhGCreation = SINGLETON (CWMIEventManager)->subscribeToObjectCreation (L"SMS_UpdateGroupAssignment", this); 

void* CWMIEventManager::subscribeToObjectCreation (CComBSTR wmiClass, IWMIEventHandler* eh) 
{ 

IUnsecuredApartment* pUnsecApp = NULL; 
//IWbemUnsecuredApartment* pUnsecApp = NULL; 

HRESULT hres = CoCreateInstance (CLSID_UnsecuredApartment, 
NULL, 
CLSCTX_LOCAL_SERVER, 
IID_IUnsecuredApartment, 
(void**)&pUnsecApp); 

DWORD dwErr = GetLastError(); 

LOG_DEBUG_2("CoCreateInstance done, GetLastError = %d, HRESULT = %d", dwErr, hres); 
CEventSink* pSink = new CCreationEventSink (eh); 
pSink->AddRef(); 
LOG_DEBUG_0("pSink->AddRef"); 

IUnknown* pStubUnk = NULL; 

LOG_DEBUG_1("pUnsecApp = %d", &pUnsecApp); 
pUnsecApp->CreateObjectStub (pSink, &pStubUnk); 
LOG_DEBUG_0("pUnsecApp->CreateObjectStub"); 

IWbemObjectSink* pStubSink = NULL; 
pStubUnk->QueryInterface (IID_IWbemObjectSink, 
(void **) &pStubSink); 
LOG_DEBUG_0("pStubUnk->QueryInterface"); 

/* 
* The ExecNotificationQueryAsync method will call 
* EventSink::Indicate method when an event occurs 
*/ 
CComBSTR query = L" SELECT * FROM __InstanceCreationEvent WITHIN 1 WHERE TargetInstance ISA '"; 
query += wmiClass + "'"; 

CW2A printstr(query); 

     // here smsProv is an instance to root/sms/site_<siteCode> 
hres = smsProv->getWbemSvc()->ExecNotificationQueryAsync (
CComBSTR (L"WQL"), 
query, 
WBEM_FLAG_SEND_STATUS, 
NULL, 
pStubSink); 

/* Check for errors.*/ 
if (FAILED(hres)) 
{ 
pUnsecApp->Release(); 
pStubUnk->Release(); 
pSink->Release(); 
pStubSink->Release(); 
return 0; 
} 

return (void*) pSink; 
} 

Lorsque cette inscription se produit, je reçois l'erreur suivante dans SMSPROV.LOG :

Execute WQL = select * from SMS_UpdateGroupAssignment ~ $$ < 14/02/2017 13: 59: 55,472-330> Exécuter SQL = sélectionner tous SMS_UpdateGroupAssignment.AssignmentID, SMS_UpdateGroupAssignment.LocaleID, SMS _UpdateGroupAssignment.AssignedUpdateGroup, SMS_UpdateGroupAssignment.AssignmentAction, SMS_UpdateGroupAssignment.Description, SMS_UpdateGroupAssignment.AssignmentID, SMS_UpdateGroupAssignment.AssignmentName, SMS_UpdateGroupAssignment.AssignmentType, SMS_UpdateGroupAssignment.Assignment_UniqueID, SMS_UpdateGroupAssignment.ContainsExpiredUpdates, SMS_UpdateGroupAssignment.CreationTime, SMS_UpdateGroupAssignment.DesiredConfigType, SMS_UpdateGroupAssignment.DisableMomAlerts, SMS_UpdateGroupAssignment.DPLocality, SMS_UpdateGroupAssignment. AssignmentEnabled, SMS_UpdateGroupAssignment.EnforcementDeadline, SMS_UpdateGroupAssignment.EvaluationSchedule, SMS_UpdateGroupAssignment.ExpirationTime, SMS_UpdateGroupAssignment.LastModificationTime, SMS_UpdateGroupAssignment.LastModifiedBy, SMS_UpdateGroupAssignment.LimitStateMessageVerbosity, SMS_UpdateGroupAssignment.LocaleID, SMS_UpdateGroupAssignment.LogComplianceToWinEvent ... ~ ~ ~ e: \ nts_sccm_release \ sms \ siteserver \ sdk_provider \ extnprov \ extproviderclassobject.cpp (2190) : ERREUR SUR L'INDICATE - probablement annulée ~ ~ ~ $$ < 02-14-2017 13: 59: 55.667-330> ERREUR ON INDICATE = (WBEM_E_CALL_CANCELLED) ~ $$ < 02-14-2017 13: 59: 55.669-330> Résultats retournés: 170 de -1 ~ $$ < 02-14-2017 13: 59: 55.675-330 >

Quelle pourrait être la raison de cet échec?

Answer 1

ne pas faire d'événements. Je l'ai essayé et SMSProv.log a généré beaucoup d'entrys. Pourquoi? À mon humble avis, l'appel de base de données n'est pas basé sur un événement, de sorte que le récepteur génère une requête de base de données toutes les 15 ms environ. Cela fera la queue et vous devrez peut-être attendre une heure pour que sccm revienne à la normale. Bien sûr, votre connexion à toutes les consoles sera annulée parce que le serveur avait beaucoup de requêtes de base de données à faire.

Une autre idée est, que votre fournisseur w wb est surchargé. J'éprouve cela aussi à temps je ne sais pas exactement pourquoi. scom ont le même problème. Ou peut-être que nos espaces de noms WMI sont brisés ... j'espère que non, ce serait un desaster ....