The wonderful thing about web standards

Alex and I were having a rant discussion a few days back about web standards after I pointed out to him that Firefox and Safari not being able to supply login credentials within a URL meant they were not RFC-compliant in this respect (and he accused me of being sponsored by Microsoft)!

I know that there are many pieces of Microsoft software where the standards have been “extended” or “enhanced” and this week I heard that they are going to extend RSS when it is integrated into the next version of Windows (codenamed Longhorn); but we had both hoped that the Mozilla browsers would be better in this respect (in general, they are).

I like Firefox. In fact the only reason that I’ve gone back to Internet Explorer (IE) is that a huge number of websites (about 10% according to IT Week) only work properly with IE and some mis-identified Firefox as a very old Netscape browser. Now that IE’s market share has slipped to about 85% and Firefox is gaining momentum, all we need to do is to persuade web designers to code sites to work with all common browsers.

It would be so much easier for web designers, IT administrators, and IT architects alike if all browsers complied with standards. In another IT Week article, Bill Pechey highlights a UK government department of trade and industry (DTI) report that suggests standards promote healthy growth.

I’m hoping that Microsoft’s forthcoming IE 7 browser will be fully web standards compliant (and if it has to support Microsoft-proprietary extensions as well then that is fine as long as it can properly render standard pages). That remains to be seen but meanwhile it’s good news that Microsoft is collaborating with the Web Standards Project to promote open standards.

Get Firefox!

(and just to show that I’m not biased…Internet Explorer).

Readvertising failed packages with Microsoft SMS

A few weeks back, my colleague Barry Feist gave me a useful tip for when deploying software using Microsoft Systems Management Server (SMS). Barry doesn’t have his own blog, so here are the details.

Details of commands executed on the local machine by SMS are held at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Mobile Client\Software Distribution\Execution History\packageid. It is not uncommon for there to be a failure within a distribution, so to rerun a failed installation, delete the key and re-advertise the package. According to the how to re-advertise a package post on MyITForum, Microsoft knowledge base article 257271 gives an alternative solution but Barry’s solution seems simpler to me.

Tips and tricks for using Microsoft SharePoint Portal Server 2003

Last year, I blogged about understanding, and developing with, SharePoint products and technologies and a few months back I attended a workshop on designing IT platform collaborative applications with Microsoft SharePoint 2003. I haven’t had time to digest and blog my notes from that course, but one of the things I came away with was Microsoft’s tips and tricks for using Microsoft SharePoint Portal Server 2003 white paper. Looks useful for anybody starting out in SharePoint administration.

Some more about sIDHistory

A few weeks back I was looking at migrating users between forests using ADMT when the source and target domain names are similar. It worked in my virtual environment but when we went to put it into practice there were some issues caused by different people’s perception of what the sIDHistory attribute will do.

sIDHistory will not avoid the need to enter the correct password to access resources in the original domain.

If there is a trust in place, then the trusting domain will trust users in the trusted domain.

If there is no longer a trust (or as in my client’s case, where there was no direct trust but a sequence of non-transitive external trusts) then sIDHistory will allow migrated users security credentials to be compared with the access control entries (ACEs) in the access control list (ACL) for a resource and if there is a match then they will be authorised; however they still need to be authenticated.

If the passwords are the same in the new and the old domains, then there will be no password prompt (as the hashes will match and the user will authenticate transparently); however if there are different passwords in use, then the correct password for the user’s old account in the resource domain will still need to be supplied.

Further reading

Unable to browse users in trusted domain (Microsoft knowledge base article 263956).
How to use Active Directory Migration Tool version 2 to migrate from Windows 2000 to Windows Server 2003 (Microsoft knowledge base article 326480).
How to Troubleshoot Inter-Forest sIDHistory Migration with ADMTv2 (Microsoft knowledge base article 322970).