Episode 306: Filewave APIs with Josh Levitsky

---

This week’s transcription is brought to you by Alectrona

James Smith:
This week’s episode of the Mac Admins Podcast is brought to you by Kandji. Did you know that you can fine tune how Kandji manages your OS updates? With Kandji, you can either select a minimum version of the operating system for basic enforcement, or you can set OS updates to be automatically enforced after they’re released. You can also specify the amount of time Kandji waits before enforcing a new update. With Kandji’s automation-focused device management platform, it’ll begin prompting users to upgrade days before the enforced deadline. There’s a lot more nuance to creating a seamless user experience with OS upgrades than we can cover in this snippet. So if you want to check that out firsthand, head on over to kandji.io/macadmins and just request access. That’s K-A-N-D-J-I.io/macadmins. Thanks to Kandji for sponsoring this episode of the Mac Admins podcast.

Tom Bridge:
Hello and welcome to the Mac Admins Podcast. I’m your host, Tom Bridge, and Marcus, I’m going to see you in just a couple of weeks. How are you doing?

Marcus Ransom:
I’m doing really well. I’m looking forward to seeing you too, Tom. I think I mentioned to a few people online, but I had a really awesome experience on Saturday night. My youngest daughter had her first group music performance as part of an orchestra, doing something that reminded me of you. I thought of you when we were watching this. So her first orchestra performance in the percussion was in fact doing Orff’s Carmina Burana O Fortuna.

Tom Bridge:
Yes.

Marcus Ransom:
And she got to play the bass drum and the timpani for the big boom, boom, boom, boom, boom. And there were gongs going off and everything. But as someone who was a singer in a previous career, would we call it, I thought of you straight away. And I thought what a way to start your love of performing music with other people.

Tom Bridge:
Yeah. Well, Orff’s work there is phenomenal. And it’s more than just the O Fortuna. The O Fortuna is how it starts and how it ends, and there’s a whole bunch of other stuff in the middle there. It’s a really phenomenal piece of music that I really encourage people to go and find. There’s a Latin bar drinking song that is so fast, it is almost a patter song. So I will find a link. I will throw it in the show notes. It’s excellent and amazing. And it’s so much fun to do from the choral perspective, especially because you get this double orchestra in front of you. It’s a really lush arrangement of the piece. It’s a lot of fun. I’m so glad that your daughter got to do that.

Marcus Ransom:
Yeah. And she’s just moving on to what she’s going to do next now.

Tom Bridge:
Nice.

Marcus Ransom:
And with percussion, there’s lots of next.

Tom Bridge:
Yes. I’m just going to say, you know, you eventually learn to play the marimba and a bunch of other really fun instruments as part of that. So Charles, how are you?

Charles Edge:
I’m great. I mean, you had me at Latin, you had me at beer.

Tom Bridge:
Yeah.

Charles Edge:
You had me at lush. I can’t even connect all of these properly. I mean, it’s snowing outside and it will be for the next, I think, 10 hours according to the last time I looked at the weather. And it’s that wet heavy snow that the snowboard just can’t touch, and you’d just be moving slush around at that point. But yeah. And I’m excited to talk about APIs. But first, how are you, Tom?

Tom Bridge:
I’m pretty great. We’ve hit March, and so March is where my brain starts waking up again after a long winter’s nap. I don’t do lack of sunlight terribly well. And so now we are past the point where it’s after 6:00 PM when the sun goes to bed and it’s before 7:00 AM when the sun gets up. So I am enjoying my return to functionality, for you I think that is probably the best way to phrase it. And we spent a great weekend here, hanging out with friends and going outside and doing fun stuff. And it’s not warm yet, but it’s certainly warmer. And I will take that.

Charles Edge:
Yeah, it’s not warmer here.

Tom Bridge:
Regrets, sorry.

Charles Edge:
I mean, it’s a little bit warmer because it’s warm enough to snow.

Tom Bridge:
Yes.

Charles Edge:
Because that’s a thing.

Tom Bridge:
Yeah.

Charles Edge:
And I do have to say, Marcus, as a former or current-ish percussionist, those bass drums and timpani’s are totally gateway drugs.

Tom Bridge:
Oh, yeah.

Charles Edge:
The next thing you’re playing the snare, you’re playing cymbals, you’re playing the toms. And then you’ve got a drum set and then your parents are ripping their hair out or whatever’s left of it.

Marcus Ransom:
We’ve already got the drum set. She was looking lovingly at the gong.

Tom Bridge:
Oh, yeah.

Charles Edge:
Yeah.

Marcus Ransom:
We may have to find a room for the gong in the house.

Charles Edge:
Then she could have a career in sales because every sales team needs a gong. And speaking of go to market teams, here at the Mac Admins Podcast, we love APIs. It tells us a little about products and a lot about how various vendors feel about structured automation, much as percussion teaches us about structured rhythm. I don’t know. In today’s episode, we’ll chat about the FileWave API. We haven’t talked that much about FileWave on the pod, regrettably. What can be done, what can’t, and of course, some cool uses in a new age of AI for everything. Our guest is Josh, Global Head of Pro Services at FileWave, who, lucky for him, gets to tinker with the FileWave APIs often. So Josh, before we start, we love to get an origin story from guests. Do you mind telling us how you got to be the Global Head of Pro Services and Training at FileWave and what that entails? And also welcome to the pod.

Josh Levitsky:
Thanks. Thanks. Yeah. Yeah, so it’s a bit of a long story, but it kind of started back in 1998. I worked at Time Inc., which is a child company of Time Warner, published magazines. I ran desktop engineering with Tony Keller, Tony Keller’s also at FileWave. So Tony and I started desktop engineering at Time Inc., back in ’98. We left Time Inc., well he left before me, but I left in 2013, and I went to Absolute Software. They had, you guys probably heard of LANrev or Absolute Manage, same product. And I went there because I was a LANrev customer. And Absolute bought LANrev, it became Absolute Manage, and I was at Absolute. And then I brought Tony over to Absolute.
And I stayed at Absolute after they got rid of LANrev. And I’ve always been in contact with Tony and there was a spot open at FileWave to do professional services. I was doing professional services at Absolute for eight years. And so it just kind of fit because I always did client management. Tony and I took care of desktop engineering at Time Inc. and I love desktop management. It’s a lot of fun for me to support companies in supporting their devices.

Charles Edge:
That’s a great origin story. And I especially love any origin story that starts with pro services or has pro services in it at any point because I do feel like whether it’s consulting or pro services within a company, so consulting inside of a software company, that exposure that you get to hundreds and potentially hundreds and hundreds of customers is just, it’s unmistakable the way that people kind of take that back to the software tools themselves, I guess. If that makes sense. I mean, Tom, you are a perfect example of that in the product space, right?

Tom Bridge:
Well, sure. And I was going to say, spent a long time in what amounted to pro services just on a more consulting basis and now I spend my time on the product side of the house. So it’s fantastic to see many different kinds of ways of handling it. What kind of fun challenges did you guys have at Time?

