IT Automation Techniques for the CAD Manager

PRESENTER 1: So I'm going to turn this over to Tiny, and he's going to talk about deciding what is a time to automate and not automate.

PRESENTER 2: Thank you, Jerry. Everybody can hear me OK? All right. So through many years of doing a lot of automation scripting and stuff like that, this is my company's perspective on when we get automation requests. General rule of thumb is we tend to look for commercial. And if there's something, a commercial product out there, or a vetted third party application out there, that does at least some of what we want-- 60%, 70%, 90%, whatever you can live with-- we always tend to go with that commercial product.

And the reason behind that is, a lot of people may say, OK, well, commercial products are very expensive. And we've got some in-house programmers or developers, and stuff like that. But you really have to look at the whole cost associated with automating. You have labor associated with the costs, you have purchasing and licensing. One thing that a lot of people don't look at is your production staff. When you're talking about automating, if it's outside of the physical IT or CAD environment, and you're looking at workflow automation or stuff like that, then you actually have to take highly paid engineers to come into a conference room and discuss the process and go through all that.

And then a lot of people don't think about the residual effect of the automation as far as training and the support, bringing your users of the speed, and then also the compatibility as far as for the changing environment. So really think about, when you go into automation-- like I said, try to look for a commercial product or a valid third party.

Some keywords that we're going to kind of go over as the process-- when you think, OK, now, I've already checked out, there's no commercial product out there that I want to do. It's very specific to my environment, or whatever. A few things to make your automation successful, or a few things to look at and then also go back and say, well, we might not even need to automate. We probably should forget about this.

As one, before you even start defining your goals-- and I've been on many scenarios where I'm getting feedback during the automation process, and the goals just change left and right. And you go down one path, and then another goal comes up, and you have to look and re-look at how you coded it, or what kind of tools you're using, and say, well, that's not going to fit in this scenario. So now we've got to go backtrack and figure it out again. So definitely get some real defined goals.

So your automation is coherent later down the road. You might have to get another person to pick up from where your original person took off. And if that coding and that flow of the automation is not very coherent, it's going to be very difficult for them to pick it up. Plan. Plan before you code. Plan before you start developing. Plan. I mean, this is getting together in workrooms, discussing the goals, figuring out your resources, figuring out who needs to be part of it. Plan it. Because like I said, you can just keep going down the rabbit hole forever if you don't do some very solid planning.

And the planning, again, can cause you to redevelop, re-code, scrap a lot of stuff, and come back.

Time. Calculate what it's going to take to get to a final product. And then calculate how much time you're actually saving. And I know I've had coding requests or automation requests for one thing. And it was like, I could spend six months doing this, and what is it going to do? Save an hour or a week, or something like that? Is it worth it? And the six months is just to get the initial product out there. And then from there on, you have the maintenance and everything going forward.

And then your return on investment. Definitely calculate the labor. Think about the labor. Think about the purchase. Think about the maintenance. And when we're talking about automation, And this is the next bullet. It's simple. When you automate, keep it simple. And I don't know, how many are software development company in here?

All right, so a lot of us might be more of the engineering side or the industry side, and stuff like that. And we just want to get these simple routines automated so we can get rid of the mundane tasks that we have to do. So just remember, we're not really paying for-purchase software. So when you start looking at your goals and your plans and stuff, if it's starting to get so complex, revert back to that original thought-- let's find a vendor. Find a vendor to do this.

Make sure you're flexible with the technique you use. And if you're going to automate a process that you do on a daily basis, keep it flexible, because down the road the goals may change. And if the goals change or if you want to reuse that later, you want to make it where it's very flexible to plug into other scenarios.

Reusability. So basically, the longevity of the automation that you're actually developing is what's going to bring you the most return on investment. So if you actually develop some form of automation or automated routine, and it's only valid for a six month period, you really have to look at what was that time savings, what was that ROI?

But if I can develop a simple routine that can save somebody one to 10 hours a week for years to come-- and we're focusing a lot of this on a lot of the licensing and deployment. And that strategy hasn't changed very much in many, many, many years. So if you develop an automated technique, that could be a very long-lived benefit.

And like I said, for me, I like to develop automation for those mundane tasks. If you're doing a manual mundane task, that's when you need it. I would suggest look at that. Don't look at trying, like, ooh, it would be cool to have this tool in an all new environment, and stuff like that. That's software development. Automating is what you already do. You just want to make automated.

