March 2, 2011 – Hosk's Dynamic Blog

CRM 2011 – New Licensing model encourages CRM integrated Portals

March 2, 2011March 2, 2011Hosk1 Comment

One of my colleges at Crimson forwarded a very interesting article about Licensing changes in CRM 2011, not only was it an interesting well written article but its also good news for companies who develop solutions using CRM 2011.

Someone described the new licence as a developer licence because the cost of offering solutions which are built around the CRM 2011 SDK are going to be a lot lower. The advantages are you can write applications using parts of CRM and users won’t need full CAL licences, which to be honest is a fair deal because if a user isn’t logging into the full CRM system then you shouldn’t have to pay for a full CRM license.

The new license allows you to connect to CRM using portals and the beauty of it is the 10 % cost of a full CAL. I think this is a great move by Microsoft. This seems to fit perfectly with Microsoft’s plan to be the number 1 CRM provider.

Read the full article here, I have just quoted the license information.

Employee Self-Service CAL (ESS)

A new type of CAL has been introduced to the model to allow for licensing internal users that use other applications to connect to CRM without using the CRM web or outlook user interfaces. This employee self-service CAL (ESS CAL) is particularly useful for line-of-business (LOB) xRM applications and for intranet portals that are connected to CRM.

This license type is still a CAL, and that means that it is needed for every internal user. The good news is that it is approximately 10% of the cost of the full-use CAL.

In the past, if you were to build a helpdesk portal for internal users, you would have to license every user in your organization for CRM, even if they were not actually using CRM. For example, you may have a helpdesk staff of 10 users supporting a company of 500 users. Without the ESS CAL, you would need 510 CRM full use CALs. With the new ESS CAL, you would need 10 full use CALs and 500 ESS CALs, representing a savings of just under 90%.

There are some restrictions with the ESS CAL. First off, the obvious – the user can only access CRM through an application that uses the CRM SDK. They cannot access CRM using the CRM Outlook or Web UIs. There are also limitations on which SDK calls can be made. The ESS CAL can create, read, and update all entities in CRM but is restricted to not delete, assign, or share through the SDK. The good news is that it can change state, so the delete capability can be achieved by changing the state to InActive, which is probably best practice anyways, especially if you have turned on auditing and want your audit data to stick around…

Limited CAL

In CRM 4, there were two types of basic user CALs (not to be confused with device CALs). The full use CAL would allow the full use of all CRM capabilities, where the limited CAL allowed for read-only use.

In CRM 2011, there are additional usage rights allowed for the limited CAL. For starters, it is not read-only any longer. Limited update capabilities are available on data that is owned (or assigned) to their user account. The use rights for broader system information in CRM remains read-only.

For SPLA partners, the equivalent to the Limited CAL is the Limited SAL. It has the same use rights as the Limited CAL.

External Connector License

There have been changes made to the external connector license as well. Just for review, the external connector license is only applicable for users that are external to your organization – they cannot be employees or contractors acting on behalf of your organization. The external connector license was previously introduced to allow an external system to be able to connect to CRM and manipulate or query data through the SDK calls. The use of the external connector license has been quite popular since the Portal framework has been introduced and many organizations are building externally-facing websites that are integrated with their CRM system. The external connector remains an on-premise option only as the SPLA and CRM Online license models do not require an external connector, presumably because these are subscription models that include the rights to connect to CRM.

The changes that have been made to the external connector is that the usage patterns have been aligned along the same restrictions of the new ESS CAL. That means that delete, assign, and share operations are no longer permissible with the external connector.

No Professional Server SKU

In CRM 4, there were two server SKUs for an on-prem install – Professional and Enterprise. The primary difference between the two is that the professional edition was limited to a single CRM organization, where the enterprise was capable of hosting multiple CRM organization databases. In CRM 2011, there is no more professional server SKU, and all CRM 2011 Server SKUs have the capability of multi-tenancy. This bodes well for the growth of xRM.

Market Impact

I think the license changes will have a significant positive impact for Microsoft Dynamics CRM 2011. Many internal line-of-business applications that were disqualified as xRM candidates because of ballooning full-use CAL requirements will now be feasible. The new ESS CALs and expanded rights for Limited Use CALs will fill the needs of properly licensing these types of applications using a license cost that is more reasonable.

This is very applicable in the portal space, which is the core competency of Adxstudio. The new ESS CAL will allow our customers to build more internal-facing portals that are integrated to CRM with much lower costs.

