This blog has moved

I have moved my blog to http://blog.morg.nl.

Changing the identity for a SharePoint 2010 Application pool

There might be a situation where you want to alter the identity for the IIS application pool under which your SharePoint 2010 web applications are running.

You might be tempted to navigate to the IIS settings and alter the identity there:

This is not recommended.

It's best practice to run application pools under a domain user account, i.e. SP_ServiceApps. This account is best managed using Managed Accounts.

To change the identity for an application pool, log into Central Administration and follow these steps:

1. Go to Security and under General Security, click Configure Service Accounts.
2. Select the application pool from the components drop-down listbox (1)
3. Select the managed account that you want to use as the identity for this application pool, or register a new managed account in SharePoint 2010, using the Register a new managed account link.
4. Click the OK button.
5. You'll be warned that this action requires an IIS reset on all servers, click OK.
6. Perform a iisreset /noforce on all WFE servers in the farm.

That's it!

Advanced editing mode in SharePoint Designer 2010

Ever wondered what the difference is between editing page layouts in default mode or advanced mode in SharePoint Designer 2010?

Editing page layouts in default mode is possible when you include a Web Part Zone in your page layout. Editing page layouts in advanced mode allows you to customize anything on the page layout page. Advanced mode is restricted to Site Collection Administrators.

If you find yourself editing a page where certain parts are locked for editing, like in the following example:

simply go into advanced mode, by clicking the button in the ribbon (Home tab, Editing section):

you will now be able to edit all code on the page layout page:

Automatic salutation for contacts in CRM 4.0

I was asked to bring more uniformity in the use of the Salutation attribute in CRM. In this case, the field is used to contain the Dutch equivelant of "Mr" and "Mrs". But there should be an option to give a contact a different or additional salutation.

Here's how it's resolved:

Initially, the Contacts form holds the Salutation text field. We want to reuse this field, but make it more stable.

On the 2nd tab (Details), there is a dropdown listbox for Gender:

This attribute is optional and contains two values, Male and Female.

First we move the Gender field to tab General, section Name:

Next, open the field properties and go to the event tab:

Edit the onChange event and add the following code:


Enable the event and add the fields "Gender" and "Salutation" to the dependent fields.

After you publish the changes, the Salutation field will update to contain one of the the chosen values defined in maleSaltutation and femaleSalutation, whenever the gender attribute changes, unless a different salutation is provided:

Modifying the Account form to hold visiting and postal address in MS Dynamics CRM 4.0

I was asked to modify the Accounts Form in Microsoft Dynamics CRM 4.0, to better match the company and Dutch way of working with addresses. Among others, I wanted to show both the visiting and postal addresses for a company in the same screen.

The Account Form already had some minor modifications; such as making the Primary Contact and Relationship Type recommended values. The Account also already shows a section 'Address' with it's most important attributes. As there was no shipping to customers, attributes such as Shipping Method and Freight Terms could be left out.

The main problem with the current form was the fact that there is only one address on the form, while most accounts have (at least) two addresses that need to be recorded: it's visiting and postal address (which can be the same, but often differ). One solution could be to use the "More Addresses" list, but these are 'generic' address entities that are linked to the account. What many don't know is that an account has

Here's how you go about altering the Account form:

Go to Settings --> Customization --> Custimize Entities, open the account entity and then open the main application form. Next, remove the unwanted attributes from the form and rearrange it.

Rename the address section to Visiting Address.

Then add a new section below the visiting address: Postal Address.

Select the fields from the Address2 collection that you want to use in the Postal Address, in my case these were the same fields as the visiting address.

The fields will be added in the same order in which they are listed in the Add Fields dialog so they'll have to be rearranged.

Rearrange and rename the fields to suit your purpose.


Both addresses also have an Address Name attribute. This field is (often) used to display the organisation name when printing an address. I want it to be equal to the Account Name by default, but still allow the users to modify it to their exact needs. To make this easy, I implemented a client-side script that runs on the OnSave event for the form:

Make sure you enable the event.

It's also wise to set the dependencies for the script, so the fields cannot be removed.

Now when a user saves the form, the Address Name fields for the visiting and postal addresses will be filled with the (mandatory) Account Name field. The Address Name fields are not read-only, so users can override this setting. If they already did fill the fields, they will be left untouched.

In this case, CRM is also used in Dutch, so I'll have to provide translations for the renamed and added form elements.

This is what the form looks like in Dutch, before translating. Export Labels for Translation and open them in Excel or your favorite Xml editor.

Translate the labels. The ones for he Address 2 fields will be empty on initially.

And here's the end result in Dutch. All that's left now is to define the address types for Address 2 (and for the visiting address, if required).