Archive: Author Archive

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.

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