Sources. Make sure whatever sources you use are well vetted. They're credible sources. It's not like a downloaded software that might tie into some process, workflow process that you have, or some extraction tool that might be used for data extraction-- MySQL or something like that.

If you start building your automation on that, and then that source no longer supports the code, no longer supports the tool, Windows environment changes, then your automation is broke. That goes back to that long-lived value of actually automating in the first place. And Jerry and I both agree a lot of times. I say, freeware is nice for home environments and stuff like that. But freeware can become expensive-ware, in the sense if you start using one, it's no longer supported, no longer functional, you've got to go back to the drawing board again.

So on this slide here, we wanted to bring to your attention that a lot of the stuff that we're going to go over today, you already have. You don't have to go out and buy something then do an automated technique or automate a process that we're going to present on. But don't forget about the simplest tools that you have already available. From licensing lmutils and the command prompt world, the pinging, the IP configs, the registry queries and stuff like that. Depends on what you want to automate, but you may already have something on your desktop ready to go and then you just massage that and get it to actually work for you.

And in all the automation, all the VB programs I'm going to show you and stuff like that, I'll use that same technique. Never bought a piece of software, never had to buy a third party add on to do the things that I actually do.

And Jerry, you want to pipe in on that?

PRESENTER 1: Yeah. Like the slide says here, the bottom line, I think, is very important. Don't forget batch files. You're going to see a lot of really fancy VB stuff that Tiny's done, nice GUI interfaces. And that's OK. But for a lot of stuff, you just need fast and dirty. The batch file's really valuable, because anything that's up there can be automated with a batch file and be done quickly, in hours, not days. OK. And then the only thing I'll say there is, once you did that, test the heck out of it before you really start using it.

PRESENTER 2: Yeah, so like I said, hopefully all those key words and stuff like that, for whatever you're going to automate on-- I know the title of the class is for CAD managers. So we're going to give you a lot of automated functions within the licensing and deployment side of things. But use the same practices for any automation.

So we're going to go over the Active Directory integration. Just for everybody's benefit, on the class sign-up, you have the documents and stuff like that. We've posted two of these tools out there for you to use. So this tool that we're going to go through for you to use-- it's freeware. And it's hopefully not going to be expensive-ware for you. It's been functioning for a good probably eight years, 10 years, now.

So basically what this tool is going to do is, it's a VB program, 2010 coding. It reads Active Directory. And it reads your Autodesk License Options file, which everybody should have. Correct, Jerry? If you've got a licensed server out there for Autodesk, you should have an options file.

And what it's going to do is read the options file. And with an option file, you can control borrowing and restrictions with it. And using groups-- and you use host groups, and you can use user groups. So what the tool is going to do is go out the Active Directory, read your options file, compare it to-- find like for like-- the groups, and pull those members out, or those hosts out, and then populate your options files for you. And this saves me a ton of time. And I don't have to worry about RDP into 10 or 12 license servers. I have this running all the time. If I need to add a member to a permission group, or to a borrow less, just add them in AD. They're done. All my servers are already synchronized and all.

So this is a good little tool. I hope that you find a benefit for it. The set up is pretty simple, too. You either create the groups in AD or you use existing groups that you already have. And then you're going to update the INI file. That basically tells it where these files are located, what domain you're actually on.

As I kind of go to re-usability, my automation is not written to my domain. It's shareable, goes to any domain. And I'll create a schedule task, actually, on the server. So I'll actually process everything for you.

So basically, steps to implementation-- identify and create your AD groups. Create a mirror group in the opt file, the options file. There should be one in on every one of your license files. So I actually have an opt file that is across the board. And so I push that out to all my license servers. And they have these groups and the permissions associated with it.

And then you run, you edit up the INI file, which we're going to show you how to do it. And then you're going to run the exe that actually updates the options file. Then you're going to check to make sure it basically populated the members. And then if it's good, you're going to create a schedule task and then you're going to test it again.

So from the download site, you're going to download update opt. And it's going to have an executable, it's going to have an INI, and it's going to have a PDF. You're going to open up this INI file. And it's really just basically for flexibility, where you install your lmutils, where you install your Autodesk manager. You actually tell it. And I'm giving it a reread, because after it updates the options file, your license server needs to reread it so it actually applies all your changes.

