Archive: ‘SharePoint’ Category

DisableLoopbackCheck

No comments March 28th, 2013

I don’t know about anyone else, but I get tried of doing this in the registry, so I thought it might be interesting to just do this via PowerShell:

New-ItemProperty HKLM:\System\CurrentControlSet\Control\Lsa -Name “DisableLoopbackCheck” -Value “1″ -PropertyType dword

SharePoint 2013 Certification

9 comments January 14th, 2013

Things are definitely changing…people have always deemed the SharePoint certifications easy to get through… Well, for all of you who wanted it to be harder to obtain… Microsoft heard you… Check out what it takes now:

Step Title Optional Training Required Exams
1 Installing and Configuring Windows Server 2012
2 Administering Windows Server 2012
3 Configuring Advanced Windows Server 2012 Services
4 Core Solutions of Microsoft SharePoint Server 2013
5 Advanced Solutions of Microsoft SharePoint Server 2013

 

Luckily, if you’re already SharePoint 2010 certified, you’ll only have to take three exams:

 

Step Title Optional training Required exam
1 Upgrading Your Skills to MCSA Windows Server 2012 417 417
2 Core Solutions of Microsoft SharePoint Server 2013 331 331
3 Advanced Solutions of Microsoft SharePoint Server 2013 N/A 332

This MCSE certification requires you to show continued ability to perform in your chosen solution area by completing a recertification exam every three years.

For more information, check out http://www.microsoft.com/learning/en/us/mcse-sharepoint-certification.aspx

Remember when it was just one test to become a MCP, just 2 to become MCITP, and no re-certification every 3 years? Those were the days. =)

Start studying people… 😉

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.

MOSS 2007 Managed Form Templates Stuck Installing

4 comments April 23rd, 2012

I know there are several posts on this on the internet already, but I have a lot of customers that have asked me about this lately, so I feel like there are either not enough posts out there or maybe this needs to be explained a little better.  I am not saying I will be the one to explain it “better;” however, I thought I’d try.  😉

To resolve this issue, we need to remove the features and re-add them at the farm level which means we SHOULD 😉 deactivate it on every site collection in the farm first; however, you could force the removal of the feature which SHOULD be okay; however, there could be some unforeseen minor issues on some site collections.

The good thing is that because the features have static IDs, when you remove them from the farm level using -force command, the content DBs believe the feature is still there and is activated, but it won’t work if a user attempts to use it while the feature is uninstalled at the farm level.

The first thing we again, SHOULD do, is figure out what all of your site collection URLs are, you will need to run the following command for every web application and pipe that to a text file:

  • [highlight]stsadm.exe -o enumsites -url http://url >C:\enumsites.txt[/highlight]

Once you have compiled a list of URLs of all your site collections, you can create a batch file using the commands below to deactivate the features on all site collections in the farm.

The following command will do deactivate Collect Signatures Workflow (CollectSignatures_Sign_1033.xsn, CS_OOB_WrapItUp.xsn):

  • [highlight]stsadm -o deactivatefeature -id 6C09612B-46AF-4B2F-8DFC-59185C962A29 –url <url_to_site_collection> -force[/highlight]

The following command will do deactivate the Translation Workflow (Xlate_Complete_1033.xsn, Xlate_Init_1033.xsn):

  • [highlight]stsadm -o deactivatefeature -id C6561405-EA03-40A9-A57F-F25472942A22 -url  <url_to_site_collection> -force[/highlight]

Once they are both deactivated on all site collections, you can run the command to uninstall the features, if you run the command WITHOUT the -force switch and a site collection still has the feature activated, you would receive this error:

The feature with ID ‘c6561405-ea03-40a9-a57f-f25472942a22’ is still activated within this farm or stand alone installation. Deactivate this feature in the various locations where it is activated or use -force to force uninstallation of this feature.

The command to uninstall the feature at the farm level is:

Remove Collect Signatures Workflow (CollectSignatures_Sign_1033.xsn, CS_OOB_WrapItUp.xsn):

  • [highlight]stsadm -o uninstallfeature -id 6C09612B-46AF-4B2F-8DFC-59185C962A29[/highlight]

Remove Translation Workflow (Xlate_Complete_1033.xsn, Xlate_Init_1033.xsn):

  • [highlight]stsadm -o uninstallfeature -id C6561405-EA03-40A9-A57F-F25472942A22[/highlight]

You can add -force to the end of the above commands if you choose to force the uninstall while the features are activated on the site collections.

The successful execution of the above commands should result in the above mentioned feature names no longer appearing in Central Administration > Application Management > Manage Form Templates.

Once you have verified that, we then need to re-install the features, use the following commands to do that:

  • [highlight]stsadm -o installfeature -name TranslationWorkflow[/highlight]

After you have run the above command, you should see in Central Administration > Application Management > Manage Form Templates that following .xsn files have been added:

  • Xlate_Complete_1033.xsn
  • Xlate_Inti_1033.xsn
  • Xlate_OOB_WrapItUp_1033.xsn (notice that one wasn’t there originally)

Next, run the following command:

  • [highlight]stsadm -o installfeature -name SignaturesWorkflow[/highlight]

You should now see the following .xsn files have been added:

  • CollectSignatures_Sign_1033.xsn
  • CS_OOB_WrapItUp.xsn (replaces Xlate_OOB_WrapItUp_1033.xsn)

Xlate_OOB_WrapItUp_1033.xsn should now have been removed from the list and you should be left with the same 4 .xsn files you had before and will hopefully be in the “Ready” status:

  • CollectSignatures_Sign_1033.xsn
  • CS_OOB_WrapItUp.xsn
  • Xlate_Complete_1033.xsn
  • Xlate_Inti_1033.xsn

An anomaly I ran across while testing this is that for some reason the CS_OOB_WrapItUp.xsn file wasn’t re-added to the list of templates and Xlate_OOB_WrapItUp_1033.xsn remained there.  If that happens when you follow this procedure, simply remove the Collect Signatures feature again and re-add it, it should then appear in the list. So basically, run these commands again:

  • [highlight]stsadm -o uninstallfeature -id 6C09612B-46AF-4B2F-8DFC-59185C962A29[/highlight] (use –force if you want)
  • [highlight]stsadm -o installfeature -name SignaturesWorkflow[/highlight]

GPO to Automatically Connect SharePoint Calendars to Outlook.

8 comments February 5th, 2012

It’s relatively easy to add a SharePoint calendar to your Outlook mail client, but what if you have a lot of users, new users, and lots of calendars? Do you really want to have to tell every user where every calendar in SharePoint is and how to connect it to their Outlook? Of course not! You have other things to do, right? Why not use a GPO?? Here is how:

  1. Find the stssync URL Address for each SharePoint calendar.
    • On a PC running Outlook 2007/2010 you will need to browse to the SharePoint calendar you would like to connect to.
    • Locate and click the “Connect to Outlook” button, this will open a dialogue box confirming you would like to add the calendar to Outlook, look for the Address and notate it somewhere by highlighting it and copying it and then click cancel. Repeat this until you have notated all the Addresses for each calendar you would like to add to your GPO.
  2. Add stssync addresses into a group Group Policy for deployment.
    • Create a group policy in Group Policy Management Console (GPMC).
    • Open group policy and add Outlk12.adm admin template:
    • Available from: http://www.microsoft.com/download/en/details.aspx?DisplayLang=en&id=22666
    • Expand User Configuration >Administrative Templates > Microsoft Office Outlook 2007, Tools | Account Settings and SharePoint.
    • Open Default SharePoint lists click on Enabled and click on Show then click on add type in a name to be displayed for your Calendar then paste the corresponding stssync address into the value field. Add each calendar to this list.

That’s pretty much it, just apply this GPO to an Organizational Unit (OU) in your domain, and whenever users login and open Outlook, SharePoint calendars specified in your GPO will be added.