We installed RoboER on three of our lab test machines. Machine A, aWindows 2000 Advanced Server system with a Pentium II 450-MHz processor and 512MB of RAM, functioned as our primary platform for remote management. It alsoprovided DHCP and NAT services to our two test clients. Machine B, a 300-MHzPentium II running Windows 2000 Professional, served as our Windows 2000 clienttest system. Machine C -- an AMD K-5 133-MHz box running Windows NT 4.0Workstation -- filled the role of our NT client test machine.
Like most Windows programs, RoboER was a snap to install. An installwizard walked us through most of the steps -- and prompted us for aridiculously long product key -- until we were ready to configure RoboER forfirst use.
A dialog box appeared when the install was completed. We were given theoptions of designating the specific transport that RoboER was to use, either aTCP/IP or a serial connection; choosing the TCP/IP port RoboER is to listen on-- if applicable; identifying the IP addresses of machines that could be usedto manage a RoboER client remotely; enabling auditing of specific events in theRoboER environment; and facilitating logins even when the Windows NT/Windows2000 SAM isn’t available -- by virtue of RoboER’s SAM Bypass Login function.
Through the Paces
The problem with a review such as this is that there is never enough time to thoroughly drilldown into everything a product can and can’t do, also there’s almost neverenough space in which to delimit eachof a product’s most notable features. This last constraint is particularly truein the case of RoboER.
Depending upon your network transport -- for example, if for some reasonyou don’t run TCP/IP in-house -- you can choose to connect to RoboER-supportedsystems using either TCP/IP or through a serial connection. We chose TCP/IP asthe transport of choice for each test we performed. RoboER listens by defaulton port 2920, by the way.
RoboER includes several test utilities that provide an indication of whatit can do for you. One program, memhog.exe, simulates a loop process on a PCthat can maximize its processor utilization at 99 or 100 percent, rendering iteffectively inaccessible from some GUI-based remote management programs.
We performed the memhog.exe test on Machine B and Machine C. Before runningmemhog.exe, make sure the RoboER service itself is started. If it’s not, you’llhave a looping machine on your hands and no way to stop it from looping shortof a physical trip to the affected client and its off switch.
After remotely starting the RoboER service on both clients, we Telnetedinto each machine, logged in, used RoboER’s process/list command to list thenames and ID numbers of the processes that were executing on the client, andthen used RoboER’s process/kill command to end the memhog.exe loop. Voila:Processor utilization on both clients returned to the average value of 1, 2, or3 percent.
How many times have you attempted to restart a service on a remote serveronly to end up exasperated by the presence of a dialog box prompting you to “Click‘OK’ or ‘Cancel’” before the service itself can actually be restarted?
RoboER’s “set” command -- which includes a /popup parameter -- neatlynegotiates this potential pitfall. For the following test, we were able to useanother of RoboER’s utilities -- crash.exe -- to simulate a service crash withan access violation. Normally, this type of premature service or processtermination would trigger a dialog box on the affected client or server, butbecause we had already used RoboER’s “set /Popup NO_SYSTEM” command to disablesystem popup notifications, it didn’t. Consequently, we were able to use RoboERto restart the affected application within seconds.
RoboER provides full command-line access to Windows NT/2000 eventnotifications, and gave us the ability to selectively ignore notifications thatwe weren’t particularly interested in. RoboER also provides wonderful remoteregistry editing features, and even boasts a command-line translation ofWindows NT/2000’s regedit.exe tool. Using RoboER’s RegEdit shell, we were ableto navigate to particular registry hives -- such as hkey_classes_root, andhkey_current_config -- and were given the option to change values if desired.Not feeling quite so adventurous, we left everything as it was.
RoboER provides several additional features that we were able to invokewhile putting it through its paces. Its Sysinfo command gave us informationrelevant to our client machines’ particular operating system platforms, overallCPU usage, and overall memory usage; its DOS command allowed us to drop out ofthe RoboER environment and into the Windows NT/2000 vanilla command shell; itsReboot command gave us the ability to reboot machines remotely; and its Helpcommand actually helped us use it.
Over All RoboER is an excellent tool that can help augment the manageability ofalmost any distributed environment. Its command-line parameters may proveconfusing to IT managers who are less well-versed in the black arts of OpenVMSor Unix/Linux, but they should pose little or no difficulty for mostadministrators. The product benefits greatly from integration with Heroix’sRoboCentral console management tool -- especially when event monitoring, eventnotifications, and special event triggers are concerned -- but it is a productfully capable of standing on its own.
In the final analysis, it is flat-out easier to manage remote servers andworkstations from a command-line environment, as RoboER aptly demonstrates.
RoboER
Heroix Corp., Newton, Mass.
(617) 527-1550
www.heroix.com
Pricing:
RoboER 2.1 with five client licenses is $1,395; with 50 client licenses it is$10,450Pros/Cons:
+ Provides an essential reduplication of Windows NT/2000’s GUI-basedmanagement features in a command-line environment
+ Command-line environment is faster and more efficient for mostmanagement tasks than a GUI-based approach
- May pose a substantial learning curve for administers not accustomed tomanagement in a command-line environment