Networking on the Net
Posted On Wednesday, 9 September 2009 at at 00:59 by Jhonby: C. J. Hayden
Data Collected from Web http://information-technology.smartads.info/
Networking is one of the most effective ways to find clients for any consulting or professional services business. But if you limit your networking to only what you can do in person, you'll be missing out on a huge number of possibilities.
Networking is more than entering a room full of people and exchanging business cards. It's creating a pool of contacts with whom you can exchange clients, referrals, resources, ideas, and information. Networking can happen by phone, by mail, over coffee, and increasingly, over the Internet.
The growth of the Internet has created many new ways to network without ever leaving your home or office. Pick a topic, any topic, and there will be multiple web sites and online communities devoted to it. Almost any type of Internet presence offers opportunities for networking.
In your favorite search engine, type the name of your profession or specialty, e.g. "interior design" or "marketing communications." Or, if you have a clearly defined target market, you can use that, e.g. "baby boomers" or "biotechnology." Skip the sponsored links or banner ads and focus on the detailed results. What you will find is the following:
Professional Associations & Schools -- Many association or school sites provide member rosters, resource pages, back issues of newsletters, event calendars, and bulletin boards or discussion lists. Not all of these features will be restricted to members or students.
Resource Sites & Online Communities -- These include directories of people in the profession, vendors, articles, event calendars, bulletin boards, discussion lists, live chats, and links to even more resource sites.
Publications -- Magazines and newsletters maintain sites that offer everything from back issues to complete online communities.
Job Postings -- These may appear on any of the above sites, and often include opportunities for independent professionals, not just those looking for full-time employment.
Colleagues & Competitors -- Colleagues and competitors may be exactly the same people, depending on your relationship with them. Their sites will tell you more about them and their work, and may offer many of the same features as resource sites.
Potential Clients -- Their sites will tell you about the work they do, current and upcoming projects, and even the names of executives and managers.
Also, if you subscribe to an online service offering interactive "channels," like America Online, CompuServe or MSN, there may be an entire area dedicated to your profession or target market. Some of these resources are available to non-members as well.
Now, how can you use all this information to network? Here are some of the most common ways:
Bulletin Boards -- These are web pages where you can view and post questions and comments on a specific subject. Answering a posted question is an excellent way to demonstrate your expertise, become known to the people who frequent the board, and get to know others in your field.
Don't be overly self-promotional when posting, just include a signature line at the end of your post, e.g. "Ingrid Gustafsson, Nordic Design." If you see someone else on the board who you would like to get to know in a collegial way, e-mail them. But never directly approach for business the people you find there. You might find yourself banned from membership.
Discussion Lists -- These are like bulletin boards, but are e-mailed to members of the list daily, weekly, or whenever a new posting arrives. When posting to these lists, you can include more information about yourself in a signature box at the end of each e-mail. Keep it short, but include some reason for people to get in touch with you outside the list, such as, "Subscribe to my free newsletter," or, "Visit my web site for a free resource guide."
In addition to locating discussion lists through search engines as described above, you can find them through online community hosts such as Yahoo Groups or MSN Groups.
Live Chats -- Many online communities sponsor real-time chats on specific topics. Participating in these chats is an excellent way to meet people interested in the subject being discussed. Chat rooms that require membership are best, because you are more likely to encounter professionals seriously interested in the topic instead of people just looking for a date.
Attending chats featuring a guest speaker can be more valuable than you might think. If you ask a question during one of these, don't be surprised if people contact you by e-mail during or after the chat to offer you more resources related to your question. You can make exactly the same type of contacts when you are the one who has something to offer.
Articles -- Notice who is writing them and who is being written about. These people are likely to be leaders in your field, or at least highly visible. That makes them good contacts for you. Send them an e-mail complimenting them on the article and suggesting you get acquainted for mutual benefit. Make a specific suggestion about what you can offer, e.g. referrals or resources.
Others in Your Field -- These may be colleagues, competitors, vendors, or potential clients. Approach them collegially with ideas about how a relationship could benefit you both, such as exchanging referrals, pooling resources, links on each other's web site, or trading endorsements or articles in each other's ezine.
If you can't find a board, list, chat, or site with the exact focus you want, consider starting one of your own. While hosting one of these communities takes time and effort, it will also put you in the center of the network that forms around it instead of on the outskirts.
About The Author
C.J. Hayden is the author of Get Clients NOW! Thousands of business owners and salespeople have used her simple sales and marketing system to double or triple their income. Get a free copy of "Five Secrets to Finding All the Clients You'll Ever Need" at http://www.getclientsnow.com
Data Collected from Web http://information-technology.smartads.info/
Troubleshooting Basic TCP/IP Problems
Posted On at at 00:54 by Jhon
Data Collected from Web http://www.windowsnetworking.com/
Over the last several years, TCP/IP has gone from being the protocol that only geeks use, to a universal protocol that everyone uses, thanks to the widespread use of the Internet. TCP/IP has been around for decades and is a solid, reliable, mature protocol. Most of the time when there is a TCP/IP related problem, the problem is related to the way that one or more of the hosts on the network are configured. In this article, I will walk you through the process of troubleshooting some common TCP/IP issues. | |
|
Step 1: Check the Configuration
The first step in the troubleshooting process is to check the TCP/IP configuration. The easiest way to do this is to open a Command Prompt window and enter the IPCONFIG /ALL command. Windows will then display the configuration results. It’s important to point out that some computers have multiple network interface cards, and Windows may also treat a Firewire port as a network adapter. You must therefore be careful to make sure that you are looking at the configuration that’s bound to the interface that’s actually connected to the network.
If the configuration appears to be blank, then the interface has not been assigned an IP address. IP addresses can be assigned manually, or via a DHCP server. If your organization uses a DHCP server to assign IP addresses, then try entering the following series of commands to see if the machine is able to obtain an IP address:
IPCONFIG /RELEASE
IPCONFIG /RENEW
IPCONFIG /ALL
If the machine is still unable to obtain an IP address, then there are several things that could be causing the problem. For example, the DHCP server might have already given out all of its addresses. You can check the server’s logs to see if this is the case. Another possible cause is that you might have a bad network cable. Try attaching another machine to the network cable / network jack that the malfunctioning machine is attached to and see if the known good machine is able to attach to the network.
Still another possible problem is that the network card is not installed correctly through Windows. In most cases, Windows XP will automatically detect a network card and load the drivers for it automatically. However, Windows XP is notorious for misidentifying network cards. If you are having trouble attaching to the network, it might be a good idea to pop the computer’s case open and check to make sure that the make and model of the network card that’s installed matches the driver that is loaded into Windows.
If the driver matches and you are still having problems, try going to the network card manufacturer’s Web site and downloading the newest driver for the card. I have seen several situations in which a new driver fixed the problem If you have tried everything that I have suggested and are still unable to acquire an IP address, try reseating or replacing the network card. Network cards have been known to go bad for no apparent reason.
Communications Failure
If your NIC has an IP address associated with it, but the machine is unable to communicate across the network, then you will have to use a slightly different approach to troubleshooting the problem. The first question that you need to consider is the source of the IP address. Was the address entered manually into Windows, or was it leased from a DHCP Server?
If the address came from a DHCP server, then you can eliminate a lot of possible causes of the problem right now. If the machine is able to lease an IP address, then it means that the computer’s network card is functioning and that the connection to the switch is good. Don’t be deceived though. When a computer leases an address from a DHCP Server, the lease is valid for a specific period of time. If the machine has successfully leased the address in the past, but the lease has not yet expired, then it might appear that the machine has obtained a lease, when in reality the machine is holding onto an IP address that it acquired during a previous session. The easiest way to find out for sure what is going on is to use the IPCONFIG /RELEASE and the IPCONFIG /RENEW commands to get rid of the old lease and acquire a new one.
If the NIC has an IP address, but the address has been assigned manually, then the first thing that you will need to do is to perform some basic connectivity tests. You can do this in much the same way as I talked about earlier. Try plugging a known good PC into the network connection to make sure that the connection is good. Make sure that the NIC has the correct drivers. In essence, you will want to make sure that your hardware is functioning before you continue.
Once you have done some basic hardware testing, open a Command Prompt window and try pinging the computer’s own IP address. If the ping is successful, then it means that the TCP/IP protocol stack is at least functional. If you receive an error message stating “Destination Host Unreachable” then it means that there is something wrong with the way that the machine is set up. It could be that Windows doesn’t recognize the network card, or it could be that a necessary system file has been deleted or corrupted. You might try removing and re-installing the network card and its drivers. If that doesn’t work, try re-applying the Windows Service Pack since doing so will refresh all of the system files.
Assuming that the machine is able to ping itself, try pinging another machine on your network by IP address. If your machine is able to ping itself, but is not able to ping another computer on the network (by IP address) then I recommend trying to ping a few more computers. If you are not able to establish communications with any of them, then look for a bad network link or perhaps a bad network card.
If you are able to successfully ping other machines on your network by IP address, try pinging those machines by hostname. If you don’t know the hostname, then you could use the ping /a command against the machine’s IP address to resolve the address to a host name. Another alternative is to ping a Web site. Most Web hosts block pings, but as of the time that this article was written, http://www.espn.com/ would still respond to pings.
If you are able to ping machines on your network and on the Internet by host name, then your machine is successfully communicating. If you can ping by IP address but not by hostname, then the problem is probably DNS related. Enter the IPCONFIG /ALL command to make sure that your machine is configured to use a DNS server. If there is a DNS server specified, make sure that the DNS server’s IP address has been entered correctly. If everything appears normally, try pinging the DNS server to make sure that you can communicate with it.
If you can ping the DNS server, the DNS server’s IP address has been entered correctly, and the DNS server seems to be resolving addresses for other people on your network, then the problem probably isn’t DNS related. I recommend checking your HOSTS file. It is located in the C:\WINDOWS\SYSTEM32\DRIVERS\ETC folder. The HOSTS file is a legacy component of TCP/IP that really isn’t used anymore. It was previously used to associate a Web site with an IP address before DNS became popular. Today, a lot of browser hijackers and various forms of spyware work by altering the hosts file. Try displaying the HOSTS file through Notepad. You might be surprised at what you see. If you see entries that shouldn’t be there, you can either delete them or delete the entire HOSTS file.
Conclusion
In this article, I have explained that configuration problems can prevent TCP/IP from functioning correctly. I then went on to discuss the TCP/IP troubleshooting process.
Data Collected from Web http://www.windowsnetworking.com/
Making Sense of Windows Routing Tables
Posted On at at 00:51 by JhonData Collected from Web http://www.windowsnetworking.com
| It’s amazing the way that time can go by. People tend to think of computers as being high tech, but the TCP/IP protocol has been around in one form or another for over three decades. As such, TCP/IP has had time to really mature and be made stable and reliable. When it comes to computers, nothing is foolproof though. When routing packets across a network, things do occasionally go wrong. In these situations, it is helpful to be familiar with the Windows routing tables. Routing tables dictate the flow of packets from the machine in question. In this article, I will show you how to view the Windows routing tables and how to make sense of the data that is contained within it. | |
|
Viewing the Routing Tables
The routing tables are an important part of Windows’ TCP/IP protocol stack, but they aren’t something that the operating system normally displays to the casual user. If you want to see the routing tables, you will have to open a Command Prompt window and then enter the ROUTE PRINT command. Upon doing so, you will see a screen similar to the one that’s shown in Figure A.
Figure A: This is what the Windows routing tables look like
Before I delve into the routing tables, I recommend entering another command into the Command Prompt window. The command is:
IPCONFIG /ALL
The reason why I am recommending that you use the IPCONFIG /ALL command is because it shows you how TCP/IP is really setup on the machine. Sure, you could look in the TCP/IP section of the network adapter’s properties sheet, but the information is more reliable if you get it from IPCONFIG. I have seen a couple of instances over the years in which IPCONFIG reported completely different information than what was entered into the machine’s TCP/IP configuration screen. This doesn’t happen often, but if the right type of error occurs you can experience this type of mismatch. To put it bluntly, the information that’s keyed into the TCP/IP properties sheet reflects how you would like Windows to set up the TCP/IP protocol for the choosen network. The information presented by IPCONFIG shows how Windows has actually configured the protocol.
Even if you haven’t had some bizarre Windows error, it’s still useful to get your configuration information through IPCONFIG. If a machine has multiple network cards, it can be tough to remember which configuration is bound to which card. IPCONFIG lists the various configurations in an easy to read, per NIC basis, as shown in Figure B.
Figure B: The IPCONFIG /ALL displays the machine’s TCP/IP configuration on a per NIC basis
Examining the Routing Tables
Right about now you might be wondering why I had you to do an IPCONFIG /ALL, when this article is supposed to be discussing routing tables. The reason for this is that normally you never even look at the routing tables unless you are having problems with your machine. If you are having problems, then the best place to start the troubleshooting process is to compare the information provided by IPCONFIG to the information stored in the routing tables.
As you saw in Figure B, the IPCONFIG /ALL screen displayed some basic TCP/IP information such as the IP address, the default gateway, etc. The routing tables aren’t quite as intuitive though. Therefore, I want to take some time to discuss how to read the routing tables and what the information in the tables mean.
In order to understand what the information in these columns mean, you need to understand a little bit about how a router works. A router’s job is to facilitate moving traffic from one network to another. As such, a router will contain multiple network interface cards, each connected to a different network segment.
When a user sends a packet that’s destined for a different network segment than the one that the PC is presently attached to, the packet is sent to the router. It is up to the router to figure out which network segment the packet should be forwarded to. It doesn’t matter if the router is connected to two network segments or a dozen. The decision making process is the same, and it’s all based on routing tables.
If you look at the Route Print screen, you will notice that the routing tables are divided into five different columns. The first column is the network destination column. This column lists all of the network segments that the router is attached to. The Netmask column provides the subnet mask not of the network interface that’s attached to the segment, but of the segment itself. This basically allows the router to determine the address class for the destination network.
The third column is the gateway column. Once the router has determined which destination network it needs to send the packet to, it looks at the gateway listing. The gateway listing tells the router which IP address the packet should be forwarded through in order to reach the destination network.
The Interface column tells the router which NIC is connected to the appropriate destination network. Technically, the interface column only tells the router the IP address that has been assigned to the NIC that connects the router to the destination network. However, the router is smart enough to know which physical interface the address has been bound to.
The final column in the routing table is the Metric column. Metrics are a science in themselves, but I will try to give you a brief explanation of what they do. The best way that I have ever heard metrics explained is in terms of an airport. Imagine for a moment that I needed to fly from Charlotte, NC (the closest major airport to my home in South Carolina) to Miami, Florida. Being that the Charlotte airport is pretty big, I have a lot of choices of how I could get to Miami Beach. I could hop a North West Airlines flight. It would take me to Detroit Michigan and then down to Miami (Detroit is a bit out of the way). Likewise, I could hop a Continental Airlines flight that would take me to Houston, TX, and then to Miami. Another option would be to just take a US Airways flight nonstop to Miami. So which airline should I take?
In real life, there are a lot of factors to consider such as the price of the ticket and the departure times, but let’s assume that everything was equal. If there were no differences between the airlines other than the route, then I would fly the airline that makes the fewest stops. It would get me to my destination more quickly, and since there are fewer stops, there would be less chance of having a problem with my connection, lost luggage, and things like that.
Routing works the same way. Many times, there is more than one way that a router could send a packet. In such a case, it makes sense to send the packet along the shortest (or most reliable) path. This is where the metrics come into play. Windows does not even look at metrics unless there are multiple paths to a destination. If there are multiple paths though, Windows checks the metrics to determine the shortest route. This is an over simplified explanation, but it gets the point across.
Additional Routing Options
Earlier, I showed you the Route Print command, but there are actually a lot of other things that you can do with the ROUTE command. The ROUTE command’s syntax is as follows:
ROUTE [-f] [-p] [command [destination] []
The –f switch is optional. This switch tells Windows to clear the routing table of all gateway entries. If the –f switch is used in conjunction with other commands then all gateway entries will be cleared prior to executing other instructions within the command.
The –p switch makes a specified route persistent. Normally, when a server is rebooted then any routes that you specify via the ROUTE command are removed. The –p switch tells Windows to keep the route even if the system is rebooted.
The command portion of the ROUTE command’s syntax is relatively simple. The command set consists of four options PRINT, ADD, DELETE, and CHANGE. I’ve already shown you the ROUTE PRINT command, but even the ROUTE PRINT command has other options. For example, you can use wild cards with this command. For instance, if you only wanted to print routes pertaining to the 192.x.x.x subnet, you could use the command ROUTE PRINT 192*.
The ROUTE DELETE command works very similarly to the ROUTE Print command. Simply enter the ROUTE DELETE command followed by the destination or the gateway that you want to delete from the routing table. For example, if you wanted to remove the 192.0.0.0 gateway, you could enter the command ROUTE DELETE 192.0.0.0.
The ROUTE CHANGE and the ROUTE ADD commands have the same basic syntax as each other. When you enter this command, you must usually specify the destination, subnet mask, and gateway. You might also specify a metric and an interface, but that’s optional. For example, if you wanted to add a destination using the bare minimal syntax, you could do so as follows:
ROUTE ADD 147.0.0.0 255.0.0.0 148.100.100.100
In this command, 147.0.0.0 is the new destination that you are adding. 255.0.0.0 would be the subnet mask for the destination, and 148.100.100.100 would be the gateway address. You can extend the command with the METRIC and IF parameters. Doing so would look something like this:
ROUTE ADD 147.0.0.0 255.0.0.0 148.100.100.100 METRIC 1 IF 1
The metric parameter is optional, but it specifies the metric or number of hops for the route. The IF parameter tells Windows which NIC to use. In this particular case, Windows would use the NIC that’s bound to Windows as interface 1. If you don’t use the IF parameter then Windows will automatically search for the best interface to use.
Conclusion
In this article, I have explained how to use the ROUTE command to display the Windows routing tables and make changes to those tables if necessary. If you need a little extra help, you can get more syntax examples by entering the ROUTE /? Command.
Data Collected from Web http://www.windowsnetworking.com
Troubleshooting Logon Problems
Posted On at at 00:46 by JhonData Collected from Web http://www.windowsnetworking.com/ This article discusses some of the more common causes of logon failures in Active Directory environments. | |
|
Logging into a computer is such a routine part of the day that it is easy to not even think about the login process. Even so, things can and occasionally do go wrong when users log into Windows. In this article, I will talk about some of the things that can cause logon failures, and show you how to get around those problems.
Before I Begin
Before I get started, I just want to quickly mention that in order to provide as much useful information as possible, I am going to avoid talking about the most obvious causes of logon failures. This article assumes that before you begin the troubleshooting process, you have checked to make sure that the user is entering the correct password, the user's password has not expired, and that there are no basic communications problems between the workstation and the domain controller.
The System Clock
It may seem odd, but a workstation's clock can actually be the cause of a logon failure. If the clock is more than five minutes different from the time on your domain controllers, then the logon will fail.
In case you are wondering, the reason for this has to do with the Kerberos authentication protocol. At the beginning of the authentication process, the user enters their username and password. The workstation then sends a Kerberos Authentication Server Request to a the Key Distribution Server. This Kerberos Authentication Server Request contains several different pieces of information, including:
- The user’s identification
- The name of the service that the user is requesting (in this case it’s the Ticket Getting Service)
- An authenticator that is encrypted with the user’s master key. The user’s master key is derived by encrypting the user’s password using a one way function.
When the Key Distribution Server receives the request, it looks up the user’s Active Directory account. It then calculates the user’s master key and uses it to decrypt the authenticator (also known as pre authentication data).
When the user’s workstation created the authenticator, it placed a time stamp within the encrypted file. Once the Key Distribution Server decrypts this file, it compares the time stamp to the current time on its own clock. If the time stamp and the current time are within five minutes of each other, then the Kerberos Authentication Server Request is assumed to be valid, and the authentication process continues. If the time stamp and the current time are more than five minutes apart, then Kerberos assumes that the request is a replay of a previously captured packet, and therefore denies the logon request. When this happens, the following message is displayed:
The system cannot log you on due to the following error: There is a time difference between the client and server. Please try again or consult your system administrator.
The solution to the problem is simple; just set the workstation’s clock to match the domain controller’s clock.
Global Catalog Server Failures
Another major cause of logon problems is a global catalog server failure. A global catalog server is a domain controller that has been configured to act as a global catalog server. Global catalog servers contain a searchable representation of every object in every domain of the entire forest.
When the forest is initially created, the first domain controller that you bring online is automatically configured to act as a global catalog server. The problem is that this server can become a single point of failure, because Windows does not automatically designate any other domain controllers to act as global catalog servers. If the global catalog server fails, then only domain administrators will be able to log into the Active Directory.
Given the global catalog server’s importance, you should work to prevent global catalog server failures. Fortunately, you can designate any or all of your domain controllers to act as global catalog servers. Keep in mind though that you should only configure all of your domain controllers to act as global catalog servers if your forest consists of a single domain. Having multiple global catalog servers is a good idea even for forests with multiple domains, but figuring out which domain controllers should act as global catalog servers is something of an art form. You can find Microsoft’s recommendations here.
If your global catalog server has already failed, and nobody can log in, then the best thing that you can do is work to return the global catalog server to a functional state. There is a way of allowing users to log in even though the global catalog server is down, but there are security risks associated with doing so.
If the Active Directory is running in native mode, then the global catalog server is responsible for checking user’s universal group memberships. If you choose to allow users to logon during the failure, then universal group memberships will not be checked. If you have assigned explicit denials to members of certain universal groups, then those denials will not be in effect until the global catalog server is brought back online.
If you decide that you must allow users to log on, then you will have to edit the registry on each of your domain controllers. Keep in mind that editing the registry is dangerous, and that making a mistake can destroy Windows. I therefore recommend making a full system backup before continuing.
With that said, open the Registry Editor and navigate through the registry tree to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa. Now, create a new DWORD value named IgnoreGCFailures, and set the value to 1. You will have to restart the domain controller after making this change.
DNS Server Failure
If you suddenly find that none of your users can log into the network, and your domain controllers and global catalog servers seem to be functional, then a DNS server failure might have occurred. The Active Directory is completely dependent on the DNS services.
The DNS server contains host records for each computer on your network. The computers on your network use these host records to resolve computer names to IP addresses. If a DNS server failure occurs, then host name resolution will also fail, eventually impacting the logon process.
There are two things that you need to know about DNS failures in regard to troubleshooting logon problems. First, the logon failures may not happen immediately. The Windows operating system maintains a DNS cache, which includes the results of previous DNS queries. This cache prevents workstations from flooding DNS servers with name resolution requests for the same objects over and over.
In many cases, workstations will have cached the IP addresses of domain controllers and global catalog servers. Even so, items in the DNS cache do eventually expire and will need to be refreshed. You will most likely start noticing logon problems when cached host records begin to expire.
The other thing that you need to know about DNS server failures is that often times there are plenty of other symptoms besides logon failures. Unless machines on your network are configured to use a secondary DNS server in the event that the primary DNS server fails, the entire Active Directory environment will eventually come to a grinding halt. Although there are exceptions, generally speaking, the absence of a DNS server on an Active Directory network basically amounts to a total communications breakdown.
Conclusion
Although I have discussed some of the major causes of logon failures on Active Directory networks, an important part of the troubleshooting process is to look at how widespread the problem is. For example, if only a single host on a large network is having logon problems, then you can probably rule out DNS or global catalog failures. If a DNS or a global catalog failure were to blame, then the problem would most likely be much more wide spread. If the problem is isolated to a single machine, then the problem is most likely related to the machine’s configuration, connectivity, or to the user’s account.
Data Collected from Web http://www.windowsnetworking.com/
Backup / Restore XP Activation
Posted On Saturday, 5 September 2009 at at 02:01 by JhonData Collected from Web http://www.windowsnetworking.com
C:\WINDOWS\system32>dir wp*
Volume in drive C has no label.
Volume Serial Number is 8447-0571
Directory of C:\WINDOWS\system32
10/24/2001 08:28 PM 12,584 wpa.bak
01/14/2002 09:05 AM 12,642 wpa.dbl
- Start XP to Minimal Safe mode
- Change directory to the \%systemroot%\system32 folder
- Rename the newly created wpa.dbl to wpa.nonactivated and wpa.bak, if it exists, to wpabak.nonactivated.
- Copy your backed up wpa.dbl and wpb.bak files to the system32 folder
- Reboot
Related:
- Technical Details on Microsoft Product Activation for Windows XP
- Running Repair on Windows XP Requires the User to Re-Activate the Product (Q302740)
- Windows XP Prompts You to Re-activate After You Restore Your Computer (Q305356)
Data Collected from Web http://www.windowsnetworking.com
Enable / Disable Task Manager in Windows
Posted On at at 01:51 by JhonData Collected from Web http://www.windowsnetworking.com
Hive: HKEY_CURRENT_USER
Key: Software\Microsoft\Windows\CurrentVersion\Policies\System
Name: DisableTaskMgr
Type: REG_DWORD
Value: 1=Enablethis key, that is DISABLE TaskManager
Value: 0=Disablethis key, that is Don't Disable, Enable TaskManager
As part of the enhanced management available in Windows 2000 and Windows XP, rather than risking a registry change, as an administrator you can enable or disable Windows 2000 Pro or Windows XP Pro's TaskManager using Group Policy Editor. This can be applied to the local policy. Note: if you are trying to override your organizations group policy, you can't. As soon as you re-authenticate to the domain, the domain or OU Group Policy will rewrite the registry setting. But if the TaskManager was accidently disabled or you need to control this item for a set of standalone boxes this is for you:
- Click Start
- Click Run
- Enter gpedit.msc in the Open box and click OK
- In the Group Policy settings window
- Select User Configuration
- Select Administrative Templates
- Select System
- Select Ctrl+Alt+Delete options
- Select Remove Task Manager
- Double-click the Remove Task Manager option
Got XP Home - use the registry edit.
Enable / Disable Task Manager in NT & 2000
Hive: HKEY_CURRENT_USER
Key: Software\Microsoft\Windows\CurrentVersion\Policies\System
Name: DisableTaskMgr
Type: REG_DWORD
Value: 1=Enablethis key, that is DISABLE TaskManager
Value: 0=Disablethis key, that is Don't Disable, Enable TaskManager
Option post SP2 NT4.0, Windows 2000, Windows XP.
Data Collected from Web http://www.windowsnetworking.com