Posts Tagged ‘User Profiles’

Redirected My Documents folders showing as ‘Documents’ rather than the users name

Monday, December 20th, 2010

Had a complaint from a member of staff recently that all students work folders showed up as My Documents when he was browsing through their work.

Many of you may have been directed to this Microsoft KB as a ‘solution’. http://support.microsoft.com/kb/947222

Not much of a solution if you ask me. Redirection to a subfolder would work, but do you really want to change something that significant on your network? Enable exclusive access would be fine if you didn’t need to give other people access to the documents folder. In a student-teacher situation, teachers need to be able to see the students work, so this doesn’t work for us. Option 3 – deny permission to the desktop.ini. We have 1400 students. That’s a lot of changes – yes I could use xcacls or subinacl to automate it, but what a headache.

The best ‘solution’ that we have come up with, is to simply delete the desktop.ini file at logoff. We created a VB Script, which looks for a desktop.ini file in the user’s My Documents folder, and if it exists then delete it. Attach this into a GPO that affects the user as a logoff script.

The code we used is:

On Error Resume Next
Set WSHShell = WScript.CreateObject("WScript.Shell")
Set FSO = CreateObject("Scripting.FileSystemObject")
DocsPath = WSHShell.SpecialFolders("MyDocuments")
If FSO.FileExists (DocsPath & "\desktop.ini") Then
  FSO.DeleteFile (DocsPath & "\desktop.ini")
End If

Next time the user logs on and then off again, the desktop.ini file will be deleted, and the folder will show as the username of the user.

Shame there isn’t a GPO option which allows you to turn off this feature. On a home machine it is great, but in a corporate environment you need to be able to turn off the fancy features and see exactly what you have got.

2 people found this post useful.

SharePoint Search – Access Denied

Wednesday, September 8th, 2010

Having a bit of a SharePoint day. Had recently noticed that no People were being returned in search results, even if you type in their name exactly.

Went through the check list of possible causes:

  • Default Content Access account permissions to the User Profile Service (Read Profiles for Search Crawler)
  • Full Read permissions on the My Site Web Application
  • Crawl Rule set up for the My Site Web Application
  • Location included in the Content Source

We were still getting Access Denied errors.

Suddenly remembered this little MS article about accessing FQDN’s from the local machine. Turns out it is still relevant in SharePoint 2010.

http://support.microsoft.com/kb/896861

Hope this helps someone else out there with the mysterious Access Denied when crawling Profiles.

Login Script Not Running Windows 2008 Remote Desktop Services (Terminal Services)

Monday, May 24th, 2010

Call today: User has not got any network drives when logging on to the thin clients.

The setup for this is as follows:

  • 2 x Windows Server 2008 R2 servers running RDS, DNS round robin, load balanced.
  • 56 x ThinStation 2.2.2 clients

A VBS login script is applied using Group Policy. All student users have a Mandatory Roaming Profile.

Any user that was not the user that I used to create the template could not run the login script. Took quite a while to work out that the mandatory profile was the cause.

To solve the problem:

  1. Open Registry Editor
  2. Select HKEY_USERS, then click File –> Load Hive
  3. Select the mandatory profile file (NTUSER.MAN) and give it a name.
  4. Right click on the key that you typed in in step 3 and select Permissions.
  5. Remove the user that you used to create the Mandatory Profile
  6. Add in the Authenticated Users (or a different group if you want to restrict access further) and assign it Full Control.
  7. Propagate the permissions to all child objects.
  8. Select the hive that you added in step 3, click File –> Unload Hive
  9. Test.

I suggest creating a backup of the original hive before you make any changes. Just in case.

Now, whenever a user logs in the script should run, and create all of the necessary network drives that you have defined in your script.

Office 2007 – Quick Access Toolbar not saved in Roaming Profile

Friday, March 12th, 2010

Just had a request from a user, who was complaining that everytime that she logs into a computer, she has to customise the Quick Access Toolbar in Word and Excel. (The few buttons to the rights of the Office Button.)

Turns out that the QAT is not stored in the roaming part of the user profile, but the local part. As profiles are deleted when a user logs off, and the user accesses a couple of different computers, the settings were not following her.

When a user customises the QAT, a new file is created in C:\Documents and Setting\%username%\Local Settings\Microsoft\Office\ called word.qat, for Word or excel.qat for Excel.

This default location can be changed by amending a registry entry, after applying a hotfix. The location of the key is:

HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Common\Toolbars

You need to create a new DWORD value called QuickAccessToolbarRoaming and give it a value of 1.

As this was a user policy, we created an ADM file and deployed the changed using Group Policy. The ADM file contains the following:

CLASS USER
CATEGORY "Office 2007 Quick Access Toolbar"
 
    POLICY "Include Quick Access Toolbar in Roaming Profile"
    KEYNAME "Software\Microsoft\Office\12.0\Common\Toolbars"
                VALUENAME QuickAccessToolbarRoaming
                VALUEON NUMERIC 1
                VALUEOFF NUMERIC 0
    END POLICY
END CATEGORY

To use this:

  1. Copy the above code into Notepad
  2. Save the file with a .adm extension, e.g qat.adm.
  3. Open Group Policy Management and then the desired GP.
  4. Right click Administrative Templates -> Add/Remove Templates
  5. Add in the template that you saved  in step 2.
  6. Go to View –> Filtering and then untick the box labelled Only Show Policy Settings that can be Fully Managed
  7. Expand ‘Office 2007 Quick Access Toolbar’
  8. Amend the ‘Include Quick Access Toolbar in Roaming Profile’ setting to Enabled.
4 people found this post useful.

802.1x User Authentication with Mandatory Profiles

Thursday, October 1st, 2009

Just been working on 60 new Asus Eee netbooks that we have bought for student use in the college. Mainly, testing thoroughly that the wireless was going to work flawlessly.

We got everything working for ourselves using Network Policy Server, HP Procurve 420 AP’s and PEAP. Only problem – when a student logs in, the authentication fails.

Did some checks to make sure that there wasn’t any user group filters or GP settings that were blocking the authentication. In a last ditch attempt we dropped the mandatory profile, and the authentication worked.

Having never had this problem before (all staff have roaming profiles), started looking up the problem.

Found that some changes in Windows XP SP3 stop user authentication using 802.1x. You can still use machine authentication, but this didn’t meet our requirements.

Turns out Microsoft released a hotfix for this. Works great – now integrated into our RIS installations. Link below:

http://support.microsoft.com/kb/969111

Group Policy Client Service Failed the Login: Access is Denied

Monday, September 28th, 2009

This error has been annoying me for nearly 4 hours now.

We have a terminal server for students. All students use a mandatory profile, located on a share so that it can be accessed by all of the servers in the farm.

I thought this would be easy to set up, so I did the following:

  1. Log in as a user (that does not have the profile path set) to create a local profile on the machine.
  2. Configure the profile as you require and then log off.
  3. Log on as an administrator.
  4. Open up System Properties –> Advanced –> User Profiles
  5. Select the profile that you created in steps 1 -3 and select Copy To.
  6. Specify the location and a security group and the intended user. Click OK and verify that the folder exists in the new location.
  7. Go to the location and rename NTUSER.DAT to NTUSER.MAN to make it mandatory.
  8. Set the user profile location for all your desired users.
  9. Log in and test.

All was going well. I was at step 8, and failure struck. Group Policy Client Service Failed the Login: Access is Denied.

Check the following first, as simple solutions:

  • The user has read access to the share.
  • The user profile is owned by the DOMAIN\Administrators group.
  • Ensure the desired group has got read access to the entire profile (you can replace all permissions).

After checking this and repeating the whole process twice, I started looking at something else. The NTUSER.DAT file is a registry hive, which contains keys with their own security on them. So:

  1. Open up Registry Editor
  2. Select HKEY_USERS and then rtight click and Load Hive
  3. Browse to the location of the profile and open NTUSER.MAN
  4. Give the key a temporary name. e.g Profile.
  5. Right click the name you just gave and choose permissions.
  6. Make sure the desired group is listed and has Full Control permissions.
  7. Propagate all these permissions to all child objects.
  8. Unload the hive and close Registry Editor

This cured the problem for me. Now all of the intended users can pick up the profile and work as desired.

I understand from my Googling that this is a problem with some Vista users to. I have not tried this as a solution for them, but would be interested to hear if it does solve it.

4 people found this post useful.