Adventures in Technobabble

Posts Tagged ‘Sharepoint 2010’:

STSADM Import Creating Ghost Lists in SharePoint 2010

Published by Christopher Webb in Sharepoint on November 6th, 2011 | 1 Comment »

I need to start this post off by saying 2 little disclaimers:

A) don’t use stsadm in SharePoint 2010, I know it’s still supported but just don’t. It’s going away soon, has less functionality than PowerShell, and can cause some issues that may be unexpected. If you are having this issue as well, you are likely using it in a way that is unsupported anyway.

B) Microsoft does not support direct SQL edits on SharePoint farms. They never have and likely never will. This post has a fix to a specific issue, but I must stress that this fix is not supported by MS.

Now, on to our problem. SharePoint 2010 introduced a great new feature with its restore from unattached content database functionality. I use it all the time for restores of lists, documents, subsites, and collections. FYI, I have run into this issue several times when restoring lists, but have not even attempted the process since SP1 upgrade for sites, collections, etc. Now, if you notice, once you have browsed for an item to be pulled from the unattached content DB, SharePoint (and all the documentation) say to use Import-SPWeb PS cmdlet to import the list/site back into your environment. Before SP1, SharePoint would allow you to use stsadm -o import without complaining and it worked just fine (at least all the times I used it, remember it isn’t supported so I may have just been lucky). Now, after SP1, if you try to use stsadm to import a list, it will fail and on your site you will see some funky issues. You may experience the following:

Import fails saying List already exists with the same name (even if one doesn’t)

You cannot browse to the URL of the list in question to view content(don’t remember if it gives error of list has been deleted by another user or if it was a 404)

You will not be able to see the list at all in site content & structure admin page or in SharePoint Designer

You WILL be able to see the list in view all site content, but when you look at the URL, it does not take you to the URL with content for the list, but to another URL with the list GUID in it (again a lot of this is just from my notes/memory, sorry no screenshots or exact URL syntax). This page gives an error stating the list does not exist, may have been deleted by another user.

The content DB will not report the list as an orphan when you try to run a check.

You will NOT be able to delete the list normally. The list settings page will fail saying list does not exist, and PowerShell will fail with same error.

So, in essence you have a ghost list where you cannot see any of the content via designer or the browser and it looks like it shouldnt/doesn’t exist, but it is stuck in view all site content and prevents you from importing the list properly (as now, guaranteed you will have a list of same name, even though it doesn’t exist).

To remove this list, you will need to do some SQL queries (again, not supported by Microsoft). First, if you look at the URL from view all site content for the list, you can see the GUID. Copy the GUID down and find which content DB the site collection is in. Go to SSMS and run this query:

use <content_db>

select * from dbo.alllists

where tp_id = <list GUID>

You should see the info for your ghost list. Now, to get rid of it, just change “select” to “delete”:

use <content_db>

delete * from dbo.alllists

where tp_id = <list GUID>

Now, refresh your view all site content and the list should not show. OK, so the ghost list has been deleted, now let’s get that list imported in properly:

Import-SPWeb -Identity-Path

Simple enough, right. Oh, and just as a note, with Import-SPWeb you put just the site URL, not the URL to the list as you did with STSADM. We have started noticing this issue in 2010 SP1, even if it’s just an stsadm export, then stsadm import, so it may not be just that we were using it improperly but some changes in SP1 that may be forcing early depreciation of stsadm. I am not sure what the situation is for sure, but I have decided to just completely stop using stsadm altogether.

Tags: ghost list, server 2008, sharepoint, Sharepoint 2010, stsadm

Clear the SharePoint Configuration (Timer) Cache

Published by Christopher Webb in Sharepoint, Windows on September 14th, 2011 | No Comments »

The config cache is where we cache configuration information (stored in the config database) on each server in the farm. Caching the data on each server prevents us from having to make SQL calls to pull this information from the configuration database. It is full of XML files containing configuration objects. The SharePoint configuration cache is where configuration information from the SharePoint configuration database is stored on each server in the farm. Caching the data from the config database as XML files on the web front ends and application servers prevents multiple calls to SQL Server thus improving performance. This is a feature in WSS & MOSS 2007 as well as SharePoint 2010.

Sometimes this cache can become corrupted. This issue can come up when developing timer job definitions . These definitions use this cache, so everytime you deploy new versions of the assemblies, you’ll have to clear the cache. Also, when the cached data becomes out of sync with what’s in the configuration database, timer jobs may start failing. This will occur if the contents of the file system cache on the front-end servers are newer than the contents of the configuration database, so after you perform a system recovery you may have to manually clear the file system cache on a server as well. Another of the reasons your cache could be out of sync is if the Timer service on your servers was stopped or failed unexpectedly.

If you are experiencing issues with WSS/MOSS/SharePoint timer jobs failing to complete or you are receiving errors trying to run psconfig, clearing the configuration cache on the farm or a problem server is a possible method for resolving the issue.

To clear the configuration cache, Follow these steps:

First, stop the timer service on the server.

Next, navigate to: C:\ProgramData\Microsoft\SharePoint\Config

You will see 2 folders in this directory. Both are named with GUIDs. Open them up and be sure NOT to touch the one with the PERSITEDFILEs. Find the one that is filled with XML files.

In the directory with the XML config files, delete everything except cache.ini. Then, edit the cache.ini file so that it just contains one line with a “1″.

Now, restart the Timer service on the server and watch for the folder to start repopulating the folder.

If this is a single-server farm, or if there is only one problem server, this may be all you need but I recommend doing it on all the web front ends and the application servers in the farm.

Once you are done, go into Central Admin and check your timer job status. You should see a timer job for “Config Refresh”. Verify that this job shows a status of succeeded.

Now you’re good to go.

Tags: Config Cache, Configuration Cache, sharepoint, sharepoint 2007, Sharepoint 2010, Timer Cache

SharePoint 2010 People Picker Invisible Duplicates (Issues with Security Groups)

Published by Christopher Webb in Sharepoint, Windows on September 14th, 2011 | 2 Comments »

I ran into an interesting issue the other day. In one of our client’s SharePoint 2010 install, we were trying to add a group to a site collection. People Picker kept underlining the name saying “No exact match was found. Click the item(s) that did not resolve for more options.” Just as you would expect if there were duplicate names but when you click the name, the dropdown only shows one name. (sorry, I cannot pull images from the client site, so these are simulated)

It would have the same effect whether using DOMAIN\user or just user. It also would only return one name when you search using the address book. This in itself isn’t that unusual, but when we select the name from the dropdown and click OK, it comes back saying No exact match again. People Picker and the address book both seem to only see 1 name, but when SharePoint goes to process it, it sees a duplicate.

So, I took a look at AD to see if there was an issue with the account. I realized there are 2 groups in AD that are very similar. The accounts have different sAM Account Names, which in 99% of applications is all that is needed to differentiate the accounts. Here is a table showing the basics of how the accounts compare:

sAM Account Name Display Name Object Type

group1_dl group1 distribution list

group1_sg group1 security group

If you notice with SharePoint, after People Picker resolves your account names it shows the Display Name of the account, not the sAm Account Name. This seems OK initially as well. After digging further into the issue, things started to click. People Picker is only able to see security principals (which doesn’t include distribution lists), so when it gave you the drop down to pick the exact account it only saw the security group. Once you select the account, SharePoint then takes and processes the Display Name to be added to SharePoint. I have never heard of an application doing this, but it makes sense after looking at the problem and how SharePoint is functioning.

So, People Picker is only allowing you to select the security group, but when SharePoint queries AD, it uses the Display Name, which sees both groups and causes it to think there’s a dup. So just make sure your display names are also different and not just the sAM Account Names.

Tags: People Picker, sharepoint, Sharepoint 2010

SharePoint 2010 Claims Based Authentication Setup

Published by Christopher Webb in Sharepoint, Windows on April 29th, 2011 | 3 Comments »

I searched around quite a bit and found a lot of incomplete walkthroughs and information on setting up claims-based authentication for Sharepoint 2010. Here is the process I finally ended up using and some extra stuff that may be helpful. This seems to be the most direct route to getting things set up, as you don’t have to fiddle around in IIS, just edit your xml config files.

Just a notice, I am using SharePoint Server Enterprise 2010 with SQL Server R2 Standard on Windows Server 2008 R2 Standard, but your SQL can be anything, even express and SharePoint can be just WSS/SharePoint Foundation 2010.

Fist you need to open Visual Studio and create a new web site. This didn’t make sense to me at first, either, but it is only to create your SQL database for .NET users. The aspnet_regsql command did not work for me, so I used VS2010 instead(any version that uses .NET 2.0 should be fine as that is Sharepoint 2010′s default .NET settings). So for your new site, just pick a blank C# site, make sure it is .NET 2.0.

Creating new website in Visual Studio 2010

Then you will go up top to the “Website” menu and select “ASP.NET Configuration”. This will open a site that we can configure .NET authentication database. We will go to the Providers tab first. Choose the option “Select a different provider for each feature(Advanced)”. Test the connection for both AspNetSqlMembershipProvider and AspNetSqlRoleProvider.

Next, go to Security tab and select authentication type under users. Pick “From the internet”, then click done. At this point, I would create a test user and a couple roles in the database (I just started with “standard” and “superuser” for the test roles).

Browse to the location where you created the web site (i.e. C:\Users\<user>\documents\Visual Studio 2010\web sites\<website1>\App_Data) and copy the ASPNETDB.mdf and the ASPNETDB.ldf (sometimes ASPNETDB_log.ldf or other variant) to your SQL server directory. Default directory for SQL 2008 R2 on Server 2008 R2 is: C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA.

