Building a Home Lab – Part 2 – Functionality

In a previous post “Building a Home Lab – Part 1 – Hardware” I talked about why I believe IT professionals benefit from having their own home lab environments. I also talked about the evolution of my home lab from multiple physical servers down to a single physical hypervisor. This single server would run virtual servers as needed and would no longer require expensive switches or complex network storage solutions.

Why?

There is no need to over complicate a lab environment if we are dealing with a single server and resources are locally available for the hypervisor to utilize. There are other reasons why it just makes more sense:

  • Produces less heat
  • Consumes less electricity
  • Takes up less space (keeps significant other happy)
  • Can be setup faster
  • Tends to generate less noise
  • Can be more cost effective in the long run

While not all of these apply to everyone, they still explain some of the benefits of a consolidated lab environment.

Lab Configuration

In order to create a functional lab I wanted to bring up some key components first. A standard local domain with two domain controllers acting as DNS and DCHP servers was the way to begin. Once all the basic pieces got configured the lab was expanded by adding a Windows 7 client and a management system (SCCM) in this case. Additional time would need to be spent to configure the system to provide windows updates and antivirus agent. A high level overview of the lab would be as follows:

  • Hypervisor (Dell PowerEdge T620)
    • 2x Intel Xeon CPUs E5-2620 (Hexacores) at 2Ghz
    • 48 Gigs of RAM
    • 4x 1Gig Nics
    • 2x 300GB 10k RPM SAS Drives (RAID 1) Drive c:\ OS and d:\
    • 5x 3TB Western Digital RE (RAID 5 with 1 as hot spare) F:\
    • 1x 500GB Samsung 840 Pro SSD (VM storage) G:\
  • DC1 (VM) Gen2 (Domain Controller, DHCP, DNS)
    • 2x vCPUs
    • 1 Gig Start Up RAM with Dynamic Memory Enabled
      • 1 Gig Minimum
      • 2 Gigs Maximum
    • 40 Gig Hard Drive stored on SSD G:\
  • DC2 (VM) Gen2 (Domain Controller, DHCP, DNS)
    • 2x vCPUs
    • 1 Gig Start Up RAM with Dynamic Memory Enabled
      • 1 Gig Minimum
      • 2 Gigs Maximum
    • 40 Gig Hard Drive stored on SSD G:\
  • SCCM (VM) Gen2 (SCCM 2012R2 Server)
    • 4x vCPUs
    • 6 Gig Start Up RAM with Dynamic Memory Enabled
      • 4 Gig Minimum
      • 8 Gigs Maximum
    • 60 Gig (OS) Hard Drive stored on SSD G:\
    • 150 Gig (Data) Hard Drive stored on SSD G:\ (May have to move since its growing too fast)
  • Win7 (VM) Gen2 (Standard Win7 Client)
    • 2x vCPUs
    • 3 Gig Start Up RAM with Dynamic Memory Enabled
      • 3 Gig Minimum
      • 4 Gigs Maximum
    • 80 Gig Hard Drive stored on SSD G:\
AD OU structure with Group Policies

AD OU structure with Group Policies

DHCP Server Config

DHCP Server Config

Once the configuration process begun I focused on identifying an IP address scheme. For a lab environment a basic 192.168.1.0/24 range will cover everyone, but in some cases you may have to put some extra thought into this. The domain controllers will need to have these IP addresses configured statically ahead of time and have their DNS settings set accordingly for example:

  • DC1
    • 192.168.1.100 (local IP address)
    • Primary DNS
      • 192.168.1.101 (IP address for DC2)
    • Secondary DNS
      • 192.168.1.100
  • DC2
    • 192.168.1.101 (local IP address)
    • Primary DNS
      • 192.168.1.100 (IP address for DC1)
    • Secondary DNS
      • 192.168.1.101

The domain controllers will be configured once IP addresses have been set and servers have been patched to the latest patch level. These domain controllers will be configured with the standard roles found in most Microsoft environments such as: Active Directory Domain Services, DHCP Server and DNS Server.

I will not go through the step by step process in standing up an active directory environment, but the Active Directory Domain Services will require folks to go through a wizard based process in server 2012R2 that’s pretty self explanatory. To begin basic testing I needed to get a basic domain hierarchy structure with some basic policies seen in one of the images above.

SCCM Collection and Folder Structure

SCCM Collection and Folder Structure

Once the basic infrastructure is set and confirmed operational I proceeded to stand up a System Center Configuration Manager 2012 R2 (SCCM 2012 R2) server. The SCCM 2012 R2 configuration of  is quite involved and will need to have a separate guide. Once SQL Server 2012 SP1 has been installed and confirmed operational and all SCCM 2012 R2 pre-requisites have been installed we can proceed with the installation. This server will be configured as a stand alone primary site with the following roles:

  • Distribution Point
  • Management Point
  • Software Update Point
  • Endpoint Protection Point
  • Management Point

Once the lengthy installation has been completed, we have to spend some time configuring discovery settings, boundary groups, site settings and more. The system will be able to see all other systems within your active directory domain and provide you with the ability to install the SCCM management client agent. It is recommended to create a folder and collection structure to branch out any planned architectures.

Finally once collections have been put into place and other systems get managed by SCCM we can start thinking about important deployment scenarios. In this case I decided to create windows update deployments for all workstations and servers within SCCM. The Software Update Groups have been broken up into years and categories to reduce the amount of total updates in anyone group as recommended by Microsoft. This is only a recommendation but every admin can create different software update groups as they please. Microsoft has a recommended hard number of no more than 1,000 updates in a single update group but I have seen where 500 updates can start causing issues.  The following is an example of Software Update Groups created for this lab:

SCCM Software Update Groups

SCCM Software Update Groups

From all this information we can see how a lab allows us to mimic a corporate environment and test different management techniques and technologies. Next time in Part 3 of this series, I will talk about additional functionality from this lab.

2 thoughts on “Building a Home Lab – Part 2 – Functionality

  1. Pingback: Building a Home Lab – Part 1 – Hardware | OMG Tech Stuff
  2. Pingback: Building a Home Lab – Part 3 – Benefits | OMG Tech Stuff

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s