Paul's Down-Home Page

From Ed’s blog, news that IBM is moving toward a slightly different licensing strategy for its products.

Why does IBM even use per-processor licensing? Customers hate it. Microsoft has been making hay in the database world by showing the license cost differential between SQL Server 2005 and DB2 on equivalent hardware– it can be up to an order of magnitude difference! That gets CxOs’ attention PDQ.

Doesn’t it make more sense to price software according to the number of actual clients or users and not the capacity of the machine? As I understand it, if I buy a 2-CPU dual-core Opteron server, I have to buy 4 Domino CPU licenses (or the equivalent number of “processor value units”), no matter how many actual users connect to the box or what else it’s used for. Compare this with the pricing model for Exchange, GroupWise, or even OCS: you pay for the number of users you’re supporting, not for what your hardware is potentially capable of.

“Processor value units” seem like an IBM attempt to extract money that they wouldn’t otherwise be entitled to from customers who are moving to multi-core CPUs. When Ed asks:

…what would you like to see happen as far as sub-capacity or multi-core licensing and pricing for Domino? ..t. If the answer is “we just want to pay less for Domino”, that dog doesn’t really hunt — unless you have an idea how that translates into IBM growing and maintaining the Domino business.

one translation of the question might be “customers, we know you think our license model doesn’t reflect reality, but we don’t care if you want to pay less.” The right thing to do for growing the business is to adopt the MS model for virtualization licensing: license per active instance and virtual CPU, not for physical instances of anything.

(and before the flames start: yes, I know MS has per-CPU licenses for some products, like SQL Server. However, AFAIK they don’t do per-CPU licenses for their messaging and collab products; I don’t know offhand if they’re doing per-CPU or CAL for Office SharePoint Server or not.)

Update: yep, customers hate IBM’s licensing model, all right.

Devin has a good summary of some of the things you should expect (or may not expect!) in Exchange 2007 beta 2.

The Exchange 2007 preview center has a new white paper on Exchange 2007’s unified messaging (UM) implementation. If you’re interested in how UM works, check it out.

Wow! Not sure how I missed this bombshell: CA bought XOsoft. I hope CA has the good sense to leave the XOsoft folks in place and let them do what they do best.

Great news! Exchange 2007 beta 2 is being launched today. The press release is here. You can download it or order it on DVD; the download isn’t active yet (I expect it any minute, but Microsoft.com is so huge there’s often a gap between press release postings and live bits).

In very closely related news, the Exchange 2007-compatible version of Microsoft Forefront (née Antigen) will be available today too.

Microsoft’s been making a big deal out of the Messaging and Security Feature Pack, which adds some nifty device and security management features to Windows Mobile 5.0 devices. However, there’s a problem with MSFP policies on the device side; ironically, it only shows up on devices of security-conscious users.
Let’s say that you set a device timeout on your WM5.0 device of 5 minutes. You then create an MSFP policy that sets the device lock policy time to 15 minutes. When the policy is applied to the device, your 5-minute timeout is overridden with the 15-minute timeout, making the device somewhat less secure.
What can you do about it? Nothing at the moment. The Windows Mobile team is well aware of the issue, and I’m sure they’re busy thinking about how they can best fix the problem.

It sometimes happens that I get the same (or similar) question from several people within a short time frame. That’s usually a good indicator that the answer would make a good blog entry! Today’s installment in this long-running series is simple: how do journaling systems and encrypted mail go together?

When you use S/MIME, the message is encrypted when the client submits it to the store. Exchange only gets the encrypted version. That means that when it’s journaled, it’s encrypted. It stays encrypted until the recipient opens it. The journaling system can copy the message, and it will have access to the envelope information (like who sent the message, who it’s addressed to, and the subject). However, for encrypted messages, the message payload is encrypted, so it won’t be readable by the archiving administrator.

When you use Windows Rights Management Services, the situation is much the same: the message is protected before it leaves the client. However, RMS supports the concept of a group of “super users” who can recover content no matter who created it. That means that super users can recover protected content from the archive, which is exactly what most companies want to do.

How do you get RMS-like behavior from S/MIME? Simple (well, conceptually simple, anyway). All you need to do is CC or BCC the archiving administrator on every message sent. That will cause the message to be encrypted with their cert as a recipient, preserving their ability to read the messages. Implementing this is left as an exercise for the reader (and it’s not really trivial, which is why DoD and other TLAs have their own custom solutions known as security guards (try this one for an example). One way to start is by using a custom Outlook form that includes the BCC recipients. In fact, you could easily build an Exchange 2007 transport rule that would NDR any encrypted message that was not BCC’d to the security guard. Maybe I’ll try that next week…

Exchange’s Unified Messaging server role controls access to the Outlook Voice Access interface in several ways. Today I want to talk about PIN authentication and how it works.

Every UM-enabled user will have an associated PIN. The PIN is stored as an encrypted string as an attribute of the user account object in Active Directory; the PIN is encrypted along with a salt, so it can’t easily be reversed. (Despite this protection it’s still a bad idea to choose your ATM PIN or AD password as a UM PIN, but of course you know better).

Administrators can set PIN policies that control the permissible length of the PINs and how long they remain valid. Users can reset their PINs at any time using OWA 2007 or Outlook 2007; when the PIN is reset, the user gets an e-mail containing the new PIN. This helps protect against denial-of-service attacks where user A logs in to user B’s voice mailbox and changes the PIN on the phone keypad. These policies are actually part of the UM mailbox policy objects, which you can use to specify some other settings as well- look for more details in a future post.

The UM role performs its own auditing of failed authentication attempts. When you call in to Outlook Voice Access, you get 3 tries to enter the PIN; if you fail, OVA hangs up and logs event ID 1013 to indicate the logon failure. If the failed authentication attempts continue, you’ll see event ID 1012, indicating that the user’s OVA access is locked. There’s also a perfmon counter that you can watch to see the number of failed logon attempts, but I’m in an airport and away from my UM server so I can’t post its exact name right now.