Josh Levitsky:
Well, Time was about 50/50 on Mac versus Windows. And there was always this argument about which one’s better, which one’s cheaper. We did a total cost of ownership study that probably cost a lot of money only to find out that basically you use the right tool for the right problem. So it made sense to have both platforms. So it was mostly the multi-platform aspect, that was the most complicated. And we had a lot of artists, writers and photographers and such that we were supporting. And they don’t like rules so much. They want to just get their stuff done. And so saying that you can’t be an administrator of your machine is not always taken so well. It would be bad if a Sports Illustrated issue about the Super Bowl didn’t get published because we had something that blocked somebody from finishing their work. So that was always the fear, that we would cause a magazine not to be published, especially a weekly magazine.

Tom Bridge:
When the timelines are tight like that, that’s got to be a high stress environment too.

Josh Levitsky:
Yeah, yeah. And we were in central IT. So all the magazines of Time Inc. were really sort of under us as far as technology and architecture. And so yes, it was constant stress, but there were nice rewards. In 2002, I went to the Winter Olympics, a free trip.

Tom Bridge:
Oh, wow.

Josh Levitsky:
Yeah. It was really cool. It was actually after 9/11, it was right after 9/11. I had said, “I’m not going to fly anywhere.” And then they said, “Well, there’s this trip to the Olympics.” And I was like, “Yeah, I can get past my fear.” So I went to, I got to…

Marcus Ransom:
Where were the Winter Olympics that year?

Tom Bridge:
Salt Lake City, yeah?

Josh Levitsky:
That was in Salt Lake City.

Tom Bridge:
Yeah.

Josh Levitsky:
It was really great. I am glad that I did not pass that up. On 9/11, I was actually at the Trade Center because I also was a volunteer EMT in New York. So I definitely was afraid of flying, but I was super happy that I went to the Olympics.

Charles Edge:
I happened to live in Athens, Georgia when the Summer Olympics came to Atlanta. And what a special, I mean, there’s just nothing that I can think of that compares, maybe the Super Bowl, but on a much shorter and weirder kind of timeline, to having the Olympics in your city. It’s just, and Athens is adjacent to Atlanta, but less than an hour and there were a boatload of events. And watching that Olympics’ money kind of transform, whether it was streams for different kayaking events or the University of Georgia football stadium for soccer events or football, according to what country you’re in. But it was just, what a special kind of thing. I do love, I had never really watched the Olympics before that, but now I do. It’s just awesome.

Josh Levitsky:
Yeah. It was really special. And actually before the Salt Lake City Olympics started, I got to go there the week before and help Sports Illustrated set up all their equipment. So that was fun too, because I got the behind the scenes stuff too. And then when I got to actually go to the Olympics as a visitor, it was like the VIP. It was great.

Marcus Ransom:
Still a lot of wet paint and wet cement on things a week beforehand, I’m imagining.

Josh Levitsky:
Yeah. It’s just really setting up all the gear, making sure everything works flawlessly. It was fun and stressful in equal parts.

Charles Edge:
Like a massive scale of what Tom went through with the, what’s name of the place that you worked with?

Tom Bridge:
Oh, the Anthem. Yeah.

Charles Edge:
Yeah.

Tom Bridge:
And I was going to say, in the larger version of the single day Foo Fighter show on July 4th in 2015 or whatever, where we had RFK for the week and so we had to make it exist from being a stadium built in 1958 all the way through to being something that could be useful in 2016 for a concert with a network backstage and point of sale for 65, 70,000 people.

Charles Edge:
And you know what else is a big lift? Software. Transitioning into the point of this episode. I do feel like when I first started working with FileWave, it was a client that ran on the actual server and then you could have little booster servers, but they ran the client that connected to the booster that then connected back to the server. But that transitioned to a client app that talked to an API on a server. So I guess, when we dig into looking at APIs, that first thing that we have to figure out is how authentication works and how we can actually talk to the API. So those can be tokens, they can be OAuth, which is token-ish, token adjacent. But how does FileWave authentication work for the API?

Josh Levitsky:
Sure. So it really is a token. And there are sort of two avenues to get to the server. The way the client does it is kind of the old way, and then there’s sort of a newer API that you would access. And the way to think of it is that the classic admin application that you run on your machine does it the old way, we have a web interface that does all the new APIs. And so basically, anything that you can do in the web, you can do in API because the web has to use APIs to do those things itself.

Charles Edge:
And do I remember that it’s running not flask, but Visual J or something like, what’s it running on the back end?

Josh Levitsky:
Well, there’s a couple of things that come to mind, like Django.

Charles Edge:
Yeah, Django, sorry.

Josh Levitsky:
OK.

Charles Edge:
Not Visual J.

Josh Levitsky:
That’s what you were thinking of. OK. Yeah.

Charles Edge:
I knew there was a J in there.

Marcus Ransom:
Even if it’s behind a D, just to confuse you.

Charles Edge:
Yeah, and I do feel like that dual API thing is something that a lot of vendors deal with where there’s a legacy, an older API, and then there’s a newer API that’s kind of more API first-ish. So it’s a token on the backend, and then that older API, is that task-based or the newer one even? Or does it provide access to everything that’s available in the GUI and more?

Josh Levitsky:
Sure. So the older one, well, let’s talk more about the newer one because the newer one is straightforward because, although I know a bit about the old one, the new one is really the future. And in fact, even that native admin is going to start using the newer API for things. Because why in reinvent the wheel twice? Right? We shouldn’t have to keep building in the old in the new. So really, as I understand it, we’re going to just build in the new, and the new is that API token. It’s not necessarily task-based, it’s really, well, it’s specific commands of things. If you want to put a device into a group and you would be able to do that in the web admin, there’s an API to put a device by device ID into a group by the group number. If you want to wipe a device, well, that’s a command. There’s not a workflow that you would pass it through. It’s kind of the individual commands that you would chain together into what you want to do. I think I answered that. Right?

Charles Edge:
Oh yeah, totally. And this is probably totally off-topic, and I think most programmers when they hear me ask this question will want to throw something at me, but Django is just serving up Python scripts effectively, and those Python types can be called directly. Is that something that you’ve experimented with or do you try to stick to just using the API itself?

Josh Levitsky:
I try, well, we also have, one of the reasons we have two things, the old and the new, is because FileWave has been around for a very long time, decades. And I force myself where possible to just stick to the new APIs because we’ve also had this push towards SaaS, encouraging customers not to run the FileWave server on premise where possible because we don’t offer direct access to your hosted server. And in generation one, a hosted server is basically a CentOS box running in Amazon Web Services. So it’s like your computer’s just running into Amazon’s cloud. But gen two is all the Dockers, Kubernetes stuff and separating everything out, and there’s not going to probably be direct access. So we really have to make the API able to do everything you need to do. So I force myself wherever I’m possible to avoid doing commands that can’t be done through the API. And I’ll nag development and I’ll say, “Hey, I really need to do this.” And then hopefully that could get into the future API versions.

