mikestanley

I am having this same issue. I'm not a domain admin on our domain, but our SCCM server was granted (and appears to still have) permissions to the System Management container. I've confirmed the Site info there is still listed as 7958, not what the Site server itself is showing - 8239. Provided my Site server does still have access to update the Site info for our instance of SCCM in the System Management container, is there some way for me to force the server to do it?

Thanks, that may just be what we do, especially for this pilot. I know the AD schema was extended when the central IT guys stood up their SCCM system. How would I be able to tell if my site is published in AD?

I work at a university and I'm not in the central IT organization, so please keep that in mind as I describe what may sound kinda crazy. Some of this situation stems from a long-standing conflict between the folks who run DNS on campus (BIND) and those who run AD, and some of it is just departmental/college politics/inertia. All that's to say this is the messy world I live and work in, and I may have very little ability to make massive changes to it, which is why I'm trying to figure out a way to work around it. Some context about our setup: Our AD forest is state.edu, with each campus have a child domain. So the domain I live in is campus.state.edu - for AD. Our campus identity DNS-wise is campus.edu. So our website is www.campus.edu, our email addresses are user@campus.edu (although we all have aliases for user@state.edu as well) Our departmental subdomains (not for AD - just FQDN) tend to follow a pattern of college.campus.edu or department.campus.edu. So a machine, like my own computer, exists in DNS as mymachine.department.campus.edu. After working with the central IT guys, who are domain admins (I am not) to grant the right permission to my SCCM server within the systems management container, I was able to follow the guide here and install SCCM. I danced, I was happy, everything was right with the world. Then I configured a system-based discovery for just the OU in which my department's machines live. But I got nothing. Checking the adsysdis.log, I saw a ton of errors that basically amounted to "I can't find machine.campus.state.edu" - which made total sense, because that FQDN doesn't exist. For the time being, I've worked around this by going to our NetReg systems and adding CNAMEs for a handful of our test machines, and sure enough, once I made machine.campus.state.edu resolve, SCCM was able to discovery our machines. The problem is we have about 2000 machines across our institute, and I personally have no way of injecting the appropriate CNAME into all of them, other than to do it one by one. I can ask the central IT guys to do it in bulk, and they may well do it, but that's only going to address the problem as it exists today, and not deal with it for new machines over time. So I'm wondering, is there any way to configure SCCM to try to discover machines based on alternate FQDN patterns? To make matters a little more complicated, I'm implementing this project for our entire Institute, which is composed of a few colleges and several departments, so I wouldn't just need to make it look for machine.department.campus.edu, but variations of machine.otherdepartment.campus.edu, then make CNAMEs for those of machine.campus.state.edu. Am I making this harder than it has to be? I know I could try to discover based on IP address or subnet, but part of the problem there is we share subnets with other departments, so logically I think of targeting our OU/sub-OU structure as the safest/most considerate way to try to do discovery. Thanks for any suggestions. I'll be going to some training on SCCM in a few weeks, and I'm hoping this sort of thing will be covered there, but I'm mostly trying to figure this out on my own right now.

Glad to have found this. I hadn't seen it before because it isn't listed on the Site Navigation on the main page like the 2012 guide is. Thanks.