IT-Project - Typepad · 2014-01-30 · Tom Trogh 3IZ Page 4 Goal of the project The goal of the project is to establish an environment that can be managed by students and only a small

IT-Project Revision of the TI Network

By Tom Trogh

Tom Trogh 3IZ Page 1

Contents

Foreword .......................................................................................................... 2

Introduction ...................................................................................................... 3

Customer ....................................................................................................... 3

Reason for choosing the project ........................................................................ 3

Involved Parties or Stakeholders ....................................................................... 3

Goal of the project .......................................................................................... 4

Results of the project ...................................................................................... 4

Course of the project .......................................................................................... 5

Stage 1: Plan .................................................................................................. 5

Stage 2: Design .............................................................................................. 8

Network Design ............................................................................................ 8

Server Design .............................................................................................. 9

Server Design Revisited .............................................................................. 10

Stage 3: Implement ...................................................................................... 13

SCCM Implementation ................................................................................ 13

Construction of the rack .............................................................................. 14

Network implementation ............................................................................. 14

Server Implementation ............................................................................... 15

Redesigned Server Implementation .............................................................. 16

Cleaning up the iMacs ................................................................................. 17

Stage 4: Document ....................................................................................... 19

Teambox ................................................................................................... 19

Minimal Requirements ................................................................................. 19

Installation Guides ...................................................................................... 19

SCCM Guide............................................................................................... 20

Conclusion of the project ................................................................................ 21

Deploy and prepare the ICT course devices for the oncoming year ................... 21

Create a small environment that can be managed by students ......................... 22

Prepare the iMac lab for the oncoming year ................................................... 23

Sources ....................................................................................................... 24

Annexes ......................................................................................................... 25


Foreword First of all I would like to thank the HUB-KAHO for providing me the opportunity of

working with equipment normally not available to students. Yvan Rooseleer gave me

this wonderful opportunity which was a good way to enhance my skills in IT. I would

also like to thank Ronny Heymans for guiding me and showing me the ropes of the

trade and sharing some of his experience in the field. And finally the last person I

would like to thanks is Jonathan Van Beneden, my colleague and the person who

helped me finish my IT Project by aiding me with the implementation and Stage Three

of the project. I enjoyed working on this project and getting both the good

experiences and bad experiences in the field. I learned that not everything works as I

want it to work and that sometimes you have to find another solution to the problem.

I made this project to succeed for my IT-project required for every 3th year student

that wants to complete their course. After reading this document the readers should

have a clear understanding of the project and the work involved. This document also

shows that I am capable of reaching level 6 as is required by Professional Bachelor

students.


Yvan Rooseleer

Ward De Smet

Jonathan Van Beneden

Tom Trogh

Ronny Heymans

Introduction

Customer The customer for this project is the association

HUB-KAHO, specifically Yvan Rooseleer, head of

Applied Informatics at the HUB. He requested that

my colleague Jonathan Van Beneden and I build a

small network for IT students and maintain it for

one year. We would have to train several students

to maintain the network after we’ve finished our

course.

Reason for choosing the project I had a wonderful opportunity during my summer holiday to help prepare the HUB for

a new year. My colleague Jonathan Van Beneden and I helped the IT department

(represented by Ronny Heymans) set-up a working environment for Applied

Informatics. It was a tiresome, but nevertheless very good experience as I got a taste

of how complicated a business set-up can actually be.

At the end of the set-up I was offered to further maintain the system as part of my IT

project. Eventually it became a much larger project and much more challenging. I’ve

always loved challenges in the past, and I wouldn’t pass up one when it was staring

me in the face. It also offered me the chance to work with equipment that I normally

wouldn’t have access to. I also had a chance to work together with several teachers

who already have years of experience on the field and provide me with their expertise

on the case.

Involved Parties or Stakeholders Several parties are involved in the realisation of the project. The organisation most

involved will be the HUB-KAHO in this case represented by Yvan Rooseleer. He will

also be the head of the project. The IT department represented by Ronny Heymans

is also involved as they will have less workload after the project and he provided

assistance to the success of the project. Students represented by their

“Ambassador”, in this case Tom Trogh will have faster access to new equipment when

needed. And last the Team working on the project (Tom Trogh & Jonathan Van

Beneden). They will responsible for the realisation of the project by the end of

December.


Goal of the project The goal of the project is to establish an environment that can be managed by

students and only a small amount of support from the IT department. This is because

it has always been the goal that the students of Applied Informatics take care of most

of their own problems concerning IT with only minor interaction from HUB-KAHO IT

department. This will also open some time for the IT department to spend more time

on more important and pressing matters while students that manage the network

have some extracurricular activity and a way to improve their own skills in the field.

Since the IT department is often busy with other tasks and not available for

implementing new software on servers, students will now take over that role and

implement their own software that they need over the years.

A summary of the goals would be as followed:

• Develop an environment manageable by students

• Lessen workload for the IT department

• Create a chance for students to enhance their education

• Reduce wait time between new technology implementation

Results of the project The project should come to an end at the 31st of January 2014. After this date the

project will be evaluated and closed. A new project will be started by new students to

maintain the network and update it as needed. The evaluation will show the final

results of the project, but the following are the predicted results of the project:

• Two physical servers (one with Hyper-V & one with VMWare ESXi) available for

use by both students and teachers.

• One virtual machine that’s used as management machine.

• Three virtual machines with Windows Server 2012 for usage by Cevora.

• One Virtual Machines used and managed by RivetingStudios.

• Apple iMac Computer Lab updated to OSX Mavericks.

• SCCM Deployments prepared for following years.

• 30 laptops setup and ready for usage by students.


