Microsoft System Center Configuration Manager 2007 – Software Distribution “Theory”

Let’s start with the basics – What is it?

Software distribution is a way of automating and in general making your life as a system admin easier. Do you really want to go round 100 client machines – USB Key in hand installing a new program? – I for one would rather click “deploy” and those 100 machines have the new software package deployed to them.

There’s three main types – MSIEXEDIFF

This means any program you can run can be distributed!

As I’m sure many of you will have been involved with various installations over the years, MSI installation is generally the easiest. Especially if you deploy via GPO or logon script. Most MSI files have all the relevant switches included (switches include making the installation run silently – so the user doesn’t notice).

EXE files (Executable files) – tend to be more difficult mainly due to the fact some are almost legacy built which means they don’t include the various command line switches required to hide the installation from the user (or to not request a reboot after installation).

DIFF or difference are for those custom deployments. If you take a system state view before and after installation you can then see all those changes (reg key changes) etc which have been made during the installation. You will then package all those changes and deploy. You can see this is a more complex and usually the most difficult way of deploying packages.

The image below is a good reference point. I’ve tried to define the three main sections (Package which contains the program), the Advertisement and the Collection. (We will cover these later don’t worry). I’ve tried to make them as simple as possible – to try and break them down in to the below questions:

What – What do I want to deploy package?

When – When do I want to deploy the package?

Who – Who do I want to deploy the package to?

It’s the combination of these three items which make the change event – change event being new software installed.

An example using the above could be:

I want to deploy CuteFTP (what) during the day at 2PM (when) to only those machine’s with 2GB ram running windows vista (who).

Below we can see a spectrum of the different packages.

MSI – most install switches are contained within. Don’t require user input and tend to be the easiest option.

EXE – may or may not have the relevant switches – BUT can be very limited.

DIFF – Multi step process – Series of reg keys to see which are copied and which are not. Overall a difficult method.

One website you will find come in VERY handy is

This website tends to have the most popular packages listed along with all their command line switches (for example VLC player).

Keep in mind, within SCCM 2007 – packages DON’T have to just be software installations. Packages can be anything…deployment of a reg key, deployment of files you name it you can do it.

The benefit over (say GPO deployments) is you can keep track and can see via the SCCM console exactly which machines you’ve deployed to have received the package successfully and those which have failed. This saves you having to go over and over, checking gpresult and trying to find out why it’s not installed for certain users/machines.

Microsoft System Center Configuration Manager 2007 – Reports & Dashboards

Well I hope you’ve got your SQL hat’s on….as we will be briefly looking at SQL queries in this blog, as well as reporting and reporting dashboards

Before we go any further we need to install the reporting server component

Right click > New Roles

Select Next

We now want to select “reporting point”

Leave the default values as is (but make a note of the URL below)

Select Next, and then Finish

Now we can take a look at the reports which are installed by default. You will see there are around 330 pre-installed reports, covering pretty much every basic report you will need.

We are going to pick one (in this example number 239) software recently used

Right click > Run and it will ask you to select a computer. In this example I’ll use MRPCXP02

Select Display and you can see those executable files which have been most recently run

If you select the little arrow (before the computer name) it will open a new window where you can drill right down in to the computer and find out all sorts of information regarding the setup / hardware / software.

We will now create a new report to show us all those clients with Microsoft Word installed. Right click > New Report

Fill out a name and the category we will be using is Software – files.

Click “Edit SQL Statement”

This brings us to the SQL part of this blog. Now depending on how you are with programming languages/SQL language the SQL Statement may or may not make much sense to you.

Basically it’s saying in this report we will select ALL entries from the v_R-System table where the value Netbios_Name0=Computername

I’ll admit, it’s not easy to see what you are doing here, and what are all those V_ entries?

Well they are different views. Let me explain more….If we open up SQL management Studio and drill down in to the database, you will if we right click views > new view > and select the views tab

