Blog


24 June 2013
Feature highlights, Releases, Total Network Inventory | 4 Comments

TNI 2.2.2 (1483): Action-packed update

Today we’re back with new TNI 2 update. And it’s all about ACTION!

Or, rather, actions: things you can now do remotely to computers in your network right from TNI. But before we jump in, as always, here’s the change-list:

  • BIG FEATUREStandard and custom actions.
  • NewDetection of CentOS and SliTaz Linux distributions: SliTaz and CentOS icons
  • FixedFreezing of the scan process in some cases.
  • FixedName resolving for assets with dynamic IPs.

 

Introducing actions

There are a few Standard actions that TNI performs directly (Reboot, Power-off and Wake-on-LAN) as well as Custom actions, where you can use a simple scripting syntax to perform just about any action you need using system routines or third-party utilities.

Let me show you some examples of the latter, starting with the most obvious one. Assume you want to ping an asset using the good ol’ ping.exe routine. You open up cmd.exe and type ping.exe followed by the asset’s IP. Why not automate the task by creating an action:

Ping asset=cmd.exe /K ping.exe %IP%

After putting that in place you just right-click any asset in the network tree to see this:

Ping action

You get the idea. Now let’s see some variety!

Conditional directives

Things like this are now a no-brainer:

Manage computer=mmc.exe compmgmt.msc /Computer=%IP%

But this action is not applicable to non-Windows machines, so why even have it available for Macs or Linuxes, right? Let’s prefix the action definition with a conditional directive.

{$IF WIN}Manage computer=mmc.exe compmgmt.msc /Computer=%IP%

It makes way more sense this way. Further, we may want to do something like

Browse web=http://%HOST%/

But this can also be enhanced:

{$IF OPEN80}Browse web=http://%HOST%/

We have a bunch of available conditions that make use of the information TNI knows about a device, and it’s a good idea to use them to remove confusion in a multitude of cases:

  • OPENXX — whether the specified port is open.
  • OPENSSHPORT — this takes the SSH port from the scanner settings.
  • ONLINE
  • WIN — whether it’s a Windows device…
  • LIN — … a Linux device…
  • MAC — …or a MacOS X device.
  • SSH — whether the device was scanned via SSH (it could be a Linux, Mac OS X or a FreeBSD device).
  • SNMP — whether the device was scanned via SNMP.
  • LAN — whether the device and your PC share the same subnet.

And of course you can prefix any of these with a “!” to make it a negative. E.g. !ONLINE means “offline”, !WIN is “anything but Windows” and so on. Also, you can list several conditions under one IF directive separating them with commas, this will be treated as logical AND. Like so:

{$IF LAN,!ONLINE}Wake-on-LAN=wol.exe %MAC:%

Actions for multiple devices

Some actions are not supposed to be executed for several devices at once. By default, an action is considered to be aimed at one asset. To make it available when several assets are at gunpoint (or when you right-click a group), you should add the {$MULTI} directive.

{$MULTI}{$IF LAN,!ONLINE}Wake-on-LAN=wol.exe %MAC:%

There’s another matter to consider when dealing with multiple devices. The declaration above makes the action applicable to a group of assets if any of them is offline and any of them is in your subnet. While there’s nothing wrong with the former condition (online assets will receive WOL packets too, no big deal), there’s no point in trying to send WOLs beyond the LAN. So, we change the latter condition to all of them are in your subnet by attributing a “!” after it. As in, LAN! — mandatory for all!

{$MULTI}{$IF LAN!,!ONLINE}Wake-on-LAN=wol.exe %MAC:%

Now this action seems pretty well-defined.

Protection from accidents

While most actions will probably do nothing destructive, some of them may be dangerous if used accidentally. Use {$?} directive for those. It will display a confirmation dialog every time you fire the action. Here we use Sysinternals PSTools to shut a device down. Dangerous, right?

{$?}Shutdown=”C:\PSTools\psshutdown.exe” -k \\%HOST%

Sending keystrokes

Let’s take it even further. Suppose we have an action to initialize Remote desktop.

Remote Desktop=mstsc.exe /v:%IP%

Simple enough, but what it will do is open the authorization window and require us to type in the password manually. There’s a better way. We can send the password in there by simulating key-presses!

Remote Desktop with login=mstsc.exe /v:%IP% /sendkeys:%PASSWORD%{ENTER}

After the /sendkeys command you may use:

  • Any line of text — it will be sent as is;
  • Templates;
  • {$WAIT X} — this directive will pause the execution by X milliseconds. If you omit this directive, the default pause before sending any keys is one second;
  • {key name} — simulate pressing a special key. Key name may be one of the following: F1..F10, LEFT, RIGHT, UP, DOWN, ENTER, BACKSPACE, PGUP, PGDN, HOME, END, TAB.

So, in the example above, we virtually type in the password and press Enter. The %PASSWORD% template will be automatically replaced with the password associated with the asset in your storage.

Speaking about templates.

Templates

The following templates in action definitions will get replaced with actual values for each specific asset:

  • %HOST% — FQDN, hostname or IP, depending on the Static IP flag
  • %HOSTNAME%
  • %IP%
  • %MAC-%, %MAC:%, %MAC% — MAC-address separated by hyphens, colons or without separators, respectively
  • %SSHPORT% — SSH port number, as specified in the Scanner settings
  • %USERNAME% — username from the assigned login
  • %PASSWORD% — password from the assigned login