Course of the project This section of the document will give a detailed description of the different stages

and the work involved in each stage of the project. You will notice that the

implementation happened before the documentation of the project. This is due to the

limited time for the project between the design and implementation stage of the

project. The stages will be discussed in the following order: Plan, Design, Implement

and Document.

Before we started any of these stages a Project Initiation Document (PID)1 was

handed to Yvan Rooseleer. His approval was needed before we could start the project.

He approved the PID after a few small corrections2 and we were able to move to the

first stage of the project: Planning.

Stage 1: Plan The planning of the project started months before the actual agreement on the

realisation of the project. It started as a few ideas that we collected and discussed

with the head of the project Yvan Rooseleer. Eventually he contacted Jonathan Van

Beneden and me to work on the project during summer holiday. We started by

making several drawings of the project. We were allowed to use the whiteboard in the

cisco lab class. We used this whiteboard to draw out all the ideas to get a clear view

on the best ideas and which ideas should be scratched. We then started to add

different ideas together into one working final design.

We then had to take inventory of the required equipment and the equipment we had

in our possession. After collecting all the information we realised we didn’t have the

necessary equipment to design the network and we had to redesign the complete

network for the project into a smaller working environment (See Stage 2: Design).

We also had to plan how to get a fully working System Center Configuration Manager3

(SCCM) environment operational to redeploy all the computers used by all the ICT

students. We decided at first to try to setup a completely new environment on some

test environment servers, but quickly noticed it was impossible due to the limited

resources on the machines made available to us. It was then decided to contact

Ronny Heymans (System Administrator) and work closely together on getting a

working environment. While he worked on setting up the environment we worked on

creating different silent installs for every application that the teachers have sent us

beforehand. We had to look up detailed documentation on how to create the correct

installations for each application. Sometimes it was just as simple as downloading a

“Windows Install” (.msi), but most of the time a custom “Windows Install” had to be

created or even a script to make sure the program gets properly installed. During the

planning of all this we had to contact Ronny Heymans often because we had no

experience with SCCM whatsoever. He did help us greatly and he was thankful that we

helped him with the planning and implementation later on.

1 See Annex: PD_Project Initiation Document_1.0_FL

2 See Annex: PD_Project Initiation Document_1.0_FL for details on the changes

3 See Annex: DL_A guide to SCCM by Jonathan Van Beneden_1.0_FL


The last thing we planned was on how to implement the environment in such a way

that they could be used for the lessons at the beginning of the year. We were

completely stumped on how to achieve this feat. IMacs are incompatible with almost

all the software that we needed to install on these systems. Eventually we planned to

integrate the iMac environment into the Active Directory (AD) of the HUB so we didn’t

have to create individual logins for everyone on every iMac. We also decided to work

with Virtual Machines (VM) on every iMac and couple them to the SCCM environment

we were working on. This would allow us to easily clean these VM’s in case of abusive

usage by students or by guests. We would have to clean install all the iMacs, and then

install a new OSX (Macintosh Operating System). After this has been done the virtual

machines will have to be created and prepared for deployment before the SCCM

environment is up and running.

Usage of the whiteboard was very important during all the planning. That way we

could implement flexible planning according to the course of the project. It was easy to council the whiteboard and use it as a medium to put our ideas on and make it easier to explain it to each other. Often we discussed various ideas and plans on the

whiteboard and started marking faults in each other’s ideas. This way we were able to trim the fat in many ideas and even bring a solution or two to things that seemed

impossible to solve.

Ronny Heymans also brought a solution to many problems we encountered during the

planning stage of the project. Because of his wide knowledge and expertise on the

case he had a lot of solutions ready for us when we asked for them. Without him this

project may have never been so successful because of the time he saved us on the

project overall.

Due to the limited time and the constant changes in the project, we weren’t able to

document all our planning properly to the point where it became too chaotic to

contribute to the project so we decided not to document all the planning. We moved

on to the design and implementation as soon as we came up with a solution to a

problem. This will make “stage 2: Design” and “stage 3: Implement” the most

important stages of the project. All the servers that were needed for the project have

been successfully documented as we planned each and every server. These will be

referred to again in the Design stage and can be found in the annex section as well4. A

list of all these installation guides5 has also been added in the annex section for an

easy overview of all the installation guides that were used in this project. A minimum

requirements guide6 was also created for the initial setup and later redeployment of

the server. We planned this in mind for the newer students that will eventually take

over this project. They will need these installation guides and minimum requirements

guide if they don’t want to lose time on recreating what’s already been done instead

of improving the current environment.

4 See Annex: DL_Installation Guide <Servername>_<Version>_FL

5 See Annex: DL_List of Installation Guides_1.0_FL

6 See Annex: DL_Minimal Requirements_1.0_FL


Later on a shipment of laptops was received and they were added to the project as

they weren’t ready for usage by students. We decided to integrate these in the Active

Directory (AD), SCCM Environment and that we had to create a script to create local

users so they can be used even offline. Two new servers have also been delivered

later on and all our planning became obsolete cause of this. We needed to redo the

whole system, but we would be able to make a much better system with the added

equipment made available to us. Due to the very limited time left we immediately

jumped to designing the new environment. The changes were immense and will be

explained in the last part of stage two.


Stage 2: Design

Network Design

During the planning stage of the project, a lot of designing has happened already. We

needed to be sure that the project was viable with the given equipment and budget.

Several designs were made on the whiteboard concerning the most important part of

the project: “Setting up a network environment for IT students that can be managed

and maintained by IT students without the help of IT helpdesk”. The problem during

the design stage is that we didn’t know how much IP addresses we would have

available to us. At first we experimented a bit with some testnet7 addresses and found

out that we needed more IP addresses then we would be able to receive. After

consulting Yvan Rooseleer we decided to create our own network in the current

network setup. Because we weren’t limited to any amount of IP addresses in our own

network setup we decided together with Yvan Rooseleer this would be the best course

of action.

We received six external IP addresses for use in the project. These IP addresses range

from 193.190.225.143-193.190.225.148. These are linked to an internal IP address of

the TIHUB network. The TIHUB network is a sub network inside the entire HUB

network for sole use by the students of ICT. Of course our own network couldn’t just

access this network because we were using the 172.20.0.0/16 network and the

TIHUB made use of the 192.168.127.0/19 network. These aren’t compatible with

each other so we had to add a router to our already existing design that would be able

to make use of Network Address Translation (NAT). NAT allows the translation of one

IP address to another (Static NAT) or even many IP addresses into a single IP address

(Dynamic NAT). Static NAT is mostly used by servers that need to be directly

accessible from the outside network (WAN). Dynamic NAT is usually used for devices

that need internet access (Workstation, Home Computer). We decided to use the IP

address 193.190.225.148 for our dynamic NAT purposes. This allowed us to add an

enormous amount of devices to the network and give them internet access at the

same time. Of course only the devices that would be accessible from the outside are

devices that make use of a static external IP address.

The IP addresses are allocated as followed (Current Data):

• Olympus – 193.190.225.143

• Unallocated – 193.190.225.144

• Venus – 193.190.225.145

• Used by Andy Van Maele8 (First semester only) – 193.190.225.1469

• Used by Andy Van Maele (First semester only) – 193.190.225.147

• Dynamic NAT pool – 193.190.225.148

7 Testnet: IP addresses that aren’t real but as placeholders to be replaced later on by real ones.

8 Cisco Academy Instructor

9 See Annex: DL_Reference Guide_1.0_FL for more information


We were able to efficiently make this setup because we received better servers to

work with by the end of the project. At first we didn’t have the correct equipment and

we had to use two physical servers that we couldn’t virtualize so we were forced to

put everything on 2 servers without any room to expand. The network was made with

expansion in mind though. Eventually the network was designed and the foundation

for the server environment was created. We did notice some more problems later on

in our design because of the limited amount of servers and we didn’t account for the

port forwarding we may need to do to get access to all the facilities. Eventually this

problem got solved by creating a “Remote Desktop Gateway”. The designed gateway

server would allow access from the WAN network and administrative users would have

to use this server to get access to the internal network. The bottleneck10 in this

network would be this server because it would have to be able to handle all the

outgoing and incoming traffic. There was nothing that could be done about it because

of the limited amount of resources. The implementation showed later that it was only

a short-term solution because the server couldn’t handle all the network traffic.

Server Design

The server design was an entirely different matter. We would have two physical

servers made available to us, but one of these would be mostly claimed by

RivetingStudios11. This server would be named Olympus. Since it wouldn’t be able to

handle anymore services we designed it in such a way that it would provide Active

Directory services for the entire network. This would provide us with the means to

centralize all our user accounts and save us a lot of time by only having to create all

our permissions once instead of on each server. This would also provide the means to

expand the environment with additional servers later on. Since we didn’t have a

Domain Name System (DNS) yet we also added that to the server since it wouldn’t

cause too much strain on the server. The name of the DNS zone would be

RivetingStudios.com.

The second physical server was a completely empty server and we would be able to

fully use this one. To stay in line with the naming theme we decided to name this one

Tartarus. Tartarus would have to serve as FTP Server. A lot of storage was needed

for this, but we found that we had access to two HP SCSI storage boxes each

containing six Terabytes (TB) of space. This would grant us twelve TB of space and

would be more than appropriate for its purpose. Tartarus was also designated as the

Remote Desktop Gateway and would be a way into the internal network from the

WAN.

After several designing steps we decided to design a rack of our own. We didn’t have

access to a rack to put our servers in so we decided to create our own temporary rack

till room was made for the servers in a proper rack. The rack was made of five layers.

The top layer would contain two screens and one Personal Computer (PC). One screen

would be connected to Olympus and another to Tartarus. The PC would contain the

software called “Spiceworks” which will be used to monitor the network. The PC will be

designated Elysium. The second layer will contain two keyboards to control the

10

Weak point in the network that can cause network traffic to slow down 11

A group of students who named themselves RivetingStudios.


servers locally if needed. The third layer holds the router and multilayer switch12 used

in the network design, connecting the servers and PC to the network. The fourth layer

contains the servers. They will be reverse stacked (each facing the other way) so the

cabling won’t be mixed and easier to check for faults in the cabling. The fifth and

bottom layer contains the two storages boxes and are stacked in the same way as the

servers. The cabling would be secured to the rack for safety measures (tripping, theft,

etc.). Multiple power cables would be secured to the rack as well. They will provide

power to all the systems on the rack. Each power cable would be labelled to explain

which system they contained. Systems were evenly spread out over the power cables

to prevent short-circuit or complete system failover should one power cable fail.

This would normally have concluded the design phase of the project, but during the

implementation of the project two new servers that could be virtualized were

delivered and the whole design stage had to be redone. The advantage of these

servers though is that they are much more efficient and the setup is much easier. I

will explain each server individually but details about the design of the server can be

found in the annexes named “Installation Guide”. The network design has not

changed and has remained the same during the whole process.

Server Design Revisited

Only one of the two servers will be actively used. The active server has been named

Mercurius and all other Virtual Machines (VMs) on Mercurius will be named after

planets in our solar system. After discussing with Yvan Rooseleer it was decided to

