I've been struggling to come up with a simple/effective way to perform this task and was hoping for some suggestions. Basically we have a bunch of clients with a particular application installed called Galileo. Within the folder C:\FP\machine\dat32com.ini on each client PC there is a line of text containing the client's Galileo ID (a license) and I need to collect and report on that ID monthly (single report for multiple PCs).
I thought it would be relatively easy and set up a log parser that monitors the ini file and searches for "%Identifier=$GalileoClientIdentifier$" and exports the ID out to $GalileoClientIdentifier$. This worked nicely the first time around and I found the ID reported under Agent Logs - Log Monitoring. I was then able to easily report on the ID by simply including the Log Monitoring log in a monthly scheduled report.
Problem is, after 31 days (I believe the default for maintaining log entries) all the data was lost and it appears the log parser was no longer working. I tested with a new PC/install and the parser worked fine first time around but then not again. Further investigation and I believe it is because the .ini file isn't changing, hence the Log Monitor doesn't believe it needs checking again. I played about with daily re-arm under the log parser settings, but nothing helped.
I looked at simple Get File/Get Variable options, but a bit lost there on how to only extract the particular line from the ini file (ID obviously varies) and then report on it effectively. The only other option would be to somehow get this re-arm working correctly so that it collects the data more than once - not sure how this can be achieved.
Any suggestions or thoughts appreciated.
Wow.... over kill, no need to upload a vbscript, or do reinvent the wheel here...
Do this in your script:
Execute shell command, as system:
for /f "tokens=2 delims==" %a in ('findstr "Client Identifier=" "C:\Path\to\your\file.ini"') do echo %a >> #vAgentConfiguration.agentTempDir#\tempout.txt
Then add another step and use Get variable, File content:
assign it the name of "clientidentifier" (without the quotes)
There you go. Anywhere else in your script after that you can use #clientidentifier# variable which will be whatever is after the = sign in, for example, "Client Identifier=g0ka4005"
So, #clientidentifier# would be "g0ka4005"
Now you can update a custom field, or do whatever you want with it.
Log Parser isn't going to work as once it checks a "New Line" it moves down to the next line for monitoring. It will not start at the top again for the file.
As for the get variable / get file I'd say that's the way to go, but it sounds like you need some additional info to make it work.
Are you looking to just report how many Log Id's are installed? or do you need to report back the PC's with each ID?
Sounds like you need to use a script. Google ‘iniedit’. Sed would probably work, too, but there’s a learning curve.
Thanks guys. I need to report the ID matched to PC - a list of all PC names and their respective ID in one report. I'll check out the suggestions thanks Ken - just worried about ease of reporting then.
Didn't realise the log parser moves down a line - makes perfect sense why it doesn't work now. Pity, as it was fairly easy to setup and then nice to schedule a report on. I was hoping there was a relatively simple way to 'reset' the parser count/check if that makes sense, or is this data held somewhere within the DB rather than a client file that could be deleted via script?
what about a simple vb script / auto IT script to parse the file - run it once a month extract the data and write to the script log - then run the report and it would link the entry to the machine. Or other option is to get info from file and then write it to custom system info field for that machine - then report on that...
Just a thought
That is the problem I guess, my scripting knowledge is pretty bad to be honest and I have no idea how to extract just that particular line from the ini file. Hence why I tried with the built-in Log Parser to try and make things easier.
Kaseya support has in fact suggested using Windows' Log Parser and provided this rough example - issue being that the line can vary from PC to PC (in their example it is on line 24):
c:\temp>logparser "select text into c:\temp\out.txt from C:\temp\dat32com.ini where index = 24" -i:TEXTLINE -o:NAT"
I could then drag this value in using Get File - Content I guess, but still a little stuck on getting the ID when it varies from PC to PC.
it sounds like a script is your best option. post an example of the ini file and see if anyone can assit you. I'll give it a shot as well (my scripting is limited). I'm betting some sort of file read line or trim statements can be used to collect the data you're looking for and send it to a txt file or something to pull from in Kaseya.
yeah pop up a copy of the ini file and the line you are looking for I might be able to bang something together....or somebody will.
Great, thanks again guys. Much appreciated. Below is an example of one of the ini files. The line I need to extract is "Client Identifier=g0ka4005" or even just "g0ka4005" would be better. The index line can vary depending on the client config, so it can't be extracted from the same line index in the script. The other thing I just noticed is that the ID is referenced twice in the ini file, which could make things a little tricky just to extract one? The file is called dat32com.ini and sits in C:\FP\Machine:
[Connections]count=2Name1=MyConnectionName2=DefaultConnection[MyConnection]type=HCMSupportsSpecialCharacters=1Client Identifier=g0ka4005ConfigServerName=localhostIPCName=PrimaryIPCS=127.0.0.1SecondaryIPCS=127.0.0.1DerivedFrom=Use DNS=0UsesSpecialCharacters=0TerminalCharacterMapOut=TerminalCharacterMapOutHCM.txtTerminalCharacterMapIn=TerminalCharacterMapInHCM.txtStructuredCharacterMapOut=StructuredCharacterMapOutHCM.txtStructuredCharacterMapIn=StructuredCharacterMapInHCM.txtForceDownload=1[DefaultConnection]type=HCMSupportsSpecialCharacters=1Client Identifier=g0ka4005ConfigServerName=localhostIPCName=PrimaryIPCS=127.0.0.1SecondaryIPCS=127.0.0.1DerivedFrom=MyConnectionUse DNS=0UsesSpecialCharacters=0TerminalCharacterMapOut=TerminalCharacterMapOutHCM.txtTerminalCharacterMapIn=TerminalCharacterMapInHCM.txtStructuredCharacterMapOut=StructuredCharacterMapOutHCM.txtStructuredCharacterMapIn=StructuredCharacterMapInHCM.txtForceDownload=0[RunTest]TestKey=[Tracking]EntryPending=0
Here's the beginning of it, may need some tweeking
Const ForReading = 1Set objRegEx = CreateObject("VBScript.RegExp")objRegEx.Pattern = "Client Identifier="Set objFSO = CreateObject("Scripting.FileSystemObject")Set objFile = objFSO.OpenTextFile("C:\Test.ini", ForReading)Set WshShell = WScript.CreateObject("WScript.Shell")
Do Until objFile.AtEndOfStream strSearchString = objFile.ReadLine Set colMatches = objRegEx.Execute(strSearchString) If colMatches.Count > 0 Then For Each strMatch in colMatches WshShell.RegWrite "HKEY_Local_MACHINE\Software\KASEYA\Counters\", strSearchString , "REG_DWORD" Next End IfLoopobjFile.Close
this should create the above key, and spit your "Client Identifier=g0ka4005" into it. From there you can parse the reg key with kaseya when ever you need to pull a report. If you want it in a txt file let me know and I'll adjust.
so copy the above to a notpad, rename to .vbs, set up a script that pushs that to the box, runs it, and then collects the results from the reg key.
Test first please!!!!
oops, the WshShell.RegWrite line should have "REG_DWORD" behind the strSearchString, but this thing cut it off. It should look as such
WshShell.RegWrite "HKEY_Local_MACHINE\Software\KASEYA\Counters\", strSearchString , "REG_DWORD"
Just going to test these now guys. Thanks again. I'll report back findings. A quick test of the vbs (edited to fix up reg path and actual file location) errors out with 'Invalid root in registry'. Dan's solution appears nice and flexible and about to try that now. Once again, thanks for the time and suggestions here!
yea, I think my reg keys were off at first, I fixed the post.
I never thought to run the search from dos command. Most of my Kscript are vbs b/c of all the issues we had in upgrading to K2 with pushing scripts. Nice shell command
Now that is awesome and neat thanks Dan! Worked a treat. I just tested an execution. It collected the ID perfectly and I then created a custom System Info field (didn't know you could do that - handy!) and dumped the value #GalileoClientID# created in the script in there as suggested.
Thanks once again all. I'm very impressed with the help and willingness to assist others. All of your suggestions gave me a little more insight and it was nicely concluded with Dan's great script :)
finally figured out this FOR command - Findstr is not present on Windows 2003 servers.. boo hoo.
But should be able to get elsewhere