HTTP 500 error - MachineID and License not received after Poll

Version 2

    Verified Product Versions

    AppSense Management Center 10.0AppSense Management Center 10.1

    Introduction

    If after Polling in to the server your new endpoint does not get a MachineID or License then it is best to gather CCA logs using our Ivanti Support Toolkit and look for the response. In the case below we see that after the endpoint sends a POST web request to the server it gets a 500 error in return.

     

    Here are an example of some details sent:

    L3 T9592 19241093 [LogData] [POST]: [<machineid>{00000000-0000-0000-0000-000000000000}</machineid>]

    L3 T9592 19241093 [LogData] [POST]: [<groupid>{00000000-0000-0000-0000-000000000000}</groupid>]

    L3 T9592 19241093 [LogData] [POST]: [<netbios>ENDPOINT_HOSTNAME</netbios>]

    L3 T9592 19241093 [LogData] [POST]: [<dns>ENDPOINT_HOSTNAME.domain.local</dns>]

     

    In the logs you see and immediate error after the POST in response:

    L3 T9592 19241093 [WinHttpClient::Navigate] Successfully set HTTP secure protocols

    L3 T9592 19241093 [WinHttpClient::Navigate] Sending request

    L3 T9592 19241109 [WinHttpClient::Navigate] Receiving response

    L3 T9592 19241890 [WinHttpClient::Navigate] status code [500]

    L1 T9592 19241890 [WinHttpClient::Navigate] 500 server Run Time error

     

    Resolving this will require some troubleshooting which information that follows should assist with.

     

    Detail

    The POST web request that is sent to the server is in XML format. This is initially processed by the Deployment Service and so we can tell more about the cause by enabling the DeploymentHandlerWebService logging. To do this navigate to "%ProgramFiles%\AppSense\Management Center\Server\Website\Deployment\Web.config" and backup this file then edit the original in an elevated text editor. Look for the following entry and change the threshold from OFF to ALL:

    <log4net threshold="OFF">

        <appender name="RollingLogFileAppender" type="log4net.Appender.RollingFileAppender">

          <param name="File" value="C:\ProgramData\AppSense\Management_DEFAULT\DeploymentHandlerWebService.log" />

     

    Change to:

    <log4net threshold="ALL">

        <appender name="RollingLogFileAppender" type="log4net.Appender.RollingFileAppender">

          <param name="File" value="C:\ProgramData\AppSense\Management_DEFAULT\DeploymentHandlerWebService.log" />

     

    You will need to Recycle the DeploymentPool within the ApplicationPools in IIS in order to start the logging. Open the IIS Manager > Under the Server name > Application Pools > Highlight "DeploymentPool" > Click "Recycle" on the Action pane. Restart the CCA Service on the endpoint and then open the DeploymentHandlerWebService.log file which will be located as shown in the Web.config (as exampled above). In this case we see that the XML from the endpoint has been received and is being parsed as we see machine details in the log:

    [2017-09-08 15:56:32,117] INFO : [Registration::UpdateDetails]: name Machine Name

    [2017-09-08 15:56:32,117] INFO : [Registration::UpdateDetails]: value ENDPOINT_HOSTNAME

    [2017-09-08 15:56:32,117] INFO : [Registration::UpdateDetails]: Acquiring the row from the dataset for the machine

    [2017-09-08 15:56:32,117] INFO : [Registration::UpdateDetails]: name IP Address

    [2017-09-08 15:56:32,117] INFO : [Registration::UpdateDetails]: value 10.1.2.3

     

    The first part of the XML has been parsed so the whole web request was received and is not structurally corrupt however in the log when the machine key and packages our passed we get an exception:

    [2017-09-08 15:56:32,117] INFO : [Manifest::SetMachinePackages]: [Enter]: Manifest.SetMachinePackages machinekey (1q2w3e4r-5t6y-7u8i-9o8i-7u6y5t4r3e2w)

    ...

    [2017-09-08 15:56:32,132] INFO : [Manifest::ModifyMachinePackages]: [Enter]: Manifest.ModifyMachinePackages machinekey (1q2w3e4r-5t6y-7u8i-9o8i-7u6y5t4r3e2w) packages (DataAccessServices.Schemas.PackagesDataSet)

    [2017-09-08 15:56:32,132] ERROR : Severe exception: Type: System.NullReferenceException

    Message: Object reference not set to an instance of an object.

    StackTrace: at Deployment.Manifest.CreateOrUpdateMachinePackageRow(Guid machineKey, List`1 ccaPackages, PLATFORM requestPlatform, MachinePackagesDataSet machinePackages, GroupPackagesDataSet groupPackages, PackagesDataSet packages)

    at Deployment.Manifest.ModifyMachinePackages(Guid machineKey, Boolean isPendingDeletion, Boolean isDeployingNativeConfigs, PLATFORM requestPlatform, List`1 ccaPackages, PackagesDataSet packages, GroupPackagesDataSet groupPackages, MachinePackagesDataSet machinePackages, Guid groupKey, Boolean isAgentInstallDisabled, IPackageLibraryHelper packageHelperInstance)

     

    In this case the issue is with the Packages information that is being passed to the function which throws a NullReferenceException suggesting that expected data is missing. If we return the CCA logs from the endpoint we can see the Packages information that was added to the XML. The culprit in this case is missing version and targetversion data:

    <patch patchcode='{4B4952BC-2DE9-45C1-B226-20B0368EC9BC}' msiupgradecode='{5295ce97-9e77-4280-9b65-1f4d939df1de}' filename='' version='' targetversion='' midsessioninstallable='false' />

     

    The above patchcode is for PM 8.3 SP1 (8.3.149.0) and the information is pulled from the Install keys in the Registry. As the version and targetversion are missing it suggests that there was some issue when the SP was installed and the installation was corrupt. We can see from a working endpoint that the POST of the patchcode information includes these variables:

    <patch patchcode='{4B4952BC-2DE9-45C1-B226-20B0368EC9BC}' msiupgradecode='{5295ce97-9e77-4280-9b65-1f4d939df1de}' filename='' version='8.3.149.0' targetversion='8.3.107.0' midsessioninstallable='false' />

     

    The structure of the XML between versions of the CCA will differ and the above examples have been from CCA 10.1 however you would see similar comparisons when reviewing other CCA versions. Simply compare the XML shown in the POST between and working and non-working endpoint that possess the same Agent versions and the differences will become apparent.

     

    Solution

    Once you have isolated the problematic Agent installations the final step would be to Repair or Re-install them using the original MSI or MSP. You can take this from a working endpoint, from the Install Media or download from the Support Portal.