create three VMs that he would use in his courses. They will be named Earth, Mars

and Jupiter. Venus will be used as a management machine and a Remote Desktop

Gateway. It’s also powerful enough to host Spiceworks as well so Elysium is made

obsolete. The only exception to the naming rule is Olympus because that VM will be

used by RivetingStudios and they are responsible for their own VM. Since the server

has no more than a single Quad-Core Processor it’s been decided that the amount of

planets in the solar system are more than sufficient to the amount of VMs that can be

hosted on one server. The most important changes are the following:

• Active Directory will now be provided by the TIHUB network

• Two physical servers will now be virtualized

• RivetingStudios will be split from TIHUB network

Mercurius

The first of the physical servers is named Mercurius. This provides us with a naming

base with not to many options but enough for expansion in the future. Mercurius will

currently have to host five VMs13 named:

• Olympus

• Venus

• Earth

• Mars

• Jupiter 12

Switch that contain some Layer 3 capacities 13

More information can be found in the installation guide Mercurius


Due to the limited amount of processors and as a result limited processing capability,

the server can’t handle huge applications, but is able to hold all the currently needed

applications. Every server that is going to be virtualised needs a hypervisor. In this

case it was decided to give Mercurius the Hypervisor: Hyper-V Server 2012 by

Microsoft. Hyper-V server 2012 is a lightweight (Server Core – No Graphical User

Interface (GUI)) and the latest release by Microsoft. This way the server won’t lose

much capacity and there won’t be any problems with compatibility because all the

systems of ICT run on Windows 8 or Windows Server 2012. More detailed information

and configuration about Mercurius can be found in the annex “Installation Guide

Mercurius”.

Venus

Venus is a very important VM in the network setup. It is the VM that the

administrators are going to use to manage the entire network and server setup. It will

now function as the Remote Desktop Gateway instead of Tartarus. It will also take

over the role of Elysium and host Spiceworks. This way the tools the administrators

need to manage the network will be available on a single device. Putty14 will also be

made available on Venus so administrators can Telnet/SSH to the switches and

routers should they need to be reconfigured. VMware vSphere will also run on Venus.

VSphere is a tool used to manage ESXi servers. The reason vSphere is needed on

Venus is because the second physical server will run on an ESXi hypervisor. The

reason why this has been chosen will be explained in a later section. This VM has to

be reached from the WAN and should thus receive an external network IP address.

Further should be noted that this machine should only be used by administrative users

and such can be a potential security risk if not secured properly. More detailed

information and configuration about Venus can be found in the annex “Installation

Guide Venus”.

Earth, Mars and Jupiter

These three VMs are specifically requested by Yvan Rooseleer. They should be three

almost empty VMs with the only thing installed on them a Windows Server 2012

Operating System (OS) and a standard administrator account. These devices will be

used by students taking the Cevora Windows Server course. These servers only need

to be accessible from the internal network and as such they can be coupled the

Dynamic NAT Pool. More detailed information and configuration about Earth, Mars or

Jupiter can be found in the annex “Installation Guide <server name>”.

Olympus

Olympus is a server managed by RivetingStudios. The only responsibility that we have

in the design of the network is to take their hardware requirements and create their

VM. An installation of Windows Server 2012 is required as an OS. They have

requested an external IP Address from Yvan Rooseleer and it has been approved.

They require this so they can be reached from the outside network. More detailed

information and configuration about Olympus can be found in the annex “Installation

Guide Olympus”.

14

Network tool to SSH/Telnet to other devices


Cosmos

Cosmos is the name given to the second physical server. This server won’t be used for

much, except for some testing purposes. This server runs the VMware ESXi OS. Yvan

Rooseleer specifically asked to get this server ready for future use as it will be used in

VMware courses that are planned. As nothing specifically needs to be run on the

server only the most basic of configuration has been planned. More detailed

information and configuration about Cosmos can be found in the annex “Installation

Guide Cosmos”.

Chaos

Chaos is the VM responsible for hosting Team Foundation Server 2013 (TFS) and all

its necessary prerequisites (SQL Server, etc.). Due to lack of experience with TFS

2013 and the lack of time a proper design has not been made and will be passed on to

the future students who will expand this project further. This VM is not configured and

can be either removed or changed according to the growing or declining needs of the

ICT course.


Stage 3: Implement This stage of the project has been separated into two different phases just as the

design stage. Due to the delivery of new servers during the project a redesign had to

be done and as such the implementation had to be adjusted through the project. Also

several different implementations had to done to complete the project. These

implementations are as followed:

• SCCM implementation

• Construction of the rack

• Network implementation

• Server implementation

• Redesigned server implementation (New server design)

• Cleaning up the iMacs

SCCM Implementation

Implementing SCCM was a very difficult task. At first we wanted to implement our

own SCCM environment and so we designed it. But during the implementation this

proved to be impossible. The servers we had our disposition were not nearly strong

enough to host SCCM and all its required applications. This was a problem beyond our

experience and knowledge. We decided to contact someone with years of experience

in this field. Ronny Heymans is the System Administrator at the Hogeschool

Universiteit Brussel. He told us that he already had an SCCM environment, but it

malfunctioned and would have to be fixed. Eventually we worked together with him in

setting up a new environment. While he worked on setting up a new server with a

brand new SCCM installation, we worked on creating “Silent Installs”1516. Most of these

Silent Installs were available and only needed a small update from the old

environment. Though due to all the new software requirements as of this year new

Silent Installs had to be created. This was sometimes as easy as just downloading the

correct installation file, but not all software is made for enterprise deployment and

