SCEP/SUP and GPOs

[Special Ed]

We are implementing a new sccm 2012 install which is going to handle all Endpoint (SCEP) and software updates. The network has an existing WSUS server, but it will go away once the migration is complete. There is no preexisting FEP infrastructure. Existing systems have GPOs assigned to configure WSUS on the clients.

 

I've created a new OU for SCCM pilot systems as we get this running. Unfortunately, the OU inherits all the existing GPOs in the company. I can't filter the OU at this time. But I need to build a NEW gpo for this OU, so that it will supersede the current WSUS GPO and free up SCCM to handle the SUP and SCEP processes.

 

When we are done, and the environment is to be totally managed by SCCM, I don't think we need ANY GPOs as SCCM handles this all via client local policy assignments. However, I need to know what to set in my pilot GPO so that machines in my Pilot OU wont be getting conflicting GPO settings. Can someone tell me what to set in my GPOs for my pilots so SCCM can manage the environment?

 

Since SCEP is now in the mix, I'm not sure what I need to have on and off, and based on conversations I'm seeing online, it's not exactly clear. Most of the docs I've seen are with a FEP infrastructure external to SCCM (SCCM07, with FEP, etc), or are written assuming you have no preexisting infrastructure to migrate from. Now I've got one integrated system managing all 3 processes, so I'm not sure what GPO to set to get the old stuff out and let the new stuff play.

 

Thanks!

[Special Ed]

Also, is there a log for the SCEP product which tells you where it's pulling updates? When I manually run an update, the WUAHandler log doesn't track where it's getting it's definitions. By default, the clients could go to SCCM, WSUS, and microsoft. So it's possible that a client could be pulling definitions from MS if my server isn't running right.

 

How can I tell where my clients are getting the SCEP definitions?

[Special Ed]

Just following up on myself. I just saw this posting on technet. Can anyone confirm this is actually the case?

 

Ended up contacting MS Support and got it fixed. The problem was with a Group Policy setting that was being applied to the machines - specifically the "

Computer Configuration - Policies - Administrative Templates - Windows Components - Windows Update - Specify intranet Microsoft update service location"

policy. In this policy, I had my SCCM Software Update Point machine specified as the update server, as instructed in part 3 of the installation walkthrough I had followed

here

.

Apparently, having this policy applied to a workstation overrides any Software Update configurations that you try to apply using SCCM 2012. So, when SCCM tried to apply my definition updates, it saw that this particular group policy was applied to the machine and aborted the update. The definition updates downloaded successfully once this group policy was removed.

 

If this is true... then if you have previous WSUS installations, and are moving to an SCCM managed SUP & SCEP model, you actually need to remove the GPO's you can't just define the SCCM server as the source in the GPOs.

 

This kind of makes sense as the SCCM client is actualy setting LOCAL policies on the client to manage updates, and any GPO would over-ride that. I'm just surprised that WUA would get cranky about not working if the GPO defines the same server that the SCCM local policy would provide.

 

The entire discussion the above quote is from is here: http://social.technet.microsoft.com/Forums/en-US/configmanagersecurity/thread/a05601a2-7843-471b-8ce4-5cdcdc616a92

[anyweb]

interesting and thanks for posting, i've added a troubleshooting note to that guide now to clearly show how to know if it's working correctly (or not) by reviewing the WUAHandler.log, I think you may have specified the Netbios name instead of FQDN (if your site server was configured that way),

 

please review the troubleshooting note and see does it correspond to your logs, and yes, you can absolutely specify this GPO for installing clients using the SUP and it does not adversely affect Endpoint Protection or other updates later on, you can see this by reviewing part 6 which uses the SUP (with the configured GPO) to install Endpoint Protection Definition Updates.

[Special Ed]

Very interesting.

 

We did NOT use a netbios name in the GPO. We used a FQDN. THAT I am sure of as that was my first troubleshooting step, and we verified that several times.

 

However, looking over your instructions again... I'm wondering if when the site role was configured, they did not select "WSUS is configured to use a custom web..." option for WSUS but instead used the default port options. I noticed in your GPOs, you specified the ports.

 

I was not present when they configured the WSUS component, but they team did follow your instructions. Could this be a cause of our problems? And if so, is there a way to change this setting without removing the SUP role and reconfiguring from scratch?

 

Thanks!

[Special Ed]

Anyweb, I would like some clarification... perhaps you can help me out here.

 

