This is a fun object, consider this

SPSite site = new SPSite(“legitimate site collection url”) ;

SPWeb webA = site.OpenWeb(“Some bogus url”) ;
SPWeb webB = site.AllWebs[“some bogus url”] ;

You wold expect this code to throw two exeptions, you would be wrong.
Well you would expect webA and webB to at least be null, you would be wrong.

Apparently (not for the sake of consistency )

Do stuff with webA

Is the prescribed way to deal with this, how many of us have seen code like the following scattered all over blogs and such

if (webA != null) ….

Well, you live and learn.

>PSCONFIG is your pal

>Having some issues with scripting psconfig at the moment also. We have written some scripts based lossely on a ms white paper and posts from Spence and a few others (Plus previous experience of doing a simmilar scripting job for MS)

Our aim is to create a standalone script which can be run from a TFS build service, the script should take an Operating system only windows server and take it to SharePoint, SSP, Central admin a couple of web apps and various custom visual studio peices.

It should do this every night (CI, Continuous integration) and furthermore it should do all this from a tfs build box accross the wire to the deploy box.

For the remoteing we are using WinRs and a fine tool it is too.

Except, it dosent work in a couple of notable instances.

WinRs psconfig to create config DB fails

WinRs to run a powershell script to re set a hyperv machine to a particular checkpoint fails.

Both of these two work when executed locally they just fail when run over winRs. The latter works via telnet (for those looking for a solution that works)

I would welcome discussing this with anyone going through the same pain.

I will follow this up once PSS get me a definitave answer on if this is supported scenario or not.

Update (October 2009)
Seems that this scenario is not supported, according to MS PSS.

However, as is often the case, needs must …

A solution: May or may not work for you.
Configure Integration macjhine to automatically log in as userx and boot time (You will now have a fully logged in session)
Create a login script which copies you integration script locally and runs it

Not Elegant, but it works.

>What you need to know about advice …

>In my last posting I passed on some advice I got from a collegue relating to december cumulative updates for SharePoint server 2007.

Well, you live and learn, following that advice caused some issues with subsequent updates in my case.

So the fact is, your mileage may vary. My mileage turned into a full restore from backup, re download the offending updates (now magically working as expected) re install and all is now well, moral, always back these things up before any major changes.

Thank god for Hyperv checkpoints.