Monthly Archives: June 2012

Why Microsoft killed the Windows Start button (PC PRO UK)

Microsoft claims it took the controversial decision to remove the Start button from the traditional Windows desktop because people had stopped using it.

The lack of a Start button on the Windows 8 desktop has been one of the most divisive elements of the new user interface. It had been widely assumed that Microsoft removed the Start button to force people to familiarise themselves with the new Metro Start screen, which is the centrepiece of the Windows 8 overhaul. However, speaking to PC Pro at TechEd in Amsterdam, a senior Microsoft executive told us that the old Start menu had already fallen out of favour with users of Windows 7.

"We’d seen the trend in Windows 7," said Chaitanya Sareen, principal program manager at Microsoft, referring to the telemetry gathered by the Microsoft Customer Experience Improvement Program. "When we evolved the taskbar we saw awesome adoption of pinning [applications] on the taskbar. We are seeing people pin like crazy. And so we saw the Start menu usage dramatically dropping, and that gave us an option. We’re saying ‘look, Start menu usage is dropping, what can we do about it? What can we do with the Start menu to revive it, to give it some new identity, give it some new power?’"

"So I’m a desktop user, I pin the browser, Explorer, whatever my apps are. I don’t go the Start menu as often. If you’re going to the Start screen now, we’re going to unlock a whole new set of scenarios, or you can choose not to go there, stay in the desktop, and it’s still fast. You can’t beat the taskbar."

Sareen also claims that people are taking advantage of keyboard shortcuts to open applications, instead of resorting to the Start menu. "Press the Windows key and 1 and you’re already in IE [if IE is the first item pinned to your taskbar]. It’s so fast."

Metro for desktops

Sareen was also quick to dismiss criticism that the Metro interface is better suited to touchscreen devices than laptops and desktops.

Demonstrations during the day had seen two Microsoft presenters struggle to make gesture controls work on laptop trackpads, with the Start screen intermittently failing to scroll when the presenters swiped two fingers across the trackpad, for instance. Sareen insisted that the touchpad drivers were still "very, very early" and were "still being refined".

He also claimed that the Metro interface "really works well with the mouse and keyboard", highlighting features such as the option to search for applications simply by starting to type its name on the Metro Start screen.


How to change the Created By column (to be a link to user info but just plain text)

Sometimes you don’t want a column, for example the Created By column, to be a link to user info but just plain text.  You can do this very easy with SharePoint Designer:

  1. First of all you have to open your SharePoint list in SharePoint Designer
  2. In the Views section, select the view that you want to modify


  3. Go to the Design view of the selected view
  4. Click on any name displayed in the Created By column
  5. Go to the List View Tools in the ribbon and select the Design tab
  6. Click Customize XSLT in the Actions section and select Customize Item


  7. Check if the name you selected earlier (Step 4) is still selected and click Delete.


  8. Go to the Current Date Source and select Author.title


  9. Drag Author.title to the place where you deleted the name from (Step 7)

Save the view in SharePoint Designer en refresh your SharePoint site to take a look at the result.

Note: This change is only made for this particular view of a list. If you would have another view, that view would still use the Created By column with a hyperlink.

Working with Managed Metadata and Choice Columns


It’s a problem we commonly face: How do you decide which is best – a choice column or a managed metadata column in SharePoint 2010? In this post I look at what needs to be considered when making that decision.

Let’s look at the problem in more detail first.
For effective management of documents and list items in SharePoint, additional columns (also referred to as fields or metadata) are required in order to classify (or describe) each document or list item. So for example a list of cars might have columns for model, colour, and year of manufacture. The type of information stored in a column is dependent upon the data type of that column. So when you create column in a library or list you are presented with the following options:
This post concentrates on choice and managed metadata columns, as deciding which to use can be problematic. Choice columns are available in all versions of SharePoint, and managed metadata columns are available in SharePoint Server 2010 and SharePoint Online. I often see choice columns being used where managed metadata would have been more appropriate. Typically this is because users were unaware of managed metadata columns.

