deploying system center 2012 r2 configuration manager with multiple ... · deploying system center...

Deploying System Center 2012 R2 Configuration Manager with Multiple Site Servers for a Lab/Production Environment

By Kristopher J. Turner Business & Decision North America The following blog is information on how to install ConfigMgr 2012 R2 in a lab environment but can also be used for a production environment if needed for a smaller organization. However, I don't recommend you use this example for a production environment for one main reason. I will be going off the beaten path here and will not be building a standard single site server lab. I will be using this lab more for an environment that may or may not come up depending on a client's needs. Also, since this lab will have a lot of the site server roles off loaded onto their own servers and smaller organizations these days could get by in most cases with a single site server I wouldn’t recommend building your lab or production environment this way. With that said, I will mention throughout the blog on how these steps could be installed on a single site server or why they can be offloaded if necessary. So if you're starting out with ConfigMgr 2012 R2 in your organization this can still be a good resource for you. I am also writing this blog with assumptions that the people reading it will have basic skills with deploying Windows Server Operating systems, Active Directory Domain Services (AD DS), SQL server installations, and various other server or network admin level knowledge. I have split this blog into 3 major parts.

Part I - Infrastructure Part II - Now we can install Configuration Manager, Yes about time! (Sort of)

Part III - Configuration Configuration Configuration. Within each part there are sub categories that will focus sometime with detail and other times without. I apologize in advance if I may lose some of you. I have written this blog in a span of a few weeks whenever I have had free time so I may or may not have information mentioned twice or the flow of it may not be perfect. I am only going to cover the basic installation of the most common features in ConfigMgr 2012 R2. There are many other features I would love to get deeper into such as Configuration Settings (DCM) which can be used for compliance and security issues a very powerful piece that is often not used, Internet Based Client Management (IBCM) which requires a lot more design and deployment and to be honest isn't necessary if your organization will every jump on the Direct Access bandwagon (another great product if implemented correctly.) I won't be going into detail about the Microsoft Deployment Toolkit (MDT) however, I will show you how to install it and integrate it into the ConfigMgr console. I will also touch a little on a Microsoft tool that is free that can help you with your third party application patching and may mention a third party product that can do that and much more for a price of course. I won't go into Operating System Deployments (OSD) or Patch Management. However, I will show you how to get your environment configured and ready to deploy your images and how to maintain your endpoints by using the Software Update features. There is so much that we can

go into but since I did originally set out to write a blog on how to deploy Configuration Manager in a lab environment I really do need to stick to the basics. Also, on a side note. You will see me referring to System Center 2012 R2 Configuration Manager as ConfigMgr or Configuration Manager throughout my blog. I do this for one reason, Wally Mead. Yes Wally I do listen! For those that are not into ConfigMgr like myself, Wally Mead is like the ultimate resource for ConfigMgr/SMS. He doesn't like people referring to ConfigMgr as SCCM like so many people do. Why, Bing SCCM. It is the Society of Critical Care Medicine. :) So off to the wonderful world of System Center 2012 R2 Configuration Manager and how we will deploy this beast of a product. Which I hope will make some administrators feel better about the project they may have at hand!

Part I Preparing the Infrastructure for ConfigMgr 2012 R2

My Infrastructure I normally build out a ConfigMgr lab only using a DC and a single site server with all roles installed. This time I have decided to off load the roles to mimic special situations where one may need to have a standalone WSUS server and a dedicated SQL Server along with a dedicated Reporting Server and Application Catalog Server. I will also create a Management server that I will install my consoles on. This isn't necessary but this is something I. For just a basic lab or even a small business with a very small number of devices to manager you can keep everything on a single server. Some may argue that SQL needs to be off loaded to another box and some will argue that for performance reasons you should keep SQL on the same box. Both sides have very good arguments. If you want my overall opinion on the matter, keep SQL on your site server unless you will be managing a larger number of devices.

Lab-DC01 Domain Controller Windows Server 2012 R2

Lab-SQL SQL 2012 SP1 Standard* Windows Server 2012*

Lab-WSUS WSUS Windows Server 2012 R2

Lab-SCCM ConfigMgr 2012 R2 Windows Server 2012 R2

Lab-Web Application Catalogue/Reporting Services Windows Server 2012 R2

Lab-Mgmt Management and Jump Server Windows Server 2012 R2

* Using pre-built templates from Azure. They currently only have Windows Server 2012 with SQL Server 2012 R2 templates. SQL Server 2012 SP1 Standard is included in your ConfigMgr 2012 R2 download as well as your System Center suite. However, if you plan to build out a production environment that will have more than 50,000 devices being managed I suggest that you install Enterprise version.

http://www.systemcenteruniverse.com/presenters.htm#Wally

http://www.sccm.org/Pages/default.aspx

Downloads Needed Before we start I suggest that you download all the software that will be needed for your lab or production environment. For my lab purposes I have downloaded just the following since I am using Azure to build out this test lab. However, I will include a list of other items you may need in order to complete your ConfigMgr lab environment.

System Center 2012 R2 Configuration Manager

Windows ADK 8.1

MDT 2013

Windows Server 2012 R2 Datacenter

SQL Server 2012 SP1 Standard * * SQL Server 2012 SP1 Standard is included in your ConfigMgr 2012 R2 download as well as your System Center suite. However, if you plan to build out a production environment that will have more than 50,000 devices being managed I suggest that you install Enterprise version.

Once I have my management/tools server setup I normally place all installation files on the E:\Install Files folder. Since I am using an Azure VM we can't use the D drive.

1. Using Internet Explorer I will download the required software installation bits to my Management

Server or a network location I will then move these files to my Management Server. a. Create an E:\installfiles folder. Download each of the software installation packages below

into this folder. b. Download SQL Server 2012 SP1 from http://aka.ms/DLSQL2012 c. Download the Windows Assessment and Deployment Kit ( ADK ) for Windows 8.1 from

http://aka.ms/DLWADK d. Download the Windows Server 2012 R2 ISO from http://aka.ms/DLWS2012ISO e. Download the Windows 8.1 Enterprise ISO from http://aka.ms/DLWIN8ISO f. Download System Center 2012 R2 from http://aka.ms/DLSCSUITE2012

Building My Infrastructure I am not really going to go into how to setup the VM's and Active Directory in Azure. I have written a blog about this in the past. Just be aware of Azure's billing rates and your current plan with Azure. You can always create this within your own private cloud as well. I also have another blog on how to setup your own private cloud using SMB 3.0 storage features within Windows Server 2012 R2.

Hardware Considerations: If you are using Hyper-V or VMware please consider the following NIC changes to your guest.

VMWare Change the E1000 NIC to VMXNET3 NIC to avoid a lot of future issues.

Hyper-V Change the default network to use a Legacy Network Adapter. This will support WOL and PXE integration.

http://aka.ms/DLSQL2012

http://www.microsoft.com/en-eg/download/details.aspx?id=39982

http://www.microsoft.com/en-eg/download/details.aspx?id=39982

http://aka.ms/DLWS2012ISO

http://aka.ms/DLWIN8ISO

http://aka.ms/DLSCSUITE2012

Configure Active Directory Security Groups and Service Accounts: I have created a domain called lab.cloud for this lab environment. I have also renamed the Administrator account to labadmin. I have created the following service accounts and security groups for this lab. There will be more accounts that are needed in a production environment.

Name Description Type

Svc.sql SQL Service Account User

ConfigMgr Admin ConfigMgr Administrator Account User

ConfigMgr Servers ConfigMgr Servers Group Group

ConfigMgr Administrators ConfigMgr Administrators Group Group

Svc.networkaccess ConfigMgr Network Access Account User

Svc.ClientPush ConfigMgr Client Push Installation Account User

Svc.sqlreports SQL Reporting Services Account User

I have added ConfigMgr Admin to the ConfigMgr Administrators group. I have also added my ConfigMgr site servers to the ConfigMgr Servers group (Lab-SCCM, Lab-WSUS, Lab-Web, and Lab-SQL) I also have created a Group Policy that gives the service account svc.clientpush local administrator rights an all systems in my domain. You can get the same results by just adding this account to Domain Admins but it isn't recommended. Since this isn't a lab on Active Directory I will not go much further with AD installation or configuration. Later during the prerequisite for ConfigMgr I will extend the schema and create our System Management Container along with the permissions needed on that container.

Configure My SQL Server I have joined my server Lab-SQL to the domain lab.cloud and have disabled the Domain Firewall profile. Please note that there are more secure ways of allowing SQL communication through the firewall but for this lab we will be disabling all Domain profiles on all servers.

SQL Server installation considerations 1. If you are installing SQL Server yourself make sure the Collation is set at

SQL_Latin1_General_CP1_CI_AS. This should be default but double check. 2. Install the Database feature, Management Tools and Reporting Services. In this ab I will be

installing the Reporting Services on lab-web. I am only doing this to mimic possible client environments that require a separate SSRS installation.

3. If using the Windows Firewall and haven't disabled the Domain Profile like I have done you will need to make sure SQL ports for incoming traffic and reporting are open.

a. SQL 1433/4022 b. Reporting 80/443

On the SQL server I will make my svc.sql account and my ConfigMgr Servers Group members of the local Administrators group. I will as well add them as a sysadmin SQL server role within SQL. I also added ConfigMgr Admin user to the local administrators group as well as adding it to the sysadmin role within

my SQL Server. This is very important for the installation part of ConfigMgr if we will be using ConfigMgr Admin to install ConfigMgr. I have changed the default SQL Data and Log file locations to the E: Drive. Since Azure VM's have a temp D drive we can't use the D drive. If you are using Azure, please make sure you never use the D dive since it is a temporary drive. My SQL VM is configured as an A5 Azure Server. Which means it has 2 Cores and 14 GB or ram. I have configured the memory usage of my SQL Server. I have set the minimum at 8,192 MB and for the maximum I have set it at 10,240 MB.

Configure My WSUS Server I have joined my server Lab-WSUS to the domain lab.cloud. On my WSUS server I make sure the ConfigMgr Servers group is a local Administrator. When installing the WSUS role for ConfigMgr you can install by GUI or using PowerShell. I have included instructions for both. The more I use PowerShell the more I find it hard going back to the GUI when working with Windows Server 2012 R2.

Using the Server Manager (GUI)

1. Using the Server Manager tool to install WSUS server role once the SQL Server has been installed and Firewall Domain Profile disabled.

a. In the Server Manager tool, click Manage on the top left menu bar and then select Add Roles and Features from the drop-down menu to launch the Add Roles and Features Wizard.

b. Click Next and Next c. Verify that lab-wsus is selected. d. On Select Server Roles select Windows Server Update Services. e. Click Add Features. f. Click Next g. Click Next On Windows Server Update Services Role Setup Screen h. Unselect WID database.

We will be using our SQL Server to host the WSUS database not a Windows Internal Database.

i. Select Database j. Click Next k. Uncheck Store Updates l. Click Next m. Enter SQL Server: lab-sql n. Click Check Connection o. Click Next after Successful Connected To Server Message. p. Click Install q. Click on Configure WSUS role but don't configure it. Allow the role to finish configuration

and then exit WSUS configuration screen.

Installing using PowerShell

1. Using PowerShell to install WSUS server role. a. Open PowerShell prompt with admin rights.

b. Run the following command: i. Install-WindowsFeature -Name UpdateServices-DB -IncludeManagementTools

c. Once role is installed you will need to do the additional configurations needed. Within the PowerShell command window navigate to C:\Program Files\Update Services\Tools

