Well it’s the middle of July so you know what time it is, its time for the SharePoint 2010 June CU.

Here are a few links…

So for those that have not already done so installing the Visual Studio 2010 Power Tools is well worth your time, especially if you do any SharePoint development. Today I created a console application to test SharePoint 2010. One of the more annoying tasks when creating such an application is adding all the necessary references to the project -- mainly because this is very taxing for my brain to try to remember the various assemblies. One of my favorite features of the VS 2010 Power tools is the new Add Reference dialog (see below).

This screenshot is the new Add Reference Dialog and at the time I captured this view I had just done a search for “sharepoint” and without hitting a single button was returned this list of assemblies. There was not a long delay in loading the assemblies and I don’t have to contend with the different naming conventions used by the various PGs within MSFT.

“Enjoy the little things” — Zombieland

VS2010 Power Tools can be downloaded from: http://visualstudiogallery.msdn.microsoft.com/en-us/d0d33361-18e2-46c0-8ff2-4adea1e34fef

We just released IT Professional and Developer training which includes PowerPoint presentations and videos going over the presentations along with demos to break things up a bit.

The content is broken into two areas, IT Pro and Developer, and both contain hours of content all based on RTM. The content assumes you are familiar with SharePoint and is geared more as a “what’s new, What’s improved, and What’s available”. So rather than explaining what a Feature is all about you get just what you want without having to go through all that stuff you are probably already familiar with.

Where is it?

SharePoint 2010 Advanced Developer Training

SharePoint Server 2010 Advance IT Professional Training

Happy training – let us know how it goes!

In my previous post I documented a bug in SharePoint where a memory leak can greatly impact that amount of memory you SharePoint WFE will use during the normal processing of web request. The SharePoint PG just recently released the 2010 April CU for WSS 3.0 and MOSS 2007. It requires you have Service Pack 2 before installing these cumulative updates but I can tell you that is something you want to invest in.

WSS 3.0
Main KB: http://support.microsoft.com/kb/981043
Download Link: Download April 2010 Server-Package for WSS (981043)

MOSS 2007
Main KB: http://support.microsoft.com/kb/982741
Download Link: Download April 2010 Server-Package for MOSS 2007 (981042)

If you dig into the description of what has been fixed in the CUs you will come across this KB which has this little blurb regarding the Sasquatch.

A memory leak may cause the application pool to recycle the AppDomain because many instances of the SPHttpApplication reach memory limits.

So lets say you create a new site based on the Team template and you would like to create a search center site under that same site collection. So you navigate to Site Actions – New Site and maybe you choose the Enterprise Search Center template and provide a name for your new site and hit “Create”. Well you may be presented with an error like this one…The dreaded unexpected error has occurred error, yuk (failure #1).

Well no worries right, you have the ULS log to query for a hint. While the dialog here provides a correlation ID you can look for in the ULS logs you cannot copy it from this dialog (failure #2) but you can still query the ULS log for entries that match this ID and you will hit upon an entry which a nice looking stack – once you factor the stack out of the ULS entry it will look like the following.

Detected use of SPRequest for previously closed SPWeb object.  Please close SPWeb objects when you are done with all objects obtained from them, but not before.  
Stack trace:    
at Microsoft.SharePoint.WebControls.ScriptLink.SharePointClientJs_Register(Page page)     
at Microsoft.SharePoint.WebControls.ScriptLink.InitJs_Register(Page page)     
at Microsoft.SharePoint.WebControls.ScriptLink.RegisterForControl(Control ctrl, Page page, String name, Boolean localizable, Boolean defer, Boolean loadAfterUI, String language)     
at Microsoft.SharePoint.WebControls.ScriptLink.Register(Page page, String name, Boolean localizable, Boolean defer, Boolean loadAfterUI, String language, String uiVersion)     
at Microsoft.SharePoint.WebControls.ScriptLink.RegisterOnDemand(Page page, String strKey, String strFile, Boolean localizable)     
at Microsoft.SharePoint.WebControls.ScriptLink.RegisterCore(Page page, Boolean defer)     
at Microsoft.SharePoint.WebPartPages.SPWebPartManager.RegisterOWSScript(Page page, SPWeb web)     
at Microsoft.SharePoint.WebPartPages.WebPartPage.FormOnLoad(Object sender, EventArgs e)     
at System.Web.UI.Control.OnLoad(EventArgs e)     
at System.Web.UI.Control.LoadRecursive()     
at System.Web.UI.Control.LoadRecursive()     
at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)     
at System.Web.UI.Page.ProcessRequest(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)     
at System.Web.UI.Page.ProcessRequest()     at System.Web.UI.Page.ProcessRequest(HttpContext context)     
at ASP._layouts_addgallery_aspx.ProcessRequest(HttpContext context)     
at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()     
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)     
at System.Web.HttpApplication.PipelineStepManager.ResumeSteps(Exception error)     
at System.Web.HttpApplication.BeginProcessRequestNotification(HttpContext context, AsyncCallback cb)     
at System.Web.HttpRuntime.ProcessRequestNotificationPrivate(IIS7WorkerRequest wr, HttpContext context)     
at System.Web.Hosting.PipelineRuntime.ProcessRequestNotificationHelper(IntPtr managedHttpContext, IntPtr nativeRequestContext, IntPtr moduleData, Int32 flags)     
at System.Web.Hosting.PipelineRuntime.ProcessRequestNotification(IntPtr managedHttpContext, IntPtr nativeRequestContext, IntPtr moduleData, Int32 flags)     
at System.Web.Hosting.PipelineRuntime.ProcessRequestNotificationHelper(IntPtr managedHttpContext, IntPtr nativeRequestContext, IntPtr moduleData, Int32 flags)     
at System.Web.Hosting.PipelineRuntime.ProcessRequestNotification(IntPtr managedHttpContext, IntPtr nativeRequestContext, IntPtr moduleData, Int32 flags) 

