Tuesday, 28 February 2012

How To Install and Configure a File and Print Server in Windows Server 2003

0 comments

Install File and Printer Sharing

By default, a Windows Server 2003-based computer is installed with Client for Microsoft Networks, File and Printer Sharing for Microsoft Networks, and TCP/IP.

NOTE: You can view these services in the properties for the local area connection.

You can create a Windows Server 2003 file server and print server manually, or you can use the wizards that are provided in the Configure Your Server Wizard administrative tool.

How to Install a File Server on Windows Server 2003 by Using the Configure Your Server Wizard

  1. Click Start, point to Administrative Tools, and then click Configure Your Server Wizard.
  2. Click Next.
  3. Click Next.
  4. Click File server in the Server role box, and then click Next.
  5. On the "File Server Disk Quotas" page, configure any quotas you need to control disk-space usage on the server, and then click Next.
  6. On the "File Server Indexing Service" page, click the indexing configuration that is appropriate for your server, and then click Next.
  7. Click Next.
  8. Click Finish.
  9. The Share a Folder Wizard starts. Click Next.
  10. Click Browse, locate the folder that you want to share, and then click OK.
  11. Click Next.
  12. Type a share name for the folder, and then click Next.
  13. Click one of the basic permissions for the folder, or click Customize to set custom permissions on the folder. Click Finish.
  14. Click Close.

How to Manually Install a File Server on Windows Server 2003

  1. Click Start, and then click Windows Explorer.
  2. Locate the folder that you want to share.
  3. Right-click the folder, and then click Sharing and Security.
  4. Click Share this folder, and then accept the default name or type a different name for the share.
  5. Optionally, configure the number of users who can connect, configure permissions for this folder, and then configure the caching options.
  6. Click OK.
  7. A little hand is displayed in the Windows Explorer window to indicate that the folder is being shared.
  8. Quit Windows Explorer.

Install a Windows Server 2003 Print Server

How to Install a Print Server on Windows Server 2003 by Using the Configure Your Server Wizard

  1. Click Start, point to Administrative Tools, and then click Configure Your Server Wizard.
  2. Click Next.
  3. Click Next.
  4. Click Print server in the Server role box, and then click Next.
  5. On the "Printers and Printer Drivers" page, click the types of Windows clients that your print server will support, and then click Next.
  6. Click Next.
  7. On the "Add Printer Wizard Welcome" page, click Next.
  8. Click Local printer attached to this computer, click to clear the Automatically detect and install my Plug and Play printer check box, and then click Next.
  9. Click the port for your printer, and then click Next.
  10. Click the printer make and model or provide the drivers from the printer manufacturer media, and then click Next.

    NOTE: If you are prompted to keep or not keep your existing printer driver, either keep the existing driver or replace the existing driver. If you replace the driver, you must provide the manufacturer driver for this printer. Click Next to continue.
  11. Accept the default name of the printer or provide a different name, and then click Next.
  12. Click the Share as option, type the share name, and then click Next.

    NOTE: This step is optional because you can share the printer later.
  13. You may provide the location of the printer and a comment to make it easier to locate. Click Next to continue.
  14. Click the Print a test page option, click Next, and then click Finish to quit the Add Printer Wizard. Your printer appears in the Printers and Faxes folder.

How to Share a Printer

  1. Click Start, and then click Printers and Faxes.
  2. Right-click the printer that you just installed, and then click Sharing.
  3. Click Share this printer, and then type a share name for the printer.
  4. Optionally, click Additional Drivers, click the operating systems of the client computers that may attach to this printer, and then click OK. By adding drivers for these operating systems, users on client computers can connect to the print server and automatically download the appropriate drivers for this model of printer without having to configure anything.
  5. When you are prompted to do so, insert the Windows Server 2003 CD-ROM.
  6. Click OK to close the printer properties.
  7. Close the Printers and Faxes folder.

How to Manually Install a Print Server on Windows Server 2003

  1. Click Start, point to Settings, and then click Printers.
  2. Double-click Add Printer to start the Add Printer Wizard.
  3. To complete the Add Printer Wizard, repeat steps 7 through 14 in the "Install a Windows Server 2003 Print Server" section of this article.
NOTE: The only difference between the manual installation of the print server and the use of the Configure Your Server Wizard to create the print server is how you start the Add Printer Wizard.







Sunday, 26 February 2012

How to install and configure a DHCP server in an Active Directory domain

0 comments

Introduction

Dynamic Host Configuration Protocol (DHCP) is a core infrastructure service on any network that provides IP addressing and DNS server information to PC clients and any other device. DHCP is used so that you do not have to statically assign IP addresses to every device on your network and manage the issues that static IP addressing can create. More and more, DHCP is being expanded to fit into new network services like the Windows Health Service and Network Access Protection (NAP). However, before you can use it for more advanced services, you need to first install it and configure the basics. Let’s learn how to do that.
Installing Windows Server 2008 DHCP Server

Installing Windows Server 2008 DCHP Server is easy. DHCP Server is now a “role” of Windows Server 2008 – not a windows component as it was in the past.

To do this, you will need a Windows Server 2008 system already installed and configured with a static IP address. You will need to know your network’s IP address range, the range of IP addresses you will want to hand out to your PC clients, your DNS server IP addresses, and your default gateway. Additionally, you will want to have a plan for all subnets involved, what scopes you will want to define, and what exclusions you will want to create.

To start the DHCP installation process, you can click Add Roles from the Initial Configuration Tasks window or from Server Manager à Roles à Add Roles.


Figure 1: Adding a new Role in Windows Server 2008

When the Add Roles Wizard comes up, you can click Next on that screen.

Next, select that you want to add the DHCP Server Role, and click Next.


Figure 2: Selecting the DHCP Server Role

If you do not have a static IP address assigned on your server, you will get a warning that you should not install DHCP with a dynamic IP address.

At this point, you will begin being prompted for IP network information, scope information, and DNS information. If you only want to install DHCP server with no configured scopes or settings, you can just click Next through these questions and proceed with the installation.

On the other hand, you can optionally configure your DHCP Server during this part of the installation.

In my case, I chose to take this opportunity to configure some basic IP settings and configure my first DHCP Scope.

I was shown my network connection binding and asked to verify it, like this:


Figure 3: Network connection binding

What the wizard is asking is, “what interface do you want to provide DHCP services on?” I took the default and clickedNext.

Next, I entered my Parent Domain, Primary DNS Server, and Alternate DNS Server (as you see below) and clicked Next.


Figure 4: Entering domain and DNS information

I opted NOT to use WINS on my network and I clicked Next.

Then, I was promoted to configure a DHCP scope for the new DHCP Server. I have opted to configure an IP address range of 192.168.1.50-100 to cover the 25+ PC Clients on my local network. To do this, I clicked Add to add a new scope. As you see below, I named the Scope WBC-Local, configured the starting and ending IP addresses of 192.168.1.50-192.168.1.100, subnet mask of 255.255.255.0, default gateway of 192.168.1.1, type of subnet(wired), and activated the scope.


Figure 5: Adding a new DHCP Scope

Back in the Add Scope screen, I clicked Next to add the new scope (once the DHCP Server is installed).

I chose to Disable DHCPv6 stateless mode for this server and clicked Next.

Then, I confirmed my DHCP Installation Selections (on the screen below) and clicked Install.


Figure 6: Confirm Installation Selections

After only a few seconds, the DHCP Server was installed and I saw the window, below:


Figure 7: Windows Server 2008 DHCP Server Installation succeeded

I clicked Close to close the installer window, then moved on to how to manage my new DHCP Server.
How to Manage your new Windows Server 2008 DHCP Server

Like the installation, managing Windows Server 2008 DHCP Server is also easy. Back in my Windows Server 2008Server Manager, under Roles, I clicked on the new DHCP Server entry.


Figure 8: DHCP Server management in Server Manager

While I cannot manage the DHCP Server scopes and clients from here, what I can do is to manage what events, services, and resources are related to the DHCP Server installation. Thus, this is a good place to go to check the status of the DHCP Server and what events have happened around it.

However, to really configure the DHCP Server and see what clients have obtained IP addresses, I need to go to the DHCP Server MMC. To do this, I went to Start à Administrative Tools à DHCP Server, like this:


Figure 9: Starting the DHCP Server MMC

When expanded out, the MMC offers a lot of features. Here is what it looks like:


Figure 10: The Windows Server 2008 DHCP Server MMC

The DHCP Server MMC offers IPv4 & IPv6 DHCP Server info including all scopes, pools, leases, reservations, scope options, and server options.

