The Admin Console is a big pain point for current ConfigMgr 2007 administrators. Not only is it difficult to customize (allowing certain users to only see the features they administer), it tends to crash often. The Admin Console in 2012 ConfigMgr was completely redesigned and written from the ground up. It does not use MMC, displays only the features the admin has rights to, and has a separate MSI for installation.
If you run a small admin team where everyone does everything in ConfigMgr 2007, then your security configuration probably doesn’t extend beyond giving everyone in the team full rights on everything (very dangerous by the way). With the vast array of features that ConfigMgr 2012 provides, it is likely that even small organizations will be delegating specific administrative tasks to different people and teams. This will require granular definition of security rights, which, while possible in ConfigMgr 2007 was quite cumbersome to manage.
ConfigMgr 2012 offers a completely revamped admin security model. This new model uses a combination of security roles, collections and security scopes to define what objects an administrative user can see and the types of actions he can perform on those objects. A security role is just a collection of permissions appropriate to a role, such as Software Update Manager (there are 14 predefined roles and new ones can be imported).
Admin users are associated with a Security Role which can be restricted to specific Collections and Security Scopes. A Security Scope is simply an identifier that can be applied to specific instances of objects within the console, so for example if there was a site, some Applications, DPs and Software Update Groups that were specific to Asia, it would be possible to associate all of these individual objects with an Asia Security Scope and then restrict administrators for Asia to this group of objects only.