Subscribe to this feed

Welcome back to our Blog series about GeNiEnd2End Scripting!

Today we will go through GUI based Front-End scripting and what you should do or avoid there.

Scripts which interact with the desktop of the robot are easier to build with AutoIt, but will then only run on Windows Platform.

The hardware of the robot should match the normal user hardware else you won´t get the same results as the user. 
A real hardware should be taken and no virtual machine.
Since the key is to find the problems a user would have and how much time it takes the user to wait for a transaction.
Every measurement which acts like a user should start with a click documentation, it includes all the steps which the script should make and you can set / find out the measurement points there. This will help you later identifying problems causes, if the script wont go through specific steps.

Example click documentation from one of our production scripts:

Best Practices:
  1. Write a Log, maybe with a debug flag which enables extensive logging if you need it.
    This can help you to quickly identify where it hangs, so you can see different results from a run in programming environment and a compiled version.
    The GeNiAgent will also search for a "error.log" and "detail.log" in the script folder and upload it to the GeNiEnd2End Server, so you can directly check that in the Web UI if there is any error.
  2. Does the application have a fast changing GUI (Will the GUI design change much)?
    If so you should try to take window text (titles, content) for this measurement so it will not be harmed as much if the design changes over time.
  3. If you have to use image search:
    When you have to take image search you should try to make as neutral screenshots as possible. 
    This means try to take a screenshot from a GUI element which will not underlie much changes or is somewhat clear to spot, even if the location changed a bit.
    The screenshot area should also be as little as possible, this will help a lot if the GUI changes since the chance to spot it even after a change is bigger.
    They should be taken on a robot so no color differences are there.
  4. If something goes wrong in this application will it throw display errors \ Error handling ?
    Maybe you have to check for an error after a timed out measurement or a problem occurred and the application didn't close correctly.
    So keep that in mind and script for that cases. Use "error.log" and "detail.log".
  5. Can you do the steps just with clicks or also with keyboard interactions?
    You can send keys and this is mostly the better way to interact with the desktop, just if it uses the same function as the click.
    If you have to use mouse clicks and the button location may change, do an image search for a part of the button and then click on it.
    So you don't click a false button because it moved over to another place.
    If your application doesn't lock the ids / captions of the design elements you can also track and directly click elements. (Check that with AutoIt Window Info)
  6. If you are doing many transactions after another or use Packet Trace / CNS Option be sure to use the 5 second pause before every transaction starts.
This Example script runs on a Robot, its a AutoIt script which interacts with IBM Notes 8.5 and 9.0 without many changes.
Next time we will go through Back-End scripting.


Welcome to this short series of blog entries regarding GeNiEnd2End Application - HowTo / Best Practices scripting.

This series will show you what you have to be aware of if you create scripts and which scripting language fits which needs. The Best Practices should help you to get around some common problems and mistakes.

This time we start with the general scripting guidelines and which language best fits your needs.
At first ask yourself these questions:

  • What would you like to achieve with this measurement?
  • Platform of application?
    • Windows
    • GeNiJack
    • Both
  • What type of application?
    • Website
    • Self maintained GUI
    • distributed GUI
    • Other
  • What measurement points will the script have?
  • Is there a default script for that, which you could edit if needed?

Which default scripts exist in GeNiEnd2End Application can be seen in the Help File under the section Application Measurement -> Default Scripts.

Feature comparison AutoIt versus Python:


  AutoIt Python
Platform Windows Windows / GeNiJack
GUI Control Yes and its easy Possible but not recommended / Not on GeNiJack
Website Testing Yes fully Yes but only download time and changes
Recommended for Beginners / Professionals Professionals
Measurement accuracy Good Best
Feature Scope Good / many Modules available Best/ full programming language


So if you are new to scripting / programming you should start with AutoIt and a basic script, if you already programmed in a professional language python has a lot more functions for you and will be more fitting your needs.