d. Run the following command i. .\wsusutil.exe postinstall SQL_INSTANCE_NAME="Lab-SQL\YourInstanceName"

e. If you want to specify a default Content Directory for the Updates you can add to the end of the command CONTENT_DIR=D:\WSUS or a specified path. However, since ConfigMgr will be managing the download of these Security updates you do not need to have WSUS download them for the clients.

Verify that WSUS role was configured and installed correctly no matter which method you went with.

a. Check the SQL server for the SUSDB database. b. If you specified a Content Directory check that the path exists.

Configure My Application Catalog/Reporting Service Server I have joined my server Lab-Web to the domain lab.cloud. On my web server I make sure the ConfigMgr Servers group is a local Administrator. Once again, this server isn't necessary to have built and the site server role could have easily been installed on the primary site server along with all the other site server roles. I wanted to do something different in this lab and play around with offloading some of these roles. At this point we will install the SQL Server Reporting Services on this server. Since I am using Azure and my SQL server was a template I would either needed to have downloaded the SQL installation media or I can use the installation BITS that are on the SQL server. I recommend that you download and install the Standard edition that comes with your Volume license copy or the version that comes included with your System Center media. I will be using the media located on my SQL Server and installing it as an evaluation copy. I am not going to go into detail on how to install the SQL Reporting Service. There are plenty of resources that you can use. However, I will provide details later in my blog on how to configure the Site Server role.

Configure My Mgmt Server (Tools Server) I have joined my server Lab-mgmt to the domain lab.cloud. On my management server I make sure the ConfigMgr Servers group is a local Administrator. I will also make sure the ConfigMgr Administrators are local Admins just for this lab only. In a working production environment security might have a cow about this. You can get around that by adding them to the Remote Desktop group to allow them RDP access to the management server. Then they can use the console from this server. I will then download the software needed to my E:\Instal Files directory that I have created. Later, after I install ConfigMgr I will come back to this server and install the SQL Management Tools, my Active Directory Domain Services tools for managing AD, and the ConfigMgr Console along with other tools like

the ConfigMgr Toolkit, etc. This will be my primary management system to keep people off of my ConfigMgr Primary Site server.

Configure My ConfigMgr Server I have joined my server lab-sccm to the domain lab.cloud. On my lab-sccm server I have made sure the ConfigMgr Servers group is a local Administrator group. I will also add ConfigMgr Admin user to the local administrator group as well. For my lab I have created a Data drive which will be my F: drive. This will be my location where I install the ADK and Configuration Manager programs. I also have added another drive that will be my ConfigMgr Source and Content Library location. In my lab environment my data drive has been configured with 50 GB and my Content Library drive will have been configured for 100 GB.

Part II Now we can install Configuration Manager, Yes about time! (Sort of)

Configuring and Installing the Prerequisites Yes, now we are ready to start our Configuration Manager installation. Well, sort of. We have some prerequisites that are necessary in order for us to complete the installation. Here is a high level of the items we will need to install and configure before we can hit the magic start button on the ConfigMgr installer. Extend Active Directory Create System Management Container and Assign Permissions Install needed Server Roles and Features on Site Server no_sms_on_drive.sms Install WSUS Management features Install Windows ADK 8.1

Extending Active Directory If you have previously installed ConfigMgr 2007 or even 2012 RTM and have already extended your AD Schema you will not need to do this if deploying a production environment. There are no changes needed by ConfigMgr 2012 R2. I highly recommend that you do extend you schema. There should be no reason not to. However, since this is a newly deployed lab I will be extending my AD schema and so should you. Make sure the account you are running this command under has the proper permissions to extend your schema. I will be running the following command from my Management server with a domain admin account that has the proper permissions.

1. You will need to have the ConfigMgr installation media handy. Since we are using Windows Server 2012 R2 and I have the ISO located in E:\Install Files\ISO\ I will mount the ISO as the F: drive.

2. Open a PowerShell or CMD prompt with admin privileges. Change your directory to F:\SMSSetup\BIN\x64\

3. Execute .\Extadsch.exes

4. Verify on c:\ that extadsch.log has been successful. This log will also tell you what has been changed. A good thing to pass off to those AD and Network Admins that may freak out over extending ad in your production network later. (wink wink)

I have seen this fail the first time. If you run it again and verify with the logs it normally will work. (This isn't the technical fix for this)

<03-20-2014 21:15:37> Modifying Active Directory Schema - with SMS extensions. <03-20-2014 21:15:37> DS Root:CN=Schema,CN=Configuration,DC=labgw,DC=cloud <03-20-2014 21:15:37> Defined attribute cn=MS-SMS-Site-Code. <03-20-2014 21:15:37> Defined attribute cn=mS-SMS-Assignment-Site-Code. <03-20-2014 21:15:37> Defined attribute cn=MS-SMS-Site-Boundaries. <03-20-2014 21:15:37> Defined attribute cn=MS-SMS-Roaming-Boundaries. <03-20-2014 21:15:37> Defined attribute cn=MS-SMS-Default-MP. <03-20-2014 21:15:37> Defined attribute cn=mS-SMS-Device-Management-Point. <03-20-2014 21:15:37> Defined attribute cn=MS-SMS-MP-Name. <03-20-2014 21:15:38> Defined attribute cn=MS-SMS-MP-Address. <03-20-2014 21:15:38> Defined attribute cn=mS-SMS-Health-State. <03-20-2014 21:15:38> Defined attribute cn=mS-SMS-Source-Forest. <03-20-2014 21:15:38> Defined attribute cn=MS-SMS-Ranged-IP-Low. <03-20-2014 21:15:38> Defined attribute cn=MS-SMS-Ranged-IP-High. <03-20-2014 21:15:38> Defined attribute cn=mS-SMS-Version. <03-20-2014 21:15:38> Defined attribute cn=mS-SMS-Capabilities. <03-20-2014 21:15:38> Defined class cn=MS-SMS-Management-Point. <03-20-2014 21:15:38> Defined class cn=MS-SMS-Server-Locator-Point. <03-20-2014 21:15:39> Defined class cn=MS-SMS-Site. <03-20-2014 21:15:39> Defined class cn=MS-SMS-Roaming-Boundary-Range. <03-20-2014 21:15:39> Successfully extended the Active Directory schema. <03-20-2014 21:15:39> Please refer to the ConfigMgr documentation for instructions on the manual <03-20-2014 21:15:39> configuration of access rights in active directory which may still <03-20-2014 21:15:39> need to be performed. (Although the AD schema has now be extended, <03-20-2014 21:15:39> AD must be configured to allow each ConfigMgr Site security rights to <03-20-2014 21:15:39> publish in each of their domains.)

Create the System Management Container and Assign Permissions Reference: http://technet.microsoft.com/library/gg712264.aspx#BKMK_CreateSMContainer Configuration Manager does not automatically create the System Management container in Active Directory Domain Services when the schema is extended. The container must be created one time for each domain that includes a Configuration Manager primary site server or secondary site server that publishes site information to Active Directory Domain Services

http://technet.microsoft.com/library/gg712264.aspx#BKMK_CreateSMContainer

You can grant the site servers computer account Full Control permission to the System container in Active Directory Domain Services, which results in the site server automatically creating the System Management container when site information is first published to Active Directory Domain Services. However, it is more secure to manually create the System Management container.

1. To manually create the System Management container a. Log on as an account that has the Create All Child Objects permission on the System

container in Active Directory Domain Services. b. Run ADSI Edit, and connect to the domain in which the site server resides. c. Expand Domain <computer fully qualified domain name>, expand <distinguished name>,

right-click CN=System, click New, and then click Object. d. In the Create Object dialog box, select Container, and then click “Next”. e. In the Value box, type System Management, and then click “Next”. f. Click Finish to complete the procedure.

2. Set Security Permissions on the System Management Container

After you have created the System Management container in Active Directory Domain Services, you must grant the site server's computer account the permissions that are required to publish site information to the container. Important: The primary site server computer account must be granted Full Control permissions to the System Management container and all its child objects. If you have secondary sites, the secondary site server computer account must also be granted Full Control permissions to the System Management container and all its child objects.

1. To apply permissions to the System Management container by using the Active Directory Users and Computers administrative tool

a. Click Start, click Run, and then enter dsa.msc to open the Active Directory Users and Computers administrative tool.

b. Click View, and then click Advanced Features. c. Expand the System container, right-click System Management, and then click Properties. d. In the System Management Properties dialog box, click the Security tab, and then click Add

to add the site server computer account. Grant the account Full Control permissions. e. Click Advanced, select the site server’s computer account, and then click Edit. f. In the Apply to list, select this object and all descendant objects. g. Click OK and then close the Active Directory Users and Computers administrative tool to

complete the procedure.

2. To apply permissions to the System Management container by using the ADSI Edit console a. Click Start, click Run, and enter adsiedit.msc to open the ADSIEdit console. b. If necessary, connect to the site server's domain. c. In the console pane, expand the site server's domain, expand DC=<server distinguished

name>, and then expand CN=System. Right-click CN=System Management, and then click Properties.

d. In the CN=System Management Properties dialog box, click the Security tab, and then click Add to add the site server computer account. Grant the account Full Control permissions.

e. Click Advanced, select the site server’s computer account, and then click Edit. f. In the Apply onto list, select this object and all descendant objects. g. Click OK to close the ADSIEdit console and complete the procedure.

NOTE: You can create a Security Group and include all your Site Servers within that security group and assign the group to the above mentioned security settings.

Install needed roles on Site Server I will now install the Server roles and features needed on my Site Server. I will also be installing the roles and features on my web box that will be hosting my Application Catalogue and Reporting Services point as well. These roles and features can be easily installed using a PowerShell script that I will provide below. There are a few things to mention before you install your .NET Framework if you decide to install these outside of the required roles and features. If you install .NET framework before you install IIS you will then need to register ASP.net with IIS after in order for you to continue on with the ConfigMgr install. If you are using Windows Server 2012 R2 like I will be using there is a bug in the .NET 3.5 Framework install that you may need to use a work around. From this point on I will always log on to my primary site server as my ConfigMgr Admin account that has the proper rights and permissions. I also add this account to the Domain Admins group but this isn't necessary as long as this account is a local admin. On my Primary site server I will install the following roles and features using PowerShell. I will list the roles and features you will need to install later if you want to manually install them through Server Manager.

Installing Roles and Features

1. Open a PowerShell prompt as Administrator

Get-Module servermanager Install-WindowsFeature Web-Windows-Auth Install-WindowsFeature Web-ISAPI-Ext Install-WindowsFeature Web-Metabase Install-WindowsFeature Web-WMI Install-WindowsFeature BITS Install-WindowsFeature RDC Install-WindowsFeature NET-Framework-Features Install-WindowsFeature Web-Asp-Net Install-WindowsFeature Web-Asp-Net45 Install-WindowsFeature NET-HTTP-Activation Install-WindowsFeature NET-Non-HTTP-Activ Install-WindowsFeature Web-Static-Content

As I mentioned before there is was a bug in the .NET framework 3.5. You may need to manually install .NET 3.5 Framework. If this is the case you will need your Windows Installation media to complete the installation of .NET 3.5 Framework. The following are some resources that you can use in order to get .NET 3.5 Framework installed properly on Windows 8.1 and Windows Server 2012 R2.

Installing .NET 3.5 if needed

1. Open a PowerShell (Command Line) prompt with administrator rights. 2. Run the following command:

a. dism /online /enable-feature /featurename:NetFX3 /All Here are some resources that you can look at if you run into any issues. A Blog by Daniel Classon. Why I included this. No specific reason. It was one of the first on my Bing Search and it was a very clan and to the point blog. So I am giving him the credit he deserves for a good informative blog. (Hint hint)

http://www.danielclasson.com/install-net-framework-35-server-2012/ Enable to install: http://technet.microsoft.com/en-us/library/dn482071.aspx List of how to enable .NET 3.5. http://technet.microsoft.com/en-us/library/dn482066.aspx PowerShell Command to enable .NET 3.5 http://technet.microsoft.com/en-us/library/dn482068.aspx

Now I will also install the needed roles and features on Lab-Web that will support my Reporting Services Point and my Application Catalog Roles. Once again, I will include how to install this manually for those that haven't started using PowerShell to do so. Trust me, don't be scared of PowerShell. This is an awesome tool that I am still learning myself. In fact, I created my home "Private Cloud" mostly using PowerShell commands. It took me about 2 weeks longer than it should and many Bing searches but I was able to get most my servers built, and most of the System Center products installed all using PowerShell.

Get-Module servermanager Install-WindowsFeature Web-Windows-Auth Install-WindowsFeature Web-ISAPI-Ext Install-WindowsFeature Web-Metabase Install-WindowsFeature NET-Framework-Features Install-WindowsFeature Web-Asp-Net Install-WindowsFeature Web-Asp-Net45 Install-WindowsFeature NET-HTTP-Activation Install-WindowsFeature NET-Non-HTTP-Activ Install-WindowsFeature Web-Static-Content

Roles and Features for ConfigMgr

List of roles and features needed to be installed for those that still want to do it the GUI way. Nothing wrong with it, but like I mentioned earlier. PowerShell can be your friend! I recommend buying a book from Don Jones called “Learn PowerShell 3 in a Month of Lunches” I was lucky enough to take a course

http://www.danielclasson.com/install-net-framework-35-server-2012/

http://technet.microsoft.com/en-us/library/dn482071.aspx



here in Phoenix at InterfaceTT taught by the ledged himself. It was a very advanced course but I did get a lot out of it. If you have time I suggest looking up videos and articles on a site he helps admin called www.powershell.org. A very useful site for the beginner all the way to someone who can write scripts in their sleep. I am only going to list the roles and features that we need right now. The link I have provided will give you additional information on additional roles and features that are needed for other ConfigMgr Site System Roles. Here is a link to the TechNet article where I get most my information from for the following information. http://technet.microsoft.com/en-us/library/gg682077.aspx#BKMK_Win2k12SiteSystemPrereqs

Site system role Windows Server Roles and Features

Site server with all site system roles installed

Features and Roles: .NET Framework 3.5

o HTTP Activation .NET Framework 4.5

o ASP.NET Remote Differential Compression IIS Configurations:

o Common HTTP Features Default Document Static Content

o IIS 6 Management Compatibility IIS 6 Metabase Compatibility IIS 6 WMI Compatibility

o Application Development ASP.NET 3.5 .NET Extensibility 3.5 ASP.NET 4.5 .NET Extensibility 4.5 ISAPI Extensions

o Security Windows Authentication

BITS Server Extensions (BITS)

Please remember these are just the default server roles and features that we need to install in order to get a basic installation of ConfigMgr installed and running with the following site server roles: Site Server, Database Server, SMS Provider, Application Catalog Web Service Point, Application Catalog Website Point, Asset Intelligence Synchronization Point, Distribution Point, End Point Protection Point, Management Point, Reporting Services Point, Software Update Point, and the State Migration Point. There are other Site Server roles that may require other Windows Server Roles and Features to be installed or added to. Please check the link mentioned earlier for that information.

On a side note. I want to rant about Endpoint protection that is a free solution included in ConfigMgr. This is a great product that I highly recommend clients to move over to once their

http://www.interfacett.com/

http://www.powershell.org/

http://technet.microsoft.com/en-us/library/gg682077.aspx#BKMK_Win2k12SiteSystemPrereqs

existing contracts have expired. No, it doesn't have a lot of the bells and whistles some of the other products may have. However, it does its job and does it well. I recommend you look into this product and compare your current cost. I think I might do a blog here soon just on Endpoint protection and the reasons why you should change.

no_sms_on_drive.sms What is this? This my friend is a very important step when deploying ConfigMgr from the good old SMS days that is still a very valuable step even in the 2012 R2 days. When you deploy a Distribution point and when you install you’re first Site Server the installation will default to the largest drive you have available. In other words it may deploy to other drives you may or may not want packages and various other ConfigMgr items stored. With ConfigMgr RTM SP1 they gave you a choice of where you wanted the Configuration Manager Content Library to be installed. However the Distribution Points at the time still would take any drive they could find and still do. In order to control this you need to create a simple file called no_sms_on_drive.sms and place it on any drive on your site servers and distribution points that you don't want data stored. For my lab and pretty much every client I have deployed ConfigMgr to my advice is put this file on all site server C drives to start with. I will also be using this on my SQL server since we will be installing the Database Site Server role on that. Since my lab's SQL server only has the C and E drives I will only place the file on my C Drive. I will also place it on the temporary drive D that Azure creates just to make sure ConfigMgr doesn't try to install and place any binaries to that drive as well. On my primary site server I will place this file on all drives except for my drive I created for my ConfigMgr installation and Source files. This is where the Content Library will be installed.

Note: This file must be on the drives before any site server role is installed.

Install WSUS Management features Even though we already installed and configured WSUS on a standalone server ConfigMgr still requires that the bits are installed on the site server as well. For this we will just install the management features using PowerShell. If you want to install using the GUI please go into the Server Manager and install the feature not the role to manage WSUS.

1. Open a PowerShell prompt with Admin privileges. 2. Type the following command:

a. Install-WindowsFeature -Name UpdateServices-Ui

Install Windows ADK 8.1 Windows ADK 8.1 which stands for Windows Assessment and Deployment Kit has many tools that an administrator can use to help deploy images, run application compatibility test on old applications, etc. The only three tools we will be installing are the Deployment Tools, User State Migration Tool (USMT) and the Windows Preinstallation Environment (Windows PE). On the primary site server I will run adksestup.exe that I have already downloaded and placed in my E:\Install Files directory.

1. Install Windows Assessment and Deployment Kit (Windows ADK) 8.1 on Primary Site Server. a. When prompted during the setup process, select the following components to install:

i. Install to E:\Program Files (x86)\Windows Kits\8.1\ or install to the directory of your choice.

ii. Click no on CEIP question. (Unless you want to select Yes) iii. Select the following features to install:

1. - User State Migration Tools ( USMT ) 2. - Deployment Tools 3. -Windows Preinstall Environment (Windows PE)

b. Click Install At this point I am glad to say it but, Congratulations you are now ready to install Configuration Manager 2012 R2! Yes, at this point your infrastructure is in place and all the prerequisites have been installed. We are ready to finally install the product that will one day save you valuable time and help you work smarter. However, don't get to ahead of yourself. As you can see there was a third part to my blog called Configuration Configuration Configuration!

Installing ConfigMgr 2012 R2 So, this is what we have all be waiting for. From my installation media which I will have mounted from the ISO located in the Install Files directory I will run the splash.htm file to start the ConfigMgr installer. At this time I will run the Prerequisite Checker to verify all my settings have been set correctly. I will navigate to my ConfigMgr Installation files. This will run some checks that may fail due to the fact that not all site server roles will be configured on this server. Also beware that the same installation prerequisite check will run during the installation as well.

1. Open a PowerShell prompt with Admin rights. 2. Navigate to ConfigMgrSourceFiles\SMSSETUP\BIN\X64\ 3. Run .\prereqchk.exe /local 4. If any errors came up that can be fixed please do so before continuing. However, be aware that

some of these errors are due to the fact that you are not running all site server roles on this server.

Now, I can finally click Install. I am ready to deploy ConfigMgr and with all the work I have already completed the process should be a piece of cake and trouble free.

1. Click Install on the Configuration Manager Installation Splash Screen 2. The first window "Before You Begin" is just information. I will click “Next” to continue.

The next window "Getting Started" gives us the available setup options. For larger organizations that have a more complex hierarchy this is where we would install a CAS or better known as a Central Administration Site. For our lab or for most standard ConfigMgr deployments a CAS is not necessary. With ConfigMgr SP1 Microsoft included the ability to add a CAS later which was a very useful change. With our lab, I will only be installing a Primary site with no CAS and no secondary sites as well.

3. Leave the default bullet selected which should be Install a Configuration Manager primary site and do not check Use typical installation options for a stand-alone primary site. You can click “Next.”

4. This next window "Product Key" is important if we will be using this deployment in production at some point. Since this is my lab I am setting up I will select the bullet next to "Install the evaluation edition of this product." If at any time we wanted to make this a production environment you can change the product key using a PowerShell script.

5. Click Next. 6. I will accept the license terms on the "Microsoft Software License Terms" window and then click

“Next”. 7. I will also accept the license terms for SQL Server 2012 Express, SQL Server 2012 Native Client, and

Microsoft Silverlight 5 on the "Prerequisite Licenses" window. Click Next. 8. On the "Prerequisite Downloads" window I have given the path to my Install Files directory. I have

created a directory called ConfigMgr Download Updates. This can be named anything you want. Just make sure it is named in a way anyone installing ConfigMgr can tell what is in the folder. Click Next.

This process will take some time and can actually be done before we start the install. As of the time of my blog there are about 56 files that this process will download. These are various files that ConfigMgr will use for the install process that have been updated since the media was released. It will also download files that it will need for installing secondary sites and other site server roles.

9. The next window "Server Language Selection" I will leave the default English selected and hit “Next”.

10. I will leave the default English selection on the "Client Language Selection" window and hit “Next”. The next window "Site and Installation Settings" is very very very very important part of our ConfigMgr planning that most likely should have already been discussed among your internal IT department. These settings cannot be changed without removing ConfigMgr site completely. The first box you will see is called the Site Code. Since this is just a lab I will use LAB for my site code. If you are also just using this as a lab then having to worry about a good site code isn't a big deal. However, if this will one day be a production system you need to put some thought behind your site code naming, especially if you will have a larger hierarchy with multiple primary sites, secondary sites, and a CAS. There are many site code naming conventions that can be used. Some people may use the three digit airport code in that area like PHX or something a little more to better identify it as a Primary Site such as P01 for Primary Site 01. If you do happen to have a large organization that is spread out across the globe I would consider sitting down and planning out your site code strategy. I myself would recommend airport codes if possible. The Site Name is important as it will help describe what that site is. For my lab purposes I will only put Primary Site for LAB. If you had used an airport code for your site code for example you could have the following site name such as Phoenix Corporate Offices - PHX. I also will change the Installation folder to F:\Program Files\Microsoft Configuration Manager\ Also, some people will not install the Configuration Manager console on their primary site servers. Since this is only a LAB environment I see no issue with installed the console on this server as well as my Management Server that I have created.

11. Type in our Site Code and our Site Name and Change the Installation Folder 12. Install the Configuration Manager console. 13. On the "Primary Site Installation" Window select the bullet for Install the primary site as a

standalone site. We will click “Next”.

14. Click “Yes” to the warning message that you have decided to install a stand-alone primary site. 15. On the "Database Information" window we will type in our SQL server. If you have installed SQL

on your ConfigMgr server type in the ConfigMgr Server name. I have setup a separate box for my SQL server. Like I mentioned before, some people like it offloaded and some people will say it is better to have SQL installed on your ConfigMgr Site Server.

16. We will leave everything else default and click Next. You may get one of a few errors at this point. Since we are logged on as the ConfigMgr Admin account or you should be at this point like I mentioned to do earlier then the follow errors may exist if we haven't done two things. 1. Did we add the ConfigMgr Admin account to the local Administrator group on our SQL Server? Permissions are always fun, are they not? Since my lab will have the SQL server on its own server the next window will ask for the SQL Server Data and Log file locations. Since I wasn't worried about performance for this lab on the SQL end I only created one Data drive for all my data and log files. In a production environment you would separate these files between different drives for better performance.

17. Change the location of both the SQL log and SQL data files to the drive you designated on your SQL Server installation location. Like I mentioned I early I have created F:\MSSQL\Data for a location for both my SQL log and data files. Click Next.

The "SMS Provider Settings" window is where we will designate our SMS Provider location. There are some augments on where the SMS provider should be installed if you don't have SQL installed on the same site server. If you are using a single site server with SQL installed on the same server then by default you will install the SMS Provider on that server. With my lab environment I have SQL on a separate server. Some people will tell you to install the SMS Provider on the SQL server. The SMS Provider is the interface between the ConfigMgr console and the Site database. I suggest just leave the SMS provider installed on your Site Server.

18. Fill in your site servers FQDN and click “Next”. Now the next window "Client Computer Communication Settings" will also be a good discussion and planning section for both system admins, desktop engineers, security team, and members from the dreaded network team. (Remember, a happy network team is a happy life for you!) By default the bullet "All site systems roles accept only HTTPS communication from clients" is selected. In my previous deployments for clients this has varied on how we have setup the communication settings between clients. If it was up to me each time I would force the client to make sure they have a healthy and working PKI Infrastructure in place and only have the clients communicate using HTTPS. The good thing is that if you have to choose HTTP over HTTPS this can be easily changed on your Management Points later. So, for most cases selecting the bullet "Configure the communication method on each site system roles" would be the best option along with a check mark in the "Clients will use HTTPS when they have a valid PKI certificate." For my lab, I don't have a PKI infrastructure setup. Just a quick note, there are many good reasons why you should have a PKI infrastructure or planning to implement a PKI infrastructure in your environment soon. I can name a few but Direct Access is one of these that can make managing devices that don't always connect to you physical network a lot easier. However, that is another blog down the road maybe?

19. For this lab we will select the bullet "Configure the communication method on each site system role" and we will also check the box "Clients will use HTTPS when…." Just in case by the time I get finished writing this blog I have the time to implement PKI. Click Next.

20. Leave the defaults for the "Site System Roles" window. Make sure there are check marks in both "install a management point" and "Install a distribution point” Also change the client connection to HTTP on both. Since again we will not be using PKI in this lab. In my personal home lab/production environment I do have a PKI infrastructure so if you have questions about configuring ConfigMgr to communicate on HTTPS reach out to me. Click Next.

21. Ah, the "Customer Experience Improvement Program" window. Since this is a lab that I am building and I am using trail version of the software or even if I was using MSDN versions of the software I will click the bullet "Join the Customer Experience Improvement Program" just because it is always nice to send Microsoft some data to help better this product for us in the future. Click “Next” when you have made your selection.

22. Now we have made it to the "Settings Summary" window. Here we will go over all the settings we have selected to verify everything looks good. Once we have done this click “Next”.

The "Prerequisite Check" window will be next. If we have preinstalled everything correctly we shouldn't see anything pop up in this window. I will be honest here and say in my experience that no matter how much we prepared we will see something come up as an issue or just a warning. For instance sometimes it will say that permissions need to be applied on the System Management container even though we have correctly added our ConfigMgr Server group. To fix this manually add the site server the same way. For our lab environment that is ok. However, if you're in a larger production environment with multiple Management Points, and multiple site servers you will have to keep added them to the permissions on the System Management container each time you add one. Also I have seen that permissions to install a site server can be fixed by adding once again the site server computer account directly to the site server’s local administrator password even though it is in the security group ConfigMgr Servers that are already set as local Administrators.

23. So, from this window, once all the red errors have been fixed and any information or warnings have been looked at, then we will click Begin Install…….

Wait!!!!!!! Before you click "Begin Install” button there is one very important tool that you need to have ready and available for you. ConfigMgr is one of the better programs for creating logs for trouble shooting. Yes, logs and a lot of them. However, I always tell my clients have you check the logs yet, or send me this or that log. That should pretty much be the first place you look when you have issues or just curious as to how the internals work within ConfigMgr. So, why do I bring this up? I bring it up because there is a little known tool outside the realm of ConfigMgr geeks like myself that is a life saver when it comes to reading log files. This is by far the best log file reading app that you can buy or get free. It has been around for years and years under different names in the past. The tool is called CMTrace. I use this tool for everything not just System Center logs. I always say, once you gone CMTrace you never go back. Where can I find this awesome tool you are talking about you ask? There are a few ways to get this tool. The first is from the Tools folder located on the installation media. ConfigMgrSource\SMSSETUP\Tools\ the other way is to download the ConfigMgr 2012 R2 Toolkit which I will have you do later. On both your ConfigMgr Site server and your Management server if you created one I suggest you place this tool on your C: drive or some other location. Open it once and select it to be your default viewer for log files. You will thank me later for this. Trust me!

24. Now I have clicked Begin Install. You will see an overall process and a few task like Evaluating setup environment, etc. After a few minutes you will see a long list of task that the installer will perform. Depending on the size of your server and if your SQL server is locally installed or on another system like my lab the time to install can be a while. I suggest that you click the view log button on this "Install" window. This will open up the running installation log in CMTrace the tool I just told you about. This way you can get a live look at what is going on in the background during installation. Whatever you do don't worry about the red and yellow lines that will pop up during installation in the log file if you are monitoring the log. These are normal errors most of the time. The only time you should worry is if the installer fails. Then you would go back and dig through this log and see why it failed.

25. You can click Close once the Core setup has been completed. Congratulations, you have installed Configuration Manager 2012 R2!!!! You can now continue on to Part III - Configuration Configuration Configuration. At this point you have successfully installed ConfigMgr 2012 R2 and are ready for hours of configuration and planning to get the most out of your Configuration Manager environment.

Part III Configuration Configuration Configuration and more Configuration.

Congratulation on installing Configuration Manager 2012 R2. We were able to successfully install and configure all the prerequisite, get your infrastructure up and running, and install ConfigMgr 2012 R2. Now the part that will take some time configuring your installed Configuration Manager. Depending on your environment it could take some time. Even though a good infrastructure is important, and installing ConfigMgr is important, planning and configuring your environment is essential to having a successful ConfigMgr experience. Depending on the site server roles you have decided to deploy and what features you will want to use, will play a big part in how you go about your planning phase. This will dictate how long until you are ready to go into "production" and start managing devices. I use the term “production” for both a lab and a production environment because you don't want to start managing clients/devices until you have planned out a strategy for each of the site server roles you are going to be using. In Part III of my blog I will go into configuration of the most commonly used site roles, how to get the best performance out of your system, and many other areas. This section will go over a little of the following.

Configure Discovery Options Boundary and Boundary Groups Setup Collections for Computers and Users Setup folder structure within the Source folder Install Site Roles and Configure Site Roles

Software Update Point Reporting Service Point State Migration Point Application Catalog roles Asset Intelligence

Endpoint Protection Configure Distribution Points Configure Site Components

Configure Management Point Component Software Distribution Point Component Software Update Component

Configure Hierarchy settings Client Settings Configuration Configuring Endpoint Protection Installing our clients Giving Console Admin Rights Ready for Production Install MDT 2013 (If necessary)

Some of the important and overlooked areas during planning and designing of organizations ConfigMgr environment are Collections and your folder structure for Source files, etc. This can cause some organization issues if you don't plan this area out correctly and a head of time. I will dig a little more into how I do this for clients. First I will go over Discovery Options and creating boundaries and boundary groups.

Active Directory Discovery Options There are 6 discovery methods that we can configure within Configuration Manager. Active Directory Forest Discovery, Active Directory Group Discovery, Active Directory System Discovery, Active Directory User Discovery, Heartbeat Discovery, and Network Discovery are the 6 methods. I will go over each a little but will only be focusing on just a few in my lab. First I would like to talk about considerations you need to plan for when running some of these discoveries.

Active Directory Discovery Considerations If or when you use an Active Directory Discovery method make sure you run discovery at the site that has a fast network connection to your domain controllers. Run Active Directory System Discovery and Active Directory User Discovery before you run Active Directory Group Discovery. Only specify groups that you will use with your ConfigMgr environment when configuring Active Directory Group Discovery. Also, configure your discovery methods to have longer intervals between full discovery and more frequent delta discovery periods.

Data Discovery Records Let's talk about a Data Discovery Record (DDR's) before we begin as well. These are files that contain information about your device we can manage in ConfigMgr. These files contain information about computers and users. This files are created by the discovery method. The information about the device/resource is entered into the database and then the file is deleted. DDR files are about 1 kb in size.

