With the release of System Center 2012 Configuration Manager, Microsoft introduced the distribution point groups functionality. Distribution point groups provide a logical grouping of distribution points and collections for content distribution as described in the following Technet Article: Configuring Content Management in Configuration Manager, Create and Configure Distribution Point Groups
A Distribution Point can be made member of one or more Distribution Point Group, based on the content deployed to that Distribution Point Group and whether the Distribution Point is member of that group, the Distribution Point receives content which is defined for the Distribution Point group.
When distributing content you have the ability to choose whether you want to distribute to a either a Collection/Collections, Distribution Point or Distribution Point Groups. This is actually the point where things start to go wrong, since depending on who is performing the distribution of the content, different options are chosen.Read More
Disclaimer: Please test and validate this in your test environment, don’t take the information i provide for granted. This article describes a method to determine correct settings and doesn’t supply the answer to your specific environment !
When you are installing System Center Configuration Manager (ConfigMgr) in environments where group policies are used to control the User Rights Assignment and Security Options security settings of the Servers, you have to be extra carefull.
You can expect some strange behavior after the installation because when the companies policy is applied again, it removes some entries made by either the prerequisite installation (roles and features) and installation of ConfigMgr itself, and this can result in some interesting scenario’s. Therefore my advise would be:
If you know the environment in which you are going to install ConfigMgr in, has a lot of restricing group policies make sure you do the installation of ConfigMgr while the servers are member of an OU with minimal policies applied.
Before you can start installing System Center 2012 R2 Configuration Manager in your environment you have to install the servers with an OS and configure its roles and features. While the Site System Installation Wizard now provides the option to configure some of the roles and features when not installed, I prefer to setup my environment upfront so that the Prerequisite Checker doesn’t give any Errors or Warnings to start with. My ex-collegue Tom Klaver already documenten the settings once for installing ConfigMgr 2012 RTM on Windows Server 2008 R2 – but since some things changed in the meantime i decided to update the spreadsheat to reflect installing System Center 2012 R2 Configuration manager on top of Windows Server 2012 R2. This information is coming from the following documentation on TechNet – Supported Configurations for Configuration Manager via: http://technet.microsoft.com/en-us/library/gg682077.aspx#BKMK_Win2k12SiteSystemPrereqsRead More
Note: I’ve already posted this article a while ago, but since my ex-employer decided to whipe the whole website without asking me if I would like a backup it got lost. Therefore i decided to place it here again. Note that this is still valid for ConfigMgr 2012 installations, i’ve modified the article to reflect that.
The System Center Configuration Manager (ConfigMgr) database can be installed on a clustered SQL Server, some things work different though compared to installing ConfigMgr on a normal SQL server installation, and you should be aware of them before starting your installation.
To summarize in front, what you should take into account before starting your installation:
- Make sure that the SQL administrators are aware that during installation extra righs are needed and that after installation the Site server must stay local administrator on the cluster nodes
- Make sure that the SQL administrators are aware of the fact that ConfigMgr will install a service on the Cluster Nodes, which is used for creating the backup using VSS
- Make sure that each shared cluster disk contains a no_sms_on_drive.sms file on the disk
- Configure the Site Backup tasks, so that it is either configured to backup to an UNC path or a drive which is suitable for storing the backup files on both the site server and the cluster nodes using the “Different Paths for the Site Backup and Database backup” option
Today, a customer contacted me with a very strange issue while installing a new Site System Server in his System Center 2012 R2 Configuration Manager environment. While adding a new Site System (in this case a distribution point) on the Distribution Point page of the Create Site System Server Wizard the customer got the following error on the Create a self-signed certificate or import a PKI client certificate part. Read More
Today, after installing a fresh System Center 2012 Configuration Manager Service Pack 1 environment, we experienced that the Boot images for both 32- and 64-bit were not created. The reason for this is already widely known, because it had to do with the virus scanner which was active at time of installation. There are already some articles describing what can go wrong during an upgrade to Service Pack 1 for example, as described in the following article: Updated System Center 2012 Configuration Manager Antivirus Exclusions with more details on OSD and Boot Images, etc… . So lesson one here: Please disable the virus scanner during installation and make sure the correct exclusions are in place after installing the ConfigMgr environment.
In the first part of this series I outlined what Microsoft changed in ConfigMgr 2012 in order to introduce Role Based Access Control. In the second part I outlined a possible scenario and started building the scenario. In the third part we mapped the business roles to the ConfigMgr roles and configured them in the ConfigMgr console. In this part we are going to see, what the outcome of this mapping has become.
SSC Operations Administrator
The SSC Operations Administrator can manage the whole environment, except for the security. As you can see, when a SSC Operations Administrator opens the ConfigMgr Console, he isn’t able to modify the security under Administrative Users.
In the first part of this series I outlined what Microsoft changed in ConfigMgr 2012 in order to introduce Role Based Access Control. In the second part I outlined a possible scenario and started building the scenario up to the point where the OpCo roles will be mapped to the ConfigMgr roles, this post will discuss the steps taken.
For the purpose of mapping the Customer roles to the ConfigMgr roles I created a spreadsheet to help out. Make sure that you understand what each OpCo needs to be able to do, and try to map this using the default roles. If not create a custom role and integrate this role into the matrix. My matrix turned out something like this:
In the previous post I introduced Role Based Access Control in ConfigMgr 2012 as the new way to delegate administrative access to a ConfigMgr hierarchy. In this post I’m going to walk you through a scenario and show you how we can delegate the access in order to meet the requirements.
The Customer is a very large company, which has a Shared Service Center responsible for the ConfigMgr environment. Each OpCo has its own IT department which manage their own servers and workstations. In the past each OpCo had their own Primary Site, and they should now be able to operate the environment in a similar way, while the Shared Service Center manages the environment. With operating you should think about:
- Create Packages and Applications
- Create Task Sequences
- Specify their own Client Settings
- Create Deployments
- Install Distribution Points
The company wants to facilitate sharing between OpCo’s though, therefore objects created by OpCo’s should be able to be shared
One of the reasons to install multiple primary sites in a System Center Configuration Manager 2007 hierarchy often was due to the fact that Administrative access had to be separated between different departments within a company. Within large companies mostly a Central Primary Site would be installed, not servicing any clients, and under that Central Primary Site, several Primary Child Sites would be installed for each OpCo needing their own administrative boundary within the hierarchy.
With ConfigMgr 2012, this has changed for the better. Because Microsoft wanted to simplify the hierarchy for ConfigMgr 2012, they introduced several techniques to partition a Primary Site for use by multiple administrative departments. I often notice though that I have a hard time to convince people of the fact that for security reasons it’s not necessary anymore to create multiple primary sites within a hierarchy. There are of course reasons to create multiple primary sites and a Central Administration Site (CAS) above them, but they are often “non-technical” or due to scaling.
In ConfigMgr 2007 we used Object Access, where we could give a user or group access to either the entire class of object, like all collections. Or you could give access to only an instance of an object, like the All Windows 7 Computers collection. This was a nightmare to manage though, and quickly became very complex in large implementations. More information can be found in the Classes and Instances for Object Security in Configuration Manager for ConfigMgr 2007 article on Microsoft Technet.