Hello All,
We have Server name and Reboot Detail in text file which is present in below format
Server Name Reboot Detail
ABC, 01/05/2020,13:30"
BCS, 01/05/2020,14:30"
RDC, 01/05/2020,14:30"
I have created Parameter Fixlet to parse the “Server Name and Reboot Detail” but while parsing the Serve and Reboot Detail it is only taking the first value as shown below
Any suggestion/Idea how I can parse all the list of servers with its respective boot time detail .
Thanks in Advance!!
Regards,
Manish Singh
You could attach the listing as a Site File, and have each system parse the file looking for the line starting with its hostname; or a Parameterized Fixlet, where the value is supplied in an HTML TextArea field in the Desciption pane; or a custom Dashboard, again taking the data in a textarea and creating an action on-the-fly from that data.
In fact, there may be a way to leverage the “Location Property Wizard” for this, IIRC one of its options is to create a new client setting based on key/value pairs. It doesn’t have to be a Location setting, amd doesn’t have to be keyed on IP addresses.
Thanks Jason for your prompt response.
Location property wizard would be useful in-case of implementing setting refereed to each computer.
Here our requirement is copy the details in txt file and store in the C:\temp\Reboot.txt on each server and after that place the batch file in same directory to schedule the reboot for particular server.
hence I think your first point would be great help for me, Could you please elaborate more on the topic which you highlighted and also if possible please help me with the reference link through which I can modify my existing script
"You could attach the listing as a Site File, and have each system parse the file looking for the line starting with its hostname; or a Parameterized Fixlet, where the value is supplied in an HTML TextArea field in the Desciption pane; or a custom Dashboard, again taking the data in a textarea and creating an action on-the-fly from that data."
Consider the implications of putting the file in c:\temp, where it’s likely a user could modify the reboot.txt file and cause any kind of unexpected behavior; this is basic security tenet, that you’ll be having the elevated BigFix Client accept untrusted data from the reboot.txt file. That said, here ya go:
1 Like
On second reading, I’d be even more concerned about putting the reboot.bat script in the temp folder, as presumably you’ll be having the BigFix client or some other elevated process execute it.
Suppose a user replaced reboot.bat with a file containing
net localgroup administrators MyUserId /add
When the BigFix client executes the batch, they’ve achieved elevating themselves.
I’d recommend putting both the batch file and the data file somewhere beneath {data folder of client}, as only Administrators can read that directory by default already; otherwise perhaps under {native system folder}, where anyone can Read but only Administrators could modify the file.
1 Like
We have something similar and using the KEY/VALUE pairs (mostly for servers) which is set on each endpoint via the Site Send Files option (small text file). This makes the patching window / reboot options more as self service and in the control of the Application or Server Owners, not the poor guy patching a bunch of machines he/she does not know what they do. The KEY are:
PatchGroup: [TEST / QA / PROD / SENSITIVE]
PatchDay: [Monday / Tues / Web / etc… you get the idea]
PatchStartTime: 24 hour clock time
PatchEndTime: 24 hour clock time
Reboot: TRUE/FALSE
We based all patching (Mac and Linux too) on Patch Tuesday, cause everyone understands that. The 2nd Tuesday of each month is easy to compute in relevance, so PatchGroup is the weeks that follow PATCH TUESDAY
TEST = Wednesday- Tuesday of the week following patch Tuesday
QA = The 2nd Wednesday following patch Tuesday
etc …
So now PatchDay is simply what day of the week does that endpoint fall in. Start and End time are obvious. So then what happens is that another setting called “PatchWindow”=TRUE/FALSE is set based on the information above.
Now we have a BASELINE that runs on servers, but in the ACTION setting it only runs when PatchWindow = TRUE. Lastly the REBOOT fixlet(s) we have in the baseline are only relevant when the client settings REBOOT=TRUE.
Other Fixlets called PatchPre and PatchPost look far a local file on the endpoint (file is only writable by domain/local admin) that if present we execute at the start of the baseline and post at the end.
This can put the options into a more self service mode, that the server or application team can adjust.
1 Like
