Understanding Essential Business Server Client Licensing

Understanding Essential Business Server Client Licensing

  • Comments 14
  • Likes

[Today’s post comes to us courtesy of Mark Stanfill]

We get a fair number of queries about CAL enforcement in Essential Business Server (EBS) support, so I’d like to try to clear up some of the common questions that our partners have.  Because EBS enforces client licensing in a fairly strict manner, it is important to understand the repercussions of being out of compliance in order to ensure that your clients are able to successfully connect to the network.

How to Properly License Clients

Assigning CALs to users is a simple process:

  1. Activate the server.  Do this from Control Panel\System as you would for any Windows Server.
  2. Install the CAL Packs using the EBS Administration Console.
    1. Open the EBS Administration Console and select the Licenses tab.
    2. Select Install CAL packs from the License Management Tasks.
    3. Follow the prompts, and enter the CAL Pack product keys when prompted
  3. Assign the CALs to users or devices using the EBS Administration Console.
    1. For existing users, open the EBS Administration Console and select the Users and Groups tab.
    2. Select the user and double-click or choose Change user account properties.
    3. Select the CAL tab and assign the appropriate CAL (Standard or Enterprise).
    4. Click OK to exit.

CALs must be assigned to users.  Installation does not automatically assign a CAL to any users.  This task is covered in the Guided Configuration and Migration Tasks during setup as well.

Assigning CALs to users

Enforcement Model

EBS does not enforce any licensing restrictions for the first 30 days after Management Server is installed.  You can verify that you are in this state by looking in Event Viewer on Management Server under Applications and Service Logs\Microsoft\Windows\Server Infrastructure Licensing\Operational.  The presence of Event 39 in this log indicates that the server is in the initial grace period:

Licensing compliance for the Domain Controller Check is not enforced until 30 days after the server has been installed.

After 30 days, enforcement will begin.  Any client that is not assigned a CAL at this point will only be authorized to log in to servers or to workstations that have been assigned CALs.  The licensing service enforces this restriction by modifying the user’s Logon Workstation’s setting in AD.  Any changes made to this key will automatically be reverted by the licensing service.

image

If a CAL has not been assigned to a user, they will be presented with the following error when attempting to log on to their workstation:

Your account is configured to prevent you from using this computer.  Please try another computer.

Windows 7 - Your account is configured to prevent you from using this computer.  Please try another computer.

Vista - Your account is configured to prevent you from using this computer.  Please try another computer.

XP - Your account is configured to prevent you from using this computer.  Please try another computer.

User CALs vs Device CALs

Previous licensing models had the concept of user CALs versus device CALs.  In EBS 2008, all CALs are “Universal CALs” and may be assigned to either a user or a computer as needed.

When you assign a User CALs to a specific individual, that person can use any PC or network device to access a Windows Essential Business Server 2008 server or other Windows server in the domain. When you assign a Device CAL to a specific device, then any number of individuals (but only one at a time) can use that device to access a Windows Essential Business Server 2008 server or other Windows server.

In most cases, assigning CALs to users is preferred. Assigning CALs to devices typically is used in very limited scenarios:

· Shared machines between shift workers

· Kiosk machines

· Machines shared between workers who don’t require concurrent access (for example, point of sale devices, computers used to check email in a warehouse, or computers only used to do a specialized function, such as scanning or machine automation)

 

Automating Assigning CALs

 

 

The BulkAssignCALs.ps1 PowerShell script will attempt to assign installed CALs to users in the domain.  It is important to audit the accounts afterwards to make sure that test accounts, users who have left the company, etc. are not consuming CALs.  This script is available here.

To run this script, do the following:

  1. On the Management Server, right-click the icon for Windows PowerShell and choose “Run as administrator”
  2. Save the file locally to disk, right-click on it, choose properties, and click on the Unblock button
  3. In the PowerShell command prompt, execute the script by navigating to where you saved the file and typing .\bulkassignCALs.ps1 standard (for standard CALs; substitute premium as appropriate)
  4. Open the EBS Administration Console, navigate to the Licenses tab, select User Licenses,  and review the results.  Ensure that users have the correct edition.

image

image

Comments
  • Do service or resource accounts that are shared by users (that otherwise have licenses assigned to them) require CALs and the assignment of CALs to them?

    As an example, we have a shared mailbox/user which we use to share an Exchange mailbox.  We also have separate users for our system administrators to use exclusively when elevated privileges are required.  One person, but with more than one user account.  

    Does that require additional licensing?  

  • M Frahm -

    Good question.  Service accounts for the most part don't need CALs.  If you don't assign a CAL, the account will still be able to log on to all servers and licensed workstations.  The only time you must assign a CAL to a service account is if the account logs on locally to a workstation (which should be fairly rare).

    In your shared admin scenario, as long as you were logging on to servers, the account wouldn't need a CAL.  If you were so restrictive that you couldn't use the local admin account on a workstation, then that would be a different story, and the account would need a CAL.  A shared mailbox will actually be OK via OWA, since the login originates from the server, not the client.

  • Re: the shared mailbox issue.  We generally access shared mailboxes via the Outlook thick client, but using the "Open these additional mailboxes" feature on the Advanced tab of the Exchange account settings.  Would such access require a CAL?

    Our "admin" accounts sometimes logon locally to desktops, so with that in mind, it appears we would need to assign a CAL, correct?  

    Few of our machines are running anything newer than Windows XP, so this seemed to be a prudent way to address security in our environment.  

  • Thanks for the very useful article. However, I don't believe the following statement is correct:

    "In EBS 2008, all CALs are “Universal CALs” and may be assigned to either a user or a computer as needed."

    This may be true for the 5 Standard CALs that come with the "retail" edition of EBS 2008 Standard. However, all CALs purchased after that must be purchased as USER or DEVICE - they are not universal. This is true for at least the Open Value and Open Business licensing programs.

  • M Frahm - in a shared mailbox scenario, the authentication is registered from the primary user's account, so no addditional CALs are needed.

    ---Mark

  • Kelly B - the User/Device designation is a sales/SKU designation, not a technical restriction.  "Device CALs" may be assigned to users and vice versa.

    ---Mark

  • I have a client with about 120 workstations. These machines are used by managers, service techs, office workers, etc. They also have about 20 salespeople who have email addresses solely for the purpose of feeding their in-house CRM server. The mail comes in to sales1@company.com and then gets POPped off the server in about 10 minutes. They don't log onto the domain and they don't access their mail outside of the CRM package.

    Will each sales account be required to burn up a CAL?

  • If I run a trial version of EBS 2008 and rearm it up to the 240 days does it ever enforce the CALs or can I run up to 300 users in trial mode without CALs during the trial period or does it still enforce after 30 days without activation?

    This is a good selling point for economically challenged customers to defer the cost of CALs and get the migrated to EBS 2008 sooner rather than later.

  • JLong,

    slmgr -rearm does not reset client licensing.  The OS is rearmed, but client licensing is enforced 30 days after installation of the Management Server regardless.

    ---Mark

  • JLong,

    If finances are blocking your deployment, one of the best deals you can find is Microsoft Financing:

    https://www.microsoftfinancing.com/

    https://www.microsoftfinancing.com/partnerresourceguide.aspx

    https://www.microsoftfinancing.com/training.aspx

    HTH,

    Mark

  • What causes the operating system to shutdown:

    Licensing Compliance Service caused a shutdown. Please look at the events under Microsoft > Windows > Server Infrastructure Licensing > Operational for details. Event 1074

    C:\Windows\system32\silsvc.exe (TRMANSRV)

    TRMANSRV

    Legacy API shutdown

    0x80070000

    shutdown

    Licensing Compliance Service caused a shutdown. Please look at the events under Microsoft > Windows > Server Infrastructure Licensing > Operational for details.

    NT AUTHORITY\SYSTEM

    00000780

  • Hans,

    If you look in the event log mentioned in the error, it will tell you exactly why the server was shut down.  Common problems are the servers can't communicate, there is a trust, the FSMO roles aren't held by EBS, Management and Messaging aren't DCs, etc.  If you look on the front page of the EBS Admin Console, the error will also be logged there.

    ---Mark

  • Is there another way to launch the "Install CAL Packs Wizard".  When I try to run it from the Administration Console nothing happens.  No errors are logged.

  • Hans,

    C:\program files\windows essential business server\logs\adminconsole*.log will have something relevent.

    You can try launching it manually from C:\program files\windows essential business server\bin\installlicenses.exe.  

    You can also use Powershell as a workaround - http://technet.microsoft.com/en-us/library/dd252607(WS.10).aspx

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment