Please note, even though this post is about SharePoint 2007 implementation, very similar technique is applicable to SharePoint 2010 as well, with changes to the content of the master page mostly.

1. Create a minimal masterpage with SharePoint Designer following this MSDN article: How to: Create a Minimal Master Page.

Basically, it all comes down to creating a file in SPD, which we are going to call msminimal.master, under your site’s http://site / _catalog / masterpage (Master Page Gallery). That msminimal.master must contain only essential empty zones, and no client-side markup or server-side controls.

My only changes to the master page from MSDN article would be adding Visible=”false” attribute to Site Actions and Welcome if you would like to hide them in your future web pages:

      <wssuc:Welcome id="explitLogout" runat="server" Visible="false" />
      <PublishingSiteAction:SiteActionMenu runat="server" Visible="false" /> 

2. While in SharePoint Designer, create a new web aspx page and reference your new master page changing MasterPageFile attribute from ~masterurl/default.master to _catalogs/masterpage/msminimal.master.

Here is an example of the simplest web page with just one web part zone:

<%@ Page language="C#" MasterPageFile="_catalogs/masterpage/msminimal.master" Inherits="Microsoft.SharePoint.WebPartPages.WebPartPage,Microsoft.SharePoint,Version=12.0.0.0,Culture=neutral,PublicKeyToken=71e9bce111e9429c" meta:progid="SharePoint.WebPartPage.Document" %>
<%@ Register Tagprefix="SharePoint" Namespace="Microsoft.SharePoint.WebControls" Assembly="Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
<%@ Register Tagprefix="WebPartPages" Namespace="Microsoft.SharePoint.WebPartPages" Assembly="Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
<%@ Import Namespace="Microsoft.SharePoint" %>

<asp:Content ContentPlaceHolderId="PlaceHolderMain" runat="server">
  <WebPartPages:WebPartZone runat="server" FrameType="TitleBarOnly" ID="MainZone">
    <ZoneTemplate>
    </ZoneTemplate>
  </WebPartPages:WebPartZone>
</asp:Content>

3. Now if you want to edit your new custom web page visually in a browser and add web parts, you would need to use one old non-documented trick. Since there is no familiar header or site actions menu, you need to type in your Internet Explorer the following URL, in order to switch between view and edit mode, and back :

