Recovering Data From Hard Drive

Here is the procedure that I've created for the technicians at our company.

1. We purchase another hard drive of equal or larger capacity. We call this drive "new drive"

2. In a diagnostic machine (one that is already running an operating system and has two available IDE channels), we install both the drive that needs repair (we call this drive "old drive"), and the "new drive". We make sure the "new drive" is mounted and we create a partition of appropriate size and type (FAT or NTFS). Drives need to be jumpered properly so pay attention to this. NOTE: for your situation, you can use the 4th IDE channel for "new drive" - it may require removing the IDE cable from one of your CD/DVD drives temporarily

3. We use GetDataBack from Runtime Systems (http://www.runtime.org) (there are two versions, one for FAT and FAT32 partions and one for NTFS partitions) and scan the "old drive" for data. After the scan is complete, we dump that data onto the "new drive". We can do that iteratively for each partition that requires *recovery* (as opposed to data that can just be copied over because the partition is still readable)

4. We check "new drive" to make sure the data was recovered properly.

5. If the damaged partition on "old drive" has it's data recovered properly, we can eliminate that partition using Partition Magic.

6. We can then recreate the partition using Partition Magic and copy the data from "new drive" to "old drive"

7. If the operating system needs to be re-installed on "old drive" then we do that prior to moving data from "new drive" to "old drive"

In your situation: Reinstalling and writing over the partition has possibily eliminated some of the data that you want to restore.

Great Forum From Here

Troubleshooting Firewall

The recent release of Windows XP Service Pack 2 highlights one of the problems you can encounter whenever you change your client's security settings with a new firewall of any kind. Programs that may have once worked properly are blocked from operation until you set the firewall correctly. It's as true for Microsoft's firewall as it would be for Symantec's, Zone Alarm, or any other. The Windows Firewall is meant to replace the Internet Connection Firewall (ICF) and starts with the assumption that all ports that aren't required by a Windows service are to be blocked until you indicate otherwise.

The two most common problems encountered when a firewall blocks a needed port is that the program can't get server data or that the program isn't responding to the request of a client. You should suspect problems of this type with FTP, streaming, and mail programs that are having problems on a client. You'll also see problems with server based programs such as a Web server, file services, or when you attempt to access a system using a terminal session or remote desktop. Keep in mind that there are other possible issues here that could be problems, in particular things like remote procedure calls and DCOM settings. Still, firewall settings are a good first place to look.

The first time you launch a program that requires a blocked port, a dialog box called the Windows Firewall Security Alert appears asking you if you would like to unblock the port to allow the program to function. Say yes and the program is in business, say no and the program won't function correctly or will crash when it tries to access a service that it can't get to. Some programs require more than one port, so it's certainly possible that there is still a blocked port that is causing your client's problems. To help isolate the problem port you can use the Windows Firewall Netsh Helper to log all dropped packets.

To identify the ports you'll need to view the Netstat log. Open a command prompt, type NETSTAT –ano > NETSTAT.txt and then press enter to create the NETSTAT.TXT file that will hold all the log entries. Then at the prompt enter TASKLIST > TASKLIST.TST, press Enter and then type TASKLIST > TASKLIST.TXT to see what services are loaded for each process. When you open the TASKLIST.TXT file you should be able to locate the program of interest using the PID (Process ID number) that shows up in the Task List.

If you need to open another port you must log on as a system administrator and set an exception that unblocks the port in the firewall's administrator program. For the Windows XP Firewall, that tool is part of the Windows Security Center which is accessed from the Control Panel folder. To get there from the command line, open the Run dialog box, type WSCUI.CPL and then click OK. You'll want to click on the Exceptions tab and then add your port. You may also need to modify the scope using the Change Scope option. The scope sets which systems can participate in this type of network traffic. Finally, you'll also want to turn on Security Logging so that you can see the source of incoming traffic. That traffic is stored to the %Windir%\pfirewall.log file. Outbound traffic is not logged.

From www.searchnetworking.com

The Power of "ping"

Ping is one of the first (and handiest) tools in your troubleshooting arsenal. Ping is a basic Internet program that lets you verify that a particular IP address exists and can accept requests.

To be more specific, ping is an Internet Control Message Protocol (ICMP) protocol utility used to check connectivity on networks. ICMP is a Network layer protocol in the seven-layer Open Systems Interconnection (OSI) model. A ping packet is also called an Echo Request and is sent as an IP (Internet Protocol) datagram. Because ping packets are sent as IP datagrams, they are not considered reliable, in that the IP layer doesn't check for proper delivery of the packet. A packet sent back by the machine being pinged in response to your Ping Request is an Echo Reply.

In order to ping another computer, or host, simply type: "ping IP-ADDRESS" (ex. ping 192.168.2.88).

To ping someone by name, simply type, "ping london.nwtraders.msft." (You don't need the period or the quotation marks.)

What can you do with ping? For one thing, if you cannot connect to a host, you can use the following steps with ping to check network connectivity between your host and the remote system.

1. Ping someone by name on the other side of your router. For example, ping london.my.com, where london.my.com is the fully qualified domain name of a server on the other side of a router from you. Since you are pinging the remote computer by name, if this works, you know name resolution is working, and your network is OK through the router to that point. Since ping only works up to the network layer, it will not help if you are having any non-connectivity related problems with applications like Microsoft Office, etc., since it doesn't check anything higher than the network layer.

2. If Step 1 doesn't work, try pinging your loop back adapter (ping 127.0.0.1). This will usually be successful unless TCP/IP is not installed and configured correctly on the local machine. By the way, if you try the ping command and get a message that ping is not recognized as a command or file name, either the TCP-IP protocol isn't installed, or it has major difficulties (i.e. corrupted, files missing, etc).

3. Ping your PC's IP address to make sure it was added to the network correctly. If your IP address was not added to the network correctly you will need to correct this. This problem often happens when administrators are manually adding IP addresses to hosts on the network and they simply make a mistake inputting the IP address information. Dynamic Host Configuration Protocol (DHCP) is preferred by most administrators when assigning IP addresses for this reason. Since DHCP automatically assigns addresses, it doesn't make typos.

4. Ping your default gateway to see if you can reach it. If you can't ping the default gateway, try pinging a computer close to you on the same subnet to see if the gateway is malfunctioning.

5. Ping a computer on the other side of the gateway by IP address. If you can do this, but can't do step 1, name resolution isn't working.

Listed below are common ping error messages you may find when pinging. (These are taken directly from Windows 2000 Help):

• A response of "destination net unreachable" means there was no route to the destination. You need to check the routing table on the router listed in the "Reply from" address in the "Destination net unreachable" message. For more information about the routing table, see Understanding the IP routing table. A response of "request timed out" means that there was no response to the ping in the default time period (1 second).

• "A router is down." To check the routers in the path between the source and the destination, use the tracert command. For more information, see Using the tracert command.
• "The destination host is down." Physically verify that the host is running or check connectivity through another protocol.

• "There is no route back to your computer." If the host is running, you can check for a return route by viewing the default gateway and local routing table on the destination host.

• "The latency of the response is more than one second." Use the -w option on the ping command to increase the time-out. For example, to allow responses within 5 seconds, use ping -w 5000.

From www.searchnetworking.com

TOP 10 "show" command

One of the most important abilities a network administrator can have is the know-how to get information out of his network devices so he can find out what's going on with the network. In most networks, the staple of information gathering has been the "show" commands. Here are my top ten commands to know and love:

1. show version: Start simple; this command gives uptime, info about your software and hardware and a few other details.
2. show ip interface brief: This command is great for showing up/down status of your IP interfaces, as well as what the IP address is of each interface. It's mostly useful for displaying critical info about a lot of interfaces on one easy to read page.
3. show interface: This is the more popular version of the command that shows detailed output of each interface. You'll usually want to specify a single interface or you'll have to hit 'page down' a lot. This command is useful because it shows traffic counters and also detailed info about duplex and other link-specific goodies.
4. show ip interface: This often overlooked command is great for all the configuration options that are set. These include the switching mode, ACLs, header compression, ICMP redirection, accounting, NAT, policy routing, security level, etc. Basically, this command tells you how the interface is behaving.
5. show ip route: This indispensable command shows your routing table, which is usually the primary purpose of the box. Get to know the options on this command.
6. show arp: Can't ping a neighbor? Make sure you're getting an arp entry.
7. show running-config: This is an easy one. It tells you how the box is configured right now. Also, "show startup-config" will tell you how the router will be configured after the next reboot.
8. show port: Similar to the show interface command on routers, this command gives you the status of ports on a switch.
9. show vlan: With the trend toward having lots of VLANs, check this command to make sure your ports are in the VLANs you think they are. Its output is very well designed.
10. show tech-support: This command is great for collecting a lot of info. It basically runs a whole bunch of other show commands, and spits out dozens of pages of detailed output, designed to be sent to technical support. But, it's also useful for other purposes.

From searhnetworking.com

Top 10 things to know about network administration

1. The OSI model: Memorize it. It's almost a cliché, but understanding it is critical.
2. TCP/IP concepts: Learn to think in binary and get a firm grasp on bitmasks, subnetting, gateways (like the "default gateway") and how addresses are constructed (the network portion, the host portion, etc).
3. Stacks: Read about how the network stack is implemented on hosts. Get a good feel for what each component (the NIC, firmware, device drivers, the OS, etc) is responsible for. Once you understand this, troubleshooting is easy.
4. Layer 2: Learn how switches operate and how they're different from hubs and routers. Understand bridging, and get a general idea of what Spanning Tree Protocol does. Learn the difference between a collision domain and a broadcast domain, and then study VLANs.
5. Routing: Learn a routing protocol. Start with RIP, because it's easy. You don't need to be a guru, just get a general idea about how routers can exchange information about the network.
6. Services: Understand the role of DNS and DHCP and WINS and know their alternatives, like the host and lmhost files and static addressing.
7. Find yourself some good networking reference material. Whatis.com is a great for deciphering arcane acronyms.
8. Security: Read a little about how firewalls operate and other security technologies like VPNs. Understand the difference between authentication, authorization and accounting.
9. Output: Learn how to get status and information out of your networking devices. A good place to start is with the "show" commands (which will be featured in next week's tip).
10. Finally, do a walkthrough: follow data as it goes from one application to another. How does it get from the application, to being segmented, packetized, framed, and routed? How does your computer know what IP address to send the packet to? (DNS) How does it know what MAC address to send it to? (ARP) How does it know how big to make the frame? (MTU) How does a switch know which port to forward your packet out on? (FDB) How does a router know which interface to use? (routing table) If you can answer these questions, you're well on your way to being competent and productive.

From www.searchnetworking.com