Dell Warranty Reporting via ConfigMgr - Dell Warranty API

Update 11/3 – Contact info for Dell API key has changed: (Info directly from Dell API Support team)
New process - The customer should create ticket via TechDirect
https://techdirect.dell.com;
Alternatively they can reach out to us at
APIs_TechDirect@Dell.com

Update 10/20  - Nickolaj posted his Dell Right Click tool, so if you’ve take then time to get the Dell API, you should add his tool for individual lookups in the Console.

Update 8/18 – Finally received our Production Key.  In the Meantime @Geodesicz also modified the script to run in either Sandbox or Production mode.  It will try if the Key can be used on Dells production API environment, and move forward if it can, otherwise, if errors, then falls back to the SandBox API. – I’ve pasted the updated Script in below and updated the latest version in the download.

Update 7/15 - Working with Dell, found we were using the older API, needed to be using v4 instead of v2 API.  Currently rewriting entire Script to use new API calls.  Will update this Post once the new script is done and tested with the updated API URL.  Will provided updates scripts and Reports once complete.

Update 7/11 - Modified Script to use the Actual Dell API URL instead of their SandBox URL. (Updated Text below & Download Zip File)

 

Recently I attended MNSCUG meeting where Jason Sandys presented on ConfigMgr database.  He showed his OSD Info Script that would write information to WMI so that you could then capture it with the hardware inventory to report back on additional information.  That got me thinking about what else I'd like to have in WMI to report on... Dell Warranty Info!

Started looking for a Dell Warranty Script to get me started, found one HERE. Used that to sparks some other ideas.  Contacted Dell to get the Dell Warranty API access process started. – https://techdirect.dell.com – Create a ticket, or alternatively, contact APIs_TechDirect@Dell.com.
Once you’ve contacted Dell to get the conversation started, you'll have to fill out some questionnaire, etc., but eventually, you'll get your access and own personal API Key.

I worked with my friend @Geodesicz (Mark) who is a PowerShell wizard, and he was able to build me the script I wanted.  Pulls Dell Warranty Info from Dell's warranty API and places that info into WMI on the workstation.  We are using a new namespace called ITLocal, which was already on the machines since we had implemented Jason Sandys OSDInfo Script the week before and decided to use that namespace for consistency.

Download Our Script HERE - Code shown below:

<#
Write Dell Warranty Information to WMI V2.2
Queries Dell Web Service API V4 for Warranty Info
Creates Custom WMI Namespace and Class
Writes Warranty Info to WMI
Requires PowerShell V5
---------------
You can also add this custom class to be collected by Configuration Manager hardware inventory
---------------
Script written by Mark Godfrey (http://www.tekuits.com/blog) and Gary Blok (http://garytown.com/) - MN.IT
#>

[CmdletBinding()]
Param(
    [Parameter(Mandatory=$true,Position=1,HelpMessage="APIKey")]
    [ValidateNotNullOrEmpty()]
    [string]$APIkey
)

# Get Service Tag of Local Machine
$ServiceTag = Get-WmiObject -Class Win32_Bios | select -ExpandProperty SerialNumber
      
# Query Web Service API
Try
{
    $URL1 = "https://api.dell.com/support/assetinfo/v4/getassetwarranty/$ServiceTag"
    $URL2 = "?apikey=$apikey"
    $URL = $URL1 + $URL2
    $Request = Invoke-RestMethod -URI $URL -Method GET
}
Catch [System.Exception]
{
    Write-Output "Production API URL failed, switching to sandbox API"
    $URL1 = "https://sandbox.api.dell.com/support/assetinfo/v4/getassetwarranty/$ServiceTag"
    $URL2 = "?apikey=$apikey"
    $URL = $URL1 + $URL2
    $Request = Invoke-RestMethod -URI $URL -Method GET
}
$Warranties = $Request.AssetWarrantyResponse.assetentitlementdata | where ServiceLevelDescription -NE 'Dell Digitial Delivery'
$AssetDetails = $Request.AssetWarrantyResponse.assetheaderdata

# Set Vars for WMI Info
$Namespace = 'ITLocal'
$Class = 'Warranty_Info'

# Does Namespace Already Exist?
Write-Verbose "Getting WMI namespace $Namespace"
$NSfilter = "Name = '$Namespace'"
$NSExist = Get-WmiObject -Namespace root -Class __namespace -Filter $NSfilter
# Namespace Does Not Exist
If($NSExist -eq $null){
    Write-Verbose "$Namespace namespace does not exist. Creating new namespace . . ."
    # Create Namespace
       $rootNamespace = [wmiclass]'root:__namespace'
    $NewNamespace = $rootNamespace.CreateInstance()
    $NewNamespace.Name = $Namespace
    $NewNamespace.Put()
    }

# Does Class Already Exist?
Write-Verbose "Getting $Class Class"
$ClassExist = Get-CimClass -Namespace root/$Namespace -ClassName $Class -ErrorAction SilentlyContinue
# Class Does Not Exist
If($ClassExist -eq $null){
    Write-Verbose "$Class class does not exist. Creating new class . . ."
    # Create Class
    $NewClass = New-Object System.Management.ManagementClass("root\$namespace", [string]::Empty, $null)
    $NewClass.name = $Class
    $NewClass.Qualifiers.Add("Static",$true)
    $NewClass.Qualifiers.Add("Description","Warranty_Info is a custom WMI Class created by Gary Blok(@gwblok) and Mark Godfrey(@geodesicz) to store Dell warranty information from Dell's Warranty API.")
    $NewClass.Properties.Add("ComputerName",[System.Management.CimType]::String, $false)
    $NewClass.Properties.Add("Model",[System.Management.CimType]::String, $false)
    $NewClass.Properties.Add("ServiceTag",[System.Management.CimType]::String, $false)
    $NewClass.Properties.Add("ServiceLevelDescription",[System.Management.CimType]::String, $false)
    $NewClass.Properties.Add("ServiceProvider",[System.Management.CimType]::String, $false)
    $NewClass.Properties.Add("StartDate",[System.Management.CimType]::String, $false)
    $NewClass.Properties.Add("EndDate",[System.Management.CimType]::String, $false)
    $NewClass.Properties.Add("ItemNumber",[System.Management.CimType]::String, $false)
    $NewClass.Properties["ItemNumber"].Qualifiers.Add("Key",$true)
    $NewClass.Put()
    }

# Write Class Attributes
$Warranties | ForEach{
    $wmipath = 'root\'+$Namespace+':'+$class
    $WMIInstance = ([wmiclass]$wmipath).CreateInstance()
    $WMIInstance.ComputerName = $env:COMPUTERNAME
    $WMIInstance.Model = "Dell " + ($AssetDetails.MachineDescription)
    $WMIInstance.ServiceTag = $AssetDetails.ServiceTag
    $WMIInstance.ServiceLevelDescription = $PSItem.ServiceLevelDescription
    $WMIInstance.ServiceProvider = $PSItem.ServiceProvider
    $WMIInstance.StartDate = ($PSItem.StartDate).Replace("T00:00:00","")
    $WMIInstance.EndDate = ($PSItem.EndDate).Replace("T23:59:59","")
    $WMIInstance.ItemNumber = $PSItem.ItemNumber
    $WMIInstance.Put()
    Clear-Variable -Name WMIInstance
    }

Syntax: WriteDellWarranty2WMI.ps1 -APIKey Y0UR@P1K3Y  (Get your APIKey from Dell)
image

Make a Package & Program and push it out to your dell Computers. (remember to have Windows Manage Framework 5 already installed on your workstations).

image

We also added this to OSD, like so:
image

 

Here is a capture of the info in WMI after the Script has been run: (Using Coretech WMI Browser)
image

Once in WMI, we have to add this to our Hardware Inventory:

Go into the Default Client Settings, Hardware Inventory -> Set Classes -> Add... -> Connect to WMI namespace root\ITLOCAL
image

Once Connected, you should see the Warranty_Info

image

After you check the box, and click OK, it should show up in your classes list:
image

I unchecked everything here, because I only want to apply this to my Dell Workstations.
I opened our Dell Client Workstation Settings (We have one that applies only to Dell Workstations, which I borrowed the idea from Mike Terrill after reading this Post about inventory bios settings.

image

Ok, now wait for your Hardware Inventory cycles to run and the data to populate in your ConfigMgr DB.

Ok, Building reports... Fun with SQL Report Builder!
Mark & I have created two quick and easy reports for now, just as proof of concept, but will probably find ways to pull this data into other reports as well.

  1. Dell Warranty Expired Report - This report shows all of the Computers in ConfigMgr that have expired Warranties:
    image
    You can click on the + next to the computer name to expand if has more than 1 warranty associated with it.
  2. Dell Warranty Expires between dates - This report will let you pick dates and show you the computers that will expire. (If computer has more than 1 warranty, it will only use the warranty with the latest end date)
    image
  3. Dell Warranty Info for specific Computer: Super simple report that lets you put in a computer name and get the info:
    image

 

We created a new folder called Hardware - Warranty, created our reports there.  I've added those 3 reports to the ZIP file you can download with the Script.

Just import them into your system, as long as you kept the namespace the same as the one in our script, it should work fine.  Update your Data source in each report, and you should be set.

In the 2 reports, I have it so if you click on the computer name, it links to a hardware report with more info about that specific computer.  I think it's a built in ConfigMgr report, so it should still work, if not, just delete that action:
image

 

I really hope I didn't miss anything, there was a lot of parts to this.  Mark will also be blogging this, since it was a joint project.  He'll probably have more info about the Powershell stuff itself.

Couple of things to remember... ConfigMgr DB is NOT the same as a Configuration Management Database.  When you delete the computer from ConfigMgr, there goes the data along with it.  I make sure to tell our management, this data is ONLY useful for computers currently active in our system, we do NOT keep historical data.

As always, if you run into any problems, please feel free to contact me, I'll update the Blog to correct anything found.  Sometimes its hard to get the proper screen captures after you've already set it up and been using it.

Also, I highly recommend checking out Jason's OSDInfo Script & Mike Terrill's Dell Posts, those might help shed some light on what we've done.

30 thoughts on “Dell Warranty Reporting via ConfigMgr - Dell Warranty API

  • July 18, 2016 at 6:41 am
    Permalink

    Very awesome work that you are doing with the script. Came at the right time for me.

    Keep up the good work.

    Can't wait to see the updated script. I requested my API key today.

    Reply
    • July 20, 2016 at 8:36 am
      Permalink

      As soon as we get the API info from Dell, we'll update our scripts to use our new API key and test, then post. I'll probably have to rebuild the reports as the v4 API is a fair bit different than the v2 API. I'll keep you in the loop Sid.

      Reply
  • July 24, 2016 at 5:55 am
    Permalink

    Great piece of work... Really smart thinking to include it in the SOE/MOE WMI Tattoo settings as well. On the strength of this holistic article I have initiated API requests with Dell (Currently Testing)

    I believe Lenovo and HP offer similar services as well...

    Thank you for taking the time...

    Reply
  • August 29, 2016 at 2:14 am
    Permalink

    Hi, I am excited to see the V4 version appear..Thanks heaps 🙂
    I have applied and been allocated our API key.
    What I am wondering... Is it possible to modify the script to output the warranty info directly?

    As part of our MDT deployment, an automated email is sent advising that it is near finished. As part of the email, it displays the latest AV signature updates, as it's updated as part of the deployment. Plus some other info that the hardware team monitor.

    I was wondering if I could include the script in our deployment to also include the warranty info in the notification email? ANd not so much imbed it into wmi

    Thanks

    Reply
    • August 29, 2016 at 2:40 am
      Permalink

      Actually, I can just run it as is and call the WMI through powerhsell and include it in the email.

      Tried it and it works a treat ...
      Thanks

      Reply
  • August 31, 2016 at 7:16 pm
    Permalink

    Hi, Sorry to be a nuisance. Hope you could assist.?
    I've added the api key into the script to automate it as much as possible.
    I'm trying to run it as part of a MDT 2013 deployment, but for some reason, it fails during the deployment. - Giving out blank outouts. It dows create the "ITLocal" class though.
    If I run it manually during a task sequence pause, it will run fine.
    Is there a trick to getting the script to run either during an MDT deployment, or is it designed to run from the local drive?

    Reply
    • September 1, 2016 at 12:58 am
      Permalink

      Came to the realization that the through MDt and WinPE, it won't have powershell 5 loaded. Hence the reason it won't work. I will need to copy the file locally, the figure out how to run the file during my task sequence and call pwershell from the local C drive.

      Reply
      • September 10, 2016 at 12:29 pm
        Permalink

        Sorry for delay, been off for a few weeks. Why not wait until later in the TS and you're running from the OS? Then you don't need to worry about the limitations of PE. We run this near the end of our TS.

        Reply
  • September 21, 2016 at 12:57 am
    Permalink

    Hi

    Awesome stuff, will it be possible to assist me with getting this working for Lenovo as well as I have been looking throughout the web and there does not seem to be any thing still working

    Reply
    • September 21, 2016 at 10:34 am
      Permalink

      Hey Dean, unfortunately I don't have the means to help with a Lenovo script, we don't have any Lenovo's to test with. I would start by contacting Lenovo Support and asking if they have a warranty API you can connect to. We have HP in our environment, but so far I've been unsuccessful getting any information from HP Enterprise Support about how to get bulk warranty data. It appears there is a company that provides additional ConfigMgr reporting that already has this all figured out though. http://www.enhansoft.com/product/warranty-information-reporting I'd highly recommend going that route, then you have support as well. If this functionality is a value to your company, then it should be an easy sell to get them to go with a product like Enhansoft.

      Reply
  • October 14, 2016 at 12:16 am
    Permalink

    Hello

    Can I use this script to pass a Serial no and get the warranty details only? I don't want to use the ConfigMgr.

    Will really appreciate if you can help.

    Reply
      • October 14, 2016 at 8:11 am
        Permalink

        I have one that functions as a right click tool via ConfigMgr. Are you just wanting something standalone where you can call the script with a parameterized serial number like so? get-dellwarranty.ps1 -serial 4KT7SD2 -APIkey 43245983464354

        I can easily modify it for something like that. Are you wanting to do this one at a time or in bulk?

        Nikolaj Anderson is working on making something like this with a standalone GUI as well, but I believe that will do them one at a time.

        Let me know what you need. I don't mind taking a few minutes to make some changes.

        Reply
        • November 10, 2016 at 3:57 am
          Permalink

          Hi Mark, I'd be very interested in something that works as a standalone script and calls Service Tags in bulk from a CSV (or other) file and can then add that data back into the SCCM database, much like the original and now defunct Dell Warraty Tool used to do. I have to gather data for a secure, isolated network so many of these amazing and useful right-click tools within the console are not much good for me 🙂

          Reply
          • November 10, 2016 at 9:26 am
            Permalink

            Hi Richard,
            I'm not familiar with this tool you reference. Making something to pull from a CSV or something should be pretty easy. The second part is what concerns me. This thing wrote it directly into the ConfigMgr database? Was it a custom table or something? I don't like to write directly to the ConfigMgr database. That's not a best practice. I could write something that exports the name and warranty info into another CSV file. I'm working on another script right now that pulls data and writes it into a SharePoint list which I could possibly merge with this as well to do it that way. That might take a little longer, however, as it is not the highest on my priority list at the moment.

  • October 26, 2016 at 3:53 pm
    Permalink

    First, I just wanna say thanks! We've just received our API Key from Dell, and are trying to pull warranty information down for easy access, and - unfortunately for us - I'm the closest thing here to a 'programmer.' Suffice it to say, we were in over our heads. And, the internet is not exactly brimming with solutions, so this was a bright, shining beacon of hope and salvation.

    I was just curious, though - are there any permissions requirements for this script to successfully write the values to WMI?

    After doing a test, I'm seeing that the Namespace, Class, and Properties are all getting created; however none of the values from the API Request are getting written to the properties.

    I have confirmed that Powershell v5.0 is installed, and the GET returns the data, I'm just not sure why it isn't then written to WMI.

    Anyway, thanks again!

    Reply
    • October 27, 2016 at 12:36 pm
      Permalink

      Thanks Seth, it was nice working with you offline. Using Powershell or the CoreTech WMI Explorer will show the proper results in WMI.

      Reply
  • March 23, 2017 at 12:09 pm
    Permalink

    Hi and thanks for putting this together.

    I have a couple thousand Win 7 machines that I want to pull the warranty info for. Being that it needs at least .NET 4.5 to work, and also WMF 5, I was thinking about making a package to deploy all 3 (.NET, WMF, and the script itself) each with a dependency on the last.

    If I can deploy one package, it will cut down on all of the administrative hoops I'd need to jump through. I'm a bit new to the deployment world so I wanted to see if using a package like this sets off any alarms you can think of. Thanks again for sharing the knowledge.

    Reply
    • March 24, 2017 at 12:24 pm
      Permalink

      I would do each install completely separate, rebooting between each, and probably even waiting a week or so between each one, or however your Change Management processes require. These are fairly large installs, that can impact other things. Definitely reboot after installing each, before moving to the next thing... or move to Windows 10, which has everything built in. 🙂

      Reply
      • March 31, 2017 at 9:42 am
        Permalink

        There's plenty of merit to taking the slower, but more thorough route. My org isn't necessarily known for being fast. On top of that, I can't tell if the deployment actually runs on each machine at different times, or if the reporting back to CM is what makes it look that way.

        Also, I spotted something that I wanted to verify on line 39 of the script:

        $Warranties = $Request.AssetWarrantyResponse.assetentitlementdata | where ServiceLevelDescription -NE 'Dell Digitial Delivery'

        Is the "Digitial" typo intentional?

        Reply
        • March 31, 2017 at 11:22 am
          Permalink

          The "digitial" part is intentional on our end due to a typo on Dell's end.

          Dell has a service called Dell Digital Delivery where you can purchase software with your machine and then later download said software, this also includes certain free applications that may come with it.

          If you run that part without the where filter, it will show you a number of items where the ServiceLevelDescription is "Dell Digitial Delivery". I don't know if this was a typo when creating the API itself, or if it relates to a database or application issue. Either way, the script's filter is based on the string returned from Dell's API query.

          Reply
  • April 18, 2017 at 12:22 pm
    Permalink

    Hi. I was hoping you could elaborate a bit on the steps to create the Package & Program. Does the command line need to include the path to a powershell.exe? example: %SYSTEMROOT%\SysWOW64\WindowsPowerShell\v1.0\PowerShell.exe \\path\to\script\WriteDellWarranty2WMI.ps1 -APIKey [theAPIkey]

    Does the command line need -NonInteractive or -ExecutionPolicy Bypass, or anything else?

    Reply
  • April 20, 2017 at 2:14 pm
    Permalink

    Hi - thoughts on whether a modified version of this could pull system configuration (CPU, RAM, etc) in bulk?

    Reply
    • April 20, 2017 at 2:20 pm
      Permalink

      If you use Report Builder, you can modify or create a new report with any fields you want.

      Reply
  • May 1, 2017 at 12:03 pm
    Permalink

    Hi

    I'm not sure how to update the data source for these reports. In the URL path to the reports, there are 2 data sources shown after the report folders. One looks to be the same as yours shows above (AutoGen__5C6358F2_4BB6_4a1b...) and then there's another one. Should I be using one of these, or should I be selecting something else?

    Reply
  • May 5, 2017 at 1:41 pm
    Permalink

    Hi,
    I seem to be having trouble with this script running in OSD. The SMSTS log seems to indicate an issue with access to our institutions proxy server. Error code that is coming up is:
    Executing command line: Run Powershell script RunPowerShellScript 5/5/2017 12:35:33 PM 3904 (0x0F40)
    Production API URL failed, switching to sandbox API RunPowerShellScript 5/5/2017 12:35:51 PM 3904 (0x0F40)
    Invoke-RestMethod : Error Message RunPowerShellScript 5/5/2017 12:35:51 PM 3904 (0x0F40)
    Network Access Message: The page cannot be displayed RunPowerShellScript 5/5/2017 12:35:51 PM 3904 (0x0F40)
    Technical Information (for Support personnel) RunPowerShellScript 5/5/2017 12:35:51 PM 3904 (0x0F40)
    Error Code: 407 Proxy Authentication Required. Forefront TMG requires RunPowerShellScript 5/5/2017 12:35:51 PM 3904 (0x0F40)
    authorization to fulfill the request. Access to the Web Proxy filter is RunPowerShellScript 5/5/2017 12:35:51 PM 3904 (0x0F40)
    denied. (12209) RunPowerShellScript 5/5/2017 12:35:51 PM 3904 (0x0F40)
    IP Address: ***.**.**.*** RunPowerShellScript 5/5/2017 12:35:51 PM 3904 (0x0F40)
    Date: 5/5/2017 5:35:53 PM [GMT] RunPowerShellScript 5/5/2017 12:35:51 PM 3904 (0x0F40)
    Server: TMGPROXY0.**.***.** RunPowerShellScript 5/5/2017 12:35:51 PM 3904 (0x0F40)
    Source: proxy RunPowerShellScript 5/5/2017 12:35:51 PM 3904 (0x0F40)
    At C:\_SMSTaskSequence\Packages\UA20018D\writedellwarranty2wmi.ps1:37 char:16 RunPowerShellScript 5/5/2017 12:35:51 PM 3904 (0x0F40)
    + $Request = Invoke-RestMethod -URI $URL -Method GET RunPowerShellScript 5/5/2017 12:35:51 PM 3904 (0x0F40)
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ RunPowerShellScript 5/5/2017 12:35:51 PM 3904 (0x0F40)
    + CategoryInfo : InvalidOperation: (System.Net.HttpWebRequest:Htt RunPowerShellScript 5/5/2017 12:35:51 PM 3904 (0x0F40)
    pWebRequest) [Invoke-RestMethod], WebException RunPowerShellScript 5/5/2017 12:35:51 PM 3904 (0x0F40)
    + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShe RunPowerShellScript 5/5/2017 12:35:51 PM 3904 (0x0F40)
    ll.Commands.InvokeRestMethodCommand RunPowerShellScript 5/5/2017 12:35:51 PM 3904 (0x0F40).

    Any help on this issue would be greatly appreciated.

    Reply
    • May 5, 2017 at 3:34 pm
      Permalink

      The script will need direct access to the internet to pull the info. Otherwise you'll have to modify script to incorporate proxy. While im sure that's possible, we've never had to set that up.

      Reply
  • Pingback: Hilfreiche ConfigMgr-Reports aus der Community | clientmgmt.de by André Picker [MVP]

Leave a Reply

Your email address will not be published. Required fields are marked *