Setting up Workstations

This morning we made sure to activate our Windows 2008 Server software. This took a little searching, but according to the folks at the website My Digital Life

you can type slmgr –ipk xxxxx-xxxxx-xxxxx-xxxxx-xxxxx in command prompt to activate. 

For those of you who need a decode on what that is:

        slmgr = software licensing manager

        -ipk = install product key

        xxx ... = the actual product key

Then we made some changes to the DNS server. First thing we wanted to check was to be sure that the server knew where to send traffic if it could not reconcile an IP address within our network. We reconfigured the DNS to send traffic to the main server, then also provided two back-up servers from a couple of the other teams around us should this ever happen. This way, information coming in will go through at least four servers and, unless those other teams used the same servers we did, up to six in order to find the correct destination of the IP address. This was no too complicated to do once we knew to open the DNS properties and add the IP addresses of those servers. Because the DHCP and the DNS share information, we did not have to enter it all again. 

The final task was to set up two workstations with Windows 7 and make sure they had internet access, could retrieve shared information from the server and also place information on the server's shared file.

For the install we found Robert Cowart and Brian Knittel at Computer World , Daniel Petri at Petri IT Knowledgebase and the folks at Finest Daily to have great visuals and information. Basically you insert the disk and press F12 before the installed operating system boots so that the CD begins the install process [you may have to choose to boot from the disk drive]. Then you follow the screens and make a few decisions along the way.

The first choice we had to make was naming the computer. The advice on the internet is basically directing home users, so the username and computer name are really of little importance. In a network this is more important. Most importantly, we had to make sure that Administrator is a user on the computer so that we can, well, administer! But the name of the computer has nothing to do with the user name [by default windows will use the username as part of the computer name], so we typed in a name as provided in the network plan we choose for this course. We also had to ensure that the computer was assigned to the network's workgroup [this took a little searching] and make sure all necessary drivers were installed. All of this took place shortly after we installed Windows 7 updates ... never forget your updates!

After the hunting exercise yesterday, we had a much easier time with it all. Updating the system, finding and installing the drivers, this is all basically the same as yesterday. However, we could not find the appropriate drivers for Windows 7. According to the support offered from Dell regarding Windows 7 compatibility for drivers, we were safe to use the drivers for Vista 32-bit instead.
Our final task was to get information from the server onto the workstation as well as share information from the workstation with the server. We were able to do this after the files on the server were opened for sharing.

Funny, though, as I  thought this was done the day before ... strange!

DNS, DHCP and Other Members of the Alphabet

Image found at http://abstrusegoose.com/strips/ping.png

The morning started where we left off the previous day. More server work!

Our tireless leader worked hard to make sure we had internet connection through our switches. So we started the morning by contacting the other switches by sending a ping request from our workstations. There was much rejoicing as we were able to make contact!

Then we began downloading updates for the server. 

 The next step was to make sure we were able to use telnet to manage our switch. Macs apparently have an easier time with that, but my ol' Dell needed some tweaking. *sigh* The good thing is that it is as simple as checking a box!

We then discovered various ways to manage the switches in our networks. Telnet is one way to access, Webview is another as is Cool Term. You can use any of these to manage work stations in your network through accessing the switch. Through your switch you can manage The good thing is that most of the commands are the same, but there are benefits to using some over others, such as batch processing through telnet and mobile access through Webview.

Through Webview, Ethernet network interface status is visible. You are able to see connection status of other switches, servers and workstations on your network.

One way of managing your network is to direct network traffic by completing routing tables. In this way you can route traffic around content filters or limit what others network users can see. In order to increase functionality, all of our switch addresses were manually typed into the routing table of the main switch. Each of our switches should have four entries in their routing tables. Using telnet, we verified that this was true for our network.

The next task for us was to set up a DHCP servers on our routing table.  We used this resource for this: http://www.windowsreference.com/windows-server-2008/how-to-setup-dhcp-server-in-windows-server-2008-step-by-step-guide/

Then we set up the DNS server! Don't tell anyone, but I think I am getting the hang of this!

Another task for the day was to create a folder on the server that could be shared with other users on the network. After making sure that we allowed all network users to have full control and the ability to change instead of only being able to read the folder contents, we added a document on another server in the network. This kind of access came in handy later in the day when one group managed to get all of the downloads we needed. They kindly stored them in a shared folder!

