Thursday, November 27, 2003

Windows SharePoint Services - Installation is Interesting

We all goof - and I'm not alone in being guilty of it. But the issue highlighted in KB article 833019 is beyond a goof. And the complications it can generate in some installations are a worry!

The problem occurs if you install Microsoft Windows SharePoint Services (STS as it used to be called), which from 3 days ago, fails with a fairly obscure error message. You also get this problem if you try to provision a new virtual server or you try to create a new content database when you are running Windows SharePoint Services by using MSDE (the KB appears to be inaccurate on this point).

The error is caused by a bug in the code that verifies the signatures of DLLS installed with SPS. All installations of Windows SharePoint Services experience this behavior after November 24, 2003. And guess which product installs this component by default? Small Business Server. Ouch!

Problems hapen. But the workaround is interesting: Set the date in the Date and Time Properties dialog box to a date that is between May 24, 2002 and November 23, 2003. That's right, lie to the OS. Trustworthy computing, maybe not, but it works. OH, be careful to not set it too far adrift, or you might trigger product activation.

My view of WPA is further diminished.

And here I thought Linux was secure!

PC World reports that Servers belonging to the Open Source Debian project were hacked. It suggests that there was no impact on the software update issued last Friday. Debian's site carries more information about the attack.

This attack comes close on the heels of both an attempt to hack the Linux kernel, and and an attack at the Free Software Foundation. These hacks show two things: First that security is everyone's problem (not just for customers of Microsoft) - attackers do not play by any rules and will attack pretty much anything that is not totally locked down. Second, it proves, yet again, that any OS can be installed insecurely.

What the Linux bigots often fail to remember is that security requires three things: people, processes, and technology. Even the most secure technology can be defeated by poor processes or by people not doing the right things. This is not a Microsoft vs Linux thing, but more a simple recognition that security of your systems is only as strong as the weakest link.

Wednesday, November 26, 2003

Dell Ditch India - and not before time

According to Dell is cancelling their Indian tech support. I've recently had the misfortune to have had to make 2 calls to this center and they were both awful. My trusty laptop (a Dell Latitude) had it's hard disk begin to go. I needed an urgent replacement as I was using the laptop to present sessions at IT Fourm.

Both techs I talked to were cheerful, but the responses bore no relationship to my questions. They had a script and totally had to follow it - any deviation was met with a refusal to go further. It took forever, and in the end, they were unable to help in time - so I go another hard drive from another source and made do with that. Next week, when I settle down a bit, I'll call again and get the disk replaced. See for full details of this story

I couldn't make this stuff up if I tried!

Only an American could make a soft drink flavoured with turkey and gravy (so awful, even its creator admits is undrinkable) and sell out. See BBC NEWS | Business | 'Gross' turkey tipple gobbled up for the details.

Thursday, November 20, 2003

Microsoft Announces Availability of Open and Royalty-Free License For Office 2003 XML Reference Schemas

I was in Copenhagen last week at IT Forum. I was co-presenting sessions on Microsoft and Shared Source, in which we looked at how MS viewed Open Source, Linux, and all that. One issue that was raised was over file formats - one thing that seemed to be wanted by customers was an open XML schema for Office documents.

As it turns out, MS also formally used Copenhagen and IT forum to announce the availability of Open and Royalty-Free License For Office 2003 XML Reference Schemas.

This is a good step forward!

Tuesday, November 18, 2003

MSH Provider Architecture

I've been delving a bit more in to the provider architecture of MSH. In MSH, you have the several default providers, including a file store provider, a registry provider, etc. I discussed this in my post yesterday. The idea of providers is that they provide a way to surface data into MSH. The PDC bits come with an AD provider and a Registry provider, although the latter at least is pretty primitive.

Each provider provides a drive, which in turn contains containers, and items. Containers, of course, can contain more containers and items. Each item is some fundamental data structure, as surfaced by the provider. If, for example, you built a DNS provider DNSProvider.dll), a particular server could be identified by a different "drive", which could then be enumerated to list all the zones on that DNS server. For example, you could do something like:

new/provider -Provider DNS -assembly DNSProvider.dll
new/drive -name MyDNSServer -Provider DNS -root

This would then list all the zones defined on the DNS server, as well as some information (eg when created) about those zones. You could then navigate to a zone (cd \ and enumerate the resource records in a zone.

This is incredibly powerful stuff. You could easily create a wealth of providers such as ones for IAS, IIS, ISA, Exchange, etc. Once created, they can easily be used in MSH command scripts.These should be relatively easy to write (at least the read/only bits!) and could be added easily. And since they are just plug-ins, there is no reason why a particular provider has to come from Microsoft. Cool!

Monday, November 17, 2003

MSH Continues to Rock

I've been playing more with the Monad command shell for Windows (aka MSH). In reading the downloaded documentation (ok, I confess, I RTFM'd!), I found another really cool feature of MSH, which is Drives.

As I understand it, drives can point to any provider, the most obvious being the file system. Thus, "C:\" makes sense at an msh command prompt. However, C:\ is just a pointer to a (filestore) name space provider. Monad extents that to allow you to add other providers. I'm still working out the documentation on how to do this, but one provider that's in the PDC MSH bits is an AD provider. You first have to load the provider, which is not presently done by default, but almost certainly will in later releases. Then you create a drive - in other words an alias to a DN. In my case, I used the alias QANET to point to the distinguished name of "DC=corp,DC=qanet,DC=net".

Once you have the drive created you can simply go 'CD QANET:' and you are pointing to a directory like view of, well guess what - the AD. You can move up and down OUs/Containers, viewing contents, etc. And since all MSH cmdlets are pretty much multi-provider, you can use things like Where (to filter), sort (er, to sort) and format (to format the data).

Another seriously cool feature of MSH is that you can format output as XML. ANYTHING you can generate in MSH can be sent to XML. Do I really have to explain why this is mega-seriously cool?!?!?

Monday, November 10, 2003

Linux hacked (almost)

This article from last Friday in The Register is highly interesting. The key thing is showed is the importance of good code control tools - without which this hack attempt could have been very damaging.

Sunday, November 09, 2003

Virtual Server Beta Slated For November - Quelle Surprise!

CRM says that Virtual Server beta is slated for November and that Microsoft is prepping its Virtual Server for beta-testing in mid Nov. Hooray - the beta is long overdue. The customer preview release in May was OK, but was clearly lacking in many areas. Since then, beta testers have seen no new builds, and no significant details on product direction. One thing seems clear: Microsoft's VM products may support Linux (etc) - but don't count on it. For those trying to server consolidate, this seems a shame, although both understandable and a market opportunity for VMware.

Tuesday, November 04, 2003

Test Post via email

Blogger just gets better. This post is being sent by email.


They are watching you.

I got an email today from my wife. It said " For those of you who travel the M4 west of London - youwill have noticed the New electronic signs. These were switched on, on Tuesday 21st October 2003. The bad news is that they are rigged with the SPECS speed cameras.

SPECS is a computer-camera based system. As you go past the sign a digital camera reads your number plate. When you go past the next sign your number plate is read again. The computer 'knows' how far apart the signs are so it can work out your average speed between the two or three or four. The system is fully automatic and will issue a ticket without any form of human intervention. It does this for every single vehicle that passes.

You will not know you've been caught as the cameras don't flash. They work 24/7, 365 days a year, and theoretically, there's absolutely no limit on the number of tickets that the system can issue. The whole section of the M4 between Theale (J12) and Membury Services (between J14 and J15) is wired, both ways. The system is set to triger a ticket at 78 mph. Radar detectors will be of no use as SPECS is entirely passive, there is no radar or laser beam to detect.

" Fortunately, the BBC have a different view.

Microsoft and Google: Partners or rivals?

OK - I've heard the story from a couple of sources, but this article in the on-line edition of Seattle's Post Intelligencer was sober reading. I have been giving it a lot of thought. At one time I sort of thought it made sense for everyone. While it would certainly benefit Microsoft, I'm not convinced it would be good for Google to be bought.

For Microsoft, I can totally see the logic. Their own search technology is miles behind that of Google. Allegedly, one of the drivers behind Longhorn's WinFS was Gate's observation that Google can search the Internet faster than Windows can search your C:\ drive. I don't know if the quote is even close to being accurately ascribed - but it's underlying truth is indisputable.

At the PDC I got to meet some of the people at Google. They are a lot like the good folks at Microsoft - open,fun, and with a great work real hard play even harder mentality. Everything I see is simple, clean and with an incredible underlying elegance - which is everything that Windows is NOT. Don't get me wrong, Windows is an outstanding OS, but it's hardly simple (if it were, I'd not be in business!). It's far from clean, with way too much eye candy and it's hardly likely to win an award from Weight Watchers. While parts of Windows are truly breathtaking, there are too many elegant hacks - things done in the name of performance and there are far too many inconsistencies (how you load/activate/remove components, etc, etc, etc). I suppose this why I'm so in love with Monad - a simple, elegant concept.

But back to Google - if they get bought, their folks would have to change. I mean, you couldn't have the lava lights in the offices (just think of the possible litigation from an employee who gets burnt). And those silly updates to the google's logo.gif on their homepage would have to stop, since they might offend someone somewhere somehow and we just couldn't take the risk. The cool clean look of would have to change to more closely resemble (By way of checking the home page is a mere 12.9kb of data, while's home page is nearly 140kb). And finally, how long do you think they'd be allowed to run Linux?

