Just Another Web Application

Removing troublesome Shared Service Providers

jasbro — Wed, 01 Apr 2009 03:08:00 GMT

Wow, it's been a looooong time since I've blogged here - a lot on my plate I guess. Anyway, on with the show.

I recently attended a customer, here in Sydney, with a number of SharePoint issues. One of these was an inability to delete old, defunct SSPs in Central Administration. For some reason, the IIS websites and the SQL Content databases had been removed (or lost during a recovery), and the SSPs couldn't be removed via the Central Admin UI.

"Hmmmm", thought I. "What can we do here?"

First port of call when the UI is behaving oddly? stsadm.exe.

Our command line tool can do pretty much everything the UI can do, and if it can't, then you can extend it yourself or use a third-party extension.On this occasion, though, it still failed, returning a "database not found" error.

stsadm.exe -o deletessp -title "My Broken SSP"

Deleting an SSP, logically, includes some database work, so this seemed like the problem's heart - the databases were already long gone and we seemed to be in a catch-22. It may be possible to delete the SSP directly from the database using a whole boatload of painstaking care and attention, but that's an utterly unsupported operation which could render one's farm useless. So what's an engineer to do?

Well, it turns out that there is a command line switch which is not documented in stsadm's -help information.

stsadm.exe -o deletessp -title "My Broken SSP" -force

The force switch basically ploughed on ahead at the "database not found" error, assuming rightly that the database was already gone. It ignored the fact that the IIS sites were missing, and it successfully cleaned up our rogue SSPs. This was a triumph.

It's not SharePoint, but it's moderately interesting

jasbro — Thu, 22 May 2008 06:57:00 GMT

Like many of you out there, I have a Windows Mobile Smartphone. The one in my case is an i-Mate SP5, and I really like it. Recently though, it developed a problem which was really annoying me.

By default, it offers quick access to menu items using the numeric keypad. For example:

1. Phone
2. Sounds
3. Profiles
4. Home Screen
5. Clock & Alarm
...

One day though, my device decided numbers were uncool. Alpha characters were now the way to go:

A. Phone
B. Sounds
C. Profiles
D. Home Screen
E. Clock & Alarm
...

This annoyed me no end, as I couldn't now use easy shortcuts and had to use the joystick to navigate everywhere. Painful.

So today I decided I'd have a dig round in the device and see if I could find the setting that had changed. I think it changed around the time I hacked on A2DP support in order to use my car's bluetooth handsfree and audio capabilities. So could be I'd changed something there. Or it could be something else. Either way I was entirely unable to find anything in the UI, so I resorted to the registry. Kids! Don't try this at home!

Using Pocket Controller, I valiantly cracked open my phone's registry with no thought for my own safety. I then hunted the registry to see if I could find some likely targets for the problem. Eventually I found the shell key [Mobile Device\HKEY_CURRENT_USER\Software\Microsoft\Shell] Which contains an entry for HasKeyboard. On my device this was set to 1. "Odd," I thought to myself, "why would that be set to 1 when I don't have a keyboard?".

The Windows Mobile Team Blog and MSDN both explain that this value shows whether the phone has a QWERTY keyboard attached. Mine doesn't. Could this be the problem? With infinite care I changed the value to zero...

Solved!

It appears something decided I had keyboard input, what that was I don't know (I suspect a bluetooth pairing with another phone resulted in the service "Input Device" being enabled) - but know I know how to fix it and so do you.

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.

Hear Ye, Hear Ye... Apurdon now a blogger

jasbro — Thu, 31 Jan 2008 04:18:00 GMT

My long-time colleague and soon-to-be defector to Premier Field Engineering Andrew Purdon has joined us on planet blog with the opening of "The Office Sharepoint Server Experience".

His opening post deals with customising Access Request emails and by extension touches upon customisation of SharePoint file within the _layouts folder, upon which we have published advice. To paraphrase: Think hard before you do it, back up the original files, be careful, don't be surprised if something doesn't quite work how you expected.

In other news, we are still running at capacity here in the Sydney support center, and while my earlier plug for our want ad has produced fruit, I should mention that if you're interested in working in the field of SharePoint support you can still send in your resumé as an expression of interest for posts that may open up in the future.

Coming: some more posts from me on Infopath Forms Services and some troubleshooting advice for ifilters and indexing. stay tuned!

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.

Sydney SharePoint User Group

jasbro — Tue, 17 Jul 2007 07:34:00 GMT

I can't make it tonight, unfortunately, but I feel duty bound to publisise the Sydney SharePoint User Group, which usually meets at Uniqueworld, Campbell Street Sydney. Check the site for full details, but it's open to all interested parties and includes nibbles and drinks. Tonight there's scheduled to be a talk on SharePoint and Compliance from Anthony Woodward.

I'll make a serious effort to be there for the next iteration, however. and p.s. it's affiliated with similar groups in Melbourne, Canberra and Brisbane. Just because your city is second rate*, doesn't mean your sharepoint experience should be too.

*no, I really mean it. honest. :-p

Inside a Support Incident: SharePoint site templates and auditing

jasbro — Mon, 16 Jul 2007 08:56:00 GMT

Here at CSS (formerly PSS), our bread-and-butter is the support incident. One recent incident (hereafter referred to as 'the case') allowed me the rare opportunity to blog on what goes on here at CSS when an issue is raised by one of our customers, and I'll be blogging the progress of this particular case as time goes on, as will Gavin, the external party. First, the background:

Gavin, our customer, has run into a problem provisioning new SharePoint site collections based on a custom template. Gavin is one of our more active SharePoint customers, and he knows the drill - some initial troubleshooting was already done when the case was submitted, and there was a clear description of the problem. Having run into what seemed to be an impasse with his own troubleshooting, Gavin called the support line, and one of our front-end guys took the call, created the incident in our system and dispatched it to the ANZ Bizapps support queue, one of several I monitor.

