Last week I was fortunate enough to attend System Center Universe 2012 live in Austin. Wally Mead was the speaker for ConfigMgr 2012, like anyone else could do better, and gave a great overview of the new AWESOME product. Fortunately, Wally was in Austin a day before SCU 2012 and a day after to present to the CTSMUG both days. I was lucky enough to be in town to attend bother user group meetings along with SCU 2012.
I took as many notes as I could throughout the session and consolidated them down for this post. Hopefully this will be useful for anyone that’s starting to look at System Center 2012 Configuration Manager and how it’s changed from Configuration Manager 2007.
· ConfigMgr RC2 is completely announced – was announced 1/17/2012. This was not a planned milestone. It was needed to provide a build for System Center 2012 (RC1 was out in October in the form of a standalone download.
· There are negligible differences between RC1 and RC2. The install wizard has changed and now requires you to accept the EULA for SQL Express and Silverlight.
· There will not be upgrades available from RC2 to RTM once it’s made generally available. The only exception is if you are a TAP customer, then you will be able to upgrade.
· RC2 will install in “Evaluation” mode, however it will not time bomb. Once the product is RTM, if installed in “Evaluation” mode, it WILL time bomb.
ConfigMgr 2012 Tech Tidbits:
· Software Distribution:
o When utilizing the new Application model, the ability to Supersede an applications has been added. As an example; upgrading application ABC from v1 to v2, you would supersede v1 with v2 so any machines in the field will remove v1 and upgrade to v2 automatically. Or if a client requests v1, they will receive v2 of the application. This is similar to how software updates function.
o The Classic application model still exists in 2012. This is what an admin would use if they needed to deploy a batch file or something that would not work in the new Application model.
· Hierarchy and Site Components:
o The hierarchy has changed to the point where you can only go three tiers deep. This would be a CAS (Central Administration Site) server, under that a Primary site server, and the third tier would be a secondary site server. The CAS cannot have clients assigned to its site, and secondary site servers cannot be attached to the CAS server.
o If a hierarchy will be built using a CAS, the CAS server MUST be installed first in the hierarchy. Primary site servers that will report to a CAS server MUST be joined to the CAS hierarchy at install. No longer can you add a primary to a central site server at a later time as you could with ConfigMgr 2007.
o Installing the Admin console on site servers is no longer required.
o The total supported client count for a hierarchy has grown from 300,000 with 2007 R3 to 400,000 with 2012.
o The majority of global data in the hierarchy is now replication using SQL replication. The replication control manager log is the log file to use when troubleshooting. The old inbox file based replication has not completely gone away yet it’s still used for some tasks. Most of the data sent from the secondary site server to the primary is still done via inboxes, but most of the CAS to PRI transfers are performed via SQL replication.
o By default when a Secondary Site server is deployed, the Proxy MP role and the DP role are installed. With the new sender capabilities with Distribution Points, and secondary site server is really only needed for the flow of traffic to the primary.
o Standard DPs now have senders for throttling and scheduling. This should cause the count of Secondary sites to drop. Distribution Points also now have the PXE point role built in, which mean the PXE Service Point role no longer exists as a site role to add to site systems. You will simply go to the properties of the DP and enable the PXE role.
o Distribution Point content can now be pre-staged for new physical sites getting a DP.
o Distribution Point groups have been reworked to now allow content to automatically be added to a new DP once it’s added to a DP group. This is a great improvement from ConfigMgr 2007.
o The Distribution Point role is the only role that will run on a 32-bit OS. The supported Operating Systems to run the DP role are; Server 2003, Vista SP2 and later, Server 2008 and later.
o ConfigMgr is now all Unicode based and the admin is asked which language to install during install. This can be changed later after install as well. You now no longer need different language versions of ConfigMgr to install for sites depending on the admins location and language.
o You can now have multiple SMS Providers per site. This would be used for load balancing and high availability for remote consoles to connect to.
o Management points no longer need to be setup in a NLB configuration to have multiple MPs per site. You can now have up to 10 MPs per site.
o The application itself is now 64-bit and there is a native 64-bit client.
o The client support numbers have not really changed other than the CAS (Central) server being able to support 400,000 clients now instead of 300,000.
o With the new features of RBAC (Role Based Access Control) the only time a primary site server needs to be added is when scaling out, or for some political reasons, but this really should no longer be valid with RBAC setup correctly. With the new RBAC features, when a user opens the console, they will only be presented with what they have access to. This is a great improvement over ConfigMgr 2007 role access features.
§ There are pre-built roles with-in RBAC that include:
· Application Administrator
· Application Author
· Application Deployment Manager
· Asset Manager
· Compliance Settings Manager
· Endpoint Protection Manager
· Full Administrator
· Infrastructure Administrator
· Operating System Deployment Manager
· Operations Administrator
· Read-only Analyst
· Remote Tools Operator
· Security Administrator
· Software Update Manager
§ These Roles can be copied and modified for customization.
o DCM (Desired Configuration Management) has been renamed to Compliance Settings and now features remediation. You can also connect to a “Gold” system when configuring baselines to grab desired settings to check against.
o There are Discovery enhancements that include better delta discovery which is enabled by default, and a full discovery scan every 7 days. Delta Discovery will also watch for AD group changes and update the ConfigMgr database accordingly. Discovery can also filter out stale accounts by the admin specifying to not discover machine or user accounts that have not changed their password, or checked into AD in a specified number of days (default is 90).
o Active Directory Forest Discovery – is a new discovery feature that will gather AD forest information, including child domains and automatically create boundaries based off AD site or Subnet if you enable that feature. This gathers very useful information since ConfigMgr 2012 can now cross publish into trusted domains without having to have a site server a member of that domain.
o Mixed mode and Native mode go away in ConfigMgr 2012. Now a roles for a site can either be HTTP or HTTPS, and this can be mixed up among the roles within a given site.
o The AD Schema has not changed from ConfigMgr 2007, so if this schema change has already been applied in your environment, there is nothing to upgrade again.
o Boundaries must now be part of a Boundary Group before ConfigMgr will acknowledge/use the boundary. Boundary Groups also play two roles now and are used for either content or site assignment or both, depending on how the admin wants to build out the hierarchy.
o Sub-collections go away in ConfigMgr 2012. Collection folders are now used as an organization tool as was it was typical for multiple collection levels to exist in ConfigMgr 2007 for organizational purposes.
· SQL Requirements:
o Secondary site servers now require an instance of SQL due to the new SQL replication features in the hierarchy. If a SQL server and instance is not provided during the setup wizard, SQL express will automatically be installed and configured by ConfigMgr.
o The CAS server can use SQL Standard edition if the entire hierarchy will have less than 50,000 clients. If the hierarchy has 50,000+ clients, then the CAS must use SQL Enterprise for its database. The database role can stay local to the ConfigMgr server.
o The Primary site server does not have a dependency on SQL, either Standard or Enterprise can be used all the way up to the supported client management count of a primary site server (100,000 clients). With that being said, if the Primary site server will manage more than 50,000 clients, then the SQL role must be split off to its own server. This is the only configuration supported by Microsoft.
o ConfigMgr 2012 requires the following SQL versions:
§ SQL 2008 R2 SP1 w/CU3 & KB2603910
§ SQL 2008 SP2 w/CU7 & KB2603910
· Client Side Changes:
o RAP (Run Advertised Programs) is no more. It has been replaced with the Software Center. The software center is much easier on the eyes and is Silverlight based. Software Center will show all applications that have been deployed and targeted to devices. It will also show what applications are already installed on the user’s system, if the application was built with the new application model. There is now an Option Tab that allows users to set their business hours and basic desired settings with remote control, as long as the admin has enabled these features.
o For user targeted Applications, there is now a web based software catalog. Users can browse any applications available to them and install from the web page portal. The admin has the ability to make an application require approval. By default this sends an alert to the ConfigMgr console for the admin to approve. Once approved the application will automatically install on the end user. The ConfigMgr team does have APIs available for integration with help desk software or System Center Service Manager where the users manager could be emailed and have to approve the software install or kick off a workflow of some kind.
o Client Health has also been improved. In ConfigMgr 2007 the general client health count was around 80-85% healthy clients. Today with TAP customers Microsoft is seeing 95-97% healthy clients. This is mainly due to the new automated client remediation built-in into the ConfigMgr client now. When the ConfigMgr agent installs, it will create a scheduled task that will run every night between 12:00am and 1:00am to verify WMI health and all necessary client services are running. If users delete this scheduled task, the ConfigMgr agent will reinstall it. With the new client health features, there is also now reporting to show what was causing bad health of the client. As a side note brought up by Dell ConfigMgr team, you can set WMI repair and client health remediation to Evaluate only mode. Dell is using the new Compliance Settings feature to modify the client registry on all of their servers so WMI will not randomly get repaired on an Exchange server or ConfigMgr server and cause an outage.
o The power management features of ConfigMgr 2007 R3 are also in ConfigMgr 2012. There has been some intelligence added so that if the ConfigMgr client detects it is installed on a VM, it will automatically turn off power management. If given access, users also now have the ability to opt-out of power management from the options tab in the Software Center.
o UDA (User Device Affinity) was also added in ConfigMgr 2012. This allows ConfigMgr to figure out what machine is a user’s primary workstation based off of login frequency and login duration. The user can also “Claim” a main primary machine using the options tab in the new software center. With this new feature, ConfigMgr will now decide what deployment type to use with deploying applications with the new application model. As an example; An application is deployed to a user and the user logs into their primary workstation, so ConfigMgr will deploy the MSI and install the application on the system. Let’s say the same user logs into a general use machine that is no their primary workstation, now ConfigMgr will NOT install the application, but will instead present it using either App-V or as a Virtual App. This is of course if these deployment types and deployment rules are configured correctly by the admin that packaged the application within ConfigMgr.
o Migration from ConfigMgr 2007 to ConfigMgr 2012 is only a side-by-side now. In place is NOT supported.
o The new ConfigMgr 2012 hierarchy will have the ability to connect to the old 2007 hierarchy to migrate objects over using “migration jobs” configurable by the admin.
o Migration jobs can move collections, clients, advertisements, and packages. Once the packages are moved over, the source location will still point to the UNC path that was configured in the ConfigMgr 2007 site. So if this is not on a file share that will stay, it must be updated after being migrated to ConfigMgr 2012. Users and Devices cannot be in the same collection when collections are migrated over. This is due to the new application model and user centric design of ConfigMgr 2012.
If anyone has any questions about anything missing here, or don’t understand what’s here, contact me and I’ll help as best I can.
Take the notes with you! Read it on the plane, on a train, on your mobile device.
Download: Notes from 3 days with Wally