The environment is an Empty Root with two child domains. A resource domain for servers and a user domain for user objects. Functional level is 2008 R2, no PKI. All DC's are W2K8 R2 SP1 The SCCM site is in the Resource Domain. There are no pre-existing SCCM or SMS sites installed. The first SCCM 2007 install failed, and I never did any collections. It appeared to be a clean uninstall, but there are SCCM related accounts still in AD. While the Schema extension looked like it worked, it did not propagate to the User domain. It was executed form the Schema Master in the Forrest Root. Permission on the System Management objects were per MS recommendations, SCCM Server with F/C Instillation problems with WSUS are also killing me. Ive been at this for over a week now. Last Wednesday I opened a trouble ticket with MS. Because its a test environment they put it on the back burner. I got an email form a tech at 9:30 PM, and a call a few days ago. Because corporate policies are preventing me from installing the Desktop Sharing utility, the tech was lost on troubleshooting it would not even attempt to start. I sent him a reply to a laundry list of things, but nothing in return. I seem to recall when the MS techs could actually troubleshoot blind, but I guess its a perishable skill. Like navigation when I was flying in the Army. In any event, I have two problems. 1) The placement of the site within the domain structure, and the associated Schema replication, Repadmin does not indicate a problem with replication. Does this have to be installed in the Forrest Root to propagate out There are Bridgehead servers in the three sits in my AD structure. 2) WSUS. I keep getting a WSUS installation failed (Error 0x80070643: Fatal error during installation.) Ive followed all the recommendations I can find, but still cant get it to install. I have a functioning WSUS install, but its been configured by the Wizard and by all accounts I cant use it with SCCM 2007 or 2012. Im logging into the WSUS server candidate with a Root Enterprise Admin account. KB 920660 did not help. I have very little experience with SQL or SCCM. The last time I deal with this was with SMS 2.0. Recommendations? Thanks in advance! Bryan

A handful of comments and questions here. Why would you have a resource a separate resource domain and user domain? How are you verifying the schema changes didn't replicate? Are you talking about objects in the System Management container? If so, that has nothing to do with the schema and is not part of the schema. Objects do not replicate from one domain to the other. Where are you installing WSUS? What OS and how are you installing it? Do you have a SQL instance set up yet?Jason | http://blog.configmgrftw.com

The reason for the separation of domains is primarily for security boundaries. I support a Gov. Agency, and the immediate group of folks I support are about 60 White Hat hackers. Short of barbed wire every little bit helps. The Systems Management container did replicate to the Resource Domain, but not the User Domain. The SCCM objects were only in the Resource Domain. Schema extension was from the Schema mater in the Forrest Root. WSUS is installed on a fully patched W2K8 R2 system in the Resource Domain; Ive tried to install it via the Add Roles wizard, and directly via the x64 executable. Fails with the MS Internal DB permissions problem that I cant seem to get aournd. Ive tried it with the IIS folder on the C drive unhardened and Hardened on the D drive per DOD STIG. SQL 2008 in installed on one of my systems, but when Ive tried to link WSUS to it, it does not work. It validates, but then falls flat. My ultimate goal is to either get SCCM 2007 R3 up and running so I can manage my Win7 & W2K8 R2, XP, W2K3 & the odd W2K servers systems or install SCCM 2012, if I can get beyond the WSUS and possible Schema issues. My environment is approaching 150 test servers and I need a better patching solution than the existing WSUS system. If I could connect the existing WSUS server to the SCCM 2001/2012 servers this would largely be a done deal. I also need it to support tests with other systesm. Bryan

The reason for the separation of domains is primarily for security boundaries. I support a Gov. Agency, and the immediate group of folks I support are about 60 White Hat hackers. Short of barbed wire every little bit helps. The Systems Management container did replicate to the Resource Domain, but not the User Domain. The SCCM objects were only in the Resource Domain. Schema extension was from the Schema mater in the Forrest Root. WSUS is installed on a fully patched W2K8 R2 system in the Resource Domain; Ive tried to install it via the Add Roles wizard, and directly via the x64 executable. Fails with the MS Internal DB permissions problem that I cant seem to get aournd. Ive tried it with the IIS folder on the C drive unhardened and Hardened on the D drive per DOD STIG. SQL 2008 in installed on one of my systems, but when Ive tried to link WSUS to it, it does not work. It validates, but then falls flat. My ultimate goal is to either get SCCM 2007 R3 up and running so I can manage my Win7 & W2K8 R2, XP, W2K3 & the odd W2K servers systems or install SCCM 2012, if I can get beyond the WSUS and possible Schema issues. My environment is approaching 150 test servers and I need a better patching solution than the existing WSUS system. If I could connect the existing WSUS server to the SCCM 2001/2012 servers this would largely be a done deal. I also need it to support tests with other systesm. Bryan Domains in a single forest are in no way a security boundary but that's not really relevant here. Objects in AD do *not* replicate between domains so there is no way your statement is accurate. As mentioned, objects (like the System Management container), do *not* replicate between domains and are *not* part of the schema. To verify the schema, you must use the schema admin tool. If you can see it in ADUC, it's *not* part of the schema. You can manually create the System Management container in each domain though depending upon where you are hsoting different site servers; however, the objects in the System Management container are located using the global catalog so if all of your ConfigMgr Site Servers (not siste systems) are in the same domain, there is no reason to do so. STIG, shudder. All of your permissions issues related to WSUS install are directly related to your security lockdowns.Jason | http://blog.configmgrftw.com

The reason for the separation of domains is primarily for security boundaries. I support a Gov. Agency, and the immediate group of folks I support are about 60 White Hat hackers. Short of barbed wire every little bit helps. The Systems Management container did replicate to the Resource Domain, but not the User Domain. The SCCM objects were only in the Resource Domain. Schema extension was from the Schema mater in the Forrest Root. WSUS is installed on a fully patched W2K8 R2 system in the Resource Domain; Ive tried to install it via the Add Roles wizard, and directly via the x64 executable. Fails with the MS Internal DB permissions problem that I cant seem to get aournd. Ive tried it with the IIS folder on the C drive unhardened and Hardened on the D drive per DOD STIG. SQL 2008 in installed on one of my systems, but when Ive tried to link WSUS to it, it does not work. It validates, but then falls flat. My ultimate goal is to either get SCCM 2007 R3 up and running so I can manage my Win7 & W2K8 R2, XP, W2K3 & the odd W2K servers systems or install SCCM 2012, if I can get beyond the WSUS and possible Schema issues. My environment is approaching 150 test servers and I need a better patching solution than the existing WSUS system. If I could connect the existing WSUS server to the SCCM 2001/2012 servers this would largely be a done deal. I also need it to support tests with other systesm. Bryan Domains in a single forest are in no way a security boundary but that's not really relevant here. Objects in AD do *not* replicate between domains so there is no way your statement is accurate. As mentioned, objects (like the System Management container), do *not* replicate between domains and are *not* part of the schema. To verify the schema, you must use the schema admin tool. If you can see it in ADUC, it's *not* part of the schema. You can manually create the System Management container in each domain though depending upon where you are hsoting different site servers; however, the objects in the System Management container are located using the global catalog so if all of your ConfigMgr Site Servers (not siste systems) are in the same domain, there is no reason to do so. STIG, shudder. All of your permissions issues related to WSUS install are directly related to your security lockdowns.Jason | http://blog.configmgrftw.com