Somewhere between the physical and the virtual
System Center Blogs
Configuration ManagerThe team that supports Configuration Manager.
OrchestratorA blog by the teams who make and support Orchestrator.
Operations ManagerThe folks who make and support Operations Manager.
Data Protection ManagerBlog done by the Data Protection Manager product and support teams.
Service ManagerCommunications from the System Center Service Manager team.
Virtual Machine ManagerThe team that makes and supports Virtual Machine Manager.
System Center HomeThe home page for System Center on the Web.
System Center on TechNetTechNet's agglomerated resources on System Center.
myITforum.comRod Trent's Web site primarily focused on systems and configuration management.
SystemCenterCentral.comThird-party site that pulls together stuff across the SC suite.
Deployment ForumCommunity site about Windows deployment matters.
The Blogcast RepositoryWhere you'll find technical videos, blogs, forums and more on Config Manager as well as other System Center products.
FAQShop.comHints, tips, answers, FAQs on Microsoft's systems management products.
Virtualization FeedMaster aggregator of blog posts and twitters on virtualization.
Virtualization HomeFor all pertaining to the Microsoft Virtualization story.
A couple of years ago, I had to plan a Configuration Manager (ConfigMgr) hierarchy for a customer who had about 6000 workstations and a couple of hundred servers in one city. They wanted to manage both their workstations and servers with ConfigMgr. We decided to create three sites: one empty central site and two child primary sites: one for workstations and one for servers. Different people were responsible for administering workstations and servers. It was easier to grant the necessary permissions to different groups, when servers and workstation were in different sites. Also, the customer didn’t want to use software inventory, software metering or remote tools on their servers. For those main reasons, we had to install three servers, install SQL Server & ConfigMgr to those, configure different sites, define the hierarchy and pay for the necessary software licenses.
With ConfigMgr v.Next, I would use just one site. ConfigMgr v.Next’s Role based access control (RBAC) makes it much easier to define necessary admin rights for different collection of clients. First you decide which security role you want to grant. There are currently 12 built-in roles, but you can create your own roles if necessary. Then you define security scope, which is a group of securable objects. Security scope manages which objects are visible to you. In our example, you just define security scopes for server and workstation related objects and give necessary roles to appropriate user groups. Of course, you can have (and most probably would have) multiple different security scopes. And you can easily define that some users can manage both workstations and servers if needed.
Another major improvement in v.Next is collection specific client agent settings. With v.Next you could easily say that e.g. software inventory is not enabled on server collection, but it is enabled for workstations and maybe for Remote Desktop servers.
With v.Next we could easily implement just one site and the benefits are very obvious: less servers to install and manage, less sites in install and configure, less server licenses are needed. Do less and save money: that’s cool!
About Panu Saukko: Panu has been a technical trainer and consultant for about the last two decades. He has been a Microsoft Certified Trainer (MCT) from 1995 and Microsoft Most Valuable Professional (SMS/ConfigMgr) from 2005. Panu’s main areas of expertise are Microsoft System Center products (ConfigMgr, OpsMgr, Service Manager and Data Protection Manager), workstation deployment and Active Directory. Panu lives in Espoo, Finland.
Thanks for the info, the collection specific agent setttings is definitely on top of my wish-list of new features.