Hey all - this question sort of crosses streams with OSD and SWD, but I figured I’d post it here.
I’m looking to set up a process where after imaging a machine, it’ll automatically install certain software/fixlets, based on what’s configured in the ‘client settings’ on the bare metal profile. Here’s my process, and my questions.
-I created a new bare metal profile, and under client settings, I added HomeOffice (or rather, NAME:HomeOffice – since it required that format). My assumption is that this will add the ‘Client Setting’ value of ‘HomeOffice’ to a machine after applying an image from this profile? Everything seems okay at this point.
-I’m fine with the software deployment portion, building the fixlets to do that etc. When I start an action on the fixlet I want to automatically apply to a computer with that HomeOffice tag, I select ‘Dynamically target by property’, I don’t see a way to drill down and specify the client setting tag. The screenshot on the wiki doesn’t really help, and I’ve dug through all of the options without success.
my questions:
1: Does my process look correct, am I missing anything?
2: How do I target that HomeOffice client setting tag in the action? It does not appear to be an option anywhere, when selecting dynamically target by property
3: Once I have this process ironed out, my goal is to build out a few different profiles with different softwares that automatically install after imaging the workstation using the corresponding bare metal profile with the right client setting tag. My thought to achieve that, would be to open an action with no expiration date and leave it targeting that client setting name. If that seems right, what happens after the machine’s already been configured and deployed and in use for a while? I imagine it retains that tag in it’s profile and would routinely check in with that action? My hope is that after configuration and deployment, we can have those actions stop checking in with the machine, if that makes sense?
The “By Retrieved Properties” part uses the columns you have showing in your console. You can simply make an analysis that pulls this client tag and add the property as a column in your console, and then target machines with that tag through By Retrieved Property.
On a very related note – i’m not a big fan of doing deployments this way.
My preference is to have organizationally-wide, department-wide, group-wide standard software baselines. When a computer comes online it simply gets the standard software for the organization/department and group the same way an existing computer would. If a computer that already is in that group is missing the software it also gets it.
Instead of trying to orchestrate deployment like this I definitely prefer to treat software as a compliance item and enforce standard software at the department and group level.
when expanding out all computers, there’s nothing in that list that resembles client settings, that I could find. I can’t seem to find a way to target it. Is it because I don’t yet have a computer in our environment with one of these client settings defined?
My understanding is that you must first create an analysis that pulls that information.
Once you have an analysis that correctly identifies that property on the clients you can add it as a column in your console and then target from that screen.
it’s interesting that it’s not called out in IBM’s instructions, but that could be the case. That’d be really odd to leave out such an important step. For now / my immediate need, I’m mostly interested in figuring out how to have these deploy right after imaging, and this seems to be the best method for that. Working towards org/dept/group level standards sounds like a better long term plan that I could build towards in the future.
I don’t really have an example machine that has this property, not entirely sure how to have it look for that property just yet. I guess I’ll image a machine with that new profile to see what it generates and try to build an analysis targeting the resulting property. I’d probably want this property being detected fairly quickly, how often is too often, to have an analysis evaluated?
I imaged a test machine with the new bare metal profile that sets the client setting. It shows up in client settings as NAME with the value of HomeOffice.
I haven’t written relevance that looks for details of this area before. I’m setting up the analysis to look for this setting now, how would I write the relevance for it?
Client settings are definitely pulled already (so the Console can display them when you edit the settings) through the property “Client Settings” so you’d have to go into that property section for settings
alright, I have most of this working now. I have it setting the client setting to ‘freshlyimaged’, and then a baseline with a series of changes to configure when it dynamically targets that. at the end of that baseline, I have it change that setting from freshlyimaged to HomeOffice, so it won’t try to re-apply later.
now if I leave the baseline open looking for that tag… no problem. but if I make changes to that baseline (as I will be while I dial this in further), and cancel it out to start a new action on that baseline, I can only target that freshlyimaged client setting if there’s a computer actively in the environment with that tag. is there a clever way to target this regardless of the availability of a computer with that tag, or will I have to tag a machine with that setting until it’s inventoried, start the action and then wipe the tag out (does this make sense?)
Use the relevance tab of the baseline so it’s only relevant on computers with the client setting and then target all computers (this is the scarier option to me)
Create a computer group with the relevance targeting the custom settings and target the computer group (this is what I would do)
The advantage with #2 is that you aren’t reproducing the relevance in every baseline/item you want to target towards new machines.
randomly, while testing something along the same lines, trying to target the custom client setting (I do plan on renaming it for better organization … just don’t want to rewrite things at the moment)… it’s showing up if my target is under select devices like:
I think it’s because you’re using the global “Client Settings” Property - which has, as its values, both the name and the value of every setting on the client. When you are viewing it by “Select Devices”, you’re only seeing the values that are present on clients that have reported Relevant for this fixlet. So breaking it up by ranges allows each value to be shown. When you target Dynamically, you will be filtering on every client setting on every machine - even the non-relevant ones - so there are too many to list individually. Instead they’re listed by ranges.
See how the first one lists "<minimum> -- __something"? That means you can expand it and see all the values between.
But that’s not what you want to do. What you need is to add a Column to your computer view, find “NAME” (which, btw, is a badly-named client setting!), and then that will show up in the target as its own property. So your view would show “By OS”, “By CPU”, “By Last Report Time”, “By Locked”, and “By Name”, along with whatever other columns you’re displaying.
In short, you don’t want a column that shows every client setting - you want a column that shows just the one client setting that you’re trying to target.
thanks for the run down - I’ll review it when I’m back in the office on Monday. that makes a lot more sense now.
I agree, it’s a horrible name for a client setting. the way it was initially generated was from the bare metal server deployment profile, there’s a field there to define a client setting. I tried something else, and the error said something along the lines of it needing to be in NAME:Settingname format, so I followed it exactly for the sake of progressing… lol. I didn’t realize at the time that it would actually carry it over in that format, super easy to fix up later, I understand how those settings are created individually now outside of the GUI tool. I’m learning how it all works right now, I’ll reorganize it shortly :]
You can also trigger on the install time of the OS to automatically have a PC join and leave a custom site (1 day). We have open baselines in this site that applies the software/settings. The sites relevance is:
((value “InstallDate” of key “HKLM\Software\Microsoft\Windows NT\CurrentVersion” of native registry) as string as integer * second + “01 Jan 1970 00:00:00” as local time) > (now - (1 * day))
