Archive for December 2010


SharePoint 2010 Site Templates vs. Features

In SharePoint v4, site templates are considered more generically as solutions; when you save your site as a template, you end up wth a .wsp solution file, not a .stp file like in v3.

So, in our site collection, we go into site settings and select the Solutions gallery.

We can use the ribbon to select Upload Solution and get a dialog box to upload one or more solutions. After uploading, you can pull down the list item menu and select Activate. 

Once activated, we can go back to View All Site Content (/_layouts/viewlsts.aspx) and click Create. In the Create dialog box, we should see our new template listed in the sites group, perhaps filtering for Custom.

We add the site name and URL and click Create. Done.

But, this being SharePoint, like any fake religion such as the Flying Spaghetti Monster, it can be more complicated at times.

As we have seen in the past, the environment from which your site template is created casts a set of requirements on your target environment in the form of host features. For example, on one particular case, we’ve created a template from a site created on a SharePoint Server 2010 host that had been migrated from MOSS 2007.

The MOSS 2007 host, of course, included a site directory and the Site Directory site had been migrated into 2010 and the site from which the template had been created was a 2010 blank site under the Site Directory site. Got it?

Well, our host site was never a MOSS 2007 host so it doesn’t have a site directory. Consquently, when we try to create our new site on this 2010 host, we get:

The site template requires that the Feature
{a392da98-270b-4e85-9769-04c0fde267aa} be activated in
the site collection.
Correlation ID: {9b9ab22e-1774-42f0-b0ca-1d3d795adaf1}
Date and Time: 12/22/2010 11:44:12 AM

So we can search for two things. First,

First, we’re still struggling with this whole Correlation ID thing. Lucky enough, our new best friend, Dina, provides an explanation here.

Then, we find a reference to the Feature ID here. It’s not great but and it’s referring to MOSS 2007 but it suggests we activate the Publishing Infrastructure feature at the site collection level and the Publishing feature at the Site level. Done.a

-Now, attempting to create a site using our template gives us:

The site template requires that the Feature
{e978b1a6-8de7-49d0-8600-09a250354e14} be activated in
the site collection.
Correlation ID: {3aa51c89-319b-4d27-a64e-aa5d6833360e}
Date and Time: 12/22/2010 11:44:12 AM

This is cool because we touched it and made it do something different. When we look for this new Feature ID, we find this from 0ur new best friend, Steve. At the very bottom, he tells us our Feature ID refers to the LocalSiteDirectorySettings feature and, like we said, there’s no Site Directory in the 2010 host.

So what we have here is a feature that’s required by my site template but is deprecated in 2010; it’s only an issue because it was created from a site under a site directory that would never have existed except that it was migrated from 2007.

So, I spend the day looking and find this from MSDN. First it tells me to go look in the \14\Templates\Features folder where, believe it or not, contains all our features listed as folders in English readable text. I open the one called \LocalSiteDirectorySettingsLink and edit the Feature.xml file and see that is indeed the GUID of the feature I need.

Then, the MSDN article suggests we run some PowerShell to install and or activate the feature using the <Command> <FolderName> <URL> format.

I try but find that while the <foldername> parameter doesn’t work, the GUID does. I get the feature activated in my site collection and try to build the site from my template again. This time I get:

The site template requires that the Feature
{fdb3e1d1-a200-46b3-ac54-11f69c0baac4} be activated in
the site collection.
Correlation ID: {adf2a768-2a9d-4fe5-b006-898d9ea0f859}
Date and Time: 12/22/2010 11:44:12 AM


SharePoint 2010 User Profile Synchronization Service

As it turns out, the SPS 2010 User Profile Synchronization Service is something of a challenge. Lucky for us, our new best friend, Spencer, has pretty much covered all the details here.

First, he provides some great backrgound information and explains that the profile service is really the new Forefront Identity Manager service bundled into the SharePoint interface. We’ve got a few cycles through the old MS Identity Lifecycle Manager so the move to the FIM 2010 is likely to be reasonably painless.

Then he drops a bombshell:

[UPDATE: 01/11/2010] Also, I assume that you have not used a
Fully Qualified Domain Name or IP Address when specifying the
SQL Server when running the SharePoint Configuration Wizard
(PSConfig). Using either is strongly discouraged, and will lead
to failures with the provisioning of the User Profile Synchronization
service instance. Stick to a NetBIOS name, or a SQL Server Alias.

We, of course we used the FQDN for our database server. So we have to go back to our SharePoint Configuration Wizard and disconnect from our farm.

Then we run the wizard a second time and connect to our farm using the NetBIOS name for our database server, which is just DB01. The wizard finds the SharePoint_Config database on it and then, we reselect our details and the wizard runs and opens Central Admin.


Next, we’ll need a new service account. Spencer lets the cat out of the bag suggesting that our service accounts ought to go into the Managed Service Accounts folder in Active Directory. Now I never claimed to be an AD wizard, just an SPRobot so, I’m going to move all of our service accounts into that group and hope nothing breaks. Spencer talks about “implications” which we’ll ignore for now. I’ll put the new service account, SVC_SPUPSynch, in there.

Next, he says, our new account will need the Replicating Directory Changes permission. That’s where we meet the Delegation of Control Wizard by right clicking on the domain. We add the service account, and create a custom task. Two pages later, we select the appropriate permission and then Next and Finish.

Then, we’re running ADSIEDIT.msc. Now, Spencer says “Connect to the Configuration Partition” and I guess that’s accurate but what we need to do is right click on our Default Naming Context and select Settings.

Here, we get the Default naming context and we move down to the Select a well known Naming Context option and pull down the list and select Configuration and click OK. Then, we get the folder called CN=Configuration, DC=Domain, DC=com. We can right click on it and select Properties. On the Security tab, we add our SPUPSynch user and then check the “Allow” box for Replicating Directory Changes. We click Apply and OK.

Then, Spencer switches us to your SharePoint server and indicates that we have to let our “SPFarm” account log on locally. This is our SVC_SPDBAcces account. I presume that it can logon locally to our SharePoint server and Spencer is accounting for the possibility that our Profile Synch might run on a different server. All the same, we move to the SharePoint server and select Local Security Policy from Administrative Tools. Under Security Settings, we open the Local Policies | User Rights Assignment node and click on Allow Logon Locally.

We add our SVC_SPDBAccess account and click OK and do a Start | Run | GPUpdate.

Then we get some instructions to make our DB Access account a local administrator. No problem. And then suggests we reboot. No problem.

Now, Spencer says create two web applications, one for the portal and one for the My Sites.

SharePoint 2010 Configs and Features

So we’ve still got a little work to do to finish but we do have a functional SPS2010 farm.

We still need to create some web applications other than the default portal including the DNS settings. Then we have search and profiles to configure.

And there’s some help with anonymous access from our new best friend, Julian here.

In the meantime, we’ve had a little trafffic on SharePoint features. There’s a great list here from MSDN that will let you decode the feature ID’s of the OOTB features.

I’ve also started to detail my DNS configs below.


DNS Settings

The multi-server SharePoint farm relies on domain service accounts that presume a domain and its accompanying DNS settings.

So let’s review. From our previous post, we’ve got three servers:

  1. Domain Controller:
    IP Address: x.x.x.1
  2. Database Server:
    IP Address: x.x.x.2
  3. SharePoint Server:
    IP Address: x.x.x.3

Then I went to my domain registrar and took over the DNS settings pointing them to my DSL modem’s IP address; this is the WAN address on my router.