Will your OCS / Lync Front End not start because of license issues?

I Have run into this problem 2-3 times last week, so I wanted to remind people about the issue.
The error you see is that your Lync or OCS Front End service centers will not start and errors a la the following is logged in your event viewer:

The evaluation period for Microsoft Office Communications Server 2007 R2 has expired. Please upgrade from evaluation version to the full released version of the product.

Failed to activate Office Communications Server Standard Edition Server on machine R2 SE.NWTraders.com

Or in Lync

The evaluation period for Microsoft Lync Server 2010 has expired. Please upgrade from evaluation version to fully licensed version of the product.

There are 2 possible sources of error for this:

You (or the colleague who usually gets the blame) made a mistake
It installed the eval version of Lync and the 180 days are now gone, so the product has expired
Find the full version of Lync, copy it locally into the server and run:
msiexec.exe / fvomus server.msi EVALTOFULL = 1 / qb
If it comes back with a message that it can not upgrade FULL to FULL, then the next source of error is:

Microsoft made a mistake
Or rather they have addressed a critical issue in their CryptoAPI (and we're happy for that), but this correction criples OCS and Lync (and LCS for that matter), so the product think it is running on an evaluation version. The error is described here:

http://support.microsoft.com/kb/974571

and solved by setting a registry setting or running OCSASNfix.exe from a command prompt.

Good luck out there!

Elevation of Privilege (EoP) Card Game

Elevation of Privilege is the easy way to get started threat modeling. Threat modeling is a core component of the design phase in the Microsoft Security Development Lifecycle (SDL).
The Elevation of Privilege (EoP) card game helps clarify the details of threat modeling and examines possible threats to software and computer systems.

Read more and get it at http://www.microsoft.com/security/sdl/eop.aspx

The Little Book of Semaphores

In common use, “synchronization” means making two things happen at the
same time. In computer systems, synchronization is a little more general; it
refers to relationships among events—any number of events, and any kind of
relationship (before, during, after).
Computer programmers are often concerned with synchronization con-
straints, which are requirements pertaining to the order of events. Examples
include:
Serialization: Event A must happen before Event B.
Mutual exclusion: Events A and B must not happen at the same time.
In real life we often check and enforce synchronization constraints using a
clock. How do we know if A happened before B? If we know what time both
events occurred, we can just compare the times.
In computer systems, we often need to satisfy synchronization constraints
without the benefit of a clock, either because there is no universal clock, or
because we don’t know with fine enough resolution when events occur.
That’s what this book is about: software techniques for enforcing synchronization
constraints.

Here are just a few examples of the algorithms covered.

• Readers-writers problem
• Dining philosophers
• The dining savages problem
• The Santa Claus problem
• Building H2O
• The unisex bathroom problem
• Baboon crossing problem

Read it at http://greenteapress.com/semaphores/downey08semaphores.pdf

Programming is not a craft – or is it?

Software Craftsmanship risks putting the software at the centre rather than the benefit the software is supposed to deliver, mostly because we are romantics with big egos. Programming is about automating work like crunching data, processing and presenting information, or controlling and automating machines.
Non-programmers don’t care about the aesthetics of software in the same way non-plumbers don’t care about the aesthetics of plumbing – they just want their information in the right place or their hot water to work. (Although it’s fair to say they appreciate decent boiler controls.)
Read the rest and the comments at http://dannorth.net/2011/01/11/programming-is-not-a-craft/