Month: February 2012
SCCM Distribution Points on Windows Server Core
I recently scoured the Internet for information and success/trials of using Windows Server 2008 R2 Core as an SCCM distribution point. Much to my surprise, I found very little information and had to piece together and test it out for myself. According to the Prerequisites for Installing Configuration Manager, a BITS-enabled DP needs IIS, BITS, WebDAV, and RDC. Unfortunately only IIS can be installed on Server Core, and not the others.
At first glance, this seems to indicate that you wouldn’t be able to use Server Core as a DP. However, when you look closer, the prerequisites listed are only for BITS-enabled DPs. So none of IIS, BITS, WebDAV, and RDC are necessary. Granted you could miss out on the advantages that BITS provides, but it is still possible to use Core as a DP. Another possible route is to use the Server Share (setup/config similar to doing a new Server), but the disadvantage is not being able to have site status messages reported to the parent site.
Phew! It seems so simple, yet so easy to get confused. So when setting up an SCCM distribution point on a Windows Server Core OS, just be sure to not enable option “Allow client to transfer content using…BITS…”
IIS Bindings and SCCM Software Updates
You may be asking, what does IIS bindings have to do with SCCM software updates. Well, let me tell you lol.
I’ve stood up a new SCCM infrastructure including site configuration/roles and deployed a few clients. When testing software updates on a client, software update scan/deployment cycles kept failing. Upon investigation of logs, the scan were failing with “Scan failed with error = 0x80072efd”. Furthermore, reporting showed scan error failure code -2147012867. These errors indicate that the Windows Update Agent could not communicate with the defined source location.
The troubleshooting difficulty is that there are many possibilities of causing this.
- Local GPO “Specify intranet Microsoft update service location”. When using SCCM software updates, the client sets this local GPO on the client pointing to the WSUS location. In my case this wasn’t it.
- Windows Firewall blocking the ports used by WSUS, on either the client or server. In my case this wasn’t it.
- A proxy or bad winhttp settings redirecting the traffic incorrectly from client to server. In my case this wasn’t it.
- Various other things.
I believed that I had reached the end of the Internet at this point when finally I came across a posting on WindowsNoob that steered me in the right direction. To fix a different technical problem with WSUS conflicting with Symantec Endpoint Protection, I swapped the Software Updates Component from using ports 80/443 to using ports 8530/8531. I guess with this change, SCCM didn’t automagically configure the default website in IIS bindings to listen for requests on the newly defined port.
So to resolve the issue, I did the following:
- Open IIS Manager
- Right-click on the default website and select “Edit Bindings”
- Add port 8530 as an IIS binding….and voila it works.
A New Adventure
I began working with SMS/SCCM in early 2004. After being “in the trenches” of systems management and desktop engineering for nearly 8 years, I am setting out on a new journey. Today begins my new adventure – I am greatly honored to be joining the highly talented group at Catapult Systems as a senior consultant for SCCM architectures/implementations and Windows 7 migrations.
t3chn1ck 