This is a topic which comes up more then once when you’re working with the content deployment feature. For those of you unfamiliar with content deployment; it’s basically a process to import and export a site collection in an automated way, across farms if you like to.
But content deployment is a tricky process in which a number of things can go wrong. Most of the solution I’m going to mention are not new, but I could not find a blog which combines them all, so that’s wat I did.
The last few days I was working on a problem reported by a user using InfoPath Service. A browser based form had to connect to the UserProfileService.asmx webservice in order to read some profile data to populate a form. This was working untill the web application was switched to claims based authentication. After that change, the webservice stopped working and (401) Unauthorized errors occurred in the logs.
It took me quite some time to find a stable solution, and you need to check for several things. I though I’d share this solution for others to use.
First, this is how our environment is configured:
Now here’s what you got to do to get this to work:
<!--udc:Authentication><udc:SSO AppId='' CredentialType=''/></udc:Authentication-->
Without authentication set, InfoPath will perform the call as an anonymous user, which results in the (401) Unauthorized exception.
<udc:Authentication><udc:SSO AppId='YourSSOAppId' CredentialType='NTLM'/></udc:Authentication>
Now you’re telling InfoPath it needs to query the configured SSO service application, retrieve the credentials stored for application ‘YourSSOAppId’ and use them to query the webservice. And because you’ve configured an account which you added to the User Profile Service Application, this account will have enough rights to perform the request.
That’s it! With these steps you should be able to use the built in UserProfileService.asmx webservice in a claims (or classic) based web application from within InfoPath forms. Good luck!
So you’re building a SharePoint farm which has to have a high percentage of availability. And to get that, you decide to make your databases highly available by the techniques offered by SQL Server. Think mirroring, or AlwaysOn if you’re using SQL2012. Which technique you’re using doesn’t really matter; you have to realise that this is not supported for all databases!
The good news; the databases which don’t support mirroring aren’t vital to keeping your sites up. It’s these three:
Also note that search databases don’t have to be mirrored, because search has it’s own high availability mechanism. It’s doesn’t matter though, when you do have then mirrored. It’s just not nessessary.
Ok. But you didn’t consider this when you were building your farm. Eventually, you’ll run into problems; most likely when applying updates to your farm. These will fail with the message that mirroring is not supported for your databases. So then what?
Well, just use this Powershell script below and you’ll be able to change the alias for the databases which don’t support mirroring. Make sure that you first create the alias on all of your farm servers!
$alias = "sql-alias"
$uh_name = "Usage and Health Data Collection"
$uh_database = "SP2010_UsageAndHealthDB"
$wa_name = "Web Analytics Service Application"
$wa_database = "SP2010_WebAnalyticsStagingDB"
$up_name = "User Profile Service Application"
$up_database = "SP2010_UPSSyncDB"
Write-Host "Changing the database server for $uh_name"
$uh_app = Get-SPServiceApplication |? { $_.Name -eq $uh_name }
Set-SPUsageApplication -Identity $uh_app -DatabaseServer $alias -DatabaseName $uh_database
Write-Host "Changing the database server for $wa_name"
$wa_app = Get-SPServiceApplication |? { $_.Name -eq $wa_name }
$stagingDbs = "<StagingDatabases><StagingDatabase ServerName='$alias' DatabaseName='$wa_database'/></StagingDatabases>"
Set-SPWebAnalyticsServiceApplication -Identity $wa_app -ListOfStagingDatabases $stagingDbs
Write-Host "Changing the database server for $up_name"
$db = Get-SPDatabase |? { $_.Name -eq $up_database }
$db.ChangeDatabaseInstance($alias)
Source for non supported databases: http://mmman.itgroove.net/2012/03/some-databases-are-too-ugly-for-the-mirror/
As I’m studying for Microsoft SharePoint certifications, I came across the “Remote BLOB Storage” topic. It’s an interesting technique, allowing you to store BLOB files (documents, videos, images, etc.) outside of SQL Server. The main reason why you’d want to do that is performance. SQL doesn’t handle those BLOB things that fast and they fill up your database. So you turn on RBS, files are stored on disk and everyone is happy again.
But there’s another opportunity RBS gives you. At the moment, my job involves the larger enterprise farms. But I have seen a lot of single server SharePoint installations as well. Many companies starting off with SharePoint Foundation out of budgetary reasons: keep listening. SQL Express is the “light” version of SQL. It’s pretty well featured, it’s 100% supported running SharePoint on top of SQL Express. One disadvantage is the 10GB database size limit. You reach that, you need to pay.
But using RBS / FILESTREAM in SQL Express, your files won’t be stored in the content database any longer. And the documentation clearly states:
SQL Server Express supports FILESTREAM. The 10-GB database size limit does not include the FILESTREAM data container).
That stretches the limits on the SQL Express scenario’s quite a bit! And it only takes a little bit of configuring. So when you want to postpone buying those expensive SQL licenses a bit more; check out RBS! For a normal intranet SharePoint farm in a small company, your databases won’t reach 10GB very soon. The only one you probably need to watch when storing a lot of documents is search.
Should you feel like sending me a small percentage of the money you just saved yourself, you’re quite welcome to 
I came across what I find to be a pretty big security risk when you’re working with multi tenant SharePoint environments.
Basically, it’s pretty simple. When you set up your environment and create a tenant, you have to specify the OU in which the accounts for this tenant live. This makes sure that your users cannot see accounts belonging to another tenant and vice versa. But you should be very aware that this filtering is only affecting stuff like the people picker. It’s not limiting access to your sites!
You might be used to granting all users access by using the “All users” groups found in the people picker. All users means: all users with a valid account. This is not limited by OU, it’s literally everyone!! So when you’ve got tenant A and tentant B setup, and you grant access to “All users” on a site belonging to tenant A, all users from tenant B will have access too.
This is most dangarous when you’ve got site administrators editing permissions on their sites and not realizing that they’re in a multi tenant environment. They might be tempted to use the all users group and not realise that this severely compromises security. Sure, the users of tenant B might not know that they’re in a multi tenant environment. And they probably don’t know the URL of tenant A’s sites. But still, you don’t want to grant access to users you don’t want on your site.
Ok so what are ways around this?
Your membership provider has an attribute called “userContainer“. This can be used to limit the scope in which the provider searches for users. That way, users belonging to a different OU won’t be validated and thus won’t have access to the site. A problem with this approach is that your own administrative accounts might not be in the tenants OU and thus lose access to the site as well. So you need to create extra admin accounts for each tenant.
When using a custom login page, you could implement your own code which checks for the OU the user belongs to. That way you could also allow your own administrative accounts (in a seperate OU) to have access. It requires some coding, but does the trick quite nicely.
As far as I know, those are your options. But feel free to leave other solutions in the comments below.
Ok. This is quite a common scenario. You’ve got your SharePoint site setup which consist of multiple webs, maybe (probably) even multiple site collections. Your user is member of a handfull of sites and get’s tasks assigned. You need your user to stay informed about the tasks he needs to perform. You’ve got a couple of options.
First, I would enable the “mail when task is assigned” option on your task list. This will notify the user a new task has been assigned. Also, with some workflows like approval / feedback request, you get automatic notifications when a task is due. Nice. But your users will start overlooking these mails, or just plain ignoring them. They start requesting an overview of all tasks assigned to them.
Now you’ve got multiple options. Waldek Mastykarz has got a nice post about using the Content Query Webpart to show info from subwebs. Works great, but the content query webpart is limited to the current site collection. Also, it’s proven to be hard for novice users getting the XSL right.
So what about a cross site collection option which is easy to configure? There are a few options, third party solutions probably being the best. For instance, there’s Lighting Tools with their conductor webpart, or Bamboo Solutions with a list rollup webpart (links are not sponsored by the way).
But wait! There’s an out of the box options you might want to consider: search! Using the default webparts (you will need SharePoint Server or Search Server Express for this), you can quite easily list all tasks assigned to the current user. It does require a tiny little bit of coding. Let’s get started!
Continue reading
Having one of the following two problems?
1) Grouped views not working properly when you’ve selected a BCS / External data field as the group field
2) Column filtering not working properly for BCS / external data fields
But these problems seem to be inconsistent, some records work and others don’t? Chances might be that you’ve selected a field for which the values contain newline characters. This consistenly brings problems with grouping and filtering. The best option you’ve got is just to eliminate newlines in your datasource. Using SQL? Then this will do: REPLACE([column], CHAR(10), ‘ ‘).
Today we ran into a weird problem. People reported not having access to their personal documents library on their MySite. So I checked, the Personal Documents library ACL was empty for that particular user. But for other users, I noticed where were some entried, just not their own user account and always Limited rights (which means a document or folder inside the library probably has custom rights).
So what was happening? Well, I checked some more and noticed that all sites had an empty Site Administrators box (Site Settings -> Site Collection Administrators). Normally, the users account would be in there because you are always an administrator of your own personal MySite. Why those were cleared, I’m still not yet sure. But luckily, this is quite easily fixable with a short Powershell script. So I thought I’d share it here for anyone who might run across the same problem.
$wa = Get-SPWebApplication "https://www.sharepoint.com"
foreach ($site in $wa.Sites)
{
if ($site.Url -match "https://www.sharepoint.com/mysite/")
{
Write-Host Updating $site.Url
$user = $site.RootWeb.AllUsers[$site.Owner.UserLogin]
$user.IsSiteAdmin = $true
$user.Update()
}
}
Since the site.Owner property still points to the correct user, this script simply takes that user; finds it in the AllUsers collection, sets the IsSiteAdmin property to true and saves the changes. Et voila; all users can acess their libraries again.
One of our environments is one that was upgraded from MOSS 2007. In that transition, BDC changed to BCS and we didn’t really take care of that because we weren’t using BDC that much. One of the lists got migrated and stopped working, but because it was in a dark alley on our SharePoint site, no one really noticed. Untill last week, when one of our users tried to use it to discover all he was getting was errors. Hmmmm.
Continue reading
I spent quite some time today on a question I was asked. In an existing solution, we added a custom action (button) to the standard menu (the dropdown menu on your account name in the right upper corner of a site). This button was a “Add site to favorites” custom solution. The request was: can we move that button to the same place the default “I Like it” and “Tags & Notes” buttons are? I didn’t think that this would be such a problem. But I was wrong due to my good friend: the Sandbox. Continue reading