During installation of the K2 client, a “Department” field can be placed on the client. This value is then sent from KeyAccess to KeyServer, and can be used in a rule to populate divisions appropriately. This is just one of various ways to help automate placement of computers into divisions. Whenever possible you will want to avoid moving each computer manually – so if none of the other methods of automation can be used, you should consider the Department field as described here.
First a quick overview of other methods:
- The easiest is to map your AD OU structure to Divisions, as described in the Authentication Modules documentation.
- If you don’t want to use your OU structure, you might instead use Filters and Rules in the Computers Window – generally here you would need to have a naming convention in place, or well defined IP ranges.
- If you can’t use name or IP address for placement into divisions, you should consider whether some other value already exists within the registry of your endpoints that would be useful. If it does, you can redirect one of the 10 Custom Fields to gather that data and use it in a rule.
- If data about computers exists in another system (AD, a Helpdesk system, etc), you can potentially pull that data into K2 using the K2 Javascript API. Also see our Sample Scripts. This data can then be used in rules.
When none of the above methods will work, you might want to populate Department values during client installs. If you are deploying the client centrally, and can use a script, the easiest approach is to use commands like the following:
\\share\K2Client-x64.exe -platform 64 -gpo -q -v PROP_HOSTNAME=keyserver.mysite.org -v PROP_SITE=site1
\\share\K2Client.exe -platform 32 -gpo -q -v PROP_HOSTNAME=keyserver.mysite.org -v PROP_SITE=site1
The script runs both the 32 and 64 bit installers from a mapped network share. It specifies the KeyServer address and a “quiet” install. Most importantly the final parameter specifies a department value for this install (site1).
If you are providing a self-serve installer, or your deployment method requires a simple run of an installer without any parameters, you can embed the department into the installer itself. This is by giving k2clientconfig for Windows the parameter “-v PROP_SITE=site1”. Or for the Mac k2clientconfig, the parameter “-i PROP_SITE=site1”.
Or, on Windows, you can rename the installer itself in such a way that the properties will take effect during install. To do this, add an @ symbol just before .exe. Then in between the @ and the . add any parameters you would otherwise pass to the exe, replacing spaces with + signs. For example, to apply the properties as in the above example you would name the 64 bit installer:
K2Client-x64@+-platform+64+-gpo+-v+PROP_HOSTNAME=keyserver.mysite.org+-v+PROP_SITE=site1.exe
There’s one change – the “-q” parameter has been removed. If we imagine a user double-clicking this installer, we don’t want it to silently run without any feedback.
After installing in any of the ways described above, when the client logs in it will send “site1” to the server, and that value will appear in the Department field, in the Asset pane of the computer details.
You can set up a filter/rule to find these computers using the syntax:
(dept=”site1”)
The first time a client logs in, you’ll see the department field, but the rule won’t yet apply (it gets checked before the value has been populated). Then at the second login, it will move to the appropriate division (or you can always click the word “Rule” next to filters to apply the rule to any computers on their first login)
Whenever you are using rules, remember that they are applied in order from top to bottom, and you can change the order. This is not so important if all of the rules are to match a field exactly – in which case a computer can only match one rule. But it becomes more important if your rules are set up to use “string contains” syntax.
In summary, if you have no other properties available to help sort computers, you can specify your own “Department” value during client installation. Despite some initial setup work, this is ultimately still easier than trying to determine what to do with computers one by one.
Subscribe