The don'ts :

  • Don't forget about the CNS Option, which can show you then how the measured time breaks down to Client / Network / Server time.
  • Don't under estimate the power of AutoIt, its feature wide, easy and rock solid.

If your tool has a special language for GUI based testing or you simply like another language, then you also can use that and deliver the results back to the GeNiAgent.

In this case please contact us for help at:

Next time we will go through GUI based Front-End scripting and what you should be aware of.

GeNiEnd2End Application

Although Wireshark is the best tool for protocol analysis, it is not the ideal tool for capturing packets on a 10 Gigabit network or a highly utilized 1 Gigabit network.

When debugging network issues, it is very important not to miss any packets in the trace file. I do not mean the packet loss, which is seen on the network itself but packets, which are dropped due to the limited capture performance of the Wireshark device. Dropped packets, due to capture performance, lead to misinterpretation and you will waste countless hours of troubleshooting without striking success.

The typical approach: a Do It Yourself (DIY) Wireshark solution is attractive due to its seemingly low up front cost. However the lack of hardware performance increases the chance not be able to capture all packets. The capture performance is either limited by the capture rate of the NICs and/or the continuous write-to-disk rate. And I’m not only referring here to capture a fully utilized 10 Gigabit link continuously. It are the spikes and microbursts which are the main cause that not all packets are captured to disk.

Wireshark is invaluable for packet analysis but capturing 10 Gigabit networks exhaust the DIY Wireshark solution. So what now?

In our troubleshooting services this is always a challenge. So our experienced consultants either reduce the traffic by applying a selective filter or deploy a solution with sustained write performance to ensure lossless capture.

A simple and effective solution to limit the packets is using the Network Visibility Switch FlowDirector. With FlowDirector you can flexible filter by VLAN, IP address, Port ranges etc.

In case this approach is not applicable, we deploy a Network Visibility Appliance like FlowMagic. It allows a scalable capture performance beyond 20 Gbps per network module and the linear scalable storage concept ensures lossless packet capture.

Missing packets in trace files are now a thing of the past. No more false insights and analysis time for the birds!

And last but not least FlowDirector and FlowMagic have an outstanding price-performance ratio.

In the past on nearly every new-released product the technical highlights were at the forefront. Based on the principle “bigger, higher, faster, further” the quantity of the presentable parameters ought to convince the potential customer from the quality of the product.

Is it really necessary that the IT Executive needs to filter the information flood to find the important information and analyze if the product is the solution for the problem? Thanks to the pioneers, like Apple, who switched the focus on the important facts and became a market leader of the consumer goods. The vendors of IT performance monitoring tools now also pay attention to present complex analysis methods in a easy to understand user interface.

This reconsideration is pretty helpful because the IT person in charge wants to check initially if the relevant components needed for the IT operation (seen from the end-user) are available at the requested time period. Only when an issue is identified the necessity is there to deeper analyze the issue to find the root cause.

A good example for this simplified user interface for the IT analysis is GeNiEnd2End.

SPTA has nothing to do with Swiss tennis professionals; it stands for Structured Performance Troubleshooting Approach. It is not exact science, however when you perform Structured Performance Troubleshooting, you achieve constant progress and solve performance issues even faster. NETCOR is introducing this approach, as it is a compilation of the best practices that GeNiEnd2End customers are using to align people, processes and tools for an effective performance troubleshooting. These companies are seeing major improvements in the MTTR of performance related issues.

1st level
2nd level
3rd level
Verify end-to-end quality for the communication channel (OSI layer 4)
Verify end-to-end quality with scripted user transaction/services (OSI layer 7)
Multi-tier performance analysis with packet tracing (AdHoc & 24/7)

SPTA is a 3 stage troubleshooting approach based on GeNiEnd2End and enables the integration on all support levels of the IT support personnel. Each support level can assist in the troubleshooting process. The foundation of this approach is the idea that with the right information for the right person at the right time the troubleshooting process can be streamlined.

