I’d like to run this task one time, but only on newly built machines, NOT on machines that already exist. Can someone help?
DOS GPUPDATE /FORCE
Thanks
I’d like to run this task one time, but only on newly built machines, NOT on machines that already exist. Can someone help?
DOS GPUPDATE /FORCE
Thanks
We have a registry key that my company uses to store settings…
HKEY_LOCAL_MACHINE\SOFTWARE\MyCompany
If I had the same need, I would deploy a key to all systems currently being managed then any system that calls in and does not have the key, executes your command.
To set the key…
regset64 "[HKEY_LOCAL_MACHINE\SOFTWARE\MyCompany]" "NewSystem"="False"
Then your relevance would have a couple of statements.
name of operating system starts with "Win"
(if exists property "in proxy agent context" then (not in proxy agent context) else true)
if exists value "NewSystem" of keys "HKEY_LOCAL_MACHINE\SOFTWARE\MyCompany" of x64 registry then value "NewSystem" of keys "HKEY_LOCAL_MACHINE\SOFTWARE\MyCompany" of x64 registry as string else "True" | "True"
Then use your action and make it a policy to end when you want.
Similar we have a Bigfix client setting in our templates.
We target a new build baseline dynamically based on the Client setting,
and add specific relevance to help avoid accidents:
(Below is a clip only, not the full thing)
((exists true whose (if true then ((exists setting "_New_Build" whose (value of it as lowercase = "1" as lowercase ) of client)
and ( uptime of operating system < 1 *day) and
( ((now - it) of unique value of (it * second + "01 Jan 1970 00:00:00" as local time) of (it as string as trimmed string as integer) whose(0 != it) of values "InstallDate" of keys "HKLM\Software\Microsoft\Windows NT\CurrentVersion" of (x64 registries;x32 registries)) < (4*day)```
AND (exists true whose (if true then (uptime of operating system > 30 * minute)
The last task of the baseline performs an update to the _New_Build client setting - making it ‘0’ so it wont run again. We also have an override client setting which will let us tag a system at any time to run, if needed for testing, etc.
The less than 4 days relevance, will prevent us from publishing a an update and potentially picking up a server that had not been updated already and is already in production and we dont want to run a few dozen updates and reboots automagically.
As @mesee2 and @D.Dean already highlighted, when you want to target newly built machines, the first thing you need is a unique identifier that indicates a newly built machine. This could be a client setting (as mentioned) or any other OS build values. You can also use the relevance shared by @mesee2 to fetch the install date. Based on that, you can create a retrieved property, which can then be used to target such devices dynamically as a policy action.
Here are the refined relevances:
//Install Date
Q: (it * second + "01 Jan 1970 00:00:00" as local time) of (it as string as trimmed string as integer) whose(0 != it) of values "InstallDate" of keys "HKLM\Software\Microsoft\Windows NT\CurrentVersion" of (x64 registries;x32 registries)
A: Sat, 25 May 2024 09:40:57 +0530
T: 0.951 ms
I: plural time
//Install Date in Days
Q: ((now - it) of unique value of (it * second + "01 Jan 1970 00:00:00" as local time) of (it as string as trimmed string as integer) whose(0 != it) of values "InstallDate" of keys "HKLM\Software\Microsoft\Windows NT\CurrentVersion" of (x64 registries;x32 registries))
A: 341 days, 01:04:06
T: 0.477 ms
I: singular time interval
Q: ((it / day) of (now - it) of unique value of (it * second + "01 Jan 1970 00:00:00" as local time) of (it as string as trimmed string as integer) whose(0 != it) of values "InstallDate" of keys "HKLM\Software\Microsoft\Windows NT\CurrentVersion" of (x64 registries;x32 registries))
A: 341
T: 0.213 ms
I: singular integer
//If you want to target machines that are recently built and fall under the category of being 5 days old (you can change the number of days as per your need), you can use the following relevance as a retrieved property:
Q: ((it / day) of (now - it) of unique value of (it * second + "01 Jan 1970 00:00:00" as local time) of (it as string as trimmed string as integer) whose(0 != it) of values "InstallDate" of keys "HKLM\Software\Microsoft\Windows NT\CurrentVersion" of (x64 registries;x32 registries)) < (5)
A: False
T: 0.264 ms
I: singular boolean
I admit, as @mesee2 and @vk.khurava stated, using a client setting is a good idea, it will then make your content cross platform, not just Windows.
We have a property labeled Earliest Subscribe Time with relevance ‘minimum of subscribe times of sites’. You could use something like ‘now - minimum of subscribe time of sites < 5*day’.
The challenge with Client settings opposed to the registry or something that is static is that if you have to remove and install the agent then you could cause tasks to run again unless your very specific with the evaluation.
Correct, Removing the agent from “Programs and Featuress” (appwiz.cpl) does not remove client settings. However, if you use besremove, it will wipe them all out.
There are some very critical settings that would cause issues if besremove is used and the settings get wiped. So we make a backup of the critical ones, into that reg key I mentioned.
For example, we have a very robust patch exception process in place, and the patch exceptions (Such as Do Not Patch SharePoint) are set in client settings. If the client is removed with the besremove tool and those settings are wiped, then the client is installed again, it would default to patching everything. This has happened and it did break a customer’s SharePoint site.
To prevent that, we have a task that if the backed up key does not match the client setting, the system is added to a “Patch Exception Discrepancy” computer group and then it is locked.
We have a daily task for some of our team members to check and ensure no systems are listed in that group.
Good points that I dont think everyone is probably aware of. We tend to use besremove as default to remove agents prior to reinstalling but i think its extremely viable to backup and restore those critical settings as you described as long as you are aware to do so.
Use a stub file. When running the task copy/create a file on the local hard drive and use that file not exist as relevance.
copy “\fileserver\RSA\CLIENTUPDATEFILES\done.txt” “C:\Program Files\Common Files\RSA Shared\Auth Data\done.txt”
not exists file “C:\Program Files\Common Files\RSA Shared\Auth Data\done.txt”