SharePoint 2007 Common Customizations and Recommendations When Upgrading to SharePoint 2010

Because of the downtime issues, in-place upgrades are better suited for small environments. In larger environments, the downtime needed to do an in-place upgrade may be too long. In-place upgrades may also not be suited for environments with significant custom code or other customizations. One of the benefits of an in-place upgrade is that the customizations in SharePoint 2007 are maintained. However, in order for your upgrade to be successful, your custom code must run in both SharePoint 2007 and SharePoint 2010.

Table below provides list of common customizations in SharePoint 2007 and recommendations on how to deal with them when upgrading to SharePoint 2010:

Customization	Good Choice	Better Choice
Custom Web Parts	Probably work out of the box with SharePoint 2010	Test on sample server, plan to rewrite for SharePoint 2010
Custom event handlers	Probably work out of the box with SharePoint 2010	Test on sample server, plan to rewrite for SharePoint 2010
Custom Site template	Create a site with the Custom Site template before upgrade	Recreate in SharePoint 2010, preferably as a Solution package and Feature
Custom site definition	Create UDF file for upgrade	Migrate to an out-of-the-box site template and deploy customizations as a Solution package and Feature
Customized (unghosted) pages	Reset to site definition	Reset to site definition, and reapply customizations
Custom code or pages in /_layouts	Probably work out of the box with SharePoint 2010	Test on sample server, plan to rewrite for SharePoint 2010

Hiding the Name.dll ActiveX Control

If you are working on a public-facing Internet site, you should be aware that SharePoint may show a particularly annoying message at the top of Internet Explorer like shown below (This website wants to run the following add-on: ‘Name ActiveX Control’ from ‘Microsoft Corporation’: If you trust the website and the add-on and want to allow it to run, click here…)

The message asks the user to run the Name.dll ActiveX Control add-on because the users don’t the SharePoint Server added to their trusted sites list. This control enables presence information to be displayed for authenticated users in SharePoint, and typically shows their availability in external Instant Messaging programs from inside SharePoint. Since anonymous users don’t really need this functionality you can turn off this message by using one of the following method:

• In SharePoint 2010 the message can be turned off from Central Administration –> Manage Web Applications –> General Settings. Simply set Enable the Person Names Smart Tag and Online Status for Members to No. This will turn off the presence information and remove the ActiveX message for the entire web application.
• Alternatively you can you can disable the message and functionality from a custom master page. Simply add the following code to your master page:

<script type=”text/javascript”>
    function ProcessImn(){}
    function ProcessImnMarkers(){}
</script>

This JavaScript code overrides the functions in SharePoint that cause this ActiveX message.

How To Turn Off Master Pages Applying to Application Pages

You may not want your custom branding to apply to the application pages, normally the way I do this is by not applying custom master page to SharePoint 2010 as the System Master Page. But wait, although this method prevents the application pages from showing the custom branding, but it also prevents the branding from showing on any nonpublising page too :(

I found a better way to do this that is by stop master pages from applying to application pages by turning off the feature completely from Central Administration, as follows:

• Open Central Administration on the SharePoint server.
• Under Application Management, click Manage web applications.
• Select the desired web application from the list, and then from the ribbon, click General Settings.
• In the dialog that appears, scroll down to Master Page Setting for Application _Layouts Pages and select No.
• Scroll to the bottom of the dialog and click OK.

Now custom master pages for this entire web application will not apply to the application pages.

Delete a Corrupted List Using STSADM

If you have a list that might appear to be in a corrupted state, when you try to delete it using SharePoint Web UI you will get the following error message:

Invalid file name.
The file name you specified could not be used.  It may be the name of an existing file or directory, or you may not have permission to access the file.<nativehr>0x81020030</nativehr><nativestack></nativestack>

Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: System.Runtime.InteropServices.COMException: Invalid file name.
The file name you specified could not be used.  It may be the name of an existing file or directory, or you may not have permission to access the file.<nativehr>0x81020030</nativehr><nativestack></nativestack>

Source Error: An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.

By using STSADM operation’s forcedeletelist, you can delete the corrupted list, here is the syntax:

stsadm -o forcedeletelist -url <URL>

Example:

stsadm –o forcedeletelist –url http://sharepointserver/lists/yourcorruptedlist

Site Settings Display A Blank Page

When you use standard hostname given to the address of the loopback network interface, “localhost”, as URL to access the SharePoint Site Settings page of any sub sites for example: http://localhost/subsite1/_layouts/settings.aspx, a blank page will be displayed and the following entries will be logged in the SharePoint ULS:

• 01/29/2011 18:43:04.10 | w3wp.exe | (0x1CB4) | 0x1DDC | SharePoint Foundation | Logging Correlation Data | Name=Request (GET:http://<<SERVERNAME>>:80/<<SUBSITE>>/_layouts/settings.aspx)
• 01/29/2011 18:43:04.11 | w3wp.exe | (0x1CB4) | 0x1DDC | SharePoint Foundation | Monitoring | Leaving Monitored Scope (Request (GET:http://<<SERVERNAME>>:80/<<SUBSITE>>/_layouts/settings.aspx)). Execution Time=1.96949915988322
• 01/29/2011 18:43:04.11 | w3wp.exe | (0x1CB4) | 0x1F24 | SharePoint Foundation | Configuration | Alternate access mappings have not been configured.  Users or services are accessing the site http://<<SERVERNAME>> with the URL http://localhost.  This may cause incorrect links to be stored or returned to users.  If this is expected, add the URL http://localhost as an AAM response URL.  For more information, see: http://go.microsoft.com/fwlink/?LinkId=114854"/>    

To fix this issue, all you need to do is to configure Alternate Access Mappings (AAM) by adding internal URLs “http://localhost” to the default zone as shown in screenshot below: