In this scenario we show how a level 1 helpdesk analyst would use Experience and Explorer together as part of their daily routine. A level 1 helpdesk analyst usually focuses on a specific device at any particular time. Here the user of a device is on the phone with the analyst describing the symptoms. Experience will enable the analyst to troubleshoot primary causes and Explorer will let them interact directly with the device to further investigate and resolve the issue.

On this page:

A case for the level 1 helpdesk analyst

An end-user calls the IT helpline, gets put through to the level 1 helpdesk analyst, and reports that their device, ACME-WIN1002, is running slowly.

Tracking down the issues in real-time

While the user is on the phone the Level 1 helpdesk analyst checks the Experience tab they have open in their browser.

The Experience Dashboard

Using the Devices page

They navigate to the Experience→Devices page, which provides an overview of all the devices currently being reported on. The environment may contain tens of thousands of devices so the analyst will likely need to search for the particular device in question. 

The Devices page

Searching for a device

In the Search Devices... field just above the table they enter some text from the name that will help identify the device. In this scenario most of the devices begin with the text ACME, so the analyst enters the significant part WIN1002 and selects the Fqdn contains WIN1002 option. If the naming convention was different, the significant part might be at the beginning of the device name, so they would likely choose Fqdn begins with... instead.

Searching for a device

Investigating the device

After the search the device displayed in the table matches the search parameters. Here the analyst can see that the general Experience, Stability, Performance and Responsiveness scores for the device are ok - so some further investigation is needed to track down the issue.

The device located

Looking at device details

Clicking on the name link in the FQDN column shows the details page for the device. Here on the left of the pane you can see the general information for the device, including System, Activity, Client Certificate, Coverage Tags and Management Groups info. On the right you can see the Metrics that have been captured for the device.

Scrolling down through the metrics the analyst can see a low score for the Memory: Physical memory usage metric, so maybe there's a memory related issue that is slowing the device down.

The device Details

Memory usage trends, a possible cause?

Clicking on the link for the metric drills down show to show the Trends for that parameter. Here the analyst can see that the general trend (even though the measurement has only been taken for just a few days) is headed downwards. So could be worth investigating more, the analyst makes a note and continues investigating.

The device Physical Memory Usage Trends

Checking the Event log

Clicking on the Logs tab displays any significant events that have been stored in the Event log on the device. Here the analyst can see that there's been one crash - which might or might not be significant, but worth noticing at least.

The device Logs

Checking the Software installed on the device

Clicking on the Software tab displays all the software reported as being installed on the device. This may be useful information in general, but doesn't show anything out of the ordinary as far as the analyst can tell.

The device Software

Further investigating the device using Explorer

Having reviewed all the information retrieved for the device by the 1E Client, a reasonable next step for the analyst is to query the device directly to get some extra info that's not captured by default. They have an idea that memory issues might be causing the slowdown and something they would like to check is what processes are running on the device.

Clicking on the Explore button in the Device details page navigates to the Explorer application, assuming that the analyst has the required Questioner and Actioner permissions. In the Explorer application the analyst can confirm that the Coverage for the question is constrained to the ACME-WIN1002 device. This means that the instruction they select will be run on that target device.

Launching Explorer to examine the device

Finding out what processes are running on the device

The analyst starts typing What proces into the search field, as they know that's involved in the instruction text. They could have typed process or processes if they were less sure and just wanted to find all the instructions related to processes.

When the list of suggested matches comes back the analyst selects: What processes are running?

Finding out what processes are running on the device

The instruction is loaded into the Explorer home. All the analyst needs to do is click Ask this question to fire it off to the selected device.

Asking What processes are running on the device

The list of running processes comes back almost immediately. 

The processes running on the device

A possible culprit process?

The analyst scrolls down through the list until they find one that might be a cause of the issue. Procmon64.exe is a good candidate as it can use up large amounts of memory and may still be running even if the front-end is not being displayed. In this instance the effect could be exaggerated by the fact that there are two copies of this process running.

Procmon64 running twice on the device

Details reveal that the process is using large amounts of memory

Clicking on the number link in the Procmon64.exe row in the results table, displays details for those results. Here the analyst can see that the pair of processes running are consuming a lot of memory. Checking with the user on the phone the analyst confirms that the Procmon interface is not visible and therefore these are just background processes that are consuming resources. Now it's time to kill the processes and hopefully return the device to its proper state.

Procmon64 using up memory

Resolving the issue

You can kill a running process from Tachyon using the Kill process(es) with image name matching... action. The analyst selects to run a Follow-up action, by clicking on the Actions tab on the results page, searching for the kill action and then filling out the image name parameter with the text Procmon64.exe.

They run the action this way because the scope has already been set to the right device.

A follow-up action to kill Procmon64

After clicking Perform this action Tachyon puts them through the authentication and approval process. First they have to confirm their credentials.

Confirming credentials

Then they have to supply the Authentication code that has been emailed to them.

Entering the authentication code

The action must then be approved by another user with Approver permissions. When all this is done, the action runs and the Procmon64.exe processes are killed on that device. Hopefully that was the cause of the problem, the analyst goes back to the user on the phone and gets them to confirm that things have improved.

In conclusion

This is a simple scenario that shows how Experience can be used to detect a problem and Explorer can be used to investigate and resolve the problem. It shows how the two applications working together can be used as part of the analyst's process for solving end-user device issues reported to the IT helpline.

After approval the action runs