The Active Directory Discovery Methods This again is just a high level of the discovery methods available and how to configure them to start discovery devices and users (resources) within your organization. http://technet.microsoft.com/en-us/library/gg712308.aspx

Discovery Method Information

Active Directory Forest Discovery

Can discover Active Directory sites and subnets, and then create Configuration Manager Boundaries for each site and subnet from the forests that you have configured for discovery. When Active Directory Forest Discovery identifies a subnet that is assigned to an Active Directory site, Configuration Manager converts the subnet into an IP address range boundary.

Supports a user-defined account to discover resources for each forest. Can publish to the Active Directory Domain Services of a forest when

publishing to that forest is enabled, and the specified account has permissions to that forest.

Active Directory System Discovery

Discovers computers from the specified locations in Active Directory Domain Services.

Active Directory User Discovery

Discovers user accounts from the specified locations in Active Directory Domain Services.

Active Directory Group Discovery

• Discovers local, global, and universal security groups, the membership within these groups, and the membership within distribution groups from the specified locations in Active directory Domain Services. Distribution groups are not discovered as group resources.

Heartbeat Discovery Used by active Configuration Manager Clients to update their discovery records in the database.

Heartbeat Discovery can force discovery of a computer as a new resource record, or can repopulate the database record of a computer that was deleted from the database.

Network Discovery Searches your network infrastructure for network devices that have an IP address.

Can discover devices that might not be found by other discovery methods. This includes printers, routers, and bridges.

Configuring Discovery Options In my lab I am going to configure Forest Discovery, System Discovery, User Discovery, Group Discovery, and Heartbeat Discovery. On all but Heartbeat Discovery I will keep the default schedules once I enable them.

Active Directory Forest Discovery

On my Active Directory Forest Discovery I will also allow it to create boundaries based off of Active Directory Sites. Since this is my lab environment I know my sites are configured correctly. If you are

http://technet.microsoft.com/en-us/library/gg712308.aspx

going to do this in a production environment make sure that all your AD Sites are configured correctly. This is very important and if they are not and you are creating boundary groups based off of AD sites you can run into some headaches with client management in the future. Since this is my lab I will also click to run discovery now when it prompts me. However, if this was a production environment you might need to wait for reasons outside your control like a change request or over bearing network and AD guys. :)

Active Directory Systems Discovery

The next discovery I will configure and enable is the Active Directory Systems Discovery. I will pretty much leave the default settings for this discovery when it comes to the polling tab. 7 days for full and every 5 minutes for a delta discovery. For those that are planning your production environment I would also suggest under the options tab to select the feature to only discover computers that have logged onto the domain in the last 90 days. You shouldn't need this if your Active Directory administrator keeps Active Directory current. Also, at this point you can configure additional active directory attributes for the computers you want to discover. Now since this is a lab environment I can just discovery everything in my entire domain. If you are deploying a production environment you should think about what Active Directory containers you are going to have this discovery look in.

Active Directory User Discovery

I will then enable and configure Active Directory User Discovery with the default schedule of 7 days for a full and every 5 minutes for a delta discovery. Also just like Systems Discovery with User Discovery you can discover custom attributes from Active Directory. As with System discovery you can specify which container that this discovery will look in. In my lab I have created an OU called LAB Users within my organization. I will configure my User Discovery to just look into this User OU. I don't really want service accounts or built in accounts to be imported into ConfigMgr.

Active Directory Group Discovery

Active Directory Group Discovery is my next discovery I will configure. Again since this is my lab environment I will keep the default polling schedule. On the General tab I will add by Location and select my User Groups OU that I have created in my demo lab. You will want to add all your OU's that may have users for example HR Groups, IT Groups, etc.

Heartbeat Discovery

The last discovery method I will configure is the only one that is enabled by default. The Heartbeat discovery method checks if a client is alive or not and will also report the status as well. I have always changed the default polling schedule to every 1 day from the default 7. I do not ever configure the Network Discovery and really don't see a need for that discovery. At least for the clients I have deployed and work with. Yes, I know there is a reason for this discovery but have never needed to configure it as of yet. By now your discoveries should have all completed for the first time and you should have users and computer resources in the console now. However since we have not configured Client Push or any other type of client installation method none of those resources will have a client installed. Before we start pushing clients or installing clients we will need to setup and configure our Boundaries and Boundary groups.

Boundaries and Boundary Groups Quick discussion about boundary groups and boundaries. So, I can tell you the technical description or I can give you my crazy description. Imagine a chicken farm or pig farm. Your pigs and chickens are the devices we will be managing. However, when it comes to feeding time you want them organized in their own pens or coups, correct? So, think of it this way, a boundary is like a chicken coup or a pig pen that keeps specific chickens and pigs within. A boundary group would be the farm that those pens and coups are on. This way when you want to send chicken feed (application or software update) to your chickens that feed is sent to the correct group of chickens and vice versa for the pigs. Can you tell I grew up on a ranch? Ok, so enough farm talk and on to talking about what boundaries and boundary groups are for and why they are very important. According to the official TechNet description Boundaries represent network locations on the intranet where ConfigMgr clients are located. Boundary groups are logic groups of boundaries that can provide clients access to resources such as Distribution Points, etc. In my deployments I normally configure boundaries based off of Active Directory Sites as long as Active Directory has been configured correctly and is being managed correctly. You will hear discussion that it isn't good to use AD sites for boundaries that IP Subnets and IP ranges are a better way to go. I would say yes in some cases but no in others. However for my lab I am using Active Directory Sites for my boundaries. A boundary group would then contain various boundaries based off of location, etc. For example, you have a corporate office that has various AD sites workstations, a VPN site, a few more Server AD sites, etc. You would have a separate boundary created for each of those AD sites for your workstations, your VPN AD Site, and your Server AD sites. You would then create boundary groups based off locations of those boundaries in most cases. So Workstation Site A and B would then be in a boundary called Headquarters Workstations, etc. These are basic examples and depending on your infrastructure they will all be different. For more information on how to create boundaries and boundary groups the following TechNet article goes into more detail. http://technet.microsoft.com/en-us/library/hh427326.aspx So, for my lab since I only have one AD Site and I have already ran an Active Directory Forest Discovery with it configured to create boundaries based off of AD sites automatically I already have my one and only boundary setup. I will then create a boundary group called LAB Boundary Group and add the boundary that was auto created to this new group. On my boundary group properties under the Reference tab I will select the box "Use this boundary group for site assignment." I will also verify that the Assigned site is my LAB site we created early when we installed our primary site server. This is where I will also assign my site server to this boundary group by adding it to the section Site System Servers. You will only need to add distribution points and state migration points to this field. Management Points are not contained by boundaries. So, now we have our boundaries setup and our boundary group setup. In a more complex organization and not in a lab environment you will want to make sure you have taken time to design and create your

http://technet.microsoft.com/en-us/library/hh427326.aspx

boundaries and boundary groups correctly. If not setup correctly clients will not be able to properly get content from distribution groups and state migration points and will be the cause of a majority of your headaches.

Setup Collections for Computers and Users Do you have those admins that constantly go into a file server and randomly create folders and place various files in various locations? This soon becomes a big unorganized mess. Well, this can happen with your collections if you don't plan out ahead of time and create naming conventions for your collections. I can't really tell you how to manage your collections because each environment is always different but I can show you and suggest to you how I usually start a client and my labs off. I normally start off by created 6 folders under Device Collections: Software Updates Software Deployments Inventory Configurations Operating System Deployments Compliance

Software Updates Collections These folder names should be self-explanatory but I will explain myself. Under Software Updates folder I will create and organize all my software update collections. These collections names usually are based off the Software Update Groups and Distributions that are created in your planning for software updates. I will create a blog in the future with more details on what I suggest is a good Software Update planning policy and procedures. For example I will have created a Software Update Group called SU_Windows_Servers_2013. Which will list all my approved software updates for all my Windows servers for the year of 2013. That in turn will have a default deployment named SU_Windows_Servers_2013 that would be deployed to a collection that we will have created. In my lab environment I would start out by creating the following collections in this folder.

SU_Windows _Servers SU_Windows_Workstations SU_Exchange_Servers SU_SQL_Servers

In a production environment I would make sure we had a few different phases that we could deploy updates to one phase at a time. So you might add something like SU_Windows_Servers_Phase_I or something like that. These collections would be mixed between direct memberships and include Collection memberships.

Software Deployment Collections Next is our Software Deployment folder which will have all our computer collections that will be created based off the application or package name we are deploying? For instance for my Microsoft Office 2013 Professional Plus Application I will have a computer and user collection based off the same name like Microsoft Office 2013 Professional Plus - Computer and one for my User collection but with a - User

after. I always create a computer collection and a user collection at the same time for each application/package we plan to deploy or place in our company store.

Microsoft_Office_2013_Professional-Computer Microsoft_Office_2013_Profiession-User

Inventory Collections Inventory is my next folder. This folder holds special collections mostly based off of queries. For instance, I always create the following collections with query based memberships:

All Windows Server 2003 Devices (yes I know but there are a lot of clients that still run Windows 2003) All Windows Server 2003 R2 Devices All Windows Server 2008 Devices All Windows Server 2008 R2 Devices All Windows Server 2012 Devices All Windows Server 2012 R2 Devices All Windows Servers (This has a membership of Include Collection and I add all the server collections) All Windows XP Devices All Windows XP x64 Devices All Windows 7 Devices All Windows 8 Devices All Windows 8.1 Devices All Windows Workstations (This has a membership of Include Collection and I add all the workstation collections)

I also will create Inventory related collections based off of installed applications like Endpoint Protection, Exchange Servers, SQL Servers, etc.

Configuration Collections My Configuration folder always contains collections that will have configurations assigned to them like Power Settings, maintenance plans, Firewall and Endpoint protection settings, and Client Configuration Settings. For example the following collections would be:

Endpoint Protection - Domain Controllers Endpoint Protection - SQL Servers Endpoint Protection - File Servers Endpoint Protection - Exchange Servers Endpoint Protection - Workstations Power Settings - Workstations

Maintenance Plan - Servers Maintenance Plan - Workstations Client Settings - Servers Client Settings - Workstations

The maintenance and power setting plans are default collections I create. I suggest that you create more collections if possible based on needs and your environment.

Operating System Deployment Collections Operating System Deployment Folder helps me organize my OSD deployments. Here is where we will organize our collections that we deploy our OSD task sequences to. By habit I will always create the following:

Build and Capture Build Resource Build Core Image Test and Development Production Image Collection

Compliance Collections Last folder I create is my Compliance Folder. The compliance feature in ConfigMgr is pretty cool yet very rarely used. I don't create any default collections in this folder until we have had time to discuss compliance goals with my client. For an example we could always create a collection for all non-complaint machines not running your version of Office 2013 or maybe an application you do not want installed on your desktops like Firefox? Now, all the collections I have shown you have been computer collections. Being from the old school days of SMS and ConfigMgr 2007 I still lean heavily on computer based collections. Yes, I know that ConfigMgr 2012 R2 is based off of being user centric. That is why I will also create folders under the Users Collection as well. The only folder that I create right out of the box for the User Collection is Software Deployment. Just like the Computer Devices I will use this folder to organize all Software Deployments to users. Now as I said these are my starter Collections that will always be added to or removed. There is an ongoing discussion in the ConfigMgr would that few collections are better or you can be on the side I lean and still use more collections for organization. For more details on how to create the collections you can visit the TechNet link below. http://technet.microsoft.com/en-us/library/gg712295.aspx

Setup folder structure within the Source folder Folder structure is a pet peeve of mine. It is hard to walk into a client and see that they have application files spread across many drives and servers, drivers and image files here and there, etc. I prefer having all my ConfigMgr files located in one location for easy management. There are several ways we can do this. I will show you here how I have recently started to create a client's folder structure. Normally I will


start by creating a folder called Source. This will be our root folder for all our other ConfigMgr related folders and files. As you go along with your ConfigMgr infrastructure you will soon see why starting organized is a lot better than trying to become organized.

DFS Share On a side note, I have started creating a DFS share that points to this folder we will be creating. Why? Well, with all your applications, packages, drivers, etc. they all have a source content location that points back to some place either on one of the folders we are creating or on another server location. If you ConfigMgr server where to die and or you upgraded to another server with a different name all your packages, applications, etc. will be pointing to the \\servername location. Which will in turn cause you grief trying to fix each package/application/etc. Just create a simple DFS namespace called \\domain\ConfigMgr or Source that points to your files. All your applications/packages/etc. will then have that path and then in turn be easier to restore if a critical crash occurs.

ConfigMgr Folder Structure Example So, here is a look at how I setup my ConfigMgr folder structure for my source files like drivers and software applications, etc. I create on a drive that I have purposely added with enough space to grow. Remember, your software updates, drivers, images, and application files will start to consume more and more space. Plan out ahead of time. In my current lab I only have dedicated 100 GB which will do for now. In a production deployment I wouldn't go less than 300 GB. F:\Source This folder is shared but usually is hidden. Just another way to keep roaming eyes out of your folders since I always give “Everyone” full permissions on the Share level that is why we hide this share. I will also assign the following NTFS permissions. Local Admins (Full), System (Full), Domain Computers (read), ConfigMgr Admins (Full), <Capture User> (Read), <Network Access Account> (Read) and Help Desk (Read). F:\Source\Captures This is for all the image capturing activities. NTFS permissions will be set at <Capture User><Network Access Account> (Full) F:\Source\Client I copy the client folder from the ConfigMgr installation directory. I also add a hotfix folder and add all client hotfixes here as well. F:\Source\Content All source files will be located here F:\Source\Content\OSD F:\Source\Content\OSD\BootImages F:\Source\Content\OSD\Drivers We will create sub-folders for each model and vendor. F:\Source\Content\OSD\MDTSettings F:\Source\Content\OSD\MDTToolKits

