P
pmfphd
We are having some difficulty with creating a new user's homedirectory
and assigning permissions to it in a VBScript script. We are using a
script that was created by Microsoft which we have modified a bit to
suit our needs. This script reads in a text file one line at a time
and creates a new user in Active Directory based on the data in the
input string. Included in this string is the user's home directory
(expressed as a UNC share name) and their home drive letter.
When the script runs, it creates the setting for the folder inside the
new user's AD account but it doesn't actually create the folder. The
morning after this nightly job runs, one of our sysadmins must go into
AD manually, backspace over the last character of the homedirectory in
the user's profile, retype the last character, hit Enter, and the
folder is then created. Once the folder is created in this way, it
also has the correct folder permissions.
No one on our team is an AD expert. However, I have the feeling that
there is something amiss with the way our AD is configured since the
simple manual step is all that is required to set things straight. It
suggests to me that if we had all of the AD settings correct, the
folder and its permissions would be created when the user is created in
AD. Again, I know little about AD and I could be way off base here.
One attempt we have made to resolve this issue is to create the folder
in the VBScript using the FileSystemObject and then using CACLS to set
the permissions for the newly created folder. (Bear in mind that the
user is created just above this step in the script.) The folder gets
created properly but when CACLS tries to assign permissions, I get an
error that suggests that the new user doesn't exist. The specific
error is Error code 0x534 (decimal 1332)- "No mapping between account
names and security IDs was done." One of our sysadmins thinks that
this is because the new user hasn't replicated across all of our AD
boxes yet. This seems odd to me. If anyone could help clarify any of
the problems I've outlined here, we would appreciate it.
Thanks,
Paul M. Frazier
(e-mail address removed)
and assigning permissions to it in a VBScript script. We are using a
script that was created by Microsoft which we have modified a bit to
suit our needs. This script reads in a text file one line at a time
and creates a new user in Active Directory based on the data in the
input string. Included in this string is the user's home directory
(expressed as a UNC share name) and their home drive letter.
When the script runs, it creates the setting for the folder inside the
new user's AD account but it doesn't actually create the folder. The
morning after this nightly job runs, one of our sysadmins must go into
AD manually, backspace over the last character of the homedirectory in
the user's profile, retype the last character, hit Enter, and the
folder is then created. Once the folder is created in this way, it
also has the correct folder permissions.
No one on our team is an AD expert. However, I have the feeling that
there is something amiss with the way our AD is configured since the
simple manual step is all that is required to set things straight. It
suggests to me that if we had all of the AD settings correct, the
folder and its permissions would be created when the user is created in
AD. Again, I know little about AD and I could be way off base here.
One attempt we have made to resolve this issue is to create the folder
in the VBScript using the FileSystemObject and then using CACLS to set
the permissions for the newly created folder. (Bear in mind that the
user is created just above this step in the script.) The folder gets
created properly but when CACLS tries to assign permissions, I get an
error that suggests that the new user doesn't exist. The specific
error is Error code 0x534 (decimal 1332)- "No mapping between account
names and security IDs was done." One of our sysadmins thinks that
this is because the new user hasn't replicated across all of our AD
boxes yet. This seems odd to me. If anyone could help clarify any of
the problems I've outlined here, we would appreciate it.
Thanks,
Paul M. Frazier
(e-mail address removed)