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\DDM.box” – 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\ddm.box

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

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.

Software

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

How to Simulated 3 site MPLS with Remote Site-to-site Branch Office


No messing about today, we are going straight in with a more advanced lab! (and once which is more than likely familiar to you)

Now we all know how to create simple site to site VPN’s between two cisco devices (easy right? especially if you’ve read my previous blogs…), but what about say requiring access to multiple LANS, topped off with a sprinkle of IPSec tunnel terminating on a non-cisco device? Well that’s what I’m going to try and attempt here.

As you can see from the above network diagram, we are effectively  simulating an “MPLS CLOUD” at it’s simplest level as well as the “PUBLIC INTERNET”.

There are 3 MPLS sites, SITE A, SITE B and SITE C.

We then have a remote site, which will connect to MPLS Site C via the public internet using a VPN Tunnel.

The idea here is to allow the Remote site, access to all three MPLS LAN’s.

First I’m going to configure up the 3x 1841’s SITEA, SITEB and the MPLS Cloud.

If you are not familiar with the serial interfaces, then don’t worry too much. They are very similar to ethernet interfaces, you just need to specify a few addtional options (e.g clock speed of the interface). I’m not going to cover this now as it’s not relevant, so am going to carry on configuring the routers.

We now need to tell the “MPLSCLOUD” how to get to the various sites

And on with Site A configuration

Moving to Site B

Quick check to make sure Site B can ping the interface Site A connects to, as well as pinging Site A’s MPLS IP

Now lets move over to Site C (ignore the hostname Internet in the first line, that was me typing the wrong name…)

Now lets assign these VLAN’s to switchports (as you have to do on the ASA 5505)

Quickly check we can access the inside interface of Site A… Oh dear. Lets make sure we can get to the MPLS Cloud interface…

So we can hit the cloud router, but not site A.

Best have a look at the routes then make sure they are OK

So it knows how to get to those remote subnets, but what about the MPLS subnets. Right lets add them in then

We also need to add the following line:

This will now let traffic flow between interfaces with the same security level (so inside to MPLS and MPLS to inside)

Now this is done and all the route’s are in lets continue with the configuration, moving on to the “Internet Router”

Make sure you can ping the outside interface of site C

Everything is coming together nicely so far, so lets go ahead and configure up the branch office.

The branch office uses a draytek 2820, and first things first lets make sure we are running the latest firmware.

July 24th 2009. Hummmm there must be some later firmware…off to draytek.com and indeed there is, so now i’ll update

Thats better, May 23rd 2012.

On with configuring the interface which connects to the public internet

And now we need to configure the local lan of the remote site

Everything looks to be OK so far. We can see a connect to the public internet:

And I can also ping the “next hop” after the draytek

Back on to the internet router to make sure I can ping the draytek.

Oh dear, something isn’t right here. Don’t worry to much, much like cisco ASA’s blocking ICMP traffic by default so does our friend the draytek

Lets retry that

That’s much better.

Now time to configure the VPN tunnel on the Draytek, fairly straight forward (for those GUI lovers)

click advanced to enter the phase 1 / phase 2 settings

Now jump back over to site C and configure the VPN tunnel on there.

So thats the VPN tunnel done on this end, lets now try and send some traffic and hopefully the tunnel builds.

Oh dear, this is not good, lets have a look at the logs on the ASA (debug crypto isakmp 7 and debug crypto ipsec 7)

So what we can see here is Phase 1 has completed, but Phase 2 is a no go. It’s saying the ACL does not match Proxy ID’s.

Local proxy 0.0.0.0 / 255.255.255.0

Well it has a point, I’ve not any specified that on the ASA, so lets just check the draytek again

And there it is “remote Network IP”, we need to specify the remote LAN on here so it matches the ASA’s ACL

Now lets pass some traffic…

And looking at the logs, we can see Phase 2 completed (and as above traffic is passing)

Lets just check this on the draytek

We now have a tunnel built, and we can pass traffic from Site C to the remote site and site C to the remote site but what about accessing Site A and B?

