Speakers: Bill Anderson, Jeff Wettlaufer, Jeffrey Sutherland, Mark Florida
This session is about the successor to Configuration Manager 2007 and not ConfigMgr 2007 R3. It will be a demo session.
The console is like a new version of the OpsMgr/VMM console. It almost looks like a web version crossed with MMC. This breaks up things nicely because the 2007 version is quite cluttered now. Locations of things have been moved around to make it more natural.
I can see straight away that advertisements are no longer involved in software distribution.
Collections, DCM and Asset Intelligence are grouped under “Assets and Compliance” and are all renamed.
Delegation appears to have been simplified with a role model. Currently there are 12 roles in additional to Administrator, e.g. “Application Editor” is a role for a person who creates packages but doesn’t deploy them. This makes it much simpler than the current system. You can copy a role and customise it according to your needs. Security scopes are new. This can be bound with Security Roles to define who can do what actions to what assets. The example we see has scopes for geographic regions.
We get a demo where an AD user is added as a application administrator and is granted permissions to Europe and Sales & Marketing scopes. The console is launched as Bruce. Now Bruce can only see the parts of the console that he has permission to. Much better than what we currently have. Some existing packages are now assigned to a scope that Bruce has rights to by the overall administrator. In Bruce’s console these applications appear automatically.
Next up is Compliance Settings (aka DCM). A baseline is defined for an application. We can see there is a high rate of non-compliance. We can be notified automatically that a baseline has a specified non-compliance rate, e.g. if compliance is less than 80%. An alert is in the Compliance Settings summary. Depending on the baseline, there might be action links for the alert, e.g. remediate the non-compliant component.
Each major feature will have a similar alerts section in the final product, e.g. if s/w deployment is below a certain level then your application deployment team can react immediately. You can only see alerts within your scope. It is also possible to do automatic remediation. This is a tick box for when there is support for a remediation, e.g. script based, WMI or registry settings. This means ConfigMgr could fix non-compliant machines with no human action.
We get a demo of Windows registry device compliance. The registry setting is originally non-compliant but is automatically changed to bring it into a compliant state.
Device (mobile) management will be integrated with normal (PC) management. You’ll get to them via the same wizard start up points. We’re shown the configuration of some Compliance Settings for Windows Mobile devices: Device Wipe (5 incorrect login attempts are allowed and 6th will automatically wipe the device), Password (4 character minimum PIN with idle timeout) and Platform Lockdown (prohibit camera). This baseline is assigned to all systems. Non-mobile devices in All Systems will report as compliant because the settings are irrelevant. That’s good.
A demo: The settings are forced onto a Windows Mobile device.
We now have “Applications”; a generic container. This contains deployment types. For example, you can have a mobile device deployment or a Windows deployment for a single application. ConfigMgr figures out the right one to use. A Detection Method is defined (e.g. the installer code or a script). If the s/w is there then it’s not installed. If it’s not there then it is installed. Requirements are specified, e.g. memory, disk space. A new one is user device affinity. A user’s primary device might be where you install bespoke expensive software, e.g. Visio. If they temporarily log in else where the s/w won’t be deployed, i.e. not wasting licenses/money. “Primary Device” can be manual, a result of Asset Intelligence or even user self-defined.
Advertisements are replaced by Deployments. You can set an Intent, e.g. mandatory, available (puts the app in a catalog) or prohibited (the uninstaller is invoked). The catalog is a web UI where users can elect to pull down optional software, e.g. Adobe Reader. The s/w will install automatically for the user. A Silverlight control on the site will immediately communicate the client on the computer to kick things off quickly. Application deployment rules are still applied, e.g. if the app is not appropriate for the user/machine then it will not install. OH HELL SWEET: There is a workflow built into this where software can be set up to require approval. For example, a user requests Visio but this request must be manually approved. This is major stuff that every SMS/ConfigMgr customer will love.
Packages and Programs isn’t changing. However there will be file level single instance storage on the Site Server between packages.
There are now distribution point groups. You assign software to the DP group and any distribution point in it gets the software. You can build new DP servers and add them to the group. They automatically get the software. Another big improvement for larger architectures.