Blog

Home > Blog

Archive for April, 2008

Microsoft Dynamics CRM 3.0 Licensing

Wednesday, April 30th, 2008

A few pieces of interesting information regarding Microsoft Dynamics licensing that we have recently discovered:

  • If you have licensed Dynamics CRM 3.0 as part of an Action Pack subscription it is not possible to add more than 10 active users. This is because since the release of CRM 4.0 the FPP (or full packaged product) CAL that was required is no longer available and it is the only kind of CAL that came with a key. No key means no additional licenses.
  • If you have licensed Dynamics CRM 4.0 as part of an Action Pack subscription be warned you are only entitled to the “Workgroup” edition which has but 5 users. This cannot be extended.

Interestingly since Microsoft deems the “Action Pack” to be a subscription-based license you, as the client, do not actually “own” the license and therefore are not eligible for upgrade pricing either. When you hit the 6th/10th user (depending on your version) you will be up for the CRM Server license and as many CALs as you have users, since you cannot use the Action Pack CALs on a box product or volume license. This obviously makes the transition very expensive and while you can at least continue to use your Action Pack SQL Server it seems like this group have not been well catered to in the revised licensing model.

By the way – Action Pack users are generally Microsoft partners – not the group I would have chosen to upset, but then they have more money than me…

[UPDATE - With the recently released Microsoft CRM 4.0 there is all new confusion.  See my new post on Microsoft Dynamics CRM 4.0 Licensing for more info.]


View Comments (1)

Public proxied access to SharePoint (WSS or MOSS)

Wednesday, April 30th, 2008

We use Microsoft Office SharePoint 2007 internally to manage all kinds of work and share documents. It’s a very effective tool. We also use it to manage our software registration database.

To facilitate customer software registrations we have a public-facing web service that uses SharePoint APIs to communicate with our registration site. The configuration of SharePoint required some fiddling to make this work. The problem was that we had SharePoint configured with no anonymous access, and obviously the users of our software that would be registering would not have credentials for our network – we didn’t really want to enable anonymous access so a creative solution was required.

In order to achieve this we used the web.config <identity /> element in our public-facing website to set the identity of the thread to a fixed user account created just for the task. The web service application pool is configured in IIS to run as “Network Service”. The SharePoint API seemed to pick up the user from the HttpContext.Current.User object, rather than from the thread which means that all our communications were failing with 401.5 errors. I was a little surprised to discover that despite the <identity userName=userpassword=passimpersonate=true/> in the web.config file, the HttpContext.Current.User was still anonymous.

The two tricks that made it work were:

  • In Global.asax use the Application_BeginRequest() method as follows:
    HttpContext.Current.User = new WindowsPrincipal( WindowsIdentity.GetCurrent() );
  • In our code ensure that each time we made a connection to the SPWeb we called:
    spWeb.AllowUnsafeUpdates = true;

The Global.asax trick ensures that the context carries the same user account as the impersonated thread.

The AllowUnsafeUpdates is required when impersonating.


No Comments

Forms, Controls & the Forms Designer

Monday, April 14th, 2008

I was just working on a Windows app that contains lots and lots of User Controls all of which inherit from a base User Control.

When I opened the controls they displayed blank in the designer. After some digging I realised that two vital pieces were missing:

  1. All controls need to have a parameterless constructor, but they do not need to be public (mine are “protected”)
  2. The default constructor needs to call InitializeComponent() as this is the method that puts controls into their positions on the form

It seems the Forms Designer creates an instance of the control by calling the parameterless constructor (which seems obvious when you think about it I suppose).

The giveaway on the InitializeComponent() call was the comment just above the call injected by default which reads “Required for Windows Form Designer support“.

Anyways – hopefully this will save somebody some time.


No Comments

Level 7, 491 Kent Street, Sydney, Australia  +61 2 9321 1555  info@5limes.com.au
Copyright ©2009 5 Limes Pty Ltd. ABN 87 119 340 680  All Rights Reserved