Now close Visual Studio and delete the directory for that web site. We just needed those database files to be created.

Once the files are in the appropriate directory(this may be a seperate directory, if you do not keep your db files in the default location), we will open SQL Server Management Studio and attach the database. To attache the database, right-click on “Databases” and select “Attach”.

Then, from the next screen you click “Add…” and select the ASPNETDB.mdf file. It will then populate the other fields like so:

Attaching-Database

One thing that is important is to verify the path on the bottom is correct for the “current file location” for your log file (.ldf).

Now we will create our application & site collection in Sharepoint. Open Central Admin, click “Manage Web Applications” under the Application Management heading. Then select “New” from the ribbon up top. In the Create New Web Application box, there are only 2 sections that you will need to modify to get claims-based auth to work, the rest you can set however you see fit for your environment. First, make sure that Claims Based Authentication is selected as the Authentication method. Second, you sill need to set the providers for your forms based authentication. To do this, next to the Claims Authentication Types setting, leave The Windows authentication as it is, but check “Enable Forms Based Authentication (FBA)” and fill in the boxes as seen below:

FBA_Providers

Now, create your site collection by going to Application Management in SharePoint Central Admin console. Then Select Create site collections under the Site Collections heading. Select the application we just created, give it a title and whatnot and pick your site collection admins. I like to create the site now, because then it forces you to choose admins who can access via Windows auth, in case the FBA config doesn’t work out.

And you are pretty much ready to go, except for editing the xml configuration files. Now, before we proceed, make a backup of these xml files. This is very important. The first file we will be modifying is the Central Admin web.config. It is located at: C:\inetpub\wwwroot\wss\VirtualDirectories\<port>\web.config by default.

Between </appSettings> and </configuration>, insert the following. If there is another section named <connectionStrings>, delete it. Please do not comment anything out in here, unless you know XML well. Comments in the wrong places can cause XML to become unreadable.

<connectionStrings>
<add name=”SQLConnectionString” connectionString=”data source=<SQL Server>;Integrated Security=SSPI;Initial Catalog=ASPNETDB” />
</connectionStrings>

Next, right before the close of system.web or </system.web>, insert the following. Again delete any duplicates of <membership> or <roleManager> categories and delete everything ocntained within them as well (i.e. all between <membership> and </membership>).

<roleManager defaultProvider=”AspNetWindowsTokenRoleProvider” enabled=”true” cacheRolesInCookie=”false”>
<providers>
<add connectionStringName=”SQLConnectionString” applicationName=”/” name=”SQLRoleManager” type=”System.Web.Security.SqlRoleProvider, System.Web, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a” />
</providers>
</roleManager>
<membership defaultProvider=”SQLMembershipProvider”>
<providers>
<add connectionStringName=”SQLConnectionString” passwordAttemptWindow=”5″ enablePasswordRetrieval=”false” enablePasswordReset=”false” requiresQuestionAndAnswer=”true” applicationName=”/” requiresUniqueEmail=”true” passwordFormat=”Hashed” name=”SQLMembershipProvider” type=”System.Web.Security.SqlMembershipProvider, System.Web, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a” />
</providers>
</membership>

Save that file and we’re on to the next. The web application’s web.config, which will be located by default at: C:\inetpub\wwwroot\wss\VirtualDirectories\<port>\web.config. Again, make a copy before editing. In between the </SharePoint> and </system.web>, insert the following (the same “delete duplicates applies to all xml changes, so I’m going to stop mentioning it).

<connectionStrings>
<add name=”SQLConnectionString” connectionString=”data source=<SQL Server>;Integrated Security=SSPI;Initial Catalog=ASPNETDB” />
</connectionStrings>

Now, in between your <machineKey …> and the </system.web> insert the following.

<roleManager enabled=”true” defaultProvider=”c”>
<providers>
<add name=”c” type=”Microsoft.SharePoint.Administration.Claims.SPClaimsAuthRoleProvider, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c” />
<add connectionStringName=”SQLConnectionString” applicationName=”/” name=”SQLRoleManager” type=”System.Web.Security.SqlRoleProvider, System.Web, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a” />
</providers>
</roleManager>
<membership defaultProvider=”i”>
<providers>
<add name=”i” type=”Microsoft.SharePoint.Administration.Claims.SPClaimsAuthMembershipProvider, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c” />
<add connectionStringName=”SQLConnectionString” passwordAttemptWindow=”5″ enablePasswordRetrieval=”false” enablePasswordReset=”false” requiresQuestionAndAnswer=”true” applicationName=”/” requiresUniqueEmail=”true” passwordFormat=”Hashed” name=”SQLMembershipProvider” type=”System.Web.Security.SqlMembershipProvider, System.Web, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a” />
</providers>
</membership>