The view we will be dealing mostly with (and which most reports link to in some way) is the v_R_System view which contains all the system information for all those end points with agents on them.

Click Add.

We’ve now added the view to our workspace. (if you’ve used access before this again may seem familiar).

If we look through the System View we will find some common values we will want to use. In this example we will list the username and computer name

At the very top of the view you will notice the Resource ID column. This is a common column throughout the views, and allows us to link these views together to produce reports which query multiple views.

If we right click execute SQL query we will see the below output

Simply showing us the last logged on user to the clients. Fairly straight forward. Now let’s add another view to this.

Right click > add Table

Select the views tab again, and this time select v_GS_SoftwareFile

This is the view which has all the information regarding software file information

What we are now going to do is link the two ResourceID columns to create a link between the two tables

In the SQL output window you can see the SQL code is getting pretty complicated now

From the v_GS_SoftwareFile table select FileName, FileVersion and FilePath and in the filter for FileName enter: =winword.exe

If we execute the SQL statement now we see the below

It’s also given us the complex SQL code we require to produce this. Here’s where doing it this way (via SQL studio) helps make our lives a little easier. We can link tables, select the values we want then simply copy and paste the output in to SCCM.

Paste the output in to the SQL Statement field, and we now have a working SQL statement (which we know will work) as oppose to trying to either:

  1. Type it out for ourselves
  2. Use SCCM to try and create the statement

We can specify how often we wish this report to update

If we wish to link this report to another report, or computer

In this example we will link this to computer details. Computer Name Column (simply means where you want that little arrow to be displayed) which opens up additional information for the client

Leave the security settings as is

Finally click finish to create the report

There we have it, our own report.

Right click > Run and you will see the report produces exactly what we want. Very handy if you are ever asked “can you show me all machines with XP or 512mb ram” etc..

Now remember I said to make a note of that URL when we installed the reporting component?

Well let’s browse to that URL:

You will see all the reports are available for users to run. This means you don’t need to give user’s access to the SCCM MMC in order to view reports. (Later on we will cover security/allowing certain groups access to certain reports)

The user can then find the newly create report and run it


Again click the little shortcut arrow to bring up additional details

That’s reports covered off, which is handy, but what about those situations where it would be nice to have say 4 reports open at once?

This is why we create a dashboard. Within the dashboard we can specify many reports to view allowing us easy access to view information at a single glance.

By default there are no dashboards, so let’s create one

Name the dashboard, you can also choose to limit the cell height if required

Select next, and this is where we will define what information is shown within the dashboard.

In this example I only really need two columns one will be displayed on the right one on the left. So change the value in Rows from 2 to 1

Click the first line and select the properties button (hand with a bit of paper under it)

Find the report you wish to use

Select the second entry and click properties to find the second report you wish to use

In this example I’m showing all XP systems with word installed, as well as all clients operating systems and which services packs are installed

Click finish

We can now see our newly created dashboard

Let’s run the dashboard and see what’s displayed

As you can see, on the left we have which XP systems have word installed, and on the right all those clients which have an operating system installed and which service pack

Select the little arrow to view more information (I’ve clicked the arrow next to Microsoft Windows XP Professional). This shows us both MRPCXP02/03 have XP SP3 installed

And there we go, another section covered off. I think most people will find this useful and will certainly use reports and dashboards in their own environment mainly for time saving.

“I wonder which machines out there have 1GB ram”. Now all it takes is a few clicks and you know…

Microsoft System Center Configuration Manager 2007 – Queries & Query Based Collections

Why is this useful?

Well say you have 100 PC’s in your environment. Some are XP, some are Vista, Some have office 2007, some office 2003. If you want to deploy updates or software you may only want to target (for example) those Vista machines with office 2007. Being able to use a query based collection means we can specifically target those machines.

Let’s start by taking a look at the built in queries.

You will notice each one of these queries matches up to an existing collection (as mentioned in the previous blog).

What we are going to do is create our own, to show us only those XP systems with Microsoft Word installed on them.

Firstly right click Queries and select new > query

I’ll name the query “All XP systems with Word Installed”.

For Object type select system resource and then select “Edit Query Statement”

We will be selecting a simple value so click select

From attribute class select “software files” and attribute select file name. Click OK to return to the above window

Now we are back on the new query page select “value”.

You will see there are already hundreds of file names populated from the inventory’s which have already been run against the systems. We need to find winword.exe from the list

Click OK to the above, and we now have a fairly simple criteria for the query. Select OK

Now we’ve create our new query, right click properties and from here we can see the query statement which gets run

If you are familiar with SQL (and the SQL language) then you will start to see similarities, as guess what…..the SCCM language is pretty similar to SQL.

Now let’s RUN the query we’ve just created and we should see the below.

Here we can see the only system with winword.exe on it is MRPCXP02.

This gives us a quick way to find out information, but what about if we want to deploy software to this machine? well this is where we have to use a query based collection.

What I’m going to do in this example, as we already have an XP collection, is simply create a “sub collection” or child collection contained within the All Windows XP Systems collection.

Right click > New > Collection

Name the new collection

On the next window select the little yellow cylinder icon, and here we find ourselves on the query rule page we have just looked at.

Fill out the information as we did previously, and select “limit to collection” (and make sure you select All Windows XP Systems”

Click OK to return to the new collection wizard, and we can now see there is a new membership rule.

click Next and Finish

and we’ve now created our first query based collection. IF you refresh the view you will see within “All Windows XP Systems” we now have a new entry

If we go in to this new collection we can now see the MRPCXP02, and as we have saved this collection (come later blogs) when I show you software distribution, this will now enable us to push software to just machines which match this criteria.

Microsoft System Center Configuration Manager 2007 – Inventory & Basic Collections

We now have our agents deployed to our end points, it’s now time to see exactly what information we can pull from the end points.

Having briefly skimmed over some of the below in previous blogs, I’m going to include the below with a little more detail:

  • Inventory client Agents – hardware/software inventory’s etc.
  • Viewing Inventory – what kinds of data can we view?
  • Creating Collections – to help us “narrow down” and refine what views we can see
  • MIF and MOF files – Allows us to customise the data pulled from clients
  • Predefined Collection – We can use it to produce reports/or patch/deploy to specific collections
  • Direct Membership Collections – Easy/Basic Collection’s (i.e the built in ones) which are installed by default.

Let’s start by taking a look at the hardware inventory client (as shown in the previous blog).

More importantly, let’s look at the MIF tab. Here we can see we have NOIDMIF and IDMIF. Well what is a MIF file? – Quite simply it’s a text based file which helps “extend” the amount of data collected.

NOIDMIF – this type is used to amend to existing records (adding additional information). If we take a look at a NOMIF file we can see it’s fairly easy to understand what is being collected/pulled. Because it is an EXISTING class there is already an ID, hence NO ID MIF (ID is not required).

Example of a NOIDMIF file

IDMIF – If there is no existing class, we can create one from scratch, which means we CREATE an ID.

Example of an IDMIF file

Once you have created your NOIDMIF or IDMIF you need to deploy this text file to each computer you wish to pull the information from. (We will cover deploying files in a later blog).

MOF files

You would generally use MOF files (as they are a lot easier to read/understand) and MOST objects you will ever need to audit can be adjusted by a simple (true or false) against the text file.

The two MOF file’s can be found here:

If we take a look at a sample MOF file you can see quite easily what is currently being collected and what values are not. (BuildNumber is currently being collected, but those other values are not).

If we look at another example of a MOF file (you can see in this example) it’s a lot more complex in that you are now choosing specific registry values. Which quite obviously shows you just how precise and exactly how far you can inventory client machines.

Unlike MIF files, once the MOF files are updated, they automatically let the client know there is a newer version available and will distribute the updated file.

Resource Explorer

Let’s take a brief look at the resource explorer, select any of the machines you have installed an agent on and right click > start > resource explorer

From here we can see various information about both the hardware and software of the computer


As mentioned above there are a number of basic collections which come with SCCM (these are pre-defined). We can see the all systems collection simply shows us every computer which has been discovered.

Whereas the XP collection (does as it suggests) and shows us those computers with XP installed

How do these collections work? Well they run off queries…


If you expand the queries group you will see each query matches to a collection. Pretty self-explanatory really.

Let’s flick back to the all systems and take a look at the query which is being run.

Right click on All Systems Collection, and select the Membership Rules tab. Here we can see it’s using the All systems query.

click the button next to the red X to open the query

click on edit query statement and if we view the criteria tab, there is no criteria as it’s simply showing all resources.

General shows us those attributes it is searching for

and if we view the criteria tab, there is no criteria as it’s simply showing all resources.

If we move to the XP collection and check out the criteria we can see it’s specifying only those machines with workstation 5.1 installed.

Of course you can change this to 6, or 6.5 for later versions. But rather than play about with the default options it would be better to create your own

Microsoft System Center Configuration Manager 2007 – Deploying Agents

Now we’ve scanned our network for resources, and we know what’s out there, it’s now time to start deploying the SCCM agent to our end points in order for us to be able to manage them.

You can deploy and install the agent in a number of different ways. We are going to start to cover some of these off in this next blog. As a general over view this blog will cover:

  • Deploying via Boundaries (AD Site/IP Subnet)
  • Client Approved & Auto Approved Installations
  • Client Installation Methods
    • Client Agents (10 different types)
    • Client Push Installation
  • A Look at the SCCM Client

Why would you want to deploy only within certain site boundaries? Well if you have a large organisation, you may have many different domains/subnet’s, and in some cases Team A may be responsible for Subnet 1 and 2, and Team B responsible for Subnet 3 and 4. This way both teams can make sure they are only managing end points on their own subnets/AD Domain.

Installation Methods

As listed below there are a number of ways we can actually install the SCCM agent on to our end points.

  • Client Push – Easiest method
  • Software update point (WSUS) – Can be included to auto install as part of the WSUS update
  • GPO – Installation via a controlled GPO (via the .msi)
  • Manual – Grab the CD and go round each workstation/Visit each workstation and run the .exe
  • Login Script – Having a simple script to call the MSI or EXE file (NOTE this requires the account to have administrative rights)
  • Software Distribution – If Microsoft releases an updated SCCM Agent, you can push the updated agent out to those end points with agents already on them.
  • Imaging – Either via Ghost or Windows Deployment Services. It could be part of a “golden” image.

You will notice if you browse to your SCCM Server using it’s UNC path, you can find the location of the .msi (If you are using the GPO method)

For all other installations the .exe file is located here:

Client Agents

Now we know how to install the agents, it would make sense to understand what type of agents are available

  • Hardware Inventory
  • Software Inventory
  • Advertise Programs
  • Computer Client
  • DCM (Desired Configuration Manager)
  • Mobile Device
  • Remote Tools
  • NAP (Network Access Protection)
  • Software Metering
  • Software Updates

I guess that’s enough of the “talking” done! Let’s fire up the SCCM console so I can show you what I’ve just rambled on about….

*NOTE* as you will see going forward I have rebuilt an entire new Virtual LAB using Server 2003 and Windows XP. A couple of reasons:

  • The Exam focuses on 2003 environment/XP Environment
  • 2003/XP take a lot less system resources (currently running it all off my desktop)
  • The Windows 7 VM’s I used were SP1 which 2007 SP2 doesn’t support (you need to download a hotfix which for the last 3 days has been unavailable on Microsoft’s site!) – So rather than wait around for it, it was quicker to build a new environment!

Fire up the SCCM console, and first I’m going to create a new boundary. I’m basing this on an AD site (although you can specify subnets/or single IP address) as shown below

Ideally this is the information you want to set before you start deploying, otherwise if there are multiple subnet’s, and you only need to deploy to one subnet you really don’t want to be discovering and pushing client installations to those end points sitting outside of your control.

Other settings we should check can be found under right click > properties

I’m leaving the default approval settings as is.

You can chose to encrypt the information sent between agent and server if you are particularly concerned, but just be aware of the additional resources this will use.

We also need to be aware of what happens if there are conflicting records. E.G a machine is offline for a period of time, or is rebuilt with the same machine name. I’m going to leave the setting to auto create a new record.

Now we’ve covered off some of the basics, we can look at the types of client agents (as mentioned above). You only really want to enable the useful ones, otherwise you will be wasting system resources).

