This post is a continuation of my previous post: http://myitforum.com/cs2/blogs/jsandys/archive/2010/05/09/software-update-management-and-group-policy-for-configmgr-what-else.aspx.
So how do the rest of the settings in the Windows Updates Group Policy section affect Software Updates in ConfigMgr? The short answer is that they don’t. These settings effectively control how the Windows Update Agent automatically handles updates. With ConfigMgr, the Windows Update Agent (WUA) is still used as I discussed in the previous post. The key word in the statement is “automatically”; with ConfigMgr in the mix, the WUA doesn’t automatically do anything. It’s not that it can’t do work automatically, it’s that the WSUS server itself does not have any updates for it so it effectively does no work – recall once again that all updates are delivered via the software distribution mechanism in ConfigMgr and not WSUS. When ConfigMgr wants to do anything related to software updates, it directly controls the WUA to achieve the desired result: this includes update scans, re-evaluations, and installation. Thus, all of the other settings are essentially harmless or have no effect.
There are a couple of things to be aware of though. First, if you set the Configure Automatic Updates setting to Disabled, then the WUA will not automatically update itself from WSUS. WUA updates are periodically sent out by Microsoft and are picked up by WSUS. These are not listed as formal updates in WSUS and are automatically pushed out to all client systems set to update.
This may or may not be your desired outcome. In general, it is recommended to set this setting to Disabled and distribute an updated WUA using software distribution in ConfigMgr. If you allow WSUS to perform this task, you have no control over how WSUS pushes the WUA out. Clients will download the updated WUA using BITS, but essentially, every client that checks in will get it as soon as they check in. Depending on your network infrastructure and Software Update Point topology, this could be a bad thing. I have noticed one or two other updates that also do not need to be approved in WSUS but are still made available to clients so the users may also get prompted for these – just something to be aware of.
The other ramification of leaving this setting at Enabled is that the WUA will detect when a restart is pending and display an additional warning to the interactive user which could be very confusing. By default, if an update deployment suppresses restarts, ConfigMgr will display an alert to the user (shown below).
Note that leaving this policy at Not Configured in a GPO doesn’t change anything, it just leaves the actual setting as is whether it was set manually on the system or using another group policy. The ramifications above still apply.
On both Windows XP and Windows 7, at the WUA scheduled scan time (every 22 hours by default), the WUA will check if there any pending restarts. If there are, it will display its own notification (shown below) in addition to the ConfigMgr notification. The only difference I could see between XP and 7 is the ability in 7 to dismiss the notification set it to remind the user at a later time.
So, even though the WUA isn’t actually automatically installing updates, its still trying to help or actually getting in the way depending on how you look at it. And of course, users being users, this will undoubtedly generate at least a few help desk calls.
One thing to note is that setting the Configure Automatic Updates policy to Disabled does not disable the Windows Update service in Windows 7 or the Automatic Updates service in XP (these are the WUA service itself, just different names in the different versions of Windows). It merely disables automatic functionality of the WUA including scanning. The Automatic Updates service must be running for software updates in ConfigMgr to work properly. Using a group policy to set this service to automatic is recommended.
One major monkey-wrench in all of this is Forefront Client Security (FCS) 2007. FCS uses WSUS to push out its updates and definitions. Because definitions can get pushed out many times during a single day, using the software updates functionality in ConfigMgr would be cumbersome to say the least – it just wasn’t built with FCS in mind. Thus, you will have to enable the Configure Automatic Updates policy using a GPO. You should also set this policy to 4 – Auto download and schedule install. However, this will potentially result in the above behavior depending on the timing of the various events involved. Additionally, because definition updates should happen without any user intervention you should also set a handful of other Windows Update related policies according to FCS recommendations. As notes earlier though, these settings have no impact on the software updates functionality ConfigMgr though. (Complete guidance for configuring Software Updates in ConfigMgr for use with Forefront is available at http://technet.microsoft.com/en-us/library/dd185652.aspx.)
Group Policies are great and the Windows Update Group Policies have some great functionality; unfortunately, none of them actually do anything to Software Updates in ConfigMgr. Without FCS, the most you should set in relation to Windows Updates is the Configure Automatic Updates policy to Disabled and forcing the Automatic Updates service to Automatic. With FCS, as described above, this gets a little more complicated because you have to remember that WSUS is actually distributing updates for Forefront and thus the WUA has to be configured accordingly which may subject your users to the double restart notifications and the “uncontrolled” push of an updated WUA.
Thanks to John Marcum (http://myitforum.com/cs2/blogs/jmarcum) for supplying some supporting material.
There is definitely a lot of confusion about how Group Policies interact with, control, and affect Software Update Management (SUM) on ConfigMgr clients. At the outset of this post (or series of posts), I don’t even know exactly what’s going to happen with some of the different settings and combinations that I’m going to try and then document.
The Windows Update Agent
The Windows Update Agent (WUA) is the key Windows component that handles both update scanning and update application to a system – this is the same whether the system uses Microsoft Updates from the web, WSUS, or ConfigMgr for updates. Because ConfigMgr actually uses WSUS, these two methods have a few things in common, specifically, the actual delivery of the update catalog to the clients. In both cases, this comes straight from WSUS and thus the use of the same group policy setting(s). Additionally, there are other settings in group policy that effect how the WUA agent behaves which I intend to explore.
Domain Group Policies vs. Local Group Policies.
As their names imply, domain group polices originate from the domain and local group policies originate on the local system. A common misconception is that local group policies are simply local registry edits in one of the above policy keys. This is not true; although you may get the desired result, this is not a true local group policy. To edit a local group policy, you must open the local group policy editor: gpedit.msc. Also note that domain group policies overwrite settings defined in a local group policy without prejudice on a setting by setting basis. Thus, only settings actually configured in the domain group policy will trump those defined in the local group policy; settings defined in a local group policy and not in the domain group policy will be left unaffected.
Why is the local vs. domain distinction important? Because ConfigMgr uses local group policies to configure the Windows Update settings on all managed clients. The clear implication here is that if you have any Windows Update settings in a domain group policy, they will overwrite those that ConfigMgr sets. The settings in the screenshot below were configured by the ConfigMgr agent in my lab environment and viewed using gpedit.msc.
So what happens if we do have a domain group policy and how can we troubleshoot this? It depends on which settings are applied in the domain group policy.
Setting the Server
The first setting to test is the actual update server. First, I’ll set it to the same value that ConfigMgr sets it to.
First a gpupdate /force and then initiate a Software Update Scan Cycle from the ConfigMgr agent Control Panel applet and check wuahandler.log on the client.
So far so good. Next, let’s set the domain group policy to point to another server and see what happens.
Another gpupdate /force, initiate a Software Update Scan Cycle again, and finally check wuahandler.log.
Egregious FAIL!
Notice what the log file says here: “Group policy settings were overwritten by a higher authority”. From this it is apparent that ConfigMgr checks to make sure that the WSUS settings do match up with those that it expects, namely the server location, and if they don’t it “gracefully” stops processing.
One of the first things I tried way back when at a customer site was to trick the process by overwriting the values directly in the registry. As many folks know, all of the group policies contained in the Administrative Templates section ultimately just set registry values (see What Is Administrative Templates Extension? for more information). The Windows Updates settings are in this section and thus update specific registry values located in HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate; note that the WUA will not automatically notice that you’ve updated the values manually so you must restart the Automatic Updates service to make them effective.
So what are the results? As you may (or may not) expect, everything worked. Of course, as soon as group policy decides to refresh, you’re back at square one.
One thing I learned in testing and verifying the above was that if the Windows Update server is set to a name that either does not resolve or is not a valid WSUS server, Windows Update is not a happy camper and neither is the ConfigMgr agent. It took multiple stops and starts of the Automatic Updates service and the SMS Agent Host once a valid update server is set for everything to work as expected again. It seems that if Windows Update has any kind of error connecting to the configured update server, the ConfigMgr agent refuses to do anything as far as software updates go – the wuahandler.log will show an initial error message but then will not show anything else until the problem is corrected, which as I just mentioned, took restarting both services. If I was patient, I think things might sort themselves out eventually, but restarting the services expedited the process.
XP: Keep Your Computer Up To Date
Another thing I noticed on my XP test client is that if there are no policies applied, either local or domain, and Windows Update has not been manually configured, then the “Keep your computer up to date” notification icon is displayed along with the associated balloon message. This is the default state of all Windows XP systems in my experience.
As soon as a Windows Update policy is applied though, including the ConfigMgr local group policy for Windows Updates, the icon and balloon are removed. This can be seen in the WindowsUpdate.log.
Windows 7: Action Center
The (nearly) equivalent behavior in Windows 7 is handled by the Action Center as seen below. However, getting rid of this message is not the same as in XP. The Action Center is a completely separate component from Windows Update and thus its messages are not generated by the WUA itself. To get rid of this message, you must set the “Configure Automatic Updates” setting; the local group policy set by ConfigMgr for Windows Updates is not sufficient. By default (in my testing at least), this setting is already set on the component at install time to “Auto download and schedule the install” and so you don’t actually need to do anything. If for some reason it’s not set though, just use a group policy to set it (local or domain).
If you set the “Configure Automatic Updates” setting to anything other than the default “Auto download and schedule the install” including disabling it, the Action Center will show the following message:
The Action Center itself is way beyond the scope of this blog, but I did dig up a few links for reference:
This blog post is long enough now so I’ll continue in another post tomorrow (hopefully). Next up is looking at the other “Configure Automatic Updates” settings and how they affect Software Updates in ConfigMgr as well as actually stopping the WUA service (i think we can all guess what happens when we do that).
From my presentation this morning at MMS I had two follow up questions that I promised to post links for. Well, here they are.
The first link is for a failure in USMT after the installation of the hotfix described in KB article 974571: http://support.microsoft.com/?kbid=977203.
The second link is to a post by Roger Zander that contains an exported task sequence snippet containing task steps to install Intel mass storage drivers using conditionals based on WMI queries looking at the actual storage hardware device by device ID instead of by vendor model: http://myitforum.com/cs2/blogs/rzander/archive/2009/08/07/apply-xp-massstorage-drivers-from-sccm-osd-task-sequence.aspx.
Importing duplicate drivers into Configuration Manager has adequately been covered by Johan and William Bracken. The process that both outline in their posts is simple and easy to implement but very time consuming if done manually on more than one or two system models. At a client recently, I whipped up a quick script to automate this process.
@ECHO OFF
for /f "tokens=*" %%G IN ('dir /ad /b /s') DO (
echo. > "%%G\%~n0.txt"
)
Just put the above code into a batch file at the root of your directory structure for a given model and name it for that hardware model; e.g., name it Optiplex755.bat and put it in the root of the folders housing the Optiplex 755 drivers.
Executing this simple batch file will create an empty text file named Optiplex755.txt in every sub-directory.
Repeat as necessary for each model and each model’s top-level driver folder.
If you add or change any drivers for a model, just re-execute the script.
Here is my slide deck from a ConfigMgr OSD 101 and Best Practices presentation I recently gave at the Central Texas Systems Management User Group (CTSMUG). CTSMUG is run by Greg Ramsey.
Q. What’s new in USMT 4?
A. Easier to reference a link on this one: http://technet.microsoft.com/en-us/library/dd560752(WS.10).aspx. Here’s a quick list though:
- Hard-link migration store
- Improved Space estimation
- Ability to gather data from an offline Windows® operating system using the ScanState command
- Domain controller access is no longer required by ScanState and LoadState.
- Integration with Microsoft System Center Configuration Manager (SCCM) and the Microsoft Deployment Toolkit (MDT)
- Configurable file errors
- New helper functions
- Volume shadow copy support
- Local group migration
- List files being migrated
- Usmtutils.exe
- New AES encryption options
Q. Which version of USMT should I be using with Configuration Manager.
A. It depends. USMT 4 has many improvements but cannot be used in all cases. First, you must install ConfigMgr 2007 SP2 for full USMT 4.0 support. Also, USMT 4.0 cannot restore to Windows XP. It can capture from XP, just not restore to it.
Thus, if you are at SP2 and are restoring to Win 7, then definitely use 4.0. The XML schema for the configuration files is compatible so you should just be able to roll any existing configuration files that you have from 3 to 4.
Q. Do I need to create package to use USMT 4.0? If so, where do I get the source files and how do I create this package?
A. Yes, you will need a package to use USMT 4.0. The source files for USMT 4.0 are actually part of the WAIK 2.0 which installs as part of SP2’s installation. Here’s an excellent post by Ronni Pedersen describing the package creation process: http://scug.dk/blogs/configurationmanager/archive/2009/09/10/configuring-usmt-4-0-for-configuration-manager-part-1.aspx.
Q. How do I use offline mode to capture data from WinPE?
A. Check out a recently posted webcast from Niall Brady: http://www.windows-noob.com/forums/index.php?/topic/1885-webcast-%23-1-using-offline-mode-in-windows-pe/.
So COM is a huge topic that I can't even imagine scratching the surface of in a single post; MSDN and CodeProject are two great places to learn about COM though. Note also that in many ways, COM has been replaced by .Net so you won't even see many people using it anymore, but it still exists and won't be going anywhere anytime soon.
Microsoft.SMS.TSEnvironment is the COM object used by Operating System Deployment in ConfigMgr 07 to expose task sequence variables. It is only available during a task sequence and is typically easy to access using built in task sequence tasks and conditions or automation aware scripting languages like VBScript.
For more “robust” development, accessing this object from a more traditional development platform, like Visual C++, is often desirable. Access from various languages was almost the entire motivation for building COM into Windows in the first place so this is perfectly supported and doable; however, automation aware languages typically hide all of the many details of accessing COM objects and thus make it very simple to use them – this is not the case with Visual C++. Usually, the simplification that accompanies VBScript comes at the cost of flexibility and power and always at the expense of speed.
Microsoft didn't provide any specific documentation on using this COM object anywhere except in automation/COM friendly tools like VBScript so here’s my quick start guide.
Because COM has a lot of “overhead” from the developer’s perspective, a lot of engineering and work has gone into Visual C++ to help streamline some of this. Smart Pointers are one of these enhancements: they point to a COM object and control reference counting and automatic clean-up among other things. There are various ways to implement these, but the simplest is to use the Visual C++ #import directive to create the smart pointer classes for us (http://msdn.microsoft.com/en-us/library/8etzzkb6(VS.71).aspx).
- Use #import to tell the Visual C++ preprocessor to create header files and smart pointer based classes from a type library (or DLL in this case) that you can then easily use in code. The DLL to use is TSCore.dll as this DLL contains the implementation of Microsoft.SMS.TSEnvironment; it can be found in any boot image.
#import "TSCore.dll" named_guids
- Add a using directive to transparently use the proper namespace; the classes created above by the #import directive will be contained in the namespace TSEnvironmentLib.
using namespace TSEnvironmentLib;
- Initialize COM
::CoInitialize(NULL);
Note that Microsoft.SMS.TSEnvironment is actually the ProgID of the COM object; a ProgID is a friendly name for a COM Object. The actual class name is ITSEnvClass: http://msdn.microsoft.com/en-us/library/cc143220.aspx.
- Create an object of the smart pointer class ITSEnvClassPtr which is created by the import directive; this class will "contain" the smart pointer to the COM object which is of type ITSEnvClass.
ITSEnvClassPtr tsEnv;
- Create an instance of the Microsoft.SMS.TSEnvironment COM object by initializing our class with the CLSID; the CLSID is contained in a static variable created by the import directive
tsEnv.CreateInstance (CLSID_TSEnvClass);
- Now use tsEnv to call the methods defined for the COM object, specifically GetValue and PutValue. The extra complication here is that COM objects do not by convention use C strings because of marshaling and compatibility issues and instead use basic/binary strings; aka BStrings.
_bstr_t b = tsEnv->GetValue (_T ("_SMSTSLogPath"));
- Don't forget to uninitialize COM when you are done; smart pointers will clean themselves up as well as take care of reference counting (which are huge advantages when working with COM)
::CoUninitialize();
If that all seems really complex, it is. That's one reason COM is (sort of) going away. Once you understand what's going on, it's not a huge deal, but there are a lot of moving parts involved and thus the complexity. VBScript (and other automation aware languages) do everything above for you without exposing you to the details.
What’s New:
- Added conditions
- Added save to and load from data file ability; aka persistence
- Added creation of “is laptop”, “is desktop”, and “is server” TS variables
- Added creation of ts variable for the chosen AppSet
- Created 64-bit version
- Fixed return code bug where pushing Enter to invoke the OK button resulted in a return code of 0xD or tabbing to the OK button and pressing space resulted in 0x20.
Get it here: http://myitforum.com/cs2/blogs/jsandys/pages/osdapptree.aspx.
Any and all feedback is welcome; the application dependencies and enhanced title area are the direct result of feature requests. Please use the contact form at the above link to let me know what you think and for any comments, feature suggestions, or support requests.
By now, most folks know that there are some major changes between IIS 6 (included with Windows Server 2003) and IIS 7 (included in Windows Server 2008) and now IIS 7.5 (included in Windows Server 2008 R2). This of course directly relates to and affects BITS enabled distribution points in Configuration Manager 2007 and the underlying IIS configuration because BITS on the server side is essentially a function of IIS. Actual configuration of IIS 7 and 7.5 in preparation for BITS enabled DPs is covered in TechNet: http://technet.microsoft.com/en-us/library/cc431377.aspx.
Near the bottom of the above linked page is a section that generally tells you to loosen some of the security restrictions in IIS to accommodate BITS distribution of software. This is the result of the inclusion of most of the features of the IISLockdown security tool directly into IIS. These security features prevent IIS from responding to requests using malformed URL strings, which could lead to elevated access or running commands that should not be allowed, or serving restricted content like configuration files or database files. The requestFiltering section described in the article specifically deals with the later and is the usual suspect when BITS is having issues providing content to clients. The ConfigMgr team recently posted a great article on troubleshooting the BITS process:
http://blogs.technet.com/configmgrteam/archive/2010/01/14/troubleshooting-client-content-download-in-configuration-manager-2007.aspx.
I ran into both the bin folder being blocked and the double escape sequence being blocked as described in step 6 of the above linked article. At the time though, I had no idea what was actually causing the problem. My first step was to open the IIS log on the DP and look for any errors. In reviewing the log, I noticed that many of the files were being transferred successfully as indicated by a success code of 200. However, there were numerous files failing with a code of 404 – content not found in HTTP error code terms. The only commonality for the failures I found was that the URLs contained Program+Files – checking the source files reveled that there indeed was a Programs Files folder there – BITS adds the plus to encode the space. Not being an IIS expert I didn’t know exactly how to correct this issue even though I knew what the symptoms were.
I copied the URLs into IE on a client system and received similar results, a generic 404 for the files with Program Files in their path and a download attempt on the others. Just because (call it intuition), I did the same on the DP itself and the error page returned gave me the cause of the symptoms: double 
escaping is disabled. Although I had forgotten and got a little lucky, the thing to point out here is that IIS (by default) will return extended error information to the web client (IE in this case) if the request was local to the IIS system. Thus, if you are having issues downloading content using BITS, locate the URL in the IIS log and enter it into IE on the DP itself and IIS should tell you exactly what’s going on.
In my previous post (Client = No) I mentioned that the ConfigMgr Team had recently posted a good article on client registration but I couldn’t find it. MVP extraordinaire Torsten Meringer sent me the link yesterday.
http://blogs.technet.com/configurationmgr/archive/2010/01/20/how-it-works-automatic-client-approval-in-configuration-manager-2007.aspx
Good on ya Torsten!
At my current customer we are performing a clean, side-by-side upgrade from their current SMS 2003 infrastructure. We are using client push to install the ConfigMgr 2007 SP2 agent on all client systems. Pretty smooth for the most part with two exceptions.
The first issue has to do with automatic uninstallation of the SMS client during the installation of the ConfigMgr agent. On a handful of clients (about 5% of our initial 200 in the pilot group), we were getting the following message in ccmsetup.log and then the log would stop, services.exe would jump to 50%+ CPU time, and the client install would just hang there:
RemoveW2KDrivers. Removing Remote Control drivers ccmsetup
After some web searching and only a couple of hits and some manual inspection we determined that the permissions on the registry key holding the information for SMS Remote Tools mouse driver were somehow corrupt. The exact key is HKLM\System\CurrentControlSet\Enum\Root\*SMS_MOUSE and all of its subkeys (not values). We wrote a quick for loop in a batch script to use regini to connect to every client in SMS and reset the permissions. Given the very low number of hits I got while searching for this issue, I can only conclude that it was something very unique to this environment and perhaps one of the legacy images used to deploy systems.
The second pain point has been that another handful of clients (some of the same ones) would get fully installed, find the MP properly, get assigned to the site, registered, and even start downloading policies but would never actually flip from No to Yes in the console for having the client installed. Multiple collection updates and client Data Discovery cycles changed nothing. This was a real head-scratcher for a while until I ran across an entry in the ClientIDManagerStartup.log on the client:
Smsid is missing but (re)generation is disabled.
A quick web search revealed a couple of posts relating this message to the local SMS certificates on the client system. Given that these were being upgraded from SMS, it made (some) sense that the self-signed certificates created by the SMS Agent were expired, corrupt, or in some other way unusable. Using the Certificates snap-in I deleted the two SMS certificates (located in the SMS store of the local computer account) on one of the systems and then restarted the ConfigMgr agent. During agent startup I monitored the ClientIDManagerStartup.log to verify successful registration. Once that happened, I waited a minute (or two) for prosperity and updated a collection containing the resource and low and behold, the client was now properly showing in the console. I truly have no idea what the exact cause of this issue is/was either. Unfortunately, the actual client registration process is somewhat of a blackbox and very little documentation exists for it. I thought that the ConfigMgr team had recently posted an article with some more detail, but I can’t find it right now.
The next step is automating the certificate removal for systems experiencing the same which I haven’t quite figured out yet because certutil is not native to Windows XP (yes this customer is still stuck on XP, 3,000 systems worth) and as far as I can see certutil has no remote capabilities.
The nasty OSD App Tree bug has been squashed and version 2.5.1 is ready: http://myitforum.com/cs2/blogs/jsandys/pages/osdapptree.aspx.
It has been brought to my attention that a nasty bug slipped by my rigorous QA process that pretty mush kills OSD App Tree 2.5. I will be sorting this out post-haste and posting an update ASAP.
Holy cow batman! The title says it all and is the conclusion of one Mark Russinovich – Windows Guru Guru Extraordinaire.
Check out his blog post: The Machine SID Duplication Myth.
More Posts
Next page »