locked
SHV dev questions RRS feed

  • Question

  • These questions are all kinda related so I thought I'd put them in one thread to keep things simple.  I'm implement an SHV and have a few questions regarding processing:

     

    1) The default SHV dialog has a section called "Error Code resolution" where you can set desired actions (Compliant/Noncompliant) for several well known conditions.  One of these conditions is "SHA not responding to NAP client".  In the SHV, INapSystemHealthValidationRequest::GetSoHRequest passes the napSystemGenerated parameter which the documentation says is primarily generated because the SHA has failed.  What's the difference between these two cases?  If napSystemGenerated is true can I return an error that will cause fire the "SHA not responding..." action?

     

    2) In general, are the SHV "Error Code resolution" actions something the SHV can influence?  If so, how?

     

    3) The online docs say INapComponentConfig is deprecated yet the SDK still implements it's methods and INapComponentConfig2 apparently inherits from it.  What's the status of INapComponentConfig?

     

    4) Assuming INapComponentConfig isn't dead yet, in my testing I've never see GetConfig/SetConfig called.  What conditions would cause them to be called?

     

    5) Under what conditions should InapComponentConfig2::InvokeUIFromConfigBlob() get called?  Never seen it happen.

     

    Thanks in advance,

    -steve

    Wednesday, January 23, 2008 12:15 AM

Answers

  • Hi Steve,

     

    I will try answer some of your questions:

     

    I will answer both and (1) and (2) together:

    The SHV must communicate the Failure Category to the NAP Server via the Failure-Category TLV in the SoH response.  In the case of the NAP Client generating an SoH on behalf of an SHA due to an SHA failure the napAgentGenerated is set to true, and the Failure-Category TLV is set to clientComponentFailure.  To match the appropriate configuration setting for this case, the SHV must indicate this Failure-Category in the SoH response.  A simple way to do this, is to simply set the SoH request as the SoH response whenever napSystemGenerated = true.

     

    (3) Yes INapComponentConfig2 inherits from INapComponentConfig.  SHVs should implement INapComponentConfig2.

     

    (4) GetConfig/SetConfig are only called when you do a netsh export/import; or when one supports remoting – in which case InvokeUIFromConfigBlob will also get called. 

     

    (5) As stated in (4) above this function will be called when NPS is managed remotely.  You need to have the SHV installed on both the local and remote machine. 

     

    Please let me know if you need any further clarifications

    Friday, February 1, 2008 12:58 AM
  • Hi,

     

    Please make sure that your implementation of INapSystemHealthValidator::Validate method returns S_OK when compliance result code or failure category is set in the SoH Response (if synchronous implementation -- BTW, the recommendation is to return asynchrously using INapServerCallback interface).

     

    Referring to http://msdn2.microsoft.com/en-us/library/aa369694(VS.85).aspx, failureCategoryMapping defaults to server component failure if S_OK is not returned for synchronous Validate() method calls.

     

    If any other error code (than S_OK, E_PENDING, RPC_S_SERVER_AVAILABLE) is returned, then the system assumes serverComponent failure has occurred, and the appropriate mapping is done to pass/fail. 

     

    Return code Description

    S_OK: Indicates that the validator has set an SoHResponse on the 'request' object.

    E_PENDING: Indicates that OnComplete() will be called on a separate thread.

    RPC_S_SERVER_UNAVAILABLE: Indicates that the SHV process terminated without the NapServer actually releasing a reference to it. The NapServer will try to re-create a new reference to the SHV and if re-execute the Validate call just once. If the creation of the object or the re-executed Validate fails, the SHV is removed from the list of loaded SHVs. The only way this SHV can now be reloaded is to unregister and reregister the SHV again, or when the NapServer restarts.

    Friday, March 14, 2008 11:32 PM

All replies

  • Hi Steve,

     

    I will try answer some of your questions:

     

    I will answer both and (1) and (2) together:

    The SHV must communicate the Failure Category to the NAP Server via the Failure-Category TLV in the SoH response.  In the case of the NAP Client generating an SoH on behalf of an SHA due to an SHA failure the napAgentGenerated is set to true, and the Failure-Category TLV is set to clientComponentFailure.  To match the appropriate configuration setting for this case, the SHV must indicate this Failure-Category in the SoH response.  A simple way to do this, is to simply set the SoH request as the SoH response whenever napSystemGenerated = true.

     

    (3) Yes INapComponentConfig2 inherits from INapComponentConfig.  SHVs should implement INapComponentConfig2.

     

    (4) GetConfig/SetConfig are only called when you do a netsh export/import; or when one supports remoting – in which case InvokeUIFromConfigBlob will also get called. 

     

    (5) As stated in (4) above this function will be called when NPS is managed remotely.  You need to have the SHV installed on both the local and remote machine. 

     

    Please let me know if you need any further clarifications

    Friday, February 1, 2008 12:58 AM
  • I've finally gotten around to testing my Failure Category code and it's not working as expected.  In my SHV, I have the following code to deal with the inability to communicate with my external server:

     

    HRESULT CBasicShv::FillResponseSoH(HRESULT validationResult, INapSoHConstructor* &pSohResponse) throw()

    {

        HRESULT hr = S_OK;

        SoHAttributeValue value = {0};

        if (validationResult == QUAR_E_NO_SERVER_COMM) {

            value.uint8Val = failureCategoryServerCommunication;

            hr = pSohResponse->AppendAttribute(sohAttributeTypeFailureCategory, &value);

        }

        else {

            return compliance TLV...

        }

    }

     

    What I see happening is this TLV gets returned to my SHA but the failure category mappings set in the SHV properties dialog don't seem to have any effect.  I was assuming the NAP server would see the Failure Category TLV then check the appropriate SHV properties setting.

     

    What am I missing here?

    Monday, March 3, 2008 11:38 PM
  • Hi,

     

    Please make sure that your implementation of INapSystemHealthValidator::Validate method returns S_OK when compliance result code or failure category is set in the SoH Response (if synchronous implementation -- BTW, the recommendation is to return asynchrously using INapServerCallback interface).

     

    Referring to http://msdn2.microsoft.com/en-us/library/aa369694(VS.85).aspx, failureCategoryMapping defaults to server component failure if S_OK is not returned for synchronous Validate() method calls.

     

    If any other error code (than S_OK, E_PENDING, RPC_S_SERVER_AVAILABLE) is returned, then the system assumes serverComponent failure has occurred, and the appropriate mapping is done to pass/fail. 

     

    Return code Description

    S_OK: Indicates that the validator has set an SoHResponse on the 'request' object.

    E_PENDING: Indicates that OnComplete() will be called on a separate thread.

    RPC_S_SERVER_UNAVAILABLE: Indicates that the SHV process terminated without the NapServer actually releasing a reference to it. The NapServer will try to re-create a new reference to the SHV and if re-execute the Validate call just once. If the creation of the object or the re-executed Validate fails, the SHV is removed from the list of loaded SHVs. The only way this SHV can now be reloaded is to unregister and reregister the SHV again, or when the NapServer restarts.

    Friday, March 14, 2008 11:32 PM