Archive for the ‘SharePoint 2010 Foundation’ Category

Fixing User Cannot Be Found in SharePoint 2010 Workflow Settings

May 21, 2013

We started getting this error overnight on our SharePoint 2010 farm. Workflows stopped working, we couldn’t republish list workflows, and we couldn’t access the Workflow Settings page for any list or library on the entire site collection. The following error would appear:

User Cannot Be Found

Opening SharePoint Designer at the site collection level, we discovered that the Globally Reusable Workflows and Reusable Workflows were owned by user accounts that had been deleted. In order to fix this we used SharePoint Designer to open every workflow and clicked Publish with a static user account (i.e. the Farm service account or App pool service account). After republishing, all started working again.



SharePoint 2010 Content Deployment – System.NullReferenceException: Object reference not set to an instance of an object

November 8, 2011

Content deployment in SharePoint 2010 works fantastically well. Once it is working. Getting to the ‘working’ stage however is a path that can cause a lot of pain, not the least of which is getting a generic error!
My configuration for our SharePoint publishing farm is as follows:

  1. SharePoint central admin site (PUB01)
  2. 2 x SharePoint web front-ends serving content (WFE01 and WFE02)
  3. Radware load balance (LOAD01)

I’m mentioning these items because they impacted how my content deployment was not working, and also the resolution required.

What You Absolutely Need To Have

There is ample documentation on setting up Content Deployment, but from a high level you must have the following in place:

  1. Your source Central Admin website must be able to access the destination Central Admin website, including setting the destination CA to accept content deployment. This includes the IP address and port of course!
  2. The account you use to deploy content on the destination server must have the appropriate permissions
  3. Your source and destination farms must be the same SharePoint version (right down to the Cumulate Update if applicable!)
  4. The destination CA must have enough room to store the content in a temporary location (check hard drive space on the destination server that hosts the Central Admin site)
  5. The destination CA must have the Microsoft SharePoint Foundation Web Application service “Started” on the server (destination CA uses this to check IIS configuration – more on this later)

Content Deployment Process

Content deployment goes through several high-level stages when it deploys content:

  1. The Source CA packages up the content into one or more CAB files
  2. The Source CA pushes the CAB files to the Destination CA, which stores them in a temporary location
  3. The Destination CA validates the IIS site and destination site collection
  4. The Destination CA unpacks the cab files and individually pushes the content into the destination site collection

The import log file shows the results of the attempted import and will display any warnings or errors that occurred.

System.NullReferenceException: Object reference not set to an instance of an object

In my environment, this error occurs very quickly after the data has been transferred to the destination farm. I dialed up the ULS diagnostic monitoring by editing the Monitoring, “Configure diagnostic logging”, “Category – Web Content Management/Content Deployment” setting to Verbose. Your ULS log file will then show much more detail about the process, including whether the CAB content files are being copied up properly from the source to the destination CA. Look for entries such as:

Upload file 'C:\SPDeploy\1c8b92e5-975c-4d30-b38e-04c25975e2bb\' succeeded

The “System.NullReferenceException” error occurs very soon after the final CAB file has been deployed.

The thing that tripped me up was the load-balanced url I had set up in the Radware load-balancer and DNS settings. My destination URL DNS entry was pointing to the load-balancer virtual IP address, which then load-balanced requests to my two web front-end servers. My suspicion is that the destination Central Admin content deployment process checks IIS to see if it is configured correctly, and because it is traveling via a virtual IP address it doesn’t resolve to a local IIS metabase entry. In the ULS logs I saw entries such as:

Saving CachingSettings for SiteUrl 'http://your.sharepoint.url/'

immediately followed by the dreaded:

Failed import operation for Content Deployment job 'Remote import job for job with sourceID = 409e7be7-7694-496d-8469-eb472e5070f6'. Exception was: 'System.NullReferenceException: Object reference not set to an instance of an object.
at Microsoft.SharePoint.SPSite.PreinitializeServer(SPRequest request)
at Microsoft.SharePoint.SPWeb.InitializeSPRequest()
at Microsoft.SharePoint.SPWeb.get_AllProperties()
at Microsoft.SharePoint.Publishing.SiteCacheSettings..ctor(SPSite site)
at Microsoft.SharePoint.Publishing.SiteCacheSettingsWriter..ctor(SPSite site)
at Microsoft.SharePoint.Publishing.SiteCacheSettingsWriter.SaveCacheSettingsBeforeImport(String importSiteUrl)
at Microsoft.SharePoint.Publishing.Administration.ContentDeploymentJob.DoImport()'

I checked the “PreInitializeServer” code using ILSpy (an improved, and more importantly free, replacement for Reflector), which wasn’t doing anything particularly complex but does use the SPRequest object. My thinking at this point was that the CA was unable to connect to IIS – it possibly does an IIS metabase lookup to get configuration settings, and because it was being bounced to the load-balancer and then down to the web front-ends, this step was failing. This occurs immediately after the cab files have been uploaded to the destination server.

The fix I put in was to edit the “hosts.” file (C:\Windows\System32\Drivers\etc\hosts.) and add an entry for the CA destination server IP address against the URL I was publishing to. This forces the destination CA to use the local server instead of trying to go via the load-balancer. This won’t affect the content being served, the web front-ends are configured via the load-balancer, and the destination CA doesn’t actually participate in this process. If your destination CA is also a web front-end, this would also still work as the URL resolves properly anyway.

After I set up my hosts file and re-ran the content deployment, it all worked perfectly! At least, on this occasion 🙂

A second “fix” I have had to use is to create another host-header site collection on my destination CA. I didn’t need to use this new site collection – I just created a blank one (see powershell script below). I’m not sure what happens in the background, but when I next tried my content deployment, it immediately changed from FAILED to SUCCESS. It’s possible that the act of creating another site collection resets Something(tm) so that content deployment can connect correctly.

Additional Content Deployment Troubleshooting Tips

While trying to diagnose the problem I also came up against the following issues (in no particular order):

  1. When creating a destination site collection, do not add a template to the site. In essence, you are creating an empty site collection, not a site collection with the blank or blank internet template. This breaks content deployment. I use the following Powershell script to auto-create a host-header (multi-tenancy) site collection:
    $contentDbName = “Your.Database.Name”
    $webName = “Your web app name”
    $url = “http://your.url”
    # Get the web application
    $webApp = Get-SPWebApplication –Identity $webName
    # Create content database
    New-SPContentDatabase –Name $contentDbName -WebApplication $webApp
    # Create the site
    $contentDb = Get-SPContentDatabase –Identity $contentDbName
    New-SPSite –Url $url –OwnerAlias “DOMAIN\gavin.mckay” –OwnerEmail “gavin.mckay@domain.local” –ContentDatabase $contentDb –HostHeaderWebApplication $webApp

    The important point here is not to use the “-Template <template name>” parameter in New-SPSite. This will break content deployment and you will get a stack of errors about being unable to overwrite content. Deployment failure!

  2. If you recreate your site collection, you will need to delete your content deployment job and path from the source CA server. The destination site collection id is stored as part of the job/path, and if you recreate your destination site collection it will have a new id. Deployment failure!
  3. If you delete your content database and recreate it, you will have to do an IISRESET on your CA and web front-ends to get them to resolve properly. You will recognise this by trying to connect to the destination URL and getting the following in your browser:
    “HTTP/1.1 200 OK Server: Microsoft-IIS/7.5 Date: Tue, 08 Nov 2011 02:41:04 GMT Connection: close”
    SharePoint is confused. Deployment failure!
  4. If you have Office Web Apps enabled on your source site collection, but not on the destination site collection, you will get:’Microsoft.SharePoint.SPException’ : ‘Could not find Feature MobilePowerPointViewer.’
    Deployment failure! Use Site settings, Site collection features, to disable Office Web Apps in the source site collection, then start your deployment job again.
  5. “The exception thrown was ‘Microsoft.SharePoint.SPException’ : ‘Unable to import the folder _catalogs/fpdatasources. There is already an object with the Id <Guid> in the database from another site collection.'”
    Deployment failure! This seems to occur if you have previously had a failed content deployment for a new site collection/content database.
    Using your destination CA remove the content database then re-add it again. This will restore the previous empty site collection ready for content deployment.
  6. Warning “A minor version has been exported with no corresponding major version. It is possible that this item was unpublished then published again. If this item is meant to be published, publish a new version and export/import it again”
    This is reasonably straight-forward. Either indivudally (or via a batch job) publish a major version, or turn off major/minor version control for the list/library.
  7. Warning “Cannot revert to the site definition version of this file”
    Currently unknown how to fix this…
  8. Error “A file with the name [filename] already exists”
    Currently unknown how to fix this…

More Detail – What Happens in the Database

The Content Deployment jobs are stored in the source farm SharePoint_Config database. You can view the details in a SQL query via:

Select top 100








FROM [dbo].[Objects]

WHERE Properties like ‘%ContentDeploymentJobDefinition%’

The Properties field is an XML data string that defines the job information.

More Detail – What Happens in ULS

You can view more detail via ULS logging if you enable Verbose logging for the category “Web Content Management” / “Content Deploymet”. Using the ULS Log Viewer will then enable you to see more detail on the process.

After the SharePoint source server packages the deployment files into multiple .cab files, they are individually pushed across to the destination farm. Yo should see ULS entries similar to:

Name=Request (POST:http://destination.sharepoint.local:8080/_admin/Content%20Deployment/DeploymentUpload.aspx?


After all the CAB files have been pushed across, the source server creates a deployment job on the destination server

SharePoint 2010 Web Services 401 Unauthorised Error from InfoPath Forms Services

March 29, 2011

This is an intermittent error that kept appearing when we deployed an InfoPath form that used the GetUserProfileByName method in order to retrieve default profile information of the current user. It’s an amazingly useful function that instantly personalises the form itself and means users don’t have to retype information into a form that SharePoint should just “know”.

The error viewed in the SharePoint logs was:
Data adapter failed during OnLoad: The remote server returned an error: (401) Unauthorized.

The following query failed: GetUserProfileByName (User: , Form Name: , … Type: DataAdapterException, Exception Message: The remote server returned an error: (401) Unauthorized. The remote server returned an error: (401) Unauthorized.)

Our setup is a two-node web-front-end SharePoint environment and we are using DNS round-robin load-balancing (I know it’s not “real” load-balancing but our hardware load balancers aren’t installed yet!). The point being that we have two web servers.

This issue occurs because of double-hop authentication. If you have two servers in your load-balancer and requests are not homed to the same server (i.e. instead of server1 requesting a web service from itself, it contacts server2 instead) then it is unable to pass your user credentials on to the other server. If you force the server to talk to “itself”, then it is able to use your credentials successfully and return the results from the web service.

The obvious solution is to fix load-balancing, but a workaround is to use the hosts file located at (NOTE no file extension on this file!):


and add an entry on each server pointing to itself. For example, if you have two web servers, Server1 on and Server2 on your host file entry on Server1 would be: your.sharepoint.address

and on Server2: your.sharepoint.address

When each server makes a request to your.sharepoint.address, it will use the hosts file entry *first*, and always visit the correct IP address.

WARNING: Using the hosts. file in this way is supported by Microsoft, but can create issues for maintenance. Consider the case where you need to change the IP address for your server(s). You would need to ensure that the hosts file is also update to reflect the changes.

HOWTO Start the SharePoint 2010 Central Administration Service with PowerShell

February 2, 2011

I have two web front-ends in my SharePoint 2010 farm with Central Administration running on one of the front-ends. I was having some serious performance problems on the Central Admin-enabled server and wanted to start Central Admin on my other server. The Central Admin service is installed on all web front-ends by default, but is only enabled and started on machines you select.

The following PowerShell command will provide a list of all servers that have the Central Administration service installed, their status, and the Id (GUIDs have been changed ;):

Get-SPServiceInstance | Where-Object {$_.TypeName -eq 'Central Administration'}

TypeName Status Id
——– —— —
Central Administration Disabled 5E1FEB60-87FB-4CDB-9E2E-B8607F003C90
Central Administration Online 390085E6-009F-44E5-B6F7-8FD46CCB103F

I can now focus on just the web front-end with the Disabled Central Administration service by using the Id with the following:

Get-SPServiceInstance | Where-Object {$_.Id -eq '5E1FEB60-87FB-4CDB-9E2E-B8607F003C90'}

The service instance can be started using the following PowerShell command, again restricted to the Id of the service instance I want:

Get-SPServiceInstance | Where-Object {$_.Id -eq '5E1FEB60-87FB-4CDB-9E2E-B8607F003C90'} | Start-SPServiceInstance

This will start provisioning the service instance (note the Status below says “Provi…”), which usually means creating the Central Administration website on the web front-end and starting the central admin service instance:

TypeName Status Id
——– —— —
Central Administration Provi… 5E1FEB60-87FB-4CDB-9E2E-B8607F003C90

You can check the progress by continually entering the previous powershell command:

Get-SPServiceInstance | Where-Object {$_.Id -eq '5E1FEB60-87FB-4CDB-9E2E-B8607F003C90'}

until you hopefully get the status as Online:

TypeName Status Id
——– —— —
Central Administration Online 5E1FEB60-87FB-4CDB-9E2E-B8607F003C90

Create Sites in SharePoint 2010 Fails

July 27, 2010

This was a hang-over from a sharepoint upgrade performed at a client site.

Each time the client tried to create a new site (i.e. sub-web) they would get hit with a correlation id and site creation failure, and the diagnostic log entries were:

07/27/2010 20:46:25.20 w3wp.exe (0x1364) 0x0590 SharePoint Foundation Runtime tkau Unexpected System.NullReferenceException: Object reference not set to an instance of an object. at Microsoft.SharePoint.Workflow.SPContentTypeWorkflowAssociationCollection.PushDownAssociation(SPWorkflowAssociation associationTemplate, Boolean bUpdateIfExisting, MethodBase mbChangeEntry) at Microsoft.SharePoint.Workflow.SPContentTypeWorkflowAssociationCollection.CopyWorkflowAssociation(SPWorkflowAssociation associationTemplate) at Microsoft.SharePoint.SPContentType.CopyWorkflowAssociationsTo(SPContentType ctDst) at Microsoft.SharePoint.SPContentType.SyncNewList(SPList list) at Microsoft.SharePoint.SPWeb.SyncNewLists() at Microsoft.SharePoint.SPWeb.ApplyWebTemplate(String strWebTemplate) at Microsoft.SharePoint.ApplicationPages.TemplatePickerUtil.ApplyWebTemplateAndRedirect(S… 2d8cade4-075d-4327-9124-353123d11350
07/27/2010 20:46:25.20* w3wp.exe (0x1364) 0x0590 SharePoint Foundation Runtime tkau Unexpected …PWeb Web, String strWebTemplate, Nullable`1 bSharedNav, Boolean bOnTopNav, Boolean bOnQuickLaunch, Page page, Boolean bDeleteOnError) at Microsoft.SharePoint.ApplicationPages.NewSubwebPage.BtnCreateSubweb_Click(Object sender, EventArgs e) at System.Web.UI.WebControls.Button.OnClick(EventArgs e) at System.Web.UI.WebControls.Button.RaisePostBackEvent(String eventArgument) at System.Web.UI.Page.RaisePostBackEvent(IPostBackEventHandler sourceControl, String eventArgument) at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) 2d8cade4-075d-4327-9124-353123d11350

There were two workflows attached to the Document content type that had not been migrated during the sharepoint upgrade from WSS to SharePoint Foundation 2010. These were now missing from the site collection, even though they were recorded against the content type. So when SharePoint 2010 created the site, it couldn’t apply the workflows to the files (such as default.aspx) within the site. This caused the creation to fail and SharePoint backed out and deleted the site it had just created.

They were no longer needed, so were removed from the site via:

  1. Site Actions, Site Settings (top-level)
  2. In the Galleries section, select Site content types
  3. Select your content type (in my case it was the Document content type)
  4. Select Workflow settings
  5. Select Remove workflows and click OK

This removed the association of the invalid workflows from the content type, and users could then create sites correctly.

HOWTO Fix SharePoint 2010 Event Log Error 7043 TaxonomyPicker.ascx

July 20, 2010

UPDATED 2010-12-18: After some further Internet sleuthing it appears that the control “TaxonomyPicker.ascx” isn’t actually required – it was left in accidentally from release. When SharePoint websites start they automatically compile and cache controls in the “/_controltemplates” folder (default location is C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\CONTROLTEMPLATES), which includes the TaxonomyPicker.ascx control. The controls are checked against the SharePoint DLLs (Microsoft.SharePoint.Portal in particular), and thus the error that is raised is actually because the control entry does not exist in the SharePoint DLLs. Hence the event log is actually saying “I have an .ascx file that does not have a matching entry in the SharePoint DLLs”.

The (rather dramatic) fix is to rename (or deleted, though that is more drastic!) the taxonomypicker.ascx file to taxonomypicker.ascx.old (or something else relevant) so that SharePoint does not automatically try and load the file. Perform this task in a test environment first! Future service packs or hotfixes may fix this issue, but also it is likely that TaxonomyPicker.ascx could be automatically re-added as part of maintenance by a SharePoint hotfix/service pack, so you may need to repeat this process again at a later date if it isn’t fixed.

ORIGINAL POST: With thanks to Xiaofeng Wang (MVP) in this post, the event log error details are: “Load control template file /_controltemplates/TaxonomyPicker.ascx failed: Could not load type ‘Microsoft.SharePoint.Portal.WebControls.TaxonomyPicker’ from assembly ‘Microsoft.SharePoint.Portal, Version=, Culture=neutral, PublicKeyToken=71e9bce111e9429c’.”
This is due to a bug in the ASP.NET control file definition within SharePoint 2010.
To fix this issue:

  1. Go to :\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\CONTROLTEMPLATES
  2. Open TaxonomyPicker.ascx in any text editor (such as Notepad)
  3. Locate the following line :
    <%@ Control className=”TaxonomyPickerControl” Inherits=”Microsoft.SharePoint.Portal.WebControls.TaxonomyPicker,Microsoft.SharePoint.Portal, Version=, Culture=neutral, PublicKeyToken=71e9bce111e9429c” %>
  4. Replace ‘,’ with a comma i.e. ‘,’ , the correct line should look like:
    <%@ Control className=”TaxonomyPickerControl” Inherits=”Microsoft.SharePoint.Portal.WebControls.TaxonomyPicker,  Microsoft.SharePoint.Portal, Version=, Culture=neutral, PublicKeyToken=71e9bce111e9429c” %>
  5. Save the file

HOWTO Stop a SharePoint 2010 Service Application Stuck in Starting

July 19, 2010

SharePoint 2010 service applications that gets stuck in the “Starting” state sometimes can’t be fixed by an IISReset or reboot. In these cases try the following:

1. Get the service application identity with the powershell command:
2. Force the service application to stop by using the powershell command:
Stop-SPServiceInstance -Identity “SERVICE ID GUID”
3. When prompted, enter “y” for [Y] Yes to stop the service

You can use Start-SPServiceInstance to start service applications as well.

HOWTO: Start a SharePoint 2010 Workflow Programatically

July 15, 2010

UPDATE – 26-Aug-2011

I just noted this on the Microsoft SharePoint Development Blog which, while not solving the problem, might be a different way to tackle it:

Calling SharePoint workflow instances programmatically from other SharePoint workflows



I needed to automate some workflow creation from a Windows client application, and there is a web service available for this purpose. First introduced in SharePoint 2007 (*not* in WSS 3.0!), the workflow.asmx web service allows you to programatically start a workflow.

Starting a Workflow Programatically (C#)

SharePoint 2010 includes a number of out-of-the-box workflows, but you can also use SharePoint Designer 2010 or Visual Studio .NET 2008/2010 (for Windows Workflow Foundation) to create your own customised workflows. In this example I will use SharePoint Designer 2010.

The following is required to start the workflow:
1. The Uri for the list item (or page) you want to start the workflow on; and
2. the Template Id for the workflow
and optionally:
3. The xml workflow initiation data (see below)

The Uri should be simple to get, but the Template Id isn’t as easy. If you use SharePoint Designer 2010, there doesn’t appear to be any way to retrieve the Template Id. So you either have to get it via code, or as a quick work-around use the SharePoint site itself. You can get the Template Id via:
1. Go to the list/library that the workflow is attached to (ASSUMPTION: you are using a workflow that applies to a list item/page)
2. Hilight an item in the list
3. In the Ribbon, Library Tools, Documents tab, click “Workflows”
4. In the “Start a New Workflow” section, right-click on the url that has the name of your workflow and select “Copy Shortcut”
5. Look at the Url and extract the Guid from the TemplateId parameter. For example, in this url:


the Template Id can be found in: “TemplateID={aed94889-39bc-4eb9-997b-302d0f55c645}”.
6. Copy the Guid for later use

You are now ready to start your workflow.

In Visual Studio 2008/2010:
1. Create a new project (i.e. win-forms or command-line)
2. Add a reference to the workflow.asmx web service (http://mysharepointsite/_vti_bin/workflow.asmx). NOTE: when adding a reference, I had difficulties adding a service reference, so you may need to use the “old-school” approach and add a web reference instead. You can do this by right-clicking on the project and selecting “Add Web Reference…”.
3. Add the following code (WSWorkflow is the name of my web reference class):

// Use workflow web service (old-style)
string _itemUri = "http://mysharepointsite/TestDocs/MyDocument.docx";

Guid workflowTemplateGuid = new Guid("{YOUR-GUID-GOES-HERE}");
WSWorkflow.Workflow workflow = new WSWorkflow.Workflow();

workflow.Credentials = System.Net.CredentialCache.DefaultCredentials;
workflow.StartWorkflow(_itemUri, workflowTemplateGuid, null);

This should start your workflow.

Providing Workflow Initiation Data

SharePoint workflows allow you to create parameters and provide initiation data. When you create a workflow in SharePoint Designer 2010 and publish the workflow, it automatically creates an Infopath form to hold Association and/or Initiation Data (even if your workflow doesn’t have any!).

SharePoint Designer - InfoPath Form

SharePoint Designer - InfoPath form created when the workflow is published

When you add initiation form parameters to your workflow, these are automatically added to your Infopath form. You can click on your Infopath form to see the form and make changes directly within the Infopath designer. Also, the Infopath designer will display the schema for your Infopath form, which is essential to provide Initiation form data to your workflow.

Initiation form parameters in SharePoint Designer 2010

InfoPath 2010 - Data schema for our workflow initiation form

The data schema can then be used to submit initiation form data to our workflow programatically. By changing our workflow call and generating an xml-friendly schema, we can start the workflow with our data.

// Create our xml the old-fashioned way!
string xmlInit =
“<dfs:myFields xmlns:xsd=”; xmlns:dms=”; xmlns:dfs=”; xmlns:q=”; xmlns:d=”; xmlns:ma=”; xmlns:pc=”; xmlns:xsi=””><dfs:queryFields /><dfs:dataFields><d:SharePointListItem_RW><d:myname>Gavin McKay</d:myname></d:SharePointListItem_RW></dfs:dataFields></dfs:myFields>”;

XmlDocument xmlDoc = new XmlDocument();

// Use workflow web service (old-style)
string _itemUri = “http://mysharepointsite/TestDocs/MyDocument.docx&#8221;;
Guid workflowTemplateGuid = new Guid("{YOUR-GUID-GOES-HERE}");
WSWorkflow.Workflow workflow = new WSWorkflow.Workflow();

workflow.Credentials = System.Net.CredentialCache.DefaultCredentials;
workflow.StartWorkflow(_itemUri, workflowTemplateGuid, xmlDoc.DocumentElement); // Pass your xml in here

You can review the results of your workflow from within SharePoint.

Final Notes
There are better ways to submit the Xml data (such as by a class that can be serialized into the initiation form format), and plenty of debugging capabilities both within SharePoint (log files and workflow status) and via SharePoint Designer (adding log history actions to your workflow to record initiation form data). But hopefully that is a good start!

Guid workflowTemplateGuid = new Guid(“{aed94889-39bc-4eb9-997b-302d0f55c645}”);

HOWTO: Add Alternate Access Mappings for SharePoint 2010 Internet and Extranet

June 1, 2010

One of my clients has just upgraded to SharePoint Search Server 2010 Express and has new server and network configuration. We are using an extended web application in SharePoint 2010 to enable Extranet usage. The external url is and internally http://companyweb. However the SSL cert stops at the firewall (ISA) and is then passed on as (i.e. http instead of https).

Links that are being returned were incorrect in my search application – http instead of https. I needed to add an alternate access mapping to point http requests and return them as https, but the Web Admin didn’t seem to want me to do that… I could only enter https OR http as my internal and external public addresses. Not what I wanted.

SharePoint 2010 power shell has a cmdlet called “New-SPAlternateUrl”. You can use “Get-SPAlternateURL” to list current ones. I ran the following commands:

1. New-SPAlternateURL -Url http://companyweb -Zone “Default”
this created my default internal zone.

2. New-SPAlternateURL -Url -Zone “Internet”
This created my external internet zone

3. New-SPAlternateURL -Url -Zone “Internet” -internal
This created my internal facing url.

Using this setup SharePoint 2010 now maps external requests for https://* to http://*, and then returns them as https://* for search results.


HOWTO: Install the Adobe PDF IFilter 64-bit on SharePoint 2010

May 25, 2010

I have recently started some site upgrades/migration from SharePoint 2007 to SharePoint 2010, and as with most organisations their content includes PDF files that need to be indexed.

Adobe offer a free 64-bit version of the PDF IFilter at:

The instructions to install and index PDF content is pretty much the same as with SharePoint 2007 (such as this blog post by Harold van de Kamp), however some things are easier with SharePoint 2010. So let’s go through the steps.

1. Download the Adobe 64-bit PDF iFilter v9.0 and install

2. Download the Adobe PDF 17×17 icon and save it to the folder <drive>:\Program Files\Common Files\Microsoft Shared\web server extensions\14\Template\Images\ICPDF.GIF

3. Edit the doc icon xml file located in <drive>:\Program Files\Common Files\Microsoft Shared\web server extensions\14\Template\XML\DOCICON.xml and add a mapping entry:

        <Mapping Key=”pdf” Value=”icpdf.gif”/>

4. Add the PDF extension as a content to be indexed. In Central Administration, General Application Settings, Farm Search Administration, <your search service application>, select “File Types” in the left-hand menu under the Crawling section

5. Click “New File Type” and enter “pdf”, then click OK. The file type displayed on my system says it is a “AcroExch.Document”. Note there is no image at this stage associated with the file – SharePoint needs to be reset before it will display, as the docicons file is cached.

NOTE: You now have two options, depending on your environment. If you want all existing and future PDF files to be searched, you need to perform a full crawl. If you only want future PDF files to be searched, you don’t need to perform a full crawl. For this blog entry, I am assuming a full crawl is necessary and the PDF icon needs to be displayed, so an IISRESET is required.

6. Reset IIS – from an Admin command prompt run the following command:

run “iisreset /noforce”

7. Reset the search service – run the following commands:

net stop “sharepoint server search 14”

net start “sharepoint server search 14”

8. Check your image installation – navigating to your File Types should now show the PDF icon next to the file type “pdf”

9. *if necessary* run a full crawl on your content source(s). The “if necessary” part depends on your search status. I stopped a crawl that was running and this sets a flag that invalidates the current search index. By stopping and starting the search service, it automatically started a full crawl.


Are there any alternatives to the Adobe PDF IFilter?

Yes, the best alternative (including 3x faster indexing that any other PDF iFilter) is the Foxit PDF IFilter 2.0. However this one isn’t free for server installations. But if you are after performance for your indexer, that’s the one to get.