Well naturally you would assume on the ASA all you need to do is make this simple change to the ACL:

  • access-list VPN extended permit ip 192.168.10.0 255.255.255.0 192.168.40.0 255.255.255.0 (original ACL)
  • access-list VPN extended permit ip 192.168.20.0 255.255.255.0 192.168.40.0 255.255.255.0 (additional line)
  • access-list VPN extended permit ip 192.168.30.0 255.255.255.0 192.168.40.0 255.255.255.0 (additional line)

Then we move over to the draytek and click the “more” button

And here we specify the remote subnets

Drop the tunnel then wait for it to rebuild, and try to ping across to site A or B….The result? You won’t be able to.

Lets just take a look at the ASA (show crypto ipsec sa)

access-list VPN extended permit ip 192.168.30.0 255.255.255.0 192.168.40.0 255.255.255.0
local ident (addr/mask/prot/port): (192.168.30.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (192.168.40.0/255.255.255.0/0/0)

for some reason the ASA is only showing the first line of the ACL. Not good, this leaves sites A  and B cut off from the remote site.

So what can we do? well luckily for us the remote sites can all be summarised, so 192.168.10.0/24, 192.168.10.20/24 and 192.168.30.0/24 can be summarised as 192.168.0.0 /21 (255.255.224.0)

If we make this change on the ASA as well:

  • access-list VPN extended permit ip 192.168.10.0 255.255.255.0 192.168.40.0 255.255.255.0 (original ACL)
  • access-list VPN extended permit ip 192.168.0.0 255.255.224.0 192.168.40.0 255.255.255.0 (NEW ACL)

Re-build the VPN tunnel by dropping the tunnel and passing traffic, we can now see the following:

Notice next to IPsec it shows 192.168.0.0/255.255.224.0 as oppose to 192.168.30.0/24

This is good news surely? Lets try from the 192.168.30.0/24 (Site C) subnet and see what we can reach

We can hit our default gateway, the laptop on 192.168.10.10 (Site A) and also the laptop on 192.168.40.10 (Site C) (no Site B as I ran out of power to have the 5th router on!)

Lets move over to site A and the 192.168.10.0/24 network and make sure we can get to everything

Again, we can hit the default gateway and the laptops in SITE C and the Remote site.

There we have it then ladies and gentlemen, complete connectivity between 3 MPLS sites and a remote branch office…..

Or do we, well I wasn’t happy having to specify such a wide subnet (just to be able to access SITE A/B/C) (192.168.0.0/21), so I spent a fair amount of time looking into this and trouble shooting.

What I discovered was:

ASA to ASA (multiple remote/local LANS) = OK

Draytek to Draytek (multiple remote/local LANS) = OK

Draytek to ASA (with multiple remote/local LANS) = Fail

After a bit of further head scratching, pulling out of hair, and shouting at the kit I found out that ONLY one pair of IPsec Security Associations (SA’s) can be maintained at anyone time……

If you’ve not already fallen asleep let me explain..

Remote Site (192.168.40.0/24)
|
Internet (IPSEC TUNNEL) ——–PHASE 1 SA OK
|
SITE C (192.168.30.0/24) WITH SITE A & B subnets connected (192.168.10.0/24 & 192.168.20.0/24)

As you can see SITE C has 3 IP subnets behind it. With IPSEC tunnels there needs to be a PAIR (one outgoing, one incoming) of SA’s for each IP Subnet pair.

Eg:
PHASE2 SA’S for example would be as follows:

192.168.40.0/24 —OUTGOING—->192.168.10.0/24
192.168.40.0/24 <—INCOMING—-192.168.10.0/24

192.168.40.0/24 —OUTGOING—->192.168.20.0/24
192.168.4.0/24 <—INCOMING—-192.168.20.0/24

192.168.4.0/24 —OUTGOING—->192.168.30.0/24
192.168.4.0/24 <—INCOMING—-192.168.30.0/24

Communication can only exist between the different IP subnets if these SA “PAIRS” exist for the corresponding subnet pairs.

The Draytek has the limitation of only being able to maintain ONE SA PAIR at a time which has the unwanted affect of NOT being able to communicate to ALL subnets at the SAME time…

Luckily for the purpose’s of this lab I was able to summarise the three subnets in to a larger subnet to get around this issue. But if I had used 192.168.10.0/24 at one site and 172.16.40.0/24 at another site then I’d have been up the creek without a paddle.

As mentioned above this problem only occurs when doing IPSEC VPN between Draytek and CISCO in my test Draytek to Draytek has no problems.

So hopefully this saves you many hours of shouting, head scratching and hair loss! as i’ll be honest until I did this lab I was not aware of that either.

Finally below is the lovely setup I’ve had to live with looking at for the past few days….

How to Multiple VLAN’s, Single DHCP Server, Multiple DHCP Scopes


 

As you can see by the network diagram above, In this next tutorial I’m going to cover off one of the most common sort of setups with SMB’s. Especially with the recent popularity of VOIP phone systems.  I think it’s fair to say most network switches used come straight out the box and straight in to the production environment, with the switch’s default settings. Until that is you wish to install a VOIP system or Guest Wireless. Now you need to make changes, and “section” off the network using VLAN’s.

What we have is:

  • 1x DHCP Server (Windows Server 2008 R2)
  • 2x Cisco 2950 Switches
  • 1x Cisco 1841 Router

The Idea behind it is, currently we have one single VLAN. We need to add another VLAN for a VOIP System going in and this requires Its own DHCP Scope.

  • Scope1 – 192.168.10.0/24 (Default VLAN 1 Range)
  • Scope2 – 10.10.10.0/24 (VLAN 10 Range)

So let’s get in to this….

I’m going to assume you’ve done the basic housework (setting hostname/passwords etc.) on the switches, and jump straight in to configuring them.

On your first switch we want to end up with the following:

  • Switch ports 1-10 (VLAN1) – Default
  • Switch ports 11-20 (VLAN10)
  • Switch port 23 – Link to Router (R1)
  • Switch port 24 – Trunk port to SW2

Technically we don’t need to do anything to ports 1-10 (as they are already members of the default VLAN), the only change I’m going to make here is to configure the ports to use portfast (a feature of STP (Spanning Tree Protocol). Without going in to this in too much detail as STP is a totally different topic, it basically makes the port “active” (Forwarding state) instead of having to wait the 30 seconds for STP to work its magic.

You will also see I’m setting the ports to access ports (again this is a totally different topic and one you will cover in the CCNA).

Now for configuring ports 11-20 I’m going to exactly the same but this time make them members of VLAN 10. There are a few ways to create VLAN’s, the way I’m going to do it is to assign the ports to a member of VLAN 10 and let the VLAN create itself. You could also create the VLAN before, and then move the ports in to the VLAN. If you do it that way you don’t get the information message (like in the below picture) showing you that VLAN 10 doesn’t exist.

I’m now going to create the trunk port (switchport 24) which will be our uplink to SW2

I’m now going to decide which VLAN’s this trunk port will “allow”. In this instance I’m going to allow ALL vlan traffic to pass over this trunk.

I’m now going to move over to switch 2 and configure this. As you’ll see I’ve done it slightly differently, but it still provides the same end result

Finally I’ll configure up the trunk port on SW2

If we do a quick “show vlan brief” you can see which ports are assigned to which VLAN

Now we’ve done this, lets connect SW1 and SW2 up with a cross over cable. Hopefully if the config is correct we should get two green lights appear on both switches.

If we do a “show vlan brief” again, you should notice something is now missing….

That’s right Fa0/24 is now missing. Why? Well now it’s “active” it’s functioning as a trunk port so if we do a “show interfaces trunk”, You will see Fa0/24 is now listed here. We can also see which VLAN’s are allowed to pass through this trunk port.

That’s the switches done for now, so let’s move our attention to the router. We’ve no need for outside access so this router is purely going to be used as the Layer 3 device in this setup. If you are going to have multiple VLAN’s with intervlan routing or single DHCP server with multiple scopes you need a Layer 3 device (be it a router or switch) which knows what to do with Layer 3 traffic. (The OSI layer model is another topic all together, so I am assuming you know the basic’s/differences between Layer 2 and Layer 3 devices). This tutorial is purely for getting you up and running.

On the router, I’m going to be using FastEthernet 0/1 as the inside LAN, this is going to be the default gateway for clients.

As you will see in the below, because we don’t physically have multiple ports for the different VLAN’s what we are going to configure is “sub-interfaces” on the router. We are then going to use the “ip helper” feature so VLAN 10 knows where to forward DHCP packets.

To fully understand this you do need to have a little bit of background on why we do this and how DHCP packets work. Basically when a DHCP client sends a DHCP request packet, it doesn’t have an IP address (obviously) so it uses the all-zeroes address, 0.0.0.0, as the IP source address. It also doesn’t know how to reach the DHCP server, so it uses a general broadcast address, 255.255.255.255, for the destination.

This is where the router (or layer 3 switch) comes in to play. The router must replace the source address with its own IP address, for the interface that received the request. It replaces the destination address with the address specified in the “ip helper-address” command. (So the packet now has a “from” address of 10.10.10.254. This then gets sent to the IP helper Address to which the server then looks at it’s DHCP scopes and matches up 10.10.10.254 with the 10.10.10.0/24 scope, which in turn hands out an IP from this range)

The client device’s MAC address is included in the payload of the original DHCP request packet, so the router doesn’t need to do anything to ensure that the server receives this information.

The DHCP server now has enough information to assign an address from the correct address pool, since it now knows what the originating subnet was for the DHCP request. Simple right!?

Anyway let continue with the configuration of the router, once again I’m going to assume you’ve done the basic housekeeping commands, and proceed to configure the FastEthernet 0/1 interface and sub interface.

You will notice when configuring the sub interface, you specifically tell the sub interface what number vlan it’s meant to be tagging. (ignore the message regarding baby giant frames)

So in the above we have configured FE0/1 with an ip address of 192.168.10.254, and the subinterface with an IP address of: 10.10.10.254, with VLAN 10 tagging.

Finally let’s put the IP helper address in on the sub interface

Right then, now this configuration is done let’s get on to testing it. First I need to make sure I can ping both IP addresses on the router from the Server:

Now we can get on to testing this setup.

I’ve already configured the server with the two DHCP scopes I will be using:

First I’m going to make sure we can get an IP address on default VLAN (so I’ll be connecting in to switchport 1 on SW1 first)

I’m using a standard windows 7 laptop for this called Michael2510p. Now it’s connected run a quick ipconfig to see if it’s picked up an IP address

Everything looks OK from the client side, let’s logon to the server and check the DHCP leases on the server

Everything looks good for the default VLAN. Just to be sure, I’m now going to connect in to switchport 1 on SW2. I’m also going to adjust the DHCP scope so the laptop should now pickup the address 192.168.10.20 (this is just to verify both switches can get an IP lease from the default VLAN)

Let’s connect the laptop backup and see what is issues to the laptop this time.

As you can see the laptop has been assigned the IP we expected, so as far as VLAN 1 is concerned everything looks good.

Right, now i’m going to plug in to port 14 on SW1 (which is a member of VLAN 10) so we should now get an ip address in the 10.10.10.0/24 range

Oh dear, something isn’t right.

So lets troubleshoot what it could be. Maybe it’s the IP Helper address? instead of pointing to 192.168.10.1 lets move it to 10.10.10.254 (the default gateway for VLAN 10), and lets see what happens

Right lets run an ipconfig /renew and test again

Oh dear still not working. So maybe it wasn’t the IP helper address. Well that’s correct, if you think about it, there isn’t actually a DHCP server located at 10.10.10.254 is there? It’s located on 192.168.10.1. So this was never going to fix the problem. So lets put it back to how it was

So what an earth could it be? We know the the uplink between the switches is fine (because we can get an IP address in VLAN1 when plugged in to either switch). This also means the link back to the router is fine for VLAN1.

But hang on a minute what about VLAN10? Lets just rewind a bit, we haven’t actually configured the port on SW1 which connects to the router (switchport 23). So at the moment it’s acting as a normal link (which is why VLAN1) is working, as this is it’s default behaviour. What we need to do is specify that this port is actually a TRUNK port, and then allow (which ever VLAN’s required) to pass.

So lets give that ago

Now lets run ipconfig /renew on the laptop and see what happens….

Success! Lets just verify this on the server

So we now know we can get access to the DHCP server from BOTH Vlans on SW1. But what about SW2? Well lets change the scope to start from 10.10.10.20 and plug in to port 20 (a member of VLAN 10)

Lets run a ipconfig /renew on the laptop again and see what happens

This is now looking a lot better! lets just check on the server

Success!

Well there we are, we now have two separate VLAN’s, each running their own subnet easily managed from the one DHCP server.

How to configure OpenFiler v2.99 iSCSI Storage with VMware ESXi 4.1


 

 

I’d imagine like *most* home lab setup’s (and even in some small businesses), my home lab ESXi setup has always used local disks for storage.

This is all well and good but if you really want to delve in to the advanced features of ESX (like HA, VMotion etc), then you need some sort of attached storage in place.

Realistically the first thing with everything like this is “what is the cost”, so as much as i’d like a fibre attached SAN (wouldn’t we all…), i’ll have to settle for something else in this instance.

Bring on the next best solution iSCSI.

I know there are a number of free options out there but i’ve heard good things about openfiler so I’ve decided to run with that.

I’m going to assume you’ve already instead openfiler (it’s honestly pretty straight forward and there are guides for both the GUI and text based installation on the website).

Now I needed to find something to run this on, as it’s only my home lab what the heck I decided to install it on an old laptop I had…

Brief overview of the spec’s:

  • Intel(R) Core(TM)2 Duo CPU U7600 @ 1.20GHz
  • 2 GB ram
  • 75GB hard drive
  • Gigabit NIC

So it’s not the first thing you would associate with a SAN….but it just shows you don’t need much to run this.

With the basic’s now covered, lets start

Openfiler Configuration

First we need to login to openfiler so we can configure this. In the initial setup you can specify an IP address to use so browse to: https://192.168.5.49:446 (this is the IP I am using in this example). Default username: openfiler Password: password

Next we need to create a volume, a volume grup and LUN. (again i’m going to assume you have a basic understanding of these) but to sum up:

  • Physical Volume – This is where you assign space on the physical disk. This will be used in a volume group
  • Volume Group – The volume group contains the physical volumes, which is then used for the logical volume
  • Logical Volume (LUN) – This is what is presented through to the ESX/i server

Once we are logged in lets navigate to the volumes tab

You will see an alert as we’ve not yet created any volumes

Below this alert you will see the local disk. Click on /dev/sda to edit the properties for this disk

You will see it display the original partitions created during the initial install

We now need to create a new primary partition (make sure you select Primary under mode and Physical Volume under partition type).

Select the starting and ending cylinder (how much space you wish to assign) and then click create

Once created you will now see the new partition you’ve created listed at the bottom of the table

We now need to create a volume group, so navigate to Volume Groups

I’m going to call this michaelv1, once happy (make sure to tick the little check box) click add volume group

You will now see this new group created in the table

Now this is done, select Add Volume from the right hand menu

This is now where we will create a volume. Click on change

In the below example I’m creating the volume named mrtest, and have specified that the volume will use all the available space. Also make sure you select from the drop down box the (block (iSCSI, FC, etc)) option, and click create.

Once created we can see the new volume listed in a table

Once the above has been completed we now need to tell our “SAN” to enable the iSCSI target service. (otherwise we won’t be able to add an iSCSI target).

To do this navigate to the services tab

You will see the iSCSI Target service currently disabled and stopped. Click Enable

Now the service is enabled, click Start

Once this is up and running we need to create an iSCSI target. Select iSCSI Targets from the right hand menu

I always leave the Target IQN as the default, but if you want you can change it. Select Add

Next we need to select LUN Mapping, you will see there are currently no mapped LUN’s. Simply click the button which says Map.

You will now see all available LUN’s have been mapped

Next click the Network ACL tab. As we have not configured the network access you will be prompted with the below. Simply click the Local Networks link

Scroll to the bottom of the page (below the IP configuration of your host), and specify which network’s can access this device. As i’m running this in my home lab i’m allowing the entire 192.168.5.0/24 subnet as this is purely used for testing. You can call it anything you like, i’ve called mine ESXi4, and most importantly make sure you select Share from the Type drop down box, finally click update.

Return to the Network ACL tab and you will now see the below. Make sure you select allow from the access drop down box.

That’s it now from the openfiler side of things, we can now fire up our ESX/i host and continue with the configuration.

 

ESX/i Configuration

Firstly navigate to the Configuration tab

As you can see from the below, i’m currently running ESXi 4.1.0. I’ve just the one Vswitch (you can chose to create a new Vnetwork and run your “SAN” on a different network) but as this is only a test environment i’ve got everything on the same network. (Obviously in a production environment I would not recommend this!).

Click on to Storage Adapters, you will see there is already an iSCSI software adapter listed, but it’s not currently enabled.

Click on to the iSCSI software Adapter and select properties

This will open up a new window, simply select configure

Then select the tick box next to Enabled.

Next select Dynamic Discovery, and click Add. Enter the IP address of your device (in this case 192.168.5.49), and select OK

Once you click Close you will notice it prompt you asking if you wish to rescan. Select Yes.

You will now see under iSCSI Software Adapter, our newly created openfiler LUN.

Great, we’ve now got this far and we can see ESXi picking up our newly created LUN. Now we need to configure ESXi to be able to use this LUN to store data on.

 

Create a new datastore within ESXi

Select Storage from the left hand menu (you will see the default Datastore currently listed). Click Add Storage

and now select Disk/LUN

Click next, and you will see listed our openfiler LUN. Select this, and click Next.

Select Next again

Chose a name for your datastore (I’ve chosen OpenFilerStore)

I also chose to leave the default block size, and maximum capacity check box ticked and then selected Next

finally click Finish, this will now create the new datastore

When you view your datastores you will now see both the original, as well as our newly created store

Finally, to make sure you can now use this datastore, create a new virtual machine and when you get to the datastore options, you should see our newly created datastore available for selection

And there we go! (wasn’t so hard was it!)

We’ve now made use of that old laptop which you thought you could do nothing with, and extended it’s life by using it in your home lab setup!

How to add VMWARE ESXi 5.1 host to vCenter Server ?


This article explains about how to add the ESXi 5.1 host to existing vCenter Server 5.1.
1.Open a VMware vSphere client 5.1 and connect to the vCenter server.
2.After logging to vCenter server ,you can see the below screen with instructions of adding ESXi hosts.

3.Create a new Datacenter to add the ESXi hosts in to that.The datacenter is nothing but collection of ESXi hosts. If you have ESXi hosts on different locations,Provide the meaning full name to the datacenter in vCenter.
4.Now our datacenter is ready .Here the datacenter name is UnixArena-DC .
5.Click on the “Add a host ” link.Here you provide the ESXi host details and valid credentials to add it in vCenter. Click Next to continue.
6.In this screen you will get the summary of ESXi 5.1 host details and it’s virtual machines.
Here i don;t have existing virtual machines on ESXi 5.1 host.
7.Add the valid license key .If you don’t have a valid one ,just click next to continue to in Evaluation mode.
8.If you want to restrict remote users directly logging to this host,just enable lockdown mode.
9.Select the virtual machines datacenter locations.
10.Click finish to complete the setup.
11. vCenter will take some time to add the ESXi host.Be patience.
12.You have successfully added the ESXi host to vCenter server.Click on “Create a new virtual machine” to create new virtual server.
13.The below screen shows configured virtual machine with the name “Solaris 11- UnixArena” .
Thank you for reading this article. Please leave a comment if you have any doubt.

– See more at: http://www.unixarena.com/2013/07/how-to-add-vmware-esxi-51-host-to.html#sthash.1oueExDz.dpuf

%d bloggers like this: