bloggingIT

I’ve had a problem lately whereby various roaming profiles have the Computer window appear when users log into Windows Vista.

I messed around with a load of settings to try and work out what it was - I thought that as the problem only manifests itself in Vista with the new profiles, maybe it’s mis-interpreting a group policy setting such as the ‘only show personal folders’ setting.

It took a while, but there was no such settin to make My Computer appear in either the Desktop settings or Start Menu and Taskbar.

The offending article is that nigh-on useless Welcome Center that Vista imposes on users when they log in for the first two times. It seems that if you have redirected folders enabled and have turned off the common options for the Start Menu, then the Welcome Center fails to run. What then compounds the problem is that instead of showing the Welcome Center, it shows the Computer window.

Here’s the kicker, because you cannot see the Welcome Center, you cannot tick the box to tell it never to appear again.

A very simple Group Policy fix is actually found in User Configuration > Administrative Templates > Windows Components > Windows Explorer. Here you can find an option to disable the Welcome Center when a user logs in.

Once enabled, the annoying Computer popup is no more.

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?

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!

If you happen to have an Intel PRO1000 network card, you may come across the following error when you open up control panel in Windows:

Intel PROset

resources are not available

The problem for me stemmed from repairing an installation of Windows.

With the Intel Pro-network cards, the software that comes bundled with them includes advanced network components that can be configured through Windows’ Control Panel. When this fails to load, you are likely to receive the above error.

Here’s what I did:

• Download and install the network software using Proset.exe
• Go into control panel, if the error is still present, go to Add/Remove Programs and uninstall the Intel Network software
• Reboot the computer
• Log back in, and reinstall the software. Include the advanced settings AND the WMI options.
• If the network card isn’t working at this point, start the device manager and scan for hardware changes.

If all has gone well, you should now have a working card.

As a point of interest, Windows failed to automatically install the drivers for me, so I had to point to the setup installation directory.

When dropping Windows Vista into an existing network, you may notice some unusual issues that weren’t apparent in Windows 2000 or Windows XP.

The main cause of a headache for me was the new interpretation of the Group Policy settings that Vista utilises.

Because most of the networks that I manage rely on roaming user profiles, it’s not uncommon for me to use folder redirection to redirect the Start Menu and Desktop. These are set so that the user cannot change the contents of these folders, and they specifically show programs that only I allow.

So, all is good. Until Vista came along and the contents of the Start Menu suddenly disappeared. Clicking on the ‘All Programs’ links showed nothing at all. Eeep!

After about 2 hours of searching as to why this might happen, I eventually discovered it was a group policy setting that works differently (and by its interpretation, correctly) to Windows XP.

The setting in question is User Configuration > Adimistrative Templates > Start Menu and Taskbar > Remove User’s Folders from the Start Menu

In Windows 2000 and Windows XP, the setting prevents the user’s profile folders from appearing. This is useful if you are using folder redirection and don’t want the default Start Menu icons to appear. However, Vista includes the redirected folders as excluded, and as such - nothing appears.

The difficulty hunting this down of course is that the group policy results show a successful redirect, which of course is exactly what it’s doing

As I’m using network manager to control wireless access on my laptop and a desktop computer in my home, I’ve decided that the keyring manager is a nuisance.

I couldn’t bear for it to constantly ask for a password every time that I needed to log on to a wireless network to retrieve the stored password. This is further compounded by the inevitable question: “Why do I have to enter my password again?”

Over at the Ubuntu forums the same question has been asked. Thankfully, there is a resolve that will also be included in the Feisty release.

The easiest way for Ubuntu user is to download the .deb package of pam_keyring and install on your system.

Once installed, so the following:

• Open a terminal window
• Type cd /etc/pam.d
• Type sudo gedit gdm
• In the editor, and the following:
  ## Added so that NetworkManager doesn't keep asking for Keyring password. ## relies on having same password to keyring as login password. auth optional pam_keyring.so try_first_pass session optional pam_keyring.so

Save the file, and then try it out.

The catch is that the keyring manager must match your login password. If you have a different password set already, then the only way to make pam_keyring work is to delete your existing keyring and restart:
<strong>killall gnome-keyring-daemon rm ~/.gnome2/keyrings/* gnome-keyring-daemon</strong>

or alternatively change your login password to match your keyring.

Once you have entered the network key of the wireless LAN, you should find that passwords and automatically stored and retrieved.

And this works for any other Gnome applications that use the keyring too.