And this about sums it up for the actions highlight. You will find most of the actions used above as examples already included, feel free to modify them as you please or delete the ones you don’t need. Don’t be shy and experiment with custom actions, there’s no limit to what you can do using third-party tools and our simple scripting syntax.

How to edit them? Right-click any asset and find the Edit actions button in the Actions submenu. Or go straight to Options » Actions. You’ll find a handy cheat-sheet there (click a value to copy it!) and a big button to open up the definition list in Notepad — the best text editor there is… ish. :)

One last thing. If you can think of anything we’ve missed (a useful condition, directive or template perhaps) then please let us know, we’ll implement it.

Update TNI 2.


30 April 2013
Releases, Total Network Inventory | 4 Comments

TNI 2.2.1 (1448): Asynchronous Discovery Engine

Hello! The theme for our new update is:

Pushing the limits of network discovery

…well, alright, maybe not that epic. Still, check out the changelist:

  • NewNew fast network discovery engine — Asynchronous engine. Discovers online hosts in /24 subnet (254 addresses) in just one second.
  • NewPossibility to choose from three network engines (asynchronous, Nmap and classic) for online status detection and network discovery, and two network engines (Nmap and classic) for port scanning.
  • NewPossibility to run TCP-ping (skip ICMP and ARP ping and scan ports immediately) to discover assets that don’t respond to ping.
  • NewPossibility to use last known IP address for assets with dynamic IP addresses and non-resolvable names (Samba environments and other).
  • NewPossibility to specify custom SSH port.
  • NewNon-scanned assets which are detected to be online or at least exist on the network (i.e. name or IP can be resolved) are added to the inventory database even if MAC address is not known.
  • NewDNS-based name resolving in domain environments.
  • ImprovedScanner settings were revised and are now more intuitive and flexible.
  • ImprovedEasier scan of SNMP-enabled devices: the program can probe most commonly used SNMP communities besides “public” and run successful scan of such device if one of them is used.
  • ImprovedRPC method of scan for Windows computers is disabled by default for new installations, and is recommended to be disabled for existing installations.
  • ImprovedAll non-Windows agents updated. Improved stability and compatibility.
  • FixedCPU usage issues with online status detection and Nmap engine.
  • + minor fixes & improvements

 

The Asynchronous Engine

Just like Nmap, the asynchronous engine can detect online hosts on the local subnet which don’t respond to ICMP ping (due to Windows firewall settings: it is the default behaviour for freshly installed desktop Windows systems). Classic engine can also do that, but it takes too long because ARP ping on latest Windows versions is slow.

And now, as you may have noticed from the first changelist item, local discovery is almost instantaneous. It takes a mere second.

New in Scanner Settings

This page of settings used to be a little cluttered. We’ve removed the scanning profile settings and made things more friendly. Be sure to notice this part:

Discovery engine options

The download link is the same, no surprizes.

And that’s it for the day. Bye!


27 March 2013
Feature highlights, Releases, Total Network Inventory | 2 Comments

TNI 2.2.0 (1438): Scan scheduler

Greetings! The change list is short this time, but check it out:

  • BIG FEATUREScan scheduler

 

The “list” kind of looks like a cigarette, but remember: smoking kills…
Yeah, I’d rather tell you all about the new Big Feature.

 

Creating and scheduling a task list

 

Yes, the Scheduler operates on saved task lists.

To create these, you first add some tasks to the scanner, set them up (i.e. discover nodes within ranges, enter logins and passwords, etc) and then you click Save current tasks button on the sidebar.

The result is what you see in the figure here. Each task list is saved to a separate file, named and fully prepared for launch at any time.

But until now you could only launch them by hand.
Enter Scan Scheduler!

 

Move your cursor over a task list to see the Schedule this task command and click it.

Schedule this task

This opens up the Scheduler page. You can access it at any time: it waits for you in the Options window.

Scheduler page

The scheduled task is already created for the task list you clicked earlier.
Now you want to tell TNI when and how often you need this task executed:

    • Once. Just tell TNI when.
      Run once
    • Daily. Every day at specific time. Or once every N days.
      Run daily
    • Weekly. On specific weekdays every Nth week.
      Run weekly
    • Monthly. This is a very flexible mode. For example, here we’ve set it up to run the task every second month on the first and last days of the month and also on the second Fridays of these months.
      Run monthly
      A more life-like set-up, e.g. “first Monday of every month”, will work just fine, too.

For each mode you should also specify the starting date and the time of day. While you’re setting up a task, you can see the Next run label constantly updating, so that you could be sure you’ve done everything right.

 

Scheduler operation

For now, the Scheduler can only execute a task successfully if, when the time comes:

  1. TNI is running.
  2. The scanner is not being used.

These are the limitations, but we’re busy lifting them.

If something stops the scheduled scan from running on time, you will know about it from the Run log. Every task has a separate log where you can find all the details: how many nodes were scanned, how many errors were encountered, whether a run was skipped and if so, why. Also, full scan logs are saved for each successful run.

I could go on and on about how useful and convenient the new Scheduler is, but you can find it out yourself by downloading the new version of TNI.

To wrap it up, I’ll just mention the two new versions of our site: tr Turkish and pl Polish.

See you in the next post!