had to be prepared. Luckily enough Ronny Heymans was also familiar with this

problem and provided us with the means to create our own Silent Installs. This

process took a few days because even though we had the software we still had to

learn to use it. Not every application was compatible with this method either and had

to be installed via command line. This is called a “Scripted Installation”. These

installations require a lot more research and time to make than regular Silent Install.

You have to research the commands to install the application, or if it is even possible

to install it via a command line. If this last one isn’t possible a manual installation has

to be done on each device in the network that requires the application. This was the

case with some applications and is very time consuming. The worth of enterprise

deployment was proven to us that day and the time it can save overall is immense.

The cost of having to do everything manually is much higher than the cost to invest in

enterprise deployment. At least if the amount of devices is high enough. In this

project the amount of devices was so high that without deployment the cost would

have been too great. In the end we managed to deploy almost every application

required via SCCM.

15

Installation of an application that can run In the background even if no users are logged on 16

See Annex: DL_A guide to SCCM by Jonathan Van Beneden_1.0_FL


Construction of the rack

This was probably the most fun of all the tasks involved

in the project. We had no actual rack to work with, but

we needed to make sure the servers were properly

secured in a safe environment. We decided to use an old

storage rack with five shelves to create the small

environment on as a temporary solution until room was

available. This setup proved very efficient and we

decided to use it permanently. We created the rack

exactly as we designed it. The top shelf would be used

for screens and PC’s. The second shelf would be used for

keyboards. The third shelf would contain the multilayer

switch and router. The fourth shelf would be used for

holding the servers in place and the bottom shelf

contains the storage boxes. Because of security issues

we had to make sure all the cabling was properly strapped and nothing was lying

around. Luckily the racks contained grooves that could be used to hold the cables in

place and even sort them nicely.

The rack setup proved to be only temporary in this case cause of the new servers that

we received. We had to do a slight redesign of the rack because we didn’t use most of

the equipment anymore. The bottom shelf was emptied because the storage boxes

couldn’t be used on the new servers. They were replaced by a server provided by “De

Fietserbond”. This server should have been included in the project, but we didn’t

receive any more updates about the requirements on the server so it became out of

scope. The older servers were removed from the rack and placed in storage for use by

other students. In place came two new Dell PowerEdge servers that would cause

much redesign work, but made reaching the end goal much easier. The PC on the top

shelf was removed as well due to the availability of virtualization making it obsolete.

This would become the final setup of the rack.

Network implementation

Implementing the network was the hardest part of the whole implementation process.

We almost immediately noticed that our design was flawed and that it would prevent

us from properly implementing the servers in the environment designed. While our

network was large enough we didn’t have enough external IP addresses for all the

devices planned. We had to do a slight redesign and bundle some applications on a

single device. This was of course a difficult limitation to work with due to the limited

hardware available on the servers.

We also decided we would need to implement “Port Forwarding” in the network if we

were to make efficient use of the IP addresses we had been assigned. This was

missing in our design as we didn’t think it was necessary at the design stage of the

project. This proved to be a major flaw and cost us a lot of time overall. This again

would prove to be the wrong solution later on as no port forwarding was necessary if

we made sure no port overlapped on one IP address. While we lost a lot of time on

this, we did learn that we have to follow all the steps on the project if we are to


succeed instead of taking a shortcut and having to backtrack later on in the project

because we failed to follow the right steps.

The communication with the IT department wasn’t optimal either at the beginning. We

weren’t always using the right technical terms and that caused some confusion on

both sides. Because of this we lost about two weeks of progress due to not being able

to get the network to communicate properly with the internal network of TIHUB.

Eventually we resolved this problem by communicating with Yvan Rooseleer and

Ronny Heymans. We had to make use of NAT in our network setup. Due to the nature

of both networks a double NAT happened before the external network (WAN) is

reached and this caused some problems of its own. Devices in our network can’t

communicate with the internal network unless they go through the process of “NO

NAT or NAT”. We created a workaround by implementing a “Dynamic NAT Pool” by

overloading the outside interface17 of the router. Overloading the interface means that

we force the router to make use of either a static NAT entry in the router table or if no

static NAT entry can be found, make use of the pre-defined NAT pool. Of course all

the devices making use of the Dynamic NAT Pool can’t be directly accessed from the

outside. While we have enough IP addresses available should the setup require for

more devices to be reached directly from the outside, then port forwarding will have

be added to the router. While it isn’t implemented just yet, the foundation has already

been put in place and only minor adjustment need to be added for it to work.

Server Implementation

Installing the servers in the environment required a lot of teamwork. We got an extra

person assigned to us to help us in this endeavour. Ward De Smedt was a huge

addition to the team in the time he worked with us. He took it upon himself to work

out the entire Active Directory on his own while we worked on other important cases

(Setting up an FTP Server, Creating Silent Installs, etc.). Ward made good progress

on the Active Directory with Jonathan Van Beneden while I worked on setting up

Tartarus with an FTP Service. The design originally worked with “Filezilla”18 but we

quickly noticed that it wouldn’t provide us with what we needed. While Filezilla is a

handy tool for personal use or small enterprises it just wouldn’t provide the necessary

tools required. After doing some more research we concluded that “Windows Server”

provides a role named “FTP Server” that included everything we needed at not much

loss of resources. Luckily enough the implementation was fairly easy. “Technet”19

provided a good base to start with and we were able to work our way from there. We

made use of the Storage Boxes to provide us with a massive amount of storage

space. Extensive research had to be done on how to properly configure a FTP Server.

Eventually the system was running quite smoothly and we were able to connect to the

FTP via the internal network, external network and the TIHUB network. We did have

to conclude that running the FTP server was not a viable option due to the limited

speed of the network. It could barely handle any transfer rate and large files could

sometimes take hours to complete. If we had to open this up to the students to store

their files the system would not be able to handle all the traffic. After contacting

17

Ethernet port that connects our network to the internal TIHUB network 18

Lightweight FTP Server application 19

Documentation about Microsoft Products by Microsoft


Ronny Heymans he provided us with a simple solution. They already had a different

system in place and it would be improved soon. This resolved our FTP Server problem

and we were allowed to get rid of the FTP Server. Eventually Tartarus lost its

usefulness and was used as a backup server for Olympus and as a testing

environment. This would prove not to be a bad thing because we would soon receive

two brand new servers that would be more than capable of doing as requested.

Redesigned Server Implementation

The first server implementation was only a temporary solution. We already requested

several servers from Yvan Rooseleer, but we had to wait on them for an extensive

amount of time. These servers contained a lot more memory and processor power.

We couldn’t just take out the old servers and replace them with the new ones because

we had already done a lot of configuration on Olympus. This would have to get

transferred to the new server (Mercurius) and then put on a VM named Olympus. We

had to create a complete backup of Olympus first which wasn’t an easy task because

there was a lot of manual labour involved in the making of the backup. Another issue

was that we had to remove the RivetingStudios.com domain from every device linked

to it or we would be unable to access them. We did forget to unlink two devices and

we had to reconnect the whole old server setup again and get it running again. This

was yet another issue that we made sure to remember since it is difficult to “simply”

reinstate an old server. After the unlinking had been successfully completed the new

server (Mercurius) could finally be installed on the rack. The first thing we did was

remove both the old servers (Olympus and Tartarus) and the connected Storage

Boxes. Then we placed both new servers on the fourth shelf on the rack. The server

provided by “De Fietserbond” named “Atlantis” was placed on the bottom shelf but

hasn’t been connected or used yet due to missing requirements.

The installation of the new servers required some redesigning because afterwards

these would be able to separate applications much more efficient and because of the

increased capacity they would also become much faster in the process. So we decided

to name the first physical server: “Mercurius”. We decided to use Hyper-V Server

2012 as the hypervisor on this server. What we didn’t take into account in our design

is that we wouldn’t be able to locally manage it. We had to create a management

server or PC that remotely20 manages a Hyper-V machine. Some configuration can be

done locally; due to the nature of Hyper-V Server this configuration is very limited.

This proved to be a bit challenging at first because we couldn’t get the management

PC to connect to Mercurius due to problems with the DNS Server. Eventually with a lot

of trial and error we managed to make the connection between the two. We decided

that we needed a better way to manage our servers so we introduced our second VM:

“Venus”. Venus would be the VM that all of the administrators would use to manage

the entire environment. Since it is a lot more powerful than Tartarus it would also host

everything Tartarus was supposed to host. This includes: Spiceworks21, Remote

Desktop Gateway and VMware vSphere. The installation of Venus went rather

smoothly and provided a good base to work with. The only problem is that if Venus

20

Remotely as in another device (PC, server) 21

Freeware Network Management Tool


should ever go down the entire network would be inaccessible until an administrator

restarts it locally. Should it go down permanently due to a crash in the system then

the management PC can be used to recreate Venus22. Once Venus was up and running

everything went smoothly. It was only shortly after that Olympus was up and running

that RivetingStudios was able to begin working on their server. The only thing we had

to provide was a clean installed Windows Server 2012 and an IP address that was

linked to an external IP address.

Yvan Rooseleer also asked if we could provide him with three clean installed (Windows

Server 2012) VMs which are accessible from the internal network. Since we didn’t

have a range we could use in the TIHUB internal network we had to go and request

one from Ronny Heymans. He happily provided us with the range 192.168.181.0/19.

We also got some requests from other teachers to use some IP addresses and we

even had to couple two IP addresses23 to an external one for Andy Van Maele. We also

made the range 192.168.181.40 – 192.168.181.50 available for use by Yvan

Rooseleer solely. We provided him with three new VMs that he could use in his Cevora

course (Earth, Mars and Jupiter).

We still had to do a lot of experimenting but we couldn’t risk crashing Mercurius so we

decided to connect the second server as well. We named this server Cosmos. We

would use Cosmos for all our testing before we launched it in the production

environment. Since Yvan Rooseleer let us know that a VMware ESXi server might be

needed soon we used this as a Hypervisor. This would provide a nice base for the

future and would save some precious time later on. VMware ESXi is a linux based

hypervisor and as such very lightweight as well. We made a VM on Cosmos which we

named Chaos. Chaos provided to be an excellent name as we used it for all kinds of

experimenting and testing. Software Engineering teachers wanted a Team Foundation

Server (TFS) for a long time so we tried to get one up and running, but it proved to be

a very challenging task and we didn’t have enough time to get it up and running since

we still had to focus on other urgent tasks in our project. As of now Cosmos is still

running, but still only used in testing.

Cleaning up the iMacs

The last task on our list was preparing the iMac lab. This was a very strenuous and

difficult task. ICT devices usually all run on Windows 8 and most applications used in

courses only run on Windows machines (with some exceptions). Apple devices aren’t

known for their compatibility with Windows based applications and the iMacs proved

to be no exception to the rule. First of all we had to clean the iMacs completely so we

decided to format them and completely reinstall them. Most of them reinstalled

without a problem, but some complained about needing licenses to continue. We had

to put those aside for the moment (Pre Mac OSX Mavericks launch) until we received

the licenses. The next thing we had to do was make sure students were able to login

on the iMacs without having to create a new account on each machine. After some

