Retrieving Package Source Path/Application Content Locations from SCCM

We've been running with an old file server and a new file server for our SCCM package sources for a while now, with all the new software being put on the new server, and obsolete software being deleted from the old server as it goes out of use. Over time the old server should be used less and less as a package source, until it falls out of use and is decommissioned, but we really need to get a shift on with getting everything off the old hardware, and onto the new one. To make things easier for future moves the new one's referenced in all our systems with a fairly generic DNS name (rather than an old and obscure machine naming scheme), which should also make future server changes easier to manage.

So the first thing that I need to do is trundle through SCCM and work out what software is still using the old server as its source. There are a few main categories of bulk content that could be referencing files on that old server:

1. Programs (using the Package Model)
2. Driver Packages
3. Applications (using the Application model)

Any of those could have their content files stored on either server. Packages are fairly easy as you can add a column to the console called "Package Source Path" and then sort by that. Applications are not so easy; each Deployment Type within an app has its own individual source path, and you have to drill right into the Deployment Type's properties to see it, there's no quick and easy way to see a list. (Obviously things like OS Images, Boot Images, etc could also be on the old server but we've only got single digit numbers of each of those, so they're just as quick to check one by one).

Packages (and Programs)

First the easy options, Packages and Driver Packages. Packages have one Package Source Path for the whole Package, which is used by each Program in the Package. All we need to do is use a cmdlet to retrieve all of the packages, then just pull out the properties from each that we're interested in, and finally dump that to a file that we can open in Excel and work our way through:

(All of the below PowerShell commands to be executed from a Config Manager PowerShell window, or a normal PowerShell command prompt with the ConfigurationManager module loaded and the current location changed to the Config Manager PSDrive for your site).

PS ABC:\> $Packages = Get-CMPackage
PS ABC:\> $Packages | Select-Object -Property PackageID, Name, PkgSourcePath | Export-Csv -Path C:\temp\PkgSrc.csv -NoTypeInformation

Driver Packages

These are very, very similar to normal packages. So similar that you may not even notice there's six extra letters in the initial cmdlet.

PS ABC:\> $DriverPackages = Get-CMDriverPackage
PS ABC:\> $DriverPackages | Select-Object -Property PackageId, Name, PkgSourcePath | Export-Csv -Path c:\Temp\DriverPkgSrc.csv -NoTypeInformation

Both of the above (Get-CMPackage and Get-CMDriverPackage) are relatively quick, they took less than a minute even running them from a remote machine against a site with a large number of [driver] packages .

Application model applications

Ok, here we go, here's the big one. Each Application can have multiple Deployment Types, each of those deployment types (which can each use a different deployment style) has its own, individual Content Location. To add to this, these queries are slower than their equivalents in the Package model (we're talking multiple minutes rather than seconds), long enough that there's some progress text output during this one, just to let you know that it's actually doing something. Then finally details of the app's Deployment Type(s) are all listed in a big XML property of the Application object, rather than each being their own object properties.

