Just Another Web Application : sharepoint

On the subject of the Central Admin website

jasbro — Fri, 28 Mar 2008 06:22:00 GMT

I've been rooting round in SharePoint internals today, mostly out of curiosity, after a fellow engineer here at the GTSC mentioned changing the port number on which Central Admin is published. We have a supported way, and some unsupported ways, and some ways that are sort of outside the scope of SharePoint entirely. So I figured why not a blog post?

The officially supported way:

psconfig.exe -cmd adminvs -port 5950

Pretty simple, but not commonly known (I had to double-check myself). Reprovisions (or more accurately, alters the existing provisioned copy of) your Central Admin site on the appropriate port. This command can also provision or unprovision Central Admin entirely, and can change the authentication scheme.

The unsupported way:

open inetmgr.exe
right-click the central admin website
click properties
on the first tab, change the port binding, click OK and go merrily about your business.

The downside here? Well the shortcut in your start menu will no longer point at the right port, for one thing. You may be able to live with that, but in addition, our config and deployment tools won't be able to talk to central admin if they need to, service packs and updates may break your changes and indeed future updates may flat-out fail.

Internally, the central admin URL is stored in two places, which won't be updated by this method. First, in the registry, at:

HKLM\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0\WSS
CentralAdministrationURL
REG_SZ

Secondly, in the config database in the 'objects' table, as part of the big bad voodoo 'properties' field in one or more rows (in my case, two rows). Exploring this deeply is probably beyond the scope of this post, suffice it to say: don't mess with the config DB, and don't change the Central Admin port this way if you can possibly avoid it.

A supportable alternative:

This is how my usual virtual machines are set up. I do not change the port on which Cental Admin was originally configured. I do however, add another IIS binding, but with a host header.

First, we need a hostname or host header. Often, you can add a DNS name, for example "admin.sharepoint.com", then we once more crack open inetmgr.exe, get the properties of the central admin site, and hit the advanced button in the IP binding section. You then:

Click Add
Add a new binding with name and port 80 specified.
Click OK

This allows me to contact Central Admin from remote machines without punching holes in the firewall and without actually moving the existing CA site. The downside? If you run the psconfig command mentioned above, it'll wipe your additional bindings. And your menu shortcuts will still point to the original port. The upside? you don't have to remember the port number any more, In fact, I find it so useful that on my VMs I have a HOSTS file entry marked 'admin' pointing to 127.0.0.1 and a host header to match. I can just type 'admin' into the address bar and away we go.

So there are three things you can do to alter the port on which Central Admin is published, one of which puts you way outside supportable territory, and two of which we'll happily support. Go with the good two, guys!

Blogging catchup and mailbox spring clean

jasbro — Fri, 07 Mar 2008 03:50:00 GMT

Having recently spent some time in India attending training on Microsoft Search Server 2008, and having been quite sick as a result, I've got a bit of a backlog of SharePoint blogging to catch up with. First of all, to comment on Search Server: This is a great product. It significantly builds on the search already offered by WSS and MOSS, streamlines the admin and search interface, adds Ajax functionality and Federation, and comes in a free Express flavour to boot. This is a new, standalone product, but you could potentially also look on it as an expansion/update for your current WSS 3.0 installation. An update for MOSS adding this functionality will be available on a provisional timeframe of mid-2008 (calendar).

MOSS administrators, you may be aware that SQL Database maintenance can be the bane of your existence, as well as being something of a dark art with documentation having been thin on the ground. The good news is that there is now a whitepaper covering all aspects of DB maintenance for SharePoint. Download it here and get cracking on supported database maintenance scenarios.

Securing MOSS is a large topic deserving of more than just a throwaway line on a blog, so I intend to develop some content on the subject in the coming weeks, as workload allows. For now, here's the Roadmap to Security Content for Office Sharepoint Server 2003, which should be on any admin's bookmark list.

Unfortunately, I'm short on time to post much more than this for now, but expect more in the near future...

I love Sushi

jasbro — Tue, 19 Feb 2008 09:28:00 GMT

No, I really, really love sushi. Quite often you'll find me dining out at Hamachi-Ya, Sushi Train, Sapporo or Sushi Club, four of my favourite japanese restaurants in Sydney.

So imagine my joy when I found SharePoint Sushi, a neat UI utility to carry out all those day-to-day annoying tasks like backing up, restoring, security checking sites and so on. It's, in essence, a GUI wrapper around many of stsadm's common commands, so it's nothing you can't already do if you're willing to type your fingers to the bone, but oh! It's so much easier and more fun.

In other news, off to Melbourne this weekend, then I'm in Bangalore for some SharePoint training - will be a new experience for me, first time on the subcontinent. Wish me luck.

EventID 5566 Troubleshooting in InfoPath Form Services

jasbro — Tue, 05 Feb 2008 05:00:00 GMT

This post has been snatched from the headlines of Premier Support. The names have been changed to protect the innocent. Now read on...

Imagine for a moment you're creating a new InfoPath form t recieve user input. Imagine furthermore that you're pre-populating this InfoPath form with information from a web service, in this case based on some sterling advice you found on a Microsoft blog. Further imagine that this InfoPath form works perfectly in the InfoPath client application itself, so you pat your own back and deploy it to SharePoint site for initial testing and feedback.

This is a very common scenario, and most people would never run into the problem my customer did, which was this: When SharePoint users who did not have the InfoPath client app installed came to use the form, it tried to open in InfoPath Forms Services, a wonderful feature of SharePoint. This is fine, the form was designed with this in mind and was set up to be a browser-compatible form. But this happened:

In addition, an Event with ID of 5566 was logged to the server's event log.

Interesting.

So what did we do here? Well, the first thing was to confirm that the form worked OK in the InfoPath client, which was confirmed. I then set about making sure the steps in the original blog article were valid and didn't contain anything weird. This I achieved by followig the steps myself in my repro environment. During this phase I observed exactly what was going on where for this to work correctly. Mine, of course, didn't work correctly right out of the box, and I discovered there are a number of things that could potentially go wrong here.

Firstly, Internet Explorer Enhanced Security, which is enabled by default on Windows 2003 servers, may stymie your attempts to even get this working in the InfoPath client, as it did to me while developing on Windows 2003 Server. Create your form on a workstation or turn off IEES by removing it from Add/Remove Programs-> Windows Features

Second: On some Windows 2003 Sp1 installations, you may possibly run afoul of the LSA Local Loopback restriction. This is designed in order to prevent a class of attacks known as 'reflection attacks', but can, on occasion, have the unfortunate consequence of denying access to code which tries to connect back to the same server to, say, run a web service. There is a KB article on this, which can be used to eliminate this angle from the enquiry.

OK, so having eliminated those, we found that my local repro worked fine in both Office Client and IPFS, but the original problem at the customer's end was still extant.

At this point, we went to the logs. Having set this up myself, I had a set of IIS logs which reflected correct behaviour. I obtained the customer's logs for a similar period and managed to track down the requests in question - which was easy enough to do. IPFS uses /_layouts/FormResource.aspx to render forms and in our scenario I'd expect to see a logged line closely following this which would go to UserProfileService.asmx to do the info retrieval so that IPFS could pre-populate the form.

What we saw there was of interest.

Expected behaviour for a secured web service such as this one would be one (or two) HTTP 401 responses, then an HTTP 200 response signifying sucess. We saw three 401 responses in a row, and no 200. So IPFS was calling the Web Service, but being denied access.

2008-02-01 02:10:33 W3SVC533812677 10.254.72.102 POST /_vti_bin/UserProfileService.asmx - 80 - 10.254.76.37 InfoPathDA 401 2 2148074254 2008-02-01 02:10:33 W3SVC533812677 10.254.72.102 POST /_vti_bin/UserProfileService.asmx - 80 - 10.254.76.37 InfoPathDA 401 1 0 2008-02-01 02:10:33 W3SVC533812677 10.254.72.102 POST /_vti_bin/UserProfileService.asmx - 80 - 10.254.76.37 InfoPathDA 401 1 2148074248

More interestingly, from our point of view, the c-ip or Client IP field did not show the IP address of this server. In my good repro, the request came from 127.0.0.1, the local loopback address. The customer's log showed that the request to the web service was coming from a proxy server.

Light bulbs flashed on in our heads - the call out to the proxy shouldn't have been happening. To solve this, we need to stop IPFS using the proxy. INA quick consultation with the customer revealed that, why yes, we are using a proxy - some custom web parts need to call out to the internet and grab data, so there's a proxy configured in web.config for the MOSS site. Like this:

<system.net> <defaultProxy> <proxy usesystemdefault="false" proxyaddress="http://xx.xx.xx.xx:8080/" bypassonlocal="true" /> </defaultProxy> </system.net>

As you can see, bypass on local is enabled. So why wasn't IPFS bypassing the proxy? The answer lay in the URL used to access MOSS, which in this case was the dot-separated local address moss.company.local. WinHTTP sees this as an FQDN, and doesn't qualify it as local, and WinHTTP does our web service request. The finishing line was in sight. All that remained was to check this MSDN article on enabling bypass lists in web.config or machine.config, and our troubles were over.

<system.net> <defaultProxy> <proxy usesystemdefault="false" proxyaddress="http://xx.xx.xx.xx:8080/" bypassonlocal="true" /> <bypasslist> <add address="moss.company.local" /> </bypasslist> </defaultProxy> </system.net>

IPFS now works like a charm at the customer's site and serenity has returned to the IT department, just the way we like it.

Incidentally, the <bypasslist> element allows you to use Regular Expression to specify addresses, so you can exclude whole ranges at will - quite neat.

PSA: Are your customised site definitions supported?

jasbro — Wed, 19 Dec 2007 06:06:00 GMT

We (Microsoft) have lots published guidance on customising SharePoint for your own specific needs. We provide lots of built-in site definitions for various purposes, but sometimes you need to tweak those to suit your own scenario. But are your tweaks supported?

Well that depends.

If you've modified a built-in site definition directly, you are in an unsupported state
If you've copied an existing site definition, then modified the copy, you're supported

Why is this important? Well, a couple of reasons.

One: we may want to release an update to an existing site definition as part of a service pack or feature pack. This will stomp all over your changes and no doubt you'll be an unhappy bunny about it.

Two: every so often a case trickles into support where a customer has tried to run an upgrade or migration, and it's failing because of a tweaked built-in site defintion. Eseentially, the upgrade program is utterly baffled that the site def doesn't just upgrade the way it expects. Yes, you will most likely have big problems upgrading a site in which built-in site definitions have been customised.

So you may find it prudent to check KB 898631 when planning custom site or area definitions:

Supported and unsupported scenarios for working with custom site definitions and custom area definitions in Windows SharePoint Services, in SharePoint Portal Server 2003, and in Office SharePoint Server 2007

PS: Premier Support here in Sydney IS HIRING. We're after SharePoint Support Engineers for both development and admin - please feel free to get in touch through the blog and I can get you referred. When I have a public link I'll update to reflect that.

SPSecurity.RunWithElevatedPrivileges()

jasbro — Wed, 12 Dec 2007 03:09:00 GMT

The subject of today's post: running code in sharepoint with elevated rights, an operation sometimes required, sometimes abused and often misunderstood.

The WSS Object Model provides a huge number of classes, some of which can carry-out potentially dodgy actions, so require elevation to run. Ordinarily you'd just deal with this by logging in as a user with rights to carry out the operation, but occasionally this isn't practical or possible, and that's where today's subject comes in.

Let's say, just as an example, you're creating an anonymously-accessible site. In a Control on on of the pages you want to enumerate subsites of your site, and grab some properties thereof, maybe for display, maybe for some other operation in your code - however, this isn't something an anonymous identity can do.

In steps our hero - RunWithElevatedPrivileges()

Used correctly, this method allows a specified block of code to run in the context of the SharePoint System Account, a powerful method with much potential. Here's the summary from the SDK:

[SharePointPermissionAttribute(SecurityAction.Demand, Impersonate=true)] [SharePointPermissionAttribute(SecurityAction.Demand, ObjectModel=true)] public static void RunWithElevatedPrivileges ( CodeToRunElevated secureCode )

Now the CodeToRunElevated parameter can be a reference to a void, parameterless method or an anonymous method via delegate() - please, follow the SDK link if that's unclear.

Pretty simple, huh? Yep, well as always there's a catch or two.

1. If you're manipulating any Object Model elements within your elevated method, you need to get a fresh SPSite reference inside this call. For example

SPSecurity.RunWithElevatedPrivileges(delegate(){ SPSite mySite = new SPSite(http://sharepoint/); SPWeb myWeb = SPSite.OpenWeb(); // further implementation omitted });

2. You can't just use SPContext.Current.Site to get your SPSite reference - or you'll ber handed the object with the security context of the anonymous (or non-elevated) user and your elevation will not work as expected.

3. If you need to Update() anything inside this block, you'll need to call SPSite.AllowUnsafeUpdates() on your new site reference (or web reference) as per this SDK entry.

So those are the gotchas. Following those we have the obvious security warnings - be careful what you do within this call, as the system identity has full control over SharePoint and could do Very Bad Things if incorrectly used. Sanitise any user input very carefully if you're going to let it anywhere near this method - you certainly don't want a user finding some injectable exploit into this code. Exercise caution over what you do, for this power must be used wisely. But you knew that, right?

Quickie blog post: SharePoint SDK available, quick note on discusson lists

jasbro — Wed, 22 Aug 2007 07:51:00 GMT

The Sharepoint SDK (officially, the "SharePoint Server 2007 SDK: Software Development Kit and Enterprise Content Management Starter Kit") is downloadable from microsoft.com. If you develop .NET applications for SharePoint, or support said applications, then you're going to need this sooner or later. Note: it's also viewable online.

the second quick note: if you plan on developing anything for MOSS 2007 that modifies discussion list posts, you're going to need to remember: updating the 'body' property of the SPListItem object is all very well, but you may also need to update the SPListItem["TrimmedBody"] property too - this is the version of the body text which shows up in unquoted view. This came up in a recent support case

li["Body"] = helper.DoSomethingToBodyText(li["Body"].ToString());

li["TrimmedBody"] = helper.DoSomethingToBodyText(li["TrimmedBody"].ToString());

li.SystemUpdate();

A popular thing to do with these programatically is to auto-hyperlink or auto-format certain keywords in text - if you don't update both variables you end up with only the quoted view showing your changes.

Quickie: Broken web part page? We can help!

jasbro — Thu, 05 Jul 2007 05:11:00 GMT

I'm called upon to troubleshoot numerous errors with SharePoint on a day-to-day basis, and some of the most frustrating are "Unexpected Error" messages which occasionally crop up on web-part pages. This is worst for administrators when they occur on hitting 'edit page' - worried admins can't then edit the page and end up running round in small circles, flapping their arms and screaming.

Well, there's an easy trick to get to the web part maintentance page.*

Let's say your malfunctioning page is:

http://sharepoint.contoso.com/pages/default.aspx

simply tack a querystring onto the end of the URL as follows

http://sharepoint.contoso.com/pages/default.aspx?contents=1

and hit enter. This will drop you straight into Web Part Maintenance, and you can remove the offending web part and get it fixed.

finally, don't forget if you have to check out the page to make changes, you'll need to check it back in afterwards - if you have full admin access, just hit 'publish', if not, get an ~~adult~~ admin to help you.

* I can never remember this when called upon to do it. I'm hoping posting it will make it stick in my memory