Are Client Access Licenses Enforceable?

One of the less-fun aspects of managing Microsoft Windows servers is dealing with the Client Access Licenses (CALs).  CALs aren’t only expensive, but with different licensing models (per seat, per user, per machine, etc) and different versions (CALs bought for Server 2003 are no good for your beefy new 2008 R2 box) they are also complicated and easy to get wrong.  But sometimes I wonder: are CALs really necessary? What if we could just ignore them entirely? This isn’t as far-fetched as it sounds. I think if it ever really comes down to it, CALs might ultimately turn out to be just so much bad data. The reasoning goes something like this:

Software licenses depend on Copyright Law, which (in the U.S.) grants copyright owners certain very specific rights relative to their protected works… namely the right to say who is allowed to make copies, and when. Legal precedent and the U.S. Copyright Office have established several specific points relative to copyright and software: computer source code is eligible for copyright protection, compiled source code is still protected, and installing software from the internet or physical media to your hard drive copies the software. Moreover, merely running software that you’ve already installed involves making a copy from your hard drive to RAM and CPU. This means that software makers can require you to license, rather than buy, your software.  I don’t agree with everything here, but I’m okay with it… and I better be, because my opinion doesn’t matter. This is legal fact in most of the free world whether I agree with it or not.

Now let’s make the next leap to CALs. Imagine you license server software from Microsoft and are legally running it. You’re also running a legally licensed copy of Microsoft Windows (client) on another machine. You now connect this client system to your server, and exceed the numbers of CALs for that server. This is supposed to suddenly be a copyright violation. The thing is, I’m having trouble seeing what part of the protected software was copied with this action. Sure, a few bytes passed over the network, but these bytes are not part of the protected work itself. They were generated by the protected work, but at the express direction of the user. Microsoft or any other software maker will have a very difficult time placing a copyright claim on that data, and you can’t copyright behavior.  Most importantly, there’s no legal precedent or copyright ruling here that I can find one way or the other.

The significance is that running without CALs is probably not a copyright violation. However, it might turn out to be a contract violation. This is interesting, because contract issues don’t have the weight of the federal government behind them in the same way that copyright does. Just one example is that the DMCA’s anti-circumvention penalties would likely not apply. Microsoft can choose enforce these contracts, but that is a much more difficult proposition, considering the sheer size of their deployed base and the fact that few of these so-called contracts will even have a signature.

I need to stop and this point and mention that I’m not advocating that anyone stop tracking their CALs. I am not a lawyer, and I’m probably way off on some key point in my analysis. This issue is far from settled, and even if my thoughts on CALs here turn out to be accurate, Microsoft or the BSA could easily make your life very difficult and your wallet significantly lighter in the attempt to defend yourself. As a sys admin, I try to protect the organization I serve from that kind of trouble, and so I purchase and track the required CALs like everyone else.

But I can at least dream of the day when this is no longer necessary.

 

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

Posted in servers | Leave a comment

The Immutable String

One theme I see often on StackOverflow is that someone will post a question related to strings, and someone or several someones else will come along and say, “You can’t; strings are immutable.”

This is all well and good and accurate, but I have a problem with it.  You see, I think most of the people who ask these questions have never or only rarely encountered the word “immutable” in the first place.  They will generally have a weak or vague idea what it really means.  I blame Eric Lippert.

Let’s get this out of the way: the root word of “immutable” is “mutate”.  Something that is immutable does not have the ability to mutate. It never changes.

Applied to strings, this means that a string instance, once created, cannot be modified.  If you want to change a string variable, you have to create a brand new string instance and assign the new instance back to your variable.

It’s good there are more programmers out there that know these $5 words, but it’s even better if there are more programmer out there that can communicate the ideas behind the words to others who don’t yet know them.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

Posted in Uncategorized | Leave a comment

A Different Way to Wifi Part 2: Basics and Stages

In my last post, I talked about what you need to get started building out your wifi network.  The main points were adequate switching and some basic network services like dhcp.  But the most important item from the list is a dedicated network team.  If you meet the first part, you probably have the second part to thank for that.  Unfortunately, while you might have some great people working on your network, if they’ve been around a while this whole “wifi” thing might be a bit scary for them.  Today’s post covers two areas.  First, a few basic things that will help your network guy put wireless in perspective.  Second is the different stages of your wifi deployment.

