Tag Archives: SharePoint

SP2010: The hidden TaxonomyStaplerFeature

Leave a reply

I am a big fan of keeping things clean. The more you clutter, the more chance of faults you might not have expected. Today, I learned that sometimes cleaner is not better.

I like using the blank site template to create new sites. Most people tend to use the team site, but that already has a document library, calendar and a number of preactivated features. Nice to start a team site, but what if the site you’re creating is not a team site?? As I said; I like starting clean.

But amongst the features not being activated by default on a blank site is a tricky one: the TaxonomyStaplerFeature (ID 73EF14B1-13A9-416b-A9B5-ECECA2B0604C). This is a stapling feature which in it’s turn activates multiple other hidden features. You need it for several taxonomy related things, like subscribing to content types from an enterprise content hub. And as said; the features are hidden, so you can only enable them if you have server access.

So I guess we’ll need another stapling feature, to staple the missing features to the blank site definition!? :-) I’m not sure yet if this is the only one which messes up pretty regular functionality. I don’t mind features I don’t use that often being off, but this one should have been on by default in my opinion. Or they could have provided another template: “blank site with no functionality whatsoever”.

SP2010: InfoPath, UserProfileService and 401 Unauthorized

Leave a reply

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:

  • InfoPath Services run browser based forms (problem does not occur client side).
  • The WebApplication is a claims based app.
  • Kerberos is configured as authentication mechanism.

Now here’s what you got to do to get this to work:

  • First, configure a Secure Store entry. If you don’t have a Secure Store setup, you need to get one, there’s enough info out there on how to do that.
  • Configure the entry as type Group with a Windows username and Windows password.
  • Set the credentials for the entry, make sure your user group has access to the entry. The account you configure will need rights to the user profile service application, so you’ll probably want to use a (dedicated) service account.
  • The account you specified needs rights to be able to actually use the webservice. This might be confusing, because all authenticated accounts have enough rights to open the WSDL. But that’s not enough when you want to use the service.
  • To set the correct rights, go to your Service Application management page, click the User Profile Service instance and choose ‘Administrators’ in the ribbon. Add the previously configured account. I chose to give it full rights, but you could fiddle a bit with which rights you actually need to perform the tasks requested.

 

  • Now create your data source in InfoPath and point it to the UserProfileService.asmx webservice (/_vti_bin/UserProfileService.asmx?WSDL). In our case, the GetUserProfileByName method was used to get the users’ details.
  • Because the service will be called as the SSO user, you need to delay loading because you need to set the username as a parameter. So don’t check the checkbox which asks if the data should be loaded as soon as the form loads.
  • Instead, go to the Data ribbon tab and click “Form Load”. Now configure two new actions, first “Set a field’s value”. Choose the username parameter for the webservice method and set userName() as the value (this is a function found under the User function category.
  • As second action, set “Query using a data connection” and set the form to query the webservice.

 

  • Return to your form and click “Manage Data Connections” in the Fields toolpane.
  • Convert your datasource to a data connection file. This file needs to be stored in SharePoint in a Data Connection Library. If you don’t have one yet, create it as you would create a normal document library (but choose the data connection library type instead, obviously).
  • The file will be created as a UDCX. The last step is to open up that file and look for this line: 
    <!--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.

  • Replace the above line with: 
    <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.

  • When you don’t use claims and you want to use Kerberos to delegate your user credentials, you need to check two more things. First, make sure you’ve configured local loopback checking and disabled it (either completely, or per URL).
  • Secondly, avoid double-hop issues by making sure the web front-end servers point to themselves. Do this by editing the hosts file and add records for 127.0.0.1 (hence the local loopback check) for the DNS addresses you use.
  • And to be complete; of course you need a valid Kerberos setup in that case. But you won’t be able to access your web application at all when you don’t, so that’s a different topic alltogether.

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!

 

SP2010: Whoops! I mirrored all of my databases…

Leave a reply

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:

  • Usage and Health Data Collection service application Logging database (typically called “WSS_Logging”)
  • User Profile service Synchronization database (Typically known as “Sync DB”)
  • Web Analytics Staging database (typically called “WebAnalyticsServiceApplication_StagingDB”)

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 = ""
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/

Update 24-5-2013: it seems the above script leaves you with a database reference for the WebAnalyticsStagingDB. This causes exceptions with health monitoring rules which check these references for good database health. This can be easily solved by running Get-SPDatabase, selecting the correct one and issuing a Delete() command on it. This will remove the reference, making sure the health rules won’t check it again. This only happens for that single database, it seems the other ones are being cleaned up properly.

SP2010: Saving yourself a full SQL license.

Leave a reply

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 ;-)