A choice column simply contains list of values that users can choose one or more values from. It improves the standardisation of recording item attributes by allowing users to pick values from a predefined list. The values are specified within the column definition. For example if classifying cars in a list, a choice column for colour could be used, with the values “Red”, “Green”, “Blue” etc.


Managed metadata, on the other hand, is a collection of centrally managed terms (words or phrases) organised in a hierarchical format. Managed metadata is exposed through a service application in SharePoint. This means that it can be shared across multiple site collections, web applications or even SharePoint farms. Business users may be given control to define terms. Although managed metadata can be hierarchical (for example, region, country, city) it can still be used for list type metadata, such as our list of colours.
When setting a managed metadata value, users can pick terms from the hierarchy, or they can start typing and see suggestions below the textbox:



The following table outlines the key differences between the two column types:

Managed Metadata
Choice column
Hierarchical sets of terms
Centrally defined and published
Presentation as dropdown control, radio buttons or checkboxes
Editable in datasheet view
Terms can be maintained by users independently of their permissions on sites and lists
Matching terms displayed as you type
So how to choose between the two? When either is acceptable, I tend to favour managed metadata as it is more powerful and flexible. However you may want to use a choice field when:
  • You only have a smallish (say less than 100) items to choose from and they are not arranged hierarchically
  • You do not want to use the filtered views of libraries that are available with managed metadata
  • You want to create a "one off" column for a particular library, and have no requirement now or in the future to share that classification across other libraries
  • You want users to have a dropdown rather than the picker in the UI
  • You want to be able to set values in the datasheet view (you can’t do this with managed metadata)
There is more information provided by the following links:
Managed Metadata Overview (SharePoint Server 2010) describing the core concepts and the way it is used with examples:
Great resource for Managed Metadata and Taxonomy including how to plan, configuration and administration:

How to Fix "The webpage cannot be found" in SharePoint 2010 My Sites

Working in SharePoint 2010, it’s a common occurrence to click on someone’s account name in People and Groups to show that user’s My Site. An all-too common occurrence in this scenario involves receiving "The webpage cannot be found" response, as shown below. Seeing this response means that your server has not yet been configured for My Sites. In this article, we will take a look at how to fix this issue for your SharePoint 2010 server.


When clicking on an account name, we will be redirected to that user’s profile page, aka My Site. The problem occurs because we have not configured My Site yet.

Now let’s look at how to configure the My Site in SharePoint 2010.

How to fix:

1. Go to Central Administration then click on Create site collections:

Create a sub site with the "My Host Site" template from the "Enterprise" tab:

2. Go to Central Administration -> Manage Profile Service -> User Profile Service Application -> Setup My Sites:

Regarding the My Site Host location, Type the URL which was created in Step1, in my case:


Location: sites/mysite/Personal

3. Then go to Web Applications Management, and select port configure My Site -> Add our Managed Path:

Type the path which we created in Step 2:

Location: sites/mysite/Personal

–> Click on Add Path:

Then click on Self-Service Site Creation from the Ribbon, and select the On radio button:

4. After configuration has completed, return to home page, and go to People and Groups -> click on User name:

At this point, you will be redirected to the selected user’s My Site successfully, without an error message in sight.

What Every SharePoint Admin Needs to Know About Host Named Site Collections

This post intends to tell you everything you need to know about host named site collections so that you can decide if they are appropriate for your environment.  This post isNOT telling you to run out and create everything as host named site collections in SharePoint, instead it is meant to help educate you about a feature that exists as part of the product.  Simply put, I heard from some of my customers that there was some misinformation in the community saying to never use host named site collections.  This is plain wrong, just as saying to always use them is also wrong.  This post explains what host named site collections are, how to use them, and some limitations to consider if you intend to use them.

What Are Host Named Site Collections

A host-named site collection allows you to address a site collection with a unique DNS name, such as “”.