Here we are. Firstly we get the full list of apps from the site (which is the part that I've seen take 10 to 15 minutes on a site with around 800 app model apps), then iterate over them, pulling the relevant properties out of the XML (including iterating over each Deployment Type in that app), then finally output all of that as an object which we write to a CSV file:

$CSVOutPath = 'c:\temp\AppSrc.csv'
#Change to your site's ConfigMgr PSDrive before running this script

#Get each Application, then get the source path from each Applications's Deployment Types
Write-Host "Fetching application details - this takes a few minutes, please wait...`n"

$Applications = Get-CMApplication
$AppCount = $Applications.Count
Write-Host "$AppCount applications found.`n"

#Iterate over the apps list pulling out the details for each app. Takes a couple of minutes.
$i = 1
$AppSourceList = ForEach($App in $Applications)
{
    Write-Progress -Activity 'Checking apps and deployment types' -Id 1 -PercentComplete $(($i / $AppCount) * 100) -CurrentOperation "app $i / $AppCount"
    $PackageXml = [xml]$App.SDMPackageXML
    #An app can have multiple Deployment Types, each with their own source location. DT details are stored in the XML properties
    ForEach($DT in $PackageXml.AppMgmtDigest.DeploymentType) {
        $DtTitle = $DT.Title.'#text'    #need to quote property names with hashes in them, normal backtick escaping doesn't work
        $DtTech = $DT.Technology
        $DtLocation = $DT.Installer.Contents.Content.Location
        New-Object -TypeName psobject -Property (@{AppDisplayName = $App.LocalizedDisplayName; PackageID = $App.PackageID;
        CiId = $app.CI_ID; Enabled = $app.IsEnabled; Superseded = $app.IsSuperseded; HasContent = $app.HasContent;
        DepTitle = $DtTitle; DepTypeTech = $DtTech; DepTypeSrcLocation = $DtLocation})
    }
    $i++
}

#$AppSourceList | Out-GridView
$AppSourceList | Export-Csv -Path $CSVOutPath -NoTypeInformation

Download the Get-ApplicationSources.ps1 here: GitHub Get-ApplicationSources.ps1

(No download for the Package and Driver Package sources, as they're basically just one-liners).

SCCM Detection Rules for Dell BIOS Updates

I've been doing a bit of work lately on deploying Dell BIOS updates using SCCM. This is using SCCM's Application Model to deploy the updates out to live machines, and also using those to update BIOS firmware during OSD Task Sequences. I've been a through a few versions of SCCM app detection rules for these jobs. The problem is that WMI's SMBIOSBIOSVersion is a text field, so it's returned as and then treated as a string type. There's also nothing that standardises how manufacturers fill in that text field, so they can use whatever versioning scheme they want, with whatever text they want around it. So different manufacturers do it different ways and they often change it between models.

Dell (at least for their Optiplex and Latitude business products) seem to use two different BIOS version number schemes at the moment, they seem to use one on older models, and the other for newer models, and they each have their own challenges. The first scheme uses an "A" followed by a two digit integer, counting up from zero, eg "A00" followed by "A01" then "A02" with "A09", "A10", "A11" being later in the series. The second scheme is a three part version number separated by dots (full stops, periods whatever your region calls them), eg "1.0.0", then "1.1.0" and later releases may be "1.6.2", "1.9.3", "1.11.2".

Taking them one by one, the problem with the "A00" scheme is that it's a mix of letters and numbers, so you can't do a purely numeric comparison to get the larger number, but at least a string greaterThanEqualTo (-ge) comparison of them does work, and you can always remove the leading "A" and then just do a numerical comparison.

Unfortunately the "1.0.0" type scheme works perfectly with a string greaterThanEqualTo (-ge) comparison right up to point where any of the numbers in it become double digits, so '1.2.0' -ge '1.0.5' returns True, whereas '1.12.0' -ge '1.3.5' unexpectedly returns False. This is because it's comparing each digit in the number one by one, so the first digit "1" is the same in both, then the dot is the same in both, then "1" is less than "3", so the greater than test fails, even though 12 is bigger than 3 it only looks at the digits individually.

The end result of this is that I'm now using the following PowerShell script in a script detection rule for Dell's BIOS updates. You just put the version number of the BIOS version that you're deploying in the variable in the first line then it parses it all correctly from that.

$NewBiosVer = '1.13.0'
$CurrentBIOSVer = (Get-WmiObject -Class Win32_BIOS).SMBIOSBIOSVersion
#Check if this is old-style Dell BIOS versioning "Ann" or new-style "n.n.n"
If ($NewBIOSVer.StartsWith('A') -and $CurrentBIOSVer.StartsWith('A')) {
    If ($CurrentBIOSVer -ge $NewBIOSVer) {
        #To indicate software is found, return something in STDOUT
        Write-Host "BIOS Version $CurrentBIOSVer found"
    } else {
        #To indicate software not found, don't return anything to STDOUT or STDERR
    }
} ElseIf (($NewBiosVer -match "^[\d\.]+$") -and ($CurrentBIOSVer -match "^[\d\.]+$")) {
    #Check if we've got a problem with two digit decimals (where 1.9 is less than 1.10 in version numbers, but not numerically)
    $NewBiosVerArray = $NewBiosVer.Split('.')
    $CurrentBIOSVerArray = $CurrentBIOSVer.Split('.')
    If ([int]$CurrentBIOSVerArray[0] -ge [int]$NewBiosVerArray[0]) {
        If ([int]$CurrentBIOSVerArray[1] -ge [int]$NewBiosVerArray[1]) {
            #To indicate software is found, return something in STDOUT
            Write-Host "BIOS Version $CurrentBIOSVer found"
        }
        Else {
            #To indicate software not found, don't return anything to STDOUT or STDERR
        }
    } else {
        #To indicate software not found, don't return anything to STDOUT or STDERR
    }
} Else {
    #Doesn't fit either BIOS version format???
    #To indicate software not found, don't return anything to STDOUT or STDERR
}

For the task sequence step's run conditions I'm doing two WQL queries, one for the device's model, and the second a simple check that the BIOS version is not the one that the update's looking for (so that machines on our nominated version skip the step) and then the Application's detection rules check fully whether the currently installed version is older or newer than the one we're installing (using the above script).

Retrieve LAPS (Microsoft's Local Admin Password Solution) details using VBScript

History

We've been Microsoft's LAPS (Local Admin Password Solution) as a solution to manage the local administrator passwords on the majority of our servers (excepting domain controllers, for obvious reasons) for a while now. The fact that we'd been living with all of our servers having one or two incredibly simplistic passwords that hadn't changed for the best part of a decade, was giving us so many potential problems, from the ex-employee knowing the all the keys to the kingdom problem, to the straightforward pass-the-hash attack, and LAPS has worked well to mitigate those problems. For our server admins the options of reading the raw password from ADU&C, or using the PowerShell module, or even using the barebones LAPS GUI were fairly straightforward.

The Present

Now we're expanding our LAPS usage to manage the local admin passwords on all of our desktops and laptops. I know that most companies roll LAPS out to their laptops first and their servers last, but the fact that we'd been regularly changing the admin passwords on our laptops and desktops roughly twice a year for years meant that it wasn't needed so badly there.

For our desktop admins, and our helpdesk staff, we can't just point them at the installer for the PoSh module and leave them to it, so we're giving them the LAPS GUI client, but also integrating LAPS password lookup into some of the existing tools that we provide them. This means that I needed to retrieve the LAPS info using VBScript, rather than PoSh, to integrate into one of these tools. All of the examples in the LAPS documentation, and in everyone else's web write-ups of LAPS, use PoSh, so I had to pull this together from a few other scripts and tools that I'd used.

Download

Download the script here: GitHub: LAPS-Password.vbs

Find objects within folders in the SCCM Console hierarchy using PowerShell

Frustration

Ever since Microsoft's SCCM got the new-style System Centre console with SCCM 2012, I've been massively frustrated about how difficult it is to find items in the console once you've organised it with folders. Probably not too much of a problem if you're a lone SCCM admin, but as someone who works as part of a larger team who all use SCCM for slightly different reasons it can be a nightmare finding things like collections buried deep in the folder hierarchy.

Yes, I know that the console has a search function, and I know that there's a subtle "All Subfolders" button that magically appears on the Search ribbon bar sometimes. However that "All Subfolders" button has a few major flaws: 1) it doesn't always appear when it ought to, leaving you in a dance of clicking in the search text box, clicking away, clicking back in there, clicking away to another part of the console, clicking back, all the while crossing your fingers that the button will show up; 2) annoyingly clicking the "All Subfolders" button clears out any text that you may have foolishly typed into the search bar already before you remembered that you wanted to search the whole tree; 3) most importantly, the search results don't give you any information about the folder path that it found each item on, so it doesn't help you find that item (or similar items that may be in the same folder) quickly next time.

SCCM console rant over.

Journey

So over time I started casually looking around for ways to access this folder hierarchy info. These days there's a regularly updated set of SCCM PowerShell Cmdlets provided by the ConfgMgr team, this seemed an obvious place to start. Unfortunately, none of them even acknowledge that console folders exist. Next I set off on a hunt through WMI on the site server (using one of my favourite tools WMI Explorer (WMI Explorer downloads), but I couldn't any folder related properties on the collections/packages/etc themselves and couldn't find any obvious looking WMI classes. Real desperation now, open up SQL Management Studio and hunt through the Views in the site database. Nothing obvious. Brick wall hit. I went away and worked on other stuff for a while.

Enlightenment

Then early last week I came across this blog post by Peter van der Woude, that my previous searches had somehow missed: More than just ConfigMgr: Get the folder location of an object in ConfigMgr 2012 via PowerShell. Finally, answers - not only did that post contain this magic phrase: A good thing to know is that all folder information is stored in two classes in WMI, SMS_ObjectContainerNode and SMS_ObjectContainerItem. These two classes are the same for every object type., but it also had a working script linked, find his script in the TechNet gallery here: TechNet Gallery: Get the location of an object in the console via PowerShell

Moving Beyond

As great and useful as Peter's script was, it does have a minor flaw, and doesn't handle some edge cases. So I set off to use his information to write my own. The minor flaw was that his script requires hard coding your SMS Site Code and Site Server names into it. I can see the reason for that, especially as it means that his script has no external dependencies (other than the ConfigMgr infrastructure, obviously) but it still bugged me. More problematically, I hit an edge case that it didn't handle within my first few uses of it. Some objects (of different types) in SCCM can share the same SCCM IDs. So a Collection, a Query and a Package could have the same 8 character ([site code][5 hex digits]) ID, as all of those objects have their own numbering starting from XXX00001 and counting upwards. So using Peter's script, you don't always find the object that you're actually looking for, and, as his doesn't echo the name or type of the object that it's showing the hierarchy for, it can get quite confusing if it's not showing the info for the item that you're expecting.

Nirvana (or Farvana)

So, I've written my own PowerShell function to do this: Get-SCCMObjectLocation, find the code on GitHub, here GitHub: Get-SCCMObjectLocation.ps1. There's a bit more code here than Peter's versions, but this now outputs the object's name and type (so that you know you haven't made any typos, and you really have found the droids object you were looking for), and if there are multiple objects with the same ID, it lists them one by one. It also gets the site code and site server name from the ConfigurationManager PowerShell provider, though this does mean that you need the SCCM console installed on your machine, and you need to change to ConfigurationManager's PSDrive before running it.

Usage:

PS C:\>Get-SCCMObjectLocation -SMSId "ABC001BB"
root\Racked Server Drivers\Dell\PE1950-Microsoft Windows 2008 R2 SP1-OM7.3  [SMS_DriverPackage]

PS C:\>"ABC000CC" | Get-SCCMObjectLocation
WARNING: Multiple objects with ID: ABC000CC
root\x64\Test\Win 7 Ent x64 with Office 2010  [SMS_ImagePackage]
root\Servers\Server roles\All Domain Controllers  [SMS_Collection_Device]

PS C:\>Get-SCCMObjectLocation -SMSId "ABC00166" -SiteCode ABC -SiteServerName sms01.example.com
root\Application Deployment\MS Access App-V  [SMS_Collection_User]

Download

Download the script here: GitHub: Get-SCCMObjectLocation.ps1

---

Music to get through this with: Faithless - Faithless 2.0

Deploying Adobe LiveCycle Launchpad ES2 (9.5) for use by end users

As in many companies these days, our users don’t have administrative permissions to their PCs or to the various servers and services we give them access to. This means that the standard one-click web page deployment of LiveCycle Launchpad won’t work for our users, and also we have to configure the permissions within LiveCycle to give them the permissions needed. Here’s how we got it working:

Throughout this please replace any references to "LiveCycleServer" or port numbers in URLs with the appropriate ones for your environment.

Software Deployment

• Log into your LiveCycle server's admin console (as a user with at least some admin privileges):
  http://LiveCycleServer:8080/adminui/
• Then go to http://LiveCycleServer:8080/launchpad
  You should be able to download the .AIR executable from your server from this page, its address will be http://LiveCycleServer:8080/launchpad/installer/LaunchPad.air ).
• (If you haven’t already) Sign up to Adobe’s AIR Runtime distribution agreement, this should get you a link to the direct download for the corporate deployable, bare-bones, all-in-one, AIR runtime installer.
• Once you’ve been sent the link to the "Download Adobe AIR Runtime" page, you want to download the installer files under the "Adobe AIR Runtime Installer files: For use with a native installer or through CD/DVD redistribution using the Adobe AIR side-car configuration" heading.
• Put your LaunchPad.air and AdobeAIRInstaller.exe files into a folder together, and you can now push out the two together, with a command line like:
  AdobeAIRInstaller.exe -silent -eulaAccepted -programMenu LaunchPad.air
• Finally the first time that you run the LiveCycle Launchpad app, you’ll notice that the servername, protocol and port are all set to defaults, and not to your server’s settings. Have a look in c:\Program Files\Adobe\LiveCycle ES2\Adobe LiveCycle Launchpad ES2 on a PC that has Launchpad installed and you should see a Server.xml file, copy that to your distribution location, open it up in a text editor and change the server details to match your environment. You can now push this file out along with the Launchpad app to give your users the correct default settings (I just use an Xcopy to put this in the folder after install).

Now you’ll find that any users (who don’t have admin permissions within LiveCycle) who try to log into the Launchpad app will get an error like: "Server configuration specified here is invalid. Do you want to reconfigure the server settings?"

Permissions

So, once users have the app, you need to ensure that normal users can use it without needing admin access all through the LiveCycle server.

• Log into the LiveCycle admin console (as a user with at least some admin privileges):
  http://LiveCycleServer:8080/adminui/
• Go to Settings -> User Management -> Role Management
• Create a New Role, I called mine LaunchPad User, and obviously fill out the description field


• Assign them enough permissions to use the Launchpad app, according to these articles they need these permissions at a minimum they’ll need "Repository Read", "Repository Traverse", "Repository Write", "Document Upload" and they’ll also need the PDFG User role assigned as well. Depending on your LiveCycle config, and which modules you have, you may have to give them additional permissions to other modules to give them all of the available modules. See these articles for more info on permissions needed: Adobe Knowledgebase: Unable to use LiveCycle Launchpad services without administrative role - LiveCycle Launchpad ES2 (9.x) and Adobe Forums: Launchpad ES2 - Logging In Issue.


• Now assign these roles to end users (or preferably to a group to keep things tidy).

Done! You should now be able to deploy and give your users access to LiveCycle Launchpad. Next up (hopefully) deploying the LiveCycle ES2 PDFG Windows printer to your non-administrative users.

ServiceCenter/Firefox Printing Redux

Some may remember this post from back in July when I was having trouble printing from a web app after upgrading from Firefox 1.0x to Firefox 1.5. Wherein I laid out a way to fix the problem using a custom usercontent.css file, and also logged a bug on the Mozilla Bugzilla system.

Well it looks like its come to an end! Not with today's Firefox 2.0.0.1 update, as you might imagine. But the latest 'Minefield' (Firefox 3 alpha) builds have the new "reflow" changes (from Dbaron's bug 30030) in them.

And it works!!

So now we just need to wait for Firefox 3's release and the whole world can feel the love!

Active Directory Group Membership Queries

The problem with being known as the person who can pull a list of group members from AD into a text file in a few seconds, you become a "go-to guy" for other AD queries. Which wouldn’t be such a bad thing, except that there aren't pre-written scripts for them all! I received a request today to ask if I could pull out a list from AD of everyone who was a member of both a departmental group and a security group, here's how I did it.

List the Members of an AD Group

For anyone who doesn't know already, there are a couple of easy ways that I know of to print a list of the members of one active directory group to a text file:

The "Command Line One-Liner"

As always with something that looks simple you need to put in a little work first, this time it’s very easy. First download the very useful psExec utility from the Sysinternals website. This handy little tool lets you run commands on a remote machine as if you're logged directly onto it. Extract that and save it somewhere, preferably in your path.

Now all you need are a few bits of information that you should already know if you’re thinking of running this sort of query: the name of a domain controller on your network, and the username and password of an ID that has admin rights on that DC (unless your normal login account has these rights, in which case you really ought to do a security review ;-) ).