Marcus Ransom:
It’s a good work flow to get into, to try and limit the amount of personal technical debt you’re accruing when you’re doing things like that, on top of whatever technical debt the platforms you’re working with have accrued over the decades.

Josh Levitsky:
Yes.

Charles Edge:
I love that perspective. And for perspective, for the listeners who might not have used fileWave, it was one of the first, maybe the second, of all of the management tools that I came in contact with. I think it was, I think they can claim founding in 1992. Which for perspective, Kurt Cobain was alive. That was quite some time ago. Flannel was great. I mean, flannel is still great. But anyways, it’s always interesting to see a company who’s reinvented the technical stack three, four, five different times because I think the only one that predates FileWave was really NET Octopus, if I’m not mistaken.

Josh Levitsky:
Well, and the funny thing is NET Octopus was made by Martin Bestmann, who later went on to make LANrev, really. LANrev was, and I was a NET Octopus customer. I was a Timbuktu customer.

Tom Bridge:
Timbuktu is a name I haven’t heard in a long time.

Charles Edge:
Right.

Tom Bridge:
I love Timbuktu. That was a great piece of software.

Josh Levitsky:
And Netopia was a good time. And they made both NET Octopus and Timbuktu. And LANrev, well, we followed Martin Bestmann, basically. He’s one of the smartest people on the earth, I think.

Charles Edge:
I’m lucky enough to gotten to work with him quite a bit and I’m very fond of him. Those Germans. The great thing about APIs is that they tend to pave the way for third party integrations. And not just that, but people to do anything they want with software, not just what the developers had in mind, which can sometimes anger developers. But at this point in my career, I’m always happy and feel validated when I anger developers. So, all good. But what kinds of things does the Incident IQ integration do, just to kind of jump into one of them specifically?

Josh Levitsky:
Sure. So Incident IQ, actually, this was a case where they had a customer, and for anyone that doesn’t know, Incident IQ was a ticket system. So they had a customer that was a FileWave customer that wanted something to tie the data together. So that in their ticket system, when Jimmy opens a ticket about his machine, you know in the ticket which machine is his and some details. And so in Incident IQ, when you look at devices that could have tickets, all the device data’s in there. It syncs over inventory information like what OS is on the device, how much RAM is on the device.
And they do a neat thing, where they actually sync, we have these fields called custom fields. You can extend the product and make fields for whatever you want, department. For Mac or Windows, you can have it run scripts and the output can be in a field. So in Incident IQ, these fields can sync from FileWave into Incident IQ. Or if Incident IQ is sort of your source of truth, you can have that sink into FileWave. So it’s pretty powerful, I think, the ability to have that information in your ticket system. Especially if your organization, in some organizations, they don’t allow all the technicians to have access to FileWave necessarily. They might get tickets and go off and fix computers, but their view of the FileWave data could just entirely be in Incident IQ. It really depends on the place, how much access they give to the different tools.

Marcus Ransom:
Have you ever seen anybody use that sort of system to actually do any kind of sort of management or orchestration from within something like Incident IQ? So they’re actually creating the body of a script that they’re running on machines and then that getting pushed via the API to do things that way. I’ve seen people do things like that with APIs in other management platforms, where they’re not really using the web console at all.

Josh Levitsky:
So I have a, well, not around scripts because we don’t have yet a execute script command, although there’s things you could do where you could technically upload what we call file set. A file set is the stuff you’re pushing to a machine. That file set could have a script. And so through APIs you could accomplish deploying that. I think right now, it might be just the smidge too complicated for folks to do. They could do it if they spent the time, but I’ve not seen anyone spend the time. I have seen people build their own integration similar to Incident IQ for bringing data together.
I have a large school I work with that they actually have Intune for Windows and FileWave for Mac and iPad. And they have this one console that kind of ties all the data together. And it’s really neat because then the technicians access that console and whatever they’re looking for. They don’t have to think about is it an Intune or is it in FileWave? It’s just in that one place. I would really like there to be a concept in FileWave like ‘execute script’ and then have an API against that because I would use that all day long in professional services.

Charles Edge:
And that’s probably a good time to mention because FileWave predates software packages, the modern version of software packages, the file set concept dates back to the OS 8 era. And originally, it was just a set of files that kind of evolved similarly to how Apple’s package format evolved, so that you could run a pre-flight script, a post-flight script. But then, I don’t know, maybe around ’05, ’07, FileWave also added straight up package support. Right?

Josh Levitsky:
Yes, yes. We have direct package support, MSI support for the Windows side. But it is very much like when you look at a file set and you look at the scripts tab, you think you’re looking at basically the layout of an Apple package, as far as the scripts available and their purpose in life.

Charles Edge:
Yeah, it’s like a faux root type of object. Right?

Josh Levitsky:
Yeah.

James Smith:
This week’s episode of the Mac Admins Podcast is also brought to you by Kolide. Our sponsor, Kolide, has some big news. If you are an Okta user, they can get your entire fleet to a hundred percent compliance. How? If a device isn’t compliant, the user can’t log into your cloud apps until they’ve fixed the problem. It’s that simple. Kolide patches one of the major holes in zero trust architecture, device compliance. Without Kolide, IT struggles to solve basic problems like keeping everyone’s OS and browser up to date.
Unsecured devices are logging into your company’s apps because there’s nothing to stop them. Kolide is the only device trust solution that enforces compliance as part of authentication and it’s built to work seamlessly with Okta. The moment Kolide’s agent detects a problem, it alerts the user and gives them instructions to fix it. If they don’t fix the problem within a set time, they’re blocked. Kolide’s method means fewer support tickets, less frustration and most importantly, a hundred percent fleet compliance. Visit kolide.com/macadminspodcast to learn more or book a demo. That’s K-O-L-I-D-E.com/macadminspodcast. Thanks to Kolide for sponsoring this episode of the Mac Admins Podcast.

Charles Edge:
So if we think of the API for FileWave and it’s a restful API, like so many other APIs that we all know and familiar with, what makes it easier for developers who understand basic design patterns of restful APIs to work with the FileWave API? Can you give us an example of a basic task and how to call it maybe through Postman or cURL or something like that?

Josh Levitsky:
Yeah. Well, one thing is documentation’s important and we use Swagger. So on every FileWave server, if you go to slash API, slash DOC, you’ll get to the Swagger page so you can see how things work. There’s a little try it button. And we had a, I guess a real thing that people needed to do, if you’re a school with a lot of iPads, you might want to rename all your iPads at the end of the school year. And you might want to say that the iPad that was Sally’s is now Jimmy’s. You want to change who that assigned user is.
So I actually made a script, a file set, and a KB article about how to bulk rename your entire fleet from a list of serial numbers and assigned users, and you give it the device name, you run the script through the API, it’ll go through and rename them all. And so that was a task that made sense to do an API because there wasn’t a clear way to do it in product. And sometimes when I make a script like this, I’ll ask for product, I’ll realize that it’s silly that we don’t have a way to accomplish it in product. So I’ll make a request internally that maybe one day we could do that thing directly instead of through API.