Typically you will create a SharePoint web application, and it contains many path-based site collections that share the same host name (DNS name).  For example, Team A has a site collection at, and Team B has a site collection at  These are referred to as path-based site collections, and is the recommendation for most corporate scenarios.  Host named site collections enable you to assign a unique DNS name to site collections.  For example, you can address them as and, which enables hosters to scale to many customers.

SharePoint makes the decision on how to map the host name to the site collection when the SPSite object is constructed.  It internally uses the SPWebApplication object to find the web application in the configuration database and determine if there is a host header associated with the site collection.  If no host header information is returned, this is a typical site collection.  Turn on Verbose logging, and for path-based sites you will see a ULS entry similar to “Looking up the additional information about the typical site”.  If host header information is returned, then the host named site collection information is retrieved.  You can see this in the ULS log with the entry “Site lookup found the host header site”.

Host named site collections have been in the product since SharePoint 2003, where it was referred to as “scalable hosting mode”.  The point is that host named site collections is not a new feature to SharePoint 2010, it has been around a long time and customers have been successfully using it in their environments for many scenarios for quite a long time now.

Admittedly, there were several known issues with the implementation early on in SharePoint 2007, such as the inability to use blobcache with host name site collections (seeStefan Gossner on MOSS 2007 blob caching and its limitations), which has contributed to the misinformation in the community and lingering perception issues about the appropriate use of host named site collections.  This issue as well as several others were addressed early on with SharePoint 2007.  You can see in the screen shot below that images are in fact cached using blobcache using SharePoint 2007 just fine.


To be clear, the blobcache issue was never an issue in SharePoint 2010, in fact SharePoint 2010 made two significant improvements for host named site collections: the ability to use managed paths with host-named site collections, and the ability to use off-box SSL termination with host-named site collections.  Host-named site collections can also be used to implement multi tenancy solutions (for a complete discussion on multi tenancy in SharePoint 2010, see Spence Harbar’s excellent Rational Guide to Multi Tenancy in SharePoint 2010).  Office365 is implemented using host named site collections and multi tenancy as this is how the product scales to support many, many customers for that specific hosting scenario.

Creating Host Named Site Collections

To better understand host named site collections, let’s see how you create them. You cannot use the self-service site creation web UI to create a host-named site collection, but instead you use PowerShell. The following code creates a new web application listing on port 80, and two host named site collections that use the Publishing Portal site template.

$w = New-SPWebApplication -DatabaseName "WSS_Content_HostNameTest" 
    -ApplicationPool "SharePoint - Content App Pool" -Name "HostNameTest" -Port 80 

#Remember to do IISRESET /noforce on each server before using the new web application 

$w = Get-SPWebApplication "HostNameTest" 

New-SPSite -OwnerAlias "SHAREPOINT\kirkevans" 
    -HostHeaderWebApplication $w -Name "HostA" -Template "BLANKINTERNETCONTAINER#0" 

New-SPSite -OwnerAlias "SHAREPOINT\kirkevans" 
    -HostHeaderWebApplication $w -Name "HostB" -Template "BLANKINTERNETCONTAINER#0"

The result is a web application that contains my two host-named site collections.  There is a third site collection for the Office Viewing Cache because I am using Office Web Apps.  I did this to show that you can have a mix of path-based and host named site collections within the same web application.


We created two host named site collections, but I didn’t say anything about adding the host headers into the IIS bindings. That is because the web application that contains them listens to *:80, any port 80 traffic that is not otherwise directed to another web application on the same machine is directed to this web application.  You can verify this by looking at the bindings for the containing web application in IIS.


This is an important point to consider.  If you create the web application with a non-default port, something like 3759, your host named site collections should also be on that port.  Otherwise, you will have to manually add the host header entries in the bindings in IIS, and do this on every machine.  Just say no to non-default ports, use port 80 and make everyone’s life easier.  You really do not want to start editing the bindings for the web applications manually, especially on every machine in your farm.  Typically you will just use a web application that listens on *:80.