So this does not really give us anything to go on here but it would appear there is a bug where someone is probably disposing of an SPContext.Current object – still nothing we can do about that.

So lets attach WinDbg to the correct w3wp process and retry the operation. Once reproduced lets look at what was spit to the debugger….

<<snip>>
(14f4.11c0): CLR exception - code e0434f4d (first chance)
(14f4.11e8): CLR exception - code e0434f4d (first chance)
(14f4.11e8): CLR exception - code e0434f4d (first chance)
(14f4.11e8): CLR exception - code e0434f4d (first chance)
(14f4.11e8): CLR exception - code e0434f4d (first chance)
(14f4.ec0): CLR exception - code e0434f4d (first chance)
(14f4.ec0): CLR exception - code e0434f4d (first chance)
(14f4.ec0): CLR exception - code e0434f4d (first chance)
(14f4.ec0): CLR exception - code e0434f4d (first chance)
(14f4.ec0): CLR exception - code e0434f4d (first chance)
CLR exception type: System.InvalidOperationException
    "The SharePoint Server Publishing Infrastructure feature must be activated at the site collection level before the Publishing feature can be activated."
(14f4.ec0): CLR exception - code e0434f4d (first chance)
CLR exception type: System.InvalidOperationException
    "The SharePoint Server Publishing Infrastructure feature must be activated at the site collection level before the Publishing feature can be activated."
(14f4.ec0): CLR exception - code e0434f4d (first chance)
CLR exception type: System.InvalidOperationException
    "The SharePoint Server Publishing Infrastructure feature must be activated at the site collection level before the Publishing feature can be activated."
(14f4.ec0): CLR exception - code e0434f4d (first chance)
CLR exception type: System.InvalidOperationException
    "The SharePoint Server Publishing Infrastructure feature must be activated at the site collection level before the Publishing feature can be activated."
(14f4.ec0): CLR exception - code e0434f4d (first chance)
CLR exception type: System.InvalidOperationException
    "The SharePoint Server Publishing Infrastructure feature must be activated at the site collection level before the Publishing feature can be activated."
(14f4.ec0): CLR exception - code e0434f4d (first chance)
CLR exception type: System.InvalidOperationException
    "The SharePoint Server Publishing Infrastructure feature must be activated at the site collection level before the Publishing feature can be activated."
(14f4.ec0): CLR exception - code e0434f4d (first chance)
(14f4.ec0): CLR exception - code e0434f4d (first chance)
CLR exception type: System.InvalidOperationException
    "The SharePoint Server Publishing Infrastructure feature must be activated at the site collection level before the Publishing feature can be activated."
(14f4.11e8): CLR exception - code e0434f4d (first chance)
(14f4.ec0): CLR exception - code e0434f4d (first chance)
(14f4.11e8): CLR exception - code e0434f4d (first chance)
(14f4.ec0): CLR exception - code e0434f4d (first chance)
(14f4.ec0): CLR exception - code e0434f4d (first chance)
(14f4.ec0): CLR exception - code e0434f4d (first chance)
(14f4.11e8): CLR exception - code e0434f4d (first chance)
(14f4.11c0): CLR exception - code e0434f4d (first chance)
(14f4.11e8): CLR exception - code e0434f4d (first chance)
(14f4.11e8): CLR exception - code e0434f4d (first chance)

OK now I have something to go look at. Sure enough on my Team site I did not have the Site Collection Feature SharePoint Server Publishing Infrastructure enabled. Once I enabled this feature I retried the operation and sure enough the problem was resolved. So failure #3 was assuming the ULS was giving me the best error available. I suspect the error being reported was due to a bad code path which we took once the source error was encountered.

I Have had the great honor of hitting a good number of errors while setting up the User Profile Sync service. I documented one error here but when setting up another environment today I hit yet another. The environment in question was a two server setup with one server being the DC and the other SharePoint + SQL Server. I use the farm account CONTOSO\FarmAccount. I setup all Service Applications using the PowerShell script found here and started the services I wanted to run. When I got to starting the User Profile Synchronization Service I would eventually see the following error in the event log.

With only this error to go on I decided to attach a debugger. Now that was probably heavy handed and ProcMon would have have probably given me the answer here too but WinDbg is much more sexy, yea! Soon after I started the service with windbg attached to the owstimer service I found a security error trying to access the registry. Poking around a bit in the debugger I was able to determine the CONTOSO\FarmAccount was attempting to gain access to HKLM\SYSTEM\CurrentControlSet\Services\FIMSynchronizationService\Parameters and was failing. I decided to shotgun this one and grant my CONTOSO\FarmAccount local admin, restarted the timer service, and retried the operation – it worked. Thinking back about what may have happened I opened the key within the registry editor…now what is strange is I noticed the CONTOSO\FarmAccount has permissions to that key – I wish I had looked before I fixed the problem however I suspect the permissions might have been set after the provision completed or at least got past the point where I failed the first time.

If anyone hits this error, before you do what I have done here I would check the permissions on HKLM\SYSTEM\CurrentControlSet\Services\FIMSynchronizationService\Parameters and see if your Farm Account is present.

While running SharePoint 2010 I started to notice the following error messages in my Application event log each time I restarted the IIS Worker process and made a request.

For the setup of my SharePoint farm I use 3 accounts, Farm (CONTOSO\FarmAccount), SA Service Account (CONTOSO\SPServiceAccount), and an Application Pool account (CONTOSO\AppPoolAccount). Looking at my c:\Users directory I see that I have a FarmAccount profile so if you are running your Application Pools as this account then you probably are not seeing this error message. But if you are using a seperate account to run your Application Pools you are probably seeing this error in your event logs.

There is obviously something running with the w3wp process which needs to load the user’s profile, which in this case is my CONTOSO\AppPoolAccount. After creating a profile for my AppPoolAccount this error disappeared and I confirmed with ProcMon that it was loaded and being used by w3wp.

There are obviously several ways to create a profile for a user, for example you might choose to login to the server as that user however I chose a different path which seemed faster.

1. Run IISReset and ensure the AppPool account is not running any processes and its temporary profile is not loaded.
2. If your AppPool account does not have login locally permission you will need to grant it for this process, I just use the cmd line: net localgroup administrators CONTOSO\AppPoolAccount /add when complete I ran the same command but with a /delete
3. From the command line run: runas /u:CONTOSO\AppPoolAccount /profile cmd  and then type the password when prompted. At the point the cmd prompt opens you should have a new profile for this user at c:\users\AppPoolAccount, if not then within your cmd prompt that you just started run echo %userprofile% if this does not work then the real profile was not loaded and you are still probably using the temporary profile. Try deleting the temporary profiles out of c:\users, these are probably named c:\users\Temp.[domainname].00x, example c:\users\temp\contoso.002 After you delete these try this process again.
4. Once you have a profile you may want to remove any logon locally rights you may have granted your AppPool account.

On SharePoint 2010 you may run into the following error (hell that is a damn lie, you will hit this error eventually if running RTM).

Load control template file /_controltemplates/TaxonomyPicker.ascx failed: Could not load type 'Microsoft.SharePoint.Portal.WebControls.TaxonomyPicker' from assembly 'Microsoft.SharePoint.Portal, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c'.

It looks like this in your Application Event Log:

UPDATE:: After doing this fix I received this error again. I checked the Microsoft.SharePoint.Portal assembly and did not find the TaxonomyPicker class!!! So to fix this you may want to rename TaxonomyPicker.ascx to TaxonomyPicker.ascx_broken so we do not try to recompile it each time the AppPool is started. The user control is never used within SharePoint and therefore serves no real purpose.

If you assumed you configured something incorrectly; don’t, its a bug in SharePoint – the good news is you can actually fix this one yourself.

1. Navigate to /14/ControlTemplates/TaxonomyPicker.ascx user control
2. Open the user control in a text editor and locate the first line
3. Find the character string , and replace with a comma ‘,’ (without quotes).
4. Save the user control and you have completed fixing this bug

I think its safe to assume most SharePoint developers which have been working with the product for any length of time have seen code similar to the code below below. Its a common problem, disposable objects which are not disposed. There has been a ton written on this problem and Roger Lamb wrote a great tool called SPDisposeCheck which you run against your assemblies to determine if they may be failing to call Dispose.

public partial class VisualWebPart1UserControl : UserControl
{
  protected void Page_Load(object sender, EventArgs e)
  {
    SPSite site = new SPSite("http://intranet.contoso.com");
    foreach (SPWeb web in site.AllWebs)
    {
      Response.Write(web.Name);
    }
  }
}

Visual Studio 2010 includes a new Code Analysis rule which can check for these problems too. Now I am no SKU king so I cannot tell you what SKUs come with Code Analysis and which do not. I do know three things about this topic, (1) Not all Visual Studio 2008 SKUs included this feature, (2) I am guilty of being one of the many Microsoft minions which when we install Microsoft products look for versions with names like “Enterprise”, “Datacenter”, “Ultimate”, “Uber”, etc. (3) I am running Visual Studio 2010 Ultimate and it has Code Analysis built-in.

You can enable Code Analysis from the Project Properties dialog and choosing the “Code Analysis” tab at the bottom and then clicking on the “Enable Code Analysis…” checkbox which I have highlighted here.

For the code I have include above here is what Visual Studio Reports…

At this point a pain of disappointment should be felt; Visual Studio 2010 only found one of the two Dispose issues, that is a 50% success rate if you are that type of person; if you are the other that is a 50% fail rate – pick your side but it is unacceptable for such as small and trivial test.

Now how does SPDisposeCheck fair? SPDisposeCheck found both issues!

Conclusion
Although Visual Studio 2010 has many great code analysis rules, and I use them frequently I personally would continue to use SPDisposeCheck as part of my development toolset.

In SharePoint 2010 you have the option of setting your Web Application to use Claims based security or Classic security which is the same as Windows security, aka like we did it in SharePoint 2007. While playing around with an anonymous site which was hosted within a Web App which was configured for claims I came across something interesting that I wanted to make sure you all were aware of. Although your Web Application is configured for claims your OS still uses Windows authentication, this means your AppPool and your IIS anonymous user are not using Claims.

To make the point check out the bit of code below and note right before the local variables the values which will be stored for each once this code is executed within an anonymous site within a claims based web application.

    
    public partial class DaWebPart : UserControl
    {
        protected void Page_Load(object sender, EventArgs e)
        {
            /*NULL*/
            string claimAnon = System.Threading.Thread.CurrentPrincipal.Identity.Name;

            /*NT AUTHORITY\IUSER*/
            string winAnon = System.Security.Principal.WindowsIdentity.GetCurrent().Name
            
            /*NULL*/
            string runWithClaim;

            /*CONTOSO\AppPoolAccount*/
            string runWithWin; 

            SPSecurity.RunWithElevatedPrivileges(delegate
            {
                runWithClaim = System.Threading.Thread.CurrentPrincipal.Identity.Name;
                runWithWin = System.Security.Principal.WindowsIdentity.GetCurrent().Name;
            });
        }
    }

This scenario does not change much when not running anonymous other than you will have real user names when you access your Claim Identities via System.Threading.Thread.CurrentPrincipal.Identity.

So when we make a call to RunWithElevatedPrivileges() its doing the right thing for us however if you only look at the Thread’s CurrentPrincipal.Identity you will be looking at the ClaimIdentity but you just told SharePoint to change out your WindowsIdentity. An important distinction if you take a dependency on this functionality when moving your code from 2007 to 2010 with claims.