javascript:MSOLayout_ToggleLayoutMode();
(Refer to my previous article on highly useful non-documented shortcuts http://artykul8.com/2011/03/useful-sharepoint-shortcuts/)

4. After adding all necessary content to your custom web page, it contains only content and no additional header, footer, etc. This sometimes comes extremely useful if you want to display some specific content in a Page Viewer Web Part on another SharePoint site, or in a frame in another non-SharePoint web application.

Enter page web part maintenance mode

Append ?contents=1 to the URL of the page for which you want to enter maintenance mode, for example:

http://site/page.aspx?contents=1

Enter page edit mode

Including system pages, such as view or edit pages: NewForm.aspx, EditForm.aspx, AllItems.aspx, etc.
In Internet Explorer’s URL bar type:

javascript:MSOLayout_ToggleLayoutMode();
or
javascript:MSOTlPn_ShowToolPane(’2′);

For more details on ShowToolPane parameter, you can refer to this old MSDN article.

Heads up: There is one thing you must seriously consider before editing a system page. This lesson I learnt the hard way from exposing modified edit pages to end-users. When you modify a previously read-only system page, such as a view or edit form, through the shortcut explain above, you make it available for editing to anyone who has contribute rights on that library or list. Hence that page becomes vulnerable to accidental changes by non-power users, because previously hidden Edit Page menu will be visible to them in Site Actions menu.

The reason for this is incorrect assembly reference in manifest.xml, which results in invalid URL for IMembershipCondition element, where binary name has an extra .dll suffix in CAS policy file, just like in the file excerpt below:

C:\Program Files\Common Files\microsoft shared\Web Server Extensions\12\CONFIG\wss_custom_wss_mediumtrust_guid.config

   ...
  <CodeGroup version="1" PermissionSetName="mycustomwebpart.wsp-12345678-90AB-1234-5678-90ABC3456-1">
    <IMembershipCondition version="1" Name="MyCustomWebPart" Url="$AppDirUrl$/bin/MyCustomWebPart.dll.dll" />
  </CodeGroup>


The solution for this problem is relatively simple:

- in your Visual Studio open WSP View pane, click Refresh button to update solution files

- open manifest.xml and in <Assembly> element remove extension ‘.dll’ from Assembly Name attribute:

<Solution ...>
  ...
  <CodeAccessSecurity>
    <PolicyItem xmlns="http://schemas.microsoft.com/sharepoint/">
      ...
      <Assemblies>
        <Assembly Name="MyCustomWebPart" />
      </Assemblies>
    </PolicyItem>
</Solution>


Additionally, while editing manifest.xml if you like to grant your web part additional security privileges you might need to add a few lines to PermissionSet element. In particular, if you are using MOSS Search or Search Server functionality, such as KeywordQuery or FullTextSqlQuery classes you would need RegistryPermission and FileIOPermission lines.

<PermissionSet class="NamedPermissionSet" version="1" Description="Example">
...
<IPermission class="System.Security.Permissions.RegistryPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Unrestricted="true" />
<IPermission class="System.Security.Permissions.EnvironmentPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Unrestricted="true" />
<IPermission class="System.Security.Permissions.ReflectionPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Unrestricted="true" />
<IPermission class="System.Security.Permissions.FileIOPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"version="1" Unrestricted="true" PathDiscovery="*AllFiles*" />
</PermissionSet>


Additional resources:

• MSDN: Administrator and Developer Guide to Code Access Security in SharePoint Server 2007
• MSDN: Solution Schema
• MSDN: Securing Web Parts in Windows SharePoint Services
• BlueDog Limited post: Code Access Security policies within SharePoint v3

Nonetheless, it is important to remember that if you are planning to install SharePoint Server 2007 or Windows SharePoint Services 3.0, it has to be at least SP2, anything before that is not supported on Windows Server 2008 R2. SharePoint Team Blog: Install SharePoint Server 2007 on Windows Server 2008 R2

There was a bit of confusion/frustration raised over this topic, because WSS 3.0 slipstream with SP2 came out long ago (April 2009), but MOSS 2007 was for some reasons left behind, and MSDN subscribers saw slipstream SP2 edition only in January 2010.

WSS 3.0 with SP2:
x86: http://www.microsoft.com/downloads/details.aspx?FamilyId=EF93E453-75F1-45DF-8C6F-4565E8549C2A&displaylang=en
x64: http://www.microsoft.com/downloads/details.aspx?familyid=9FB41E51-CB03-4B47-B89A-396786492CBA&displaylang=en

MOSS 2007 with SP2 (trial):
x86: http://www.microsoft.com/downloads/details.aspx?FamilyID=2e6e5a9c-ebf6-4f7f-8467-f4de6bd6b831&displaylang=en
x64: http://www.microsoft.com/downloads/details.aspx?FamilyID=3015fde4-85f6-4cbc-812d-55701fbfb563&displaylang=en

After eliminating all possible causes – NLB, SharePoint site configuration, IIS security and settings – it turned out that it wasn’t even IIS- or SharePoint-related issue at all. Starting with Windows Server 2003 SP1 and higher (Windows Server 2008 and R2 editions in that list as well), as a security measure Microsoft introduced a loopback check to prevent man-in-the-middle (MITM) attack, when a malicious application (such as spyware) can try to eavesdrop communication with a remote server by introducing itself locally as a remote host. Please note: loopback check happens only when host headers do not match local computer name.

The symptoms and solutions are described in Microsoft KB article: http://support.microsoft.com/kb/896861
Additionally a few other related issues (accessing network shares, etc) are outlined in two more KB articles: http://support.microsoft.com/kb/887993 and http://support.microsoft.com/kb/926642.

To deal with this issue you have two options: either explicitly specify all host headers in the registry (the most secure, but also the most cumbersome solution), or disable loopback check entirely.

If you decide to opt for completely disabling loopback check (on a development or test server), here is one command line you can achieve it through. Please remember to restart your server after changing the registry!

REG ADD HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v DisableLoopbackCheck /t REG_DWORD /d 1

Microsoft SharePoint product team is blowing all bells and whistles, announcing SharePoint 2010, and how important it is to switch to 64-bit environment, while poor SharePoint 2007 left in the dust and crippled with the only development extension working on 64-bit, which is still in CTP phase Visual Studio Extensions 1.3 (March 2009 CTP).

VSeWSS 1.3 was promised almost half a year ago to become a final release in the spring of 2009, and later on in one of the dev blogs mentioned July 2009 release date, but up to this date there hasn’t been any final version announcement or releases yet.

Also, if you are looking for more information and code snippets, you may still find useful referring to the samples that come with Visual Studio Extensions 1.1 for Visual Studio 2005 User Guide, which have been removed from 1.3 release.

I’m keeping my fingers crossed for the new release to come soon, while blaming it all for the recession…