Month: March 2012
Troubleshooting ACT Log Processing
Ran into a problem where ACT was deployed to many computers, their data was successfully being created on the file share, but the computers were not showing up in the App Compatibility Manager. What I discovered (as it’s been awhile since I last used ACT) was that there is a log processing service which imports the logs from the share into the database.
In troubleshooting the issue, I came across and excellent guide by Microsoft for troubleshooting the log processing service. I went through every step and in nearing the end of the guide, the computers were still not imported. Ironically, the very last step was my fix and it was the easiest step – check that the Windows service “Act Log Processing Service” is running. Really? That couldn’t have been listed as one of the first thing to check?
SCCM Guru Webcast – 1 Week to Go!
In one week from today – on March 28th – I will be presenting for BDNA’s SCCM Guru webcast series on the power of SCCM task sequences. To sign up for the webcast, visit the registration page at http://info.bdna.com/20120328Webcast-SCCMGuru-NickMoseley_RegistrationPage.html. Additionally, this Friday, I am presenting a bulk of my material to our Denver-area Microsoft Enterprise Management User Group. If you’re here, please come!
SCCM task sequences are most commonly used for operating system deployment. They have tremendous power and usefulness, which are often unknown, overlooked, and underutilized.
In this presentation, we will explore various aspects of task sequences and demonstrate ways that they can be used in your day-to-day administration of SCCM – including uses outside the realm of deploying an OS!
Migration Strategy for WSUS to SCCM & Software Updates
The key to protecting an environment from incidental patching during a transition from using WSUS to using SCCM with Software Updates is to reconfigure three group policies which have an impact on SCCM software updates.
- Specify intranet Microsoft update service location: the SCCM client sets this as a local GPO pointing to the SCCM\WSUS server. (Note: It could be possible to set these values as domain GPO, but the trouble is that there are two SCCM servers acting as WSUS for their clients, so managing multiple GPOs would be more pain than value.)
- Configure Automatic Updates: this will set the automatic update settings. I’ve seen that once this was turned off in GPO, it kept the default to automatically download and install updates. It is possible to set this to Disabled without impacting SCCM’s delivery of security updates, but it will impact delivery of FEP definition updates. With SCCM 2007 and FEP 2010, in order for definition updates to automatically install, auto approval actually gets set in WSUS itself, so therefore disabling AU would mean no delivery of those updates and need to be re-enable in the future.
- The final GPO is just configuration of the Automatic Updates windows service. If the GPO disables the service, then no updates will work. A forced enable of the service through GPO would be a good thing.
A route for the WSUS to SUP migration could look like this:
- Configure Automatic Updates set to Disabled
- Enable the AU windows service
- Optional: continue to disable user’s ability to get updates themselves from Windows Update
- Set all other WSUS related GPOs to not configured
- Updated 6/14 (Tip from Kevin in Denver) – remove any Domain Group Policy setting pointing to a location for Automatic Updates. This needs to be left“Unconfigured” in order for SCCM’s SUP to work correctly.
- Deploy the SCCM client upgrade/changeover
- Later, as part of a FEP migration, use GPO to configure automatic updates to be enabled (since that will be needed for automating the definition update releases)
SCCM & Cisco NAC
I ran into an interesting issue with a SCCM implementation in an environment that utilizes Cisco NAC to protect their system resources from unauthorized devices. One of the goals of the implementation was to ensure the SCCM clients could still function when no user was logged into Windows, thus NAC agent not being authenticated with the production VLAN. In order to accomplish this, ports used by SCCM needed to be opened, allowed, and unrestricted to the SCCM servers.
The issue that we found was when the computer was on the “dirty” VLAN, the SCCM client would switch from being an Intranet client to an Internet client. Furthermore, the client’s LocationServices log showed that it was failing to locate the MP from AD and the SLP from AD.
Using a network monitoring tool called WireShark, we identified that the client was trying to communicate with AD on TCP port 3268. This is a normal port used by AD for LDAP. Checking into the configuration of NAC, it was certainly not allowing communication over that port. As soon as that was allowed, the SCCM client immediately began functioning to download software updates and SWD packages. Who knows whatever else was fixed through this discovery…
t3chn1ck 