Outstanding Questions

As with any new licensing program, there are questions that remain to be answered, and this is no exception.

Q 1: What license can we use to cover the use of internal application connectors that are not users. For example, an ESB such as Biztalk, connecting to CRM and an ERP. An external connector used to be used, but now that delete capabilities have been removed, what license options do customers have to be in compliance? Or can we use a full-use Device CAL for the ESB for this purpose? Also notice that the terminology has been switching to the concept of ‘external’, but an ESB is an internal application connector.

Q 2: I do not see an employee self-service SAL for SPLA environments, nor any mention of an inherent limited use SAL for CRM Online. Consider the scenario where a company hosts their internal helpdesk in Online with an employee portal hosted in Azure. Since the employees that register new tickets in the portal are internal to an organization, they are excluded from being covered by the external connector. Are Limited CALs required despite the users not accessing the CRM UI? I think that Microsoft should include an inherent ESS SAL for SPLA and CRM Online environments to be consistent with how they bundle the inherent external connector license in those environments.

CRM 2011 Blog – Hosk is number 1 and 5000 page views

March 2, 2011Hosk1 Comment

Early this week I passed the 5000 page views (currently 5,265), a small milestone in comparison to my the many great CRM blogs out there but they say every long journey starts with one small step.

As well as looking at the some of my stats, I was looking at what search terms where being typed in and how they found their way to this blog

if you type in crm 2011 blog or crm 2011 books into Google and my blog comes out as the first link, which is pretty impressive.

Here are the all time search links

Search	Views
crm 2011 blog	30
crm 2011 books	30
crm 2011 javascript intellisense	16
silverlight crm 2011	11
crm 2011 metadata browser	10
crm 2011 linq	8
linq crm 2011	8
crmsvcutil 2011	8
crm 2011 book	8
add jquery to dynamics crm 2011	8
crm 2011 sdk	8

Here are this weeks most popular search terms

Search	Views
crm 2011 books	10
linq crm 2011	8
crm 2011 javascript intellisense	7
silverlight crm 2011	6
crm 2011 blog	6
crm 2011 linq	6
crm 2011 sdk	5
crm 2011 javascript	5
crm 2011 jscript	5
dynamics crm 2011 javascript	5

It’s interesting because I can see these items are the topics that have interested me the most and where I have spent most of my time researching over the last couple of months.

Although this CRM blog is generating more traffic through people searching Google I have not yet got many subscribers but I think this is because I have only really been blogging about CRM since December and subscribers need to be earnt

How to upload large report files in CRM

March 2, 2011Hosk6 Comments

If you have a report file in CRM that is larger than 4MB, you will get an annoying and nondescript error when you try to upload it.

The default report size in CRM 4 (and I think CRM 2011 as well). This article – Report and Snapshot Size Limits, this section explains about the maximum size and why it is set to 4MB

Maximum Size for Published Reports and Models

On the report server, report and model size is based on the size of the report definition (.rdl) and report model (.smdl) files that you publish to a report server. The report server does not limit the size of a report or model that you publish. However, Microsoft ASP.NET imposes a maximum size for items that are posted to the server. By default, this limit is 4 megabytes (MB). If you upload or publish a file that exceeds this limit to a report server, you receive an HTTP exception. In this case, you can modify the default by increasing the value of the maxRequestLength element in the Machine.config file.

Although a report model might be very large, report definitions rarely exceed 4 MB. A more typical report size is in the order of kilobytes (KB). However, if you include embedded images, the encoding of those images can result in large report definitions that exceed the 4 MB default.

ASP.NET imposes a maximum limit on posted files to reduce the threat of denial-of-service attacks against the server. Increasing the value of the upper limit undermines some of the protection that this limit provides. Increase the value only if you are confident that the benefit of doing so outweighs any additional security risk.

Now if you have some pictures in your report it can easily go above 4MB but when you try to upload the report you will get an error. You will need to configure the report services, although in this case someone else did this some I’m not entirely sure what had to be changed. I guess you will need to up the memory, these two links should help with that.

Configuring Available Memory for Report Server Applications

http://msdn.microsoft.com/en-us/library/ms159206.aspx

How to: Modify a Reporting Services Configuration File

http://msdn.microsoft.com/en-us/library/bb630448.aspx

You also need to change some web.config settings for the Microsoft Dynamics CRM website, to up the limit from 4MB’s.

This forum post had a good response to what settings you should change, I found you needed to make this change the CRM web.config.

Increasing the maxRequestLength under httpRuntime in web.config file of reporting services will help. The default value is 4MB, however, base64 encoding used by RS has an overhead of approximately 25%, so the actual limit will be hit at around 3.2MB.

e.g. to increase the maxRequestLength to 20MB:

My college also sent me this email, although I’m not sure where he got it from but it basically says something similar to the line above. I not so sure about changing the machine.configs but you may need to so I have included it.

The root of the problem here was .NET. Nothing changed when editing the web.config files. However, there were two machine.config files on the server in the following locations:

C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\CONFIG

and

C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG

The machine.config in the v1.1.4322 folder had exactly what I was looking for with comments on what to replace. But changes these settings will not affect anything. Changing the machine.config for v2.0.50727 will have an affect. The reason why this is, is because IIS was using ASP.net v2.0.50727 (but changing IIS to use 1.1 did not accomplish anything). Now the strange thing about the 2.0.5 version was that it did not have any of the parameters already in it that I needed, so I skipped over it when my search didn’t find maxRequestLength (my mistake there).

HERE IS THE FIX

1. Go to C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG
2. Open machine.config
3. Search for <system.web>
4. Add in <httpRuntime executionTimeout=”9000″ maxRequestLength=”102400″ /> under the <system.web> (I added it right before the end)
5. Save
6. Restart IIS

That should fix the problem. I attached the code that I edited so you know what to look for. The first part is from the file that doesn’t affect anything but tells you what everything does. The second part is the part that I edited and fix everything with.

10:

11:

12:

13:

14:

15:

16:

17:

18:

19:

20:

21:

22:

23:

24:

25:

26:

27:

28:

29:

30:

31:

32:

33:

34:

35:

36:

37:

38:

39:

40:

41:

42:

43:

44:

45:

–v1.1.4322

httpRuntime Attributes:

executionTimeout=”[seconds]” – time in seconds before request is automatically timed out

maxRequestLength=”[KBytes]” – KBytes size of maximum request length to accept

useFullyQualifiedRedirectUrl=”[true|false]” – Fully qualifiy the URL for client redirects

minFreeThreads=”[count]” – minimum number of free thread to allow execution of new requests

minLocalRequestFreeThreads=”[count]” – minimum number of free thread to allow execution of new local requests

appRequestQueueLimit=”[count]” – maximum number of requests queued for the application

enableKernelOutputCache=”[true|false]” – enable the http.sys cache on IIS6 and higher – default is true

enableVersionHeader=”[true|false]” – outputs X-AspNet-Version header with each request

–>

<httpRuntime executionTimeout=”1200″

maxRequestLength=”102400″

useFullyQualifiedRedirectUrl=”false”

minFreeThreads=”8″

minLocalRequestFreeThreads=”4″

appRequestQueueLimit=”100″

enableVersionHeader=”true”

–v2.0.50727

<system.web>

</providers>

</membership>

</providers>

</profile>

</providers>

</roleManager>

</system.web>

Understanding the Web.config file

March 2, 2011HoskLeave a comment

Whilst I am studying for the 70-515 .NET Web applications exam, you are consitently adding things to the web.config file. It was only whilst reading the self study book that I learnt each .NET framework will have it’s own machine.config.

Web.config works in a programming way because it uses inheritence in a roundabout way. You have the machine.config, which is overwritten by application level Web.config, any values in here will overwrite the values in the machine.config but rather than put all the details into the Web.config you just put the values you want to change.

Then each website/web application has it’s own web.config which only overwrites the values it wants to change. ASP.NET does a pretty good job of updating the Web.config file for you but it is good to know what the web.config file looks like and how to manually edit it because you will certainly need to.

Today I found a great article below which is written by Ruben Heetebrij called The ASP.NET Web.config file Demystified, it really explains the Web.config in detail.

Applications of XML have been integrated into .NET to such an extent that XML is hardly a buzzword anymore. Microsoft, as you probably know, has taken XML into the core of its .NET framework. Not only is XML a generally accepted format for the exchange of data, it’s also used to store configuration settings.

Configuration settings for any of your ASP.NET Web applications can be stored in a simple text file. Presented in an easily understandable XML format, this file, called Web.config, can contain application-wide data such as database connection strings, custom error messages, and culture settings.

Because the Web.config is an XML file, it can consist of any valid XML tags, but the root element should always be <configuration>. Nested within this tag you can include various other tags to describe your settings. Since a Web.config file comes as a standard when you start to build a new Web application, let’s look at the default XML file generated by Visual Studio .NET:

<?xml version="1.0" encoding="utf-8" ?> <configuration> <system.web> <compilation defaultLanguage="c#" debug="true" /> <customErrors mode="RemoteOnly" /> <authentication mode="Windows" /> <authorization> <allow users="*" /> </authorization> <trace enabled="false" requestLimit="10" pageOutput="false" traceMode="SortByTime" localOnly="true" /> <sessionState mode="InProc" stateConnectionString="tcpip=127.0.0.1:42424" sqlConnectionString="data source=127.0.0.1;Trusted_Connection=yes" cookieless="false" timeout="20" /> <globalization requestEncoding="utf-8" responseEncoding="utf-8" />
</system.web>
</configuration>

Experienced ASP.NET programmers will have noticed that I’ve left out the comment tags that are generated automatically with the file. I’ve done that to provide a clear view of the XML that’s used here. Also, I’ll elaborate on each configuration tag later in this article, and this discussion will make the comment tags rather obsolete.

If you look at the example XML, you’ll notice that the <configuration> tag has only one child tag, which we call section group, the <system.web> tag. A section group typically contains the setting sections, such as:compilation, customErrors, authentication, authorization, etc. The way this works is pretty straightforward: you simply include your settings in the appropriate setting sections. If, for example, you wanted to use a different authentication mode for your Web application, you’d change that setting in the authentication section.

Apart from the standard system.web settings, you can define your own specific application settings, such as a database connection string, using the <appSettings> tag. Consequently, your most common Web.config outline would be:

<configuration> <system.web> <!— sections--> </system.web> <appSettings> <!— sections --> </appSettings > </configuration>

Let’s discuss the details of both section groups now.

The system.web Section Group

In this section group, you’ll typically include configuration settings that, in the pre-.NET era, you’d have set up somewhere in the IIS administration console. At Microsoft’s MSDN Library, you can find an overview of all the tags that the system.web section group understands, but, depending on the complexity of your site, you may not ever use even half of those options.

Let’s have a look at the most valuable tweaks you can make within the system.web section group, in alphabetical order.

<authentication>

The authentication section controls the type of authentication used within your Web application, as contained in the attribute mode. You’ll enter the value “None” if anyone may access your application. If authentication is required, you’ll use “Windows”, “Forms” or “Passport” to define the type of authentication. For example:

<authentication mode="Windows" />

<authorization>

To allow or deny access to your web application to certain users or roles, use <allow> or <deny> child tags.

<authorization> <allow roles="Administrators,Users" /> <deny users="*" /> </authorization>

It’s important to understand that ASP.NET’s authorization module iterates through the sections, applying the first rule that corresponds to the current user. In this example, users carrying the role Administrators or Users will be allowed access, while all others (indicated by the * wildcard) will encounter the second rule and will subsequently be denied access.

<compilation>

Here, you can configure the compiler settings for ASP.NET. You can use loads of attributes here, of which the most common are debug and defaultLanguage. Set debug to “true” only if you want the browser to display debugging information. Since turning on this option reduces performance, you’d normally want to set it to “false”. The defaultLanguage attribute tells ASP.NET which language compiler to use, since you could use either Visual Basic .NET or C# for instance. It has value vb by default.

<customErrors>

To provide your end users with custom, user-friendly error messages, you can set the mode attribute of this section toOn. If you set it to RemoteOnly, custom errors will be shown only to remote clients, while local host users will see the ugly but useful ASP.NET errors — clearly, this is helpful when debugging. Setting the mode attribute to Off will show ASP.NET errors to all users.