research we found out that it is possible to integrate them with a Windows Based

Active Directory. We had to synchronise the clocks on each machine manually because

22

See Annex: DL_Installation Guide Venus_1.1_FL for installation instructions 23

192.168.181.69-70 have been reserved


they couldn’t connect to the Active Directory without the clocks synced. We were

successful in our endeavour but apparently a few machines were able to receive data

about user accounts. Eventually we decided that it was more important to get these

machines operational. So we decided to add some general local accounts that

everyone could use. While providing a security risk there was no other choice since

time was very limited. This was agreed on by Yvan Rooseleer since he also said it was

more important to get the machines at least usable and later on add all the

functionality. We then had to install Parallels24 on each device manually since we

didn’t have a mac server to deploy them. This took several days as well due to the

amount of machines and information needed for the installation. This was proof again

that enterprise deployment can save a lot of time and money. Lucky enough the VMs

created in Parallels could be deployed because they would have to be Windows

machines. Some software had to be manually installed on the machines as well like:

Aptana Studio25. Later on Apple announced that they released a new free OSX

upgrade called Mavericks. This was very beneficial because we were now able to get

the same OSX on all machines and even on the machines without an OS installed. We

were able to get 4 more machines working this way (Potentially saving more than €

8.000). The security risk proved itself as a lot of students messed around on the iMacs

and they had to be continuality fixed. It went from simply reconnecting some cables

to completely reinstalling a machine. In the end the result was much better than

expected and we were able to integrate most machines in the Active Directory (some

unresolved connection issues still remain) and not many complaints regarding them

have been received. The occasional tampering still happens but nothing can be done

about it for the moment until the Active Directory connectivity issues get resolved.

24

Virtualization software 25

Web development software


Stage 4: Document This stage is the actual final stage of the project. The only thing left for us to do after

the implementation was to document some important information about the created

environment. These documents would include:

• Detailed information on Servers and VMs

• Quick Overview of all Servers and VMs

• A guide on how to use SCCM

These documents will serve as the base to pass on the project to future students.

They will need the information in these documents as a reference base to the servers,

virtual machines, network configuration and SCCM.

Teambox

Due to the limited time we didn’t document our whole workflow. We did have to

document some important information like: What port are we using, what IP address

is assigned to which server, etc… Now we couldn’t just write everything on the

whiteboard or scribble it on paper. We decided to look for a collaboration tool that

would allow us to write some notes and information and would be accessible at all

times. Jonathan Van Beneden presented us with Teambox. This tool is a free

collaboration platform26 in the cloud. This proved to be an enormous help in our

project. We weren’t forced to scribble everything down anymore or scared of losing

information on the whiteboard. We simply posted it on Teambox and the rest of the

team could just open the note and look up the information.

Minimal Requirements

The minimal requirements document serves as a quick reference for administrator to

look up information about a certain server or VM. If an administrator at any moment

wonders what’s installed on a VM, he/she should only take a quick look on the

document and would know what its purpose is and how it is used. This document does

not contain any details on how the application should be installed or maintained, but

rather what that which the server is used for. This document will have to be updated

as VMs change or should an administrator decide to add/remove a VM.

Installation Guides

We did find it important to document the current state of all the VMs though. In worst

case scenario, it would always be possible to recover all the VMs to its current state

with this document. The document would also serve as base for future project

students who would need information about a certain VM. They would also have to

update this document as they make changes so the information is always up-to-date.

These documents provide the base for the entire environment and if they are kept up-

to-date properly should be able to function as part of the disaster recovery plan. To

make sure that these documents stay easy to read and understand illustrations may

be added. Another measure that we took is to create a separate document for every

server and VM that has currently been created.

26

Free up to five users


SCCM Guide

Finally we decided that we would need a guide on how to make use of SCCM. This

guide would involve a basic walkthrough of the steps we had to take during the

implementation of SCCM. This guide would be necessary because at least once a year

all the device of ICT would have to be redeployed. We wouldn’t be available after we

finished our course but the work still has to be done. This guide will provide the newer

students with some documentation on how it should be done. This guide should save

them potentially more than a few days’ time trying to figure it out by trial and error. A

step by step guide on how to actually get the application working. It will not contain

information on how to prepare a complete SCCM environment as this is completely

beyond of our field of expertise.


Conclusion of the project While we were unable to completely achieve all the goals of the project, we were able

to lay the foundation for a long lasting environment. Ronny Heymans, Yvan Rooseleer

and I share the believe that we were able to make this year slightly more successful

due to the project. We were able to take over some more mundane tasks from the IT

department and Yvan Rooseleer making sure that they could focus on more important

tasks. Yvan Rooseleer believed it was important to involve students more closely in

maintaining their own environment and that those that volunteered for the job would

be able to add the experience to their resume. By doing this project I can honestly say

that I share his vision and that I am more than happy to put this experience on my

curriculum.

The main goals of this project were the following:

• Deploy and prepare all ICT course devices for the oncoming year

• Create a small environment that can be managed by students

• Prepare the iMac lab for the oncoming year

Deploy and prepare the ICT course devices for the oncoming year

While this was the hardest part of the whole project it was also the most interesting

part. I was able to work together with an experienced System Administrator to create

an environment I had absolutely no experience with. We had to communicate very

closely especially with my colleagues. I believe I also learned a lot from doing this

part of the project. I gained a lot insight and experience working with SCCM and that I

would be able to use this experience in my future working environment.

We did face a lot of difficulties on the way, but eventually we were able to get almost

95% of the devices in working condition. Some of the hardships we discovered

hindered the project were:

• Our inexperience

• Network problems (Slow connection)

