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!