We work on a callback system here in ANZ Premier - when a customer calls in with a problem, we won't immediately dive in and start troubleshooting on the same phone call. The complexity of our incidents is often high, and the callback model allows us to route to the appropriate specialists and allow those specialists to get up to speed before going live with the customer.

So when I received Gavin's case I had four lines of text to work on, describing the behaviour in a very succinct style, and the specific error message: "The specified web does not contain a reporting metadata list".

The first thing I'm likely to do with an incident like this, even before contacting the customer, is to fire up our internal Knowledge Base client and search on the error message. This I did, and discovered that there aren't many hits for this particular message. In fact, I found only one previous case with this message cited. Luckily for me I struck gold with this initial search - there is indeed a workaround, which is to run:

stsadm -o activatefeature -name Reporting -url http://server/sitecollection/ -force

Which essentially just switches on the reporting feature. I sent this over to Gavin, and received a nice positive response - it worked! This meant Gavin could now provision sites successfully. Of course, this doesn't tell us why this feature wasn't activated in the first place.

So at this point Gavin and I discussed the nature of the problem as it stands, and moved on to stage two, seeing if the problem will reproduce and understanding if the issue is caused by something in the product or outside the product. Gavin, to his eternal credit, had already done the 'minimum repro' thing, and provided me with a set of steps to reproduce the problem.

Onwards, to the Virtual Machine.

I have a base image I use for these problem repros, which consists of a full install of Office SharePoint Server 2007 on Windows Server 2003, all packaged up as a Virtual Server VHD image. When I need to play with MOSS, I fire up either an existing instance of this VM or start a brand new one. This is a pretty quick process. I just copy one file, run through a quick wizard in Virtual Server and fire it up.

In this particular instance, I decided to use an existing VM to reproduce the problem. Of course, Murphy's law kicked in and I ran into a problem provisioning the new site collection entirely unrelated to Gavin's own problem, which I was able to trace to a custom feature I'd installed on that particular VM. So out with that VM and in with a clean one.

This time, the repro went perfectly. Here are the steps I took. They're essentially the same as those posted by Gavin in this post.

From a baseline install of MOSS, I provisioned a new Site Collection at http://sharepoint/ , based on the 'team site' template.
In the 'site settings' page of this new site, I clicked 'save site as template', provided the basic info and saved to an STP.
the resulting STP file was saved to disk, and I ran stsadm.exe to make this template globally available. The command is: stsadm.exe -o addtemplate -filename “audit-repro.stp” -title “Audit Repro Template” -description “Reproducing a reported problem with auditing activation”
Back in SharePoint Central Administration, I provisioned a new Site Collection based on this new Custom Template.
In 'Site Settings' for this new site collection, I clicked on 'Audit Log Reports' and received the self-same message as Gavin. The source site collection had no such issue.

So it appears that this problem is reproducible, and not something specific to Gavin's environment. It is, in essence, a bug*. That's a bug*, not a bug. At this stage, it's a bug report, and not officially confirmed by the powers that be, though it fits the definition of an unexpected error condition, reproducible on demand and contrary to expected behaviour.

And what's done at this point? Well, I log a bug report in our internal system and that is escalated to the Office Server Product Team for triage and an official response, then I sit back, reflect on quite a smooth incident thus far, and write up this blog post. And that's as far as our story goes for today. Tune in next time for the exciting conclusion!

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

I'm in yr Office System, Devloping yr Appz.

jasbro — Thu, 31 May 2007 10:56:00 GMT

kthx

OK, so the nod to Lolcats is extremely cheesy and trite, but I'm in one of those moods, OK? To put it sensibly, the Microsoft Office Interactive Developer Map is now available from MSDN as a ClickOnce Application, designed with the creamy goodness of WPF. Think of it as a nice clickable poster outlining Office System 2007 developer features with which codemonkeys can get an overview of the amazing dev features Office 2007 has to offer. If you're involved with Information Worker development, even in passing, I'd recommend you grab it and have a browse around. Think of it has your animated information hub for Office Developer info. Pay special attention to the Sharepoint and Office Server System information

kthxbye

Who are you and what are you doing in my blogosphere?

jasbro — Thu, 31 May 2007 04:07:00 GMT

It is written: All blogs must begin with an awkward introductory post from the blogger, explaining in stilted terms who the blogger is, and what he or she intends to do with the blog. This stated direction will then turn out to be anything but the direction in which the blog will drift, in accordance with the long-established laws of the internet.

Here's mine

I'm Jason Brown, freshly minted SharePoint Support Engineer at Microsoft's Sydney GTSC. It is my ongoing mission to assist Microsoft's Premier (and Professional) customers in resolving such issues as they may encounter in their use of Sharepoint, both 2003 and the newer MOSS 2007 suite. In former times I was an IIS Support Engineer working on a range of IIS and developer related subjects, which means I come to the role with pretty good general web-application troubleshooting skills, and what is SharePoint if not a Web Application?

Actually, it's far more than just a Web App, which is why this blog exists. I'll be using this location to post interesting snippets of information, troubleshooting techniques and sundry technical nonsequiteurs loosely related to SharePoint, the platform on which it operates, and the world of Microsoft at large. I'm still learning the SharePoint product and expect to be in a constant state of study as long as my tenure continues, so a lot of the content will shadow my learning experiences and hopefully assist in those of SharePoint users and administrators around the world.

This is most emphatically not my personal blog, so don't expect a lot of musings on the state of the world and whines about the rigours of day-to-day life. I do that elsewhere, and may consider posting a link to that location in due course. I reserve the right, however, to post apropos-of-nothing IT-related items such as this.

I thank you.