So I actually put in a port number and the computer name, which is universal. So it doesn't matter what PC or what license server you put it on. It'll actually run. Now the port number, you'll go in there and change if you're not using that port and stuff like that. And then also tell it where the options file is. Where is it located? And in the A to Z class where we teach it, we'll point out what we suggest as far as locations. But if that's not the case, you just edit this INI file.

And then the domains. What domain are you on? And then-- and this is why I actually made it flexible, not so I could share it with everybody, but because we go through a ton of acquisitions. And we ended up where we have four different domains. So the AD groups, I can have the one company that we just purchased or something like that go and create their own AD group, and then synchronize it, so they can control their users for borrow. We can control our users for borrow. And it actually allows for a multi-domain environment.

In just the AD, looking at AD users in computers, I have a borrow group here in the Americas, BORROW-T1. It's a legacy borrow group. And I'm sure some of you might know what it means, but it's a legacy. One thing I want to point out is the tool understands that a group in AD can have another group, and that group can have another group. So in this case, I have a AM-BORROW-T3. And in there, I add the T1 group and the T2 group, so I don't have to keep maintaining that third tier type group. So the tool will read the group as it's reading the members. It'll find if there is another group out there, and it'll read that members list. And if it finds another group, it'll keep on going and populate for you.

So if we look at the actual Autodesk options file, which everybody should have, mainly because of these two lines here, time out and rolling of the report logs, keeping up with your report logs. I have a group and the name of the group, and I just put "noone." And this is when I stand up another license server, I just throw this options file out there. And then I set up my schedule task, I run it, and the "noone" should be changed and get populated with all the members associated with it.

Now the reason you want to create groups is so that you can actually control the borrowing. So this T1 group can borrow AutoCAD 2015 applications licenses. You can use it for borrowing, you can use it for restrictions and all. So how you use the group doesn't matter. It's just the name of a group that is associated with Active Directory.

So once you've actually edited the INI-- you got your groups, you got your members and stuff like that-- you double-click on the exe. And it actually runs, and then hopefully you open up the options file. And I'll show you what you'll see is, you'll see a bunch of names. OK. If that worked, as it should, next is actually starting up your schedule task. And when you go through a schedule task, it's very basic. Choose that you're going to run it on a daily basis. You're going to start a program. You're going to come in here and point it to the exe. The one thing you want to make sure is to give it the start.ini folder. So basically, you copy this first part and drop it in there. And that's mainly so the exe knows where the INI file is. And so wherever the exe runs, the INI file should actually be.

And then before you actually finish creating a schedule task, tell it to open up for advanced properties, because you're going to make a couple of other edits here. Here you're going to tell it a user to log on and use. And this should be a service count. If you're license server administrators, you really should have a service account running that you can use to run these schedule tasks and all. And you just tell it, basically, to run this schedule task whether the user is logged on or not.

And then after that, under your triggers, you're going to edit the trigger, which you chose was the daily. You have the option of how often you want to repeat it. So this is just totally up to you, how often you change your borrow users. If you got a lot of influx on people saying, hey, I need to borrow a license or something like that, and you do it on a daily basis, then make it daily or whatever. So it all depends on how often you do it or you make changes to the borrow list.

Now after you do that, test it, because the difference between double clicking an exe and running a schedule task can actually be quite different. Because the account that you use, you might have mistyped the password. The account you use might not have access to the folder where your lmutil is located and stuff like that. So you want to test it. After testing, whether you run the exe or the scheduled task, this is what you should see. You're going to see multiple rows, depending on how many users you got in the borrow groups. So if you notice on the T1, it's only got one line. So we've got a few people that have a very high level of borrowing or restrictions, or non-restrictions.

And then T2, we actually have about three rows. And then T3, we got a ton of rows. Don't worry about that, because what the tool is doing is, once you exceed a certain limit-- the license manager tends to flake out and not like that. So the actual executable is maxing the characters per line by 2000. And the license manager knows, as I go through here, it's not the typical "the last one wins." It's actually concatenating a list over and over and over.

So that's what it actually should do. The executable that we're providing you also only does changes. And I didn't have this in earlier version, and my logs grew crazy. Because every time it would run, it would do an lmreread, and it would make the logs super huge. So I modified the code to go in and compare what the file was before and what it is now. And only if there was a change will it actually do an lmreread. OK.

So that's actually the tool that I give you. Now you're saying, OK, well, kind of like that freeware is expensive-ware. Or maybe we don't want to use Tiny's tool and stuff, which is perfectly fine. I just want to show you there are other techniques that you could integrate with Active Directory or pull data out of Active Directory and not use this actual tool. There are some complex ones and you really need a pretty savvy way of understanding AD some scripting and some syntax. And then there's a lot of really easy ways.

So here are three examples that just come with the OS that you can actually run. It will pull data from Active Directory. One is table oriented, one is comma separated, CSV format. And then there's just a query service. And so basically the goal is a tool to extract AD group members into a text file that you can then go put in your options file. So that's the ultimate goal.

So the one I found that was the simplest to actually use, where you didn't need to know a whole lot of information other than your group name, is dsquery. So you're doing a dsquery group, the sam account ID name, and this is all you need to know. So if you take this line, get members, and then process the sam account IDs, you take that line, put it in a bat file, and then pipe that to a text file, you're going to get a list of users, usernames, which you actually need, or the host names which you need, to add to your options file.

So now once you get it, it's going to give you a table output. So then you just need a secondary process to go in, because the option file requires the user names or the host names to be separated by a space in a linear fashion. And that can be done pretty much with any other type of scripting and stuff like that. So I'm going to turn it over to Jerry. He's got to talk about one tool that we both love. But Jerry is the master of it, and he loves it the most. It's lmutil.

PRESENTER 1: I guess it's because I started life in the industry as a Unix administrator in the days before there was much GUI there. So I spent my entire life at a command line. It feels warm and fuzzy to me.

So everybody that has a license manager gets a copy of lmutil. It's just a command line executable. There's a lot of power in it, so we're only going to scratch the surface of it in this class. There's a document that comes with the license manager. It installs in the folder where you install the license manager. It's a PDF file. I strongly recommend that you go in there some day and actually do the boring thing and read chapter 12. It could really inspire you. Hey, I was trying to do this over and over and over again. It was really hard. I'm clicking on lmtools, and I only see the little window. So read through this thing. You might find other possibilities than we're talking about that are of use lmutil.

And what I do typically on my workstation-- and I don't really usually execute lmutil on the server. I execute lmutil on my workstation. And I create a folder on my computer. I call mine bin. Once again, it makes me feel good because it sounds like Unix. But you can call it anything you want. But I put all the different utilities that I use, all the executables that I use, in there, and add that to my command path. So then I don't have to switch into a particular folder to run those things. Just makes life a little easier.

I really hate typing. I like command line, because I can see what's going on, but I don't really love typing. So this cuts down on how much typing I've got to do.

So I'm going to go over a few examples. lmnewlog is special because you can't do this in lmtools. There is no function like lmnewlog in lmtools at all. And what this does is it archives the report log, the .rl. Who records RLs on their license server? Good chunk of you, OK. So if you have flexnet manager, flexnet manager will automatically rotate that log file for you so you don't have to touch it. But if you're using SAMReport-lite, or if you're just simply building the report log for a second source of truth against something else, which a lot of people do, then you've got this file that's growing. And like anything else that grows, as it gets too big, it starts causing problems.

So the idea is to take this script that I've written, run it on the server once a month using a schedule task like Tiny just showed you for his Active Directory integration. So we do the same thing with this. And we run this lmnewlog once a month, is typical, and it builds a monthly archive. And if you look at the example here that I've got, it's lmutil lmnewlog function. Minus c says pointing to where the license is. OK? And I'm saying, you'll find it on @127.0.0.1. Now if you talk to any Flexera person, the guys who work for Flexera, makes ths stuff, they get mad when they see this. Oh, you shouldn't, you shouldn't do this. But this particular is a special situation. You can calm them down, because what this is designed to do is, I can take the script just the way it is and run it on any machine.

The only time it doesn't work is if I happen to be, say, in the UK. They use a different time and date format. So when I parse the date out here, it scrambles it. So you've got to go in there and adjust the parsing there. That's all. So when you wrote the first time, if it looks like gibberish, the file name looks like gibberish, it's because you're on a non-US date and time format. And once you stare at it for a few minutes, it's pretty easy to adjust the parsing for what you have.

