André Krijnen

Sometimes you it’s easy to script some stuff, and you redo some stuff. For example: You want to manually script your export-import action in SharePoint automatically.

Something you need by importing the site is the webtemplate before you can start the import. So, what you can do before deleting the site is to extract the WebTemplateId. The WebTemplate in $web.Url is not sufficient, because it doesn’t translate the correct Configuration.

So, what I’ve did is to use the WebTemplateId and get the according WebTemplate Name. And use it to create a SPSite.

function Get-SPWebTemplateNameBySPWebTemplateId($WebTemplateId)
{
    $templates = Get-SPWebTemplate | Sort-Object "Name"
    $templateValues | ForEach-Object {
        if($_.ID -eq $WebTemplateId)
            $templateName = $_.Name
            return;
    }
    return $templateName
}

$templateName = Get-SPWebTemplateNameBySPWebTemplateId -WebTemplateId 53

Write-Host = $templateName

Above will return BLANKINTERNET#2

There is nothing as worse as a Content By Query Web Part that you can’t use when you want to fix it against a List which will be made automatically for example.

I would like to create a Team Site based on a Custom Web template with an extra sub-site with blogging functionality. This blogging functionality is used for exposing news of the Team or Department.

But when using the functionality like

<Property name=”WebUrl” type=”string”>~site/News</Property>

and using the property

<Property name=”ListName” type=”string”>Posts</Property>

and you removed the value of the property

<Property name=”ListGuid” type=”string”></Property>

it won’t render the CQWP web part by default. The reason is that the ListGuid is needed to render the Web Part.

But also an issue is that, when your list is created it has a changed ListGuid. The ListGuid is never the same when you create a new List.

So basically I created the follow code which will fix that issue.

using System;
using System.ComponentModel;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using Microsoft.SharePoint;
using Microsoft.SharePoint.WebControls;
using Microsoft.SharePoint.Publishing;
using Microsoft.SharePoint.Publishing.WebControls;

namespace AK.Custom.CQWP 
{
    [ToolboxItemAttribute(false)]
    public class AKCQWP : ContentByQueryWebPart
    {        

        protected override void  OnLoad(EventArgs e)
        {
 	        if(!string.IsNullOrEmpty(this.WebUrl) && 
                !string.IsNullOrEmpty(this.ListName) && 
                string.IsNullOrEmpty(this.ListGuid))
            {
                SPWeb webRoot = SPContext.Current.Site.OpenWeb();
                if (this.WebUrl.StartsWith("~site"))
                {
                    this.WebUrl = this.WebUrl.Replace("~site", "");
                    using(SPWeb web = SPContext.Current.Site.OpenWeb(webRoot.ServerRelativeUrl 
+ this.WebUrl, true))
                    {
                        SPList list = web.Lists[this.ListName];
                        this.ListGuid = list.ID.ToString();
                        //this.ListUrl = webRoot.ServerRelativeUrl + this.WebUrl;
                        this.WebUrl = webRoot.ServerRelativeUrl + this.WebUrl;
                    };
                    
                }
                else if(this.WebUrl.StartsWith("/News"))
                    return;
                else
                {
                    using(SPWeb web = SPContext.Current.Site.OpenWeb(this.WebUrl, true))
                    {
                        SPList list = web.Lists[this.ListName];
                        this.ListGuid = list.ID.ToString();
                        this.WebUrl = this.WebUrl;
                    };
                }
                
            }
            base.OnLoad(e);

            
        }

        protected override void OnInit(EventArgs e)
        {
            base.OnInit(e);
        }

        protected override void CreateChildControls()
        {
            base.CreateChildControls();
        }
    }
}

When you have created this part of your solution ensure that you Export the standard CQWP and edit it like you want to. First of all, what you need is to ensure that it takes your assembly instead of the default CQWP assembly.

    <metaData>
      <type name="AK.Custom.CQWP.AKCQWP, $SharePoint.Project.AssemblyFullName$" />
      <importErrorMessage>$Resources:core,ImportErrorMessage;</importErrorMessage>
    </metaData>

Change the properties as following:

<Property name=”WebUrl” type=”string”>~site/News</Property>
<Property name=”ListName” type=”string”>Posts</Property>
<Property name=”ListGuid” type=”string”></Property>

A quick blog about the ‘Localized resource for token ‘direction’ could not be found with path ‘feature path’ is an issue when you have generated a List Definition. When you deploy a list definition in a feature without a Default Core Resource file you will run against this message. It seems to be introduced by the 2010 December update, and it also seems to be solved by the SP1 of 2011 June Refresh update, but I can’t say for sure.

I have installed some language packs on my dev machine, and it does work without any problems, but the environment I want to deploy to seems to have this issue for one reason or another.

So I started out today debugging some weird issues regarding feature deployment. And well sometimes I don’t know why I get errors, but what’s new. So first of all, let’s start where to start.

cannot complete this action.please try again

Starting point:

A colleague of mine had written a feature for a customer of us, which worked perfectly. The customer had never issues like it should. After almost a year we (me, and the customer) decided to change the full Site Templates. Like a developer should do is making and changing the solution work. Well then comes the burden. After days of work, testing everything out the solution worked by me. (Owwh yeah, the known starting point: well on my computer it works).

So after deployment at the production server it didn’t work. I didn’t knew why, because everything should work like my notebook. The reason is simple, I had the same configuration, databases, etc. Well that didn’t work that out to.

So I thought well, let’s start fresh with new content databases from production. Ahh yes, there we go. Well, at my notebook it didn’t work either. Whoehoe, nice, we’ve got a good starting point for debugging.

Visual Studio 2010:

So I worked with Visual Studio 2010 and the deployed the feature again to debug. Well. Strangely, the solution worked after that. So Microsoft did some tricks while deploying. So I searched and called some people, yes on sunday. And telling me that Visual Studio 2010 is deploying asychronously. Yeah I knew that, but after a minute and some conversation telling that Powershell is deploying synchronously. Well that the trick I thought. So I decided to help my self out with some times, running the admin jobs, etc.

Even that didn’t worked out.

Go debugging old fashioned style: disabling Web and Site scoped features in the onet.xml.

After the first Web Feature (Deploying some List Instances and List Definitions) disabled the solution worked by powershell. I didn’t have a clue, but ohh well, I decided to change the ordering of the feature. Instead of List Definitions first, I decided to set the List Instances first. And you know what, It worked.

After enabling the Web Feature again, I could run the New Site creation perfectly.

Sometimes users receive the following message when attempting a search:

Before that, it will take some seconds before you can see your search page. After watching the ULS logs, I found the following messages:

SearchServiceApplication::Execute–Exception: System.Runtime.InteropServices.COMException (0x800703FA): Illegal operation attempted on a registry key that has been marked for deletion. (Exception from HRESULT: 0x800703FA)

SearchServiceApplicationProxy::Execute–Error occured: System.ServiceModel.FaultException`1[System.ServiceModel.ExceptionDetail]: Illegal operation attempted on a registry key that has been marked for deletion. (Exception from HRESULT: 0x800703FA) (Fault Detail is equal to An ExceptionDetail, likely created by IncludeExceptionDetailInFaults=true, whose value is: System.Runtime.InteropServices.COMException: Illegal operation attempted on a registry key that has been marked for deletion. (Exception from HRESULT: 0x800703FA)

I knew this error before, when I developed a WCF Service, so I searched the registry in order to find the following message:

The reason is when the WCF service stops working and it runs under a particular service account SharePoint restarts the WCF service, and it works again.
The cause of it all is when the service account is logged on when the Search Service Application is launched in this case. It happens all when the service account logs off and the COM+ application can no longer read registry keys in the profile.
If you see the event viewer message, you’ll see that the User Profile Service is a new functionality added in Win Vista and Windows Server 2008. When a user or Service account is logged of, the profile Service forces the unload of the User Profile on the server. But when this happens the User Profile Service can break an application if registry keys are not closed.
The resolution is to make a workaround this issue to disable this feature in the Software Policy on the local system. Btw. For each SharePoint Server you should do this.
Go to the Group Policy Editor and then go to Computer Configuration -> Administrative Templates -> System -> User Profiles.
Edit the setting ‘Do not forcefully unload the registry at user logoff’ to enabled.
And voilà. Workaround created.