In this step: http://www.windows-noob.com/forums/index.php?/topic/5683-using-system-center-2012-configuration-manager-part-5-adding-wsus-adding-the-sup-role-deploying-the-configuration-manager-client-agent/

 

you suggest that the SUP role should use the CUSTOM web site in Step 2.

 

However, in other SUP configurations walkthroughs you have published (look here: http://www.windows-noob.com/forums/index.php?/topic/4427-using-sccm-2012-rc-in-a-lab-part-2-add-sup-and-wds/ ) you built the server using the default websites.

 

What are the pros/Cons of those choice and how will them impact how the systems work?

 

Thanks!

[anyweb]

hi SpecialEd,

the reason I've chosen to use custom ports is because it's a recommended best practice from Microsoft, see here

 

Best Practices for Software Updates in Configuration Manager

Updated: December 1, 2011

Applies To: System Center 2012 Configuration Manager

Use the following best practices for software updates in System Center 2012 Configuration Manager.

 

Installation Best Practices

 

Use the following best practices when you install software updates in Configuration Manager:

 

When Configuration Manager and WSUS use the same SQL Server, configure one of these to use a named instance and the other to use the default instance of SQL Server

 

Use a custom website for the WSUS installation

 

When you install WSUS 3.0, you can specify whether to use the default Internet Information Services (IIS) website or create a WSUS 3.0 website. As a best practice, select Create a Windows Server Update Services 3.0 Web site so that IIS hosts the WSUS 3.0 services in a dedicated website instead of sharing the same website with other Configuration Manager site systems or other software applications. When you use a custom website for WSUS 3.0, WSUS configures port 8530 for HTTP and port 8531 for HTTPS. You must specify these port settings when you create the active software update point for the site.

 

as regards your original issue, do you have any of the logs you sent to Microsoft i'd be happy to look at them to figure out your problem

[Special Ed]

Well, that's good to know which is the right setting.

I am curious... is there a way to change the settings after the SUP is configured in SCCM? Or must we remove the site role and reconfigure? We are set for port 80.

 

As for our issues... I'll post the log here. As you'll see when you review it you'll see different errors over the last week 2 weeks.

Initially, we had a conflict with the old WSUS server, then you can see we played around with various GPO settings until we got it 'working'. We tried 'disabled' but that clearly wasn't a good setting.

At one point we modified the server information in the GPO by cutting and pasting the policy information that was set in the local policy (http://sccmserver.local:80) into the GPO, but that didn't seem to put an end to the "Group policy settings were overwritten by a higher authority" errors for several days. (though those errors are not in this log) But we could not figure out where our conflict was. Updates were not flowing to our machines. So we moved our machines to an OU with no GPO.

We've been running in that OU for a week now. As you'll see, the errors are no longer there, but it still not downloading updates as we expected. For a few days we modified the policy so that it would only pull down updates from our SCCM server, and we disabled the access to MS. Things seemed to be working ok, our compliance was at 100%. When we turned access to MS back on Wednesday, it would appear that our clients aren't pulling updates anymore. For example the machine this was pulled from had not pulled an update for a while. Our overall compliance dropped from 100% to 17% since Wednesday. Again, all our machines are now in a group with no GPO to create a conflict.

What's weird is that while we were working on this, late last week, updates seemed to start flowing. This was after I posted my initial post. We thought all was happy with no GPO, and thought that was our solution, so then we turned back on access to MS on Wednesday and it's stopped again. It's really weird. I would think that the access to MS would simply give us a redundant access to updates should our server go down. Am I misunderstanding how it should work?

So,this morning in an attempt to duplicate our original issues for your entertainment pleasure, and show you what we see, we moved this machine back into the OU with the GPO. You should see the logs changed after 9am Aug 17. The machine pulled it's policy like we want, and updated nicely. No errors in the log. We then modified the policy so it should only pull from our server, and not be able to pull updates from MS. We forced a synch with MS so that it has updated policies since then, and ran our auto deployment rules so we should have nice fresh policies in place. And of course, now it would seem that things are working. But I'm still not trusting it. It feels like things work for a few days, then stop, and I can't figure out why.

 

I've also posted an export view of the GPO we are trying to use initially (and for the above test). It's very likely our GPO is/was our problem. Note that I've pulled any corporate/Domain names from the logs and GPO and tried to replace them with generic names.

 

 

Many thanks!

WUAHandler.log

WSUS - Use SCCM 01.htm

[Peter van der Woude]

Settings of the Software Update Point can still be managed via Administration > Overview > Site Configuration > Sites > Site Server > Settings > Configure Site Components > Software Update Point.