Now, there are some accounts that you'll run into where if I save this is a batch file and try to schedule the Task Manager, it's going to generate a bunch of errors saying your service account doesn't have run as batch permissions. And if that occurs, and your IT security people don't want to allow you to give the service that permission, what you can do is instead you schedule lmutil. And then and that Task Scheduler, it says, what parameters do you want me to pass to that program? And you just give the rest of the line as a parameter. And then you've gotten around the fact it doesn't want to run a batch file.

I use this one as an example, because it's also got a gotcha. So the typical use case for this is people write scripts that use lmreread, particularly when they have, say, a centralized bank of option files. And you'll do the edit the options file on a central machine. And then they'd write a script that copies the options file out to their servers and then does an automated reread. So it's one edit, one button to reread, and they're done. What's the gotcha? Anybody know?

The gotcha is, if one of these rereads fails, and it's an automated script, and the command window opens and closes, you don't see the error. So you assume all three of these servers got reread and have the new information you got. And one them failed. That's why if I'm doing this interactively, I just go ahead and I put a pause at the end of my batch file. And I can look to see what happened. If I'm not doing that, I want to do one of several things. I can always go in and track for errors, error codes. After each one of these, do an if and see if I have an error condition, do something else, like send an email or whatever so you know what happened. Or you got to go and look at the debug or server status to make sure that reread really occurred.

Because it's not uncommon for a network glitch to kill a reread. It'll work again in two minutes from now, but it's not uncommon for reread to fail.

Now this is the most powerful part of lmutil. And this is what I use day in and day out in my work and Tiny uses in his. And a lot of Tiny's automation is based on information that we pull out of the license manager using lmstat. And essentially, it provides you information on licenses and the health of the license server. It has some flags you can use-- you have to use, so the most typical one is minus a. It basically dumps all the information out. It's very verbose.

Minus s is specific to a given vendor, say, adskflex, which is a Autodesk vendor daemon. I seldom use the minus s because usually I fixe the port number that lmgrd runs on for every vendor in a license server. So if I've got brand x and brand y and all this licensing, I put them all in specific ports so I can find them reliably. So what I'll do is I'll say, minus a, well, I'll do a minus a. And when I specify where the license is, I say 27,002 at whatever the server name is. OK? And then this way I don't have to bother with the s. Same thing. Minus f gives you feature specific information.

I personally don't generally deal with this either. I just dump everything a, dump it to a text file, and then massage the data that I need to see it once it's in the text file. That's generally how I do it. Tiny does it otherwise. Furthermore, the minus i gives you a nice neat looking table. It's a fixed column table. Tiny likes to use it for a lot of things, and he's got a couple of good reasons to do it. I'm going to let him talk to this particular part of the lmutil in a minute.

I don't use it. What I use instead to get my columns of information about what's in the license file, I use the license parser. Anybody use licenseparser.com Check it out if you haven't. It's an Autodesk site, actually. And it still says to this day, it's been out there for what, about five years Tiny? And it still says it's beta, but it's there.

So the lmstat minus a gives you everything. And I'm going to kind of quick quickly go through this. Same thing for this one. And F what I want to get to is here just to talk a little bit about the output that you see. So basically, I didn't know this is an lmutil, lmstat minus a and pipe that to a text file. So I can search on any of this information in here. So if I can parse the information out the way I want to see it.

A couple of things that are important. You've got the vendor daemon version right, here you've got the master daemon version up here. So if you're required to have a certain version, it's a quick check for you. And here you see what really loaded, not necessarily a file that on your server. I've seen many times somebody accidentally configure the license server at a different group of files than what they thought they were doing, because they had two instances of the software installed. One was installed, when it was copied. And they just configured the wrong one. Here you see what's really happening.

The feature, of course, this is the license that you're actually trying to use. And probably one of the most important things is, who's got the license borrowed? Once again if you're running flexnet manager, that will tell you. But if you're not using flexnet manager, which is Flexera's high end reporting mechanism, if you're not using that, you don't know who's got anything borrowed. You don't know if anybody's got something borrowed unless you're looking for this linker flag. And I actually produce a report that's just a quick script file. I run this thing. I filter on the word linger, and I get a list of everybody who's borrowed something.

