Friday, July 15, 2011

Day 10 VoIP, Packet Sniffing and Media Center

VoIP is voice over internet protocol. This is how Skype works, by using the internet to send and receive audio (and sometimes video) data. We installed an application (not Skype) and set up a mini VoIP for our network. Set up was minimal (follow installation directions) and easy to use. We actually had a lot of fun calling back and forth and leaving messages.

To test the quality of service between callers, we installed a program called Wireshark so that we could monitor the quality of signal transmission. To achieve ideal conditions, we only had to adjust settings to 46 (or hexadecimal 2e) so that the packets were sent and received on an optimal bandwith to facilitate communication.

Finally, we took a short drive to Chinook High, Lethbridge's newest High School which will also serve as a media center. Unfortunately, going through the list of everything the school had took too long and we were not able to tour much of the facility past the stage and control room. It would have been great to see a classroom. There is a lot of technology in the school to be sure, but the speaker did not mention much about students and it makes me curious about what drove the school's infrastructure. Was it learning or having the best? I really hope it was (or at least will be) the students.

On a last and personal note, this was last day of class for me in this masters program. It was a sentimental day. I have met many incredible people through this and will cherish the connections I have made for ever. I only hope that we do not lose touch!

Day 9: Security, Packets and Virtual Machines

Today there was a lot of discussion about security. There is always that balance that needs to be found between free and easy access to internet tools and keeping data and students safe. This is one area that educators and IT personnel really struggle yet they are both interested in the student's best interests in mind. Where one is focused on educational value the other is focused on personal and identity safety. Both are worthy concerns and usually a compromise can be found. Still, I believe that keeping a student out of something does not really protect him or her in the long run as it fosters ignorance about the real issues. The threat to personal safety does not seem all that pressing. However, when discussing security of information, there is a real concern. There are several instances where personal data has been compromised and this is unacceptable when we think of school records and the information they contain.

The increased power of servers has led to an increased excess of storage. Blade servers offer so much space that virtualization has become more and more popular. What is virtualization? Tricky concept, but it is a way to minimize costs related to equipment and power usage. How? By making it seem that something is there when really it is not. Kind of like magic only more difficult to do :)

Virtualization allows you to use excess capacity to house software and redirect workstations icons, etc. to the main server instead of using the C: drive on the computer they are using. So instead of actually having the software on the hard drive of several small computers dispersed through the network, you have all data stored in a central place. Although this may seem to increase risk of losing data (single point of failure and all), but because blade servers have segregated sections, pieces can be stored and backed up on a regular basis limiting the loss of data from one failure. 

Running a machine through virtualization requires the use of an application such as Virtual Box. Through this easily installed application, a person can virtually run a machine.

Wednesday, July 13, 2011

Day 9: Printer Driver!

Today's task was fairly simple: install a printer driver on our server, connect to the network server and push it out to all users on our network ... AND finish customizing the start menus of our network's users, but technically that last bit was from yesterday.

We are getting the hang of the group policies, active directory and server management. Although we downloaded the wrong driver for the printer at first, and some setting on the server blocked us from downloading it [so we had to download on a workstation and save it to the server], we managed to complete the task of downloading and installing the correct driver, connect to the printer, and print a document! All before a field trip to a local data center. We hit a couple of glitches, but troubleshooting was easy!

The data center was a metaphor for technology in education. The building was strong and impressive, but slightly intimidating. It is costly, but it serves a purpose when used correctly. It has not yet reached its potential and it was constructed with a well-laid-out plan, yet there is one oversight that limits its growth.

After the afternoon class [where I made my final presentation to this cohort of exceptional individuals] we hit the lab to clean up the work from the previous day. Group policies and scripts and active directory ... they are finicky, but if you are persistent, you can get them to work. It is amazing how much technical help there is on the internet. It is even more amazing that I understand what they are saying in some of those how-tos!

So we worked out the issue and our students have a modified desktop. Their start menus are empty except for the icons we placed in a folder on our server [one GPO and a file redirect later!] and our network's users will save their files on our server instead of on the c: drive of the computer they are on.

We are drawing to a close of this course and I have to say I have learned a lot. The next two days it will be interesting to see what we will do to finish the network.

Tuesday, July 12, 2011

Day 7: Adding Roles and Scripts to Active Directory

More fun today! We began the day with an exercise to check the system functionality. Essentially we were to login to another team's workstation using one of the users created from yesterday ... ??? We did not complete this step yesterday, so this provided a starting point for the day. Review the exercises from the day before and find what we missed. This was it:
"Inside the Groups' container you will need to create two groups for your team that will use your team's members in the name. For example, 'Students Joe Pete', and 'Teachers Joe Pete' ... In the Students container create a user with a password and assign them to the group "Students xxx xxx" (the x's represent team names) that you've just set up. In the Teachers container create a user with a password and assign them to the group "Teachers xxx xxx" (the x's represent team names)."
Actually, now that I read that I am wondering if we created them in the correct container ... will have to check that again in the morning.

Once we had completed the activities from the previous day, we started on today's assignments. They included two mini exercises. The first was to create logon scripts using group policies. This is done through the Group Policy Management menu in the Administrative tools on the server. First you have to be sure to find and select the folder that you want to apply the policy to. This is important as the rule you make will apply to all folders under that file in the directory's hierarchy. Once we decided which container to apply the policy to, you can right click on the file [or container's] name and choose 'Create and link GPO here'.

A new menu appeared [titled 'New GPO'] and in it we named the policy. We were directed to name them "Login Script XXXX" where the Xs are replaced with our team name. When the script appeared in the directory, we right clicked it and choose 'Edit' so that we could define the policy. We then had to take this path to find the preset selection of policies we wanted to use. It is important to right click on the GPO and make sure 'enforce' is checked. This way your policy is activated, if you do not enforce it, your policy will not be implemented. You may choose to leave a policy as not enforced if you create them ahead of when you need them. This is the path we took:

In the cascading file system on the left, select: User Configuration >> Windows Settings >> Scripts [Logon/Logoff] 

We had to configure the policy and this took a lot of searching. The online help tutorials were helpful to certain points [we really like Daniel Petri's posts], but often they are not created by large network users, and so they are only helpful up to certain points. When this happens, we begin to 'guess and check' and when this proves to be not helpful, we ask the others how they are doing and what they are doing and if what they are doing is working ... we search for the answers using all the talent in the room and on the internet!

Another task for the day included creating a folder on the server that all the users would save their documents in. This is a basic step of creating a new folder, but then you have to be sure all your network users can access it. This is done by right clicking on the folder and choosing Sharing and Security > Sharing tab > Share this folder > Permissions > check the Read/Change boxes to allow all users the ability to read and change the documents in the folder.


Now that there is a place for our network users to store their documents, we had to create a path so that when they saved the document, it would be automatically saved to this file. To do this we had to map a drive. This was an interesting task. We first typed "net use s: \\ksserver\shared\" on a notepad document and then saved the file as 'login.bat' in the this folder path: C:\Windows\SYSVOL\sysvol\network5769\scripts\.  Now we have the file to save in and a way to get there. Now we have to redirect the documents to this file through this drive. This way our user's documents will be automatically saved through the root server to ours.

 Once again, we opened the Group Policy Management menu and created a new GPO in the correct file and named it accordingly.  When the policy appeared in the left hand file structure, we right clicked it, and edited  it through this path:

User Configuration >> Policies >> Window Settings >> Folder Redirection >> locate the folder on your server that you created for storing your user's files.

Now that all may have sounded easy, but believe me there were many moments of frustration and confusion. Finding the online materials with correct directions for our setting was not easy and things kept rolling along until I was sure we would never be able to catch up. EVER! However, many others in the class are having huge issues beyond their control and so I should celebrate the successes we have made. We did not get all tasks completed today. And we may not get through tomorrow's either. The patience of the instructor and the help from colleagues goes a long way to making this a worthwhile endeavour. 

Only three days left ...

Day 6: Active Directory

This week started with installing active directory on our server. This was fairly straightforward, actually. This can be done through the Server Manager (found in Administration Tools) by adding a role. Okay, that is not straightforward ... why it is called a role, I am not sure!

However, after clicking the 'Add Role' link, an 'Add Roles Wizard' opens and you can pretty much click through it. The first menu has a few suggestions about what you need to complete the task. In the following window, you will have to select what roles you wish to install. In this case, it is 'Active Directory Domain Services'. Click the box beside this and then click next.

The next window describes what you will be doing to set-up the active directory. Click next when you have read that screen. Then confirm that this is what you what you want to do by clicking next in the confirmation window. Now you have to wait until the installation process is complete. You will get a message of success when the process has completed correctly.

Back in the Server Manager, you will notice that there is a red X beside the Active Directory Domain Services. Click the link to go through the steps necessary to rectify this, which starts with running the 'dcpromo' command. This will open the 'Active Directory Domain Services Installation Wizard'. You have to appreciate when you get to go through a wizard!

Once again, there is a cautionary screen about some of the heightened security in this version of Window. When you go past this window, you have to determine whether you are creating a domain controller for an existing forest or creating a new forest. This terminology is derived from the term 'root', which the main network's active directory is called. Once you have created a root in your network, you have started the tree, which then connects with other trees creating a forest. The network we are creating will be one tree in the forest! Anyway, we are joining a forest, so we choose 'Existing Forest' and 'Add a domain controller to an existing domain'.

We had a little trouble here. We tried to join the network5769.local domain, using the Admin username and password, but we couldn't. It wasn't allowed for some reason. We played around with it for quite a while changing names and domains, etc. We took comfort knowing that the other teams were having the same issue and we all tried various troubleshooting measures and checked back and forth to see what worked. Finally one of us (certainly not me!) figured out that we were still routing through the University's network and this was causing all the problems for identification and authorization. This makes sense as the University network would not recognize our domain, administration passwords, servers or switches as we are not part of their network! So we had to direct our network through our mini-network for DNS services. This image shows the correct preferred DNS server with the alternate still accessing the incorrect server.


Once we were added successfully to the domain, we could then add our workstations to our tree in the forest. We had a little fun pondering whether or not a DNS request denial would be heard if our forest was empty ...


The next task was to add our workstations to the forest through our server's container in the Active Directory. This is where something strange happened. We went through the set up, which is pretty simple: Right click computer in the start menu > select properties > select 'change settings' in the 'Computer name, domain and workgroup settings' section > [you will get the system properties menu] under the computer name tab, select 'change' to the right of 'To rename this computer or change its domain or workgroup click change' > select 'Domain' and add the name of the domain you are adding to (we are using Network5769.local). Click 'okay' and we were indeed okay!

However, although other teams could see our workstations in the network's active directory, we could not see them on our server's active directory. This was odd as it simply seemed that our server's active directory was not updating. My partner worked on this for an extended time while I used another server to complete the next task. Finally he, by chance, clicked on the authorize option for ipv4 and then reauthorized it. Suddenlyour workstations appeared! Was this the trouble all along? Why?

 While he was troubleshooting, once it became obvious that it would only take one of us and we were nearly out of time, I used a neighboring computer to access our tree and add the containers 'Teachers', 'Students', 'Computers' and 'Groups'. I dragged and dropped the workstations into the 'Computers' folder. We were also to set rules for these, but we simply ran out of time. So that will be completed tomorrow.