Set Access Request Email on All Sub-Site of a Web Application

Hi all!

Follow a Powershell script to change the Access Request email for all sites in a we b application:

$webapp = Get-SPWebApplication ""
$currentEmail = "";
$newEmail = "";

foreach($site in $webapp.Sites)
   foreach($web in $site.AllWebs)
     $url = $web.url
	 Write-host $url
     if (!$web.HasUniquePerm)
            Write-Host "Access Request Settings is inherted from parent."
			Write-Host "Access Request Settings is enabled."
			write-host $web.RequestAccessEmail
	        if ($web.RequestAccessEmail -eq $currentEmail)
				Write-Host "Email needs to be updated."
				$web.RequestAccessEmail = $newEmail
				Write-Host "Email changed successfully!"

            Write-Host "Access Request Settings not enabled."


Hope this helps you!


See you,


Removing a Web Part from Pages Using Powershell

Hi all!

Today I’m just posting this useful Powershell script to remove a web part from all the pages in a specific site.

It goes through all the libraries you define and looks for instances of the web part and removes to ones it finds.


$wpName = "Your_Web_Part_Name";
$checkedOut = @()
$site = new-object Microsoft.SharePoint.SPSite -argumentList "";

$webApplication = $site.WebApplication;

foreach($spsite in $webApplication.Sites)
	$spweb = $spsite.OpenWeb("your web site name")
	$url = $spweb.Url;

	write-output "Processing $url"

	# libraries to check for the web part on pages
	$libraries = @("Pages");

	foreach($lib in $libraries)
		$title = $list.Title
		foreach($item in $list.Items)
			$WebPageUrl = $item.Url
			write-output "Processing page $WebPageUrl"

			$spWpManager = $spweb.GetLimitedWebPartManager($WebPageUrl, [System.Web.UI.WebControls.WebParts.PersonalizationScope]::Shared);
			$webparts = @()

			if ($item.File.CheckOutType -ne "None")
				$checkedOut = $checkedOut + $WebPageUrl + ","

			foreach($spwebpart in $spWpManager.Webparts)
				if($spwebpart.Title -eq $wpName)
					$webparts = $webparts + $spwebpart.ID

			foreach($webpartId in $webparts)
	write-output "$url has been processed."
	write-output "The following pages were checked out and could not be processed: $checkedOut"


	if($spWpManager -ne $null)

The code file can be found here.

See you,


The Business Analysis Masterclass

The Business Analysis Masterclass is a series of posts by Chris Wright explaining how you can be a better BA working with SharePoint.

The posts are very interesting and cover several simple to apply processes which could be used in lots of projects (involving SharePoint or not). His target is to post 100 articles in a 100 days.

By the way, The Microsoft SharePoint Blog (not the official SharePoint one) is a very good blog with articles divided in categories such as IT Professional, Developer, Project Management and Analysis.

See you,


URL Rewriting – Part 1: The Basics

Sometime ago I’ve been asked to deliver a rewrite/redirect engine solution for a project. I started researching, got some tips from my boss and found a few IIS/.NET solutions to do this kind of operation: IIS URL Rewrite ModuleURLRewriter.Net and URLRewriting.Net.

Doing this task I realized there is not much information about URL rewriting in general and even less articles about using it with SharePoint 2010. I then decided to write a series of articles on how to use it, how to configure it on IIS and apply the URL rewrite concept to SharePoint 2010.


What is URL Rewriting?

URL Rewriting is the operation of change the external URLs for a web site in order to allow it to have more meaningful and search friendly URLs. It can make your site easier to use and also make it more appropriate (or friendly) for the search robots crawling it.

As more web sites become dynamic and data driven, some of them expose really confusing URLs for either people to memorize and understand or for search robots to analyze. URL Rewriting can help sole this problem allowing site admins to expose URLs that actually represent the page’s content.


Here some examples of hard to remember and understand URLs:,mod=9&sourceid=chrome&ie=UTF-8&q=url+rewriting


Here are some examples of friendly URL:


Which URLs would you prefer to have on your web site?


URL Rewriting can be done in two ways: rewrite or redirect.

On the rewrite operation we have the actual meaning on the URL rewriting. We are hiding our internal complex URL and exposing a friendly URL. When the friendly URL is requested we translate it to our internal URL (full of parameters and numbers nobody but our site would understand) and execute it. The user’s browser will receive the returned HTML with the friendly URL.

On the redirect operation we expose a friendly URL but instead of executing our internal URL and keeping the friendly URL for the user’s browser, the user is redirected to a different URL, a friendly or not so friendly one, depending on how we configure the redirect.

On the browser’s level the difference between rewrites and redirects is how the URL will be displayed. On the rewrite, the browser will keep the friendly URL all the time. On the redirect, IIS will send a HTTP request for a new URL back to the browser, the browser will request the new URL and the browser’s address bar will be updated with the new URL. The user will definitely notice that the URL has changed.


As an example of rewrite we could have:

-The user types an url on the browser:

-The redirect engine detects that this URL should be changed to newurl.

-The redirect engine makes an IIS call to new url and send its HTML output back to the browser.

-On the browser’s address bar the user will still see the old url:


As an example of redirect we could have:

-The user types an url on the browser:

-The redirect engine detects that this URL should be changed to newurl.

-IIS will send a HTTP request asking the user’s browser to go to

-The browser will request the new url and update its address bar.



IIS URL Rewrite 2.0

Analyzing a few solutions for this URL Rewriting, the one I liked better was the IIS URL Rewrite 2.0. In my case it made more sense since the run SharePoint 2010 and IIS 7 and it would be easily integrated with these technologies.

The URL Rewrite is an IIS 7 feature which allows you to process inbound and outbound URLs and redirect or rewrite it according to rules. The rules can be hard-coded, use wildcards or can even be regular expressions (I really enjoy using REGEX even though it is not that easy to create or maintain the expressions).


For more references on the IIS URL Rewrite check these links out:

URL Rewrite 2.0:

URL Rewrite Extensibility Samples:

Using Custom Rewrite Providers:

Developing a Custom Rewrite Provider:


The installation is very simple. You just need to download the installer and run it.

Get the 32-bit installer or the 64-bit installer.

After it is installed, open IIS Manager and check a new icon on the web site’s features.


Using the URL Rewrite

When you click on the URL Rewrite icon on the web site’s features, it will take you to the URL Rewrite rules screen. It should be an empty screen since we don’t have any rule configured. Rules are the definitions telling IIS how to handle the URLs. Basically, we can have inbound rules and outbound rules. Inbound rules are applied when the requests come to IIS and outbound rules are applied before IIS sends HTML back to users’ browsers.

It is now time to add rules and start with URL rewriting.


Inbound Blank Rules

On the URL Rewrite screen, click on “Add Rule(s)…” link on the Actions panel.

Select the Inbound Blank rule template.

When creating a rule you need to define:

  • Name: rule name.
  • Match URL: defines the rules for matching URLs and applies your rule.
    • Requested URL:
      • Matches the pattern: your rule is applied if the requested URL matches the pattern.
      • Doesn’t match the pattern: your rule is applied if the requested URL doesn’t match the pattern.
    • Using:
      • Regular expressions: defines Regex as the parser for the expression defined on the pattern field.
      •  Wildcards: defines the wildcards parser as the parser for the expression defined on the pattern field.
      • Exact match: defines the URL should match exactly what is on the pattern field.
    • Pattern: defines the pattern to be searched on the URLs.
    • Ignore case: defines if your rule ignores case on the matching test. That is a important field to be selected since you have no idea on how users might type URLs.
    • Conditions:

      • Defines conditions based on the HTTP request for the rule.
      • Logical grouping:
        • Match all: requires all matches to continue processing the rule.
        • Match any: one match is enough to continue processing the rule.
      • New Condition:
        • Condition input: request variable.
        • Check if the input string: has option on how to match the input string.
        • Pattern: can be a regular or wildcard expression.
    • Server Variables

      • Allows the rule to change values of server variables.
      • Set server Variable:
        • Server variable name: variable name.
        • Value: new value.
        • Replace existing value: allows the value to be replaced if it already exists.
    • Action:

    Action types available: rewrite, none, redirect, custom response and abort request.


    Defines that your rule will rewrite the URL and execute it but the URL on the user’s browser will continue the same. This execution will be transparent for the user.

    • Action Properties:
      • Rewrite URL: URL to execute instead of the original one.
        • Offers tags to be used as dynamic part of the rewrite URL:
          • {R:0}: returns the whole input expression.
          • {R:1}: returns the first part of the input URL contained in parenthesis.
          • {R:N}: returns the N part of the input URL contained in parenthesis.
      • Append query string: appends to original query string to the new URL.
      • Log rewritten URL: logs rewritten URLs to IIS log files instead of logging the URLs request by the browser.
    • Stop processing of subsequent rules: the rules are processed in the order they appear on the Rewrite Rules screen. When selecting this option your rule will abandon the processing of the following rules if this rule is applied. This normally is how you want to configure it.


    No action should be taken. This is an odd option to be seem here since we can disable the rule.


    Defines that your rule will rewrite the URL and send the new URL back to the user’s browser. The user will notice the URL has changed and a new request will be made to IIS to process the new URL.

    • Action Properties:
      • Redirect URL: URL to redirect the browser to.
        • Offers tags to be used as dynamic part of the redirect URL:
          • {R:0}: returns the whole input expression.
          • {R:1}: returns the first part of the input URL contained in parenthesis.
          • {R:N}: returns the N part of the input URL contained in parenthesis.
      • Append query string: appends to original query string to the new URL.
      • Redirect Type:
        • Permanent (301): Redirects the browser to the new URL and tells the browser to cache it.
        • Found (302): Temporary redirect. The browser doesn’t cache it.
        • See other (303): Redirect for application using POST HTTP method.
        • Temporary (307): Also a temporary redirect introduced on HTTP 1.1. Requires the request to be repeated to be executed.

    Custom Response

    Creates a custom HTTP response to the browser with a status code defined by the rule.

    • Action properties:
      • Status code: status code number.
      • Substatus code: substatus code number.
      • Reason: string with the reason.
      • Error description: string with the error description for the response’s body.

    Abort Request

    Aborts the request and drops the HTTP connection.


    Example of an Inbound Rule

    In our example we are going to setup a regular expression rule to rewrite the friendly URL /products/45/sharepoint-book to our actual application URL /products.aspx?id=45&name=sharepoint-book.

    Basically we are creating a rule to get any URL composed by products/[a sequence of any characters]/[a second sequence of any  characters] and rewrite it as product.aspx?id=[first sequence of characters]&name=[second sequence of characters].


    Testing the example

    The product.aspx page code is very simple and just shows the two query strings ID and Name.

    The test it, first we accessed the regular URL using the parameters in the querystring.


    Then we tested our rewrite rule:


    It worked just fine. Behind the curtains IIS got the friendly URL /prodcuts/45/sharepoint-books and execute the URL /product.aspx?id=45&name=sharepoint-books.


    IIS UI versus Web.config

    All the options you configure on the IIS user interface actually are written on the web.config file.

    If you fill more comfortable going to the web.config file you can configure all of your rule there. It is also a much simpler way to copy the settings to move to a different server.

    All the settings are under configuration/system.webServer/rewrite node.

    Follow the web.config snippet for the inbound rule we created:


    On the next article I will write about outbound and user-friendly URL rules.


    See you,


Developing for SharePoint Using Visual Studio 2012 – Tech Ed North America

I just watched the video Developing and Managing SharePoint Solutions with Microsoft Visual Studio from Tech Ed North America 2012.

Jay Schmelzer covered the following topics (I also put my opinions about each topic):

  • Web Development versus Sharepoint Development: He stated that on VS2012 what you can do for web development can also be done for SharePoint development. That is really a great achievement for the SharePoint developers.
  • Simplified SharePoint project types: I was really very confusing on VS2010. Why would you create a project for an event handler instead of having a SharePoint and add the event handler to it??
  • Creating SharePoint lists using Visual Studio 2012: That is a cool feature demonstrated by Jay on this video. VS2012 can create the list and support most of the list configurations available. And best of all, no XML involved.
  • Creating Visual Web Parts for Sandboxed Solutions: Now it is part of Visual Studio 2012. If you use Visual Studio 2010, you should use the Visual Studio SharePoint Power Tools.
  • Better integration with the SharePoint Content Database: I didn’t see it much, even though he mentioned it a bunch of times. The only time it really showed knowledge of the content database was when he deployed the list for the second time and VS2012 told him there was a conflict. I was expecting something smarter in the way intellisense works to help you figure out list names, field names, available content types, etc.
  • Using the JavaScript Client Object Model and JQuery: No news here. I was expecting something more from VS2012 on this matter but no
  • Page inspector on IE – Developer Tools (F12): No news here. He just showed what already exists. No VS2012 related feature and by the way, Chrome Developer Tools is much better!
  • Retract is automatic after stopping the debug: That is new and it is also configurable.
  • Deployment config, pre and post deployment steps: All this stuff already exists on VS2010.
  • Less features created on projects: Finally!
  • Manifest file: You can edit it and also have schema completion.
  • Feature dependency: Already existed on VS2010.
  • Deploy to Office 365: Cool feature.


He also talked about 2 interesting topics by the end of the session:

Unit test for SharePoint– fake classes: they are going to provide those classes to allow developers to right unit test for SharePoint solutions in a less painful way than what is out there now.

LightSwitch: rapid business application development tool now integrated with SharePoint lists.


My rating for the session would be 3 out of 5 because no great/new topics were covered in depth on this session and I was expecting more from VS2012.


You can watch other videos from Tech Ed North America 2012 at Channel 9:



See you,


Error Editing Wiki Page – You must specify a value for this required field

We were having the following error editing Wiki pages:

“You must specify a value for this required field”

Actually it is a custom master page issue not hiding correctly some content place holders. We were able to solve it following the directions from this article from Travis Mathison:

“You must specify a value for this required field” error when hidding PlaceHolderPageTitleInTitleArea

See you,