I’ve got a fixlet partially written that does a traceroute for 3 hops to www.google.com and pipes the report to a txt file in the bes client folder. I’ll also create a retrieved property to report every check in with the info.
Let me know what anyone else is thinking to see behind local routers, etc to get the real ip and to maybe track down by the internet service provider.
The problem I have had with this - is that all the laptops that we have had stolen never report back in - because the crooks are usually smart enough not to put them on the network before wiping the drives or either they throw the current drive out. Guess you would need BES to run on the BIOS level to really have control. One of these days though - we’ll get the un-educated thief who doesn’t know better enough not to put a stolen laptop on the Internet before wiping
BigFix does not have a specific wipe command, but you can try to run scripts to download and run wiping tools, or delete certain files, or format the drives, or whatever other tricks you can find.
It sounds like the first thing we should do is verify all the configurations. It might be that one of the settings was reset during the upgrade.
Note tha using the SSL redirect is definitely not a common configuration and the new “message level encryption” feature is generally considered to be a better approach to protecting the agent reports.
We have deployed BigFix to laptops and have them contacting a relay in our DMZ. In the following scenario would you anticipate an issue when moving from the wireless to wired network:
Laptop boots and connects to the Internet via wireless card.
Successfully contacts BigFix relay in DMZ and executes fixlets.
Laptop set to sleep mode.
Laptop brought into the office, connected to trusted wired network and woken up.
At this point since the DMZ relay is no longer available (no access to it from the trusted network), would the laptop look for and find the trusted network BES server / relay or would it keep looking for the DMZ relay?
If the agent was asleep log enough that the relay selection interval elapsed (6 hours default), then it would naturally try to find another relay at this point and find an internal relay… However, if it was asleep only for a short period of time, it would still try to contact the DMZ relay, but it would fail (because it couldn’t reach it) and then the agent would try again 10 min later (by default) and if it still couldn’t connect, it would try to find a better relay.
So in your scenario, it seems that the default autoselection agent behavior would work well…