As I see it, Google is still fun - a fun to work at, fun to use, and fun to watch grow. Whereas, Microsoft almost by necessity, has had to become all too corporate. Sure it does cool and fun things, but at the same time, it acts ruthlessly when it has too. While I can certainly see the logic in Microsoft buying them, and the potential benefit to millions of Microsoft customers, I guess I'd hate to lose the fun.

The End of Linux as we know it?

In an article on NewsForge, Red Hat tells customers, 'No more freebies!"

Is this the beginning of the end for 'free' operating systems, or just the end of the beginning???

Saturday, November 01, 2003

MSH Rocks

MSH Rocks!!!

One of the coolest things I saw at the PDC was Microsoft's new command shell, code named Monad. Also known as msh, this new tool is possibly the biggest advanced in scripting since Unix scripting was invented. Yeah, I know, big words. But let me tell you about it!

Before getting into what Monad is, let's look at conventional Unix scripting. One of the real power features of Unix (and here I include Linux, BSD, etc, etc) is the ability to string along a bunch of tiny commands via the pipe commands. This allowed you to crate truly useful tools. This is something that was never really possible with Windows. Possibly the very best thing about Unix is the huge array of very simple programs that can be strung together to do everything you need.

In the Unix world, you take tiny commands, cmdlets in MSH-speak, which are either built in (eg ps, ls, cat, touch) or which you can easily write, and let them communicate via the normal stdin/stdout/stderr pipes. In the Unix world, this works very well. However, there is one fundamental obstacle here. Cmdlets communicate in the pipeline via text.

Now text input/output (stdin, stdout) is cool. BUT: the individual cmdlets are written using absolutely no standard way of expressing or mandating input and output data formats. Thus, in order to do good shell programming, you also have to master grep, sed/awk/perl, etc. in order to manipulate the various inputs and outputs. Unix scriptmeisters will be familiar with the having to "drop the 1st two lines, then go to col 34 and take the next 10 chars but if there were tabs instead of spaces, etc, etc." Let's face it: text sucks as a method of inter-command processing.

MSH takes the incredible power of the pipelined cmdlet approach of Unix, but instead of passing raw text, MSH sends NET Managed objects between cmdlets. That's right, objects, not raw text. Managed, type safe, and easy to write/extend .NET Managed objects! Now with such .NET objects, you get rich metadata available to the cmdlets. The MSH shell then uses .NET reflection to get this information into the cmdlet.

Now the format take a bit of getting used to, but you can type something like: "get /process" to get a list of processes running. You could string this together with the where cmdlet giving: get/process | where "handlecount -gt 500" to print out a list of processes with large handle counts. Now since you are passing .Net objects, the second cmdlet (where) has the full metadata of the process objects create by the process cmdlet. So it can do a 'where' based on all the processes attributes such as handle count, memory usage, etc, etc. And of course, there are a ton of formatting options since you know all about the attributes of the passed objects.

You can also write more complex scripts, such as:
$p = get/process
foreach ($p)
{ $p.FileName.ToString()
This assigns the output of the get/process to an array then prints the file name property of each array member (i.e. prints the file names of the executables for each process in the process list) . At least I think this is right! Apologies if the syntax is a big mangled

The next cool thing is how msh handles namespaces. In Unix, cmdlets essentially have just one namespace: the file system. MSH has this, but also adds the registry, active Directory etc as namespaces. So you can go: CD AD:\ and get into the AD, where you can type DIR and get a listing of the top level objects. Or, type "CD HKLM:\" and be able to see the top of the registry. And of course, you can write your own namespace provider! MS plan to add a provider for SQL, and are open to adding others. I want a DNS namespace provider!

Then there's all the cool output options. Builtin, MSH supports output formats including HTML, XML, Excel, Word or even good old formatted Text. If you want to output text, you have all the formatting options you want, either from the shell, or in code if you write your own cmdlets.

Developers will love the cmdlets - they're incredibly easy to write - and being .NET based, you can write them in any .NET language. Your cmdlet class inherits from the commandlet base class. You just need to add a few attributes and hey presto you have a cmdlet!. And since the cmdlet has the full .NET namespace at its disposal, your cmdlet has access to anything and everything you could possibly want!! There are a bunch of simple examples in Jeffrey Snover's PDC deck.

Finally, the MMC will in future be based on this. So you can use the MMC to do some command, then dump out the MSH script that would be needed to do that action again. Then you can apply this to your entire domain

And as to the name. At first sight, it seemed odd, but Jeffrey Snover told us that: "the name came from Leibniz's Monadology, a philosophy which says that everything is a composition of smaller things (the smallest being a Monad)". I could go on - but I was totally blown away by the presentation and the demos. I'll post more details once I get them! Watch this space!! [a later update] I've written a couple of more posts on MSH: MSH Continues to Rock and MSH provider architecture. Enjoy