If I go into the address pool and the scope options, I can see that the configuration we made when we installed the DHCP Server did, indeed, work. The scope IP address range is there, and so are the DNS Server & default gateway.


Figure 11: DHCP Server Address Pool


Figure 12: DHCP Server Scope Options

So how do we know that this really works if we do not test it? The answer is that we do not. Now, let’s test to make sure it works.
How do we test our Windows Server 2008 DHCP Server?

To test this, I have a Windows Vista PC Client on the same network segment as the Windows Server 2008 DHCP server. To be safe, I have no other devices on this network segment.

I did an IPCONFIG /RELEASE then an IPCONFIG /RENEW and verified that I received an IP address from the new DHCP server, as you can see below:


Figure 13: Vista client received IP address from new DHCP Server

Also, I went to my Windows 2008 Server and verified that the new Vista client was listed as a client on the DHCP server. This did indeed check out, as you can see below:


Figure 14: Win 2008 DHCP Server has the Vista client listed under Address Leases




Thursday, 23 February 2012

Fix Active Directory replication issues

0 comments

In Windows Server 2003, the replication process is responsible for keeping each domain controller updated with the latest Active Directory information. The replication process is also responsible for keeping DNS replicas synchronised.
As you can see, replication is a very important part of the Windows Server 2003 network operating system. So what do you do when replication fails? For that matter, how do you even know when a failure has occurred? Here are some answers to these questions and how to fix the replication process.
How does replication work?
Before you can fix the replication process, you need to understand how it works. As I mentioned earlier, replication is used to keep both domain controllers and DFS replicas synchronized. There are a few other tasks that use replication as well. For the purposes of this article, I will focus my discussion on Active Directory replication that occurs between domain controllers.
If you have ever worked with Windows NT, then you are probably familiar with the PDC and BDC domain controller roles. In such an environment, if someone needs to make an update to the Security Accounts Manager, the update gets applied to the PDC. The PDC then alerts the BDCs to the update and the BDCs download the updates and use them to update their own copies of the Security Accounts Manager. This structure is known as single master replication.
In contrast, Windows 2000 and Windows 2003 use multi-master replication. In multi-master replication, there is no PDC or BDC. Every domain controller contains a writable copy of the Active Directory database. If an administrator makes an update to the Active Directory, the update is applied to the closest available domain controller. The domain controller then uses the replication process to apply the update to the other domain controllers.
Because of the multi-master replication model, the Active Directory must have a technique for resolving conflicts. For example, suppose that two different administrators are making changes to the same attribute of the same user account at the same time. Now, suppose that those changes get written to two different domain controllers. When the next replication cycle occurs, you will have two domain controllers attempting to write contradictory data to the other domain controllers.
To get around this problem, Windows relies on a "most recent change wins" mentality. This means that Windows looks at the timestamp for both changes. Whichever of the two changes was made most recently will be the change that takes precedence. The other change will be overwritten.
I mention this because I've seen situations in which two administrators try to apply updates to user accounts and can't figure out why some of their changes are undone. If you suspect that you might have a replication problem, do a little checking to make sure that two or more people are not trying to update the same information at the same time.
Another aspect of replication that I want to touch on is something called Inter-site replication. Inter-site replication is domain controller replication across two or more sites.
The idea behind Active Directory sites is that you want to avoid congesting slow WAN links with excessive replication traffic. Imagine for a moment that you have a domain spanning two offices and that each of the two offices has ten domain controllers. Also, imagine that these two offices are separated by a slow WAN link.
In a situation like this, every time anyone makes a change to the Active Directory, the change is replicated to nineteen other domain controllers. It also means that, since there are nineteen other domain controllers that have to be updated, nineteen different copies of the same data are flowing across your network. To make matters worse, ten separate copies of the same identical data are flowing across your WAN link.
Now, imagine that someone is performing an Active Directory-intensive process, such as creating a hundred new user accounts. This process would cause at least a thousand different update sequences to flow across your WAN link. It is very possible that all of this traffic could choke out the link, preventing other, more important, traffic from flowing across it.
The solution to this problem is to divide the domain into two sites. In a situation like this, one domain controller in each environment is designated as a bridgehead server. The bridgehead server is responsible for sending and receiving batches of Active Directory updates. To see how sites work, let's return to my example of the company with ten domain controllers in each office, separated by a WAN link.
In this situation, if someone in an office made an update to a domain controller, only nine updates would be sent out instead of nineteen. These updates are designed to update the domain controllers in the local site. Remember, however, that one of these domain controllers is acting as the bridgehead server for the site. The bridgehead server receives the updates and then sends a single copy of the update across the WAN link to the remoter bridgehead server. The remote bridgehead server receives the update and then distributes it to the domain controllers in the remote domain.
As you can see, only a single copy of the update was transmitted across the WAN link instead of ten separate copies. When implemented correctly, sites can drastically reduce replication-related network traffic.
Troubleshooting replication
Anytime that you make an Active Directory update and the update isn't accessible to those accessing other domain controllers within a reasonable amount of time, there's a chance that you may have a replication problem. For example, imagine that an Administrator creates a new user account. The Administrator then calls the user to say that the new user account should be ready to use within about 20 minutes (after the next replication cycle completes), After about half an hour, the user calls back and says that she can't log in because Windows is telling her that her account doesn't exist. The Administrator checks and, sure enough, the account exists. In this case, the account exists on the domain controller that the Administrator is connected to, but the account has yet to be replicated to the domain controller that is processing the user's login, thus giving the illusion that the account doesn't exist.
If the company only has a few domain controllers, the administrator can actually use the Active Directory Users And Computers console to see which domain controllers the account has been written to. To do so, simply right-click on the domain name and select the Connect To Domain Controller command from the resulting shortcut menu. In doing so, the administrator will be able to connect individually to various domain controllers and see if the new account has been replicated.
This technique works great for small organizations, but what if your domain has 200 domain controllers? You don't want to have to individually check each one. This is where a tool called the Replication Monitor comes in. The Replication Monitor is a tool that allows you to see exactly what is happening with the replication process. It allows you to view the status of Active Directory replication and force replication if necessary.
The Replication Monitor is one of the Windows 2003 Support Tools and, therefore, isn't installed automatically as part of the operating system. (This tool is also included in the Windows 2000 Support Tools.) To install the Windows 2003 Support Tools, insert your Windows 2003 Server CD. Now, open My Computer and browse the CD's contents. Navigate to the CD's \SUPPORT\TOOLS folder, and then run the SUPTOOLS.MSI file.
When installation completes, there will be an option for the Support Tools on the Start | All Programs menu, but the Replication Monitor is not listed on this menu. To open the Replication Monitor, you must go to the \PROGRAM FILES\SUPPORT TOOLS folder and run the REPLMON.EXE file.
When the Replication Monitor opens, you'll see a big, mostly empty screen. This console is divided into two columns. The column on the left simply says Monitored Servers, and the column on the right says Log. In a large organization if all domain controllers were automatically monitored, there would be so much data displayed that it would be very difficult to make sense of it all.
The first time I ever used the Replication Monitor, I was slightly upset that I was unable to automatically monitor all of my domain controllers. After all, I wanted a tool that would tell me where replication was failing, not a tool that would make me guess which server was failing and would then tell me if my guess was right. In a way, though, the Replication Monitor does tell you which server is failing.
Let's go back to the situation in which the Administrator creates a user account but the user can't access the account because it has never been replicated.
In a situation like this, you can use the replication monitor in conjunction with the information that you know to figure out which domain controllers are failing to receive replication updates.
For example, the administrator knows that the domain controller on which he created the account has a copy of the account. The administrator can even find out which domain controller he is connected to by using the Connect To Domain Controller option in the Active Directory Users And Computers console. Upon selecting this option, the console will tell you which domain controller you are currently connected to before asking you which domain controller you would like to connect to.
The other useful tidbit of information in this situation is the user's physical location. By looking at which building the user is located in, the Administrator can determine if the user is trying to authenticate through a domain controller in the same site as the administrator's domain controller or through a domain controller in a remote site. For the sake of argument, let's assume that both the user and the administrator are in the same building and are, therefore, accessing domain controllers in a common site.
In a situation like this, every domain controller in a site sends updates to every other domain controller in the site. The administrator knows that the domain controller he is attached to is functional, so he can tell the Replication Monitor to monitor that domain controller. He can then watch to see which domain controllers fail to be updated. If there is a failure replicating Active Directory information to all of the other domain controllers, then the administrator's domain controller is probably the one with the problem. If, however, only one domain controller fails to receive updates, then that's the domain controller with the problems.
To perform such an operation, right-click on the Monitored Servers container within the Replication Monitor and select the Add Monitored Server command from the resulting shortcut menu. This will cause Windows to display the Add Server To Monitor dialog box. You can either enter the server's name directly or you can select the server from a list. Upon entering the server name, Windows will display the Active Directory in tree form. You will notice in that multiple domains are listed.

