# The Console, isn't your friend If you’ve ever worked with Automatic Deployment Rules, at some point an update has failed to download. While you might be familiar with the RuleEngine.log file, did know the “updateID” is the “CI_ID”? If you’ve ever tried to find a software update via CI_ID, you know you’re going to one of two places, and neither of them is the console. ![[Log-ErrorCode404.png]] For those of you who already know what this is and just want the quick answer here you go: ## PowerShell Script ```powershell #Enter the site code here $siteCode = "XYZ" #Enter the CI ID $ciID = "11111111" Get-CimInstance -ClassName SMS_SoftwareUpdate -Namespace "root\SMS\site_$($SiteCode)" -Filter "CI_ID = $($ciID)" | Select-Object LocalizedDisplayName,DateCreated ``` ## SQL Query ```SQL --Where XXXXX is the update ID from the logs with an error SELECT * FROM v_UpdateInfo WHERE CI_ID = 'XXXXXX' --or for more strategic data SELECT dbo.v_UpdateInfo.CI_ID , dbo.v_UpdateInfo.ArticleID , dbo.v_UpdateInfo.Title , dbo.v_UpdateInfo.CI_UniqueID , dbo.v_UpdateInfo.InfoURL FROM v_UpdateInfo WHERE CI_ID = 'XXXXX' ``` ## What’s this error mean? In this scenario, the ADR has failed because it was unable to download content an example error for this might be: ```` Failed to download ContentID 16778383 for UpdateID 16779809. Error code = 404 ```` While this might be a pretty simple error (Can’t download the content, content not found, cause I deleted it) – what’s not clear is the name of the update causing the issue, and trying to determine the name of the update from a series of numbers might be frustrating. ## Getting Update Info with PowerShell If you’ve worked with Configuration Manager for any length of time then you know it’s all WMI at the end of the day. In this case, software updates and their information exist within the Site Namespace, and have a class called “SMS_SoftwareUpdate”. You can actually retrieve all of the updates, and their associated properties by just requesting the objects that are of type SMS_SoftwareUpdate. This is pretty simple to get using the below line. When you do this, make sure you update line with your site code. This is pretty neat as you can get a lot of general information about software updates directly via PowerShell. ```PowerShell Get-CimInstance -ClassName SMS_SoftwareUpdate -Namespace "root\SMS\site_DM6" ``` ![[Example-WMI-Return.png]] If we take a close look you can see the CI_ID field here which of course means you can filter on it as was done in the example at the top of the article, so in this case we could run: ```PowerShell #Enter the site code here $siteCode = "XYZ" #Enter the CI ID $ciID = "16779809" Get-CimInstance -ClassName SMS_SoftwareUpdate -Namespace "root\SMS\site_$($SiteCode)" -Filter "CI_ID = $($ciID)" | Select-Object LocalizedDisplayName,DateCreated ``` With this we get the below output which includes the date the update was created, and the name of the update causing the issue. ![[Getting-Update-PowerShellExample.png]] ## Getting Information with SQL We can also get this information from SQL. Fortunately the SQL information is a little more transparent in my opinion, because CI_ID is the primary key which is used in a lot of locations across the Configuration Manager Database. For this use case it’s the primary key in the view. ```SQL v_UpdateInfo ``` If we run a select * from this view we will find all of the pieces we need for this particular puzzle, and from there we can create the SQL query like we did above to find out the name of the update which was causing this issue. ![[SQL-QueryExample.png]]