Charles Edge:
Just out of curious or curiosity, Tom, if one of your, I don’t know if you have pro services engineers, but if you do…

Tom Bridge:
We do.

Charles Edge:
… and we do, one of them wrote a script and was like, “Hey, can you give me a modal that does that?” What would your response be?

Tom Bridge:
Well, it depends on whether or not it’s, if it’s using the same APIs, chances are we should have built that in the first place because when we’re building endpoints for the API at JumpCloud, the intention with rare exception is to make them possible to do those tasks directly from the API, or directly from the console, what we call the admin console.
And there’s rare exceptions, and there’s a really good one I’ll point out, is that if you want to do a kernel extension restart with a JumpCloud device, that’s not something most of our customers do. In fact, it’s rare where you can essentially, where it’s even required. And so we had a customer who came to us, they’re like, “We really need to do this, can you at least make it available in the API?” And so instead of tying up a front end dev, we just did the backend dev work to make it possible to send that kind of KEX path down the API pipe.

Charles Edge:
Right.

Tom Bridge:
At that point. So I mean, if we had the opportunity, if there’s something in there, obviously if there’s a use case where you could say, yeah, I really need to do this, and in fact, I need to do it 10,000 times, it probably needs a spot in the front end.

Charles Edge:
Yeah, I think Josh’s example though is super interesting because I don’t think I’ve ever encountered five customers that use the same logic for bulk renaming.

Tom Bridge:
Oh, yeah. No question.

Charles Edge:
I don’t know why. Just everyone has a different way of doing it. And so you can take the design pattern that Apple put into any of the automator or configurator type of tools, but everyone just has this bizarre, well, I want the building name and then I want the site name, and then you encounter character limits and all kinds of logic. And the next thing you know, you’ve got a 1,500 line script to do this thing.

Josh Levitsky:
Yeah.

Tom Bridge:
I was going to say, we thought about, we started going down the pathway of like, well, how would you do a renaming? And so what kind of things would you want to include in the name? Would it be the serial number? OK, yeah, but then you might be giving that away.

Charles Edge:
Well, and now you can’t get that. Ish.

Tom Bridge:
Well, you can and you can’t.

Charles Edge:
Right.

Tom Bridge:
Right? If it’s a user-enrolled device, you’re never getting that serial number.

Charles Edge:
Right.

Tom Bridge:
Good luck. Have fun.

Charles Edge:
You can’t guarantee it. Let me rephrase that.

Tom Bridge:
No.

Charles Edge:
You can’t.

Tom Bridge:
Programmatically, that’s right. And so going through that process and trying to figure out like, “Hey, what can I actually depend upon here?” And in the answer was, at the end of it, more trouble than it’s worth. Do it with a script of your own devising, we’ll help you if you need it. And we have a couple of pieces of our API that are meant for that, at JumpCloud. We have what’s called the system contacts API, which is where a system can use its own a API key to rename itself. And so that tends to be how we end up doing that. But it’s meant for use out of the system, a contacts API, which can handle itself.

Josh Levitsky:
We actually, we have something like that too, through in a file set even, a device knows it’s a device ID. So if you have a script in there that’s calling the API, it makes it really easy for the device to update something about itself. And in this script that renamed the iPads, the complex logic and the lack of standards of naming is why I made that script to read a CSV file. So basically you would decide all the names of your devices, all the assigned users, as long as you put the serial number in, we know from inventory the serial number. And so we matched up with that record. So it made really flexible because you could use whatever rules you want for naming, as long as your spreadsheet had it, it would rename the device.

Marcus Ransom:
As long as you don’t have commas in your names, you’re fine.

Josh Levitsky:
Yeah.

Tom Bridge:
Good old Bobby Drop Tables. Sanitize your data inputs people.

Charles Edge:
And I do feel like that CSV becomes, at that point, somewhat synonymous with the idea of a table about devices with a column, with device names in that table. And you know, you mentioned Kubernetes. So people can host their own instances, even if there’s a push to move to SaaS, obviously. So if users have a CentOS or macOS box hosting FileWave, they can access the database directly as well, but my guess is it’s not supported because developers would probably throw things that support people who tried to support that.

Josh Levitsky:
Yeah. So if you have on-premise, I mean you could pretty much do what you want because you have access to the data, hosted, you can’t get into it, and future hosted, you can’t get into it, as far as I know for the moment, APIs will be the way. And I know that by the end of this year, our goal is that everything will be on this SaaS 2, this Kubernetes, Docker thing instead of CentOS, because you guys might know that next summer, CentOS 7, which we are on, is dead. CentOS 8 is already dead. So we already have a move for our hosted customers by the end of the year, and actually by this summer, we’re going to give on-premise customers a path to get to, we’re going to AlmaLinux, is the choice that we made.

Charles Edge:
Right on.

Josh Levitsky:
Because we like how it’s being supported. The organizations that are picking it up, we like their governance model. We like that they’re CentOS 8 binary compatible. We already have FileWave running on AlmaLinux, so it was an easy move.

Charles Edge:
The Linux world is really interesting in that regard. Is under the hood, is it like a SQL or a no SQL.

Josh Levitsky:
Postgres.

Charles Edge:
Anytime I start, OK, Postgres.

Tom Bridge:
Postgres.

Charles Edge:
Yep, anytime I start hearing a bunch of Kubernetes and different workflows that kind of revolve around that, I start wondering if it’s not SQL.

Josh Levitsky:
Yeah, no, Postgres for us. Then we’re going to do all that stuff where you separate out things so that you can make everything scale really well.

Charles Edge:
Yeah. You don’t have to fine tune every single table constantly.

Josh Levitsky:
Right.

Charles Edge:
Little crown scripts running at midnight every night to re-index all the things.

Marcus Ransom:
Or just restart Tomcat every two hours for reasons.

Charles Edge:
Or Django, you know. Same, same.

Josh Levitsky:
And potentially, our plan for SaaS could also be our on-prem plan. We’ve been talking about that internally because the same things that we’re doing to do it in SaaS, you could do.

Charles Edge:
Right.

Josh Levitsky:
So that would make it so that there’s not sort of two different platforms. The only real consideration is FileWave server runs on macOS and CentOS right now. So we have to think about does whatever we decide work, continue to work on macOS and CentOS for server? Well, not CentOS, but macOS and the future SaaS. So we have to make sure.

Charles Edge:
Yeah. I mean, obviously, it can, but that’s a lot of logic to sanity check that every single package in whatever package management tool, which Python 3 is Python 3-ish. But yeah, that’s a lot of extra work to support a platform that not a ton of people care about supporting in this specific regard anymore, I don’t think.

Josh Levitsky:
Yeah, I guess we have to see. As of this moment, macOS, FileWave server running on macOS is still a thing and we haven’t made any choice to move away from it. But you’re right, I mean as it gets easier to run, a lot of people had issue with it being on CentOS. Schools that might know macOS really well, they might even know Windows really well, but they don’t have a lot of Linux, so they don’t feel good about it. If they can set up a Mac and run FileWave, they’re happy. And we have a lot of customers that are that way. Why learn Linux just for this one thing?

Charles Edge:
Right.

Josh Levitsky:
And so that’s been a lot of it. Or you might really love macOS.

Charles Edge:
So just give me a package that does the things under the hood and then yeah.

Josh Levitsky:
Yeah.

Charles Edge:
And that is a lot of, go ahead.

Marcus Ransom:
It’s something that further to our conversation before that, as a professional services engineer, you often see the harsh realities of decisions like that, that the developers behind a product team may not actually, logic may say, well of course you want it to be running in Kubernetes or some sort of scenario like that, but that’s when you have the experience and knowledge of the developer who’s building the software. Whereas the person who’s been told by their boss, “This is your job now. Guess what?” Somebody just, to quote Rich Trout and won the lottery bus and peaced out, got hit by the lottery bus. Sorry. Yeah, you are now an infrastructure engineer instead of help desk.

Charles Edge:
There’s something about shiny shoes and the electric Kool-Aid acid test around getting hit by a bus.

Marcus Ransom:
Yeah.

Charles Edge:
But we’ll leave that conversation to the side and move on. I’ve been on a deep dive into extensions for well over a year now. And I did notice there’s a CLI in the FileWave Central application bundle that can be used for some of the tasks as well. Right?

Josh Levitsky:
Yes. And I like that you called it FileWave Central because we only just started using that name, FileWave Central for the native and anywhere is the web. But yeah, you can do things like import file sets, import images, remove association. So an association is the file set, which is the stuff and the relationship of the stuff to the device. So if I have a bunch of teacher devices, I have a group called ‘Teachers’ and I would associate the file set to that group of teachers. I can update the bottle, which in FileWave terms, there’s like a version of all the settings. Every time you make an update to the version that kind of tells systems to grab possibly new stuff or different stuff. And you can, what was it? You can report on clients, file sets and associations.
Sometimes I have to think about it because the CLI is pretty helpful. I do still find myself forcing myself to not depend on it because I really want everything through the API. But the CLI is cool because you can do neat things like there was a script that we shared. We did an onsite training day last year in Indiana and we had a script for auto package that would grab a new version of Chrome, let’s say, it would insert it into your existing file set as a new revision of that file set, so that you could have this script just running constantly as new versions of software would come out. It would fetch it through auto package and then push it into FileWave using the CLI. So you can do some neat automations with it.

Tom Bridge:
That’s CLI, is that available for deep linking or do you guys have a domain for it or an on-device domain for it, or is it all just meant for direct usage?

Josh Levitsky:
So the CLI, if you install the admin client on your machine, that is what drives it. So that admin client knows how to log into the server and you can ask you to do things. So if I want to set up the auto package thing, for example, I install auto package on my device, I install auto packager, the GUI interface, set everything up, I install the FileWave admin and the script can then drive auto packager and it can drive the FileWave admin to do things. So that’s where that CLI is. It’s in the admin.

Charles Edge:
And some of your developments in Switzerland, is there an auto packager or Switzerland connection there that I’m missing?

Josh Levitsky:
Switzerland is where our company is based out of, technically. The home base is Switzerland.

Tom Bridge:
Very neutral.

Charles Edge:
Not Nurdan, she’s not neutral. She’s awesome.

Josh Levitsky:
Yeah, she’s not actively in the org anymore. Now Tobias is the CEO, Tobias Schimmer. But I did work with Nurdan. In fact, I knew Nurdan when I was at Time Inc. and we were going to use FileWave as a product. Nurdan, I quite like and miss her at FileWave.

James Smith:
Deploying, managing and protecting Apple devices at work shouldn’t be difficult or require several solutions. Mosyle is the only Apple unified platform for business. By combining enhanced device management, endpoint security, internet privacy and security, single sign-on and enhanced in-apps management into a single Apple only platform, businesses can now easily and automatically deploy, manage and protect their Apple devices with one solution and add an affordable price. With a solution for every business size and the best support in the market, request your free account today and see firsthand why Mosyle is more than an Apple MDM. Mosyle is everything you need to work with Apple. To learn more, visit business.mosyle.com. That’s business.M-O-S-Y-L-E.com.

Charles Edge:
So Josh, I do feel like Mac Admins spend an inordinate amount of time creating packages if they don’t automatically generate those packages. So I’m totally stoked that you mentioned auto-package. And anyone, including device management vendors, who are looking to redo that auto-package logic, which at this point is a decade old maybe, and programming from scratch seems somewhat bullish right about now maybe. So that brings up a great question. You mentioned auto-package and AutoPackager. How’s the auto-package integration work, maybe at an API level or maybe just in general?

Josh Levitsky:
So there is a plug-in for AutoPackager, you’ll see it with all the other plug-ins in AutoPackager, and it’s using the CLI integration in the admin client that I talked about, to drive uploading that package. One thing to think about is that we are moving away from what were file sets and associations we’re moving to, well file sets kind of say the same, but we’re calling them payloads, but they’re essentially the same. But we’re moving from associations to deployments. Deployments are a bit different than associations. And so right now in the product, if you are running the very latest version of FileWave, you have both associations and deployments. Just think deployments can do a couple of extra things that associations can’t. And the FileWave admin, the CLI doesn’t really know, and the plugin for AutoPackager doesn’t really know how to deal with deployments.
So whenever we get rid of associations for good, we have to make a decision about how we want AutoPackager to integrate. Because we would probably want to move it over to deployments, which would probably mean APIs because like I said, even in the native admin where it talks to the server for newer things, we’re trying to use the APIs. So likely we’ll have to cut over to APIs. We have the AutoPackager integration, just like in our knowledge base, we have winget for Windows, kind of details about how to set that up. Because we try and find anything that exists already as a process that somebody could just take advantage of and hook in really easy to FileWave, rather than necessarily building something from scratch ourselves. Although we might build something from scratch or on third party patching. But if we give you access through tools that you like, tools that work well, that are developed by great folks, that feels good too. Winget, if you don’t know what it is, Microsoft is really supporting that and pushing that, a command line way to install apps.

Charles Edge:
I’ll drop a link to winget in the links. I have to say, if anyone from Apple product management happens to be on the call, this is an awesome, I think the overused term of the episode is design pattern, but this is an awesome design pattern for how you can bring a collection of somewhat open source concepts in, in order to facilitate the automated package management. Which going back 20 years is probably a consistently large, I think the term we used earlier in the episode is inordinate, amount of time that Mac Admins actually spend managing devices. Once we get into this workflow where everything is using a device management tool. We’re not running around swapping out floppy discs anymore. Right? But we are creating the next Firefox, the next Firefox, the next Firefox, the next Firefox.

Marcus Ransom:
And we’re certainly using the Mac App Store for deploying these kind of apps on a Mac.

Charles Edge:
And regrettably, the Mac App Store just isn’t available for everything we need. For example, an endpoint protection extension cannot be put in the Mac App Store. So we can say like, oh, we want everything in the Mac App Store, but literally there are APIs from Apple that are not available to apps in the app store. Ergo the app store is not available for every app that we might want to install. Right?

Tom Bridge:
Well, and plus if you look at how winget plus CSPs on the Window side of the house work, it’s actually a really nice and elegant solution that I would love to see come to the Apple side of the platform in a lot of regards. I’m really excited by the fact that CSPs on the Windows side of the house are finally LGPOs, but enforceable. And there’s a lot of really good stuff that’s coming down that pipeline, so that you can make a really solid Windows MDM. And Joel Reddick and I have spent a lot of time diving in on some of those Windows MDM protocol pieces and it’s just like, “Oh, this is nice. This is actually pretty sweet.” And I didn’t expect to say that at all.

Charles Edge:
Oh, I did. Yeah. I mean, who knows more about large scale and large, large scale.

Tom Bridge:
Sure, but I just didn’t expect it outside of Intune, is my point.

Charles Edge:
Oh, yeah.

Tom Bridge:
I didn’t expect it to be an open standard that the folks get could get to. And same with winget here, you know, you get some really solid opportunities here. And it’s not just MSI only, you can also do AXEs, you can do other things like that. Winget as a technology for delivering applications is pretty solid.

Josh Levitsky:
We actually have been looking at putting a front end on winget. Because it is just part of Windows, I mean, it’s a Microsoft tool. And how nice would it be if you could just browse the list of software, pick to deploy something? We have in our KB about how to set up a file set to do it through a couple of scripts, but it would be really nice for an admin to not have to think about that. And on the CSV front, CSP front, I agree, they are really wonderful. We have Windows MDM and FileWave now, and so we support a bunch of CSPs. And there’s neat things like if I want to take all my Windows 10 to Windows 11, there is a checkbox in the software update CSP that I could technically do it. And I have one customer where I really want to try that with them because I want to see how successful it is. Because software update is painful on every platform.

Charles Edge:
Yes.

Marcus Ransom:
No, to see Apple be able to implement something like that, but also be able to dovetail it with an application control framework as well. So to give us a manageable programmatic way we can control not just what applications go onto our machines and keeping them up to date, but also to be able to ensure that only those applications can go on onto the machines. Because we all know that’s what the users of the systems we work on and their security teams need. And it’s much like softer update, it’s not really a solved problem yet.
So here’s a question every product manager or developer knows the right answer to already. So I feel like I’ve fiddled with the FileWave database, but I should probably be using the APIs so I don’t introduce breaking changes or cruft. Right?

Josh Levitsky:
Yeah. Yeah, going back to I’ve mentioned this on a couple of answers that I myself who could always use the backend stuff to do things, I don’t want to do that because the API is the right way to do it. Which is why our web admin, if you think about it, that’s an administrator that we’ve already put in all the protections, all the ways to avoid dangerous things happening. So the API is always the safest method.

Charles Edge:
So let’s extend your example of a cURL command from earlier and say we want to introduce, I don’t know, something insane like ChatGPT support, which you did. How was that?

Josh Levitsky:
Yeah, yeah. I’ve been using ChatGPT and actually also I started using Edge Browser so that I would get into Bings, I don’t know what you call, limited release of their version of ChatGPT. I like Bing.

Charles Edge:
They pumped millions of dollars into it.

Josh Levitsky:
Yes,. Microsoft is an investor in OpenAI, and so this integration in Edge and Bing is a part of that. And the nice thing about Microsoft’s implementation of ChatGPT is it gives you sources, which you do not get in ChatGPT. So if you want to know where that information came from, good luck. But ChatGPT is really great at coding, at giving advice on coding. So that script about updating the device names from a list of serial numbers and changing the assigned person, I actually really did that in a very short time with ChatGPT.
So I could give it even the beginnings of a script and then I could say, “Hey, change this, change that,” or, “I decided to make this a parameter in the script. Can you make this a parameter at the top of the script?” And then it’ll replace all the bits of code that were referencing it. It’s really good at doing that because I look at scripting a little bit like artwork. I mean, in a way it is. You sit there and you’re thinking about your problem and how to solve it, and ChatGPT is like having your buddy there to ask questions and what if, and sometimes it’s completely wrong, but sometimes your buddy is completely wrong too.

Charles Edge:
Yeah. And sometimes your buddy draws fingers completely wrong. But I do have to say, I ran into a very similar thing in my experiments with both GPT-3 and GPT-J, and I’ll post a link to this too, but I wrote a quick machine learning similarity checker to run post GPT-3 to try to find places where you’re accidentally plagiarizing people.

Josh Levitsky:
That’s cool.

Charles Edge:
Because that’s a thing.

Josh Levitsky:
Yes, yes.

Charles Edge:
To your point about sources, right, you don’t know where the source is. So as a post-flight script, if we were using packaging terms, you can then say, oh, where did this come from?

Josh Levitsky:
Yeah, it is a concern. Well, for schools, they have concerns about ChatGPT being used by students to submit homework assignments and knowing if that’s plagiarized or not.

Charles Edge:
But that’s just a smart move on the student part.

Josh Levitsky:
That’s kind of the way I see it because, but I’m not a teacher, in a way, maybe I am. I run training at FileWave too. And so in a way, if somebody turns in an assignment that was generated by ChatGPT, if they don’t know that topic, then they don’t know that the stuff is true in there. So they’re taking a real chance. And I kind of look at, if you were able to use it to make a better answer to a question I had, and it’s true what you hand me, then I would see no problem. If someone worked for me and I asked them to do something, as long as they give me the right answer, I don’t care. And as long as it’s not breaking any laws around plagiarism or anything, like stealing somebody’s work, then that’s good too because it’s proper to give credit.

Marcus Ransom:
So what you’re trying to say is that there would never be a developer out there who had just copied an answer from Stack Exchange and had no idea what it was actually doing, just it compiled.

Charles Edge:
I feel like I can field this a little bit. No developer worth their salt thinks that code auto-generated from a GPT-3 or a GPT-J implementation or GPT-2, according to how cheap you are, is worth it’s salt. Earlier you mentioned Swagger, there are GPT-3 module, or I don’t know what word I want to use here, but you can use GPT-3 to attempt to build Swagger documentation based on an existing API that you’ve built. But the code that it puts is just garbage, it’s crufty beyond. It’s like if you went on Fiverr and actually paid $5 for someone to write a PhD dissertation, this is what you get.

