Well here we are again, another exam to study for which means a whole new load of topics to revise!
In terms of the 70-400, I have now passed the exam BUT I must admit I haven’t done any of the write up’s yet purely due to a time issue, so with the 70-401 I’m going to do my best to try and keep it updated as possible!
Anyway enough about that and on with this “new” topic.
System Center Configuration Manager (or SCCM as i’ll be referring to it), essentially allows the configuration and management of end points with agents installed on them. In relation to SCOM (which does the monitoring) SCCM is used for the configuring.
Before we go any further, it’s best to get your home lab built. In this example I am going to be using three virtual machines, all located in the same Active Directory Forest and single domain.
- Domain: Riccioni.ad (Both Forest and Domain functional level 2008 R2)
- MRDC02 – Domain Controller – 192.168.5.30 (Windows Server 2008 R2)
- MRSCCM01 – SCCM 2007 Server – 192.168.5.31 (Windows Server 2008 R2)
- MRPC01 – End User PC01 – 192.168.5.40 (Windows 7 Enterprise SP1)
You may wonder why the DC is called MRDC02, that’s because MRDC01 sit’s on my ESXi host, and for the following blogs i’m simply running the VM’s off my desktop computer.
With that out the way lets gone on with finding out about SCCM 2007.
Gone are the days of walking round each machine in your network with a CD (or floppy disks!) installing software.
Now in a lot of cases, administrators will install software via GPO which references a network shares with stored ISO’s or Executable’s (EXEs) or via logon scripts.
Most companies also have standard “deploy-able” images which contain’s (a usually) up to date image of (for example the Windows 7 Operating System) with all the latest relevant patches, commonly used software, and customisation’s.
To be honest this is nothing new, many people have been doing this for year as a manual process so why bother with SCCM at all?
Well SCCM provides you with a more centrally manageable ”overview” of what is being deployed, installed, controlled within your network.
Features such as:
- patch management
- software distribution
- operating system deployment
- network access protection
- hardware and software inventory
To name a few.
If you are the sole administrator in charge of 100 end points, then you will be grateful for SCCM!
I can’t really go in to too much more detail as like you i’m only just touching the surface with SCCM, and i’m hoping the next few blogs will help us all to understand SCCM in greater depth.
Here we are for Part 2 of the SCCM 2007 Series of Blogs I’m writing to help me along the track of revising and (hopefully) passing the exam at the end of it (the 70-401).
I guess the fact I never got round to writing a “part 2” for SCOM 2007, already bodes well for the SCCM 2007 Series!
Before we start installing and playing, I thought I’d take some time out to just try and cover off some more of the basics.
For example what components actually make SCCM?
Well if we look at the MAIN components:
- The SCCM Site – The SCCM Site as a whole. E.G an AD Site or IP Subnet.
- The Site Server – Essential to ANY SCCM Site. You need at least ONE Site Server. The
- The Site System – If you find your SCCM Site Server Is struggling with the load from servicing all your end points, you can deploy site system servers to help spread the load
- Site Hierarchy – Central Site, Primary site and Secondary sites.
- The Client – One of the most important parts! The client (SCCM agent) must be installed on the end point.
- The Management Console – Where we will spend most of our time.
I’ve only covered them off briefly, as at the moment that’s all I know! As I progress I’ll be able to expand further in future blogs.
Let’s also look at some of the Site System Roles (As mentioned above).
- Site Server – The Key/Main distribution point. Imagine this as a file share for example where clients go to, in order to get their file (source code)
- Management Point – Used for the communicating of policy’s and system inventory’s
- Reporting Point – As you may have guess…Used for reporting and producing web based queries/outputs
- Site Locator Point – Useful if you are unable to extend your AD Schema when installing SCCM. The Site locator point will help agents “find” the SCCM Server.
- Database Server – Again it’s in the name. Where all the information gets stored.
OPTIONAL system roles
- Device Management Point – Used for managing individual devices
- PXE Service Point – IF you have this in your environment then you can push out operating systems via SCCM using Win PE (Windows Pre-installation Environment)
- Software Update Point – Integration with WSUS (Windows System Update Services)
- System Health Validator (SHV) – Mainly used to integrate with NAP (Network Access Protection) for validating the health of agents before being “allowed” on to the production network.
- State Migration – Used during Operating System deployments
Just to expand on something I touched on earlier. Site Hierarchy. If we look at the exam below, you can see we have multiple sites.
At the very top you can see our central SCCM Server (which is either the database server or has a database server “attached” to it) A couple of Primary sites (again which have databases attached), and finally some secondary sites (which don’t have a database attached to them).
The below diagram should give you a better understanding of HOW a SCCM Site Hierarchy could look, as well as hopefully below explaining the difference between each:
- Central Site – typically has no parent site, but has child sites and collects all of their client information to provide centralised management and reporting.
- Primary Sites – A primary site stores SCCM 2007 data for itself and all the sites beneath it in a SQL Server database.
- Secondary Site – A secondary site has no SCCM 2007 site database. It is attached to and reports to a primary site.
In the example below, In order for Secondary Site 2 to “retrieve” new information, the data would not flow from Central Site 1, but would flow UP from Primary Site 1, via Central Site 1. (as shown with the data flow arrow)
Finally I’m going to cover off some of the “new features” in SCCM 2007 (compared to previous versions).
- DCM (Desire Configuration Manager) – For example you can specify the “desired” level of config you wish to use (e.g a certain reg key MUST be a certain way).
- NAP (Network Access Protection) – Used to help keep those end points which are not fully up to date (either AV or OS patched) off the production network
- WOL (Wake On Lan) – Allows you to send “a magic packet” to the LAN port to “power on” the end point
- BDP (Branch Distribution Point) – If you have a very small remote office, with no server’s and a very “flaky” WAN link you can make one of the workstations a distribution point. This means the other end points talk directly to this machine instead of over the WAN and back to your main SCCM server.
Time to get hands on now and prepare our server for installing SCCM 2007 R2. Now before we start I am going to run through some of the hardware/software requirements and also the prerequisites. (I’ll also include extending the AD Schema).
Firstly let’s cover off hardware requirements (both client and server).
If we look at the table below you can start to get an idea of what sort of specification is required. This is minimum/recommended specification.
||733Mhz/2GHz (Single Role/Multiple Roles)
||256Min / 385 Recommended
||256mb/1GB (Single Role/Multiple Roles)
||5GB/15GB (Single Role/Multiple Roles)
||Windows 2000 SP4 and above
||Windows Server 2003 SP1 and above
This means operating systems like: Windows 95, Windows 98, XP Home, XP Media Center, Vista Starter, Vista Home, XP Pro (Below SP2), NT Server, Pocket PC, Win CE 3.0 are all not supported.
From a server point of view we will require IIS 6.0 or above, BITS 2.0, NLB (if using NLB), IE 5.0 or above. It is also worth noting SHV (System Health Validator) is only supported on Windows 2008 and above.
More common software which is required: MMC 3.0 and above, .NET framework 2.0 and above, SQL Server 2005 SP2 and above. *NOTE* You CANNOT use SQL Express. You will need to use a version like standard or express.
As you can see from the above, before we can even start installing we need to cover off those requirements so I’m going to now go and install the required roles on my SCCM server and also install Server SQL 2008 R2. (Once done return to here and carry on!)
Like most “major” Microsoft products (SCOM/Exchange) they require the schema to be modified to included additional attributes specific for SCCM. This only needs to be done once per forest, and if you have multiple Domain Controllers just make sure the changes have replicated between all the DC’s.
Microsoft give us two ways to update the schema, a simple file called “extadsch” which does it all for us, or via an LDF file. The LDF file can be found here: (C:\ConfigMgr\ConfigMgr07SP2Eval_RTM_ENU\SMSSETUP\BIN\I386 – In this case I’m installing it from the extracted CD on to the C:\ of the server your location maybe different)
If you open the LDF file up in notepad you can see step by step exactly what it is doing. Please note if you are going to use this method you will need to change the values of the LDF file, at present you will see multiple entries for DC=X you need to update this to suit your own environment. For this example it would be to replace DC=X with DC=riccioni, DC=ad
To run the command you would use:
- Ldifde – I –f configmar_ad_schema.ldf –v –j c:\schemalog.txt (I’ve included a log file so we can see any errors/issues during it running)
However I am going to use the extadsch.exe method to update the schema.
Browse to the location (C:\ConfigMgr\ConfigMgr07SP2Eval_RTM_ENU\SMSSETUP\BIN\I386 – again this depends on the location of the installation media)
Open up a command line and browse to that location and then run the .exe application
You are left wondering has this run, has it failed? Well if you browse to c:\extadsch.log we can check the status and see if it has failed anywhere.
Luckily for us, it’s run through correctly!
We now need to open up the tool called ADSIEDIT, (Start > Admin Tools > ADSI Edit), as we need to add an additional container for SCCM to use (this is not automatically created for new installs) IF however you are upgrading from previous version the container will already be there).
Browse to > Domain > System > and right click, create a new object container called “System Management”.
Once this is done, right click the properties and select security. We need to give the correct permission to this server in order for this sever to populate this newly created container.
Make sure you select Object types and tick “computers”
We will want to apply permissions to all child objects as well so select “advanced”
Select the computer object and click edit
then select “This object and all descendant objects”
click OK to come out of this and click apply/OK to apply the changes then exit ASDI Edit.
Once this step is done we can finally start with the SCCM installation. First we want to run pre-requisites checker, (as with all things Microsoft there are always MANY pre-req’s!)
Enter the requested information and then click Run. (I’ve yet to install anything which has not come back with at least two errors and multiple warnings…..so let’s see what awaits us)
And there we go, it’s failed on a few and has given me a warning regarding the service pack of WSUS.
If you double click on error/warning it gives you a description in the bottom box.
Once I’d corrected these I re-ran the pre-req checker and I can live with the warning it gives regarding WSUS, which means I’m happy to continue with the installation.
It’s a fairly straight forward next next next type installation as you’ll see below, but let’s go through it step by step.
Select Next, and as this is the first installation we will be installing a new configuration manager site server.
Accept the usual terms and agreements
Like any installation we want to chose custom settings, as we want to be able to change the values to suit our environment.
We will be installing a Primary site
It’s up to you if you wish to send data to Microsoft, I personally never do.
Even though i’m installing an evaluation from Microsoft (which comes with pre-populated key), I’ve decided to blank it out just to save any issues…
chose your installation location
This is important. You cannot have duplicate site codes within your SCCM Site. It is also a “pain in the backside” to change, so think carefully about your naming convention before deploying SCCM in your environment.
Now, as I currently don’t have a fully working PKI infrastructure, I’ll be running in mixed mode. Native Mode allows those of you with full PKI infrastructure’s to take advantage of managing agents over the internet.
I’ve chosen to install all options.
I left the default site database name, although you can change this.
The next steps I am just going to accept the defaults
If we had selected Native mode, we would be able to specify the HTTPS settings, but as we are running in mixed mode we will simply be using port 80.
Since it’s initial release there will be a number of updates available, I’m going to download all of these to c:\SCCMUPDATES
Great, 89 new updates…..I’m going to leave this for a while and come back to it later!
Ok so we’ve now downloaded all the prerequisite components, we should be just about there.
A quick overview before installation allows us to just confirm/check we are happy with the proposed installation.
Once happy, select next and SCCM will begin to install
We are finally there!
SCCM is now installed, if you go to the start menu you will see the new SCCM 2007 folder group.
I’m going to launch ConfigMgr Console, to get a first look at the management console.
As you can see, at the time of installation there is now R3 available (we’ve just installed R2). But lets not worry about that!. Instead lets focus on the pane to the left.
I’ve expanded the major components, and as you can see there are a fair few options here, which hopefully we can cover off in the coming blogs!
And that’s it for now….