| Downloads |
|---|
| 22355.zip |
I want to use Windows Script Host (WSH) and Microsoft Active Directory Service Interfaces (ADSI) to change the location of a user's profile from one Windows NT 4.0 server to another. I'm using the %USERNAME% environment variable in the user's profile path. When I use User Manager to manually clone the account, the environment variable resolves to the correct username. However, when I use ADSI to programmatically clone the account, the environment variable doesn't resolve to the username. Instead, the scripting engine takes the path literally and creates a folder called %USERNAME% in the profile share. If I go into User Manager after running the script and click OK, User Manager resolves %USERNAME% to the correct username. Listing 2 contains the problematic part of the script. How can I get %USERNAME% to resolve correctly?
The answer depends on the context in which you're running the script. If the script is running under the context of each user account (e.g., as part of the user's logon process), you can use the WSH Shell object's Expand- EnvironmentStrings method to resolve %USERNAME%, as Listing 3 shows. However, if the script isn't running under the context of each user account, which I suspect is the case because users typically don't have the security privileges needed to modify these values, you need to come up with an alternative solution.
The solution might be easier than you think. Because you already have the username (i.e., UserName in the ModifyUser subroutine), you can use it to set the user's Profile and HomeDirectory properties, thereby eliminating the environment variable problem altogether. Listing 4 shows the modified version of the Modify- User subroutine.
I made one other tweak to the Modify User subroutine. As callout A in Listing 4 shows, I appended a class identifier to the string I passed to the GetObject method. The class identifies the type of object to which the WinNT: provider needs to connect (i.e., bind). Although appending the class type isn't necessary, including it makes the WinNT: provider more efficient. The provider doesn't need to examine Computer, Group, and other non-User objects to resolve the name, thereby optimizing the binding process. This optimization is unique to the WinNT: provider.
