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

The Twilight Zone

The weirdest problem. You debug your code in Visual Studio, place a break point and try to step through… All of a sudden, Visual Studio seems to go mad and highlights the wrong line. As you step further in it seems to jump almost randomly from one line to the other…. WTF?!!

Well, we’ve just had this problem with one of my clients.

Debugging the Debugger

The problem is sporadic – in other words, it’s always the same areas of the code where we get the issues, but we don’t always need to debug through those areas, so we don’t always notice.

Initially we thought it was debug symbol files (.pdb) being out of date/sync with the assemblies we’re building. This culminated in very lengthy complete teardown, clean and rebuilds, to no avail. Much googling and trial and error and wheelspinning.

A few articles on the internet mention a hotfix (KB937122) for Visual Studio 2005 SP1 that resolves a similar sounding problem, but this nothing relevant to our version of Visual Studio.

The next time the problem occurred, we thought maybe Visual Studio was loading the wrong .pdb files. But no. A check of Debug –> Windows –> Modules shows which symbol files are loaded and from where.

We tried specifying locations to load symbols from, and even right-clicking modules in the above window, and picking Load Symbols From –> Module Path. None of this worked.

On and off, this has cost my team maybe 5 days of effort in the last couple of weeks.

The Culprit

After a lot of digging around, it transpires that if you tell the compiler to optimise your code, it can screw up the .pdb files; moreover it seems to cause the random stepping from line to line when debugging in Visual Studio 2008. The default setting in Visual Studio 2008 is for Release configurations to be optimised, but Debug configurations to be unoptimised. However, opening up many of our Visual Studio Project files shows something like this:

The Resolution

So, someone, it seems, is guilty of setting the optimise flag on each of our 20-odd projects in Visual Studio. Luckily, we have Team Foundation Server as a source code repository, and I can see exactly who made that change, and when :)

Maybe you’ve found this article via a search engine, in which case I hope I’ve saved you from the pain in the backside this issue caused us.

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!