Basics

When we talk about wifi speeds, we tend to talk about them in the same terms as we do for wired networks.  This is misleading.  When we talk about a 100mbit or 1000mbit (1gbit) wired network, this usually refers to a switched network.   Wireless access points are not switched.

On a switched network, each packet moves between a computer and a port on a switch, or perhaps between two switches.  It’s the job of the switch to transmit a packet only when the line is clear, and only to the necessary ports.  This way, it’s like each computer is on it’s own private network.  You never have packet collisions and you leave as much of your network clear as possible.  This means you get the most throughput possible out of your network.

Two Network Packets about to collide

On an unswitched network, all packets go to all ports and visible to all computers.  If two computers want to send a packet at the same time, you have a collision.  Both computers must resend, and that particular bit of bandwidth used for the broken transmission is completely wasted.  This means that actual network throughput is much lower than the theoretical potential.  However, networks speeds are still advertised in these terms because there’s no good way to know how much lower the real value will be.   In a simple home network with few machines and little interference, you might get something close to what’s advertised.  More machines makes things worse quickly, and too many machines can even push this number all the way to zero.

The good news is that your network is only unswitched within individual access points, and there is some provision in wifi to allow multiple access points in the same space.   There are 11 available channels in the b/g wireless range, and more in the 5ghz range used by a and n radios.  The bad news is that these channels tend bleed into each other and overlap.  For example, in the b/g range you should really only use channels 1,6, and 11 most of the time (there are exceptions where you can use more).  That’s only three channels.  Since a single access point can generally only handle about 20 simultaneous clients, if you have more than 60 users in an area you could be in trouble.

There is one more important consideration to look at as your network grows: broadcasts.  Broadcast traffic can be really disruptive to wireless networks, and so it’s important to keep your broadcast domains small — typically no more than around 500 devices, though the explosion of mobile devices (that are on for shorter periods at a time) has perhaps pushed this number higher.  This is why you need equipment with good vlan support.  You will need to create multiple vlans (segmented by area) as your network grows beyond this number.

At York College, we are right on the cusp of needing an additional vlan.  We have well more than 500 devices.  Currently we have avoided this route, because many are devices are mobile (we have an iPod program) and we have some other things in place as incentives for students to use the wired connections available in their rooms.

Stages

When I think about stages of wifi deployment, I like to think in terms of three “C”s: Coverage, Capacity, and Clarity.

For the first stage, you are working just get a basic level of coverage to an area.  Imagine you are the only person on the network.  If you go to a specific location, would you be able to use the network there?  While building out coverage, you may find yourself tempted to look for stronger access points that can cover larger areas.  I urge you to avoid this, for reasons that will soon be clear.

Once coverage is established, you begin to worry more about capicity.  Sure, the access point on the floor below may be able to send a signal up a level, but if it typically already has too many users you may find you can connect but not actually get any work done.  It’s time to start adding more access points beyond the basic coverage level, because you need more Capacity.

As you add access points to meet your Capacity needs, you may find that in some places you have a Clarity problems.  Users at the edge of the range of an access point on a particular channel will send transmissions that reach area covered by the next access point over on the same channel, causing packet collisions and hurting throughput.  Again, you may be able to connect to your network, but find that you are unable to get any work done.  This problem is also called “Density”, but I find the term “Clarity” makes it easier to understand where we are in our deployment.

At this point, people tend to start worrying about things like rogue access points or interference from neighbors, cordless phones, and microwave ovens.  While that’s noble, it’s mostly a mistake.  The largest source of interference on your network is usually your own access points and devices.  To counter this, you want to look for access points that have smaller coverage areas and lower (or adjustable) power antennas, not larger coverage areas or more powerful antennas.  It may seem counter-intuitive, but this way you can have smaller size cells and you can put more access points in the same size space- you can have a more dense deployment where the frequencies you need stay clearer.  The downside is that this adds expense and management issues, but it’s how they do it with the big enterprise deployments, too.

Next time, we’ll cover site surveys and access point placement.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

Posted in Uncategorized | Leave a comment

A Different Way to Wifi Part 1: Basic Requirements

Before I really get into things I need to cover some basic requirements you will need for your network.