If we take a look at the types of agent available to us we can see:

Hardware and software inventory are both pretty self-explanatory, and are enabled by default.

We will cover IDMIF and NOIDMF files later on

Within the software inventory settings, you can see we have the ability to include/exclude files from the inventory, (obviously if you change this to *.dll) this is going to give you a list of every single DLL file which is going to grow your database considerably!

File collections is also one to be careful of. This will “pull” the file’s from the client machines. E.G if you wish to collect the file winword.exe (Microsoft Word) It will collect this file from the client machine in to the database. Not only does this affect your database size, but consider the network utilisation if you are pulling this file from all your clients.

Inventory Names – Listed the many manufacture names out there.

Advertised Programs – Allows you to deploy software to end points or to target users to deploy software to. We will cover this later on but I’ll enable it for now.

Computer client Agent – this is the core “component”. The computer agent. Without this we can’t do a lot! I’ve set the service account to use the administrator account.

We can also customize the messages displayed to the end user if we are performing maintenance.

We can also use BITS to decide if we wish to set the level of network usage. (BITS is used to prioritise/throttle network traffic).

We can finally chose how long to display notices for before the machine is restarted (if required)

DCM – We will cover this in future blogs

Mobile – As above

Remote Tools – As above but allows for remote control of the user’s desktop via Remote assistance or Remote Desktop.

NAP – To be covered later

Software Metering – Also to be covered later

Software Updates – Again to be covered later

Deploying Clients

Finally we get hands on with deploying clients to our organisation. If we have a quick check of the discovered end points we can see it has populated all the machines in our environment.

We will now also enable the client agent installation. You will see two options, the main one I will be using is client push. (Software update client point installation is used if you are installing or want the agents to be installed via WSUS) Back to client installation – Right click > Properties, and enable this.  I’ve added the SCCM Admin account here as well as the credentials it will use to install the agent with.

The Site code is MR1 by default (as this is what we called out SCCM site).

Right click the PC you wish to install the agent to and select install client. This brings up the agent install wizard (fairly straight forward), I’ve selected all the options for now, click finish.

You will see when an agent is being installed the following process running on the machine (ccmsetup.exe), once complete you will notice a further task ccmexec.exe – this is the process which run’s and collect’s the requested agent information (hardware/software inventory for example).

Give this time to run and when we refresh the console we can now see the agent has been installed on to the selected endpoints.

From a client’s point of view, they will see the following appear in the control panel.

And there we have it, basic SCCM agent deployment covered…


Microsoft System Center Configuration Manager 2007 – Discovery Resources

Now that we’ve installed SCCM, it’s time to start discovering resources.

Before I jump straight in, I’m going to cover off some of those discovery methods, as well as the configuration of them.

In this blog we will be looking at:

  • Discovery
  • Inventory
  • The DDR (Data Discover Record)
  • Types of Discover (the 6 types)
  • Configuring Discovery
  • Tailoring discovery

Discovery / Inventory

What’s the difference? Surely both do the same?. Well nope..

Before you can inventory a (for example PC), you first need to discover that PC and deploy an agent to it.

Discovery is used for FINDING those end points in your network, and inventory is used to then retrieve information from those end points once they have been discovered.

