I am developing a dashboard page for our clients. This page will be purely informational, and provides the ability to send the displayed information, via email, to a technician.
I would like to display the last time that the client successfully communicated with the BES server in that dashboard. Unfortunately I can not find any inspectors that will report the last connect time according to the client.
Can someone provide me an inspector, or perhaps even the relevance needed to parse the log files for this information if that is the only way to accomplish this?
I donât believe we have an inspector for this⌠and I guess you could read it from the log file, but the BigFix Agent canât open the log file for today because it is locked for writingâŚ
I am not 100% sure if this will work, but you might try to look at the modification date of one of the agent temp files:
modification time of file â__resultsâ of folder â__BESData__Globalâ of parent folder of regapp âBESClient.exeâ
(Note that I am not sure if this will update if the agent tries to report and failsâŚ
Currently I have a javascript interval that checks the time of the last refresh against the current time and refreshes (actually mine displays a message forcing them to refresh, but I simplified it). Note: timestamp is the id of a textarea containing <?relevance now ?>.
var ageCheck = window.setInterval(
"refreshNeeded()", 60000); function refreshNeeded()
{ lastRefresh =
new Date(Date.parse(timestamp.innerText)); currentTime =
new Date; timeSinceLastRefresh = currentTime - lastRefresh;
if (timeSinceLastRefresh > 600000)
{ location.href=
'cid:load?page=_dashboard.html';
}
}
This works great, however it doesnât solve the problem of a user logging off and another logging on. Any user specific information is still displayed for the previous user, causing a potential security problem in our environment.
I would like the page to do a cid:load automatically whenever a new user logs in. However I can find no way to do this reliably. The page refreshes when the BESClientUI.exe starts, so my scripts run fine, however it doesnât do a full cid:load so the data is stale. And since the dashboard is not able to run relevance from within javascript, I cannot find a way to determine if the information displayed is the for the current or the previous user.
Is there a way to trigger a cid:load at the start of BESClientUI.exe so that the page AND the data is refreshed when the client UI starts.
Iâm not familiar with the cid:load mechanism and I was unable to google any documentation. I donât quite understand why the data wouldnât refresh if it in fact reloads the page.
Have you tried window.location = â_dashboard.htmlâ ?
I currently use " location.href=âcid:load?page=_dashboard.htmlâ " to reload the page, and it works great. I think the cid:load portion of the url tells the BigFix client that it needs to parse the html file and replace any <?relevance ?> tags with the results of the relevance query contained within them.
The problem isnât with my script, the problem is that when a new user logs in, the page doesnât refresh the data. Itâs obviously reloading the html, because it processes the javascripts again⌠however itâs using cached data.
I may be wrong, but I think that when the BESClient service first runs, it does a cid:load (for lack of a better term) and creates a new html file with the data in it. Then when we open the dashboard, this cached html file is displayed. However this cached file is not updated when the BESClientUI is started, therefore a newly logged on user sees the exact same cached HTML file that the previous user did.
I guess my question is, how can I force the dashboard to refresh the data whenever a new user logs in.
We use a link like this in one of our production client dashboards:
Refresh
As far as I know that refreshes the data sucessfully. I think your situation should basically do the same thing. Are you sure that the data isnât getting refreshed?
I think your misunderstanding me. I apologize for the confusion.
Our page refreshes fine manually. We have a timer that determines how old the data is and prompts to refresh when it is 10+ minutes old.
The data doesnât refresh when a user logs off the workstation and another logs on.
If a user logs on after another user, and they do not refresh the dashboard manually, they see the previous userâs information.
Try it with your dashboard. Put the userâs name in your dashboard somewhere. We use the following line to pull the the domain/username and their local admin status. eg. DOMAIN\username (non-admin)
<?relevance ((sid of current user) as string) &
" " & ((
if (exists current user) then (
if (exists dacl whose (effective access mode
for (name of current user) of it = effective access mode
for
"Administrators" of it) of security descriptor of system folder) then (
" (Admin)")
else (
" (Non-Admin)"))
else (
" (Admin Status Unknown)"))) ?>
Now log on to the machine as a different user, you will see the previous userâs username displayed.
On some of our systems, the previous user is considered sensitive information, and other information that we may make available on our dashboard is as well. (login time, group memberships, home directory path, etc.)
I need a way to have the dashboard refresh once at logon, when the BESClientUI.exe process starts.
Sorry for the delay responding. I am able to reproduce the behavior you describe. I was under the impression that a new BESClientUI session is initiated for each logged in user, which presumably should mean that the UI would reload the dashboard when a new user logs in. Perhaps itâs a bug or perhaps my understanding of the behavior is incorrect. I will have to ask around. Unfortunately in the meantime I canât think of any way to trigger a reload when the current user changes.
It is possible that your issue is related to the âcurrent userâ inspector, which returns the person logged into session 0.
Try this and see if your behavior changes:
if (number of logged on users > 1) then âMultiple Usersâ else ((sid of logged on user) as string) & " " & ((if (exists current user) then (if (exists dacl whose (effective access mode for (name of logged on user) of it = effective access mode for âAdministratorsâ of it) of security descriptor of system folder) then (" (Admin)") else (" (Non-Admin)")) else (" (Admin Status Unknown)")))
Any further insight on this Jesse, has it been reported as a bug?
It should be easily fixed, for example caching the clientUI pages in the userâs profile rather than the BES application folder⌠and of course triggering a reload whenever the clientUI.exe is started.
I hate to reopen an old topic, but did this ever get fixed? I think I am still experiencing a similar issue and we are on version 9.0.835.0
My query is: unique value of value of components whose (type of it=âCNâ) of distinguished name (distinguished name of logged on user of active directory)
When the Dashboard UI tab is clicked on, it displays âSingular expression refers to nonexistent object.â, if I click on the refresh link to reload the page, then the value I was expecting pulls in.
So it seems like I am not getting fresh data even after restarting the BES client.
EDIT: Turns out that the issue was that the AD sampling time wasnât current therefore the object didnât exist until I manually hit refresh.
I ended up using this relevance instead which does what I need it to:
if exists (domain users(names of logged on users))then full names of domain users(names of logged on users)else if exists (users(names of logged on users)) then âlocal accountâ else ânoneâ
I still seem to be experiencing this exact same behavior using the client dashboard. Everything works greatâŚuntil a new user logs on the machine. If they hit ârefreshâ which reloads the html page (cid:load?page=_dashboard.html).
It then keeps the first userâs name and adds the currently logged on userâs name next to the original name.
Possibly itâs just incorrect relevance causing this?:
if exists (domain user(name of logged on user))then full name of domain user(name of logged on user)else if exists (user(name of logged on user)) then âlocal accountâ else ânoneâ
Well the behavior happened initially when I had the relevance in plural form âusernamesâ instead of just âusernameâ when I changed it to just singular and had someone logon and hit refresh, this time it populated with their own info. So itâs possible that it really was just the relevance.