First up is that you do need an existing, functional, wired network.  This network should already have established links to each building.  Your network should also already have adequate switching capacity (in terms of ports) for the access points you’ll want to add.

Arionet 1003

Expensive Access points *not* required

There are some specific features you’ll want to check for in your switches, as well.  Most of these are a given these days, but they bear mentioning.  First of all, the switches should support vlans via 802.1q tagging.  Your core switch needs to support Cisco’s IP Helper feature (or your switch vendor’s equivalent –  our 3Com equipment calls it “Virtual Interface”). This allows you to easily set up a single dhcp server to use different IP ranges for different subnets.

That brings me to the next item.  You’ll need existing dhcp and dns servers that support handling multiple subnets from the same server.  Support for RADIUS is also nice, but you can add a small virtual machine for this somewhere if you need to.  Windows Server Standard Edition can handle all this nicely by itself, and I’m pretty sure the standard linux tools can as well with nothing fancy.

Another requirement is a good gateway solution.  One of the things you give up when eschewing a traditional controller is reporting.  I’ll cover that more in a later post, but for now it’s important to note that you’ll need to think about how you’re going to gain insights into what’s happening on your network. A good gateway solution can help here.  At York College, we currently use Untangle.

This next item should be a given, but I want to make sure to mention that you will need a few test devices.  This includes both Windows and Mac-based laptops, and a couple mobile devices are very helpful as well.  When all is said and done, you need to be able to quickly verify that things work in a basic sense for the different kinds of device you’ll need to support.

Finally, and probably most important, you’ll need a dedicated network support team. People who know your network, know your business and needs, and know your users. At York College, that was (until recently) just me.  I now have additional support staff, but for the first part of this I was the sole person working on wireless at the campus.

The thing I want readers to take away from this is that whole idea behind what I’m doing is to take advantage of existing infrastructure you already have.  If you don’t already have the core infrastructure, you’re looking at a major vendor contract anyway, and at this point you’re likely just as well off going with a traditional enterprise deployment.  But if you do, and you have people who can implement it, this really can work.

Next time: Wifi 101

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

Posted in wifi | Leave a comment

A Different Way to Wifi Part 0: Introduction

Over the next several weeks I’m going to talk about Wifi, and how to do an extensive multi-building deployment on the cheap.  I’ll cover required background knowledge, basics and stages of a wifi deployment, site surveys and access point placement, security requirements, access point selection and preparation, and handling density and scale.  From there I’ll move on to the weaknesses of this approach, and how to migrate away from it should you need to.  But today I just want to share some background. 

McCloud Hall

One of many building on campus where wifi didn't work

I’m the Director of IT at York College, a small liberal arts school in York, NE.  When I first came here, the wifi network consisted of a single 3Com controller switch with 9 enterprise access points, augmented by about as many commercial routers literally purchased from Walmart and plugged in nearly unconfigured; it was entirely inadequate.  Even if there had been enough coverage, the controller switch was unable to even keep up with authentication requests, let alone our capacity needs.  The whole thing was a broken mess.

The surprise is that the off-the-shelf “access points” actually worked better than our overloaded enterprise system.  The first 50 people to connect to a router since the last reset (before the dhcp range filled up) would have good internet access. Regular resets kept them mostly responsive for most students, most of the time.

When I started, improving campus wireless access was a top priority.  Given the history here, along with other budget concerns, I felt the need to think outside the box for building out our wireless network rather than using a traditional enterprise product.  I hatched a plan that allowed me to continue using and building on the existing equipment, including the Walmart routers, and move on from there.  We now have more than 40 access points spread over 18 buildings, I expect to grow to 60 or more very soon, and that’s just phase one.

I still have all the original equipment (that now actually works). Everything added since is based on commercial products you could order from NewEgg or Amazon for your home (albeit a little nicer than what you’ll find at Wal-mart) – all without relying on a central controller.  We’re beginning the transition from what I call a first-stage deployment to a second stage deployment (I’ll talk about this in a later post).

Most enterprises have already partnered with a vendor for their wireless deployments, but my hope is that this series will be timely for some who are thinking about the migration to 802.11n.  I expect most will still want to use a traditional deployment, but for some, the current economy might make what I’m about to describe a compelling idea.

Next time: Basic Requirements

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

Posted in wifi | Leave a comment