Expand the desired domain and you will see the other domain controllers in this domain. If you look at Figure A, you will notice that there is a red X over the icon for server Brien. In this case, I have purposefully taken this server offline so that you can see what a replication failure looks like. If you select the failing server, you can see log information that gives you additional information about the failure.
In a situation like this, the first thing you would want to do is right-click on the failing server, and select the Synchronize With This Replication Partner command from the resulting shortcut menu. When you do, the Replication Monitor will attempt to force replication. Of course, in this case, forcing replication is impossible because the server is down.
Fixing a replication problem
Once you have identified the problem server, the next step is to fix the problem. In every real life replication failure that I have ever seen, the problem was one of three things: the server was down; the server was having trouble with network communications; or the server's hard disk was full.
Therefore, I recommend going to the server and checking out the basics. Make sure that the server has plenty of hard disk space. Next, make sure that you can ping the functional domain controllers. It's important that you be able to ping by both IP address and host name. If you find that you can ping by IP address but not by host name, then it's likely that the machine is having trouble communicating with a DNS server. Make sure that TCP/IP is configured correctly and that the server's designated DNS server is functional.
If everything checks out on the server, but it still can't receive replication updates, you are not completely out of luck. The truth is that there are quite a few less common problems that can cause replication troubles. This is especially true if you are dealing with replication across a site link. For example, when replicating across a site, your designated bridgehead server may be too busy to effectively handle its bridgehead duties. You can find a description of these less common problems and their solutions in Microsoft's TechNet.

