In part 1 of this SCCM 2012 R2 Installation Guide blog series, we planned our hierarchy, prepared our SCCM 2012 R2 Server and Active Directory.

In part 2, we installed and configured SQL in order to install SCCM 2012 R2.

In part 3, we installed a stand-alone SCCM 2012 R2 Primary site.

In the next 16 parts, we will describe how to install the numerous site systems roles available in SCCM 2012 R2. Role installation order is not important, you can install roles independently of others.

This part will describe how to install SCCM 2012 Application Catalog web service point and the Application Catalog website point.

Role Description

The Application Catalog web service point provides software information to the Application Catalog website from the Software Library.

The Application Catalog website point provides users with a list of available software.

This is not a mandatory site system but you need both the Application Catalog website point and the Application Catalog web service point if you want to provide your user with a Self-Service application catalog (web portal).

sccm 2012 application catalog

Site System Role Placement in Hierarchy

The Application Catalog web service point and the Application Catalog website point are hierarchy-wide options. It’s supported to install those roles on a stand-alone Primary site or child Primary site. It’s not supported to install it on a Central Administration site or Seconday site.  The Application Catalog web service point must reside in the same forest as the site database.

If you’re having less than 10,000 users in your company, co-locating the Application Catalog web service and Application Catalog website roles on the same server should be ok. The web service role connects directly to the SCCM SQL database so ensure that the network connectivity between the SQL server and the Application Catalog web service servers is robust.

If you have more geographically distributed users, consider deploying additional application catalogs to keep responsiveness high and user satisfaction up. Use client settings to configure collections of computers to use different Application Catalog servers.

Continue to read the complete blog post here :

Security is necessary in today’s world, that’s undeniable, but that doesn’t make it fun.

At my current customer, most everything was going swimmingly well until I went to deploy the first test client. This was a manual install from the command-line — not that that should make any sort of difference though. So, while watching ccmsetup.log like any good ConfigMgr admin, I was greeted with the following major failure as ccmsetup tried to download files from the MP.

Checking the URL ‘’
Got 401 challenge Retrying with Windows Auth…
Failed to correctly receive a WEBDAV HTTPS request.. (StatusCode at WinHttpQueryHeaders: 401)
Failed to check url Error 0x80004005
Accessing the URL ‘’ failed with 80004005

The first question of course was why was it failing back to the MP to download the files? Checking the log file a bit further up revealed pretty much the same series of messages for the package on DP at$/XYZ00003. Per HTTP 401.x-Unauthorized on TechNet, an HTTP error code of 401 means Unauthorized. Correlating this to the IIS log file revealed a 401.3 code which translates to “Access is denied due to an ACL set on the requested resource” per the same article. I also cranked up procmon to watch the process in real time — this revealed much the same: an Access Denied when trying to hit the file.

Given that this was a default install of ConfigMgr and IIS, I couldn’t imagine that the ACLs were actually messed up though and a cursory review up the ACLs validated this. The next and usual suspect was AV (not SCEP). After disabling it, there was no change — this made me sad because I love blaming third-party AV: most of the them suck and have caused ConfigMgr admins all kinds of problems in the past and thus deserve to be ridiculed.

The next likely culprit was Group Policy. As it turns out, this customer was using the high security templates available from Microsoft. These are well vetted templates and should work for most things Microsoft, but in this case, something was certainly getting in the way. Blocking the GPO applying these security settings from applying to the site system hosting the MP and DP was up next to rule these settings out or confirm them as being the source of the issue. After this (and a reboot for good measure) … ccmsetup ran through like a champ. So now on to comparing each setting one by one to see which could be the source. After an initial review I narrowed it down to either (or both) the “Access this computer from the network” setting or the “Bypass traverse checking” setting and after some trial and error, the latter turned out to be the culprit. Adding the built in Users group back to this security (along with a reboot) allowed the process to go through.

This makes sense and does line up with the Access Denied as reported by procmon and the 401.3 reported by IIS because the computer account of the system installing the client agent didn’t have explicit read permissions on the folders in the path to the file but did have permissions on the file itself. Time to bribe the GPO admin …

Winter is coming …

The post CCMSETUP and Bypass Traverse Checking appeared first on ConfigMgrFTW!.

Last week I had the pleasure to present at the Computer Weekly 500 Club. An event for IT leaders that, every month, talks about a different subject about modern challenges faced by organizations. I was invited as one of the three speakers for the night along with Ian Turfrey, IT Director at City & Guilds and Andy Beale, Director of Common Technology Services for GDS. The topic of the month was the future of desktop and technology in general after Windows 10 is released. Conversations were very diverse and the round table discussed very interesting topics proposed by the audience. A great article with the main topics of the events was published on the Computer Weekly website. Check it out. For those who missed the event, here is a brief intro video recorded on the night. Cheers David Nudelman

Read the complete blog:


Hi All, SCCM gives you the ability to remote access to client machines. This is not new as this feature has been there for quite a while. Interesting is that SCCM gives you 3 options for remote access: 1- Remote Tools (Remote Control). This is a “SCCM feature” 2- Remote Assistance: This is a “Windows Feature” and what SCCM does is to set local GPO to allow/block access 3- Remote Desktop: This is also a “Windows Feature” and again, SCCM only set local GPO to allow/block access. What is really interesting here is what happen “behind” the scenes regarding firewall. When you open the client settings for remote access, the 1st option is to enable/disable and also configure the firewall. There are many people that think that once you enable, SCCM will enable the firewall for all 3 options..but unfortunately this does not happen. The only rule SCCM does manage…

Read the complete blog:


Issue: Print jobs taking too long to get to the printer. Branch offices were experiencing small delays between hitting print and the printer actually getting the job

Diagnostic: All the traffic is going through the WAN as printers are configured through policies.

Solution: As we use Windows 8 and Server 2012, we identified the “Branch Office Direct Printing” which is a functionality in Server 2012 would resolve our issue, as it captures the ports and send the print job directly to the printer is the printer is local, instead of going through the print server.

Result: Faster printing on branch offices and reduced WAN utilization.

Branch Office Direct Printing

More on Branch Office Direct Printing