F:\Source\Content\OSD\OSImages I will also create sub-folders for each image version and type. For example you will have your reference images, and your core images, and your production images, etc. F:\Source\Content\OSD\OSSource For all OSD related content. F:\Source\Content\Software Deployment For application and package deployments. I normally create a sub-folder for each vendor, then another sub-folder for the product, then another sub-folder for the version. F:\Source\Content\Software Updates Windows Security updates (Software Updates). One sub-folder for each Software Update Distribution Group. For example, Windows Workstations, Windows Servers, Exchange Servers, etc. F:\Source\Error Logs A place for startup scripts and task scripts to dump their errors in. NTFS Permissions Domain Computers (Full) F:\Source\Import Location to import content like drivers and other files that will be imported into ConfigMgr. This is not a package source location. F:\Source\Import\Baselines For ConfigMgr DCM/Settings Management. F:\Source\Import\Drivers One sub folder for vender with a sub folder for each model that will be imported. F:\Source\MDTLogs MDT Log files. Permissions NTFS <Network Access Account> (Read) F:\Source\Scripts Script location F:\Source\StateMigration State Migration Point Location for USMT during OSD Task Sequences. Permissions will be controlled by ConfigMgr. F:\Source\Tools Tools like CMTrace, PolicySpy, etc.

Install Site Roles and Configuring Site Roles Software Update Point Reporting Service Point State Migration Point Application Catalog roles

Asset Intelligence Endpoint Protection

We are at a good point where I will be installing the Site server roles that I had mentioned earlier. We will also configure some of the components that had been installed. As well as configure the site server roles we will be installing. The roles we will be working with are you most common features that most organizations use. Here is a quick high level way to install any site system role on both existing site servers and to install to a new site server like I will be doing for my lab environment. http://technet.microsoft.com/en-us/library/hh272770.aspx#BKMK_HowtoInstallSiteSystems_existing

1. In the Configuration Manager console, click Administration. 2. In the Administration workspace, expand Site Configuration, click Servers and Site System Roles,

and then select the server that you want to use for the new site system roles. 3. On the Home tab, in the Server group, click Add Site System Roles. 4. On the General page, review the settings, and then click Next 5. For System Center 2012 Configuration Manager SP1 and System Center 2012 R2

Configuration Manager only: On the Proxy page, specify settings for a proxy server if site system roles that run on this site system server require a proxy server to connect to locations on the Internet, and then click Next.

6. On the System Role Selection page, select the site system roles that you want to add, and then click “Next”.

7. Complete the wizard If you are installing to a new Site Server then you would follow these high level instructions:

1. In the Configuration Manager console, click Administration. 2. In the Administration workspace, expand Site Configuration, and click Servers and Site System

Roles. 3. On the Home tab, in the Create group, click Create Site System Server. 4. On the General page, specify the general settings for the site system, and then click Next. 5. For System Center 2012 Configuration Manager SP1 and System Center 2012 R2

Configuration Manager only: On the Proxy page, specify settings for a proxy server if site system roles that run on this site system server require a proxy server to connect to locations on the Internet, and then click Next.

6. On the System Role Selection page, select the site system roles that you want to add, and then click Next.

7. Complete the wizard.

Software Update Point Role I will start out by installing and configuring our Software Update Point role and continue with the rest stopping at the Endpoint Protection Point. Most site roles are installed the same however each one will have different configurations. We did install our WSUS Server role on its own server. For my lab I will install the Software Update Point (SUP) on my stand alone WSUS server. The next step is configuring the SUP role. I always use ports 8530 and 8531 for client communication. Leave everything else default on that window and click next. The next window we will also click next since we will use the Computer Account for permissions. We will keep the default Sync

http://technet.microsoft.com/en-us/library/hh272770.aspx#BKMK_HowtoInstallSiteSystems_existing

Source of Microsoft. On the sync schedule I always do a sync every night. Yes, a majority of updates come out on patch Tuesday but we would like to catch any revisions. I also will alert when it fails to sync. I also select the option to immediately supersede any expired software updates. On the next few windows I just leave the default classifications and products and remove all languages except for English. Once we have a successful sync I will go back to this component and start selecting our products. Click the rest of the way through and monitor the installation of this component. Next, I am going to select the following roles and install them at the same time since all of these roles will be installed on the same site server, State Migration Point, Asset Intelligence Point, and Endpoint Protection Point.

State Migration Point (SMP) The first configuration the installation wizard is asking me is for the State Migration Point (SMP). This role will need a local folder that we will designate for the User Data. Earlier we created this folder F:\Source\StateMigration. We will then specify how long the User Data is kept for, which I normally keep for 7 days, as well as how much space is reserved for this SMP. I normally will reserve a minimum of 10 GB. You will need to specify a boundary group for this SMP. Since we have a small lab it is pretty easy. I have selected the only boundary group we created earlier. This is where boundary groups will start becoming very important. We don't want our clients at site A to use a SMP at a remote location. We want them to use the SMP at site A. By default the correct boundary group should be listed. If not, we most likely have AD Site issues.

Asset Intelligence Point The Asset Intelligence Point is pretty basic. Unless you are required to use a certificate you can accept default settings for both windows.

Endpoint Protection Point The Endpoint Protection Point will need you to accept a Microsoft License agreement. Click the box and click “Next”. On the MAPS window since this is my lab environment I will always send data to Microsoft. In a production environment please make sure your organizations policies allow you to send data to Microsoft. Click through the summary pages and install your site server roles. You can monitor the installation using the Monitoring Workspace. Click System status, then select Status Message Queries and open the query "All Status Messages." This will give you some status messages that will show if the component installed or failed. If you want you can dig deeper by viewer the actually log files using CMTrace. I prefer the log files since it will give you more details.

Reporting Service Point & Application Catalog Roles The final site system roles I am going to install and configure is the Reporting Service Point, Application Catalog Web Service Point, and the Application Catalog Website Point. This will be similar to installing the SUP since we are installing these roles on another site server. I will be installing these roles to my lab-web.lab.cloud server. Please follow the above instructions if you are not sure how to start the installation of these roles on a new site server. Just follow the windows in the wizard and select the three roles we are installing.

Reporting Service Point Role The first role we will be configuring will be the reporting service point. Here we will need to specify the Site Database server which is lab-sql.lab.cloud in my lab. The database name should default to you existing ConfigMgr database. Click Verify to make sure that the information is correct. On the same window leave the Fold Name default. In the Reporting Services server instance select in our lab-web.lab.cloud server.

Application Catalog Roles Next we will configure the Application Catalog website points and the Application Catalog Web Service Point. I am going to keep the defaults on most of these settings, ISS Website and Web Application name I will keep default. The port as well, we will keep the default port 80. On the next windows I will just leave the defaults as well. The next window allows you to pick a website theme which is basically just a color and then an Organization Name that will appear on the app store. Click next all the way through and monitor the installation of these new components.

Configuring Distribution Points Now that we have installed all the site roles there are still some configuration to be done. We need to go back to the Software Update role and configure which product and the type of updates we will want to include in our searches. We also need to go configure out distribution point to handle PXE request. Also, we would like to know if our management point is healthy or not. There are some client and hierarchy configurations we will verify are set as well. I will now go to our distribution point since I only have one and it should be fairly easy to configure.

1. Click Administration work space 2. Expand Site Configuration 3. Select Servers and Site System Roles 4. On the right I will select my primary site server since this is where my DP has been installed 5. The window below will list all my site roles installed on this server. 6. Right click and select properties on the Distribution Point Role. 7. Click the PXE tab.

a. I will enable PXE support for clients here even through it is in an Azure network. b. Select "Allow this distribution point to respond to incoming PXE Request." c. Select "Enable unknown computer support” Hit OK when the information window pops

up. d. Type in a password. I don't suggest ever unchecking this option in a production

environment or even a lab environment. e. I normally change User Device affinity to "Allow user device affinity with automatic

approval." This is a feature that I won't go into on this blog but is very nice if configured correctly for many purposes.

8. Under the Multicast tab I don't usually enable this feature. This is something for you and your network team to hash out.

9. Under Group Relationships, we haven't created any Distribution Groups at this time. 10. The content tab probably at this time only has one item and that is most likely the Client

Install files.

11. Content Validation I will enabled at a lowest priority and on the default schedule. 12. Verify on the Boundary Groups tab that your current boundary group is listed. 13. Click OK and you are done configuring the DP role.

Configuring Components I will finish up by configuring the rest of my components including my Software Distribution Point and my Software Update Point component. The following is a list of the components that we can configure: System Health Validator Point Software Distribution Software Update Point Management Point Status Reporting Out of Band Management Email Notification Collection Evaluation

Since I am in a lab environment and I didn't setup an Exchange Server I won't be configuring the Email Notification. However, you can go into this component and configure it pretty easy to send alerts. The Collection Membership Evaluation and Status Reporting Components I will also leave default. These components just let you get a little more granular on how often your collections are evaluated and what detail level and importance certain status messages are. These are two areas that can help with performance on larger deployments. We are not using Out of Band Management, if you're interested in that have fun. :) System Health I will leave as default as well. The only two that I will discuss here are Software Distribution and Software Update Point components.

1. Click the Administration Workspace 2. Expand Site Configuration 3. Select Sites 4. Right click again on our Primary Site Server and select Configure Site Components

Configuring Management Point Component I will configure our Management Point. For this we will only need to change one item and that is the alerting on an unhealthy management point. Not sure why this isn't set for default since it is a very important piece for client communications but hey, we all never truly understand the Microsoft thinking process? I will now go to our management point since I only have one and it should be fairly easy to configure.

1. Click Administration work space 2. Expand Site Configuration 3. Select Servers and Site System Roles 4. On the right I will select my primary site server since this is where my Management Point has been

installed 5. The window below will list all my site roles installed on this server. 6. Right click and select properties on the Management Point Role.

a. Under the General tab place a check mark in "Generate alert when the management point is not healthy."

b. Click OK

Software Distribution Point Component I will go ahead and click on the Software Distribution Component properties. Here you can set a few settings such as how many packages can be distributed at one time and how many times it will retry if it fails. I am going to leave the default settings here for my lab on this tab. Next I will configure my Network Access Account. The Network Access Account is used by ConfigMgr clients to access network locations during deployment or during operating system deployments. This is an account I have already created in Active Directory and have already given all the correct rights to the shares and directories it will need to access.

1. Click on the Network Access Account Tab in your Software Distribution Component Properties window.

2. Click the bullet "Specify the account that accesses the network locations." 3. Click the * to add an account.

a. Since we have not yet added a Network Access Account you will need to select Add An Account.

b. Hit Browse and look for the account created in Part I of this blog. I had created an account called svc.networkaccess.

c. Type in the password for this account. d. Click Verify e. Select a network share that this account should have rights to. f. Select Test Connection g. Once it is successfully verifies the account Click OK

4. Click OK again and we are done configuring the Software Distribution Component.

Software Update Component Now, I am pretty much at the last part of configuring the configuration for Configuration Manager. I consider Software Update to be one of the most important parts of ConfigMgr. Yes, Software Deployment (Application Deployment), OSD, Compliance, etc. are pretty important as well. However, this is where I feel ConfigMgr shines over its competitors in this area. Don't get me wrong, ConfigMgr is better for Image deployment, application deployment, etc. than all the products I have touched. I have already installed the Site Role earlier in my blog. I also left pretty much the default settings for what classifications we will include and what products. During this section we will go over the settings we have already set and configure the classifications and products that we will need to provide and ensure all our endpoints are patched correctly. The Software Update how-to's are an entire different blog but I will go over the basics once we have configured the component.

1. Click the Administration Workspace 2. Expand Site Configuration 3. Select Sites

4. Right click again on our Primary Site Server and select Configure Site Components 5. Select Software Update Point