For example the Service Desk can now support the process by providing end-user performance information during the submission of the tickets. These trouble tickets are now rated and assigned by the Service Desk, which leads to reduced ticket processing time.

Are you interested to contribute to SPTA or find some spare time for testing, than let us know.


Than please do not run away and search for cover. There is no reason to panic.The land of kangaroos, didgeridoos and countless poisonous animals has something new. The first Reseller for GeNiEnd2End in the southern hemisphere! Congratulations PlexNet Pty Ltd! If PlexNet delivers GeNiEnd2End with Vegemite is currently not known.

IT performance can appear complicated which can make the diagnosis more difficult than it needs to be. An important performance indicator for the End-user is response time, which can be translated to end-to-end network performance metrics: packet loss, one-way-delay and jitter. These are important network characteristics for the network administrator to document the end-to-end quality of the network.

In this blog I want to start by taking a look at packet loss, which is a common network problem that affects application performance. So why is packet loss such an application performance killer? This mainly relies to the nature how TCP handles packet loss. If within a certain period of time (known as timeouts) the receiving party does not acknowledge a data packet, the sender sends it again. Timeouts caused by packet loss can add up to large delays as timeout values double with each retry.

We find out that a lot of IT admins think that packet loss of 1 or 2% is a small number and should have little impact on the application performance. Unfortunately, already a very small amount of packet loss will have a big impact on the TCP throughput, which in turn will affect the application performance. We recommend that packet loss rates higher than 0,01% should be investigated.

Server Retransmission - who ist the originator?

Client Retransmission - who ist the originator?

Identifying packet loss is with GeNiEnd2End Network little effort. You install either the free software endpoint on already existing PCs/Servers or position at demarcation points the cost-effective GeNiJacks. GeNiEnd2End Network will report besides packet loss also one-way-latency, jitter and other important network quality parameters.

GeNiEnd2End Network is the perfect addition for already existing network-based APM solutions like SuperAgent from CA, Application Xpert from Opnet or TruView from Fluke Networks. It streamlines the diagnosing of network performance problems considerable. With GeNiEnd2End Network it is a piece of cake to prove that "it's not the network".

So let me review in more detail the reasons why an active endpoint-based solution like GeNiEnd2End Network is the best mate of a network-based APM approach:
Within a network-based APM solution packet loss is reported with the metrics client and server retransmission. However, the originator (network, server of client) and the direction (backward/forward) of the packet loss can't be determined clearly. Have a look at the bounce charts above that reveal this.

However, with GeNiEnd2End Network you can decide quickly whether packet loss is caused by the network or not. Detecting packet loss is the first step for the network team in diagnosing application performance problems caused by the network. GeNiEnd2End Network streamlines the troubleshooting workflow and enables the network team to become productive in isolating the problem domain.

Interested to attend a product web session? Then let us know.

GeNiEnd2End Network - the real Troubleshooting tool for the network engineer!

If you are Indiana Jones, you now have a serious problem. If not, you will be delighted.
GeNiEnd2End 4.6 supports an additional application script language: Python. Now you are uncoupled from AutoIT and can script nearly everything what ever comes into your mind. Assuming that you know Python. If you still have problems to tame the Python, we are happy to help you with your project. Do you have the need to measure for example the response time of a database query? Or to initiate a Trace route and analyse the captured packets? No problem, we can take care of that.

Nearly nothing can stop the Python. The best is: GeNiJacks can now be involved „properly” in end-to-end application performance measurement. The time that they were the gloomy entities as an endpoint is a thing of the past, because on our GeNiJacks runs now Python too. So everyone wants to be a snake lover, right?

A typical field of application for GeNiEnd2End Network is to verify if the Network Service Providers (NSP) comply with the agreed service levels. Very often our partners get involved when their customers have painful experiences with the performance of their NSPs. Characteristic is that they have a hard time to pinpoint and resolve the performance issues with their existing monitoring tools fast enough.

NETCOR GeNiEnd2End Network