Another part of the day's work was to make sure our server had all the necessary drivers for full functioning.  At first, we tried to update through the automatic update settings found by clicking on the drivers with an error message. That did not work.

So we downloaded a driver detective on the server and ran a diagnostic. We were unable to locate the drivers without paying for the service, so we scrapped that. We located the driver downloads, but the server did not recognize them. We assumed that meant they were the wrong drivers. That was a mistake.

Although I am not sure, I believe the error was simply that the server had not completed the updates we started getting at the beginning of the day. This seems to have interfered with our progress significantly!

While trying to access the internet from the server, many security warnings popped up. This was all too annoying, so we went to this site and changed the setting: http://www.404techsupport.com/2009/01/08/remove-internet-explorer-enhanced-security-configuration/

Finally to test internet connectivity, we booted a work station with Knopix operating system to make sure the DCHP server would assign a dynamic IP address when requested. At first we loaded the system on our server – WHOOPS! Not to worry - it is just another reboot!

We had a little difficult getting the work station connected, so we tried to reboot, change out towers, check connections ... check both ends of the connection and viola! The ethernet cord was a little loose. All it took was a little wiggle to get things done!

Not sure how techy that is! SHEESH!

Pinging and the Windows Server 2008

The day started with rebooting our switches. *Whew* ours was working! 

[NOTE: we did experience some rough times early in the day. First we did not have all of the cables connected, then we did not have the proper IP addressing on our computers as we forgot to undo yesterday's work, finally we actually have to turn the switch on in order for it to function.]

As a recap of yesterday's work that did not work, we reviewed the various IP addresses and subnet masks to discuss whether or not they would work and most importantly WHY!

Here is a break down of what should have happened:

It turns out that the computers will not respond to each other (with the occasional exception of a Mac) if the subnet masks are different or they reveal the networks are not the same. Same network and same subnet masks are needed for successful communication.

However, if this was true, wouldn't that mean a computer with a class A IP address would not be able to ping a computer with a Class C or B IP address ... this will have to be clarified in the morning!

The morning continued with some more configuring of our switch. We need the switch to recognize one of the ports as the route to the internet through a hop. To do this, we had to type in a series of prompts:

• vlan 2 
• ip interface vlan-2 address 192.168.16.254 mask 255.255.0.0 vlan 2
• ip static-route 0.0.0.0 mask 0.0.0.0 gateway 10.0.1.254    
• vlan 2 port default 8/1

Now, before we started, we were told that we should make sure we had configured correctly from the day before. We were to enter this command: 'aaa authentication default local'. But we had concerns about not accessing the internet, so after typing the above commands, we re-authenticated.  "default local" and "http local" ... and ... and ... what would it hurt to enter 'aaa authentication default local' one more time after we start? Well apparently there is an issue if you enter some commands out of order. Good to know. 

Reload the switch.  Re-type all commands - IN ORDER. Remember to 'write memory' and 'copy working certified'. Those you can do any time! :)

The next thing we were supposed to do was to make sure our clients were able to connect to the layer three switch - the next hop we configured. However, some error occurred and we were not able to successfully ping either switch. But never fear! There is always something else to be done!

We were given a task to take inventory of the computer we were going to use as a server, which will be the next step in this process. The inventory is as follows:

Total amount of RAM:  2 x 512 + 2 x 1GB [total 3 GB] DDR2

Hard Drive Capacity: 2 x 160 GB

Total number of USB ports:  8 [two front; six back]

Total number of Firewire ports: 2 FW0A823019M MIC E-G900-04-0123(B)

Type of DVD drive: Sony NIC Optiarc Inc   AD-7200S DVD/CD RW serial ATA

Type of Video port(s):  S-Video and DVI

Network Interface Card type: MIC 00-10-18-34-8688 E-G021-04-2613 (B)

                                                      PCI Express BCM5721 gigabit ethernet

NIC Maximum Speed: 1000 Mb/s

Video Interface Card type: ATI Radeon 102 B27602 (B) B276

Motherboard manufacturer: Dell

Computer manufacturer: Dell

Computer: DCSM serial # 73HYLG1   

Monitor manufacturer: Dell

Monitor: 1704FPTt

We also had to check the minimum requirements for running Windows Server 2008 to ensure computer So, do we meet the minimum requirements? According to this table, it appears so:

This information was taken from: http://www.microsoft.com/windowsserver2008/en/us/WS08-system-requirements.aspx
 

The last thing of the day was to install the server software. This was a little time consuming, but not too bad in the way of problem solving. Many more references online were needed to get through the process, but it really was straightforward! Mostly it was waiting for the program to run its course and selecting the right choices as we went along. 

So except for some difficulty with connecting with the layer three switch of our network, we had a very successful day.

Subnet Masks and Assigning IP Addresses

Image by saschaaa available on Flickr at: http://www.flickr.com/photos/saschaaa/152502539/sizes/m/in/photostream/



If you are wondering what these posts have been about, please let me explain.
#1: I am working on my masters of education through the University of Lethbridge.
#2: My current course is System Development, which includes setting up a network of computers. Yesterday we programmed a switch which will be the gateway for the network my partner and I will be building over the next two weeks.

Wow! What fun, right? And just so you know, I did laugh a couple of times!

So today we rebooted the switch (which was properly programmed the day before!) and we set about connecting our laptops to the switch. We had to assign static IP addresses and ping to test connectivity. Many problems arose, but we did manage to get it mostly completed. Pinging proved problematic. I could get signal from my computer to the switch and to my partner's laptop. But he could only receive signal from the switch and not my computer. I felt certain the trouble was with the picture of an apple on the front of his laptop, but alas I was incorrect. And some of the ribbing I had given him over this was returned to me ... but only a small portion.

Turns out the trouble was with the firewall on my division-owned computer. The one that I thought I had complete administrative control over. It also turns out that I cannot turn off the firewall, but with a little playing around we discovered I could create a rule that allows ping requests be accepted and returned. That helped! But the activity to test various IP addresses and subnet masks did not work so well. We struggled with it for some time with no reliable results. On the up side we were not the only ones having trouble; on the downside we will have to pick up the pace in the course tomorrow.

Here's a test for you techies; look at the images below. What is the difference? [Hint: think fat fingers]

IT Leadership: Setting up an Alcatel Switch

Ahhh ... back in Lethbridge, back at the college, back to work! Today marked the first day back with the cohort and the beginning of the last summer courses together. With a team member we began the assembly of a network starting at level one, the physical layer. The first task (the one that took all class and more) was to connect to and assign an IP address to an Alcatel 6648 Omniswitch. Fun stuff!

The major barrier was finding the instructions to do this. Apparently no one has developed a quick and easy guide that can be accessed through a simple internet search. Instead there are at least two guides needed to successfully complete the assigning of an IP address to a switch, it is possible that you actually need three. Many of these are well hidden on the Alcatel website and others can be found. There are rumours that we will need up to eleven such guides to get through the next two weeks of tasks! All of this has provide insight into the personality stereotypes generally given to IT personnel. No doubt they tend to be reclusive!

In the end the steps are such:
- Download and install Coolterm Win (if your computer is using a Windows operating system). This is not as easy as it sounds as you have to find the driver that works for your computer. I am running Windows 7 and my partner is on a Mac. With trial and error we got my computer to install (we used the Vista version)
- Connect your computer to the switch using a cable
- Now find the switch on Coolterm; you may have to restart first; it is also handy to know that the Latitude E5510 has its own serial port, so you will have to choose Com 3 [at least in my case] instead of the Com 1 that comes up
- Check the settings of the switch on Coolterm
- Connect to the switch by clicking the 'Connect' icon
- Type in the default login and password when prompted
- Type in the command "ip interface vlan-1 address 192.168.16.254 vlan 1" *of course the address typed will be the one appropriate for your switch!*
- Type in the command "write memory"
- Type in the command "copy memory certified" [This is important to know: you are working on the 'working' copy - a work in progress - and to actually write your changes permanently on the switch, you have to copy your working changes onto the certified copy - which is the 'hard' copy.]
- Then you can reboot your switch by typing the command "reload"
- Once the switch is operational again, login using the default settings [there is a process to change the default login, which a person would do if this was real life, but today we did not as this is NOT our permanent equipment and someone else will need access when class is over :)]
- Check the IP address assigned to the switch by typing "show IP interface"
- You have done this successfully if you get this screen:

See how the IP address is showing? That is what we wanted!!!

This was a learning day for sure! Essentially I learned that the help of those who have experience or training (and especially BOTH) is truly invaluable in these situations, even if you have an extensive and difficult to navigate user manual (or six). To call on those who can and are willing to help after your feeble attempts have begun to overwhelm is the most important lesson. It is so great that there are several of these kinds of people (so much for stereotypes!) in this cohort.

ps. The references for the vast list of manuals that may come in handy to work with Alcatel 6600 and 6800 series of switches would look like this:
Alcatel Internetworking Inc. (2005, March). Alcatel OmniSwitch: CLI Reference Guide (Part No. 060158-10, Rev. G). Retrieved from http://www.scribd.com/doc/27892885/Omniswitch-CLI-Refernce-Guide

Alcatel Internetworking Inc. (2005, March). OmniSwitch 6600 Family: Advanced Routing Configuration Guide (Part No. 060187-10, Rev D) Retrieved from http://wedophones.com/Manuals/Alcatel/OmniSwitch%206600%20Advanced%20Routing%20Configuration%20Guide%20R5-1.pdf

Alcatel Internetworking Inc. (2005, March). OmniSwitch 6600 Family: Getting Started Guide (Part No. 060178-10, Rev. E). Retrieved from http://wedophones.com/Manuals/Alcatel/OmniSwitch%206600%20Getting%20Started%20Guide%20R5-1.pdf

Alcatel Internetworking Inc. (2005, March). OmniSwitch 6600 Family: Switch Management Guide (Part No. 060180-10, Rev. E). Retrieved from https://service.esd.alcatel-lucent.com/search/query/display.jsp?type=file&f_url=new_search_docs%2Ftarget%2Fdocs%2Fomniswitch_6600%2Fmanuals%2FOS66_Switch_Management_Guide_Rev_E.pdf#search="ipv6"

Alcatel Internetworking Inc. (2007, December). OmniSwitch 6800 Series, OmniSwitch 6850 Series, OmniSwitch 9000 Series: Advanced Routing Configuration Guide (Part No. 060216-10, Rev. E). Retrieved from http://www.alcatel-lucentbusinessportal.com/private/active_docs/os68-90_ar_631r01.pdf

Alcatel Internetworking Inc. (2007, December). OmniSwitch 6800 Series, OmniSwitch 6850 Series, OmniSwitch 9000 Series: Network Configuration Guide (Part No. 060198-10, Rev. B). Retrieved from http://ligf.cn/doc/6800/os68_net.pdf

Alcatel Internetworking Inc. (2007, December). OmniSwitch 6800 Series, OmniSwitch 6850 Series, OmniSwitch 9000 Series: Switch Management Guide (Part No. 060215-10, Rev. E). Retrieved http://dinf.ru/Doc_base/omniswitch_6850_user_guide_SW.pdf

Alcatel Internetworking Inc. (2007, June). OmniSwitch 6800 Series: Getting Started Guide (060195-10, Rev. D). Retrieved from http://wedophones.com/Manuals/Alcatel/OmniSwitch%206800%20Getting%20Started%20Guide%20R6.pdf

Alcatel Internetworking Inc. (2007, June). OmniSwitch 6800 Series: Hardware Users Guide (Part No. 060196-10, Rev. G). Retrieved from http://wedophones.com/Manuals/Alcatel/OmniSwitch%206800%20Hardware%20Users%20Guide%20R6.pdf

Alcatel Internetworking Inc. (2006, April). OmniSwitch 6600 Family: Network Configuration Guide (Part No. 060179-10, Rev. F). Retrieved from http://wedophones.com/Manuals/Alcatel/OmniSwitch%206600%20Network%20Configuration%20Guide%20R5-1.pdf

Alcatel Internetworking Inc. (2006, September). OmniSwitch 6600 Family: Hardware Users Guide (Part No. 060181-10, Rev. G). Retrieved from http://www.alcatelbusinesspartner.com/private/active_docs/os6600_hdw_541.pdf?CFID=122707&CFTOKEN=98828638