Reiterating this point, if you are going to implement host named site collections, you should not use a host header for the containing web application that houses the host named site collections or it will not work properly.  Doing so will create a host name binding for the web application in IIS, and the other host names will not be routed to the IIS site.  In the example I used, all host names are processed by port 80, which alleviates the need to manually add host bindings in IIS.  This has one unfortunate downside: if other web applications that use host headers, say, are stopped due to application pool failures or other issues, then the application that listens on *:80 will process the traffic.  This can lead to unexpected results if the site uses a different authentication mechanism or is processed by a different application pool identity.  It’s just a function of how IIS works, but something to consider when designing your applications and something you should test in your environment (you do test things before implementing them in production, don’t you?)

Managed Paths and Host Named Site Collections

As stated previously, an improvement to host named site collections in SharePoint 2010 is the ability to use managed paths.  As we saw when creating host named site collections, there is no UI to create a host header managed path, you instead use PowerShell using the –HostHeader switch on the New-SPManagedPath PowerShell command.

New-SPManagedPath "cthub" -HostHeader -Explicit

$w = Get-SPWebApplication "HostNameTest"

New-SPSite -OwnerAlias "SHAREPOINT\kirkevans" 
     -HostHeaderWebApplication $w -Name "HostA Content Type Hub" -Template "sts#0"

In this example, we create a managed path “cthub” and create a site collection using that managed path.  The results are as you would expect, a new site collection is created using the DNS name using the managed path “cthub”.


This can be hugely beneficial when defining consistent provisioning solutions.

Can I Use Alternate Access Mappings with Host Named Site Collections?

SharePoint provides a capability to create a web application using a host name such as, and you extend the web application using a new alternate access mapping for the web application to a new host header such as This is particularly useful when you have different users accessing the same content through different authentication means. Internal users authenticated with Windows claims can access the web application using, and external users access the same content using The difference is the URL that you use to access the web application.

With host named site collections in SharePoint 2010, you do not have the ability to provide different authentication mechanisms based on the host header. Remember that this happens at the web application level. Using our previous example of a web application “HostNameTest” that contains two host named site collections, “” and “”, it is not possible in SharePoint 2007 or 2010 to provide different authentication to each of the site collections. This means that you cannot use alternate access mappings with host named site collections. This should be a consideration when designing your information architecture.  If you need to support site collections responding to multiple host-name URLs, consider using path-based site collections with alternate access mappings instead of host-named site collections.

Host Named Site Collections Only Use One Host Name

Continuing on the discussion on AAMs and host named site collections, you cannot use multiple host names to address a site collection in SharePoint 2010. Because host-named site collections have a single URL, they do not support alternate access mappings and are always considered to be in the Default zone.  This is important if you are using a reverse proxy to provide access to external users. Products like Unified Access Gateway 2010 allow external users to authenticate to your gateway and access a site as and forward the call to Remember that URL rewriting is not permitted. Further, a site collection can only respond to one host name. This means if you are using a reverse proxy, it must forward the calls to the same URL.  If your networking team has a policy against exposing internal URLs externally, you must instead use web applications and extend the web application using an alternate access mapping.

Host Named Site Collections and SSL

We’ve pointed out several times that we can only use one host name, can we simultaneously use both HTTP and SSL based URLs simultaneously?  The answer is no.  By default, host-named site collections in SharePoint 2010 use the same protocol scheme as the public URL of the Default zone of the web application.  If you wish to provide host-named site collections in your Web application over SSL, ensure that the public URL in the Default zone of your Web application is an HTTPS-based URL.

[Update: thanks, Spence Harbar!]  The August 2010 Cumulative Update adds additional support for both HTTP-based host-named site collections and HTTPS-based host-named site collections to coexist in the same web application. By default this support is disabled. To enable this support, set the

Microsoft.SharePoint.Administration.SPWebService.ContentService.EnableHostHeaderSiteBasedSchemeSelection property to true. As soon as it is enabled, SharePoint will no longer use the web application’s default zone public URL protocol scheme for all host-named site collections in that web application. Instead, SharePoint will use the protocol scheme provided during host-named site collection creation, restoration, or rename. Host-named site collections that are created before this update is installed will default to use the HTTP protocol scheme if this property is set to true. These site collections can be switched to use the HTTPS protocol scheme by renaming the host-named site collection and providing an HTTPS-based URL as the new site collection URL.

