/build/static/layout/Breadcrumb_cap_w.png

How to patch only systems that have had a system restore point in the last 24 hours

Had an interesting request come up this week. Someone asked me, 

"I want to patch my workstations, but I'd like to have a System Restore done before hand, and also be able to have patching verify this has been done before hand."

So that got me thinking; well I know we could run a PowerShell command to enable and create a system restore point. 

*NOTE this only works with workstation class OS's. There is a role for Windows Backup you can add for servers. I will add a snippet example doing something similar for that as well. 

enable system restore:
Enable-ComputerRestore -drive "c:\"

Create a restore point:
Checkpoint-Computer -description "My_first_checkpoint" -restorepointtype "Modify_Settings"

Source: http://mcpmag.com/articles/2012/02/21/powershell-windows-restore.aspx

How to run this above command from the K1 using Launch a Program:

NOTE: I found in the description, you can not use spaces

However, I wanted to take that a step further, and setup a Smart Label that includes only systems that have had a system restore point in the last 24 hours. 
To accomplish this, i would need to get a date of the last checkpoint into the K1000 in a date type format so I can use date operators on it. 
For that, I introduce to you the ShellCommandDateReturn custom inventory rule!

To get the last date of the last system restore point created, I run this:
get-computerrestorepoint | format-table @{Label=" "; Expression={$_.ConvertToDateTime($_.CreationTime)}} -HideTableHeaders

This should output something like this:
mPqxnP.png

(If you want to see the whole enchilada, you can run just get-computerrestorepoint to see all the details and verify the output above)

From there, I tried using just the command above in my shellcommanddatereturn rule:

ShellCommandDateReturn(cmd /q /c powershell.exe -command "get-computerrestorepoint | Sort-Object -property CreationTime -descending | Select-Object -first 1 | format-table @{Label=' '; Expression={$_.ConvertToDateTime($_.CreationTime)}} -HideTableHeaders")



And it worked beautifully!
ZMacAd.png

Now I can make a smart label based off of that date:
SScUen.png


BONUS: 
Someone shared this with me a while ago and thought I'd share it here since it helps me immensely when looking for my custom inventory rules under Software:
Create a Software Custom Inventory Label with the following MySQL query:

SELECT ID FROM SOFTWARE
WHERE (SOFTWARE.IS_MANUAL='1')
AND ((SOFTWARE.INVENTORY_RULE != ''))

This will show you all your custom inventory rules. Enjoy!
Posted 9 years ago 4724 views

Comments

  • One thing i found later when i ran through this, i noticed in 6.3 that I also can't run powershell scripts successfully.
    If anyone has an example of one running (any powershell script) in 6.3, let me know - brucegoose03 9 years ago
  • I am on 6.2 and haven't tried your custom inventory rule, but this may work for your CIR:

    ShellCommandDateReturn(cmd /q /c powershell.exe -command "get-computerrestorepoint | Sort-Object -property CreationTime -descending | Select-Object -first 1 | format-table @{Label=' '; Expression={$_.ConvertToDateTime($_.CreationTime)}} -HideTableHeaders")

    Does 6.3 allow offline scripts to run at every checkin? Or are you running the script as an online script? - flip1001 9 years ago
    • That worked! awesome, thanks flip1001 - brucegoose03 9 years ago
  • Before I open a ticket with Dell, I implemented this script (minus the -restorepointtype "Modify_Settings"), and the associated CIR (which doesn't display the correct hour for some reason). The script is only pushed to a small group (12 computers), but it appears that when it runs, KACE is bogged down in shellscript tasks (On the Dashboard, the Tasks in Progress widget shows shellscript being as high as 97). While this is happening, connections drop, and the Device Check-In Rate falls slowly to 0.

    Has anyone else who has used this experienced the same thing? Do you think this is from the PowerShell command, or the ShellCommandDateReturn rule? - ondrar 9 years ago
    • shellscripts are going to be related to running actual scripts; CIR's are an inventory thing. what you could do to verify is in teh OS Selection multi-select box in the CIR, you could just unhighlight all the OS's, effectively disabling it and see if you continue to have this problem. - brucegoose03 9 years ago
      • I was going to delete the CIR to test, but that's a better idea; thanks for that. Why would shell scripts show up in KACE tasks, though? Isn't that running locally on the computer? - ondrar 9 years ago
      • Shell scripts are a specifc type of kace Scripts that you would have ran. When you go to scripts > Choose action > New, you can do either a Online Kscript, Offline Kscript, or Shell Script. you would have had to have ran a Shell Script to see that, and you willl see a Scripts directory in the C:\programdata\dell\kace directory - brucegoose03 9 years ago
      • So do you think it's unrelated to this script? I do have two Online Shell Scripts, but all they do is delete a few files, and this issue began when I turned on the System Restore script/CIR. - ondrar 9 years ago
      • I believe my issue was the online shellscripts, despite the fact that they only had 4 del commands in them. I recreated them as regular kscripts and have not seen a recurrence of what happened the last two days. It must have just been a coincidence that it started at the same time I turned this script on.

        Thanks for the advice, and sorry for muddying up this post with an unrelated problem. - ondrar 9 years ago
      • Not a problem ondrar - brucegoose03 9 years ago
This post is locked
 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