The use cases are based on transformation projects. For example, if clients are trying to implement some new deployments in SCCM, they use this solution and we help them with the migration. We are currently helping with a Windows 10 migration. Clients use it for application and system crashes in order to maintain the compliance status for their business applications.
On individual machines, we can see the performance and what is going wrong as well as what can be improved in order to enhance the performance of the machine. This is very useful when we get any queries from a VIP user or someone from our project's top management. So if they get into any trouble, then we are able to fix it as soon as possible. Because if an agent is unable to work for two hours or even for two days, that won't make much big of an impact. Whereas, if someone from higher management is unable to work on the system for about two hours, then they would lose a lot.
Initially, we were just looking at it in order to maintain compliances, and we were using it only for that. The guy managing this tool before me was more or less concentrated on device compliances. Later on, we started getting into the application and system crashes (when I started).
In our environment, we need to put a proxy server in place. Currently, devices are connected via the corporate network or the VPN. We don't have machines reporting from the open network. This is something that we are working on. Once that is in place, we will get all the machines reporting in our environment.
In the past two years, the biggest benefit is that we have been able to identify 57,000-plus defects. These are possible tickets that we are preventing by using Nexthink.
On a weekly basis, we monitor the trend, then based on the trend and wherever we see a downfall on the performance grid, we just deep dive into it. We look into what is wrong, then proceed with remediation. We access the output weekly, not in real-time.
There have been some system crashes. We have a dashboard for the blue screen of that. On the dashboard, it is usually a wave type of graph, but I saw depth in it during the weekday. So, we investigated into this and got to know that DLP client was crashing. This was causing the BSODs on the machines. So, we were able to bring it into action within three days. Then, within seven days, the ones which had already crashed were all fixed. Nexthink also helped us in preventing the rest of the machines from using the same version of DLP client, since that version was crashing. The version was the cause for the BSODs. Therefore, the deployment teams went ahead and downgraded the version of the DLP client. When there was an upgrade available, they were upgraded. This helped us in avoiding 30,000-plus tickets or being contacted from end users.
It has helped us in proactive prevention. There was this investigation done for device login time, which was quite high and they were taking a lot of time when logging in. In total, 6,567 were affected by this and we were able to fix the problems for approximately 5,900-plus machines. Those machines do not need to be replaced now, since the performance is better. However, the rest need to be refreshed or replaced. Overall, this provides cost savings.
It is being used by our asset management team. We gave them access to the dashboards. We also created some custom dashboards for them where they could look at the performance of the machines. Based on that, they do a comparison with the list that they have available for the refresh. If they see there is a machine on their list for a refresh view, then they look at our data and the machine is performing quite well, it is best that they don't refresh that machine at that particular time. Instead they put it on another machine, which is in our list, but not on theirs. This way, it is helping both sides.