To configure SSL for host-named site collections, enable SSL when creating the Web application. This will create an IIS Web site with an SSL binding instead of an HTTP binding. After the Web application is created, open IIS Manager and assign a certificate to that SSL binding. You can then create site collections in that Web application.

A server certificate has to be installed and assigned to the IIS Web site. Each host-named site collection in a Web application will share the single server certificate assigned to the IIS Web site.  You need to acquire a wildcard certificate or subject alternate name certificate and then use a host-named site collection URL policy that matches that certificate.  For example, you will need a * wildcard certificate to generate host-named site collection URLs such as,, and so on, to enable these sites to pass browser SSL validation.  If you require unique second-level domain names for your sites, you have to create multiple Web applications rather than multiple host-named site collections.

Because SharePoint Server 2010 uses the public URL in the Default zone of the Web application to determine whether host-named site collections will be rendered as HTTP or SSL, you can also use host named site collections with off-box SSL termination.  As discussed in the previous section, “Host Named Site Collections Only Use One Host Name”, the SSL terminator must preserve the original HTTP host header from the client.  As discussed in the TechNet paper, Plan for host-named site collections (SharePoint Server 2010), there are 3 requirements to use SSL termination with host-named site collections:

  • The public URL in the Default zone of the Web application must be an HTTPS-based URL.
  • The SSL terminator or reverse proxy must preserve the original HTTP host header from the client.
  • If the client SSL request is sent to the default SSL port (443), then the SSL terminator or reverse proxy must forward the decrypted HTTP request to the front-end Web server on the default HTTP port (80). If the client SSL request is sent to a non-default SSL port, then the SSL terminator or reverse proxy must forward the decrypted HTTP request to the front-end Web server on the same non-default port.

The ability to use SSL termination and managed paths makes host header site collections a very powerful tool for hosting scenarios.

Size Matters

When you need to create vanity URLs, the first question you must ask yourself is “how many URLs will I need?” The unit of scale for SharePoint is at the site collection level. There is a tested limit of around 100 web applications for SharePoint, while each web application can have up to 250,000 site collections (see notes in the section “Know Your Limits” for discussion on number of web applications). When talking about options for vanity URLs, size matters. I have heard several people blanketly denounce host named site collections without providing context around the size of the environment or the solution being architected. It is important to remember the guidance in the SharePoint Server 2010 capacity management: Software boundaries and limits paper when architecting your information architecture. If you require a handful of vanity URLs, you are likely going to be better served creating web applications and leveraging alternate access mappings. If you are creating hundreds or thousands, then obviously you can’t create this many web applications, you are left with host-named site collections.  See the section below “Know Your Limits” and understand the software boundaries and limits when designing your information architecture.

Uptime Matters

When you create a new web application using the SharePoint web UI, you are reminded to use “IISRESET /noforce” on each of the servers before using the web application.  Simply put, this affects your uptime, even for a very short duration.  A benefit to host named site collections is that you do not need to issue IISRESET when you create a site collection, host named or path-based.  Maybe this isn’t a big deal in your environment, but in some environments an IISRESET is a big deal.  You can see in my example above that I include a note reminding you to use IISRESET on each machine, this is only because I created a new web application as part of the demo.

Can’t I Just Rewrite the Path?