Thursday, 16 February 2012

Advanced WINS Features

0 comments

The Trouble with Names
For those who missed my past columns ("Name Resolvers: WINS vs. DNS," November 1996; "NetBIOS Names and WINS," January 1997; and "Inside a NetBIOS Name Resolution," March 1997), you can find them on the Windows NT Magazine Web site at http://www.winntmag.com. The articles show that NT and TCP/IP have a problem: names. We want servers to have nice, human-friendly names such as, in my network, Aldebaran, Rigel, Betelgeuse, and Elnath. (They are the brightest and second-brightest stars in the Orion and Taurus constellations. The brightest are the primary domain controllers--PDCs, and the second-brightest are the backup domain controllers--BDCs.) Those names are easier to remember than IP addresses such as 198.34.57.44, 198.34.57.11, 198.34.57.90, and 198.34.57.26. To satisfy both us and the computers, networking software converts the human-friendly names into IP addresses. The term for that conversion is name resolution, and it typically involves looking up the name in a database.
Name resolution makes NT networking with TCP/IP particularly troublesome because NT uses different kinds of names from other TCP/IP-based networks. Most use names such as http://www.mmco.com, a Domain Name Service (DNS) name. NT's Microsoft networking lineage was not very TCP/IP- and Internet-aware until recently. Over the years, Microsoft networking has used a different set of names--NetBIOS names. So running NT on TCP/IP presents a special challenge: The network must resolve DNS names and NetBIOS names. The NetBIOS names are more central to NT's operation. As a result, NT depends on NetBIOS over TCP (NBT or NetBT) for NetBIOS name resolution.
NBT name resolution occurs in NT with WINS. Basically, a designated NT server keeps a JET database of NetBIOS names and IP addresses. Workstations and servers refer to that WINS server to resolve names into IP addresses. But how does WINS gather information about computers on the network? Every computer that intends to use a given WINS server for name resolution registers its NetBIOS names with that WINS server. In a small network with one WINS server, you tell all your computers to refer to that WINS server. That server is the central repository for NetBIOS names. But what about redundancy or the situation in which you need a second WINS server to handle your enterprise network? How does a second WINS server share the information the first WINS server owns? In that case, you need to know about push and pull partners.
When you set up a Microsoft TCP/IP client, NT asks for a primary and a secondary WINS server address. When your PC boots, it goes to the primary WINS server and tries to register its NetBIOS name. If the registration is successful, your PC never contacts the secondary WINS server, unless a subsequent name resolution attempt fails.
Nobody Home
Suppose you create a backup WINS server and point all your workstations' Secondary WINS Server fields to that backup. The primary WINS server goes down. Where are you? Nowhere very interesting. The secondary server doesn't know much, because no one has registered with it. So if the primary server goes down and everyone starts asking the secondary server to resolve names, the secondary server just says, "Sorry, I can't answer that question." You must convince the primary server to replicate to the secondary server. Fortunately, an easy method exists: push and pull partners.
You can conFigure two WINS servers to be push and pull partners, or you can let them discover each other with a Registry entry. In HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WINS\Parameters, add a new entry, UseSelfFndPnrs, of type REG_DWORD. Set its value to 1 to cause the WINS server to periodically multicast to find other WINS servers and automatically replicate. This entry usually works for only WINS servers on the same subnet, because most routers don't pass IP multicasts.
Alternatively, you can introduce the two WINS servers. WINS database replications transfer data from a push partner to a pull partner. For example, suppose you have two machines, Primary and Secondary. Primary gets the latest information because it is the primary WINS server. Secondary backs up Primary's information. Thus, Secondary never has information to offer to Primary. In that case, Primary pushes its database changes to Secondary.
Push Me, Pull You
In a push/pull relationship, data gets from Primary to Secondary in one of two ways. First, Secondary (the pull partner) can request that Primary (the push partner) update Secondary, telling Secondary only what has changed in the database. Alternatively, Primary can say to Secondary, "I've made a lot of changes since the last time I updated you. You should request an update." The pull partner does most of the work initiating the replication updates. All the push partner does is suggest that the pull partner start requesting updates.
Can you tell Secondary to be a pull partner with Primary, without telling Primary to be a push partner for Secondary? You might think so, but if Secondary starts pulling from Primary, Primary will refuse to respond to Secondary's pull request unless you've conFigured Primary as a push partner with Secondary. Thus, you need to make Secondary a pull partner with Primary, and make Primary a push partner with Secondary.
What triggers the WINS database replication process? Recall that either partner can start the conversation. In the case of a push partner, you conFigure it to contact its partner and suggest a replication session based on the number of database changes. You can tell Primary to notify Secondary whenever 50 (or any number greater than 19) changes have occurred to the WINS database on Primary. (You can alternatively trigger replication from the WINS Manager.)
A pull partner, which doesn't know how many changes have occurred, requests updates based on time. You conFigure a pull partner to contact its partner every so many minutes, hours, or days.
Less Is More
I have more to tell you about WINS, but I'm out of space for this month. Before you experiment with extra WINS servers, however, I have three important pieces of advice. First, when it comes to WINS servers, less is more. Microsoft claims that it runs its entire worldwide enterprise with only 15 servers. Don't start setting up WINS servers all over the place. Second, if you set up a WINS server, don't put it on a multihomed PC (a computer with more than one NIC). This configuration has traditionally been a problem for WINS servers. Third, don't set up a test WINS server, register a few names on it, have a production WINS server pull the names from the test server, and then shut off the test WINS server for good. WINS will refuse to delete names that it got from another server, no matter how old and expired the names are, until it can do a final double-check with the WINS server that provided the names originally. If you shut off the test server and never turn it back on, those records never go away.