• Faulty installations

• Incompatible software

• Updates

Our inexperience was in no way a surprise when we took this project. We never

expected to be able to get it right on the first try. But this proved be a learning

experience and in the end we were able to work around our inexperience by

researching documentation and receiving guidance.

The network problems were a surprise because usually the network (internal) was

always fast. Especially now only a few students were working on the network, but

nevertheless the network could not handle all the traffic and sometimes made us wait

for an entire day to simply deploy an entire classroom. This was made worse by the

fact we sometimes had to redeploy entire classrooms twice or even thrice.


Faulty installations are a real threat in a deployment environment. It often happened

that we deployed a new software package, and our test results showed that it worked

perfectly. Of course we deployed it in the production environment and it’s only then

we noticed that the installation showed some faulty results. Often the error messages

were vague at best and the solution wasn’t always clear. Due to good teamwork we

were able to figure out a solution eventually.

Incompatible software is even worse than faulty installations, because faulty

installations can be fixed but are confirmed to work with SCCM. Sometimes we came

across software that was either old enough that it wasn’t compatible with deployment

software or in no way could be installed in the background. With this software we had

no other choice to put it on a USB stick and simply install it manually. Another

solution would be to include it in the base installation, but this would require us to

recreate the entire base installation. This was a difficult task, but we learned that not

everything can be pleasant and sometimes it just has to be done.

The last and most surprising one were updates. They could utterly break software if

the software updates weren’t applied properly. A good example of this was our

installation of Visual Studio 2013. An update package was released for this application

and we were asked to deploy it to fix some bugs. What we forgot due to our

inexperience is that we first had to deploy the software and then the update package.

We redeployed every device in the ICT environment after we fixed every software

problem. Though we forgot to turn of the update package and it started deploying

along with the installation corrupting several files in the process. We were forced to

redeploy everything yet again because of this mistake. Updates can be very volatile if

applied in the wrong way. Another experience we have learned from this project and

we never would have learned if not for the work experience.

Create a small environment that can be managed by students

This is another hard one, but not extremely hard. Because we were given “Carte

Blanche” on this part of the project we were pretty much free to do as we liked as

long as it was advancing the course. The purpose was to create an environment that

would allow students access to more resources for educational purposes. Another part

of this was to create it as such that students should manage it. We asked around if

teachers required any server access for their course. We created the basic setup for

these teachers and later on discussed what they needed. We didn’t get much feedback

at the moment, but because of our work the foundation has already been laid and the

new students will be able to implement everything the teachers need with minimal

effort. It worked smoothly except that we had to research extensively about certain

software.

The biggest problem we encountered was that we had to switch between servers

during the project, but we were able to handle it just fine due to our experience that

we got from testing on old servers. On the contrary the new servers were much easier

to manage due to the virtualisation and allowed us to do much more in less time. It

was a unique opportunity to work with such equipment during my education and I

believe that it has certainly contributed to expand my education.


Prepare the iMac lab for the oncoming year

The last goal and the one that gave us the most trouble in the end was preparing the

iMac lab. First of all we couldn’t install the Operating System every machine leaving us

with several “useless” machines.

The integration with the school’s Active Directory was a faulty as well. Continuous

connection problems between the two caused either that it was impossible to login on

a device or even impossible to add the device to the Active Directory domain. This did

cost us a lot of time trying to fix this problem and eventually we had to manually

create accounts for these iMacs.

Another problem was the extremely slow virtualization software. It was very difficult

for a user to work with due to the slow speed. Increasing the RAM27 only helped

slightly. Eventually Yvan Rooseleer decided that the usage of the virtualization

software would be at the teacher’s discretion. Some even asked to install the software

they needed on the iMacs itself which was a good solution for the time being.

The release of OSX Mavericks by Apple was another step forward in getting the

devices ready. It allowed us to install the non-functioning machines without the need

for a budget to buy the licenses. We installed all the machines with the Mavericks OSX

so every machine would have the same base installation.

Eventually we were able to get the machines in working order. They still cause some

problems, but that was expected due to the platform they run on and the software

that needs to be run on it. We live in a world where compatibility is still an issue.

27

Memory


Sources Several sources were used in the realisation of the project. These include forums

where IT’ers can discuss several topics and provide each other with solutions. Another

good source of information was the people we communicated with. These are experts

in their own field and contributed to the success of the project. Sometimes using

encyclopaedias provided answers to some history and changes about several

problems.

Experts

� Ronny Heymans (System Administrator – HUB)

� Yvan Rooseleer (Cisco Academy Instructor)

� Colleagues (Project Team)

� Teachers HUB

Forums

� Technet (Microsoft)

� Stack Overflow

� Microsoft Academy

� Cisco Academy

Encyclopaedias

� Wikipedia


Annexes

A. PD_Project Initiation Document_1.0_FL

B. DL_Timesheet_1.0_FL

C. DL_Minimal Requirements_1.0_FL

D. DL_List of Installation Guides_1.0_FL

E. DL_Installation Guide Mercurius_1.1_FL

F. DL_Installation Guide Olympus_1.0_FL

G. DL_Installation Guide Venus_1.1_FL

H. DL_Installation Guide Earth_1.1_FL

I. DL_Installation Guide Mars_1.0_FL

J. DL_Installation Guide Jupiter_1.0_FL

K. DL_Installation Guide Cosmos_1.0_FL

L. DL_A guide to SCCM by Jonathan Van Beneden_1.0_FL

Documents

IT-Project - Typepad · 2014-01-30 · Tom Trogh 3IZ Page 4 Goal of the project The goal of the project is to establish an environment that can be managed by students and only a small