Joel's Space - SharePoint - MOSS and WSS Tips and Consultancy Tales

You can now find us on iTunes as “joelblogs tv” :o) and also on blip.tv.

Welcome to the second in my SharePoint 2010 series of how-to videos for developers. This one is all about Business Connectivity Services, the technology previously known as the Business Data Catalog.

The BDC in SharePoint 2007 was pretty cool. It allowed us to quickly create read-only forms from existing line of business, or back-end, systems. The technique also allowed us to index and then search data in these back-end systems in a structured way.

In this video, I'll show how easy it is to work with SharePoint 2010 Business Connectivity Services. We'll use SharePoint Designer 2010 to hook up with an old friend - the Northwind database - and bring a SQL table of Contacts into SharePoint.

We'll also see how SharePoint does the hard work for us in creating not just read only, but all the CRUD operations - create, retrieve, update, delete. It also creates InfoPath and browser forms for us, without writing a single line of code. Lastly we'll have a look at the offline functionality of the BCS and SharePoint Workspace, including the magic of conflict resolution.

It’s been my pleasure over the last few weeks to teach SharePoint 2010 to an audience of developers for Microsoft during their Ignite event in Dublin.

One of my favourite features of the news development platform has got to be Sandbox Solutions and the User Code Service. This allows developers to write code, packaged up as a SharePoint .WSP solution, and deploy it at the site collection level in a security sandbox. This feature is aimed at hosted and multi-tenant SharePoint customers, and also the incredibly security conscious.

In this video walk through, I shows developers how to create a simple Microsoft SharePoint 2010 Sandbox Solution in Visual Studio 2010, I show what works and what doesn't inside the Sandbox, and lastly how to write a custom validator for other developers' solutions.

This happened to me on a client site. In slow motion. One of those “noooooooo……!” moments. “Not *that* one!!!!!”

“Stop and start the W3SVC.” That’s what I meant. I’m sure that’s what I said. But my colleague stopped and started the Windows SharePoint Services Web Application service instead.

Popular Misconception #1: I can stop and start the Windows SharePoint Services Web Application without any severe implications.

If you backup your IIS metabase, then yes. You *do* do that, don’t you? No? Damn. We’ve got some work to do then. Here’s what happens.

This is IIS before stopping the WAS. Note a healthy sufficiency of IIS Sites to host my manifold Web Applications:

So, let’s try this out. I’m going to navigate to Central Administration –> Operations –> Services On Server. Now I’ll find the Web Application Service and click “Stop”.

Note how it asks me to confirm that is what I want it to do:

So, I hit “OK” and sit back and await the carnage. Here’s what’s left in IIS when the service stops.

Which brings me to other misconceptions:

Popular Misconception #2: The Windows SharePoint Services Web Application is just a normal service, I can surely just hit “Start” and everything will be back to normal?

and

Popular Misconception #3: SharePoint memorises all my web.config changes when it backs up and timestamps them…?

Alas, no. SharePoint can only restore things that it configured in the first place. So when you edit settings in Central Administration, and configure Authentication Providers, yes. It can restore those. But for other things. like custom web.config edits, custom permissions, or virtual directories, you have to create those yourself.

Popular Misconception #4: So, the Web Application Service is a complete liability then?

No. Not at all.

The Web Application Service has a purpose. This is to allow all your front-end web servers to maintain the same collection of IIS Sites to host their SharePoint Web Applications extended into their corresponding Zones. When a new Web Application is created, or one is extended on one of your Web Front End servers, the Web Application Service running on all the others in the farm make sure the IIS Sites are mirrored across the whole farm.

It’s just not designed to take your customisations with them. (So try really hard not to make any!)

So, given this is so significant, why doesn’t SharePoint warn your more insistently?

Here’s a more suitably worded dialog you get when doing something similar in IIS – this time I’m restoring the IIS Metabase over the top of any existing IIS Sites:

Something along those lines would help enormously.

So, as an alternative to having to figure out yourself what to recreate, I highly recommend backing up not just the whole metabase, but individual IIS Sites. This can be done painlessly through IIS Manager, by right-clicking a Site and choosing All Tasks –> Save Configuration to a File…

Popular Misconception #5: I get the picture – I should never touch the Web Application Service then?

When you install SharePoint on a server as a Complete Install, it won’t start this service by default. You’ll have to decide to do that. You don’t need it for SSPs and Central Administration sites. And sometimes you want to change the role of one of your servers. Or sometimes you want to consolidate your usage of Application Pools among your Web Applications. So then you may want to stop the service… but tread carefully.

Lastly, check the IIS Metabase Backup and Restore history before you write it all off. If you’re very, very lucky you could have an Automatic Backup just before you hit the switch. :)

There is a moral to this story: back up your stuff. All of it. Always.

Thanks for reading!

In this blog post, I’m going to try and address a few misconceptions about SharePoint AAMs, Web Apps and Zones.

Popular Misconception #1: I create a new Web Application for my Intranet site, then to expose it to my Extranet audience I just set up an Alternate Access Mapping Public URL for the Extranet Zone.

Nope. Not really. There’s quite a few moving parts involved.

Web Applications map on to one or more IIS Sites. When you create a Web Application, you get your first IIS Site for it (IIS Site #1 above) and it creates a mapping called the “Default” Zone. You can then administer Authentication Providers for your Web Application and tell SharePoint how you want your IIS Site and Default Zone to authenticate users:

• Windows Authentication
• Forms Authentication
• Web Single Sign On

Typically, the Default Zone will be used for local machine-name/domain-name access to a site, e.g. http://server1 or http://intranet. But this really is entirely up to you what Default means. If your intention is to take your Web Application and also expose it via https as intranet.mycompany.com, then you need to “Extend” your Web Application (Central Admin –> Application Management –> Create or Extend Web Application) into a Zone (say, for the sake of the argument, “Extranet”) and give it a Load Balanced (or Public) URL of https://intranet.mycompany.com. Then you can edit the Extranet Zone under Authentication Providers, and enable SSL.

Note: you probably need to make sure all the domain names you use exist in some DNS server somewhere, and that you can resolve them properly.

Popular Misconception #2: Alternate Access Mappings are just host headers. I can just add Internal URLs for each host header I want to support in a Zone, and it’ll just work.

Ah, no. Two problems here:

1. When you add an Internal URL, it doesn’t automagically configure the Bindings of your IIS Site for you. You’ll need to check that these exist on your Site for in IIS Manager.
   
2. This is a fundamental misunderstanding of what Public URLs and Internal URLs are for in AAMs. You have one Public URL per Web Application per Zone. When any user visits a page via that Web Application and Zone, any resources (images, scripts etc) mentioned in the body of the returned HTML of pages, will have hard-coded links to the resource under the Public URL. If you add an Internal URL for someone to use from outside the LAN, all the resources on that page will still be hard-coded to use the Public URL; in other words they’ll get broken images.
   

   

Which brings me to a pair of misconceptions about Zones in SharePoint.

Popular Misconception #3: Default Zone, Extranet Zone, Intranet Zone, Internet Zone and Custom Zone have specific meanings. I must choose carefully when I extend my Web Applications!

And…

Popular Misconception #4: Default Zone, Extranet Zone, Intranet Zone, Internet Zone and Custom Zone have no specific meanings. I can choose whatever I like when I extend my Web Applications!

Neither of these extreme views is entirely correct. In fact, you are free to choose. None of these Zones has any intrinsic meaning. A Zone will let you specify a Web Application’s authentication provider, encryption and access details and the collection of URLs that can be used to access the content. The important thing is this: if you decide to use the Intranet Zone to mean SSL access to your Intranet Web Application, then you should use the Intranet Zone to mean the same thing for other Web Applications.

I’ll give you a “for example”: one of my students had some weird behaviour in her live SharePoint site. The My Site links on her Intranet worked OK inside the company firewall, but over HTTPS outside the firewall, links to My Site were not generated using HTTPS. This is how things were set up:

• Content Web App #1
  • Default Zone configured to allow requests from https//intranet.mycompany.co.uk
  • Intranet Zone configured to allow requests from http://intranet
• My Sites Web App
  • Default Zone configured to allow requests from http://mysite
  • Public URL for the Intranet Zone set to https://mysite.mycompany.co.uk

Two problems: there was no “Intranet” Zone for the My Sites Web App, and we’ve got Zones with the same name doing different things from each other in each Web App. We had to delete the Public URL for the Intranet Zone of the My Sites Web App, so we could extend the Web App into the “Intranet” Zone without errors and set the URL to http://mysite.mycompany.co.uk. We then set the Default Zone authentication provider to allow SSL.

• Content Web App #1
  • Default Zone configured to allow requests from https//intranet.mycompany.co.uk
  • Intranet Zone configured to allow requests from http://intranet
• My Sites Web App
  • Default Zone configured to allow requests from https://mysite.mycompany.co.uk
  • Intranet Zone configured to allow requests from http://mysite

So now things work as we expect them to: when you visit the main site at http://intranet, the My Site link is generated as http://mysite; and when you visit https://intranet.mycompany.co.uk, the My Site link is generated as https://mysite.mycompany.co.uk.

Thanks for reading!

Fun.

I recently had lots of fun with this at a client site. Especially if you redefine the dictionary definition of the word “fun” to some sort of diametrically opposed antonym.

The Platform

• Server A: Windows 2008, IIS7, MOSS 2007 SP1.
• Server B: Windows 2008, SQL 2005 SP2 with SQL Server Analysis Services.

The Task

Configure SQL Server Reporting Services (SSRS) for SQL 2005 SP2 on Server A in SharePoint Integrated Mode.

The Problem

There are SSRS Reports that access a SSAS Cube which uses ID of the current user as part of a filter. In other words, we must log into SSAS as the Windows Account of the current SharePoint user.

Why this Hurts

Default Windows Authentication (Negotiate/NTLM) cannot pass your credentials from one server to another. When you log into a web server, it knows who you are. When the server then has to log in to a database as you, it cannot send your credentials down the line to the next server. This is referred to as the “double hop” problem. It’s not a SharePoint problem, it’s a fundamental design constraint of N-tier systems since Active Directory has existed. It works OK on a single server environment, but when you deploy this to a production system with two or more tiers (i.e. a separate database) we hit the brick wall.

How to Get Out of It

There are generally two mainstream solutions (yes, there are others, I know!). My preferred solution, let’s call it “Solution A” is this:

• Don’t do it.

Seriously. If you’re designing your own applications, it’s frequently best practice to have a small set of (usually *one*) service accounts that you use for all server-to-server access. But that won’t work here. SSAS is not my application; the reports and analytics are not up for being edited. So we must take another choice.

Which brings me to “Solution B”, thus:

• Use Kerberos – the Greek Triple-Headed Hate-Dog from Hell.

How Kerberos Gets Round The Problem

Kerberos is an MIT-invented protocol for authentication developed in the 1980’s. It’s gone through many iterations, and since Windows 2000 it has been the default authentication method in Active Directory Windows installations. We want to use a Kerberos technique called “Constrained Delegation”.

With NTLM authentication, Server A would authenticate you, and your client would send a one-way hash of your credentials, called a “token”. Server A would then be unable to pass similar token to Server B, as it has no way of reverse-engineering your password from the token, to generate a token of its own.

Kerberos, however, works on a “ticketing” system. If we configure Kerberos correctly, then your client will send Server A a different kind of one-way hash of your password: instead this is a “ticket” with a time-to-live. That means if Server A is appropriately privileged in Active Directory, it can send your ticket on to the next server down the chain – i.e. Server B – if the ticket has not expired.

Kerberos Caveats

Kerberos ticketing is time-based, so it needs to have all the system clocks of all the participating machines in sync. There are a few other requirements:

1. The Key Distribution Center service should be running on your Domain Controller(s)
2. The Functional Level of your Active Directory should be set to Windows Server 2003 or above
3. Computer accounts for Server A and Server B need to be “trusted for delegation” in Active Directory Users and Computers
4. Service Principal Names need to be created for every service for which you want to allow delegation

Points one and two above are free if you’re running Windows 2008 Active Directories, which we were. So that’s all good. You should note that the default for a Windows 2003 Active Directory domain is to run in Windows 2000 Compatibility Mode. If you need to, you can raise this in Active Directory Users and Computers like this:

You can accomplish step 3 – trusting the computer accounts of Server A and Server B – through Active Directory Users and Computers –> Computers –> Server A, like this:

Step 4 requires some command-line action with a tool called SETSPN.EXE.

And that’s where things get tricky. Luckily for us, SETSPN.EXE comes with Windows 2008 Server. However, if you’re using 2003 you’re not going to be so lucky. You’ll need to download it from the Support Tools for 2003 Server.

Server Set Up

There’s a lot of moving parts going on here, so let’s have a look at how I intend to set some of this up.

DNS

• Server A
  • Primary IP address and FQDN of: SERVERA.JOELBLOGS.LOCAL
  • Secondary IP address and FQDN of: REPORTS.JOELBLOGS.LOCAL
• Server B
  • Primary IP address and FQDN of: SERVERB.JOELBLOGS.LOCAL

Active Directory

• Windows 2008 Active Directory Functional Level
• Our Active Directory Domain is called JOELBLOGS (or JOELBLOGS.LOCAL)
• Server A and Server B trusted for delegation
• Domain Accounts created for the main services:
  • SQL Server: JOELBLOGS\SQLAgent
  • Reporting Services: JOELBLOGS\SSRSSvc
  • SharePoint Database Access Account: JOELBLOGS\SPConfigSVC
  • SharePoint Content Web Application Pool Account: JOELBLOGS\ContentWebAppSVC

Service Principal Names

Putting it all together, here’s the commands I issued at a command prompt on my Domain Controller to create the relevant Service Principal Names for delegation to work:

What I Didn’t Do

Actually, I tried many, many things; some of which would never work. Luckily, remembered to create a virtual machine snapshot before applying the changes… and so managed to “undo” them and roll the machine back and start again! This is what I tried and rejected:

• Following all the advice in Microsoft Knowledge Base Article KB938245 including:
• Removing Kerberos from the IIS Metabase for the Reports Server (No. Just don’t. This is silly. It sets NTLM explicitly as the authentication provider here. So, why did we just spend all that time configuring Kerberos then? Quite. Don’t do this.)
• cscript adsutil.vbs set w3svc/##/root/NTAuthenticationProviders "NTLM"
• Editing the Registry to tell SSRS to use Kerberos (Really? I mean, *really*?)

After 12 hours of faffing around with SQL Reporting Services 2005, I decided to quit, and take the easy path and install SQL Server Reporting Services 2008 on Server A, using the SQL Server 2005 on Server B.

SQL Server Reporting Server 2008 Unpleasantness

Before you install SSRS 2008 on top of SharePoint, you might want to install the SharePoint Option Pack for Reporting Services 2008, rsSharePoint.msi. One problem with this is that the Reporting Services Add-In setup stalls when you run it on Windows Server 2008. You can try running it as Administrator, but it will likely fail. Instead you need to launch it from an Administrative Command Prompt, with the following:

rsSharePoint.msi SKIPCA=1

This will unpack the option pack into your temp directory. For me, it put it under “%temp%\1”. Yes. That was indeed odd, that extra numerically-named folder underneath… Heigh-ho! Then you need to change into that directory and run:

rsCustomAction.exe /i

Now the option pack should start installing without too much going wrong, and you can install SSRS 2008 on your SharePoint Web Front End server.

Things should start working at this point. Unfortunately, there are a few problems with persuading SSRS 2008 to use Kerberos authentication. Some things get a bit missed out in the RSReportServer.config file that drives how Reporting Services authenticates you. Specifically, line 3 below is missing from the file:

   1: <Authentication>

   2:     <AuthenticationTypes>

   3:         <RSWindowsNegotiate/>

   4:         <RSWindowsNTLM/>

   5:     </AuthenticationTypes>

   6: </Authentication>

After this, everything starts authenticating properly.

Tidying Up

You may find yourself sitting in a shotgun shack. You may find yourself with a working SQL Server Reporting Services 2008. And you may ask yourself, “Well, how did I get here?”

You may also find yourself with Kerberos authentication broken because of duplicate Service Principal Names (SPNs). To find out if this is what’s preventing your servers from authenticating, you can execute:

SETSPN.EXE –X

You can then run

SETSPN.EXE –D <ServicePrincipalName>

for each duplicate you want to remove.

Best of luck! And if you find yourself stuck, banging your head against a brick wall trying to get SSRS 2008 working with Kerberos on Windows Server 2008 in SharePoint Integrated Mode, then you now know someone who’s got it working: me.