Transcript
♪♪ Hello, fellow ninjas. Welcome to our Like a Ninja stream, all about leveling up your reporting. This is a different time for us, but I also have to say, we have, like, covered the global game, in the spirit of the first day of the World Cup. Go, France. We are currently coming to you from three different continents. So, I'm Robin, Community Engagement Manager for NinjaOne. I'll be basically just kind of along for the ride. I'll be asking some questions, checking in on the chat. Let us know where you're from in the chat. Make sure you throw your questions here. But I'm Robin, and I want to go around and introduce ourselves. We can start with Roy. Good. Good evening, or good afternoon, or good morning. So, fantastic to be on the stream today, Robin. Thank you very much for inviting me. So, my name is Roy. I'm the CTO at Esprit Limited, which is a mid-size MSP based in the UK. Yes, my name is Sam, or Walker, as you may know me in Discord. I am an automation engineer at an MSP here in Australia. I'm relatively new to the MSP world. I've been at the MSP for about four years, but previous to that, been in IT for about 10 years. So, yeah. We did have, or we were planning on having Josh Adcock, Mr. Slip in the Discord joining us from another time zone, but he unfortunately wasn't feeling great. So, it's a good afternoon for me in California, a good evening from Roy in Europe, and an early good morning for Sam in Australia. So, thank you guys all. Thank you to the both of you so much for joining, because I know it's kind of extreme times for both of you for different reasons, and I was amazed that we figured out a way to make this happen. And the reason why I had reached out to you both was because you both have been doing some really cool and exciting things with reporting and sharing them in the Discord. And I thought, you know, we were kind of talking about it before we went on live, is that reporting is one of those things that it's so subjective, it's so specific. You need to be making sure that you're servicing things. Every MSP internal IT organization needs to be servicing things that matter to them, but what those things are can be vastly different from organization to organization. And so, it's a constant battle in terms of product development, feature requests, and things to get that prioritization right for features. But it also makes sense, but it also is kind of mandatory for organizations to be able to get reporting that works for them that they need. And to do that, you have to be very creative. So, I wanted to start off by just asking both of you, how do you decide what reports you need? And then, how are you figuring out what needs to be included? How do you kind of start? Good question. Who wants to go first? How about you? Okay, no, that's fine. So, there's a few things to think about. So, when I'm creating a report, I break it down into five steps because I deal with lots of reporting and lots of different types of reports as well because within the MSP world, report can mean a million and one things. It could be financial sales. It could be customer-based reports. It could be reports for your engineers. It could be reports from your engineers to the execs, or it could be reports for your customer execs. So, the first thing that I want to establish when I'm creating a report of any kind is who is the report for, and what is it for, and what do they actually want? Because what an engineer's perspective is what a customer wants might be different from what the customer actually wants. So, the first thing that I want to do when I'm creating a report is talk to the customer, find out what they actually want. So, that would be my step one of creating a good report, or it might not be a customer. It might be an exec within your business. It might be a senior engineer. Talk to them and find out what they want. Next, I would probably, knowing what they actually want in a report, I would do a mock-up. So, I would forget what I know and what I don't know and go, right, I'm going to create the perfect report in Microsoft Word pretending that I've got all data imaginable. So, I would design the dream report, whether it be an HTML, PDF report, CSS report, Ninja 1 doc, design exactly what I want the output to be. And then from there, I would go, right, so that's the dream goal. And then I'll go, right, step three, what data am I going to need to make this possible? And then how can I retrieve that data, whether it be the Ninja 1 API, using the PSA system API, using the backup monitoring system API? And basically, normally, when you're trying to collect data, if there's a will, there's a way. So, work out what data I need to collect. Once I know exactly what data I need to collect, then I'm going to work out how am I going to store that data for the report. Once I've got to that point, once I've worked out, yes, I can get the data, here's how I'm going to store that. It might be a SQL database, it might even be a Ninja 1 custom field, storing the data as a JSON text file. There's the final stage, which is the fun bit, which is how am I going to transform that data from raw data into the final product, the product that I wanted in step two, when I was thinking, how do I want the data to be presented? So, how can I transform that data into a presentable way? That might be through an automation script, it might be using Ninja 1 native reporting, but that transformation is going to be, okay, now I'm going to write scripts or use a piece of software to turn that unstructured data into a structured, you know, HTML report, PDF report. What you see is what you get in Ninja 1 dashboard, which are excellent, or a Ninja 1 document, so you can have a historical view of Ninja 1 documents as you trend data over time. So, if I was planning a new report, that's the sort of methodology I'd use to go from A to B. Thanks. What about you, Sam Walker? Yeah, look, just to pretty much to echo Roy, sorry. Generally, our reports done by committee, we have feedback loops internally and they're fleshed out and discussed quite heavily. What we think from a technical perspective might be useful. Generally, it might not always translate directly well to a client. So, the client's interpretation can be quite different to what we present technically. And then there are also clients that have specific reporting requirements as well. So, it's something that's constantly evolving and it's never quite finished. We're just always reviewing and improving those reports. So, it's something that's just a living, breathing entity, effectively. That brings me to another question, which is kind of, and also Eric Tech kind of makes a joke about reports of how many reports there are. But how much time do you think that you generally will spend on reporting and compiling these reports? And then is there a number or is there a report in which you have to just kind of push back and say, I don't think the data that you're going to get from this is worth the amount of time spent to compile this? Definitely. Look, a recent example is we have a client wanting a specific report, which contains a specific metric. And ultimately, my personal opinion is that it just looks good on paper, but they might not actually really understand the technical definition of that metric. And what's the point of sharing and knowing and looking at that metric unless you truly understand what that is? So, that's somewhat of a common theme. Sometimes clients look like pretty metrics, but they don't always understand the technical calculations or working of those. So, in those cases, it is great to have a bit of a conversation and try and have a bit of a pushback because they really, truly need to understand the actions needed to take from any reporting. And so, in general, do you kind of have like a cap on like, OK, I have to compile this many reports. I have allotted this amount of time to it. And then after that, I need to go back and do the 90,000 other things that make up my job. Do you try to do that? Is your organization like open to that? And are there things that you're like, OK, I just need to figure out the best way to make this work? Generally, I think, depending on the request, we would generally review and see whether it actually provides merit or benefit to all clients. And if it is, it's something that we will then work on and to include and build out into our already native reporting. Otherwise, if it's just an ad hoc request, yeah, we try and limit, obviously, what amount of time needs to be spent because it can be generally not worth the cost benefit. Roy, is that the same for you? Yeah, well, I think so. It's interesting. So I think sometimes there is instances where we will do a bespoke report, but generally, the more bespoke you get, the less worth it is. Obviously, the one challenge with putting time into billing, sorry, time into reporting, reporting generally isn't a billable process as an MSP. So if you can limit the time you spend reporting, that's always going to be better. I tend to find, as an industry, we're getting a lot better with not over-reporting now, I would say. We definitely think everyone's starting to automate things, which is a positive. And normally what I found is the less I can have, the more reporting I can automate, the less time the engineers are spending on automating, the more time, sorry, the less time the engineers are spending on reporting or things like that, the more time they're spending on fixing things, which is probably the best utilization of that resource, should we say. Right. So I guess the next question I have is, like, reporting is important, right? And it is especially important when they, like, justify work and also to kind of show growth and show what's happening for both clients and then also executives and things. How important do you find that to be and these discussions to be in, like, having those, I'm going to say client and executive relationships? And yeah, just kind of how would you rank that importance? And for other people, how would you try to or how would you say, like, they need to really kind of invest in good reporting in order to help build those relationships? It's incredibly important, probably more important than a lot of engineers actually see on the service delivery side. And what you're presenting to the IT managers is really important. It's really important that you're reporting accurate data that's presented in a very simple and readable format for you, whether it's your end clients or your directors or your heads of departments. It really is essential because if you it seems like a basic necessity to get right. But the real risk is when you don't get it right. If you start reporting incorrect numbers or I think as the president would say, fake news, you can really deteriorate a relationship and you can really break trust just by getting your reporting wrong. So you would almost say you're reporting as an MSP. It's your bread and butter. You have to get it right. And if you don't get it right, there's going to be problems because of it, especially when people start going contractual and looking at SLAs and things aren't adding up. But that's when it can all go south if you don't get it right. Yeah, I definitely agree with that. I think it's a critical fundamental. You know, you might be providing an excellent service, but if you can't surface that in reporting to show the value that you're providing, then it's not always realised to the client. to the client. So the reports are extremely important to show the value that you're providing in the work that you're doing and you're keeping your clients protected and up to date. Yeah, especially just to add to what Sam said, because that's a really good point. In a modern world where a lot of MSPs, we're really focusing on automation and efficiency, but almost fixing problems in a way that the user doesn't even know that their devices have been fixed. It's really important to report on that and to log that. Otherwise, your customers might think you're actually doing nothing when you're doing a great job. So it's one of the classics of an MSP. Why do we need an MSP? So that's really important to explain your value as an MSP and what you're doing better than the competition. And the best way of doing it, that is through really good reporting, targeted reporting, where you're doing your exec level reports for the execs and you're doing your engineer based reporting for your IT managers. So what do you think are the biggest challenges that you're tackling with your reporting? In terms of like, these are the built in things. And that's not doing what I need it to do. So now I need to go in there and really like automate, create something that is personalized. Yeah. I mean, ultimately, there's two categories for us. It's the data collection and aggregating all the data from the different sources of systems. And then basically the data interpretation, how we present the data, what's a meaningful way to present the data. Do you show them in graphs? Do you show them in large tables? Do they want a high level summary? Do they want a detailed drill down? And deciding how to present that in an easy digestible way for clients to act on. I'm sure a client doesn't want to look at a list of 100 devices of each individual patch status against the device, but they might want to see the top five devices that are the most out of date. And they might be devices that have been retired and they need to be archived or whatnot. But it's an important decision to show, decide how to show that data. That's, I think they're the two biggest challenges. Okay. Yeah. Yeah. Data collection from a large variety of vendors is definitely a challenge. And I feel like that's always a moving goal post as an MSP, because you're always, you know, taking on new customers that have different tool sets as much as we would love for all of our customers to have a unified tool set. That's a dream goal that no one ever achieves, right? Because you bring on new customers and, you know, they happen to use a different firewall vendor that has a different cloud solution with a different set of APIs. So then you need to develop scripts to pull the data from those APIs, compile them into your preexisting reports. So being able to obtain the data from a variety of tools, as Sam said, is probably my biggest challenge and keeping up to date with it as well, making sure that nothing gets missed out, such as a new backup solution isn't missed out, et cetera. And then before we like try to go into and getting you guys to show us some of the stuff that you've done and what you've been working on and how, and the tools that you're using to like level up your reporting, just wondering to like, what was like, I guess the catalyst to get you to, I mean, Roy, you're going to show us some Power BI things, right? That dashboard, like what was the catalyst to get you to like really like dive deep into Power BI and what it could do? Same for you, Walker, like you're doing a lot of stuff with like just the API and things and PowerShell. Just kind of what got you started and going to those tools and why those, you know, work for you? I'll be brutally honest. So what got us into Power BI was a lack of native reporting within NinjaOne. So I completely understand how difficult it is for an RMM solution provider, because no matter how you set up your reporting, you're never going to appease everyone in the enterprise world, because something's not going to work for one sector, might work for another sector, or an executive dashboard might not be enough information for a certain engineer, but it might be too much information for a CFO. So I think one of the things that led to it is, okay, we use Power BI a lot for reporting on our CRM system, for example. So NinjaOne does have a fantastic set of APIs that a lot of work has gone into, so the data is there to be extracted. Power BI can extract the data, and I believe one of your architects, Andre, has done a great job of setting up a good Power BI base that connects to the API. So it's really good for community members to see how they can do that natively. So it just built from there, really, given we've already got Power BI dashboards for our CRM system, for our PSA system, that we present to our customers as well, via the Halo portal, their self-serve portal. It seemed like a no-brainer to bring NinjaOne into the fold, and then we can do cross-data analysis with alerts that come in from NinjaOne, and then time to resolution and things like that from the PSA system, and then present easy-to- digest dashboards to the customers for real-time information, and then that information can be exported separately, and then compiled into trend data over time as well. Blocker, how about you? For us, well, for me personally, I started tinkering with API reporting about four years ago, so when we moved to Ninja, it was quite a natural path for us to sort of look at the API reporting. You know, using and having access to the raw data straight from the API is excellent. Any report that you can think of, you can transform with the API, and it's, you know, it's endless, effectively. So when the native reporting doesn't quite meet the criteria, but not only that, we use, we actually have a third-party reporting, like, dashboard tool that we use, and it ingests data via CSV, or at least that's one of the options. So formatting the data in a readable way that we can translate that into graphs and whatnot is quite simple and straightforward using the API, so it's quite a natural and easy path for us. Nice. So I wanted to showcase, like, some of this, some of these comments. Dej2418 says definitely could use more out-of-the-box functionality in reporting, but has found great success in data tables, referencing, basically using custom fields, and it's been working really well for them. I do want to say, like, we do have, I should have gotten the link. I will get the link, and I'll put it in our chat, but we have a product board, so you can always request, if there is, like, out-of-the-box functionality that you're not seeing that you want, you can always request it, like we said at the top. The biggest thing is prioritization, and as Lobby had mentioned here, there is more report customization coming, and it's something that we are constantly working on, but just both things, right? So we're working on it. We understand, like, the limitations of it, but also, if there is something that you think is, like, would be very helpful, please submit it in product board, because that is the best way, and then, you know, if you're in our community, kind of try to drum up some upvotes for it, because that's the best way to really kind of get what you are looking for in front of the product team, and help them kind of figure out what they want to focus on, but that being said, and as we mentioned before, there will always be some subjective things. There will always be something that you find, like, must be done, you need it right now, that doesn't exist out-of-the-box, not just within your one, but any of your technology that you're using, and, you know, the maximum, like, I'll do it myself, fine, I'll do it myself. So, and that's really what we're here for, is the really cool, fine, I'll do it myself thing. So, I'm gonna start with you, Roy, you were talking about Power BI, and just, like, let us, like, know, kind of, what you're, you know, what you're working on, what you're showing off, and how you think that start down this path to help themselves. Excellent. So, unfortunately, I don't have anything I can actually show you today, because I don't want to expose any data that shouldn't be exposed, as I'm sure you wouldn't, your own customers, but I will, what I will say, I'll ask Robin to share this afterwards. In terms of getting started, Andre, the architect, has done a really good Power BI dashboard that connects to the Ninja One API. That, you can then, let's say, set permissions on that, so that you only show a certain customer, and then you can present that in a Halo portal, or, you know, your PSA of choice portal. You can format it to match your company's organization, and because he's already done the hard work with connecting to the Ninja One API to import the data into Power BI tables, you can also add additional fields, and then report on what you want to report, and you could even pull your custom field data out of, let's say, you've done some cool custom fields within Ninja One, to maybe look at trend data for which devices have your AV enabled, or maybe you have custom AV alerts going into your custom fields. You could then pull that information from your custom fields, and present them in Power BI using the base that Andre has already set up. So, I'd say, use that Power BI dashboard as your base, if you've got the licenses for it, and then add to it in a way that customizes it for your organization, which, like I say, super easy to do, because most of the work has already been done there. Like I say, the good thing about Power BI, as well, you can present these dashboards as HTML files, wherever you want, in any portal you've got. So, I definitely recommend that. Yeah, that's the product board. I'm still looking for the link that you gave me. I'll get it up there, though. I should have put these in a separate spot. I live in Discord, which sometimes can be a hassle. I wanted to see if you could walk us through this data flow to start with, and then we can look at some other stuff. But, just kind of, this is a screenshot that you'd shared, and just kind of walk us through what this thought process is. Excellent. So, one of the reasons I uploaded this data flow is more to talk about data flows and on this specific data flow. Now, whenever I'm doing maybe an automated report pack or a more complex report, I think it's really good to start with a data flow, so that you can plan out what you're doing, and then you work from the data flow. That way, you'll always have a point A reference to go back to, in terms of what you're achieving. So, what we've got here, specifically, is a server utilization reporting pack. Now, one of the things at Esprit that our service delivery managers really wanted, that Ninja One Native reporting couldn't do, is trend data on a per month basis for server utilization, including availability and including IOPS. So, what we've got here is a pack that I put together that creates a organizational level dashboard to show your server organization resource utilization, a device level dashboard, and also it logs your monthly snapshot of the resource utilization of your servers over a month in the Ninja One documentation, which utilizes a really useful module created by Luke Whitlock, I think, actually. That's really good. So, this pack that I've essentially uploaded into the script share should allow you to do that, but the reason I uploaded this one specifically was because I thought maybe it's a good one for people to take apart, steal some of the PowerShell functions, look at how I've connected to the API, look at how I've used the text custom fields in Ninja One to store JSON data, and then this data flow just explains how it all works. So, you've got three scripts, one to run at the device level, one to run at the org level, which hopefully you would run on a secure API server that pumps the data into the dashboards, and then a script that does the uptime, although I must say the uptime script, while it looks pretty, I'm still working on making it a bit more accurate. It's based on Event Viewer. It's based on event viewer logs at the moment. But for it to work properly, you need to make sure your event viewer buffer is set to 256 meg or above, otherwise you won't get an accurate reading. So yeah, that's what this data flow is all about. But the main point that I wanted with it is if you're gonna do an in-depth report and you're not sure where to start, start with a data flow, map how your data flow is gonna look, and then you can build your report from there and you won't get lost, if that makes sense. Yeah, it really does. And Walker, you also had a data flow. I'm trying to find that too. No. Here we go. So the data flow that you kind of start with as well, Yeah, correct. So something that was sort of quite apparent early on in our reporting was that we didn't want to constantly pull down the API live in each and every report because that would basically be duplicated across different reports. So instead of doing the live API call in the report itself, we have a data orchestrator that looks at a manifest file and decides how frequently those API endpoints need to download. So for example, we might download the devices data set every 15 minutes, and we might download the organization data set, say every hour. And then effectively separate to that is our report generation. So those reports will pull those cached API responses and generate the reports directly from that. So we have a script that runs about every 15 minutes. It passes the manifest file to see how often those data sets are expected. And then it looks at a second file to see the last run time, whether it was successful, whether there was any errors, which then feeds into reporting and logging to see, alert us to if there's any failures. But this model, I think, is probably the smart way to do it because it means that you're not gonna hit API throttling limits. It's a central way to configure the frequency and the freshness of the API data rather than having to duplicate and basically repeat logic in multiple different reports. And then all your reports are worried about is picking up those JSON files or to generate the reports from. So that's our API workflow. The other thing is obviously it's probably quite important to use a PowerShell module. We rewrote our own PowerShell module for Ninja, but MyIKEY does have one published, which is perfectly fine and probably better to use than mine. So I think that's an important step of PowerShell automation. Okay, so we're gonna go back to Roy and just kind of, oh, that's your data flow, sorry. Talk us through some of these and what we're working on and what we're trying to get, like what are the words? Now within Ninja 1, I'm a huge fan of the what you see is what you get dashboards. And we'll call this as a type of report that's targeted towards our internal engineers more so than a customer-facing report. But the data nonetheless is really useful. So I use these kinds of dashboards for things like in-depth vulnerability reporting. So I can see which vulnerabilities have been publicly exploited, things like that. For a custom Sophos integration that I've built, all kinds of things. It's probably my favorite feature within Ninja 1. So if you haven't used these kinds of dashboards within Ninja 1, definitely have a play because they are excellent. So this one in particular, it's part of the script that I shared earlier within the community Discord channel. This one is to give you trend data for the last report month. So you'll see here, we've got our dev environment and we've got the report period set to May, 2026. And this provides information on your average CPU, your peak CPU, your average memory, your memory peak and your DevOps as well. I found this particularly useful for Azure-based servers. If you want to right-size your Azure-based servers, make sure that you can just quickly check if you need to upsize a VM or downsize a VM. And other than that, it's just, you know, it was a nice dashboard for me to play with and learn the CSS functionality and limitations within Ninja 1. So again, this is available publicly on the Discord if you want to have a play with it, break it, fix it, make it better or use some of the functions. This does use the Ninja 1 API to write back to Ninja 1, if that makes sense. So I pulled the information from Ninja 1, store it in custom fields, then push it back to Ninja 1 via the API. So that's an organizational level dashboard. And then there's a device level dashboard as well, which Robin, are you all right to flip to the device level dashboard? So... What you can do from that organizational level dashboard, oh, no, back, there we go. Yeah, from the organizational level dashboard that I showed you earlier, you can click on any of those links and it will dynamically take you to the Ninja 1 device. And then from the Ninja 1 device, you've got this device level metrics report, which will give you some trend data of your CPU average in percentage, CPU max as well, and your memory average max. Just gives you a quick highlight of the server, the server health, where the average is at, and the same with the IOPS. I can see, you could argue that, maybe the CPU is a bit redundant, cause that is available for the Ninja 1 native tools. But I like this cause it gives me the full month report, whereas in Ninja 1, you can see the last 30 days and you can't do the calculations on it. This gives you the IOPS as well, which is really useful. It gets the data from a collector script that uses perfmon under the hood to obtain the IOPS and it runs for 60 seconds every hour, but they're adjustable variables in the script. So again, I know I've over-engineered it a little bit, but I thought it'd be a good script to share because it's got a bit of everything. So people can take it apart and steal the functions that they want from it. Nice. And then can you walk us through this one here? Yeah, so again, it's part of the same script pack. So once it's set up, this just all works and runs every month in theory. And this is using Ninja 1 native documentation. Again, a bit of thanks to Luke who done a good module and he's been a good guide on how to automate the process of uploading information to Ninja 1 docs. This is that same information that we saw on the org-level dashboard, but you just get a screenshot of it, essentially, well not a screenshot, a capture of that data and that gets sent to Ninja 1 documentation at the end of every month when the scheduled task runs and it's there forever then. So if you wanted to say, oh, has the utilization on this server increased over the last year? You could flip through that server utilization report if you wanted. The main reason though was more because I just wanted to play with Ninja documentation, seeing what I can do with it and how the CSS limitations translate into the documentation. Nice. So these are all done. Well, it's one script pack that you think, like you've shared, so if you're in our Discord and I can put the QR code on the corner here, just so you guys, if you're not in our Discord, you can scan that QR code that just popped up and join our Discord. We have a script share channel where a lot of people will join and put in self-created scripts. That's not the right term for it, but like, share the scripts that they're using, share what they're useful for, and you can kind of like, the very great jumping off point, starting point for a lot of users. I think the question that I have though is so you're using these and then the goal is now, once this has all been set up to your specifications, you're happy with it, then you just are running it on a monthly cadence, right? You're not having to really kind of go, I mean, how often do you think you're really like going in there and changing certain things around or is it basically like, now that we've got this and we're happy with it and it's tailored to what our particular needs are, just to make sure that we run it monthly, bi-monthly, whatever. Yeah, I mean, this is completely hands-off now. I've got a scheduled task that runs within Ninja One, runs a script, generates this information and I don't touch it. It's just useful information for the service delivery team that we've got here at Esprit to monitor the health state at a quick glance for their customers. I would treat this as maybe more an internal-facing reporting than external-facing reporting, but still very useful nonetheless and this is set and forget. What I do for customer-facing is the same set of data, the same JSON fields that are read from this information also go towards creating a more customer-friendly looking PDF report that gets added to their server pack, but unfortunately with that being branded to our MSP, I wouldn't be able to share that. Yeah, but it is that you're kind of taking this same idea and then using this data and this information and packaging it so that it makes sense for a customer-facing. And what is like your kind of response from your customers when you're giving these reports? Is it very clear and they like expect it the same way automated, it just gets shipped to them monthly, bimonthly? Yeah, I mean, the actual customer reports look fairly different to that and there may be a bit more comprehensive in certain aspects, less comprehensive in other aspects with them being customer-facing. But what I think the customers really like is when they get automated reports that are point-in-time shots, especially with the patching, which I think Sam will come on to in a minute. The one good thing with automated patch reporting is a customer knows that they're 100% accurate. So they're getting accurate reports on their device state and there's no middle faffing with manual Excel imports or faffing with getting information from tickets of what you had. So Chinese whisper reporting essentially. The customer is getting accurate data presented in a nice, healthy way. So that's something that's important to consider. Any questions from the audience about what Roy shared? Let us know. We can always come back to this. I'm trying to look now if there's anything that we haven't kind of touched on, I think. Just so you guys know, I'm not responding to some of these, but I think that some of these questions are more geared to actual Ninja staff. So that's why we're not gonna kind of, I'll make sure to like internally share these comments to Ninja staff. But right now, since we're talking with two customers who are grateful enough to like share, I'm not gonna touch those. Oh, here we go. Kaner asks, start to finish, how long would it take to get started if you've never messed with API at all? That's a great question. Look, my advice would probably just start small. There are already some API scripts shared in the Discord. You could start there. You can look at how the PowerShell module comes together or the script comes together. And it will give you a bit of a base and fundamental understanding of how the pieces come together. And then from there, I would probably just start to slowly tack on or have a specific goal or project that you wanna work on with anything, with all IT projects, it's always iterative. It's something that you constantly build on. You'll find problems or issues down the line. It's not gonna be perfect straight away, but that's just part of the process. That's where everyone starts. It's fun. You get to put something in what you think looks great. I would just take a stab at it and have some fun with it. I would just take a stab at it. I want to also add too that as someone who is completely... As much time as it's been in the Discord, I struggle sometimes understanding what is being said because I am not technical. I can clearly tell that the people who spend a lot of time in the API channel and in that scripting and general chat, review my script, script share, they're some of the most technically savvy and eager to talk about what they're doing and working on. I would also say that if you're starting, I would have that Discord up and open and ask a lot of questions. Yeah, there's definitely people in there who are keen to help you and keen to share and knowledge share. It's a great resource for sure. So we also have this question from Bullfrog Slam. He also put this in the Discord. So I'd let him know that we can speak to it a little bit more expansively in Discord. But how, if possible, do you report on deferral counts accepted when a fourth reboot takes over to have data behind the patch mechanisms? I would say for the sake of time and stuff, how would you just kind of start to approach that if you guys could answer that, if you're able. If you're not, that's fine. We can take it. I'm not quite sure I understand the question. I think they're asking how many times the user has clicked on defer this update. I'm not sure that you might be able to do something through the activity log. I know Robert has an activity tool that he shared in Discord. You might be able to leverage that and pull those activities from that perspective. Yeah. Okay, I will follow up on that for you guys and let us know if that touches the surface, but we can follow up in Discord for that. This question from the Lily Herold is kind of more for me. So you can host scripts also in the dojos. We do have in the community portion of the dojo, we have a community. We also have a script share. I personally think that the Discord just happens to be more active and we get more scripts submitted there than we do on the dojo. The biggest thing about this is because these are customer created scripts and things, they won't be in the template library, for example, because all of those templates have been written or confirmed and have kind of the Ninja One stamp on them. And then there's also just gets into a lot of data, privacy, security kind of concerns. So we've kind of taken the approach of letting people post where they are most comfortable. And I really wish, and I'm always looking, so please also you can, you know, look, I'm on the dojo as well. You can add me, message me. I don't know how that, or you can just email me. But I'm always looking for suggestions on how to make a place that is a little bit more accessible for everyone. But we've kind of just at this point have taken the route of let people post where they're most comfortable and then let people find it and use it where they're most comfortable. So that's why, especially when it comes to community hosted script shares, there's a space in both for whichever platform that you prefer. So, yeah. And okay. So Walker, let's see, can you walk us through the, I'll start with this patch table. Kind of what you're going through and what you're trying to. Yeah, sure. So I think pretty much with most patch reporting systems, they generally use the device as the source of truth. And the problem with that is that if the updates are broken on the device for whatever reason, you can get a false positive. It can appear that the device is up to date or that no updates are available. So we really wanted a robust centralized source of truth. So what we did is we pulled down all of the device data from the API, the organizations, the locations and whatnot to generate a comprehensive device list. We also pulled down custom field data where we are storing the Windows build version, which you can see in one of those columns there. And so the Windows build version can actually be used to cross check against Microsoft what version of Windows or, you know, what release or what build of Windows it's running. And there's actually an API that you can check up on. It's called Data for Nerds and they publish a list of all of the builds and the date that were released. So by cross referencing that build number against that list, which is scraped from Microsoft, you can actually determine how old or how many days ago that patch was released. So we split the devices into three categories. So recent, out of date and high risk. Something like recent is every 30 days. Out of date is under 65 and high risk is above that. But by doing this, it's just a much more reliable and accurate way of reporting the device's patch compliance. So that's something that we've been working on for quite a while and it's sort of really only just come to finalization in the last couple of months. But we're really quite happy with how that's come together. Great. And then let's look at this dashboard. I love the dashboard. Even when I don't understand the dashboard a lot, there's something about the charts and graphs that just really tickles my brain in the best way. Yeah, this is effectively a summarization of that table. So instead of showing it in a drill down format, we're just sort of grouping these together. So we break it down by workstations or servers. And as you can see, it's broken down by the recent, out of date, high risk or even unknown. But they're basically the calculations of whether it's under 30 days, between 30 and 60 or above. But this is a really great way of using a complete accurate list to determine device patch health. Yeah. And it just, and it looks great. Yes, this has been a very, very significant amount of work. Yeah. When you say it's been a significant amount of work, I'm wondering, is it more about getting it to this, like the data's there, right? It's what we talked about, but it's more about like how you're displaying it. Did that take a long time to get to where you're really comfortable with? And what kind of were your steps and feedback loops to get there? Look, so originally we had the PowerShell API, and we were using that to generate the CSV data, which was then used to upload into a third party reporting tool. So this tool that we're looking at here is something that we're planning to migrate to, to replace that. So this is something that is not technically PowerShell, but it is using the API. I see a question there. What's software service? It's a React front end and with a Postgres SQL backend. The technical challenge with this is this is actually something that's automatically pulling through the APIs. So it's just tying that all together and building the tool, something that I haven't done, but relying heavily on vibe coding to pull this together. And then we have this final report. I don't know if you guys can see this, or the default fields. Can you kind of explain what we're looking at here? Yeah, so this is a script that's available in the Discord. It's just a really solid way to get the device lifecycle, like the OS lifecycle. So different releases of Windows, so like 23H2, 24H2, have different end-of-lives to just say Windows 11 itself. So this script will query end-of-life API and basically detect if the device is running on an end-of-life. This is what you see, what you get field, but the script can populate basically all of these data into their own custom fields, which can be used to generate conditions and to tell you how you've got devices that are end-of-life or coming up to end-of-life. So it's a neat little script. I love that. OK, we're coming up kind of on time. First off, thank you guys both for sharing those. And then again, if you're in our Discord, you can see if he's in our Dojo. I'm not 100% sure, but Josh Adcock also was doing some really cool things with Grafana that he wanted to share with us, but unfortunately, he's under the weather, so he couldn't join us. But we're always talking about these things in the community. If you have any final questions, please throw them in the chat. We're about to log off. But I have one kind of final thing of how important is custom fields in all of this? And how are you guys really kind of making sure that between the APIs, that the data is there first and correct and well documented and managed? How important is that? And then how are you making sure that everyone is on the same page with that? I think custom fields are critical to Ninja 1. They allow you to store data that's important to you, that's not natively out of the box. And I think that's, to me, that's the correct approach. I think everyone will always have their own subjective opinion on how things should appear or how they should be Sometimes it is a little bit of work, obviously. But once you get to the point of maturity and you have that data, it's excellent. So, for example, that script that we were looking at there, we have a Boolean true, false, is device end of life, which was then passed into that dashboard that you looked at there before. So I think everyone should be throwing themselves at custom fields and trying to get as much information into those. And I'd highly encourage it. I've seen sometimes people aren't so keen, but I think it's very important that you get your head around that and get enthusiastic about it. OK, coming up on time, is there anything else that you guys want to make sure that we mention or anything else that I should throw or make sure that we all, everyone on the stream knows? No, I think what Sam said is definitely right. When you get custom fields are great. And the more you do, the more beneficial they are because you can start to link them, especially in how we link Ninja One to our PSA system. We're able to do a lot of relationships by adding custom fields in the PSA system that link to custom fields in Ninja One, et cetera, et cetera, which makes it really powerful because you can store data in Ninja One from your PSA system and vice versa. And you really can make Ninja One your single source of truth, which is definitely a unique selling point. So yeah, totally with Sam there, use your custom fields. Yeah. I personally am very biased and say, yes, join the Discord. If you don't like Discord, that's also totally fine. We continue to do streams like this. We do have the Dojo. And like I said, reach out, talk to your account managers, ask them, hey, that Robin girl on community, how do I get in touch with her? They'll link us and we can figure some other things out. I don't, I personally think Community is what you make it, so I'm here to help any way I I personally think community is what you make it. So yeah. can. But I want to thank you guys again for waking up really early and staying up really, staying up, not staying up late, but like, you know, staying online late, taking this time to like really walk through this exciting things. And also, I want to thank you guys just for sharing this stuff. Like, like I said at the top, like, you're sharing this stuff, I'm seeing like, oh, this is really cool, conversations are happening. And then we end up here talking about it on stream. So just that kind of Community is what I think makes the Ninja One Community so special and amazing. And that like, willingness to share and like help other people get better is just top notch. So thank you guys again, thank everyone who joined us at whatever time and whatever continent you're on. This, I think, was our first tri-continent stream, and I'm very, very proud to say that we did it. You guys should have seen our, our trying to figure out the timing, it was nice, nicely done. So yeah, and we will see you guys next, 14.0 is coming out quicker than you'd expect. So see some fun stuff from us from there. And yeah, we will see you on the internet. Bye guys. Thanks. Bye.