And then a lot of people don't realize this. This crazy looking number at the end is the number of seconds that the license is borrowed for. So simple arithmetic, you can use to calculate borrow time in something that's usable like days. And then over here, you've got the user, the PC, the license server, the port, time and date that it got started. All available information.

Ideally, unless it's a borrowed license, you don't want to see anything that's not today in this column. Can anybody tell me how you avoid having what happen? Something older than today? Licensing use?

AUDIENCE: [INAUDIBLE]

Well, no. You can just set the time out all in your options file. And time out all will pull them all back in if someone's not using it. So in a moment I'm going to turn this over to Tiny to tell you how he uses the i switch on the lmstat. Like I said, I don't use it. I virtually never use it. Tiny uses it a lot, to let him talk to this particular slide.

Thank you, Jerry. So basically, the dot i is-- and I'll show you an output that it actually generates-- one, easy to parse. One, if you're doing scripting and automation, the option to have a licenseparser.com give you feedback and stuff like that is kind of difficult.

But licenseparser.com is a great tool. I use it the same way everybody else is. Used to take my 10 or 12 licenses and drop it on there and export it and pull out the features and populate my options file. It just got real hectic doing that, for me.

So I started using the -i because I could parse this out and get all my features, and then I could easily populate my options file that way. Also, it will tell you your license count. It also will tell you if there's an expired license out there-- a very easy, quick identity there. Go there.

So this leads up to we've talked about lmutils, switches, and stuff like that. Here's another tool that I've posted out there that you can download, the freeware version. And basically, it's a flexLM utility.

So if you are a license manager, an Autodesk license manager here, you probably have some time where OK, I need to know what my license servers are doing, I need to know to check the statuses and stuff like that. And you might have multiple license servers. In my case, I don't want to have to go RDP into every single one of them and run a report.

And also, what I wrote was, again, a VB GUI, and all it is is a shell. Everything it's doing is just what we taught you. We're running the lmutil with those parameters, and it's feeding back information that's usable, and it's feeding it to multiple servers all at once. So it's going to concatenate the reports and bringing back information for you.

Now, what I have is on the GUI, you have your FLEXlm license servers. You can go in here and specify the port at, and then license server name. If you don't use ports in your license file, which you should not do, or it's strongly suggested to use the ports, you can just put @ and then your license server name. And then you got a plus or minus so you can add that to it.

Next is actually the feature list, and if you-- if anybody knows real quickly anything different about the feature list here? One is in order by the product, because I stripped off the first five numbers. And all. So the GUI tool, originally I just had the whole feature name there. Well, every time I wanted to run a report on, I needed to know how many AutoCADs I got out there. And I use-- I had to go here, scroll down, go here, scroll down.

So the tool automatically pulls all the unique numbers on the feature code, so that you get all the products in the list in alphabetical order. In the tool, there's multiple-- this is just a drop down for the report you want to run. And up here is the reports. I have it categorized as custom reports and FLEXlm reports. The only difference is all of these are running the same FLEXlm, lmutil parameters. The only difference is I'm taking the output and parsing it inti a fixed width text file that you can view and easily read.

And also-- nothing magical going on here. The one thing that you'll see, there's a little trim here is, you'll have a total license by server. And then you have total license by server selected. And then you have license by feature, licenses by feature selected.

Any time you choose the selected one, it will open up this, where you can actually select not only which servers you want to run it against-- multiple or just one-- also which features you want to run it against. So if you want to see, I want to know the total licenses on this new server. I just got a new license file for all these features, or I just bumped up my AutoCAD. I want to know what the new license count is, it's easy to go through and run it and get a snapshot of that.

Some of the most useful ones I found is licensing use by feature, licensing use by user, or borrow. How many people has got the licenses borrowed? Who's got it specifically? So it runs a lmutil again, the dash A command. Reads it, populate it, finds the linger, just like [INAUDIBLE] was talking about, parses it out and puts it in a readable format.

One little nifty one I actually like, and I made specifically. Because every time we get license files, I have to go in there and drop them in a location that populates all my servers and stuff like that. But I used to run to licenseparser.com to populate this tool with all the new features.

So this tool is run by, again, an INI file. And at the bottom it's got a list of features, and it's got all of them with that five character number. And I used to wipe it out and paste it in there. Wipe it out and paste it in there. And I was like, well, I can just use the dash-i. Run it after I've already updated all my license servers. And it gives me all the unique-- I can just parse out all the features.

And it's going to automatically update this GUI for you. And it automatically pull out just the unique features that you have in all of your license files. And then if you want to take that and export it out and send it to another spreadsheet you might have, doing some automation calculations or usage data or anything like that, you can easily export that out into a list.

Again, this is the Verbose raw report, the flex report. So you can do the same thing, but what you're going to do is notepad-- every time you run this report, notepad is going pop open and show you the report. This is going to pop open notepad, and it's going to have that very verbose language that FLEXlm utility is going to give you.

You can also run information on your vendor demons and your lmutil version. So you know you just went through an upgrade. You went to 2017. You updated all your license servers. I got 10 or 12 or 20 license servers. I don't know how many you got. I need to know, did I do them all right? Did I miss one? Did somebody not do their task? I gave it out to all the regions and stuff like that. I can just highlight them all, run that utility, and it'll tell me what versions on all the servers there are.

One thing I did as specifically for this class is extracted data. Because what I do is I run the lmutil command. It dumps out that very Verbose information. I process it and pull out whatever I want out of it. And I created in a CSV format a nonsummarize CSV. And then I go through and summarize it and pull out unique values and total values and stuff like that.

So if you just want the raw CSV without all that Verbose information, you can click here, and it'll pop open notepad with a CSV with all the data out of your license files.

This is just an example of one of the reports. In the reading guide for the class sign-up sheet and stuff like that, I had a number of these snapshots. Just for sake of time, I didn't include them all in here. So this is the licensing use by feature, listing all the current users.

So here's the servers. And I ran it on maybe all 10 servers. But these were the only ones maybe that had licenses. So you can see, and that can give you a clue, hey, I ran it on five servers. I really should see five servers listed here. Are one of my servers down? And why is there no usage on my server?

Also here is a asterisk to indicate that this is a borrowed event. And I calculate those seconds. This is when that borrowed event should expire. Because that's how long they borrowed it for. And also, if you haven't controlled your borrow limit, if you see somebody's borrowed it for six months, you might want to talk to that individual.

And so it gives you all the information. And here is this user is actually coming off of this server. If you go down here, this user is actually coming off of this server. So you know where they're pulling their data, and if you're across time zones, and you don't want that, across regions, that's a good indicator. Why are these users, or why are these PCs in Asia, hitting the server when they should be hitting a different server? So that's free. It's out there for you.

Now I'm going to turn it over to Jerry about the desktop setups.

PRESENTER 2: Thank you, Tiny. Well, this thing's got a sticky key every now and then. So it's often desirable to figure out what's on your desktop, as we spoke before. I'm going to talk about some of the key pieces of data you can query off of this thing and collect.

Environment variables, of course, are important. And also stored in a similar area on the registry is a thing we call breadcrumbs. Who knows what a breadcrumb is in FLEX talk? Breadcrumb is basically an area in a registry that FLEX stores the last, not just the last, but a list of successful license pulls.

So it says, I pulled a license from server a, I'm going to add them to this list. Pull license from server b, adds it to the list. It sounds really cool. It gives the software a strong will to live. Because even if someone clobbers the environment variable or something, you're still able to start the product. And everything's really hunky dory until you don't want Joe get to that server anymore.

You clobber his environment variable, and lo and behold, you still see him in there when you look at the log file. It's because there's a breadcrumb. So while it's a good thing sometimes, it's good for rote, it's good for medium sized and small environments. It really is good. It's very handy.

And for an enterprise, it can be a real headache. And just learning how to deal with them and knowing that they're there is important. So I'm going to talk a little bit about those.

We also want to be able to make sure when we're querying the desktops to figure out what we want to do with them, we want to make sure they've got good solid communication back to the license server, right? So we're going to talk a little bit about a couple of different methods to do that.

And then you quite often want to know the insulation type, whether standalone or network. And maybe the serial number that got installed, particularly for standalone, for compliance reasons. You don't want serial numbers on your network that you don't own, right?

So the ADSKFLEX_LICENSE_FILE variable is the variable used to point to multiple servers. And of course, it follows the order that they're in. After, by the way, it looks at the breadcrumb. It looks at the breadcrumb first.