bloggingIT

Now that MS Office 2007 is doing the rounds, I suppose it’s time to lookat some of its shortcomings.

It has a few when it comes to deployment. The biggest nuisance being deployment.

You have four options:

• Install it on a PC manually (not great)
• Deploy through group policy with no customisations
• Use a deployment system such as SMS
• Use a computer startup script

You may as well just say “no” to the first one. Anything more than a handful of PCs and you have a tedious task.

Group Policy has always been my method of choice. Most of my clients have less than 100 PCs, so Group Policy deployment is ideal. But as pointed out in the list, you cannot customise the installation with any defaults.

SMS is out. It’s not worth explaining to clients why it’s a good idea to buy software that makes my life easier. Even though the effort and management might simplify things somewhat.

So we’re stuck with computer startup scripts. Another method I hate - but if you want to control Office Deployments, then this is the way to do it. Thankfully, Aaron Parker has posted some startup scripts to help with this using the MSP method.

If you are using a network with WSUS, then updates become a non-issue, and I think that the only time to need to redeploy is if you decide to change the application packages that you want. At which point, you could check that executables of the programs exist or record your own registry entries that you can check for.

It’s not a great method (I’ve managed to avoid having to use ANY computer startup scripts in 2000-based networks) - but there’s no reason why it shouldn’t work. Especially if you make sure to use the quiet options in the Setup /admin tool.

Office, eh?

Windows Vista. It’s big, bad and insists its new technologies upon unsuspecting users while not actually working quite right.

The Vista Sidebar is one such culprint. Ever since the early previews of Vista (aka Longhorn), there was a giant box hanging around the desktop on the right side that had a giant clock in it.

Of course, that has now become sidebar gadgets - which can live on your desktop.

It’s a poor tradeoff though. We’ve lost Active Desktop.

Foisted upon an unsuspecting user base. Active Desktop was pitched as a portal to an always-on internet with IE4 or Windows 98. The fact that barely anyone had an always-on internet connection seemed irrelevant. But you could put loads of webpages in little windows on your desktop, or just replace your wallpaper with a web page or HTML page.

Until recently, I’ve found this pointless - but for networks running an intranet such as Sharepoint, it’s the perfect solution. A user logs on, and on their desktop appears the site’s intranet. At a single glance you have all the information you need from your intranet. If you click on a click, a new IE window opens, and you carry on from there. Simple, and very effective.

Vista comes along and as surprisingly AD was put into Windows, it was taken away again. Gone forever (probably). Now, considering how much old Windows fluff is still hanging around in Vista (old Font dialog box, anyone?) it seems that this is a bit of an own goal on Microsoft’s front.

The suggestion now is that I have to write desktop gadgets to do the same jobs as a webpage would. And to make matters worse (and here’s the kicker), Desktop Gadgets does not support roaming profiles! So you move from one computer to another, and the sidebar smugly sits there with its clock, photo slideshow and newsfeeder. So even if I did make those gadgets, they would currently be about as much use as a Dell laptop battery.

Fantastic! So for network administrators - there is now no native way to access an intranet or any other application service with a user specifically going there. And I can really see illiterate computer users making sure that they start IE and go to the intranet when they log in. Yeah, right!

Thank you Microsoft, good night!

I was having a great deal of trouble installing printer drivers in Vista for the Xerox Phaser 6100.

Online, Xerox say that the XP drivers wok fine in Vista, so use them until the new drivers come out. I’ve spent two hours trying the get the badger to work.

And what was it in the end? Stupid driver defaults!

• Right-click on the printer
• Click run as administrator
• Click properties
• Clear any UAC prompts
• Click on the Advanced tab
• Click ‘Printing Defaults…’
• Click Graphics
• Click ‘Adjust Color’
• Click ‘reset’
• Keep pressing OK until the windows are cleared

Now send a print job! That’s it. Really!

It happens enough times. You’re busy reinstalling Windows for someone when you find that you can’t install Windows Updates because the internet connection available is slowly than a milk float delivering breeze blocks instead of milk.

In so far as keeping up-to-date, the issue is no longer “How soon can the updates be installed on the computer?” It is actually “Can I even download updates on my computer?”

The odds are that if you are using Windows XP pre-SP2, the answer is simply ‘no’. Whenever you’re behind on a service pack, Microsoft likes to ensure that this becomes part of the download set. And that 200MB+ download might take a little while on dial-up. Once you’ve completed this, you’ll probably find another 100MB+ worth of updates to install afterwards.

Thankfully, there are a number of ways around this.

Downloading the redistributable versions of the various service packs is a piece of cake - they can be downloaded from the Microsoft website without too much effort. The subsequent rollups prove to be more of a nuisance.

Enter AutoPatcher. This is a handy little project for those folk who have all of those problems, and then some. What I particularly like is the semi-frequent updates that do not require you to download a complete CD of updates. So having a full download and the latest update CD does the job nicely. On my next visit to this school where I need the files, I’ll hopefully be able to install the updates with the minimum of fuss - then I’ll be a happy chappy.

Go get it!

Yes.

Although only half a year for a user such as myself.

As I’m happily dual-booting between Ubuntu and Windows at the moment, it becomes clear that in British Summer Time (BST), Windows and Linux disagree on how the computer clock should be interpreted.

What’s really a nuisance is that I keep staying up an hour later than I intended!

Basically, the problem boils down to how Windows and Unix-based systems interpret the computer’s internal clock. There’s more about this here, including some pros and cons of either system.

Windows takes the local computer clock time, and treats it as a ‘local’ time. That is, the clock matches the time that it should be in the region. Mac and Linux systems treat the computer’s clock as GMT, and then makes any adjustemnts inside the Operating System.

The bottom line is, unless you’re living in a GMT timezone - you’re going to get the time constantly changing as you switch between operting systems on the same computer.

The simplest way to get around this is to ask Windows to use UTC time instead of local time:

Copy and paste the following into a new file called time.reg

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation]
"RealTimeIsUniversal"=dword:00000001

Save the file, and double-click on it. Accept the various warnings that appear.

Once Windows has been rebooted, make sure that the clock is set to the correct time. The time should now settle down as you dual-boot between systems.

Now I’ll be able to go to bed at the right time!

Some grief today as I found that Vista wasn’t behaving with user profiles. Whenever a user attempted to logon, he or she would be greeted with the following popup:

Your user profile was not loaded correctly!

You have been logged on with a temporary profile. Changes you make to this profile will be lost when you log off. Please see the event log for details or contact your administrator.

How annoying is that message when you are the administrator?

Anyway, the event log was equally unhelpful:

Windows cannot locate the server copy of the roaming profile and is attempting to log you on with you local profile. Changes to the profile will not be copied to the server when you log off. This error may be caused by network problems or insufficient security rights.

DETAIL - Access is denied.

What was weird was that some users were creating the username.v2 profiles.

After a bit of trial and error, I realised that the users that had a dynamic roaming profile path (such as %logonserver%\users\%username%) would not locate or create a profile in Windows Vista.

As soon as I replace %logonserver% with the name of a domain controller (\\server1\users\%username%), everything behaved itself.

This is pretty annoying, as I’d have to set up DFS to get around this. In the meantime, I’ve just changed the paths.

There is no evidence to suggest that this is by design, especially considering that using the SET command in Vista shows that the logonserver variable is indeed set.

ARGH!