Introducing SCCM 2007 R3
SCCM 2007 R3 (R3) has released! R3 is not a service pack – it is an addon that brings additional functionality. R3 includes all of the features of R2 and requires that SCCM 2007 SP2 be installed because the SP2 version of the SCCM client has the needed functionality for R3. In addition, there is a requirement to deploy a client side hotfix for R3 – this is described in KB977384. R3 won’t allow the install to proceed until this hotfix has been applied. There tends to be a decent amount of confusion about an Rx release compared to a service pack so hopefully this helps clear things up.
When deploying KB977384 you have a choice to allow the install to create a package for you or to create the package manually. If you choose to have the package created automatically it will be similar to what I have below.
So what exactly is in this R3 addition anyway? R3 is mostly about power management. There are some other interesting additions as well. We will walk through each.
Power Management
The power management feature of R3 makes use of SCCM hardware inventory – so make sure hardware inventory is enabled when R3 is installed. During installation R3 will add some inventory classes to the SMS_DEF.MOF. The R3 inventory changes are an addition to the MOF files rather than an overwrite of the MOF files as we have seen with service packs so there really shouldn’t be a need to backup your MOF’s first – but it’s always a good idea just to be safe.
If you take a look in the SMS_DEF.MOF after R3 is installed you will see the specific sections that are added – just search for PWR.
So what are the components of power management? There are two – the power management client agent and the collection specific power settings. The power management client agent is shown below – the only setting here is either enabled or disabled.
The per collection power management settings is where the configuration is done. Notice that in my lab I’ve built two collections – one for systems where I specifically do not want a power policy applied and one where I will define my power policy.
If we right-click on any collection we can set power policy for the collection. Let’s start with my no power policy collection.
Notice the power management setting – in my no power policy collection I first enable power management settings and explicitly configure to never apply power management to systems in the collection. This will ensure that these systems never have power policy applied. So what happens if a system is in this no policy collection and another collection with power policy? First, that shouldn’t happen if you configure your collections properly but if it does the ‘never’ policy will supersede any configured power policy so the system won’t have any power management applied to it.
OK, so lets look at the settings for power management where we do have configured power policy.
Here we have configured power settings – the peak plan will be high performance and the non-peak plan will be power saver. Notice that you have full control of the hours where peak policy applies. Note also that there is the ability to configure a wakeup time for systems in this collection. The wake up time will power up systems to allow them to do any pending work assigned through SCCM.
A common question here is what mechanism is used to wake the systems – is it wake on LAN, is it AMT based? No to both. Windows has internal powerup timers that will function as long as there is power available to the system. When the preconfigured time arrives the system will know to wake up.
Note: Wakeup is not supported for laptop systems to prevent a scenario where the system will wake up on battery and exhaust power before shutting back down.
Another common question – suppose a system wakes up but power policy is configured to have it sleep again in 15 minutes of inactivity. Suppose also that SCCM has work queued up that will take longer than 15 minutes – will the system sleep in the middle of SCCM jobs? No. While SCCM has work to do we keep the system in an active state so that it will sleep only when all scheduled work is done.
So what power policies can we configure here? If we select view we see the list and the default/configurable values.
We can change whatever we like here and the modifications will be saved against the current collection – other collections will be unaffected.
OK – we have the power policy configured – what does it look like on the client? We have both a Windows 7 and Windows XP test client – the settings apply to both. If we look at the Windows 7 client we see that the power policy that is in place indeed is coming from SCCM – and the user has the ability to change the plan settings. It’s a futile effort though as with every 24 hours (not every policy cycle) we will just set power settings back to what we have configured for the collection.
Our XP test system also has applied the SCCM power settings but notice that with XP the user has no ability to change the settings. Also notice that in XP the SCCM options show up as customized.
So that’s about it for setting up power management. Now that we know how to configure things is there any general strategy for rolling out power management? Yes.
In most cases organizations are interested to know what the impact of power management has been – how much money has been saved? Getting a good handle on these questions is best addressed by rolling out power management in phases. In general terms there are four phases
1. Monitor the current state and power consumption
2. Plan and create the power management policy
3. Calculate savings
4. Check compliance and report savings
R3 power management includes a good number of reports that help track through these phases. At the most basic level we can start with our hardware inventory information. Looking at resource explorer for my Windows 7 system we see the information returned. Note that my test system is a VM so some of the numbers may look odd.
Looking machine by machine is interesting but the reports that come along with R3 provide the ability to get a more holistic view of the environment so you can track what your power usage is currently, how it has changed since applying power policy, savings associated with the change etc.
The reports that come along with R3 will not work with classic reporting. Why? Classic reporting is at the end of life – all future reporting work is focused on SQL Reporting Services so the R3 reports will only be usable if SCCM SQL Server Reporting Services integration is enabled. If you haven’t started working toward SQL Server Reporting Services integration, take a look at my technet article that discusses how to do this and some of the advantages.
Once you have SQL Server Reporting Services integration enabled all you have to do is import the R3 reports.
Select to copy reports to Reporting Services from the right-click menu
Walk through the wizard to the ‘select reports’ screen and you have two choices – either select classic reports to migrate to SSRS or choose to import reports to SSRS (an option that was added as part of the R3 installation). In our case with R3 we want to import reports to SSRS. The cab file we want is in reports > power management folder of our R3 installation.
Once imported you will see the new power management reports under ‘all reports’
Running a sample report – such as the Power Settings reports will return data about the various settings configure on our test systems as follows:
The report shows all of the settings available, how many computers are configured with each and is a drill down report – so if the value in the computers column is selected we further drill into the report to show which computers have the listed setting.
A final question – does power management support both workstation and server OSes? No – the biggest benefit you will see for power management is on the workstation side and workstations OSes Windows XP and forward are supported for power management. Power management of server OSes is not supported at this time.
And that’s it - fairly straight forward for power management. There are a couple of other changes in R3 as well.
Delta AD Discovery
Delta AD discovery looks for changes in AD membership – additions, changes, deletions – and reports just those at the end of the discovery cycle. The advantage here is that AD discovery can be run much more frequently without overloading the site. There is still a requirement to have a full AD discovery on a schedule but with the delta feature the full discovery can be run far less frequently.
Dynamic Collection Updating
Dynamic Collection Updating – also known as fast collection updating – allows for collection additions to be picked up quickly. One of the key benefits of adding systems to collections more frequently is in terms of software distribution. Before dynamic collection updating a system may not receive new advertisements for up to 24 hours (assuming a collection update frequency is once a day – which is the default). With the dynamic scenario and if the system is capable of being found by this method (more on that shortly) the time for software to reach the system is dramatically reduced.
Dynamic collection updates do not apply in all scenarios – only four specific types of configurations can be picked up by dynamic collection updates.
1. Systems being discovered for the first time
2. Systems provisioned by OSD
3. Systems scanned for initial hardware inventory
4. SCCM clients that have been upgraded to a higher client version.
Collection updating happens normally for any system besides those in one of the 4 listed conditions.
While dynamic collection updating is available on all collections with R3 we only recommend it’s use where needed.
PreStaged Media
PreStaged Media allows for the offloading of some imaging responsibility to the OEM. This is a feature that has been in MDT for a while but is now native to SCCM with R3 installed. The idea is that the OEM is provided an image and as part of building PCs they load the provided image. Then, when the system arrives at your company it is plugged into the network and imaging continues from where it was paused. For more information on PreStaged media take a look at this blog entry.
Scalability
R3 increases the scalability of SCCM in that now we support 300,000 clients per hierarchy. Other support numbers stay the same – we still only support up to 100,000 clients on a single primary, etc.
And that’s it for R3 – definitely worth checking out and very easy to use!
Comments
Anonymous
October 14, 2010
Great post, thanks Steve! Very blurry screen shots though :-SAnonymous
October 14, 2010
nice write up.. very informative.Anonymous
October 14, 2010
This is a brilliant very useful blog Steve! You are to be commended! :-)Anonymous
October 15, 2010
Excelent article as always ThanksAnonymous
October 15, 2010
The comment has been removedAnonymous
October 16, 2010
it could be the MVLS site hasn't been updated yet? I've only seen that error if trying to install mismatched versions - such as pre-release R3 on full version SCCM.Anonymous
October 17, 2010
If this is the case, where can I get the full RTM version?Anonymous
October 17, 2010
Doesn't look like it's been posted yet to the volume license site. Not sure when it will be but would expect soon.Anonymous
October 17, 2010
Thanks for your article. I got the point although the screenshots are almost unreadable...Anonymous
October 18, 2010
I'm trying to run the package created by KB977384 Advanced Client Hotfix. If I run the Installer syntax manually: msiexec.exe /p <server>PackageBuildKB977384sccm2007ac-sp2-kb977384-x86-enu.msp /passive - it works. However, if I advertise the same package via SCCM, every single PC reports a failed installation: "The program for advertisement "<advertisement ID>" failed ("KB977384 - Advanced Client Patch Install"). The program was able to be executed but the system was restarted unexpectedly before the program could be completed or before status could be recorded. No installation status MIF was found after the system restarted. Possible cause: The program performs a restart of the client computer when it completes, but the 'After running' setting in the program's properties is not set to Program restarts computer, or the client machine was restarted while the program was running. Solution: Verify the above. If the program does a restart when it completes, even if it only requires a restart in some cases, modify the program's properties and set 'After running' to 'Program restarts computer'. However, if I run the "Count SMS client versions" report on the collection I ran the update against, it reports a client version of: 4.00.6487.2157 - whereas other collections I haven't tried to install it on report a client version of: 4.00.6487.2000 - Does this mean it has worked!? Does anyone know what the SMS client version should be once the upgrade has completed? Thanks very much.Anonymous
October 22, 2010
THANKS so much for this very imformative post! I have been doing a great deal of searching for R3 related information for the last several days, and this is by far the best article I've found!Anonymous
October 24, 2010
Steve, I was wondering if you could elaborate on your comment that WoL isn't necessary because "Windows has internal powerup timers that will function as long as there is power available to the system. When the preconfigured time arrives the system will know to wake up." How does a system in standby know that it needs to wake up (which I thought was the point of WoL) -- are a minimal number of CPU cycles still being scheduled even when a PC is in a low-power state? Great article overall, thanks for the deep dive.Anonymous
November 02, 2010
Hello, nice post :-) But one question; What happens if you dont deploy the msp to all the clients in the network after upgrading the server to R3? Will it stop working/comunicate with the server or will just the power managment option not be there.Anonymous
November 03, 2010
I don't actually know - I've never tried it because the hotfix that ship s with R3 is required - not supported without it.Anonymous
January 02, 2011
Nice quick view of what is inside.. much appreciatedAnonymous
February 23, 2011
In regards to the JE 18 Oct 2010 5:40 PM post: The hotfix it going to restart the SMS Agent service on the client when it is installed. This will result in the 'unexpected reboot' log message. These can be safely ignored. You can use Hardware Inventory to verify the KB is installed. Regarding the version number - I followed the README advice as you did and noticed the same thing. It looks like SMS_G_System_SMS_ADVANCED_CLIENT_STATE.Version does NOT get updated - it stays at .2000. But, SMS_R_System.ClientVersion does get updated to 4.0.6487.2157 I remade my collection rules so they used SMS_R_System.ClientVersion and everything worked fine.Anonymous
March 01, 2011
Where does this leave the relationship with 1E? It appears to me that R3 does a good 95% of what their PC Power Management product does, and yet Microsoft still seems to promote their product. I confused about what I should buy.Anonymous
April 06, 2011
Hi Steve. Can you tell me if the pre stage media is site specific, like OSD boot media?Anonymous
May 03, 2011
Delat discovery for AD Sys Group seems to be of no use as it cannot detect group membership changes (Addition/Deletions), we still have to wait for full discovery :(Anonymous
May 19, 2011
What logs actually show software distribution that completed.Anonymous
May 19, 2011
The execmgr log will show what completed successfully.Anonymous
September 20, 2011
Hi, Very informative atrticle..also good write upAnonymous
February 01, 2012
If we already own the "SCCM2007" select licensing, is that we are elgible to upgrade to "SCCM2007R3"??Anonymous
May 09, 2012
Nice article, but the screenshots are very blurry to the point they are unreadable.