The Flex Wing: how to use a license file to bring strategic tactical immense MBA value to your business and stuff

This post is one in a series of irreverent blog posts on the topic of software licensing. 

FlexLM and Furious: setting up a license server
FlexLM and Furious: restricting FlexNet license usage
FlexNet, FLEXnet, FlexLM, FLEXlm, it’s the same product, stop renaming it you crazy marketing people: an overview.

WAR!

Software licensing is a war between your cardigan-wearing procurement group and the software vendor sales team (usually salespeople wearing pinstriped suits who fly private jets). License file generation is an extension of this negotiation, which is why I've dedicated a quarter of this blog post to discuss a third of the topic. But let's first begin with license files, without which we wouldn't have license servers, vendor daemons or headaches.

Requesting the FlexNet license file

Up to 167% of a vendor account manager's time can be spent issuing license files, issuing updated license files, guiding the customer through updating their license files, explaining licensing restrictions, forcing their internal licensing group to reissue an incorrect license file, listening to customer complaints about license files, determining whether the customer complaints should be referred to the police, and secretly wishing their internal licensing group could hear the customer complaints.

Requesting a new license file usually involves filling out a long form that contains lots of personal information that, quite frankly, scares me. They'll ask things like what the MAC address of your license server is so that you can't give it to your friends (everyone on the internet). If you are getting a license file reissued, the vendor will make you fill out the same form except charge you $190. This is to pay for the cost of reissuing the license, which takes about 5 minutes for them to do after you've spent 3 weeks getting a purchase order.

Once you get the license file, you should immediately put it in a random location you'll forget, probably the digital equivalent of where you keep your receipts or birth certificate. Although license files have the file extension of .lic, be sure to name it something helpful like ntoskrnl.exe or latestLicenseUpdatedtoV2-NEWESTDontUseIGNORE-MUSTUSETHIS.lic. If you rename the license file to something descriptive like the name of the vendor daemon (ie. abaquslm.lic), you're just showing off. If your application has multiple license files (eg. ESRI), be sure to place them in different folders on different data drives. That way, people who don't understand your random license file layout will know that you have mad licensing skills and then join your posse.

The vendor daemon is adskflex.exe.
The license file is adskflex.lic.
It's in a folder called adskflex.
When the license file is updated, a backup copy is made in the Backup folder.
You don't have to be a rocket surgeon to figure this out.
(a rocket surgeon is a guy like Norman Einstein)

Negotiating FlexNet license features

Just as the vendor sales team screwed you during negotiation, the licensing team will try to screw you during delivery. Remember, it is the job of the vendor licensing team to deliver as little functionality as contractually obligated in order to open future sales opportunities.

You: "We purchased ten BizzaroCAD licenses. Please give me a license file so my Australia and Mumbai teams can work. Some team members use BizzaroCAD while traveling."

Software vendor: "I can give you a license file which is time zone locked to Antarctica with borrowing functionality disabled. Everything should be fine for your five person team."

You: "Five licenses? We purchased 10! And you agreed to enable license borrowing!"

Software vendor: "You should talk to our sales team to get those features."

On the other hand, you may be lucky and have a naive software vendor. Some vendors in the medical imaging space like to be "lenient" to their customers because they "help save lives". Amateurs! You must abuse their trust so they can learn and their culture can progress to that of Microsoft's. If you don't abuse their trust, how will they cope in the real world? Here's an example.

Software vendor: "I see you are licensed for 10 concurrent users! Let me gen..."

You: "I want a license file allowing 5000 concurrent users!"

Software vendor: "That is an unreasonable request."

You: "YOLO"

Insist that the licenses aren't MAC address locked to any server. If the vendor hesitates, point them to this VMware KB article then laugh at them. When they capitulate and generate a license file that isn't server locked, post the file on The Pirate Bay. This will demonstrate who calls the shots: you, and the hamster on the wheel in your head. Or the hamster who manages enterprise software licensing at your organisation. Either or really.

See that 'ANY' and 'permanent'? That's example of a licensing WIN.
Oh, and it's not a real license file. HJK3AFH4 is only 8 characters,
the real one is 13 characters. You can test if you don't believe me.
But if you don't believe the word of a person on the internet you've never
met before, who can you trust?!

Serving the license file

Now that you've got your license file, you'll need to load it so that idiots can use their stupid license-locked applications. This is done with the FlexNet License Server (lmgrd.exe) of which there are many versions in common circulation. The good news is that it's easy to check the version (just right-click on the file in Windows Explorer and look for the version). The bad news is they all suck.

The FlexNet License Server (lmgrd.exe) is a standalone executable: you can place it anywhere and it will work. You can easily upgrade the lmgrd.exe license server too: if you've got a newer version, just replace the old executable with the newer version you downloaded. Of course, this will require you to stop the license server. Watch out.

I would rather play this game than restart the licensing server at...well, any company.

Upgrading the FlexNet license server

Backward compatibility is an important feature of computers. The backwards compatibility features of the Xbox 360 allowed you to play older Xbox games (and if you JTAG'd your console, PlayStation, Super Nintendo, Nintendo, Atari and ColecoVision games too). License servers are similarly backward compatible, meaning that a vendor daemon compiled with an earlier version of the framework will work with a newer license server. This means your license server version needs to be equal to or newer than the FlexNet framework used to create the vendor daemon. For example, if your Autodesk licensing daemon is version 9.0, you need a license server (lmgrd.exe) version of at least 9.0. Running FlexNet license server version 8.0 with a 9.0 vendor daemon will cause your server to burst into flames, which may or may not wake up your datacentre and facilities managers.

Generally speaking, it's better to run the newest version of the lmgrd.exe license server. You'll get access to the new features, and it's more stable due to Flexera phasing out parakeets from their development team in favour of humans. The latest version of lmgrd.exe and the LMtools license management application is always available here. Don't ask me why the domain is globes.com. I think that was the name of Flexera three acquisitons ago. I miss those parakeets.

Upgrading the vendor daemon

As the name would suggest, each vendor will have their own vendor daemon. If the vendor is an software company that has lots of acquisitions, they could have multiple vendor daemons for their products (I'M LOOKING AT YOU AUTODESK!). Thankfully, vendor daemons are usually easy to find on the vendor website. If you're lucky, the vendor daemon (such as this one from Autodesk) will be available as a small standalone 300kb download. If you're unlucky (probably you if you're reading this post), the vendor daemon will only be available in the 8.4gb source media file in a members only part of their website which requires a secret handshake from an account manager.

Making sure licenses still work after you've upgraded the FlexNet license server/vendor daemon

It's important that you use the most recent vendor daemon and FlexNet license server as possible, because newer versions support newer features and keywords. Did you just try to use the PRIMARY_AS_MASTER keyword with a vendor daemon compiled with version 9 of the FlexNet licensing framework? You imbecile! Didn't you know that the PRIMARY_AS_MASTER keyword wasn't introduced until version 10?! Didn't you drink enough milk as a child?!

Getting LMtools (lmtools.exe)

You might think LMtools is a badly written piece of crap.





Anyway, thanks for reading! I hope to bring some humour to the most boring topic in IT. Probably not.

FlexLM and Furious: setting up a license server

FlexNet is a licensing framework used to control access to software. Negative people like to call it the worst piece of software ever made by human kind, but I like to think of it as the best piece of software ever made by lobotomised parakeets. This blog post demonstrates the tedious process of setting up a FlexNet license server. Although I've only described how to install a single license server, you can repeat steps 2 to 8 to serve license for as many FlexEnabled products as you like. Lucky you!

If you're unfamiliar with any of the terms in this blog post (license server, license file, vendor daemon, grand royal with cheese), read my previous blog post on the topic.

Scenario
You work for Contoso. Contoso has purchased licenses for Autodesk AutoCAD and MATLAB. You have been asked to set up a license server so the products work and your boss doesn't fire you.

Before you begin…
Software vendors usually package FlexNet with their products. Unfortunately, vendors almost universally package FlexNet in a way that prevents you from using the license server to serve other products. So don't install the FlexNet from the vendor's installer. Use my instructions instead! All your wildest dreams will come true!

Step 1 - Install the FlexNet License Manager

FlexNet is a stand-alone application that does not require installation process. This step involves downloading the latest versions of the FlexNet binaries and placing them in a folder on your server. All you need to do is

1. Download the latest versions of the following files from the Flexera website
   1. lmtools.exe
   2. lmutil.exe
   3. lmgrd.exe
2. Create the folder C:\Program Files\FlexNet
3. Copy lmtools.exe and lmutil.exe to C:\Program Files\FlexNet

While I suggest using C:\Program Files\FlexNet, tossing all the files into C:\Program Files\StarCraft is okay too.

Step 2 - Identify the vendor daemon name

For this step, you’ll need to open your license file in Notepad. The license file is provided to you by the vendor in exchange for money.

The vendor daemon name is specified on the VENDOR line of the license file. This is illustrated in the following tiny screenshot. In this example, the vendor daemon name is MLM.



The vendor daemon is an executable file. If you look in your license file, the vendor name will be located after the DAEMON keyword. Now that you know what the vendor daemon name is, you can…


Step 3 – Create a subfolder under FlexNet for the vendor daemon
In this case, you’d create a folder called C:\Program Files\FlexNet\mlm


Step 4 – Find the vendor daemon
If the vendor name is MLM, the vendor daemon will be mlm.exe. If the vendor daemon name is ADSKFLEX, the vendor daemon will be adskflex.exe. Vendors typically publish the latest version of their vendor daemon in their website. If you can’t find it, try looking on your source media.


Step 5 – Assemble license server files in folder
Now copy the following files into your folder

• the vendor daemon (which you downloaded from the vendor website)
• lmgrd.exe (which you downloaded)
• the license file (provided to you by the vendor)

Once you’ve done that, create the following blank files

• vendorDaemon.debuglog
• vendorDaemon.log
• vendorDaemon.opt

where vendorDaemon is the vendor daemon name. Once you’ve done all this, your folder should have 6 files.



Step 6 – Register the license server as a Windows service
If you don’t register the license server as a Windows service, it won’t start when your server starts. To register a license server as a service, you’ll need to use the LMtools (lmtools.exe) utility you downloaded in step 1.


Caution: follow these instructions carefully! The LMtools application is the Ralph Wiggum of management consoles. If you click Save Service at the wrong time you'll end up with a useless Windows service called Flexlm Service 1.

1. Open the LMtools utility (lmtools.exe)
   
   
   
   The picture of the world symbolizes the world of pain you will be in.
   
2. Select the Config Services tab.
   
3. Delete the contents of the Service Name field and enter whatever Windows service name you like. If your license server is for Autodesk, you might want to use Autodesk License Server
   
   
   
4. In the Path to the lmgrd.exe file text field, click the Browse button and select the lmgrd.exe file you copied into the vendor daemon subfolder in step 5.
   
5. In the Path to the license file text field, click the Browse button and select the license file you copied into the vendor daemon subfolder in step 5.
   
6. In the Path to the debug log file text field, click the Browse button and select the lmgrd.exe file you copied into the vendor daemon subfolder in step 5.
   
7. Click the Use Services checkbox.
   
8. Enable the Start Server at Power Up checkbox.
   
9. Click the Save Service button.

This will create a Windows service. You can verify the service has been created by using the Computer Management console.

Step 7 – Set the service to automatically restart
In the unlikely event of a license server failure, you’ll want the license service to automatically restart so you won’t be pestered by users. To do this,

1. Open the Computer Management console
   (Start > Run > compmgmt.msc)
   
2. Click on the Services node
   
3. Right-click on the license server service and edit the Properties of the service.
   
   
   
4. On the Recovery tab, set the first failure, second failure and subsequent failure action to Restart the service.
   
   
   
5. Start the service
   
6. Close the Computer Management console.

Step 8 – Prevent users from shutting down license server
By default, any user has the ability to stop a license server remotely. I’m not sure why this functionality exists, but it can (and should) be disabled with a registry setting.

1. Open the Registry Editor
   (Start > Run > regedit.exe)
   
2. Navigate to the key
   HKEY_LOCAL_MACHINE\SOFTWARE\FLEXlm License Manager
   
3. Click on the application license manager
   
4. Change the value of the cmdlineparams entry to
   
   -local
   Important note: there is a space before the dash
   
5. Close the Registry Editor.

Done! You’ve set up a license server manually! How boring. If you want your license server to serve licenses for multiple products, simply repeat steps 2 to 8. Just wait, didn't I write that in the introductory paragraph?

How do you determine the version of FlexNet used by a vendor daemon?

The FLEXnet licensing framework is designed to limit the use of software to legitimately paying customers. Instead of achieving this goal, it punishes and annoys legitimate buyers while making it easy for cracking teams to defeat their software protections. Have you written a fake vendor daemon that always responds with "LICENSE AVAILABLE"? Congratulations, you've cracked every piece of software protected by FLEXnet!

One of my peeves with FLEXnet licensing was that not all vendor daemons were created equally. When a software vendor wants to protect their software with FLEXnet, they create a vendor daemon using the FLEXnet framework. This vendor daemon contains the business logic of license availability: it reads the license file, figures out whether you're entitled to a license, and gives the yay/nay. As Acresso try to clamp down on cracks, new versions of the FLEXnet framework are released with new features. If a vendor is on the ball, they'll update their vendor daemon. Fortunately for software pirates and cracking teams, most vendors aren't. Unfortunately for legitimate paying users, not understanding what version of the FLEXnet licensing framework a particular vendor daemon was compiled for can result in mysterious errors.

Example: the PRIMARY_IS_MASTER directive (which forces the first FLEXnet server in a triad to be the active node) was introduced in FlexNet 10.8. If you try to use this directive in a license file for Autodesk vendor daemon version 9.2.2.0, the license server would crash with an incredibly informative error message like "Error: there is an error. Refer to error description (Description: Error Occurred)." HELPFUL!

So, how do you determine the version of FlexNet used by a vendor daemon?

1. In the LMTOOLS application, click the Utilities tab then click the Browse button.
   
   
   
2. Select the vendor daemon executable then click Open.
   
3. Click Find Version.
   
4. Text will appear in the status window. The version is the number directly after FLEXnet Licensing.
   
   

FlexLM and Furious: Restricting FlexNet license usage

FlexNet licenses are expensive. Sometimes they can cost all your coffee money so it's no wonder you might want to restrict their usage. The FlexNet framework offers a horrific mechanism for restricting license check-out: the options file. Typically named license.opt, the options file is a configuration file that doesn't make sense to anybody.

A typical FlexNet license server folder containing an assortment
of files. The options file is labelled ‘4’. Depending on your region, this
may appear as IV or 四.

 

The options file allows you to restrict license check-out to authorized users (informally known as, "stopping those filthy students from other departments too cheap to buy their own darn AutoCAD licenses"). Can you restrict license check-outs to people in an LDAP or Active Directory group? No. You're restricted to lame methods like

1. Computer name - This might be useful if you want to authorize license checkout to computers in a specific computer lab or the nodes in a high-performance compute (HPC) cluster. If you're a university, your HPC cluster probably consists of over-clocked Celerons in a datacentre. And if you’re a university, your datacentre is probably a broom closet with an Apple sticker on it.
   
   
2. User name - If you include the line INCLUDE matlab USER paul, I will be able to check-out a MATLAB license for my Donald Trump popularity modelling project. But what if I login from a personal laptop where my user account is DoctorPaulMedicineMan? License check-out denied! And did I mention FlexNet treats usernames as case sensitive? If I login as PAUL or even Paul I'll get the same error: check-out denied!
   
   
3. IP address - this is useful in approximately 0% of circumstances. If your users use DHCP, it's useless. If your users VPN in, they're assigned a VPN address which is useless unless you want to give access to everybody who VPNs in (in which case, you're useless). If your desktops use static IP addresses, you've probably got bigger problems than restricting license checkouts.
   
   
4. Subnet - this would be useful if the programmers at Flexera knew how to subnet. In the magical FlexNet world (I'm not sure how to get there but I think it involves being at the Flexera offices and eating lots of mushrooms) there is no such thing as CIDR. To allow all the users in 172.16.0.1/24 access to the AutoCAD license, you simply include the line INCLUDE autocad INTERNET 172.16.0.* Simply place the asterisk in the subnet octet you want to permit! Awesome! Now, what do you do if it's a /25 and the next subnet is full of hungry AutoCAD who will consume all your licenses like piranhas with humans in a villain's lair?
   
   
   
   Piranhas can be restricted using an options files.
    
5. Display - you can restrict the check-out of licenses to a /dev/tty or Windows Remote Desktop client name. This was last used when tested in 1987 by a Highland Software engineer and the FBI currently offer a $25 million reward for any tips leading to proof this feature is used.
   
   
6. Project - check-out is restricted to users who have a environment variable set. This is unfathomably useless.

With all these useless mechanisms, how can I properly restrict license check-outs? I'm glad you asked.

1. Free for all! - if you're reading this blog post, you’re probably looking to restrict license usage so a free for all solution probably isn't acceptable in your organization.
   
   
2. License slave - designate somebody in your organization as a 'license slave'. Restrict license checkouts for controlled applications/features using an options file. If a user wants access to a feature, have the license slave add their username or hostname to the options file. To ensure they are always available to update the options file, simply handcuff them to their desk.
   
   
3. Leverage identity management! - Create a security group for each feature/application you want to restrict. For example, if you want to restrict AutoCAD check-outs, create a security group called Authorized AutoCAD Users Bagel. With some clever ETL skills, you can transform the contents of this security group into an options file! Could this be the topic of an upcoming blog post?!
   
   
4. Leverage directory services - The poor man's version of the above. Instead of using your identity management system to convert the contents of a security group into an options file, write a script to do it. Setup a scheduled task to run this script every second. Don't dare comment the script - this will allow somebody beside yourself to understand it which can only undermine your job security.

Thank you for reading. I'm unsure what my next licensing blog post will be on. Maybe alligators. Or that identity leverage thing.

 

FlexNet, FLEXnet, FlexLM, FLEXlm, it’s the same product, stop renaming it you crazy marketing people: an overview.

Hundreds of years ago, software vendors had a problem. They realized distribution of their software was uncontrolled after they sold their products: that is to say, people pirated their software. Vendors had to rely on the goodwill of their users to not copy their software. Until FlexNet was invented in 1988, times were hard for software vendor salespeople.

Sales person: “Hello customer! I can sell your company 100 licenses of this expensive product for the low price of $100,000!”
User: “If I buy 1 license, will your software stop me from installing it on 100 company computers, all my friends computers and all the computers in my brother-in-law’s electorate?”
Sales person: “No.”
User: “In that case, I’ll buy 1 license.”

Over the next two decades, the FlexNet licensing framework (aka. FLEXnet, FlexLM, Flexlm, Flex Kal El, Flex LM2: Electric Boogaloo and El Flexacabra) would allow vendors to minimize this problem. This worked by having a license server that would keep track of how many licenses were in use, how many licenses the user had purchased, and how many cabbages would be thrown at the user if they tried exceeding this limit (typically a student trying to use a pirated copy of AutoCAD).

But how did they restrict the software to the licensed computer? They did it by locking the software to the only unique and unchangeable serial number a computer has: the MAC address of the network adapter. When you purchase software that is FLEXenabled, the vendor will ask you for your license server MAC address. They will give you a license file which is locked to this MAC address. If you do not provide the vendor a MAC address, they will steal your automobile’s air freshener. It may seem harsh, but this is the price of software license management.

A typical MAC address.

Once you have a license file, you can setup your license server. This server needs to be reliable otherwise people won’t be able to use the legally obtained software your company has purchased, driving them to a life of unhappiness and overeating. Your license server needs to be network connected (2600 baud token ring should be fine) because FLEXenabled applications on your client computers need some sort of layer 2 network connectivity to send their license check-out requests.

So Mr. Paul, tell me more about this type of exercise!

OKAY! At its core, FlexNet is a service on a Windows server (or a daemon on a Linux server). In Flex terminology, each service/daemon is referred to as a license server. Here is a screenshot of multiple FlexNet license servers installed on a Windows server. You will require a video card to view the following image.

The Windows Services management console. To access this screen, you will need enough money to buy a Windows license.

I have highlighted the FlexNet license servers with red boxes. If your computer only has a CGA or EGA graphics adapter, these may appear as black or light blue boxes. Are you impressed? We can take that one step further. If your computer has Microsoft Silverlight, you can zoom further to reveal more. Let’s zoom in on the Autodesk License Manager to see what the heck a license manager service consists of.

A folder containing the FlexNet licensing components. In Linux, the Windows logo in the upper right is replaced with a penguin.

Each FlexNet license server consists of 6 components.

• The FlexNet license manager (lmgrd.exe) is the server that does everything. When started, it starts the vendor daemon (more on this later), hogs a port (usually 27000) and waits for license management queries. When an application says “My stupid user wants to model Donald Trump’s hairpiece in AutoCAD, are there any AutoCAD licenses remaining?”, the FlexNet license manager replies helpfully with “What? I’m just the project manager, I don’t do any work! Go ask the vendor daemon on port 1234.”
  
• The vendor daemon contains the business logic required to determine whether a license is available. When started, the vendor daemon will hog a port and then read the license file to see what you’re entitled to. It will then wait for referrals from the FlexNet license manager. When the client contacts it asking for a license for a particular feature, it will respond with either yay, nay. If it responds with yay, the application will work. It it responds with nay, the application will respond with “YOU HAVE NO LICENSES: BUY MORE LICENSES DEADBEAT” and then fill your house with ghosts who will push you down the stairs and break your legs.
  
• The license file contains your entitlement information. A FLEXenabled application could contain many licensed features. For example, the Autodesk Education Suite 2010 consists of the following features, some of which you may or may not be licensed for:
• Autodesk AutoCAD – 10 licenses
• Autodesk 3ds Max – 1 license
• Autodesk Green-Up-Your-Building-Yo – 60,000 licenses
• Autodesk The White Album - unlimited licenses
• Autodesk Toupee Modelling – 2,000,000,000 licenses

The license file also contains information on which vendor daemons are allowed to read it.

• The options file allows license check-out to be restricted. You can restrict licenses to IP addresses, IP ranges, hostnames, usernames, or a combination. This is a useful feature if you think that people named Paul are morons who should never be allowed to use AutoCAD let alone a computer or a refrigerator. The file extension is .opt. If you give an options file a different extension bees will swarm your local pool.
  
• The log file contains any server related events (ie. logging when the license server has stopped, started, failed, died, submitted its tax return, run over pedestrians, etc.). The file extension is .log. If anything goes wrong it is about as useful as a log. If you are having issues with your licensing, do not send me your log file. I cannot emphasise that enough.
  
• The debug log file contains license related events (ie. when licenses have been checked-in or checked-out). File extension is .debuglog. If you are a linux neckbearded geek with no life, you can write an application which reads this .debuglog file and tells you which license features are most popular (probably that toupee modelling one) and which ones are least popular (so you can stop buying those features and spend the money on Domo merchandise).

How do license checkouts work?

FlexNet is a client-server application. That is to say, the client (your end user) wants to kill the server administrator when the licensing is broken (in a good year, this can be up to 99% of the time). However, in the unlikely event your license infrastructure is working, the license check-out process is as follows.

1. Client contacts the FlexNet Server
   The client (typically a laptop user in a north pole igloo) starts AutoCAD. AutoCAD looks in a few places (system environment variables, Windows registry, licensing files, adjacent barrels) for the hostname and port of the FlexNet license server. It will ask the FlexNet license server for the vendor daemon port.
   
2. Server responds with vendor daemon port
   The FlexNet license manager replies with the port of the vendor daemon and sometimes the location of your neighbourhood chemist.
   
3. Client responds with license check-out request
   The client responds with “AutoCAD license: give me 1.”
   
4. Vendor daemon checks license file
   The vendor daemon determines whether any valid licenses are available.
   
5. Vendor daemon replies with yay/nay

So there you have the basics of FlexNet. It is a completely foolproof framework for preventing filthy pirates (read: students) from pirating your application. Some questions still linger: how can I make my license service redundant in case someone drops a lobster into my license sever and destroys it? Where should I purchase cheap name brand footwear? What colour is a license file? I will address these issues in a following post if I feel like it. Stay tuned.

Setting up an Aladdin HASP license server

In my last licensing blog post, I wrote about how AnywhereUSB devices could be used to virtualize physical license servers with USB copy protection dongles. In this post, I’ll show you how to setup an Aladdin HASP license server from scratch. Nothing about it isn’t difficult, but the entire process is unintuitive. There are two nearly indistinguishable types of HASP keys, and you’ll need different types of installers for each. And you launch the installer from the monitoring component. So obvious. And the great thing about licensing is, you have no choice! You either figure out how the licensing application works, or you don’t use the software.

To begin, you’ll need three bits of software.

• Digi AnywhereUSB drivers
  These will install the virtual USB controllers on your server and install the AnywhereUSB management console. If you’re installing the HASP license server on a physical server with USB ports, you obviously don’t need to install this.
  
  
• Aladdin Monitor
  This is a management console for your HASP devices. It shows you what devices are connected, whether the HASP services have started, and the clients that have checked out licenses (for HASP HL keys). It is also the installer for the HASP HL Service. How obvious! The user interface for the Aladdin Monitor is among the worst ever produced (up there with BMW iDrive and SAP).
  
  You can download the Aladdin monitor installer (aksmon32_setup) here.
  
  
• Aladdin HASP4 server
  The Aladdin HASP4 server acts as an intermediary between Aladdin HASP4 protected applications and the Aladdin HASP4 dongle
  
  You can download the Aladdin HASP4 server installer (lmsetup.exe) here.

To begin, install the AnywhereUSB drivers. I’ll describe how to install these drivers in a later blog post.
Next, install the Aladdin Monitor by performing the following steps.

1. Extract the aksmon32_setup.exe file from the package to the destination server.
   
2. Run the aksmon32_setup.exe installer.
   
3. Unless you are a German speaker, select U.S. English then click OK. Perhaps Aladdin HASP makes more sense if you select German (UPDATE: according to a German reader, no. It isn't any more intuitive in Deutsch).
   
   
   
   
4. At the Welcome screen, click Next.
   
   
   
5. At the License Agreement screen, sign away your rights by clicking I agree then clicking Next.
   
   
   
   
6. At the Destination Location screen, click Next.
   
   
   
   
7. The installer will ask you if you want to keep a backup. This backup is completely useless, but we’ll select Yes anyway. Click Next.
   
   
   
   
8. Click Next to start the installation of the Aladdin Monitor.
   
   
   
   
9. Once the installation has completed, click Finish to exit the installer.
   
   
   
   
10. The Aladdin Monitor is now available in the Start Menu.
    
    

That was boring! Now time to install the Aladdin HASP HL-Service. You have to do this from within the Aladdin Monitor. How intuitive! Let's begin before you fall asleep.

1. Open the AKS Monitor application
   (Start > Programs > Aladdin > Monitor > AKS Monitor)
   
   
   
   
2. Click Services > Hardlock > Install HL Service
   
   
   
   
3. A prompt will appear.
   Click OK to accept.
   
   
   
4. Now it’s time to make sure the HASP HL service automatically restarts if it crashes (a license service crashing? Surely not!).
   Open the Computer Management console (Start > Run > compmgmt.msc)
   
   
5. Select the Services node in the left-hand pane
   
   
6. Select the HL-Server service.
   
   
   
7. Right-click on the HL-Server service and click Properties.
   
   
   
   
8. On the Recovery tab, change the First failure, Second failure and Subsequent failures reponses to Restart the Service.
   
   
   
   
9. Click OK to close the properties window.
   
   
10. Close the Computer Management console.
    
    
11. In the AKS Monitor, click Services > Hardlock > Start HL-Server Service. This will cause the HL-Server service to rescan the network for Aladdin dongles.
    
    
    
    
12. Once the scan is complete, an HL-Server will appear under the HL-Server folder.
    
    
    
    
13. Expanding the server node will show all the Aladdin dongles connected to the server. In this case, there is a single Aladdin dongle with the module address of 6903.
    
    
    
14. Close the Aladdin Monitor.

Okay, we’re nearly there. If we plug in an Aladdin HASP HL dongle, it will work. Now we need to install the software to support Aladdin HASP4 dongles! To do this, perform the following steps.

1. Extract the lmsetup.exe file from the package to the destination server.
   
2. Run the lmsetup.exe installer.
   
3. Select U.S. English then click OK.
   
   
   
   
4. At the Welcome screen, click Next.
   
   
   
   
5. At the End User License Agreement screen, click I accept the license agreement then click Install.
   
   
   
   
6. At the Installation Type screen, select Service (nhsrvice.exe) then click Next.
   Installing it as an application is utterly stupid and would require you to login to start the license service.
   
   
   
   
7. A the Choose Destination Location screen, click Next.
   
   
   
   
8. A the Select Program Manager Group, click Next.
   
   
   
   
9. At the Device Driver Installation screen, click Next.
   
   This screen will appear even if the appropriate driver is present on the server. Good work guys!
   
   
   
   
10. If a Driver Installation error message appears, click OK to continue.
    This behaviour is by design and expected.
    
    
    
    
11. On the HASP License Manager screen, select Yes then click Finish to complete the installation.
    
    
    
    
12. Now, time to make sure the service automatically restarts when it crashes.
    
    Open the Computer Management console
    (Start > Run > compmgmt.msc)
    
13. Select the Services node in the left-hand pane
    
14. Select the HASP Loader service.
    
    
    
    
15. Right-click on the HASP Loader service and click Properties.
    
    
    
    
16. On the Recovery tab, change the First failure, Second failure and Subsequent failures reponses to Restart the Service.
    
    
    
    
17. Click OK to close the properties window.
    
18. Close the Computer Management console.
    
19. Open the AKS Monitor application
    (Start > Programs > Aladdin > Monitor > AKS Monitor)
    
20. The server name will appear under the HASP License Manager server.
    
    
    
    
21. Close the Aladdin Monitor.

Woo, finally done! Now all you need to do is point your HASP clients at your HASP server! Maybe I’ll write a post on that.

Aladdin HASP security dongles, USB-over-Ethernet devices, and licensing frameworks.

If you’ve done virtualization work in an engineering companies, you’ve probably come across a USB hardware dongle. These awful devices are used to ‘secure’ software from unauthorized copying. Software companies love them because they believe that dongles prevent piracy (or make it difficult), and VMware architects hate them because

• they require additional hardware and software to use in a virtual environment
• the additional software is sometimes flaky
• physical elements add a single point of failure and prevent us from using SRM
• they’re difficult to test because our customers need them to use their products, and we need them to test our solutions
• we dislike physical things.

In 2010-2011, the most common type of security dongle in circulation is the Aladdin HASP series. Aladdin HASP is a family of hardware produced by SafeNet Inc (previously Aladdin Knowledge Systems). There are several types of HASP dongles.

• HASP
• HASP4
• HASP Hard Lock (HL)
• NetHASP
• TimeHASP

The most common HASP keys are the HASP4 and HASP HL. The features of these two types differ: amount of onboard memory (used to store entitlements, instructions) and encryption strength. Neither dongle has a battery-backed RTC (real-time clock, typically used to enable time-based software rental). HASP keys can be identified by their translucent and coloured shells. The following are photos of the HASP4 and HASP HL keys.

Dongles: back, and with a vengeance!

As shown above, the form factor cannot be used to accurately identify the type of dongle. HASP4 dongles typically have stickers containing the letters H4. HASP HL dongles typically have an engraving in the reading HASP HL.
Dongles are only half of the problem. The problem is the license software used to drive them. For HASP4 dongles, it’s often FlexNet. For HASP HL dongles, it’s the HASP HL server.
Applications protected with FlexNet and Aladdin HASP4
FlexNet is a licensing framework published by Flexera Software. Vendors license and customize the FlexNet framework to meet their entitlement management requirements. In the majority of FlexNet implementations, machine-specific license files are used to protect applications.
The non-dongle FlexNet license check-out process is illustrated below.

1. Client contacts FlexNet license server and requests vendor daemon port: The FLEXenabled application contacts the license server and asks for the port of the vendor daemon. The FLEXenabled application knows the hostname and FlexNet license server port number from the client license file.
2. Server responds with vendor daemon port: The FlexNet license manager replies with the port of the vendor daemon
3. Client responds with license check-out request: The FLEXenabled application sends a license check-out request to the vendor daemon
4. Vendor daemon reads license file to determine entitlement
5. Server sends accept or reject: The vendor daemon determines whether any valid licenses are available and sends an accept/reject to the FLEXenabled application.

The FlexNet framework supports the use of Aladdin HASP hardware dongles (as well as other dongle types). HASP4 sits on top of the FlexNet framework. This involves an additional step between step 4 and 5. I’ll label these 4A and 4B.

4A. Contact HASP4 server: the vendor daemon contacts the HASP4 server and requests the HASP_ID of all connected HASP dongles.
4B. Dongle check: The HASP4 server contacts all connected HASP dongles and retrieves the HASP_ID. It passes these to the vendor daemon which checks for an authorized dongle.

Applications protected with HASP HL
Aladdin HASP HL is a standalone licensing framework. The license check-out process is illustrated below.

1. Client contacts HASP HL Server: The protected application sends a request for a license check-out to the HASP HL Server.
2. Entitlement check: The HASP HL Server asks the Aladdin HASP HL dongle whether the license check=out is permitted. The dongle determines whether this is allowed and replies with an answer.
3. Response: The HASP HL Server replies to the application.

Okay, enough about licensing frameworks. How do you virtualize a server that has a USB dongle plugged in the back?
To do it, you’ll need a USB-over-Ethernet device. A USB-over-Ethernet device is a network attached USB hub that connect USB peripheral devices to a server over a network. They were typically used as range extenders for USB devices (such as receipt printers, point of sale barcode scanners, biometric readers, manufacturing line control systems) where having a local PC was not practical or secure. Recently, they have been used to connect USB devices to virtual machines.
The following illustration (taken from VMware's AnywhereUSB guide) shows how an AnywhereUSB USB-over-Ethernet device can be used to connect USB devices to a virtual machine.

The advantages of USB-over-Ethernet devices are

1. Dongles with potentially high replacement costs can be secured in datacentre (I worked with a dongle that costed $45,000 to replace. The vendor had a clause in the EULA stating the replacement cost of a dongle was equal to the cost of the license. No joke.)
2. VMs with license servers can be protected with VMware HA and VMware FT – license servers previously didn’t have any HA mechanism.
3. They allows you to virtualize those “final few” servers in datacentre.
4. They are easy to centrally manage and monitor
5. No major architectural changes required.

USB-over-Ethernet devices aren’t without their drawbacks…

1. There is the possibility of potential incompatibility between dongles and USB-over-Ethernet device. These devices aren’t perfect.
2. They introduce another point of failure
3. No USB-over-Ethernet devices on market have redundant power supplies – if you have to do power testing, get ready to lose the device.
4. The cheapest USB-over-Ethernet devices aren’t rack mountable.
5. They require additional drivers in virtual machine.
6. They are difficult to source in Australia: It is important to have hot spare ready or you could potentially be waiting weeks for a replacement. That’s a week of your licensed software being unavailable to users. If you need them, please contact me!

A word of caution: hardware dongles are notorious for being finicky. Working with dongles can be tedious and time consuming. When you find a configuration that works for you, document the solution current state: the USB-over-Ethernet firmware level, the host driver software, the OS and even the hotfix level. Pay careful attention during your patch cycle and ensure that the dongle continues to work after any updates have been applied. There are documented cases of incompatible dongles and servers and there is no definitive hardware compatibility list and determining compatibility is an exercise in trial and error. USB-over-Ethernet devices vendors periodically release firmware updates to improve compatibility, but those same firmware updates could break compatibility. Exercise extreme caution!
USB-over-Ethernet devices
There are a few USB-over-Ethernet devices on the market.

1. Digi AnywhereUSB: these are the most popular device on the market. Use these and your problems will be minimized. If you can’t source the AnywhereUSB…
2. Lantronix UBox: was previously popular. Although discontinued, the UBox is more compatible with certain families of security devices. The device drivers for this software are a little less stable.
3. Belkin Network USB hub: don’t even bother. Support for HASP dongles are hit and miss.

The Digi AnywhereUSB/5. Plug the USB dongle in the front, the network cable in the back, and you’re set.

In my next post, I’ll describe the process for installing these devices in your environment.