The account that will be used to run the extadsch.exe needs to have appropriate access and be in the “Schema Admins” group. You cannot run the extadsch.exe with alternate credentials using Run As.
The exe used to extend the AD Schema can be located in the default installation directory under the bin\i386 folder.
If you have installed ConfigMgr to an alternate location, then it will be located in that installation path (installation paht\bin\i386).
You can run the file by either opening a command prompt and running the extadsch.exe, or by double-clicking the file.
Once it’s ran, you are looking for the “Successfully extended the Active Directory schema” output. You can also view the results by viewing the ExtADSch.log that is created on the C: drive.
This log file will detail the changes made to the schema and also show the success of the schema extensions.
Creating the Systems Management Container
After the schema is extended successfully, the Systems Management container needs to be created in Active Directory.
Open ADSI Edit and expand to the “System” container.
Right-click on the System container and select “new” then “object”.
Select “container” from the object list, and then select “Next”.
Next, enter in “System Management” and then click “Next”.
Once you click Finish, you should see the new container listed.
Once the System Management container has been successfully created in Active Directory, the appropriate permissions needs to be set on the object.
With ADSI Edit still open, right-click on the System Management container object and select properties.
Go to the Security tab of the Properties dialog box and then select “Add”. Once the next dialog box opens, add the computer account of the primary site server(s) or the Active Directory group containing the servers. It’s recommended to use an Active Directory group so that you are not required to make this change again. Once you have entered in the required information, select “Ok”
Select “Full Control” for the site server or group you just added.
Next select Advanced, and then configure the server or AD group permissions to apply to “this object and all descendant objects”.
Click “OK” 3 times to save your changes.
This post is provided as-is, use at your own risk.
My latest lab is on Server 2008 R2 and I was having a weird issue with the MP not installing. Even though I had configured WebDav correctly as per the TechNet article here, however my mpsetup.log was still giving me errors about WebDav not being correctly configured. Upon opening up the webdav_schema.xml I could see that it wasn’t actually set correctly.
I tried clearing the settings, uninstalling WebDav, restarting the server and reinstalling, reconfiguring, but even that didn’t work.
This post here pointed me in the right direction and credit is due where credit is due!
After manually modifying the webdav_schema.xml, then I was able to successfully install the MP site role.
I was helping someone configure some shares the other day for Migdata and Logs. I dug this up from the old BDD 2.5 documentation, it’s a good reference point for creating access to shares in order for computers to put files there.
After you have configured the SMS client access accounts, you need to configure the appropriate shared folder permissions. Ensure that unauthorized users are unable to access user state migration information and the deployment logs. Only the workstation creating the user state migration information and the deployment logs should have access to these folders.
To configure the shared folder permissions for each folder listed in Table 24, perform the following steps for each folder:
1. Start Windows Explorer and navigate to SharedFolder (where SharedFolder is one of the shared folders listed in Table 24).
2. Right-click SharedFolder (where SharedFolder is one of the shared folders listed in Table 24), and then click Properties.
3. On the Security tab, click Advanced.
4. On the Permissions tab, clear the Allow inheritable permissions from the parent to propagate to this object and all child objects check box.
5. When the Remove when prompted to either Copy or Remove the permission entries that were previously applied from the parent appears, click Remove.
6. On the Permissions tab, click Add.
7. In the Enter the object name to select text box, type Domain Computers, and then click OK.
This action allows domain computers to create subfolders.
8. On the Permission Entry for Text dialog box, in the Apply onto list, select This folder only.
9. On the Permission Entry for Text dialog box, in the Permissions list, select Allow for the Create Folders/Append Data permission, and then click OK.
10. Repeat steps 6– 9 substituting Domain Users for Domain Computers.
11. On the Permissions tab, click Add.
12. In the Enter the object name to select text box, type CREATOR OWNER, and then click OK.
This action allows domain computers and domain users to access the subfolders they create.
13. On the Permission Entry for Text dialog box, in the Apply onto list, select Subfolders and files only.
14. On the Permission Entry for Text dialog box, in the Permissions list, select Allow for the Full Control permission, and then click OK.
15. Repeat steps 11–13 for each group that you want to grant administrative privileges.
The permissions you set in these steps allow a workstation to connect to the appropriate share and create a new folder in which to store user state information or logs, respectively. The folder permissions prevent other users or computers from accessing the data stored in the folder.
Note The default permissions on the SMS distribution point shares should provide the appropriate resource access by default.
Credit to Jake Cohen who suggested this on the MyITForum email list.
Someone asked for a way to restrict people from browsing the default distribution shares and installing whatever they feel like. Below is one method of “locking” down this common share without inhibiting SMS/SCCM software distribution.
We are not going to set or change anything on the default share permissions, default is that Everyone has read/write access, that’s fine, we’ll control it at the NTFS level, since that will apply locally and over the network.
Another thing to note is that this will set the permission on all existing packages, however any newly created packages won’t have these permissions until you re-apply the permissions from the root folder.
First lets go into our share properties:
Next we want to go to the security tab:
Then we want to click on “Add”:
Add “Domain Computers”, click on “Check Names”, then Click on “OK”:
Verify that you have read permissions for Domain Computers (should be selected by default):
Next, we will want to modify the permissions for the server\users group:
Again, we want to uncheck the “List” permissions, then click “OK”:
Next, we want to check the box for “Replace permissions….”, then Click on “OK”
Click “Yes” On this box:
You can verify your permissions for Domain Computers and Users here, then click “OK” when you are done:
Now you have modified the default file security permissions for your package distribution share in SMS/SCCM.
Hope this helps,