If you supply a relative (for instance, /error404.html) or absolute address (http://yourdomain.com/error404.html) in thedefaultRedirect attribute, the application will be automatically redirected to this address in case of an error. Note that the relative address is relative to the location of the Web.config file, not the page in which the error takes place. In addition you can use <error> tags to provide a statusCodeand a redirect attribute:

<customErrors mode="RemoteOnly" defaultRedirect="/error.html"> <error statusCode="403" redirect="/accessdenied.html" /> <error statusCode="404" redirect="/pagenotfound.html" /> </customErrors>

<globalization>

The globalization section is useful when you want to change the encoding or the culture of your application. Globalization is such an extensive subject that an entire article could be dedicated to the matter. In short, this section allows you to define which character set the server should use to send data to the client (for instance UTF-8, which is the default), and which settings the server should use to interpret and displaying culturally specific strings, such as numbers and dates.

<globalization requestEncoding="utf-8" responseEncoding="utf-8" culture="nl-NL" />

Encoding is done through the attributes requestEncoding and responseEncoding. The values should be equal in all one-server environments. In this example, the application culture is set to Dutch. If you don’t supply a culture, the application will use the server’s regional settings.

<httpRuntime>

You can use the httpRuntime section to configure a number of general runtime settings, two of which are particularly convenient.

<httpRuntime appRequestQueueLimit="100" executionTimeout="600" />

The first attribute specifies the number of requests the server may queue in memory at heavy-traffic times. In the example, if there are already 100 requests waiting to be processed, the next request will result in a 503 error (“Server too busy”).

The executionTimeout attribute indicates the number of seconds for which ASP.NET may process a request before it’s timed out.

<sessionState>

In this section of the Web.config file, we tell ASP.NET where to store the session state. The default is in the process self:

<sessionState mode="InProc" />

Session variables are very powerful, but they have a few downsides. Information is lost when the ASP.NET process crashes, and sessions are generally useless in the case of a Web farm (multiple Web servers). In that instance, a shared session server can solve your issues. It’s beyond the scope of this article to expand on this topic, but it’s worth a mention. More information on sessionState can be found in the MSDN Library online.

<trace>

Your application’s trace log is located in the application root folder, under the name trace.axd. You can change the display of tracing information in the trace section.

The attributes you will look for initially are enabled: localOnly, and pageOutput.

<trace enabled="true" localOnly="true" pageOutput="false" />

Set localOnly to “false” to access the trace log from any client. If you set the value of pageOutput to “true”, tracing information will be added to the bottom of each Web page.

The appSettings Section Group

Apart from the Website configuration settings I’ve been talking about in the preceding paragraphs, you’ll know that a programmer frequently likes to use custom application-wide constants to store information over multiple pages. The most appealing example of such a custom constant is a database connection string, but you can probably think of dozens more from your own experience.

The common denominator of these constants is that you want to retrieve their values programmatically from your code. The Web.config file provides the possibility to do so, but as a security measure, these constants have to be included in the <appSettings> section group. Just like <system.web>, <appSettings> is a direct child tag of the Web.config’s configuration root.

A typical custom section group would look something like this:

<appSettings> <add key="sqlConn" value="Server=myPc;Database=Northwind" /> <add key="smtpServer" value="smtp.mydomain.com" /> </appSettings>

The example shows that keys and values can be included in the custom application settings via an <add> tag. The way to access such a value in any of your Web pages is illustrated below:

ConfigurationSettings.AppSettings("sqlConn")

Yes, it’s as easy as that! Note that the value of these settings is always a String format.

A Few Other Issues

I won’t go into them here, but the Web.config file can contain several other section groups besides the aforementioned system.web and appSettings, such as the configSettings group.

A Web application can contain more than one Web.config file. The settings in a file apply to the directory in which it’s located, and all child directories. Web.config files in child directories take precedence over the settings that are specified in parent directories.

Web.config files are protected by IIS, so clients cannot get to them. If you try to retrieve an existing http://mydomain.com/Web.config file, you’ll be presented with an “Access denied” error message.

IIS monitors the Web.config files for changes and caches the contents for performance reasons. There’s no need to restart the Web server after you modify a Web.config file.

Closing Remarks

In this article, I’ve touched upon the possibilities that the Web.config file offers the ASP.NET programmer. You can use the easily accessible XML file to define your application settings, without the hassle of using the IIS management console. With the Web.config file, ASP.NET lets you add, change and delete basic configuration settings like authentication and authorization, custom error displaying, and tracing in a straightforward manner.

Moreover, the Web.config file offers you room to define any custom key you require, such as database connection strings. What we’ve subsequently seen is that, with just one line of code, you can retrieve the information you need from any page in your application.

Hosk's Dynamic Blog

All views and opinions are personal opinions of the Hosk

Day: March 2, 2011

CRM 2011 – New Licensing model encourages CRM integrated Portals

CRM 2011 Blog – Hosk is number 1 and 5000 page views

How to upload large report files in CRM

Understanding the Web.config file

The `system.web` Section Group

The `appSettings` Section Group

A Few Other Issues

Closing Remarks

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

The system.web Section Group

The appSettings Section Group

A Few Other Issues

Closing Remarks

Share this:

Like this:

The `system.web` Section Group

The `appSettings` Section Group