Wednesday, 15 February 2012

Name Resolvers: WINS vs. DNS

0 comments

What do WINS and DNS do?
Windows NT 3.5 offered the Windows Internet Name Service (WINS). Most of us had no idea what it did, but we soon figured out that we pretty much needed it. The rest of the Internet world seemed to be using something similar, but incompatible: the Domain Name System (DNS).
What is WINS, and, well, why isn't it DNS? The short answer is that WINS and DNS have somewhat different jobs. Consider the two following commands, both issued to the same server:
ping server01.bigfirm.com and net use * \\server01 \mainshr
The ping command refers to the server as server01.big firm.com. The net use command calls the same server server01. The difference is important.
Why Two Different Names?
The ping command is a platform-independent, TCP/IP/Internet kind of command. It's valid on UNIX, VMS, Macintosh, and MVS--so long as the machine is running a TCP/IP protocol stack. On any of these platforms, you can issue a ping only if you're running TCP/IP. The command's syntax is the same on every OS, but the response varies from platform to platform. For example, when the command is successful, many UNIX implementations of ping return the message, "server01.bigfirm.com is alive" (UC Berkeley used to have a machine named Elvis, so you could type ping Elvis and get the response, "Elvis is alive"). In contrast, Microsoft implementations of ping respond with something like, "Reply from [IP address]..."
In contrast to ping, net use is a Microsoft platform-specific networking command that is independent of protocol. You can do a net use on an NT network, no matter what protocol you're running, but the command usually isn't valid on a UNIX, VMS, Mac, or other machine. Microsoft networking is designed to work on PCs and machines built on the MIPS, PowerPC, and Alpha chip sets.
The difference between ping and net use goes back to the network API that each command is based on. The ping command is based on the TCP/IP Sockets interface--actually, on the common PC implementation of TCP/IP Sockets, the Winsock interface. Basing ping on Sockets was a good idea, because this approach makes creating a ping for any OS simple, as long as the computer has a Sockets interface. In fact, people use basically the same source code to create ping for PCs, UNIX machines, VMS machines, and Macs.
The server01.bigfirm.com reference is to a DNS name, so for ping to recognize server01.bigfirm.com, you need a DNS name resolver (a DNS server) on your network. The ping command works only with IP addresses, not names; ping must know that server01.bigfirm.com is at IP address 212.33.14.88. Translating from the human-friendly name server01.big firm.com to the ping-friendly 212.33.14.88 is Winsock's job, and it calls on DNS to help. That need for two types of address is why NT 4.0 has a DNS server--to handle name resolution for Winsock-based programs.
net use is built on a different programming interface, the NetBIOS API. This API is based on a fairly old and simple network protocol that Sytek and IBM invented in the mid-1980s. The original NetBIOS protocol no longer exists: It has mutated into the NetBEUI protocol. Because existing networking programs were built under the assumption that NetBIOS would continue to be around, NetBEUI retained NetBIOS as its programming interface.
By the way, when you read network documentation, remember that NetBEUI is the network protocol and NetBIOS is the network programming interface that first appeared on NetBEUI. Although I'm drawing my examples from the net commands, they're not the only important programs built on NetBEUI. The Microsoft File Server System and Network Neighborhood are examples of two applications that won't work on a computer that doesn't have NetBIOS.
NetBEUI was Microsoft's protocol of choice until as recently as 1993, I recall Microsoft bigwig Steve Ballmer preaching that the speed of what he called JetBEUI would assure NetBEUI's eventual preeminence in the networking market. So Microsoft's networking tools have traditionally been built on NetBIOS, NetBEUI's programming interface. The net.exe program, the networking shell for Microsoft networking, cannot run unless NetBIOS is present and cannot use other programming interfaces such as Winsock. (However, Microsoft intends to eventually change that restriction: A version of net.exe called inet.exe works just like net but runs atop Winsock.)


