Is there any way to be able to log the last numbered machine in sequence on a per-client basis through a custom field or managed variable? I am interested in being able to automate the naming convention of new machines so that when we bring on a new workstation (AB-WKS##) that a script can be used to pull from this field and name the machine for us. So, the first time it is run, it will name the machine AB-WKS23 (if ABWKS22 was the last machine provisioned), then it will proceed to AB-WKS24 the next time it is executed. I would want this to be scaleable as well and on a per-client basis just for workstations since those are the ones we are frequently provisioning.
Any thoughts? Or is there something already out there that can accomplish this?
Managed variables won't work - they are "per-machine-group", and there's no API to update them (increment the count). Even if you could update it, you'd need different sequence number ranges per group.
Custom Fields won't work - they are "per-machine", although there is an API to read and update these. You would have to designate one system the "master" and tell the procedure to obtain that system's Agent ID and then query the value and update it, but you run into the control issue noted below. This also involves customizing the procedure to tell it where to get the data from (could be a managed variable) at each org.
An Org Custom Field could work, but this data is only accessible via the API - there's no Agent Procedure method to read much less write this data. The challenge with this approach is even if you had an app to read and update the Org Custom Field, there would be no way to control this process, and two (or potentially more) systems could retrieve the same value, resulting in duplicate computer names. You'd need a method for controlling access or guarantee that only one system at a time could possibly request this data.
The only sure-way to accomplish something like this would be with something like an Access database on a central system at each client, which could arbitrate multiple concurrent requests, or at least support Request-Lock-Read-Update-Unlock sequences. Unless the entire application were self-contained and simply invoked via agent procedure, the tool would need to be able to pass the data back to the procedure to perform the agent naming process. The other part of this is how the overall name format looks - do you define this as a managed variable? Where does the number go - is it in the beginning, middle, or end? Do you use a macro to identify where the number is placed? The application needs to accommodate this for the needs of multiple clients.
You would also likely want to be able to reference the value as a number so it could be incremented, but then process it as a string, and likely with front-padded zeros. This isn't something that's easy with Agent-Procedures.
One possible method would be to define the number when the agent first checks in. These alerts ARE sequential events, which eliminate the access-control issue. Something like our ITP (which provides the centralized control) could run a custom process module for New Agent Check-in and set a value into a temporary custom field by reading and updating a per-org central value. ITP already runs a custom Agent Init procedure whenever a new agents check in. The Agent Init process could check that field and, if defined, run the Agent Rename procedure that used the custom field data to rename the agent. Once the agent was renamed, the temp data in the custom field would be cleared. If the customer didn't have the Agent ID Count field defined, it wouldn't rename it. This would leverage the Org Custom field for the count and support the ability to define the agent name format, per-customer or even per customer machine-group using Managed Variables. Two Org custom fields, a small mod to the Agent Rename procedure, and a custom ITP module (customers get 3 modules/year at no cost) would get this done.
One way to go about it would be to use the "fixed name" option for your workstation deployments, with a custom "fixed name" for each client when you build the package. The first machine would check-in to kaseya with agent name i.e. AB-WKS, the second machine would check in as AB-WKS-1, and so on. This would handle the automatic incrementation of names.
Later on, make then run a kaseya procedure that rename's the computer to the same name as the agent name. (for domain joined machines use netdom)
Make use of the built-in vars in Kaseya
#vMachine.ComputerName# = Computer Name ( I suppose you could also use %computername% instead)
#vMachine.machName# = "Everything to the left of the left most decimal point is the machine name" (also fixed name from the agent package)
You'd run this k-proc on the computer that you wanted to rename. You would also need to deploy the executeable netdom.exe prior to these steps. You can get netdom.exe from the "Remote Server Administration Tools" (free download from MS aka RSAT)
Basically download the RSAT tools, install/extract to your tech machine, and upload netdom.exe and netdom.exe.mui to your Kserver VSA shared files. Then in the Kaseya Procedure;
step 1 WriteFile VSASharedFiles\RSAT\netdom.exe to #vAgentConfiguration.agentTempDir#\netdom.exe (writes file to agent temp dir)
step 2 WriteFile VSASharedFiles\RSAT\netdome.exe.mui to #vAgentConfiguration.agentTempDir#\netdom.exe.mui (writes file to agent temp dir)
---Determine if OS is 32 or 64 bit----
step 3 IF HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\CentralProcessor\0\Identifier Contains "64"
step 4 ExecuteShellCommand copy /Y "#vAgentConfiguration.agentTempDir#\netdom.exe" "%windir%\SysWOW64\netdom.exe"
step 5 ExecuteShellCommand copy /Y "#vAgentConfiguration.agentTempDir#\netdom.exe.mui" "%windir%\SysWOW64\en-us\netdom.exe.mui"
ELSE (implies 32 bit)
step 6 ExecuteShellCommand copy /Y "#vAgentConfiguration.agentTempDir#\netdom.exe" "%windir%\System32\netdom.exe"
step 7 ExecuteShellCommand copy /Y "#vAgentConfiguration.agentTempDir#\netdom.exe.mui" "%windir%\System32\en-us\netdom.exe.mui"
step 8 Use Credential (where the K-agent creds are a domain admin)step 9 ExecuteShellCommand (as user) netdom renamecomputer #vMachine.ComputerName# /newname:#vMachine.machName# /force /reboot
It might also be a good idea to check the network and AD that the name does not alread exist on the network before attempting the rename.
(fyi netdom will also rename the computer account in AD)
I've done similair procedures for renaming computers, but I've never used the the var #vMachine.machName# for this purpose, but it should work.