DDR (Data Discovery Record)

The DDR contains information about discovered resources. It’s stored in a folder called “\inbox\” – BUT it’s not stored there for long, once it’s polled by the database the record is removed.

This folder can be found here: C:\Program Files (x86)\Microsoft Configuration Manager\inboxes\

Think of it as a simple inbox system. If a new record is created it is located in the inbox. Once the database polls this entry it’s removed (sent to the database), and no longer resides there.

Types of discovery

It may surprise you to learn there are six types of discovery (I certainly didn’t think there would be that many)…Those types are:

  • AD System – systems within AD (computers/servers)
  • AD User – users within AD
  • AD System Group – OU’s, Global Groups
  • AD Security Groups – AD Security Groups
  • Network – Printers, Routers, Switches etc
  • Heartbeat – If the device does not respond with a heartbeat after (say 30 days) SCCM considers it removed from the network and no longer exists.

Configuring Discovery

Now we’ve covered some of the basics, let’s fire up the SCCM management console and actually configure the discovery methods.

Expand your site management tree, and click on discovery methods. On the right hand side you’ll see the 6 discovery methods mentioned above.

I’m going to start with AD System Discovery. Seeing as AD is the backbone, and already has all our computer accounts it would make sense to start here!

right click > properties

You’ll see it is not currently enabled, so tick the box to enable this, and then click on the little sun/start shaped icon.

I am going to be including the local domain and I always want to search groups, so tick the box next to “include groups”

When you click OK it will ask you where to search. You can chose an OU, but for now i’m selecting the entire domain

It will then populate the pane below

If we move on to the polling schedule tab you can see it is set to run every day. I’ve also ticked the box next to “Run discovery as soon as possible”

Finally we have the active directory attribute tab. Here you can choose custom fields to be pulled from AD.

If you are not sure what the attribute name is hope back in to ADSI edit, and have a look for yourself

In this example I’m going to add the lastlogoff and lastlogon attributes.

you will see both now appear in the list. Click apply/OK to start the discovery

If we right click > properties on the AD user discovery you can see it’s exactly the same options but this time for user accounts. Depending on your environment you may or may not require software to be pushed to users but rather to machines (as an example). For now i’m not going to enable this as I have no need.

AD Security Groups, again has the same options (with exception of the attributes tab)

AD System Group is exactly the same as the above

Only the one option in the heartbeat discovery properties, it’s fairly straight forward. How long do you want the interval to be

Now lets move on to network discovery. Here we have multiple tabs and on the first tab we have multiple options explained below

  • Topology – IP and basic information
  • Topology and client – additional information about WHAT is on the end of it (i.e is it a router, a printer etc)
  • Topology, client and client operating system – as suggested, even more information about the client (OS it’s running)

Moving on to the subnets tab, here you can specify subnets to “scan”

The domains is self explanatory, if you wish to scan a certain domain, enter the domain information to scan for devices within the domain

finally (for our purposes) the SNMP tab. If you use SNMP, and have a community name you can enter them in here

Well that was a fairly short(ish) and sweet introduction to discovering end points. Obviously everyone’s environment will be different but for the purposes of my home lab i’m only really covering off what I need to know for the exam for now.

Microsoft System Center Configuration Manager 2007 – Part-1

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: (Both Forest and Domain functional level 2008 R2)
  • MRDC02 – Domain Controller – (Windows Server 2008 R2)
  • MRSCCM01 – SCCM 2007 Server – (Windows Server 2008 R2)
  • MRPC01 – End User PC01 – (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.

Client Site System
Processor 233/300MHz 733Mhz/2GHz (Single Role/Multiple Roles)
RAM 256Min / 385 Recommended 256mb/1GB (Single Role/Multiple Roles)
Disk Space 350MB 5GB/15GB (Single Role/Multiple Roles)
Operating System 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!)

Schema Update

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… 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….

%d bloggers like this: