Monday 22 September 2008

So, were the Gates/Seinfeld ads canned? Who knows – right from the start they were supposed to be teasers, something to get a conversation started – and they sure did that – the ‘net is awash with people (like me) saying how lame they are (although I’ve seen a few comments from people saying that they were starting to get into things with the second ad).
Now the blogosphere (and mainstream industry sites) are awash with people saying how Microsoft has come up with “I’m a PC” to take a swipe back at Apple – but without being funny. Hang on guys… you’re missing the point! I’m a PC is just a soundbite – saying how (Windows) PCs have been stereotyped as dull things from the office, things that are unreliable, things that can’t do anything exciting – but that over a billion real people use (Windows) PCs to do real things and showing some of those people. Personally, I don’t like the “I’m a PC” statement from the myriad users featured in the ads (“I use a PC” would be fine) but, then again, I come from the country that invented the English language (England) and these ads are targeted at people who speak American (there is no such thing as US English!).

Then there is the Life without Walls campaign – showing how many things can be done on a PC and how one operating system transcends so many devices used throughout the world.

Windows - Life Without Walls

And the Mojave Experiment, which basically said “come and look at Windows before writing it off as a disaster”.

I can see that this campaign is multifaceted. It seems to lack something to link the disparate themes of Mojave, Seinfeld/Gates, I’m a PC, Life without Walls and the manufacturer-focused Vista Velocity but I do at least understand where this is heading now. And I think it’s a smart move inviting consumers to add their own videos to the campaign, further underlining the fact that ordinary people use Windows PCs (a PC is not a stereotype).

As for the Microsoft-bashers, well, they’ll always find something to poke at, like that the ads were apparently made on a ~~Mac~~ Apple PC – but really, so what? (Many professional design studios do use Macs but that doesn’t mean a Windows PC is not perfectly good enough for home movies).

At last, this campaign seems to be going somewhere, but I can’t help thinking there are a bunch more Bill and Jerry ads waiting to slip out one day.

An alternative view

The links below highlight the views on this subject from a few well-known Microsoft-watchers:

Continuing the series of posts about design considerations for Microsoft Active Directory (AD), based around the MCS Talks: Enterprise Architecture series of webcasts, this post discusses the design considerations for the creation and use of security groups within Active Directory.

First of all, let’s recap on the various group scopes.

Account groups are used to group users and computers. There are two types:

Global groups may contain members from their own domain (only).
Universal groups may contain members from any domain in the same forest and their membership is included in the global catalog in order to support mail-enabled groups.

Permissions may be assigned to either type of group (as long as they are in the same or a trusted domain).

Resource groups are used to assign rights and permissions and, again, there are two types:

Domain Local groups may contain members from any trusted domain in any forest (so are required if there is to be a cross-forest group membership).
Built-in local groups.

Permissions may be assigned to either type of group but only in their own domain.

Some organisations will ignore the differences in group scope if they are using a single domain environment, as the various types of group will function in a similar manner; however it’s worth considering that the forest/domain design may change over time (e.g. as a result of business changes) and so it is always good practice to use the appropriate group type.

The recommended approach is to add users to account groups, then add account groups to resource groups and use the resource groups to assign permissions on objects.

One consideration is nesting – whilst nested groups help to keep the size of the kerberos token down (Microsoft knowledge base article 263693 is old now, but explains why this this may be an issue), it can also make auditing difficult. Nesting is not to be totally avoided; however the complexity of the nested groups should be carefully considered. In particular, nesting groups into the built-in Administrator group should be avoided as it creates a potential “back door” into a system – anyone with the ability to add users to one of the nested groups can effectively make themself an administrator!

Adding users directly to a domain local group is not good practice but there are situations where it can be useful. For example, if there are two forests with a trust relationship, adding user accounts from one forest into a domain local group in the other may be preferable to adding a global group from the trusted domain to the domain local group, which effectively delegates control over the domain local group to the administrator in the trusted forest – almost certainly undesirable.

Basically, add users to account groups, account groups to resource groups and assign permissions to resource groups where possible but sometimes a little flexibility may be required.

In the next post in this series, I’ll take a look at the design considerations for domain controller placement and the associated site links.