Saturday, 11 February 2012

Active Directory: NTDS folder and its Contents

0 comments
The Active Directory Database is Stored in %SYSTEM ROOT%\NDTS folder. The file is called asntds.dit. Along with this file there are other files also present in this folder. The files are created when you run dcpromo. The list of files and use of those files are listed below
1. ntds.dit : This is the main database file for active directory.
2. edb.log : When a transaction performed to ad database, like writing some data first the data will be stored to this file. And after that it will be sent to database. So the system performance will be depends on how this data from edb.log file will be written to ntds.dit. multiple .log files will be created according to the requirement.
3. res1.log : Used as reserve space in the case when drive had low space. It is basically 10MB in size and created when we run dcpromo.
4. res2.log : Same as res1.log. It is also 10MB in size and the purspose also same.
5. edb.chk : This file records the transactions committed to ad database. During shutdown, shutdown statement is written to this file. If it is not found when the system rebooted, the ad database tries to check with edb.log for the updated information.
6. Drop folder : It contains details related to SMTP.

Wednesday, 8 February 2012

Active Directory : Understanding FSMO Roles.

1 comments
Introduction
Flexible Single Master Operations (FSMO) is a feature of Microsoft’s Active Directory (AD).
FSMOs are specialized domain controller (DC) tasks, used where standard data transfer and update methods are inadequate. AD normally relies on multiple peer DCs, each with a copy of the AD database, being synchronized by multi-master replication. The tasks which are not suited to multi-master replication, and are viable only with a single-master database, are the FSMOs.
The FSMO roles are also called Single Master Operations or Operations Master, FSMO is sometimes pronounced as “fizmo”.
What is the need of FSMO roles?
Active directory is multi master replication model. Meaning clients can register their records to any available Active directory domain controller and have access to resources within active directory NTDS.DIT database.
The purpose of having FSMO roles is being cause by Multi master replication model. In this model there has to be a way of preventing the conflict being happened, such as firing up adsiedit.msc and adding to the same object from different locations, which one would win? The NTDS.DIT DataBase would get confuse, Therefore we needed to have schema master so that regardless where you make the changes within the Domain changes gets okay from Schema Master first than, schema master replicates these changes to all other Domain controllers. This is the primary purpose why Microsoft comes up with FSMO roles (Operations Masters)
Knowing these FSMO roles and understanding them is Curtail for any Windows server administrator who is dealing with Active Directory and Exchange server.
The Five FSMO Roles
There are just five operations where the usual multiple master model breaks down, and the Active Directory task must only be carried out on one Domain Controller. FSMO roles:
1. PDC Emulator
Most famous for backwards compatibility with NT 4.0 BDC’s. However, there are two other FSMO roles which operate even in Windows 2003 Native Domains, synchronizing the W32Time service and creating group policies. I admit that it is confusing that these two jobs have little to do with PDCs and BDCs.
2. RID Master
Each object must have a globally unique number (GUID). The RID master makes sure each domain controller issues unique numbers when you create objects such as users or computers. For example DC one is given RIDs 1-4999 and DC two is given RIDs 5000 – 9999.
3. Infrastructure Master
Responsible for checking objects in other other domains. Universal group membership is the most important example. To me, it seems as though the operating system is paranoid that, a) You are a member of a Universal Group in another domain and b) that group has been assigned Deny permissions. So if the Infrastructure master could not check your Universal Groups there could be a security breach.
4. Domain Naming Master
Ensures that each child domain has a unique name. How often do child domains get added to the forest? Not very often I suggest, so the fact that this is a FSMO does not impact on normal domain activity. My point is it’s worth the price to confine joining and leaving the domain operations to one machine, and save the tiny risk of getting duplicate names or orphaned domains.
5. Schema Master
Operations that involve expanding user properties e.g. Exchange 2003 / forestprep which adds mailbox properties to users. Rather like the Domain naming master, changing the schema is a rare event. However if you have a team of Schema Administrators all experimenting with object properties, you would not want there to be a mistake which crippled your forest. So its a case of Microsoft know best, the Schema Master should be a Single Master Operation and thus a FSMO role.
Note: There is a also an important Global Catalog Role, however it’s not a FSMO role as you can have more than one Global Catalog.
FSMO Role Deployment
Three of the FSMO roles (1. 2. and 3.) are held in each domain, whilst two (4. 5.) are unique to the entire forest. Thus, if you have three domains there will be 3 PDC emulators, 3 RID master and 3 Infrastructure Master, but only 1 Schema Master and Domain naming master.
Which DC is holding FSMO role?
By default, the first domain controller of the domain will be holding all the five operations master roles of the forest. But we can transfer the roles for the load balancing and for the better distribution of Active Directory replication.
We can transfer the Operations Master roles using Graphical interface or Command line interface, which I will discuss in another article.
Here I will tell you how we can identify which AD Domain controller.
RID, PDC, Infrastructure (1. 2. and 3.)
You can discover which server holds the Operation Master by opening Active Directory Users and Computers, Right click your Domain and select Properties, Operations Masters.
Domain Naming Master (4.)
To see the Domain Naming Master (4.), navigate to the little used, Active Directory Domains and Trusts, Right click your Domain and select Properties, Operations Masters.
Schema Master (5.)
The Schema Master (5.) is the most difficult FSMO to find. The reason is the Schema snap-in is hidden by default. Perhaps is this is Microsoft saying – don’t mess with the object definitions. However, you can reveal the Schema and its FSMO settings thus:
1) Register the Schema Snap with this command, RUN regsvr32 schmmgmt.dll
2) Run MMC, File menu, Add\Remove Snap-in, click the Add button and select,
Active Directory Schema
3) Select Active Directory Schema, Right Click, Operations Master.