Alright, save it and we’re on to the Security Token Serivce’s configuration. This one is located at: C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\WebServices\SecurityToken\web.config by default. Here, we are going to insert this right in between your </system.net> and </configuration>, but if you already have a <system.web> category in this section, please be sure to copy your <machineKey… > entry from the old system.web and put it into this new one (then delete the old).

<system.web>
<roleManager defaultProvider=”c” enabled=”true” cacheRolesInCookie=”false”>
<providers>
<add name=”c” type=”Microsoft.SharePoint.Administration.Claims.SPClaimsAuthRoleProvider, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c” />
<add connectionStringName=”SQLConnectionString” applicationName=”/” description=”Stores and retrieves roles from SQL Server” name=”SQLRoleManager” type=”System.Web.Security.SqlRoleProvider, System.Web, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a” />
</providers>
</roleManager>
<membership defaultProvider=”i”>
<providers>
<add name=”i” type=”Microsoft.SharePoint.Administration.Claims.SPClaimsAuthMembershipProvider, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c” />
<add connectionStringName=”SQLConnectionString” passwordAttemptWindow=”5″ enablePasswordRetrieval=”false” enablePasswordReset=”false” requiresQuestionAndAnswer=”true” applicationName=”/” requiresUniqueEmail=”true” passwordFormat=”Hashed” description=”Stores and Retrieves membership data from SQL Server” name=”SQLMembershipProvider” type=”System.Web.Security.SqlMembershipProvider, System.Web, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a” />
</providers>
</membership>
</system.web>
<connectionStrings>
<add name=”SQLConnectionString” connectionString=”data source=<SQL Server>;Integrated Security=SSPI;Initial Catalog=ASPNETDB” />
</connectionStrings>

Now, you can save this file and go to your site you created earlier. You will log in with Windows authentication, this time and then in site permissions, add the test user you created in Visual Studio earlier to the site with whatever permissions you like. Or, add the two roles (standard & superuser) with the rights you want them to have. i.e. add the “standard” role from SQL to the site members group in Sharepoint. This will all depend on your group and permissions structure.

An important note, the people picker normally can search partial names to find users in AD, but for FBA, it cannot do the search for user and group names. If your user/role is named “test1″, you cannot enter test and let it check namees to search for it. You need to type the full name in, then click check names and it should show that the name either came from active directory or your FBA database. Below, I show how you can tell whether it sees the users from FBA DB. I have two accounts with the same username in SQL and in AD. people p[icker will show you which it is like so:

FBA_vs_AD

Now, sign out of the sharepoint site and try to sign in using the user account from forms auth db. Should be good to go.

So, now your site is working for claims-based authentication, but there are some other disclaimers about things I ran into along the way. Hopefully, these extra little nuggets save you some time.

First, you may receive an error like so when using FBA or resetting passwords:

You must specify a non-autogenerated machine key to store passwords in the encrypted format. Either specify a different passwordFormat, or change the machineKey configuration to use a non-autogenerated decryption key.

See this MSDN article for information on Machine Keys. Honestly, you will most likely just want a key that you can use for your site. This auto-generater may help.

Also, you will see that when you try to access .NET Users or .NET Roles via IIS manager, you will get this error and not be able to manage users:

This feature cannot be used because the default provider type could not be determined to check whether it is a trusted provider.

You can use this feature only when the default provider is a trusted provider. If you are a server administrator, you can make a provider a trusted provider by adding the provider type to the trusted providers list in the Administration.config file. The provider has to be strongly typed and added to the GAC (Global Assembly Cache).

The provider can be added to the trusted assemblies by adding the following line to your <trustedProviders> section in the following file: C:\Windows\System32\inetsrv\Config\administration.config.

<add type=”Microsoft.SharePoint.Administration.Claims.SPClaimsAuthMembershipProvider, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c” />

However, due to a glitch in IIS 7, this will still not allow you to manage the users via IIS. See this post for information on trustedProviders.

Now, you have the issue of trying to manage users in the SQL db. You can access the users that are in the database from sharepoint and grant them permissions, but you cannot actually add roles or users to the SQL db. Here is where I simply point you in the right direction, but have a little less detail. You can, for now, use Visual studio to open the web site that sharepoint created and go to the website menu, then ASP.NET Configuration and create more users/roles as we did with the first one, but this can be a pain for regular use.

Also, this video is pretty short and has some good info on ASP membership, if you are fairly new to it.

Finally, for our site, we made a page with this createuserwizard for user addition and there is definitely a lot that you can do with the basic wizards, but it may help, as most likely if you are using this form of authentication, users will be registering themselves for the site anyway. This wizard is a basic template for registration for your users. Maybe not ideal when we go to production, but it works to et things going quickly for dev. Good luck!