GeNiEnd2End Network completes the management tools already being used and delivers a unique advantage: an indisputable document about the end-to-end network quality. With these convincing arguments it is easy to stop the finger pointing blame game. Instead of laborious analysis with uncertain outcomes, the culprit can be located within an extremely short time. With GeNiEnd2End Network the customer receives objective end-to-end performance values for Triple-Play applications and makes the NSP hand tame during crisis meetings. GeNiEnd2End Network is the fear of the provider and a made investment is paid off in a short time.


Swiss Federal Department of Foreign Affairs (EDA) uses GeNiEnd2End Network to monitor the end-to-end quality of embassies around the world.
In about 190 embassies a GeNiJack is located. They provide, in combination with the central management software GeNiEnd2End, a complete 24/7 end-to-end network performance visibility.

GeNiEnd2End completes the existing network management tools with the capability to register significant end-to-end performance irregularities between the head quarter of EDA in Bern and the embassies. Now EDA can rapidly and verifiably check the performance of every remote embassy worldwide end-to-end.

With GeNiEnd2End the network administration of EDA can pinpoint network performance issues much faster, which significantly lightens the workload of the network personnel.

With the elaborate performance reports of GeNiEnd2End EDA is now able to support their embassy servants with consultation and with these reports long-standing performance issues caused by the network service provider belong to the past.

We are confident that the new  GeNiJack Plus will also sell like hot cakes. The last 2 years we’ve been selling the GeNiJack very successfull and with the recently launched GeNiJack Plus the possible field of applications will be extended even more.  The GeNiJack plus offers with the 2 Ethernet and WLAN connections additional field of applications like remote packet tracing via a span port. In combination with the web-based  GeNiEnd2End MultiTrace Software, multiple GeNiJacks can be controlled centrally for a multi segment packet capture. Trace files can be saved on the embedded memory card. Subsequently the trace files can be transferred as needed to a central location to merge the trace files for further analysis with multi trace analysis tools like the ClearSight Analyzer from Fluke Networks. The GeNiJack Plus is cost-effective hardware  for remote packet capturing in remote locations and completet the already embedded end-to-end/QoS performance monitoring functionality.

And again a customer ordered 50 of them. Even when it looks like assembly line work, every  GeNiJack is unpacked, strenuous installed, plastered and packed in again.

It is like producing nutcrackers from the Erz Mountains.

But if our GeNijacks taste like hot cakes, you have to check by yourself.


After a long time and loving handwork, equal to a katana of Hattori Hanzō, GeNiEnd2End 4.5 alight from the still hot (software-)forging furnace. But GeNiEnd2End has much more features then a stupid sword. It does not only stay in a cabinet. It works for you!

GeNiEnd2End automatically identifies QoS misconfigurations. You can immediately see if your QoS tagged packets do not arrive at the destination. QoS variations are alarmed now pair-based. Furthermore, you can activate QoS testing with a single click.

The new GeNiJacks can now perform packet tracing. This allows you to use the GeNiJacks for QoS testing. Try that with a sword!

The possibility of customized unit’s open up a new world of values. With GeNiEnd2End 4.5 you can insert all possible values, and even converting them. You can tap into every possible data source and display the collected data in GeNiEnd2End 4.5.

There are additional major and minor changes. We changed a lot in the web GUI, some procedures were improved and some shortened. The GeNiEnd2End Agent runs now in the system tray, if it was installed as a GUI version (finally no more DOS box). Under the surface we improved a lot, too. Stability and speed has been increased on the server and on the agent.

All changes can be read in the release notes. You want to convince yourself?

Then ask for test environment, or contact us for the support for an update of your existing GeNiEnd2End installation.

What sounds like a Hollywood blockbuster, turned out to a real challenge at the last customer measurement for an application monitoring with  GeNiEnd2End Application.

You start to script full of drive and then you see application that tell anything. You can neither check on window titles nor window contents or buttons.