ASP.NET 2.0 introduced a very cool feature that you could rewrite a URL programmatically, such that a request for could be rewritten to  This allows for URLs that are easier for end users to understand and navigate your web site.  SharePoint does not support asymmetrical URL rewriting (  Modifications to the content path or the host name are not supported.  This means that URL rewrites (different than redirects, see the next section) cannot be used with SharePoint 2010.  I have seen several developers try to do this to do things like remove “Pages” from the URL, this is not supported either.  The inability to rewrite the path has implications on other scenarios, such as reverse proxies.  See the section “Host Named Site Collections Only Use One Host Name” for a discussion on reverse proxies.

What About Redirects?

If your goal is to provide vanity URLs, then there is another approach to consider: using HTTP redirects.  You can configure IIS to redirect all requests to a particular path to another resource.  This is different than URL rewriting because the client makes a request to a resource, receives a 302 redirect response, and then requests the new resource based on the information in the 302 redirect.  In fact, Jie Li mentions using redirects in an attempt to address SEO.  For many cases, this is absolutely a great approach.  However, consider that SOAP (web services) does not handle 302 redirects.  This means anything that calls SharePoint with the vanity URL will not work.  If your end user tries to use one of the Office client applications and work with SharePoint using their vanity URL, they will receive unexpected behavior and error messages because those applications use SOAP to communicate with the server.

Kerberos and Host Named Site Collections

You are probably wondering if you can use Kerberos with a host named site collection, and the answer is yes.  To prove this, I configured the web application “HostNameTest” to use Negotiate for authentication.  Its application pool is running as an account sharepoint/sp_app.  The DNS entry for “” was set up as an A record.  I added a SPN “HTTP/” to that account, made a request, and we see a Kerberos ticket when I use KLIST.exe.  This shows that I am getting a Kerberos ticket.


Yes, Kerberos works with host-named site collections.

Migrating Path-Based to Host Named Site Collections

If you have a number of web applications that provide vanity URLs and you are approaching some of the software boundaries for too many web applications (see the next section!), you are probably wondering if you can somehow collapse the information architecture to use host named site collections instead of path-based site collections in web applications.  The answer is yes!

In order to convert from path-based to host named site collections, you have to use backup and restore using PowerShell.  Back up the site collection to a file using Backup-SPSite, and then restore to a host named site collection using Restore-SPSite.

Backup-SPSite http://server_name/sites/site_name -Path C:\Backup\site_name.bak

Remove-SPSite –Identity http://server_name/sites/site_name –Confirm:$False  

Restore-SPSite -Path C:\Backup\site_name.bak -HostHeaderWebApplication http://server_name 

It goes without saying that when you backup and restore, make sure that you are not creating multiple site collections that are identical in your farm to avoid duplicate GUIDs.  It is important that you remember to use Remove-SPSite before Restore-SPSite in this example.

In SharePoint 2007, site collection restore was performed with “stsadm –o restore”, which did not provide a mechanism to specify which content database would contain the site collection.  A nice change in SharePoint 2010 is the Restore-SPSite command allows you to specify the content database that will house the site collection.  This lets you kill two birds with one stone if your old path-based site collection was contained in a content database that was approaching the 200 GB limit, you can move the content to a new content database.

By default, the site collection will be set to read-only for the duration of the backup to reduce the potential for user activity during the backup operation to corrupt the backup.  Another nice feature of the improved capabilities in SharePoint 2010 (compared to SharePoint 2007) is the ability to use SQL snapshots with SQL Server Enterprise Edition.  If you have SQL Server Enterprise Edition, we recommend that UseSqlSnapshot parameter be used because this ensures a valid backup while it allows users to continue reading and writing to the site collection during the backup.

See the next section, “Know Your Limits”, for discussion on limitations of the Backup-SPSite and Restore-SPSite commands.

Know Your Limits

There are many factors that you should consider when designing any information architecture, host-named site collections or not.  As a SharePoint administrator, you should commit the SharePoint Server 2010 capacity management: Software boundaries and limits paper to memory.  I am pointing these limits because while most readers will have small farms with a handful of cases where host named site collections are used, there are a few administrators of huge farms that could potentially have tens of thousands of host named site collections.  Understand the limits of the product when designing your provisioning solution.  Also understand that some of these limits are extreme boundaries that may not be at all applicable to your environment, in fact your environment may not be capable of reaching some of these numbers.

  1. The number of application pools is limited to 10 per web server.
  2. There is no published limit for the number of web applications for SharePoint 2010.  The limit in SharePoint 2007 was 100 web applications total.  Most of the Premier Field Engineers that I work with recommend that this limit generally applies to most SharePoint 2010 environments.  This is due to the number of timer jobs, resource contention, and other factors that vary by environment.  In fact, most PFEs recommend a practical limit of number of web applications to around 20 web applications to improve manageability of the environment.
  3. Each web application can have up to 300 content databases. 
  4. Each content database can have up to 200 GB of content. 
  5. Maximum recommended 2000 site collections per content database. If you intend on creating many site collections, take this and the max content database size in mind.

Other considerations to keep in mind is how your information architecture may impact search.  Search will not automatically pick up the host named site collections, you may need to manually add the addresses in as start addresses or as content sources. Given the limit of 100 start addresses, you may need to define multiple content sources and start addresses. This means you need to keep the following software boundaries and limits in mind:

  1. Limit to 100 scope rules per scope; 600 total per search service application.
  2. Maximum 200 site scopes and 200 shared scopes per search service application.
  3. Maximum 50 content sources per search service application.
  4. Maximum 100 start addresses per content source.

If you are using host named site collections for vanity URLs (not using multi-tenancy), you should also consider the behavior of the PeoplePicker.  You can adjust the PeoplePicker settings to only resolve names within the current site collection (  This isn’t really anything to do with host named site collections, but worth pointing out.

As mentioned in the Migrating Path-Based to Host Named Site Collections section above, content is migrated from path-based to host-named site collections using Backup-SPSite and Restore-SPSite (replacing the stsadm backup and restore).  This command has a tested limit of 15 GB.  I have one customer who is able to use this command with much larger content databases, and another customer who times out with 18 GB databases.  It varies depending on disk latency for the local disk as well as disk latency / throughput in SQL. Know that the supported limit is 15 GB if you intend to migrate from path-based to host named site collections.

Customize out-of-box Workflows in SharePoint 2010

In SharePoint 2007 out of box workflows were rigid, you cannot modify them but in SharePoint 2010 you have ability to customize out-of-box workflows using SharePoint Designer. Now, let’s get into the action and tweak the Approval Workflow a bit –

  • Open your Site Collection in SharePoint Designer (SPD). Under Navigation on left side click Workflows.

  • Right click Approval – SharePoint 2010 workflow and click Copy and Modify option.
  • Give Name to your workflow ‘Custom Approval – SharePoint 2010’ and select All in Content Type Field. Click OK.

  • You will get the below workflow editor window.

  • Let’s say that at the very end of this workflow you wish to log to the history list that the workflow has finished executing. To do that click below the line and type Log and press Enter. Click ‘ this message’ and write ‘ Workflow has finished executing’ .

  • Save the workflow.

Now, let’s remove CC field from the Initiation Form.

  • On the Ribbon click Initiation Form Parameters .
  • Click the CC in the pop-up window and modify it to Show on ‘ Association ’. Click OK

  • Save and publish the Workflow using buttons on the ribbon.

We have completed the process of customizing the out-of-workflow and removed CC field from Initiation Form. Now let’s attach this customized workflow to the list.

Create a List and Attach the customized Workflow to it
  • Open your site in browser and create a list ‘Approve Items’.
  • Go to the List Setting –>Versioning Settings. Make setting as below
  1. Content Approval – Yes
  2. Item Versioning History(optional) – Yes
  3. Draft Item Security(optional) – Only users who can approve items

  • Return to the list and you will see Approval Status column created for you.
  • In the Ribbon, under List tab à Workflow Settings à Add a Workflow
  • Select your customized workflow in Workflow section. Give Name to the Workflow.
  • Click Next.
  • Fill out the required fields and  Enable Content Approval .

  • Click Save
  • Go to your list and add an item. Check Approval Status – Pending
  • Open Item menu and click Workflows.

  • Click on your Workflow.

  • Here comes your Initiation Form with NO CC Field .

  • Start the Workflow by clicking Start button.
  • Approve the item by going back to the list. Status will change from In Progress to Approved.
  • Click on Approved Link and check the Workflow History, it has your log.