Sync Settings The first tab is how we can configure our Sync settings with Microsoft. There are some very rare occasions that I have come across where we wouldn't sync with Microsoft but an internal WSUS server that another department has control of. Normally in highly secure organizations or some branch of the government. In my lab I will have my Software Update Point sync directly with Microsoft. Classifications Here is the list of classifications we can set to include when we sync with Microsoft. I have linked a site that I have obtained a good explanation to what these classifications are. Remember, if you borrow please give the person credit. Yes, I have borrow here and there from TechNet but any personal or professional blog outside of TechNet I will always give credit to. http://www.acupofit.com/2012/04/wsus-update-classifications-explained.html

•Critical updates: Broadly released fixes for specific problems addressing critical, non-security related bugs. •Definition Updates: Updates to anti-malware or other definition files. •Feature Packs: New product functionality usually included in the next full product release. •Security Updates: Broadly released fixes for specific products, addressing security issues. •Service Packs: Cumulative sets of all hotfixes, security updates, critical updates, and updates created since the release of the product. Service packs might also contain a limited number of customer-requested design changes or features. •Tools: Utilities or features that aid in accomplishing a task or set of tasks. •Update Rollups: Cumulative sets of hotfixes, security updates, critical updates, and updates packaged together for easy deployment. A rollup generally targets a specific area, such as security, or a specific component, such as Internet Information Services (IIS). •Updates: Broadly released fixes for specific problems addressing non-critical, non-security related bugs.

This is an area that you should seriously discuss with your security, desktop, and server teams. However, since this is a lab I will pretty much select all of them.

http://www.acupofit.com/2012/04/wsus-update-classifications-explained.html

Note: The sync process doesn't download the actually update but the catalog and Meta data of each available update.

Products Here is where we will select what products we want to sync. If you had noticed when I first installed this role that a majority of newer products where not listed. This is why I didn't configure this section when I installed the role. I waited until we had a successful sync in order for the newest list to download. Here I will check all the products that we want updates for. This again is another area you need to discuss with your Security Team, Desktop Team, and Server Team.

Note: If you are going to be using Endpoint Protection make sure you have selected "Forefront Endpoint Protection 2010" updates.

Also, be aware for products that you may not think you have installed on your endpoints. For a good example is Microsoft Live products, Skype, and/or older versions of Lync or some application that may cause a security risk. I suggest you select a little more than not enough. Sync Schedule I had already set the Sync Schedule earlier but I will double check that it is still set to run every 1 days. This again is something you need to discuss if setting up a production environment. Make sure that this is also checked to alert you on sync errors. Supersedence Rules I allow it to expire superseded software updates. In your environment you may have a security team that wants to research an update first and you may have to manually supersede updates. Languages In my lab I have only selected English for both Software Update File and Summary Details. If you are planning a larger deployment across different countries you may consider adding more languages for each update.

Once I am done configuring this component I normally force a sync again. Since the first sync can take some time.

In order to force a sync:

1. Click on the Software Library Workspace in your ConfigMgr console. 2. Expand the Software Updates folder. 3. Right click All Software Updates and select Synchronize Software Updates

Primary Site Settings Now I will just walk through the Primary Site settings to verify everything is configured the way I would like it to be.

1. Click the Administration Workspace 2. Expand Site Configuration 3. Select Sites

4. On the windows to the right click the primary site and select properties.

I will not change anything here for this lab. However some people will want to enable Wake On LAN, maybe change some of the default ports the clients communicate on, change AD publishing, etc. So I will just list a few things on any tab that may become important later as your deploy your environment. The only tabs that may be of concern would be the Wake On LAN to enable that feature, Publishing to verify that you are publishing to all your AD forest and Domains, Ports if you need to change the port that clients communicate on, and Client Computer Communication which is where you would change it from HTTP to HTTPS and assign a Trusted Root Certificate Authority if you are going to use PKI client certificates

Configure Hierarchy Settings. Once last configuration of the site that I will look over. There are some important settings that can be changed in the Hierarchy settings for this site.

1. Click the Administration Workspace 2. Expand Site Configuration 3. Select Sites 4. Click On our Primary Site 5. At the top along the Ribbon menu there is a Hierarchy Settings option.

Since this is a single site a fallback site isn't necessary however, I will enable this in my lab for testing. Under the General tab place a check mark in the "Use a fallback site." Select the Client Approval and Conflicting Records tab. I will leave the default settings here. The next tab is something that you should discuss with your team. In a lab environment it isn't very important but in a production environment you should take in some considerations for automatically upgrading your clients. Just take note, this client upgrade feature only will upgrade your clients if it is a major service pack or revision release. If you install a CU this will not upgrade your client to the currently patched CU level. This also doesn’t give you much control of which clients at which location go and in what order. It is basically an enable or disable with a time period. If you enable this feature the system will randomly schedule the clients over the period of time you have selected. Since this is my lab I am going to enable it with a 1 day period. In past clients when I have enabled this we normally changed it to 14 days depending on the size and had no issues.

Client Settings Configurations The client settings section is basically what it says. It is where we will configure pretty much every setting that will be assigned to the clients. There is a long list of settings that are available to configure but for my lab I will hit only a few. For a good resource for breakdown of all the configuration settings included in Client Settings. http://technet.microsoft.com/en-us/library/gg682067.aspx

Client Settings for Devices Background Intelligent Transfer Client Policy Compliance Settings


http://technet.microsoft.com/en-us/library/gg682067.aspx#BKMK_BITS

http://technet.microsoft.com/en-us/library/gg682067.aspx#BKMK_ClientPolicyDeviceSettings

http://technet.microsoft.com/en-us/library/gg682067.aspx#BKMK_Compliance

Computer Agent Computer Restart Endpoint Protection Hardware Inventory Metered Internet Connections Network Access Protection (NAP) Power Management Remote Tools Software Deployment Software Inventory Software Updates User and Device Affinity

Client settings for users:

Mobile Devices Enrollment User and Device Affinity

Create Custom Client Policy Let's create a custom client setting and assign it to our collection in our lab. This is also a good discussion issue. What settings are needed, what they will be deployed to. Normally in a production environment you would have settings for servers and settings for your clients. You would even break down these settings and possible create custom settings such as Endpoint Protection, Computer Restart policies, etc. For the my lab I am going to create a custom client setting for all my servers and a custom client setting for all my workstations and then deploy them to the proper configuration collection that I previously created. Here is a quick step by step on creating a custom client setting and deploying it.

1. Click the Administration Workspace 2. Right click on Client Settings 3. Select Create Custom Client Device Settings 4. Name the Custom Device Setting and also please please please include a good description. I have

created one called Client Settings - Workstations. 5. For my custom client setting I have selected the following:

a. Client Policy b. Compliance Settings c. Computer Agent d. Hardware Inventory e. Remote Tools f. Software Inventory g. Software Updates h. User and Device Affinity

6. Click OK

Configure Custom Client Settings We now have a custom client setting ready to be configured. Also, remember any setting that you don't select will fall back to the Default Client Setting that is positioned at priority 1000. When the client is

http://technet.microsoft.com/en-us/library/gg682067.aspx#BKMK_ComputerAgentDeviceSettings

http://technet.microsoft.com/en-us/library/gg682067.aspx#BKMK_ComputerRestartDeviceSettings

http://technet.microsoft.com/en-us/library/gg682067.aspx#BKMK_EndpointProtectionDeviceSettings

http://technet.microsoft.com/en-us/library/gg682067.aspx#BKMK_HardwareInventoryDeviceSettings

http://technet.microsoft.com/en-us/library/gg682067.aspx#BKMK_MeteredInternetConnetionsSettings

http://technet.microsoft.com/en-us/library/gg682067.aspx#BKMK_NAPDeviceSettings

http://technet.microsoft.com/en-us/library/gg682067.aspx#BKMK_PowMgmtDeviceSettings

http://technet.microsoft.com/en-us/library/gg682067.aspx#BKMK_RemoteToolsDeviceSettings

http://technet.microsoft.com/en-us/library/gg682067.aspx#BKMK_SoftwareDeploymentDeviceSettings

http://technet.microsoft.com/en-us/library/gg682067.aspx#BKMK_SoftInventoryDeviceSettings

http://technet.microsoft.com/en-us/library/gg682067.aspx#BKMK_SoftwareUpdatesDeviceSetting

http://technet.microsoft.com/en-us/library/gg682067.aspx#BKMK_UserDeviceAffinityDeviceSettings

http://technet.microsoft.com/en-us/library/gg682067.aspx#BKMK_MobileDevicesUserSettings

http://technet.microsoft.com/en-us/library/gg682067.aspx#BKMK_EnrollmentUserSettings

http://technet.microsoft.com/en-us/library/gg682067.aspx#BKMK_UserDeviceAffinityUserSettings

installed the default settings will be applied until it has had a chance to check in with the server and get it assigned settings.

Client Policy Here is how the client computers retrieve policy. Normally I will leave these settings as default unless a client has issues with how often a client polls the management server. However, this is very little traffic. Compliance Settings Once again these settings can be set to default. Computer Agent These are general settings for communication between the client and the server. I would start by configuring the Default Application Catalog Website point. In my lab I have configured it to use the FQDN of the Application catalog which is http://lab-web.lab.cloud. I also add the Application Catalog to the local trusted site zones. This is something you should discuss with your security team. I also elevate the trust mode for Silver light applications since the App store does run on Silverlight. You can also type in a name that will be displayed in the Software Center. There are more settings that you should take into consideration. For my lab I have the PowerShell execution polity to be set at Bypass. This may send up a red flag in your organization if you don't talk to your teams first. Hardware Inventory This setting configures the hardware inventory settings on your client computers. Don't let the name fool you because the hardware inventory also does software inventory which in turn is analyzed by Asset Intelligence. Software Inventory will inventory directly from files that you specify. It will collect file header information from those specified files. So in easy to understand terms, hardware inventory does what it is called and collects hardware information from the client like (CPU, RAM, Servicers, etc.) as well as WMI queries which in turn can include information from add/remove programs, etc. I always leave hardware inventory enabled and default schedule. If you look at the setting you will also see a line called Hardware inventory classes with an option to Set Classes. In here you can add information from about a boat load of available WMI classes. Take some time and scroll through these. You might find that you want to know what battery is installed on a certain laptop. By default that WMI Object isn't being reported on. One check and bingo you will now start seeing that in your hardware inventory results. Remote Tools This feature has returned with some added capabilities from the time between SMS 2003 and ConfigMgr 2007. Now you can configure the Remote tools policies per setting and not just the entire site. Which means you can have multiple Remote Tools polices deployed throughout your site depending on who need access to what systems. Software Inventory

http://lab-web.lab.cloud/

Once again like I mentioned in Hardware Inventory, Software Inventory inventories specific files that you specify. It can also collect a certain file type for you as well. This will not give you an accurate view of what is installed on your clients. Software Updates Normally I leave the default settings. I might bump up the deployment re-evaluation depending on the client. With R2 you can now allow Software Updates to deploy with priority over all other deployments once it has reached its deployment deadline. User and Device Affinity. This feature is nice. I won't go into it much here but you really need to look into taking advantage of User and Device affinity. This is really good for advanced software deployments and more. I will change it to allow the system to automatically configure user’s devices from the stats it collects.

These are the basic client settings that I would focus on before deploying any agents. You should sit down and plan your client settings and how you want to deploy those settings to what group of clients.

Deploying Custom Client Settings Now we need to deploy this custom setting to our collection we have created our configurations.

