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
On Tuesday evening the 17th of September the Windows Management User Group Netherlands organizes its 3rd meeting. The announcement, which is in Dutch can be found here.
The subject of the evening is virtualization, and its hosted by PQR and we have three fantastic speakers for this evening, session summaries will be communicated soon:
- 17:30 – 18:30 Registration and food
- 18:30 – 19:30 Sessie 1, Ruben Spruijt
- 19:45 – 20:45 Sessie 2, Henk Arts
- 21:00 – 22:00 Sessie 3, James van den Berg
The sessions will be in Dutch, tickets can be reserved here at no additional costs.
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.
Text below is in Dutch, together with Bob Cornelissen, Marnix Wolf and Peter Daalmans we created a new User Group called the Windows Management User Group Netherlands or in short WMUG.NL.
With the user group we want to provide a platform for and by people involved with managing the Microsoft Windows platform. Our first session will be held on the 22nd of May this year.
If you have any questions about the new user group, mail us at email@example.com
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.
During Techdays, the annual event organized by Microsoft in the Netherlands, i had the honor of presenting a session together with Peter Daalmans, Microsoft MVP on ConfigMgr. Our session, named ConfigMgr 2012: Notes from the field discussed what’s new in both ConfigMgr 2012 and ConfigMgr 2012 SP1 and included our best practices and tips & tricks which we discovered during several roll outs of the product in customer environments.
Although the presentation was in dutch, we created our slides in English for your viewing pleasure, click the link to download:
Beware when installing ConfigMgr SP1 when still using vSphere 4 or running other platforms not supporting Windows 8 – UPDATED
Update: Microsoft has released CU2 for Configuration Manager 2012 Service Pack 1, allowing you to use Boot images based on Windows 7 from the WAIK again (with some contstraints but workable). See the KB 2854009 article for more information. See this article written by Brandon Linton from Microsoft for more information on how to import your WAIK boot image: How to Create and Import a WinPE 3.1 Boot image for use in ConfigMgr 2012 SP1 CU2
VMware’s vSphere 4 doesn’t and will not support running Windows 8 and Windows Server 2012 as a VM on top of its ESXi hypervisor. The reason for this is that the BIOS for the VM’s running on top of vSphere 4 do not meet the Windows 8 Hardware Requirements. You can check vSphere compatibility for Microsoft Windows 8 here. For ConfigMgr this shouldn’t be a direct problem, because we can still install the ConfigMgr roles on top of Windows Server 2008 R2.
When installing ConfigMgr 2012 SP1 or upgrading to SP1, one of the changes introduced is that the Windows Automated Installation Kit (WAIK) isn’t used anymore, and we start using the Assessment and Deployment Toolkit (ADK). And this is were we have a potential issue, because the ADK contains a new boot image based on Windows 8 which will be used to create the new Boot images.