An irreverent look at VMware's Software-Defined Data Centre (SDDC)

The intent of this blog post is to explain the SDDC in plain language. I get a lot of questions about SDDC so I'll address them here in an irreverent manner and hopefully you'll find it entertaining or educational. Preferably both, but I'll settle for the former.

What the heck is the Software-Defined Data Centre?
The Software-Defined Data Centre is VMware's strategy for delivering data centre services as a set of capabilities implemented in software. In VMware's SDDC vision, compute is delivered with vSphere, networking is delivered with NSX, management is delivered with vCenter and vCloud, and storage with vSAN. The SDDC is distinctly different from competing data centre architectures where network capabilities (such as VLANs, security, load balancing, etc) and storage capabilities (VMDK storage, storage replication, storage availability, etc.) are implemented in hardware.

The goal of the SDDC is to deliver a "fully automated, zero-downtime infrastructure for any application, and any hardware, now and in the future". While it is possible to deliver these goals in hardware (using orchestration and integration), VMware believe that software is a more appropriate mechanism and delivers higher levels of flexibility. And I tend to agree.

The SDDC consists of green and blue boxes.

Can I buy the SDDC?
The SDDC is a state your data centre can achieve, rather than a product. Don't worry, you'll be buying VMware licenses as your data centre matures from an SDDC 1.0 "basic virtualization" state to an SDDC 3.0 "Fully Cloud Ready" state. As you progress through your SDDC journey, you'll be buying licenses to unlock the capabilities your data centre requires (whether it be multi-tenancy, chargeback, self-service). If in doubt, just buy the vCloud Enterprise Suite.

Ignore the word "SAP" on the slide. I did and my life improved.
(from VMware Consulting blog article SDDC + SAP = CapEx/OpEx Savings)

Is the SDDC cheaper?
In most cases, SDDC will reduce and shift spending. Virtualization of servers and network devices can result in incredible reductions in capital and operational spending. For organisations transitioning to an SDDC model, network and storage infrastructure refresh spending will shift to vendors which support SSDC. An example is Nutanix customers who have consolidated their storage and compute spending into "converged infrastructure" spending. Another example is Amazon Web Services (AWS) using SDN to slash a $1b Cisco spend to $11m.

Sorry Cisco.

The other benefit of the SDDC is the increased agility of the IT organisation: people can actually get the infrastructure they need, when they need it. A case could be made that the capability and flexibility of AWS is not feasible to implement in hardware.

Where does cloud fit in with SDN?
The SDDC is one method of achieving cloud. The NIST definition of cloud computing includes on-demand self-service, broad network access, resource pooling, rapid elasticity and measured service. As long as the service you provide has those qualities, you have a cloud (regardless of the underlying technology). In fact, it's entirely possible to implement "as a service" offerings without any virtualization at all (I'd hate to do it though!). VMware believe the easiest way for enterprises to provide a cloud-like service is to pursue an SDDC architecture.

There's more than one way to implement an SDDC architecture.
Let's not talk about the other ways.

Isn't the SDDC just server virtualization?
Server virtualization is one component of the SDDC and it's neat for delivering more virtual servers with less spending and management overhead. But the delivery chain is only as strong as the weakest link: delivering a server in 10 minutes is of no use if it takes two weeks for firewall changes to be applied to make the server active. Provisioning a VM is just one part of delivering usable infrastructure.

So to deliver the network quicker, we virtualize the network?
Yes. This is known as Software-Defined Networking (SDN). Generally speaking, data centre capabilities which exist purely in software are more flexible, simpler, easier to test and can be integrated more seamlessly than hardware-defined solutions. This is also true with networks: many existing network architectures are device-centric and don't easily provide the provisioning flexibility and ease of integration required to implement on-demand cloud services such as rapid spin-up and teardown of networks.

Because software-defined networking solutions aren't constrained by physical network topology and are more programmable, more cloud-style flexible and programmatic approaches to networks are possible. This enables data centres to become less device-centric and more service-centric. VMware's SDN product is called VMware NSX.

But network devices can be orchestrated to provide what I need!
An alternative to SDN is to use an orchestration system to orchestrate VM and network changes (an example could be updating the perimeter firewall when a VM is provisioning/deprovisioning, or the ability to spin-up a new test network). If the orchestration system is implemented well, you'll get the same result as the SDDC: infrastructure services delivered quickly. If it isn't, you'll have a Rube Goldberg frankencloud. I'm not discounting the completeness or capability of physical network devices over SDN, I'm saying that SDN enables organisations to provide network capabilities (such as firewalls, site-to-site VPN, load balancing) in the hypervisor (which is more flexible and cost-effective) rather than the physical network.

A market-leading orchestration platform.

Why should I virtualize storage?
While vSAN has amazing infrastructure benefits (which I'll outline in another blog post), the strategic importance of vSAN is for storage to be managed with same flexibility and integration as compute. Storage today is a pain: storage administrators are either struggling to keep up with providing the amount of storage the data centre needs, and they're struggling to manage it. The presentation of "as a Service" IT models which enable the business to consume IT more easily make this problem worse. Instead of trying to optimise your storage procurement, provisioning and management processes, vSAN allows you to manage them the same way you would your compute capacity. When you run out of storage, simply buy another server.

But storage can be orchestrated today using robust interfaces provided by storage vendors!
Yes, it can. The majority of storage vendors have SDKs you can use to enable integration with orchestration tools or monitoring tools. If you already have this level of integration in your environment, you are already experiencing the benefits of the SDDC. If you are struggling with integration, or find that your home-grown integration doesn't deliver the feature completeness present with out-of-the-box solutions such as vSAN, it may be worth pursuing another strategy. Implementing technologies (like VAAI and VASA) which bring storage closer to compute aren't as easy as they should be. With the amazing capabilities of SANs, it feels strange that configuring array integration requires reading 30 pages guides, deploying vApps, create service accounts, configuring certificates, etc. You don't need to worry about any of this with vSAN, or any hyper-converged infrastructure. It just works seamlessly.

I followed a 32 page guide, submitted two firewall change requests, one storage change,
and one VMware change so that VASA provider would provide
a single concatenated string of disk capabilities. I guess it's a start.

Physical SANs are more fully featured than vSAN.
Horses for courses. Tradeoffs are involved with all data centre architectural decisions. In the majority of cases, choosing vSAN over a traditional physical SAN will be involve a tradeoff between features and seamless integration. Some customers may consider the lack of a deduplication capability in vSAN to be a glaring omission. Other customers are willing to choose vSAN over a physical SAN for the ease of management. I expect that over time, VMware will make vSAN feature-competitive with physical offerings (as they already have with VMware NSX and physical networks).

How will I know when I achieve the SDDC?
The CEO of VMware will personally hand you a key which will unlock over 600 airport lounges worldwide. SDDC is the journey and delivery of IT as a Service is the destination. Just because a data centre uses an SDDC architecture doesn't mean it's any good; it could be atrocious!

There's all the other usual KPIs for measuring success: amount of administrators per VM, current versus historical infrastructure spend, turnaround time on VM/firewall change request, etc. A good barometer of your ability to deliver IT as a Service is the stress level of project managers whose projects require IT infrastructure. In every organisation I've worked in, project managers are acutely aware of the lead times for delivery of IT infrastructure. Buy them a coffee and ask what they think about delivery of IT infrastructure. Another barometer is whether your developers use Amazon Web Services. Buy them a coffee as well, but understand that they'll likely not admit to using AWS!

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?

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.