%Logonserver% session variable doesn’t work on network Vista logon

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!

Resources are not available error when accessing control panel

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.

Windows Vista in “Dude, Where’s my Start Menu?”

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.

Group Policy EditorThe 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

Get Network Manager to stop asking you for the keyring password with pam_keyring

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:
killall gnome-keyring-daemon
rm ~/.gnome2/keyrings/*
gnome-keyring-daemon

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.

Group Policy Application Deployment Woes

I recently managed to cause myself a huge headache when removeing some software via group policy.

The worst part is, I only have myself to blame as the software was wrapped by me using Masai Installer.

If software uninstallation (or installation for that matter) goes bad, then a dialog window will open asking for some sort of input, which should never happen during silent installations.

If this happens while Windows is installing / uninstalling managed software, then Windows will hang and the only way to avoid the installation is to reset the computer.

The way around this is to make sure that you test the MSI by installing and then uninstalling.

The best way is to use these commands:

Install
msiexec /i msifile.msi /qb

Uninstall
msiexec /x msifile.msi /qb

Of course, replace msifile.msi with the name of your MSI installer.

If the MSI installs and uninstalls without any prompts for input, then you know that it will deploy correctly through group policy.

If there is a prompt, then you need to work out how to prevent the prompt appearing during the installation.

Roaming Profiles in Windows Domains

Getting roaming profiles working on Windows Servers is a very simple process, and I generally include this in a script when creating users for the first time.

Here’s a quick ‘how to’ for those that are interested, based on a Windows 2000 or Server 2003 network.

Step 1 – Decide where you want the profiles to live on your file server

  • Log on to the Windows server as an administrator
  • Open the drive where you want your profiles the be stored for the user accounts. It’s worth noting that by default, Windows user profiles stores Application Data, My Documents, Cookies, a few other folders and the profile itself. Needless to say, if you are using the defaults, make sure that you have enough drive space.
  • Create a folder where you want your profiles to live. I generally store user profiles in D:\Users on a server. Make sure that the folder has user read privileges.
  • Right-click on the folder you have just created and click ‘Sharing…’. Call the share ‘Users’ and give all users full access to the share.

Step 2 – Configure a user profile to roam

  • Open ‘Active Directory Users and Computers’. You can find this in the ‘Administrative Tools’ folder on the start menu
  • Find the user that you want to set up a roaming profile for, and double-click
  • Click on the ‘Profile’ tab
  • In the ‘Profile Path’ field, enter the network path to the Users share, and then add the username to it. (eg. \\myServerName\Users\John)
  • Click ‘OK’ to apply the changes to the user account.

Step 3 – Check that the profile is saved back to the server

  • All we need to do now is check that the profile is going to be saved back to the server correctly. So log on to a client workstation with the user that we have just been tampering with. Once logged on, log off again.
  • On the server, goto the User profile folder (D:\Users\) and have a look. In our case, the user was called ‘John’, so you should see a folder called ‘John’. The profile is stored inside here. Well done!

A few pointers

  • Some of the settings in the profile tab directly conflict with the profile path and some other group-policy settings. Don’t be tempted to use the ‘Home Folder’ option if you are using profile path
  • You can replace the username with %username%. This will automatically put the username of the user in for you. This is especially handy when you want to change the path of multiple users at once.
  • If you have more than one domain controller, and the profiles and stored on there servers, you can use %logonserver% instead of \\myServerName. Just bear in mind that you should be using file replication for this to be useful.
  • You may not automatically have access the the profile folder that has been created. If you logged on for the first time in Windows XP SP2, then the default folder permissions will lock administrators out of the profile folder. You need to change a setting in the policy if you don’t want this to happen.
  • When Windows 2000/XP/Vista logs onto a network, the entire user profile is copied to the local machine. When you log out, the profile is copied back to the server. If the user has masses of data in the profile, then you should be using folder redirection to move folders