3

I have been tasked with improving our current image deployment. Right now we do a fair amount of manual setup after imaging to reduce the work for users who get a newly imaged machine. I would like to automate this as much as possible. We have a lot of short-time volunteers and interns so time-savings here will add up quickly.

One task is setting up the default save locations in Word and Excel. Some users have the User HomeDrive environment variable set, but not all (and none of the short time students). All users have the UserSharedFolder ActiveDirectory attribute set. This is not saved as an environment variable. Ideally the default save location would be set to the value of this AD attribute. It is different for each user.

Any suggestions on how to manage this?

I determined that the Default Save location is in the registry. I would like to use Group Policy Preferences to set it, but I can't access an Active Directory attribute from GPP.

How would I access this in a script? It will need to run in the user's context. I won't have access to the Powershell ActiveDirectory module on most machines.

Is there an alternate way to do this that makes more sense?

1 Answer 1

4

In Group Policy Preferences, you can do an LDAP Query in the Item Level Targeting and store the result in an Environment variable. That Environment variable can be referenced by a Registry Preference item. (Or referenced by a script that runs later, e.g. a user logon script).

To set the Environment variable using Group Policy:

  • Edit the GPO (or create a new one)
  • Go to User Config -> Preferences -> Windows Settings -> Environment
  • Create a new Environment variable
  • Name = MYSAVELOCATION
  • Value = %_MYSAVELOCATION%
  • In this case, it should be a User Variable
  • Under Common, check Item-level Targeting
  • Click Targeting...
  • New Item -> LDAP Query
  • Filter = (&(objectClass=user)(sAMAccountName=%USERNAME%))
  • Binding = LDAP:
  • Attribute = userSharedFolder (I think this is the AD attribute you want. Double-check it!)
  • Environment variable name = _MYSAVELOCATION
  • Click OK

You can then create a Registry Group Policy Preference item that references %MYSAVELOCATION%. You could also reference the environment variable in a batch file or script that runs after the GPO has applied.

If you wanted to do the equivalent thing in PowerShell, you could do this (e.g. in a user logon script). This has no dependency on the PowerShell AD modules:

$searcher = New-Object System.DirectoryServices.DirectorySearcher
$searcher.SearchRoot = New-Object System.DirectoryServices.DirectoryEntry
$searcher.Filter = "(&(objectClass=user)(sAMAccountName=$env:USERNAME))"
$searcher.SearchScope = "Subtree"

# I am assuming userShareFolder is the AD attribute you want
# Double-check that and update this lin accordingly.
$searcher.PropertiesToLoad.Add("userSharedFolder") | Out-Null

$result = $searcher.FindOne()

# All of $result.Properties must be lower-case!
$user_shared_folder = $result.Properties.usersharedfolder

Write-Output "User Shared Folder = $user_shared_folder"

# Update the Environment Variables (two-step process)
# Call SetEnvironmentVariable to make the change persistent.
# Update $env:variable so the change affects the current process.
[Environment]::SetEnvironmentVariable("MYSAVELOCATION", $user_shared_folder, "User")
$env:MYSAVELOCATION = $user_shared_folder

From there, it is in an environment variable just like Group Policy Preferences. You could also just take the value of $user_shared_folder and write it directly to the registry with Set-ItemProperty, no environment variable needed. However, keeping it in an environment variable can be handy if you have a script or application which may need to reference it later.

For reference, I use the techniques described above to get Full Name and E-Mail address out of Active Directory and use them for application setup (e.g. personalizing Office). You can also do a similar query with WMI to get the computer model and serial number.

2
  • Thank you, the GPP method worked well. For anybody else trying the same thing, I spent a long time testing this and failing until I figured out that this setting will only apply on a fresh login. Gpupdate /force and then allow it to log you out to update the setting.
    – Quinten
    Apr 29, 2014 at 13:52
  • Yeah I should have mentioned that. When you change an environment variable, it typically does not affect the environment of an already-running processes. That's why I do the double-change in the PowerShell script. Also in scripts you have to be careful about changing the "persistent" Environment Variable, and not just the environment of the current script. Apr 30, 2014 at 19:14

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .