| Hello everyone. I know the blog has been offline for several months. I decided to bring it back and move it over to SharePoint 2013. I am still experimenting with some things (blog site vs publishing site for SEO reasons, perms for anon commenting, tweaking cache, etc) so please be patient while the site undergoes some reworking for a month or so. My categories were a bit jumbled in the move over, as well as unpublished posts from the previous WordPress blog coming over as published posts. I am still trying to clean everything and reorganize that as well. Anyway, thanks for your patience and I hope you enjoy the new site once its all done and dusted. |
|
So, recently I had a list where we needed to remove a couple of columns but couldn't do it using the normal browser UI. They were site columns that were added to the list. The column needed to be removed and I was having a hard time figuring out how to do it without just deleting and recreating the list (which had several thousand items). This little bit of PowerShell allowed me to remove the column:
$web = Get-SPweb https://portal.contoso.com/sites/app_us_strategy/scorecard
$list = $web.Lists["Shared Documents"]
$field = $list.Fields["Privacy Classification"]
$field.AllowDeletion = $true
$field.update()
$field.Delete()
$list.Update()
$web.dispose()
I tried this on several lists (for some reason had several requests to delete columns like this in the same night), and the $field.update() was not required the first time, but it was the subsequent attempts. I would recommend just keeping it in there.
Now, if this is a content type you are removing the column from, try the following:
$web = Get-SPWeb http://portal.contoso.com
$contentType = $web.ContentTypes["PIR Request"]
$field = New-Object Microsoft.SharePoint.SPFieldLink ($web.Fields["Variations"])
$contentType.FieldLinks.Delete($field.Id)
$contentType.Update()
$web.Dispose()
Now, there is a slight catch once you delete the column from the content type.the content type has children, you will have to delete if from the children using the same script. Kind of a pain to run through it again, but shouldn't take much to modify it for the other types.
The final caveat is that the lists content types were attached to still have the column added to them. I was lucky in that there were only a few lists where I even had to bother with this and I simply used powerShell to update the lists individually. If all your lists based on the same content type use the same name or some other similar identifying aspect, you could always try to iterate through the lists to update them at one go, like so:
$site = Get-SPSite http://portal.contoso.com
$site | Get-SPWeb -Limit all | ForEach-Object
{
$list = $_.Lists["PIR Requests"]
$field = $list.Fields["Variations"]
$field.AllowDeletion = $true
$field.Update()
$field.Delete()
$list.Update()
}
Took a bit of digging on the SPList class and content types to find this, so hopefully it helps some of you to take care of this quicker than I did. |
|
So, this is a pretty common thing to run into, so I thought I would put a workaround for both 2007 & 2010 in one place.
You are trying to save a site (with content) or list to a template in SharePoint, but it gives you this error:
The list is too large to save as a template. The size of a template cannot exceed 10485760 bytes.
To adjust this in SharePoint 2007 is pretty easy. This quick little stsadm command will allow you to adjust this (you need to be in 12-hive to run any stsadm commands or have it in your path; "C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN"):
stsadm -o setproperty -pn max-template-document-size -pv 524287999
The size above is in bytes and will change to allow you to save sites/lists as templates up to 500MB (approx.). Now, there is a hard limit of 524288000, and if you change the size to above that value, it will cause your templates to fail to save every time. Just remember the default size is 10MB (10485760).
In SharePoint 2010, the stsadm command doesn't always work (I believe it no longer works after SP1, but I don't know for sure), so instead we can use PowerShell, which works for SP 2010 no matter what patch level you're at. Also, to note, the default size and the maximum size for 2010 is the same as 2007. Either fire up SharePoint Management Shell or if you plan to script, start with
Add-PSSnapin Microsoft.SharePoint.PowerShell
Then, on to the fun stuff:
$intTemplateSize=524287999
$svcWebService= [Microsoft.SharePoint.Administration.SPWebService]::ContentService
$svcWebService.MaxTemplateDocumentSize = $intTemplateSize
$svcWebService.Update()
There you go. Now, whether in 2010 or 2007, you can blow your template size limit up to 500MB.
|
| So SharePoint 2010 has tried to make restores quicker by including the ability to pull data out of unattached content DBs, but they have certainly added their best feature yet with the new PowerShell commands. Now, just remember, these will only be available in your SP 201o SP1 farms, not pre-SP1:
Alright, so let's say you have a user who deleted a site collection and you need to restore it. Instead of a new SQL DB and browsing it unattached, or attaching it to another farm, we can simply skip that time-consuming step altogether.
Open up PowerShell, either the SP 2010 Management Shell or if you end up making a script with this, get used to including this at the top:
Add-PSSnapIn Microsoft.SharePoint.PowerShell
The deleted site collection is at http://intranet.contoso.com/sites/tlsc_2010.
Now, Get-SPDeletedSite has some nifty switches to allow you to limit the deleted collections you want to view. If you run the command with no switches, it will simply show all the site collections that were "deleted" from SharePoint, no matter what the web app, db, or URL. You also have to option to specify only one Web Application, or Content DB to view deleted sites from. Below is the most effective way I have found to quickly bring them back:
Get-SPDeletedSite | where {$_.path –eq "/sites/tlsc_2010”} | Restore-SPDeletedSite
Now, the thing to remember is that this command uses the relative URL, notice it starts with /sites. You can always just run Get-SPDeletedSite and change the query to:
Get-SPDeletedSite | where {$_.path –like "*tlsc_2010*”}
Then, verify that the site coll. you want is listed and do the Restore- command with the GUID of the collection you want.
|
| 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. |
| 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. |
| 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. |
| So I ran into an interesting issue recently. We had a SharePoint 2007 installation with a calendar list. The end users sync the calendar to their Outlook as a shared calendar. All of the client computers running a variety of Windows XP, Vista, and 7 with Outlook 2003 & 2007.
NOTE 9/14: This process can help to resolve several sync issues between Outlook and SharePoint Calendars. If you are receiving Failed to copy one of more items because some are not compatible with SharePoint error or somethign different, this may still be something to check out.
The issue we ran into was when a user would update an event, whether they did it via Outlook or SharePoint, not all of the fields would update. The new description, title, modified by, modified date/time, and event date/time would show correctly in the SharePoint calendar, but the user's Outlook would not have the proper modified by & modified date/time. This may not seem like a big deal at first glance, but the root cause of this issue can cause other sync issues as well, in case you're hunting some down.
There were no error codes during the Outlook send/receive, no errors in SharePoint, and nothing in the sync issues folder in Outlook so it definitely took me a while to find anything on this. I finally got to the point where I decided to open the SharePoint list in Access. By doing this, you can look for corruptions in the list or just anomolies.
In order to view the list in Access, you need to be viewing the list from a machine that has Access installed on it. Then, make sure your view is showing all list content and click Actions> Open in Microsoft Access. You will want to create an active link so you can edit the list from Access. Once you have it open, look for anything that looks improperly formatted. I did not find anything that looked corrupt, but I did notice that there were several items that did not have a title. I went back and checked the list's required fields. Start Date, End Date, and Title were all set to required.
So, how did this happen? It was most likely just a user error, but the problem is that when users create an appointmentin the calendar via Outlook, Outlook does not enforce the rules you put on the SharePoint list. So, to resolve, all I had to do was remove those items that didn't meet the rules for required fields (or you can simply modify them to meet your rules, if you'd prefer). Then, just have users do another send/receive and it should resolve. Although there were a couple users who were still having issues. The only thing you need to do if they still have issues is remove the calendar from their Outlook and have them recreate the connection.
To do that, in Outlook, go to Tools > Account Settings >SharePoint Lists tab > then remove the calendar. Then, have them go to the calendar in SharePoint and click Actions > Connect to Outlook. They should be good to go.
Hopefully this helps resolve some sync issues for you all. Feel free to comment if you have any other sync issues or questions. |
| In one of the environments I work in, we have a SharePoint 2007 server on Server 2003. Recently we applied our June Windows patches and the April cumulative update (CU) packs for WSS 3.0 ( http://support.microsoft.com/kb/2512783) & SharePoint 2007 ( http://support.microsoft.com/kb/2512782). As a note, if you aren't patching your SharePoint with the CUs as per this site, I would highly recommend a change. Check out the site and decide for yourself. Anyway, after patching I had users complaing of certain menu items disappearing. Namely, the "Settings" options for just about everything. I went in to check it out and noticed the "Site Settings" was gone from the site menu even though I am the site collection administrator. I was able to get to it via the direct url (<site url>/_layouts/settings.aspx), but things were not quite right. I also noticed I could not modify permissions for the site collection.
Everything seemed to be functioning as far as the site would display for users, noone was denied access, they just weren't able to modify workflows or lists or anything. I also found it strange that it was only affecting 1 site collection of 1 web application on the server. I ended up discovering that the site was set in readonly mode. The content DBs are locked during patching and backups, sometimes if the process is interupted they can remain locked afterwards. The way to check whether there are any locks on any of your sites is via this command (remember to change your prompt to the 12-hive, C:\Program Files\common files\Microsoft Shared\web server extensions\12\BIN):
stsadm -o getsitelock -url http://server_name
If it returns anything other than "none", something is locked. Now, remember, if you are during backup/patching timeframe, someone else may be doing something that requires a db lock. In order to release all locks on your server and return to normalcy, run this command:
stsadm -o setsitelock -url http://server_name -lock none
Now, you should be good to go. If you notice lingering issues, or anything different, let me know. I'd be glad to help look into it. |
| 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.
[caption id="attachment_298" align="alignnone" width="550" caption="Creating new website in Visual Studio 2010"]  [/caption]
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:
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:
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:
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!
<membership defaultProvider="SQLMembershipProvider">
<providers>
<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> |
Compliance Details javascript:commonShowModalDialog('{SiteUrl}'+
'/_layouts/15/itemexpiration.aspx'
+'?ID={ItemId}&List={ListId}', 'center:1;dialogHeight:500px;dialogWidth:500px;resizable:yes;status:no;location:no;menubar:no;help:no', function GotoPageAfterClose(pageid){if(pageid == 'hold') {STSNavigate(unescape(decodeURI('{SiteUrl}'))+
'/_layouts/15/hold.aspx'
+'?ID={ItemId}&List={ListId}'); return false;} if(pageid == 'audit') {STSNavigate(unescape(decodeURI('{SiteUrl}'))+
'/_layouts/15/Reporting.aspx'
+'?Category=Auditing&backtype=item&ID={ItemId}&List={ListId}'); return false;} if(pageid == 'config') {STSNavigate(unescape(decodeURI('{SiteUrl}'))+
'/_layouts/15/expirationconfig.aspx'
+'?ID={ItemId}&List={ListId}'); return false;}}, null); 0x0 0x1 ContentType 0x01 898 Document Set Version History /_layouts/15/images/versions.gif?rev=23 javascript:SP.UI.ModalDialog.ShowPopupDialog('{SiteUrl}'+
'/_layouts/15/DocSetVersions.aspx'
+ '?List={ListId}&ID={ItemId}') 0x0 0x0 ContentType 0x0120D520 330 Send To other location /_layouts/15/images/sendOtherLoc.gif?rev=23 javascript:GoToPage('{SiteUrl}' +
'/_layouts/15/docsetsend.aspx'
+ '?List={ListId}&ID={ItemId}') 0x0 0x0 ContentType 0x0120D520 350
|
Christopher Webb
|
| I am a SharePoint Architect living in the DFW area. I am a father and currently working as a Senior Microsoft Engineer with Planet Technologies. |
|
