wilbywilson

Fed, I'm about to go through a similar process (I need to deploy an internet-facing MP/DP/SUP in the DMZ.) Did you end up setting up a dedicated SCCM site server in the DMZ? If so, was that server in the same domain as the SCCM primary? It doesn't seem like that would be good security practice, but I also don't know what all of the implications are if the DMZ site server is in a workgroup (or another domain altogether).

Thanks very much for the reply, Peter. I have a follow-up question. I've been doing more research about installing an internet-facing Distribution Point in a DMZ, but not many people are saying whether their DMZ site server is joined to the same domain as the SCCM Primary. In general, it seems like best practice is to never have a DMZ-based server on the same domain as the rest of the organization. So, how would things work if the SCCM Site server in the DMZ was in a workgroup? What additional hoops would we need to jump through to get things communicating properly? I've never installed SCCM roles onto servers that were NOT in the domain, so I'm wondering what all of the implications are.

I would like to add an SCCM Site Server into our DMZ, so that it can distribute updates to laptop clients out on the internet. I've been reading through documentation on how to set up the proper certificates for PKI and client auto-enrollment, but I haven't seen too much about adding/configuring the SUP role itself. I assume that WSUS needs to be installed on the site server in the DMZ? Does it need any configuration at all? Or should I just cancel the WSUS config screen when it comes up? This is Windows 2012 R2 if it makes a difference. Will the SUP inherit all of the required settings from the Primary? Anything special that needs to be done with the SUP? Thanks

I'm happy to report that 75% of the clients that were updated to 5.00.7958.1203 are now reporting that version correctly in the SCCM 2012 R2 console. It seems to have taken approximately 4-5 days for the new client version to report back in. I'm going to assume that the remaining 25% of the clients will also report their version correctly as more time passes. I guess I need to remind myself that with SCCM, patience is required.

I've been following the SCCM 2012 deployment guides posted on this site, and have a few questions about optimal configuration of the Endpoint Protection piece. Specifically with the Automatic Deployment Rules. I created a few of these ADRs in SCCM 2012 R2 CU1(one per SCCM collection that will be targeted for Endpoint Protection, per the guide's suggestion), but I'm curious about the resultant package and distribution behavior. 1) Each ADR is pointing to the same Endpoint Deployment Package. So what exactly happens when the next scheduled ADR runs? Is the package re-created and re-distributed for each of the 3 ADRs? I certainly don't want to stress my SCCM and network infrastructure. It almost seems like a single ADR makes more sense, but I'm not sure if that would work, since these ADRs target specific collections. I guess I'm looking for best recommended practice, without crushing my network with a constant flood of rule deployments and package pushes. (Right this second, all 3 of my EndPoint Protection ADRs are scheduled to run at exactly the same time. Not sure what the resultant behavior will be, since I just configured this today. I didn't necessarily want these Endpoint Protection ADRs running at different times, and stepping all over each other trying to recreate and redistribute the same exact package.) 2) Speaking of distribution, my initial Endpoint Protection deployment package (I filtered for just "Forefront Protection 2010" and "Definition Updates") was 263MB! Is that normal? I've got to send this out to a number of distribution points, and that just seems overly large for anti-virus definition updates. 3) What happens when the ADR runs the next time, and the package gets a new definition update added to it? Will the entire package try to re-distribute itself? Or will only new content get distributed out? Again, I'm concerned about network bandwidth. 4) Lastly, when configuring the antimalware policies, on the "definition updates source" options, there are 4 things listed. I'm curious about the difference between "Microsoft Update" and "Microsoft Malware Protection Center." I want to enable my laptop antimalware policy to allow updates from Microsoft, but I'm not sure which one of those 2 choices is best. Thanks for any advice on these questions.

I'm seeing the same issue with the CU1 update to SCCM 2012 R2. I pushed out the CU1 update to a small number of clients last week, and only 1 of them is reporting back with "5.00.7958.1203" in the console. The others are still reporting to be at base R2 level (5.00.7958.1000.) I have manually checked the clients in question, and they ARE updated with the latest client; it's just not showing as updated in the SCCM console. Are other people seeing this behavior? About how long should it take for the SCCM console to get updated, when clients get a new version? Is this a known bug? Thanks in advance for any input.

You should try using the "%dp0" variable: http://www.ntcenter.ca/tools/sccm-sms-and-batch-scripting http://www.myitforum.com/articles/8/view.asp?id=12036

Hi Mike, I think I understand you question, because I just went through a remote SQL installation a couple weeks ago. On the first dialogue box, you need to point to your remote SQL server (and named instance.) On the next screen, I believe that you can just leave the default paths in place (if you're alright with the DB living in the default MSSQL folder) It's confusing, because it says something like "D:\Program Files\Microsoft SQL Server\...." but you're not trying to put the DB on the local SCCM 2012 Primary drive. You're trying to point it to the D: drive on the remote SQL box. Anyway, I left the default paths for that part, and the installation worked, and the DB did end up on the SQL server. Hope that makes sense... -------------------------------------------------------------------------------------------- Does ConfigMgr actually need to know the path to the SQL data and log files? If so, why? If not, can I just leave the dummy default paths? If I have to share the data/log paths, is it just the SCCM service account that needs access or do other accounts need to know this path?

I spent some time dredging the 'Net last night too, and while I didn't find anything that's 100% definitive, I don't think that the server hotfix needs to be installed on anything except: -Central Servers -Primary Servers -Secondary Servers -Remote SMS Providers If I'm understanding everything correctly, even though the SQL server and Distribution Point are "Site System Servers" according to the SCCM 2012 console, I don't believe they need the hotfix. (I did choose to patch the Site Database itself during the upgrade, but that was done directly from the Primary server as part of the main CU1 update.)

I've been building out a new SCCM 2012 R2 environment over the past couple of weeks, and just noticed that Cumulative Update 1 was released. I just applied it to my stand-alone Primary, which seems to have gone well. It created a number of resultant hotfixes that need to be pushed out in my fledgling SCCM environment. While I’m pretty clear on most of it, I'm not entirely sure where to send the “server” hotfix. What would qualify an SCCM server as needing the hotfix? Is it any server that’s listed as “Site Server” in the SCCM console? Right now, (besides my Primary) I just have a separate SQL box (roles are “Component Server, Reporting Service Point, Site Database Server, and Site System”) and a separate Distribution Point (roles are “Distribution Point and Site System”). I would guess that both of those would qualify for distribution of the hotfix, but I'm not positive. I don't know whether only full Secondary sites need the hotfix, any Site Server at all, or some other criteria. Thanks for any input. -cw