Archive: Posts Tagged ‘SharePoint 2010’

Unexpected: Throw If Max Http Collection Keys Exceeded

1 comment April 24th, 2012

On Dec 29, 2011, Microsoft released a security update KB2656356 / MS11-100 (http://technet.microsoft.com/en-us/security/bulletin/ms11-100) for ASP.NET to address a potential Denial of Service vulnerability.

In the update, they introduced a limit to the number of data elements on an ASP.NET form.   The default limit is 1000 data elements which can be easily met by complex 3rd party or custom webparts

Exceeding the limit will cause a ThrowIfMaxHttpCollectionKeysExceeded error.

After applying the patch, forms that exceed the limit will generate the following error (in ULS Log) attempting to configure/manipulate the webparts attributes :

System.Web.HttpException: The URL-encoded form data is not valid. —> System.InvalidOperationException: Operation is not valid due to the current state of the object.

at System.Web.HttpValueCollection.ThrowIfMaxHttpCollectionKeysExceeded()

at System.Web.HttpValueCollection.FillFromEncodedBytes(Byte[] bytes, Encoding encoding)

at System.Web.HttpRequest.FillInFormCollection()

Add the following to the web.config of all web front end servers in your farm:

<appsettings>

<add key=”aspnet:MaxHttpCollectionKeys” value=”10000″></add>

[</appsettings>

After the above is added, your various webparts should begin functioning normally.

Resolving the super user/super reader account utilized by the cache is not configured…

2 comments October 9th, 2011

Chances are that if you have a multi-server SharePoint farm, you’ll soon run into these errors in your Event Viewer sooner or later, probably sooner rather than later:

  • Object Cache: The super user account utilized by the cache is not configured. This can increase the number of cache misses, which causes the page requests to consume unnecessary system resources.
    To configure the account use the following command ‘stsadm -o setproperty -propertyname portalsuperuseraccount -propertyvalue account -url webappurl’. The account should be any account that has Full Control access to the SharePoint databases but is not an application pool account.
    Additional Data:
    Current default super user account: SHAREPOINT\system

 

  • Object Cache: The super reader account utilized by the cache does not have sufficient permissions to SharePoint databases.
    To configure the account use the following command ‘stsadm -o setproperty -propertyname portalsuperreaderaccount -propertyvalue account -url webappurl’. It should be configured to be an account that has Read access to the SharePoint databases.
    Additional Data:
    Current default super reader account: NT AUTHORITY\LOCAL SERVICE

I’ve seen my clients run into this issue a lot; however, I myself have personally never encountered the error in an environment of my own. Well the other night I decided I was going to “upgrade” my SharePoint 2010 Single Server environment to a multi-server load balanced farm. Everything went great, I went to bed happy, I woke up in the morning, and my claims based web applications weren’t working anymore. I saw the above error in the Event Viewer of both WFEs. Like I said before, I tell people how to resolve it all the time, but it never brings down a web application, it’s just an annoying error. Well apparently claims based sites in multi-server environments need these accounts to be set properly. So lets walk through it:

  1. Navigate to Central Administration
  2. Application Management
  3. Manage Web Application
  4. Select the Web Application
  5. Click User Policy
  6. Add Users
  7. Click Next
  8. Fill in domain\superuser and domain\superreader accounts
  9. Select Full Control
  10. Click OK
  11. Edit the domain\superreader account you just added and change it to Full Read

If you’re utilizing Claims Based Authentication the users should be displayed something like this:

  • i:0#.w|domain\superuser
  • i:0#w|domain\superreader

Once you’ve completed the above, you are ready to set the accounts as superuser and superreader of the farm for that particular web application.  There are several ways to do this, you can use the STSADM method which I consider the old way, but hey, it still gets the job done:

  • stsadm -o setproperty -propertyname portalsuperuseraccount -propertyvalue account -url webappurl
  • stsadm -o setproperty -propertyname portalsuperreaderaccount -propertyvalue account -url webappurl

You can also use STSADM’s big brother PowerShell which is the better more powerful option…

If you’re utilizing Classic Mode Authentication execute the following cmdlets from any of your SharePoint Farm servers:

$wa = Get-SPWebApplication “http://WebAppURL/”
$wa.Properties[“portalsuperuseraccount”] = “domain\superuser”
$wa.Properties[“portalsuperreaderaccount”] = “domain\superreader”
$wa.Update()

If you’re utilizing Claims Based Authentication execute the following cmdlets from any of your SharePoint Farm servers:

$wa = Get-SPWebApplication “http://WebAppURL/”
$wa.Properties[“portalsuperuseraccount”] = “i:0#.W|domain\superuser”
$wa.Properties[“portalsuperreaderaccount”] = “i:0#.W|domain\superreader”
$wa.Update()

If everything executes successfully, just give IIS a quick restart and you should be good to go. 😉

How to delete a service application using Powershell

1 comment August 9th, 2011

The SharePoint 2010 Central Administration is great, but just like every other version of SharePoint, it doesn’t always quite cut it and even though you’re the “Admin” you inevitabley won’t be able to do something you want to do.  Go figure right? We can’t do whatever we want when we want to? Who would have though that? 

Well STSADM used to be to the “one” who wouldn’t say “NO” as much as often or as LOUD as CA while giving you less lame excuses. 

With SP2010, PowerShell is another option we have to turn to that does more of what we want when we want with even less lame excuses.

Let’s run through how to delete a service application when CA is saying NO…

Lets find the service application we want to delete using the following command:

$spapp = Get-SPServiceApplication -Name "Service Application Name"

For the “Service Application Name” (yes, include the quotes in the command) just type the service name you see in your CA under:

Central Administration >> Application Management >> Service Applications >> Manage service applications

or since we are talking about using Powershell, use the following command to display the services:

Get-SPServiceApplication

For Example: Search Service Application

So your command might look like this:

$spapp = Get-SPServiceApplication -Name "Search Service Application"

So if you remember in STSADM, you would have to run a command that would output the GUID for you, then run another command with the GUID included to get your desired results right?  Powershell actually stores the GUID in the $spapp variable for you.  So all you have to do is run this command and you can kiss that Service Application goodbye.

So keeping in mind that $spapp is storing the GUID for you, type the following command:

Remove-SPServiceApplication $spapp

If you would also like to remove the associated database(s), type the following command:

Remove-SPServiceApplication $spapp -RemoveData

So long story short:

$spapp = Get-SPServiceApplication -Name "Search Service Application"
Remove-SPServiceApplication $spapp

or

Remove-SPServiceApplication $spapp -RemoveData

SharePoint 2010 Cumulative Updates

No comments May 25th, 2011

SharePoint 2010 Cumulative Updates have always been a little hard to keep up with, by the time you update, you’re already behind. So the only point of this post is really so that I can point people to a URL that I can remember that has all of them in one place, with version numbers and release dates.  So here they are starting from newest to oldest…

CU TitleApplicationKB#VersionReleased
April 2011SPS2010251280014.0.5138.5001April 28, 2011
April 2011SP Foundation251280414.0.5138.5001April 28, 2011
February 2011SPS 2010247587814.0.5136.5002March 3, 2011
February 2011SP Foundation247588014.0.5136.5002 March 3, 2011
December 2010SPS 2010245925714.0.5130.5002December 31, 2010
December 2010SP Foundation245912514.0.5130.5002December 31, 2010
October 2010SPS 2010239432014.0.5128.5000October 26, 2010
October 2010SP Foundation239432314.0.5128.5000October 26, 2010
August 2010SPS 2010235234214.0.5123.5000August 31, 2010
August 2010SP Foundation235234614.0.5123.5000August 31, 2010
June 2010
June 2010
June 2010
June 2010
June 2010
SPS2010 (No Consolidation)983497
2124512
2182938
2204024
2281364
June 29, 2010
June 2010SP Foundation202856814.0.5114.5000June 29, 2010

Utilizing PowerShell to Deploy SharePoint 2010

2 comments January 31st, 2011

Standardization of SharePoint 2010 deployments are important to me, especially within the DoD. It’s my belief that standardization could minimize environmental issues while giving all of us engineers a baseline understanding of how farms have been deployed in common environments, reducing spin up to final resolution times. The use of PowerShell allows us to do this without having to rely on the user to click or not click something which lets face it, sometimes we can’t rely on ourselves to click the right thing every time, so we can’t expect it from anyone else. So let’s look at how we can install SharePoint 2010 using a script and deploy the farm using PowerShell:

I recommend following a previous blog post before implementing the steps below to insure you have prepared your operating system for SharePoint 2010:

Preparing W2K8 for SharePoint 2007/2010 Installation.

Install SharePoint 2010 PreReqs:

For each of the servers in the farm (SPAPPSVR, SPIDX, SPWFE1, and SPWFE2):

  1. Create a folder named SP2010_Build on your D:\
  2. Inside the SP2010_Build folder, create 2 more folders named Products and another named Scripts.
  3. Inside the Products folder, create another folder named SharePoint_2010_Installation.
  4. Copy your SharePoint 2010 RTM files and any updates into the D:\SP2010_Build\Products\SharePoint_2010_Installation folder.
  5. Download the SP2010_PreReq.iso file.
  6. Mount the ISO file to your operating system or burn them to a CD.
  7. Copy the folder named PrerequisiteInstallerFiles to the D:\SP2010_Build\Products\SharePoint_2010_Installation folder.
  8. Copy the file named PrerequisiteInstaller.Arguments.txt file to the D:\SP2010_Build\Products\SharePoint_2010_Installation folder.
  9. Copy the file Prereq_SP2010.cmd to the D:\SP2010_Build\Scripts\ folder.
  10. Execute Prereq_SP2010.cmd from command prompt so that you can view the output:
  11.  

    Restart Server(s)

    Continue reading…