Windows Server 2008 Enterprise licensing

Over the last few days I have been in communication with a vendor regarding the new Microsoft license type known as Volume Activation (VA) 2.0. VA 2.0 has one major issue that differentiates it from it's predecessor, the end user can no longer bypass the activation process of the software package. With Windows XP and Windows Server 2003 R2, when a volume license was purchased, a single Volume License Key (VLK) was provided to the customer that could be used to activate a limitless number of Windows servers/clients. As can be imagined, to Microsoft's chagrin, this convenience likely led to many illegitimate copies of Windows being deployed.

Microsoft sought to resolve this issue with VA 2.0, which partially brings us back to the old FLEXlm days. Microsoft now offers two types of VLKs: MAK (Multiple Activation Keys) and KMS (Key Management Service). These license types differ as follows:

• MAK keys can be used a finite number of times prior to becoming useless.
• This is good if you are setting up a single machine, such as an AD server or Web server.
• This is bad if you are going to be regularly redeploying your server images using Sysprep, such as in a Terminal Server environment.

• KMS keys, once installed on a KMS host, essentially issue licenses like a DHCP server issues IP addresses.
• Once the KMS host has been activated by Microsoft an unlimited quantity of 180 day activation leases can be issued for the licensed products. This solves the Terminal Server redeployment issue.
• The downside to KMS is that we now have to maintain yet another service. A minimum of five servers must be in operation for the KMS host to function.
  

As it turns out, Microsoft has given the VA 2.0 customer the latitude to choose which type of license they will utilize via the MVLS (Microsoft Volume Licensing Services). KMS seems to make the most sense for us, hopefully this is the correct decision.

Most other vendors (Sun, HP, IBM, Oracle) have given up trying to lock down their core operating systems/products (Solaris, HP-UX, AIX, Oracle 10G). Sun has even gone to the extent of starting the OpenSolaris project, giving away the source code for Solaris. Maybe one day Microsoft will again liberalize their activation policies as others recently have.

Amy...

Just heard this song on XM Radio: Amy Winehouse - You Know I'm No Good, nice sound...

Compiling PerLDAP on Solaris 10

To compile PerLDAP 1.5.2, which is part of the Mozilla Directory (LDAP) SDK Project, with the Sun Studio Compilers on Solaris 10u4 (sparc) using the native perl (5.8.4), retrieve the following components:

• The 32-bit LDAP C SDK.
• Currently, precompiled binaries exist for v6.02
• Source is available for v6.05
• The latest version of PerLDAP
• Currently, v1.5.2 is available
  
• Sun Studio Compilers
• Available for free to SDN (Sun Developer Network) members, for which membership is free
• At a minimum, install the C & C++ compilers with the build tools.
• v12m1 (09/2007) is the latest currently available

To install the precompiled version of the LDAP C SDK simply gunzip and untar the package and move the resulting directory to '/usr/local/ldap-sdk'. There is a self explanatory installer included with the Sun Studio compilers. Following installation, confirm that you have the Sun Studio compilers installed porperly:

z4-obx# cc -V
cc: Sun C 5.9 SunOS_sparc 2007/05/03
usage: cc [ options] files. Use 'cc -flags' for details

z4-obx# CC -V
CC: Sun C++ 5.9 SunOS_sparc 2007/05/03

Now, gunzip and untar the PerLDAP package and change into the source directory and type 'perl Makefile.PL'. It will now ask you where your LDAP SDK is located, on this line type:

/usr/local/ldap-sdk

Accept the defaults for the remaining options. Once this is done, modify the 'Makefile' so the following lines look like this:

INC = -I/usr/local/ldap-sdk/include -I/usr/include/mps

LDLOADLIBS = -L/usr/local/ldap-sdk/lib -lssldap60 -lprldap60 -lldap60 -lssl3 -lnss3 -lsoftokn3 -lplds4 -lsasl -lplc4 -lnspr4

The 'LDLOADLIBS' and 'INC' variables should each be on a single line. These changes are necessary so that the module successfully compiles and the built-in tests run without failing.

Once this is done run 'make test' on the command line and the package should be successfully built and tested. At this point, type 'make install' and the package will be made available on the server.

There is some nice documentation available here regarding utilizing PerLDAP. Also, it is worth noting that PerLDAP is not Perl-LDAP.

Hello

This is my first blog post, just trying it out.