Then run the following command from a command prompt:

psexec \\domain_controller -u domain_slash_userid -p password net group "group name"

This will list all of the group members to the command prompt, to redirect this output to a text file, just add "> c:\temp\groupmembers.txt" to the end, eg:

psexec \\domain_controller -u domain_slash_userid -p password net group "group name" > c:\temp\groupmembers.txt

The VBScript (or Perl) Method

Go to the Active Directory Cookbook's Source Code page and download Script 7.2 "Viewing the direct members of a group" in VBScript format (or Perl if you have Perl installed and are more comfy reading that).

Save the script somewhere, open it up in Notepad and replace the <groupdn> bit with the path to your group. Now change to a command line and run either:
"cscript View_Group_members.vbs" (for the VBScript version) or
"perl View_Group_members.pl" (for the Perl version)

While it is possible to just double-click either file in Explorer to run them, you don’t want to do that; the VBScript version will pop up an alert box on screen for each group member (meaning if you have a group with 100 members, you’ll get 100 alerts on your screen one after the other, each one wanting you to click OK), whereas the Perl version will dump its output to the command line then close the window before you have time to read it. So drop to a command line to run them.

If you want to send the output to a text file then (as above) just append a right facing angle bracket and the name of a text file, eg: cscript View_Group_members.vbs > c:\temp\groupmembers.txt perl View_Group_members.pl > c:\temp\groupmembers.txt