SP2013: SharePoint hosted app, getting to your lists

Leave a reply

As described in my previous post, a SharePoint app gets its own Web instance in which it lives. For the SharePoint engine, that means getting rid of your app is easy: just delete the web and everything is gone. The web gives you the option to deploy regular SharePoint stuff like lists and columns. But now that you’ve got your solution setup with a list; how can you reach it to add items? Continue reading →

SP2010: All SharePoint cloud scenarios

Leave a reply

Okay. It’s 2012. You’re hearing all this talking about the cloud and you’ve studied it a bit. Seems quite cool: no need for expensive hardware any more, no need for people carrying around servers, routers and firewalls. Signing up should be enough, right? Sure, if you know what you want and need. And that sometimes is a problem. In this post, I’ll try to list all the options you’ve got at this moment (mind you: the options will probably change over time).

Continue reading →

SP2013: The missing designer view in SPD

Leave a reply

Today I came across this thead on the forums, started by Marc Anderson; a well known MVP for SharePoint. He mentions the fact that SharePoint Designer 2013 is missing the “design view” known from SPD 2010. As expected, this is getting a lot of people nervous because they’re using the design view on a regular basis, for instance to tweak webparts like the Data View WebPart (DVWP). When the designer disappears, those tasks will become much more difficult and who likes difficulties, right?

I’ve post my reaction to the thread, but wanted to elaborate here too. Not so much as to start a discussion (see the thread for that), but more to get things straight as far as my view on this goes.

To begin with: as seen in my previous posts; SharePoint 2013 is all about apps. It’s clear that Microsoft is betting on us developers to go on and enrich their platform with integratable apps. This has some pro’s and con’s:

Pro’s

  • Apps are simpler than old style solutions. A simple app consist of HTML, JavaScript and CSS. Nothing more, nothing less. You can host as an ASP.NET app as well, but there’s nothing new to developing ASP.NET if you’re used to baking solutions.
  • Apps can be distributed through the marketplace, so it’s quite easy to make money. Much more easy than getting your WSP out there and making sure it’s not pirated in any way.
  • Because all of the interaction with SharePoint itself is being done via the CSOM (client side object model), SharePoint administrators will be more happy than they ever were. No more weird solutions damaging your farm, no more weird jQuery scripts doing unexpected things and breaking pages. If the app is faulty, you simply disable it and that’s that. Apps are of much smaller risk to your farm then (full trust) solutions.

Con’s

  • You need to learn the app model, that takes some time (but isn’t that hard at all)
  • You need to learn JavaScript if you didn’t know that already.
  • A power user is probably not able (or not willing) to create apps on their own.

That being said; I like the app model. I like the cleanness of it and the possibilities it gives us developers. I also understand that power users are being cut in their options of customizing SharePoint. But to be honest; I’m not sure if that’s a bad thing. Of course, on every ten power users there are always a few people getting it absolutely right, extending SharePoint in a good way. But there are also folks who… how to put this nicely… mess up your carefully build environment with weird scripts they found somewhere on the Internet.

Yes, you can disable SharePoint Designer alltogether to prevent that, but that would mean you don’t have a designer view either, right? :) And yes: you can put time and effort into training your power users on how to use Designer. That helps, but not always.

So should we eliminate the concept of the power user alltogether and let the developers solve every single thing? Most definitely not. But we should be careful in how much power a poweruser actually has.

And as I mentioned in my reaction on the topic; you don’t need to upgrade to SharePoint 2013 right away. Microsoft isn’t forcing you to go and use SharePoint Designer 2013 without the designer view. You’re perfectly fine when you stick to 2010 for a little while (how many of your customers are still operating 2007 for that matter?). And people are mentioning that SPD 2010 also works with SharePoint 2013, including the designer to build DVWP’s. So what’s the panic then?

I expect components for the app model will emerge soon, allowing you to get data into HTML tables without too much problems. There are already good ways to do stuff like client side databinding and what’s more configurable then plain HTML and JavaScript? It’s just a matter of acquiring the right libraries and knowledge.

Change. Some people like it, some people don’t. But getting to the future doesn’t go without it.

 

Disclaimer: I really hate dislike SharePoint Designer anyway. It’s unstable, dead slow, doesn’t do debugging and messes up my markup on a regular basis. So as far as I’m concerned, it’s dropped entirely and never returns again. But that’s coming from a Visual Studio enthousiast, just so you know. (Writing this, I realise this might change your view on this entire post… too bad :) )

SP2013: apps versus sandbox

Leave a reply

Hi SharePoint friends! It’s been a while. The last few months I was changing jobs (more about that in a seperate blog post) and taking vacation. Just before that, Microsoft released the first bits of SharePoint 2013. As is the case with 2010; this new version comes in two flavours: an on-premise installed version for which you need a server, and an online hosted version within Office 365, which is offered as a service. As we developer have become used to: development options differ.

I’ll leave the normal solution building to what is was for now, since that’s not the most eyecatching change. Then what IS, you ask? Apps! Since a few years, the terms “apps” is hot and happening, so Microsoft decided SharePoint and Office needed apps too. And they we’re probably right.

So, what exactly is a SharePoint 2013 app? I’m not sure if there’s an official definition out there somewhere, but here’s my view. An app for SharePoint is a solution (collection of files) which is meant to run client side; in the users browser. You cannot deploy server side code like codebehind, webservices, that kind of stuff. Where a sandboxed solution let’s you use a limited part of the server object model, an app only allows you to use the client side bits (i.e. the JavaScript ECMA model).

Update! There seems to be somewhat of a definition (found here): “So what’s an app? It’s best described as a solution that carries a light footprint and uses standards-based technologies such as HTML5, JavaScript, and OAuth.”

My initial response was: why would you want to build a solution with even less options as opposed to a sandboxed solution (which is already pretty limited and thefeore sometimes pretty annoying)? But after thinking about it twice, it might be even better than sandboxed solutions because of the extra limitations. I’ll try to explain why.

If you’ve ever tried developing solutions for Office 365 / SharePoint online, you know the limitations of the object model in the sandbox. Especially when you’re used to building “normal” onpremise farm solutions, these limitations are sometimes frustrating. You’re used to solving problems in a certain way and suddenly Microsoft decides your way of working isn’t going to work any longer. You need to find other ways of doing the same (which feels like a workaround to you), which takes time and learning. So a task which you already knew how to implement in a normal solution suddenly takes more time to build for the sandbox.

Because an app is fundamentally different, it doesn’t resemble a standard solution. The way of creating one is different, the goals are probably different, the tools are different (ok, you can also use Visual Studio of course). Being forced to use the client side bits, you start solving problems in a completely different way instead of using your standard object model knowledge. That’s a good thing.

Because of the client side, disconnected nature of apps, you’re forced to implement asynchronousity in a proper way. I don’t like doing async stuff in JavaScript (scripts easily get bloated and unreadable), so for Sandboxed solutions I tended to just write some server side code for stuff which I probably should have better handled client side instead. I still don’t like async stuff, but now I’m forced to do it and I’m forced to do it in a proper way if I want to remain writing maintainable code. The skillset for writing apps differs from my current skillset. So I need to learn how to do it properly using JavaScript. And was about time I did :)

I’m not sure yet how much time I’m going to be able to put into SharePoint 2013 the coming months. But I’ll definitely share some insights and hopefully code here. Towards the end of November I’ll be attending the Dutch SharePoint conference, which will probably feature a lot of SharePoint 2013 content. So stay tuned; there’s more to come!

SP2010: Security risk using “all users” in a multi tenant environment

Leave a reply

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.

 

SP2010: Aggregating tasks with search

Leave a reply

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 →