Marcus Ransom:
So stupidier than anything I’ve written.

Josh Levitsky:
You have to really know the limitations of ChatGPT. And I guess if you use it the right way for what it can do, then it can be a time saver. If you can’t remember how to do a certain routine, instead of looking on Stack Overflow, sometimes ChatGPT just gives you the answer right away. And then when you see it, you kind of remember, OK, that was true, that was the thing that I already knew, I just couldn’t quite remember it. I use it for that. I use it for formatting emails. I’ll write something out and say, “Can you make this sound more positive,” or, “Can you make this sound,” like if I’m apologizing or something to try and help me with the words that I could come up with if I sat and sat. But if it gives me the words and I really like the way that it phrased it and I agree with it, that’s when I use that.

Tom Bridge:
You’re giving me too many ideas from my keynote [inaudible 00:57:15].

Charles Edge:
I mean, clearly, we probably need to have an episode on generative, sorry, I always stumble on that word, machine learning frameworks. I do feel like, whereas in my opinion, the most time-consuming part of being a Mac Admin is probably package creation. With being a machine learning admin-ish or developer, the most time-consuming part is really those Jupyter Notebooks or whatever you keep your models in and how you train that model. And generative, if I say that properly, finally, after years of trying, it’s that untrained model or automated training of the model with the different generations. Right? That’s why you used it, right, Josh?

Josh Levitsky:
Yeah. Yeah. And actually, [inaudible 00:58:12] sort of cool idea from this, and every time I use ChatGPT, it makes me think of this, everybody has a knowledge base, every product has a knowledge base. Wouldn’t it be really nice if instead of having these knowledge bases that it was just the ChatGPT interface? To known true data that it’s trained on your data. And so for FileWave, you don’t have to poke around through the structure of the knowledge base. You just say, “I want to know how to set up the support for Chromebooks,” and then it spits back an answer based on being trained on our data.

Charles Edge:
Yeah. That’s not entirely new though. Salesforce has had a tool called Einstein for years, that if you’re keeping your ticket information in there, except then you run into no compliance person is happy with the, can you 100% guarantee meat that no customer data will leak based on this Einstein result. And you’re like, “Well, there’s no such thing as a hundred percent in computing.” How’d you get into compliance, if you say a hundred percent.

Marcus Ransom:
That’s where we end up back with self-hosted solutions because people want to have it within their own perimeter of where their data is.

Charles Edge:
Yeah, don’t forget, Atlassian is named based on Atlas who holds the world on his shoulders because he’s a jackrabbit. Right? According to the Greek gods. Anyways, sorry, that’s getting off on a whole tangent. We definitely should have a ChatGPT maybe panel, and we might invite you back to be on that with us because, or GPT-3 or GPT-J or whatever, OpenAI. Not DALL-E, anything but that. Because fingers are a thing.

Josh Levitsky:
What about Midjourney?

Charles Edge:
No.

Josh Levitsky:
Midjourney is wonderful.

Charles Edge:
Nope.

Marcus Ransom:
What I want to know is are we going to get to the next level where we have auto-packaged GPT, where it will just go and works, let it have at Adobe and it can work it all out itself?

Charles Edge:
Not until the vacuum cleaner can actually not get stuck under the couch.

Marcus Ransom:
Yeah.

Charles Edge:
So speaking about the future of generative, gosh, that word is just sticking with me right now, is always tough, but in software development in general, it’s always tough. It just kind of takes what it takes to build stuff, as I’m sure Tom bangs his head against the wall all day, every day about these days, now that he is on the product side. But timelines are still necessary for the product manager, but customer facing, definitely not because who knows. Right? It takes what it takes. But in broad strokes, so no timelines required, what are some of the things you see coming to the API in the future?

Josh Levitsky:
Sure.

Charles Edge:
Other than ChatGPT support? Because that would be similar.

Josh Levitsky:
Sure. So these are a couple of things that I could talk about because, I mean, they are coming. So I talked about how deployments are a thing. So I guess deployments are in the web, they are in the API, so I suppose it’s not future. But Windows Imaging. So if you don’t know, for FileWave admins, some of them use FileWave to image Windows systems. They used to use it to image Macs, but obviously we went to Thin Imaging years and years ago, and so they don’t really, even though our system supports it, they don’t really do that, which is good. But Windows Imaging is still a thing. We’re trying to get people away from that with Windows MDM, but I think Windows Imaging will take a few more years to really go away. So we’re adding to the web admin to manage the association of image to machine. So that would come to the API.
As people have looked at the APIs, it’s been a consideration that maybe we don’t have enough permissions. We have a lot of permissions that you can assign a user, but we could probably use a lot more permissions. So that you could, through the API, make it so that somebody could only, well, I guess API or the web admin, that you could only do certain tasks against the device. Where now you get kind of broad permissions granted to you. So I guess, those would be the things that I see. We also, for customers that are listening, in our knowledge base, there’s a product management page and there’s a link there to a roadmap. So you can see what is in the next couple of versions coming. And I believe that that Windows Imaging one is mentioned. And you can actually submit requests, like, “I wish it did this, or I wish it did that.”

Tom Bridge:
I always love getting feature requests as a PM because it shows me new and different ways that our customers think about the product all the time. So it’s a great way to learn and to be humble and to kind of be open to the future. So that’s a great way to do it.

James Smith:
Here at the Mac Admins Podcast, we want to say a special thank you to all of our Patreon backers. The following people are to be recognized for their incredible generosity. Stewbacca, thank you. Adam Selbe, thank you. Nate Wolke, thank you. Michael Tsai, thank you. Rick Goodie, thank you. Mike Boylan, you know it, thank you. Melvin Vives, thank you. Bill Steitz, thank you. [inaudible 01:03:59], thank you. Jeffrey Compton, M. Marsh, Stu McDonald, Hamlin Crusin, Adam Berg, thank you. AJ Petrepka, thank you. James Tracy, Tim Perffit of Two Canoes, thank you. Nate Sinal, Will O’Neill, Seb Nash, the folks at Command Control Power, Steven Weinstein, Chad Swarthout, Daniel McLoughlin, Justin Holt, Bill Smith and Weldon Dodd, thank you all so much. And remember that you can back us if you just all head on out to patreon.com/macadminspodcast. Thanks everybody.

Tom Bridge:
So here at the Mac Admins Podcast, we will frequently talk about a bonus question. And so since we’re talking automation today and we’re talking APIs, what is the silliest API automation that you’ve built, even if it’s just for home or proof of concept?

Josh Levitsky:
So it wasn’t a real, I mean just for me, it was a script that would generate jokes. There was a site that could generate jokes and I wanted this thing that would just make jokes, not make jokes, but produce jokes when I ran the commands against an API. That was probably the silliest thing, literally.

Tom Bridge:
All right. Do you have any good examples of jokes that came from that?