Listing Everyone Who is Both a Member of Group A and Group B

(intersection of groups A and B)

Now listing everyone who is a member of both Group A and Group B is slightly more difficult, and I couldn't find a script online that pulls that out for you - so I wrote one myself. This is a Perl script as I've known Perl for years, and whilst I can read simple VBScript fairly well I wouldn't want to try writing it. So if you want to run it you’ll need to have a version of Perl installed, I can recommend ActiveState’s ActivePerl (see below for download instructions).

This is an adaptation of the above Perl script (http://rallenhome.com/books/adcookbook/src/07.02-view_group_membership.pls.txt for anyone who hasn't downloaded it yet) that pulls out the members of the two groups, hashes them, then prints the intersection to the command line.

The fine print at the bottom of the Cookbook's source code page seems to suggest that it’s ok to modify and distribute the code as long as the acknowledgement and citation are kept intact. So you can click to download my "Viewing the intersection of members of two groups".

---

Note 1: Downloading ActivePerl

• Go to http://www.activestate.com/Products/ActivePerl/
• Click Get ActivePerl
• Select Free Download
• Click "Continue" (no need to fill out the form if you don’t want to)
• And choose a download format.
• Save and install

(Note to self: see also Kbase 1027070447)

Unisys ServiceCenter Firefox printing fix

For anyone still living in Unisys-land (aren't I glad they're not filling out my wage slip any more ), and for anyone else forced to use their "idiosyncratic" (read shite) web tools here's a little something.

If you've been forced to use the web (ie HTML not Java) version of their (Peregrine-based) ServiceCenter tool, you'll notice that its dog-slow if you're using IE and has a whole myriad of intermittent problems. The obvious, and really quite effective, solution is to use Firefox. This speeds up ServiceCenter measurably and seems to get around most of the other problems.

Or at least it used to. Firefox v1.0 to v1.08 all work absolutely perfectly, but Firefox 1.5 introduced one teeny-weeny and yet show-stopping printing bug that stops you from being able to print any useful info from ServiceCenter (technical details here in Mozilla bug 326162 if you're interested). Unfortunately according to the recent Firefox 2 beta release it doesn't look like it'll be fixed in Firefox 2 when that's released , and checking Firefox trunk (the ongoing work to create the not even alpha yet Firefox 3) the bug actually looks even worse at the moment.

So after reading this page on creating your own "user stylesheets" in Mozilla and this page that mentions a new experimental CSS rule, I put two and two together and actually came up with four for once!

So here's how to get Unisys ServiceCenter printing correctly in Firefox versions 1.5 and newer:

• Download a recent version of Firefox
• Run it
• Close it
• Find your Firefox profile folder (see here if you can't find your profile folder, and bear in mind that your profile may be in a Windows network roaming profile, or may be on your C drive).
• Inside your Firefox profile folder look in the "Chrome" folder
• Do you have a file in there called "userContent.css"? If so, open that file in Notepad, if not create a new text file with that name and then open it in Notepad.
• Paste the following text into the "userContent.css" file:

  
  /* Fix b0rked ServiceCenter printing in Firefox 1.5+
  see Mozilla Bug 326162 https://bugzilla.mozilla.org/show_bug.cgi?id=326162 */
  
  @-moz-document domain(www.sc-ps.unisys.com){
  div.labl, div.val { overflow:visible !important; } }
  

• Save the file
• Open Firefox
• Re-visit ServiceCenter and try printing a ticket out
• Send me thanks, adoration, first-born children, money or just leave me a comment below saying how it worked out for you (actually forget the first-born children I wouldn't have a clue what to do with them).

One final note, Unisys have been known to change the server these web apps are on periodically, if so you need to edit the bit that says domain(www.sc-ps.unisys.com) to reflect the new server name. This may or may not work for other company's Peregrine web interfaces, may be broken at some point in the future by an upgrade to the website or to FIrefox, YMMV). Also this Mozilla bug may be fixed at some point in the future, so at that point you can safely delete the above lines from Firefox's userContent.css.

In the end there can be only one!

Steve's abandoning me then So I guess the time has finally arrived when I have to deal with the muppets on my own.

"We Are Not Afraid" campaign spreads to Cowes

Isle of Wight Today - RECORD FIREWORKS CROWN BUMPER WEEK

Not specifically blogging about that news story, but I've just been away for a week racing a J/109 at Cowes Week (sorry, Skandia Cowes Week 2005 to give its full official title) and the presence of a "We Are Not Afraid" symbol on the side of the Class 0 yacht Nokia Enigma has me in two minds.

(photo is from the above story in the Isle of Wight County Press)

On the one hand I'd spent the previous 3 weeks working in London every day, and was looking forward to a week of racing, recreation and alcohol abuse where I could forget about any and all world issues, yet this is here forcing world politics to intrude on my time off.

On the other hand its heartening to see that not only can a huge international event like this (over 1000 boats raced in Cowes Week this year, with many of them carrying over 6 crew, some as many as double or triple that) carry on almost exactly as normal despite the happenings in London, but there are also people here proudly displaying the fact that they are getting on with everything and not letting "the terrorists win".

I'm not exactly a Londoner by the classic definition, but I do commute into and work in London every working day (and a few weekends) and I've continued to travel into London and work there every day since 7th July (apart from a week off for Cowes, obviously). Despite the terrorist's attempts to scare us all away I've fought through the crowds, been insulted by security guards, been under constant scrutiny from the Police (City Police, Met Police and British Transport Police), security guards and the general public, and been on constant lookout myself. Yet I still love this City and wouldn't want to work anywhere else.

Some people call it the "Blitz Spirit", some call it typical British pig-headedness and stiff-upper lip resolve - I don't what it's called really, but very, very few people are letting these attacks affect them any more than they absolutely have to, and everyone is back at work as normal and London is still the buzzing, vibrant, multi-cultural great place that it always has been.

This one's for Steve

From this year's Big Brother contestants:

Science: "These cups are filthy all the time."
Eugene: "I always drink tea and coffee normally out of a mug, but when I'm around my friends I drink it out of a glass. One of my friends, him and his family, they drink out of pint glasses, everything and including tea."

Potential Poo

Q: How much potential poo am I in at the moment?

A: An awful lot!

Thoughts on default and recommended security modes and what it reveals about the people expected to use the systems.

When you have a large network, with a large number of servers, and a number of network/server administrators there essentially two different ways to set up the supervisor/administrative rights and which route you go down reveals a lot about your overall philosophy.

Method 1: Restrict each person's network rights to exactly what they need for day-to-day work and precisely no more. If they do need to do anything else they can use a specific administrative account (or supervisor account, or superuser depending what world you inhabit) to carry out their business.

Method 2: Give all of your administrator's network accounts full administrative privileges to each resource that they might need (or even everything depending on the size of the network, and the person's role).

There are definite advantages and disadvantages to each approach.

Method one means that your admin's own network accounts only have limited rights, this means that they are a less worrying vector for viruses, they're less likely to cause catastrophic problems by accidentally clicking the wrong thing and you can control who needs the passwords for various resources.

The downside is that you can't control who knows the passwords, someone extra will always need it for some reason, or will notice it whilst it is used for some othert reason and you can only control it by regularly changing your admin passwords, and keeping a (secure) database of them all.

Method two means that you can audit who did what, every admin level action on the network will have an actual person's own ID against it, it means that work for admins is less of a hassle: less passwords, less logging in and out all over the place with 30 different passwords, less time spent performing quick and easy tasks.

The downside is that if any of your admins happen to become infected by a virus, or are simply having a bad day and making an awful lot of mistakes, then they can wreak havoc on an unparalleled scale.

From what I've seen experienced, method one is the method that pretty much every network admin training course reccomends, and most Linux/Unix networks actually carry out ("su" is your friend) whereas despite the official guidelines most Microsoft based shops tend to either be configured as method two (or a mixture of the two).

Well I'm sitting here at work with a couple of pints inside me. It's the last half hour, I've done a fair amount of work this abo, and I've even updated my weather script to show actual weather phenomena using the far more optimal hash based lookup table implementation.

Yet I can't shake off the feeling that I've been awake for too many hours without sleep, and I really could do with curling up in a quiet corner somewhere and going to sleep.

I think I'm going to have to spend the next 23 minutes chain-eating my Penguin mints (mmm, caffeine) and hope that I don't eat so many that I end up bouncing off the walls on the train home!