1. Right click the Client Settings - Workstation custom setting and select Deploy. 2. Navigate to the folder Configuration Settings that we created earlier. ON the left window you

should see our Client Settings - Workstations collection. Select it and click OK.

Configuring Endpoint Protection I will run through setting up Endpoint Protection on a higher level in this blog. You should really focus later on your Endpoint policies and make sure you have then setup to help protect your clients and servers. I have heard that Microsoft now recommends only installing anti-virus on specific server with certain roles installed. Anything your user’s endpoint will access like File Servers, etc. You can get to your Endpoint Protection policies, better known as Antimalware Policies here:

1. Click on the Assets and Compliance Workspace. 2. Expand the Endpoint Protection Folder 3. Select Antimalware Policies.

Once we have our Endpoint Protection role installed we will need to make sure we configure the client settings to enable or disable Endpoint Protection on our resources. There are many ways one can get to a final solution but I am going to give you mine. I had gone over earlier in my blog creating collections based off of configurations, inventory, etc. This is where one of those configuration collections will come into the picture. Now, remember this is my lab and not a working production environment but I will try to mimic how I would suggest a client to setup their Endpoint Client settings and collections. In my example here and in my lab I will have already setup the Endpoint Protection - Workstations collection that has a membership rule to include all Windows Workstations. Since we want to make sure all our workstations (endpoints) have the client installed. In a production environment you may create more Endpoint Protection settings for specific reasons outside of your server policies of course.

Let's create an Endpoint Protect setting and assign it to our collection in our lab. 1. Click the Administration Workspace 2. Right click on Client Settings 3. Select Create Custom Client Device Settings 4. I will name it Endpoint Protection - Workstations 5. Type in a description. Please!!!!! Document what and why this setting is there!!!!!! 6. Select Endpoint Protection 7. Click OK.

Now that we have our Endpoint Protection custom setting created I will edit the setting to fix out needs.

1. Right click the newly created Endpoint Protection Custom Setting 2. On the left column click on Endpoint Protection. 3. Under Custom Device settings in the left window we will find all the configurations that we can set

for this policy. This doesn't configure how the client will handle viruses and malware. That is in the Antimalware Policy section.

a. Manage Endpoint Protection client on client computers. Change this to Yes. Now you will notice that more options are selectable and no longer greyed out.

b. Install Endpoint Protection client on client computers. I will keep this at Yes. c. Automatically remove previous installed antimalware software. I will keep this at Yes. A

quick note, this feature is pretty good and can uninstall a very long list of existing software out there currently.

d. Allow Endpoint to restart. I always say No to any restart questions. e. Pretty much the rest of the options here are default. However, the last option is an

interesting one and depending on your patch management policies as well as your bandwidth from your sites may or may not be important. I will normally suggest that you disable alternate sources for definition updates and only allow the clients to download from the closest distribution point. However there may be a need to allow clients to grab from Windows Update directly. There are more settings that can be set within the Malware policy that will tell the client after a certain amount of time when the definition on a client is old it can go out to another source.

4. Click OK Now we need to deploy this custom setting to our collection we have created for Endpoint configurations.

1. Right click the Endpoint Protection custom setting and select Deploy. 2. Navigate to the folder Configuration Settings that we created earlier. ON the left window you

should see our Endpoint Protection - Workstations collection. Select it and click OK. On a high level we now have the Endpoint Protection role installed, configured and deployed to our workstations. There is still a lot to do here if you plan to use this environment f or production. However, for our lab we are done except for creating a Server Custom setting and deploying that as well.

Install our clients OK, so now we have a majority of the configuration settings completed for the roles that we have installed. We are now ready to talk about how we will install the client to our systems. There are different ways of getting the client installed to your systems. I will configured my lab to use the Client

Push Installation to install a client to all discovered systems. This option sometimes isn't always configured with clients I have worked with. There also is the install client from console option as well. I stay away from these first two as much as possible to avoid the over load of errors that will fill our logs file we will monitor. Don't get me wrong, there are times when you will want to install the client from the console. Each client has been different and it always depends on how the other teams involved would like to see the client deployed. You can deploy the client via GPO and logon script as well. The two later are pretty much what a lot of clients have selected to use and some have enabled the automatic client push to install the rest. If there is an existing WSUS environment you can also install the client using the Software Update-based Client installation feature as well. I also can't forget the good old fashion manual method of just running a script or typing out the command line. I won't go into the logon script or GPO installation methods in this blog. There are plenty of great resources out there that can help you create a logon script and a GPO. I will be honest, I use to not suggest GPO or logon scripts but after some time in the field I have found it is a pretty good way to get a high percentage of your machines installed. Today in my blog I will cover how to configure the "Client Push Installation," how to configure the "Software Update-Based Client Installation and how to install the client using the console. Configuring the Client Push Installation Method

1. Click the Administration Workspace 2. Expand Site Configuration 3. Select Sites 4. Select our Primary Site 5. On the menu ribbon click "Client Installation Settings" 6. Select "Client Push Installation" 7. Check "Enable automatic site-wide client installation."

General Tab On this tab is where we will enable the automatic site-wide push installation. There some decisions that should be made by your server teams here that may affect what options you select in a production environment. However, this is my lab so I am going to place a check mark for Servers, Workstations, and Configuration Manager Site systems servers. Also, I will select the bullet "Always install Configuration Manager Clients on domain controllers" since this is a lab and I have complete control over all my servers. In a production environment I wouldn't normally select this option. I would had off the task to the server admins or AD admins depending on how large of an originations. Accounts Here is where I will add my Client Push account I created earlier. Since I have not yet added a Client Push account to my ConfigMgr I will need to add a new account just like we did for the Network Access Account.

1. Select the * and select add new account 2. Browse and select the account created. I will be using svc.clientpush that has already

been setup in Active Directory and already has been assigned the correct permissions on all my servers and workstations via a GPO.

3. Verify the credentials work 4. Click OK.

Installation Properties Since Client Push settings are site specific under the Installation Properties tab you should already have SMSSITECODE=LAB listed. If not you can add it here. You do not need to add anything else to this list.

Software Update-based Client Installation method 1. Click the Administration Workspace 2. Expand Site Configuration 3. Select Sites 4. Select our Primary Site 5. On the menu ribbon click "Client Installation Settings" 6. Select "Software Update-Based Configuration Manager Client Install" 7. Check "Enable Software update-based client installation. 8. Click Ok

Once you have configured your installation methods you should shortly see in your Devices view your resources reporting the client installed. At this point your clients should be running a full Software and Hardware Inventory, running your Software Update evaluations, and checking if they have any Software Deployments deployed to them, etc. If you have configured Endpoint Protection and enabled the role you will also see the Endpoint client starting to pop up and your existing anti-virus software should be removed. Give your new client some time before assuming that something is not working. Check your log files and monitor what is really going on with your clients at this point.

Giving Console Rights I won't go to deep into Role Based Administration here on this blog but I do need to assign the ConfigMgr Admin Group to the proper group within ConfigMgr. If I don't then the only user that has access to the console is currently my ConfigMgr Admin user account. I would suggest reading up on Role Based Administration which is pretty dang cool with ConfigMgr 2012 R2. For now I will walk you through adding our ConfigMgr Admins Security group.

1. From the ConfigMgr Console click on the Administration Workspace. 2. Expend the Security Folder 3. Right click on Administrative Users and select add group 4. Browse for your ConfigMgr Administrator Group 5. Click the Add button 6. Place a check in the Full Administrator in the Add Security Role Window. 7. Click OK 8. Under the "Assigned Security Scopes and collections" section make sure the bullet "All instances

of the objects that are related to the assigned security roles" are selected. 9. Click OK

Note: I would advise against adding any user directly to this ConfigMgr group. Use your AD group to manage who has admin rights. Also, don't just throw anyone in this group. Especially if you plan on breaking down the roles later.

Ready for production At this point I should have given you enough information to have a fully functional lab environment for testing as well as a start for your production environment. As you go about finishing your configurations and installing other site roles you will learn that my way isn't always the best way compared to your way. What I have done in this blog works for me and is a good starter for my clients. There are so many other configurations and areas that I could talk about. We just hit the tip of the ice berg. For instance, more detailed client settings for different policy requirements, Role Based Administration so your Desktop team can only see their collections, their applications, their deployments, etc. As well as only allowing the server team to view their reports, collections, deployments, etc. We can talk about Configuration Settings for compliance and security concerns. We can go deeper into Software Updates and how to make sure you are compliant in that area. Application deployment alone is a full time job in a lot of organizations. Also, OSD, one of my favorite features in ConfigMgr, being able to truly image a machine with limited touch and knowing that as soon as that image is deployed it is 100% ready for a user to us. We can also talk about Power management and maintenance windows settings. Reporting and many more areas of ConfigMgr that we can go on and on and on. So please keep my blog saved and when I have time I will blog about a lot of these features. I even plan to re-write this blog into a more high level step by step and less talk blog for those that just want the how to version.

Install MDT 2013 (If necessary) Before I finish I would like to walk through the Microsoft Deployment Toolkit integration with ConfigMgr console. I won't go into depth on the product or how to use it as a standalone solution for imaging or even how to use it after you integrate it into your console. In my lab environment I am going to install MDT on my management box since I only really care about the added functionality to my ConfigMgr console. In a production environment and if you decide to use MDT to build your reference and core images I would suggest building a dedicated server for those task. You will still need to install MDT on any box that you plan to use these features from within ConfigMgr.

1. Start by downloading the installation files from Microsoft. http://www.microsoft.com/en-us/download/details.aspx?id=40796

2. I will be installing on my Management server like I have mentioned. Lab-mgmt, already has the ConfigMgr console installed.

3. Double click the MDT Installation file. 4. On the MDT Splash Screen click Next. 5. Select location where MDT will install installation files. I will place mine on F:\Program

Files\Microsoft Deployment Tools\ 6. Click Next 7. Click Next on Customer Experience Improvement Program. 8. Click Install 9. Click Finish 10. Go to your Apps menu (I am using Windows Server 2012 R2) 11. Click Configure ConfigMgr Integration in the MDT Section. 12. On the Options Window, verify that the bullet "Install the MDT extensions for Configuration

Manager" is selected. Verify that there are checks in the two boxes in that section.

http://www.microsoft.com/en-us/download/details.aspx?id=40796

13. Verify that your FQDN for your ConfigMgr Server is in the Site Server Name field. My site server I will enter is lab-sccm.lab.cloud

14. Verify that your correct Site code is entered. My site code I have selected is LAB. 15. Click Next. 16. Click Finish after successful install.

At this point you have installed MDT 2013. I suggest looking at my future blog on how to use MDT 2013 but for now you can Bing and find plenty of resources on MDT 2013. -----------------------------------------------------------------------------------------------------------------------------------------

Food for thought System Center Configuration Manager isn't something that I suggest you just jump into and deploy. If it isn't done correctly you will be miserable and your experience with the product will be a very bad one. If you have the budget you should seriously consider hiring a consultant to implement your ConfigMgr solution. Yes, I am going to plug the company I work for here. We here at Business and Decision have a good number of consultants including myself that can get the job done for you no matter the size of your organization. We work with public and private companies large and small. If you are seriously looking into ConfigMgr we can also look at getting you on a program that can be paid by Microsoft to start a POC for your company. Even if you don't pick my company I suggest that you get a consult that knows System Center in to design, plan, and implement your solution. As well as give you some hands on training along the way. Give me a shout if you would like to find out more about Business & Decisions solutions.

http://www.businessdecision.us/

deploying system center 2012 r2 configuration manager with multiple ... · deploying system center...

Documents