I have been looking at creating reports so our service desk can keep control of users, licences and who to charge etc. However I am unable to get the reporting tool to display the information i want. Does anyone know if it is possible to use another program to extract data from the database to create reports / databases.
using the reporting tool I am able to get most of the information I require, however is it possible to tap into the data directly or export in realtime, so that reports will not need to be created exported to spreadsheets, imported etc.
Solved! Go to Solution.
You may also use scripting tool (sbadmcl) to obtain information in real time, though it might not give you information in the format you want.
Using the sbadmcl interface is the way to go here. Some tips...
- use the DumpUserAudit command to see "who is doing what". You can use the -eventID input parameter to filter for specific events (like key export, or recovery). A list of event IDs is in the admin guide.
- GetLastCheckInDate is kind of a catch all command for machine information. It tells you the last time it sync'd, crypt status, last logged in user, etc. You can dump lots of info from this one command.
- remember, all commands require authentication. So you have to use the -adminuser: and -adminpwd: parameters for any command that tries to pull data from the database. If you don't like passwords in clear text in your scripts/commands, use the GenerateAdminAuth command to hash your pw (then use the -adminauth: instead of -adminpwd: in the command syntax).
sbadmcl -adminuser:dan -adminpwdassword -command:dumpuseraudit -eventid:02000016 -group:* -file:user_aduits.txt
You would run this on the server. This would dump all "recovery started" events for all users in the database. It would write it to a file in the application directory on the server.
Does anyone have any ideas for reporting policy settings? I'm looking for a way to dump all the settings for, say, a controlled machine group. Settings beyond just encryption, like which boxes are ticked in Options, under General settings. I really don't care about format, I'll parse whatever gets spit out so I can work with it.
Sorry, but the API doesn't have any "export policy" or "export settings" commands. I believe there is a feature modification request to create such a feature (import/export policy), but it isn't being developed yet (not on the roadmpa with a release date).
Thanks for the input on the policy export question. I'm a little surprised. Here's why it's needed: The API can report encryption status of a drive. That good but it's only half the picture, Encryption without PBA is almost pointless. Our CIO, our legal counsel and our auditors all know this. When we have laptops stolen they all immediately ask, was it encrypted, and was PBA enforced? The EE audits as they exist will allow me to fully report on "who", "where" and "when", but not "what". If the loss is reported between the last time that machine's policy changed and now they will live with print screens of the current settings assuming the machine synched within that time frame. But if the policy was changed between the loss and now, or the machine had not synched since the policy was changed, we have no way to report what the settings were at the time of the loss. With an API to pull that data our I could plop a script into our enterprise reporting tool and maintain our own policy settings audit trail.
BTW, I can tell you from first-hand experience that auditors really, really dislike screen prints as evidence and it makes them grumpy.
Ok, now I see what you are after. You can get what you want with our API. You just have to use the DumpMachineAudit command. This will show you who is logging into the system, if you see autoboot as the last logged in user then you know it was in autoboot mode. Autoboot can only log in if the user is there AND you've unchecked the "disable checking for autoboot" (so this inference confirms your policy setting).
In fact, if you run the GetLastCheckinDate command you'll get everything you want. It shows the crypt status and the last logged in user. So if that user is autoboot, then you know it was in autoboot mode.
Remember, what your policy says in the console is irrelevant when in audit mode. What matters is what was actually applied to the PC. So its actual state is only as true as your last audit event (i.e. the audit event is what you can prove).
Duh, thanks! It's brilliant in its simplicity. So that addresses the "lost laptop" scenario, which is huge, but I have some others where an API to get to those settings would be useful. Or maybe other brilliantly simple ideas that I'm not considering:
1) Periodic audits--some policy parameters in EE are set by our IT controls. For example, passwords are required to be a minimum legth. When auditors come in and say show me that all your applications comply with your password policy, how do I do that with EE? I have 180 User Groups and 120 Machine Groups.
2) Routine Admin--Yes, we have fairly stringent change controls but they're not perfect. Changes occasionally occur that should not. How do I know if one of my 180 User Group settings is not in compliance with the established standard without having to open each and every group?
3) Helpdesk Knowledge--when our service folks need to troubleshoot an issue related to EE they need to be able to get information about the user and their machine. The way they have that now is they all have the EEM app installed locally. And it's slow so they want to leave it open all day, "just in case". That eats connections and makes "everyone off" maintenance in EE an occasional challenge. (40 or so full-timers plus 5-8 temps seasonally, spread across 5 US States.) Also, it means that I have to complicate my config and connector settings considerably since several additional groups are required to make the administrative settings granular enough to suit our needs. But with an API I can take EEM off most of our helpdesk PCs and let them search for the info they need from a web page, which uses a single EE user account. Possibly even a single connection. Heck, I wouldn't even need to create EE accounts for most of them.
None of the above are show stoppers but man are they expensive over the long run.