Of course a person can work with it, because he can read and execute the appropriate actions, but it is difficult for a robot script for application monitoring. You could use OCR-software, but this is much to complicated. In the past we used elaborate pixel-checksums, but they were really rigid and with every change of the application they had been new calculated.

Fortunately had some colleagues from NETCOR already developed a screenshot helper, which allowed me to “photograph” parts of the screen and check them. With a few clicks I was able to select the desired screen area and define a measuring point as well as a click target. No matter where the cutout is. Even with changes in the application!

Since this point NETCOR has no effort with "mysterious windows" anymore. All applications, windows or window contents such as flash elements in the browser windows, CITRIX, TELNET applications, JAVA applications or remote desktop windows with less told information are now on the "no-problem-at-all" list.

Again a service has been completed. The problem was found and the client is happy. For the customer it was a long ordeal, because the problem has already been moved for a while between the supplier of the software, the server administrator and the application and network managers. Because the environment is no simple client to "single server" application, but much more complex, we chose the path of the expulsion proceedings. Complex was: ESX Server on 2 blade systems, each with 2 virtual servers and multiple single distributed application services.  All together in an MS cluster that could be distributed from VM and MS cluster view. Of course, everything connected double redundant.

We used  GeNiEnd2End Application to make the sporadic problems visible which were described by the users. In addition, we used  GeNiEnd2End Network to get a view on the network infrastructure from the perspective of the end-to-end quality.

As most common, it is rarely just one big problem, most of time there are a lot of small problems, which become to a big problem.

So we could see that the application had sporadic longer transaction times. But the network was not flawless, too. The central WAN route had packet loss. Moreover, the measured application transaction came to a standstill because local and remote tailed workstations lost 1-2 packets and as a result they needed 2.5 seconds instead of a second.

The WAN line was tuned by a new router, which resulted in a significant improvement of the usable bandwidth, but also to omission of all packet losses.

To restrict the cause and location of the packet loss in the LAN,  GeNiEnd2End MultiTrace has been used. So it was now easy to perform a 3-point clamp measurement and investigate a problematic transaction. The clamp measurement was placed on the VM guest, the server switch via SPAN and on the client. The investigation showed that the packets drop away between the switch and server VM host.

These losses were also confirmed by the measurement with  GeNiEnd2End Network. Here was also the packet loss over the whole period of measurement between server switch and vServer measurable.

There followed several attempts by the server people to isolate the problem further. At this point only  GeNiEnd2End Network and  GeNiEnd2End Application had the control - by these tools, we received an analysis with minimal effort in the single digits of minutes!

All other changes, e.g. use vMotion, to test the other blade or the switch within the MS cluster, were unfortunately unsuccessful.

Finally we have got an improvement by replacing the virtual network card inside the guest VM.

The measurements have now shown that they have no packet loss within the VM anymore.

Thus, this problem has been identified with comparable little effort and ultimately resolved in the right department.

The increasing complexity of infrastructures with centrally hosted applications make the search for performance bottlenecks to a time-intensive task that is usually then necessary when there is really no time for it, because of the project situation.

Especially the network managers are required here in the first place. The statement that "the network is once again slowly" has burned itself into the minds of the user. Objectively, there was in the past years a clear shift of the cause of the problems. But the man is glad with what is familiar to him. So at first the network is then problem, till the contrary was proved.

Looking for potential error sources networkers made use of typically SNMP or NetFlow monitoring solutions. But first of all it must be verified, which "way" the application takes, which is not always easy. In addition, a port with a high load is not directly the trigger for high response times.

Also time-consuming protocol analysis is a frequently chosen tool to expose the problem, or at least their own "innocence" of the issue. Everybody who has ever done this knows how time consuming it is. More annoying is it when it is found that the  cause of the problem is not the net!

Because of this fact more and more network managers implement a solution that measures und documents the performance of the infrastructure 24x7 from the view of the users. With the right tool everybody can proof or disproof within a few minutes that the cause of the problem is in the infrastructure or not. A quick-to-deploy and affordable solution for this is for example  GeNiEnd2End Network.