Marcus Ransom:
We’re going to get sued for a whole different reason.

Charles Edge:
It’s like asking Alexa. Alexa tells me jokes every morning and they’re never good.

Tom Bridge:
That’s sad. I mean, you did hear the one about the VC who went bankrupt trying to create a dating site for chickens, right?

Charles Edge:
Is that my day job?

Tom Bridge:
Maybe. But I mean, if you’re trying to make hens meat, I mean, that’s really hard.

Marcus Ransom:
I’m going to revoke your token for that, Tom.

Josh Levitsky:
Yeah.

Charles Edge:
So Marcus, what’s a good automation with an API that you’ve built?

Marcus Ransom:
Well, there’s one that’s on my plan to build at the moment where I want to use, I’m trying to find an API for our local council’s website so I know which bins go out on which week. So that I don’t need to keep going to the calendar and trying to work out, one of those. I saw a great one someone did with tram, with a tram timetable. Where in the morning, they’d have a color changing light that would be like red, you’ve missed the tram, don’t bother leaving. Orange, if you grab your bag and run now, you’ll get the tram. So something like that, but you sounded like you, have you already built one Charles while I’ve been waiting?

Charles Edge:
No, I didn’t need to. My bin service, trash service, garbage service, whatever, changed last month. And the new service has an app and I get a push alert not only the night before, so I know to take the bins down, but the morning of, when they’re like four stops, I don’t know how they determine it, but when there are a few stops away, it says, “By the way, the truck’s close. You might want to get your crap down there if you want us to take it.”

Marcus Ransom:
For me, when I wake up in the morning to the sound of the garbage trucks coming down the street and it’s like, “Oh, forgot to put them out last night.”

Charles Edge:
Then you run downstairs and the next thing you know you’re outside in your underwear.

Marcus Ransom:
And you realize they’re going on the opposite side of the street.

Charles Edge:
Wait, that might just be me.

Marcus Ransom:
No, I’ve had that a moment. Look, that’s one. And another API I saw, which was silly because it even needed to exist at all, but was phenomenal in the way that it worked, was dealing with sort of ties in so many of the things we’ve discussed. So it was an organization I worked with who had very complex deployments. And so they captured all of these APIs from all these different services so they could see where, if a user was getting assigned a new machine, on a dashboard that the deployment team could have, they could see hardware was ordered, hardware was in the depot, hardware was arrived. And this was the one that was fantastic, was has it been assigned to Apple Business Manager. If it has been assigned to Apple Business Manager, and this is where they were self-hosting their Jamf so they could have at the database, where they could actually see was it scoped to a pre-stage. All of the things that if a deployment technician unpacked that device and powered it on could make things go horribly wrong. They could see, they were then correlating against, they were binding to active directory in those days.
So this amazing dashboard where you could just look up a device in the deployment queue and you could see exactly what stage of being built it was. And rather than just having one API that was querying one service, it was the freight service, their internal warehouse system, pulling serial numbers in AppleCare status from the vendor, querying the database for things that Apple Business Manager, Apple School Manager, not having an API, please give us an API so we can automate things. So that was, I’d say, silly in the way it was implemented, but phenomenal in what it could achieve. By having a bunch of developers taking really weird approaches to automating things that got there in the end.

Charles Edge:
So how about you, Tom?

Tom Bridge:
So we released some new commands, triggers at JumpCloud, not too long ago, actually in January. And one of them is on enrollment. And so I have a MacBook Air sitting on my desk. This is my JumpCloud MacBook Air that I used for testing all of my stuff. And so I wrote a deployment script, free use by our API. So that essentially, a new device checks into JumpCloud, gets the agent, does all of the agent stuff, binds the user. At the conclusion of that process, it sends the API key to wipe the device. So I built a do nothing.

Charles Edge:
Well, a reset. A factory reset.

Tom Bridge:
And so essentially, it’s a full factory reset.

Charles Edge:
Yeah. I really did that.

Tom Bridge:
So I mean, on check-in, the system makes it entirely about five minutes, and at the end of the process, it issues the command to delete the record, or excuse me, it issues the command to wipe the device and then delete the record. So I mean, if the only thing I did was like, all right, wait 10 minutes and then do this task. Just long enough for me to check in on the device. So yes, I wrote a self-erasing computer script.

Charles Edge:
I love that so much because mine is actually super adjacent to that. So in writing, I find that I frequently need to set something in motion and then be able to write, and then I need some kind of physical trigger when it’s done. So IFTTT is a thing, and somewhere on my GitHub, I’m probably not going to remember to go paste a link to this because it’s super late at this point, we’re going over, but somewhere on my GitHub, there’s a link for an IFTTT script to take a Jamf enrollment trigger, since we’re talking about webhooks pretty much. And once it’s updated in IFTTT, I can do anything. So what I chose to do was flash the lights. OK, this is done happening, the lights flash, now I can go grab my screenshot and then I can manually factory reset. Now if I had your script, I could actually screenshot with the screen capture command and then factory reset and walk away and have it all be automated, which would be way better.

Tom Bridge:
Yep.

Charles Edge:
But yeah, that’s a lot of scripting for a screenshot, so I’m probably not going to bother.

Tom Bridge:
That is. I think, yeah, you may want to find other ways.

Charles Edge:
Yeah. Yeah.

Tom Bridge:
Josh, thank you so much for joining us this week and for talking with us about the FileWave API. If folks want to find you online, where should they go looking?

Charles Edge:
I suppose, well, if you search for Joshua Levitsky, I and a doctor in Chicago are the only two you really find, but I’m on LinkedIn and everywhere else and it’s josh.levitzky@filewave.com and I’m happy if anybody emails me about anything. And we didn’t talk about it, but we also started up a web-based forum alliance.filewave.com. And we have a Discord server, everybody has Discord, discord.gg/filewave, and I’m on there all the time. But email’s probably the simplest.

Tom Bridge:
Well, make sure that you go check the show notes, listeners at home, and you will see all of those links, including the two that he just mentioned for the FileWave Discord community and for the web-based forum. And of course, thanks so much for our incredible sponsors this week. That’s Kandji, Kolide, and dataJAR. And thanks so much, everybody. We’ll see you next time.

Charles Edge:
See you next time.

Marcus Ransom:
See you next time.

James Smith:
The Mac Admins Podcast is a production of Mac Admins Podcast, LLC. Our producer is Tom Bridge. Our sound editor and mixing engineer is James Smith. Our theme music was produced by Adam Codega the first time he opened GarageBand. Sponsorship for the Mac Admins Podcast is provided by the macadmins.org Slack, where you can join thousands of Mac Admins in a free Slack instance, visit macadmins.org. And also by Technolutionary, LLC. Technically, we can help. For more information about this podcast and other broadcasts like it, please visit podcast.macadmins.org. Since we’ve converted this podcast to APFS, the funny metadata joke is at the end.