Types of Servers

There are many different types of servers used in the marketplace today. Click on the server category you'd like to know more about, and you can get additional information and resources.


Web Server :

A Web server is a program that, using the client/server model and the World Wide Web's Hypertext Transfer Protocol ( HTTP ), serves the files that form Web pages to Web users (whose computers contain HTTP clients that forward their requests).

The primary function of a web server is to deliver web pages (HTML documents) and associated content (e.g. images, style sheets, JavaScripts) to clients. A client, commonly a web browser or web crawler, makes a request for a specific resource using HTTP and, if all goes well, the server responds with the content of that resource. The resource is typically a real file on the server's secondary memory, but this is not necessarily the case and depends on how the web server is implemented.

While the primary function is to serve content, a full implementation of HTTP also includes a way of receiving content from clients. This feature is used for submitting web forms, including uploading of files.

Many generic web servers also support server-side scripting (e.g. Apache HTTP Server and PHP). This means that a script can be executed by the server when a client requests it. Usually, this functionality is used to create HTML documents on-the-fly as opposed to return fixed documents. This is referred to as dynamic and static content respectively.

Highly niched web servers can be found in devices such as printers and routers in order to ease administration using a familiar user interface in the form of a web page.

Database Server:

A database server is a computer program that provides database services to other computer programs or computers, as defined by the client-server model. The term may also refer to a computer dedicated to running such a program. Database management systems frequently provide database server functionality, and some DBMSs (e.g., MySQL) rely exclusively on the client-server model for database access.

Such a server is accessed either through a "front end" running on the user’s computer which displays requested data or the back end which runs on the server and handles tasks such as data analysis and storage.

Mail Server:

A mail server (also known as a mail transfer agent or MTA, a mail transport agent, a mail router or an Internet mailer) is an application that receives incoming e-mail from local users (people within the same domain) and remote senders and forwards outgoing e-mail for delivery. A computer dedicated to running such applications is also called a mail server. Microsoft Exchange, qmail, Exim and sendmail are among the more common mail server programs.

The mail server works in conjunction with other programs to make up what is sometimes referred to as a messaging system. A messaging system includes all the applications necessary to keep e-mail moving as it should. When you send an e-mail message, your e-mail program, such as Outlook or Eudora, forwards the message to your mail server, which in turn forwards it either to another mail server or to a holding area on the same server called a message store to be forwarded later. As a rule, the system uses SMTP (Simple Mail Transfer Protocol) or ESMTP (extended SMTP) for sending e-mail, and either POP3 (Post Office Protocol 3) or IMAP (Internet Message Access Protocol) for receiving e-mail.

Proxy Server:

In computer networks, a proxy server is a server (a computer system or an application program) that acts as an intermediary for requests from clients seeking resources from other servers. A client connects to the proxy server, requesting some service, such as a file, connection, web page, or other resource, available from a different server. The proxy server evaluates the request according to its filtering rules. For example, it may filter traffic by IP address or protocol. If the request is validated by the filter, the proxy provides the resource by connecting to the relevant server and requesting the service on behalf of the client. A proxy server may optionally alter the client's request or the server's response, and sometimes it may serve the request without contacting the specified server. In this case, it 'caches' responses from the remote server, and returns subsequent requests for the same content directly.

Proxy Server have two main purposes:

Improve Performance: Proxy servers can dramatically improve performance for groups of users. This is because it saves the results of all requests for a certain amount of time. Consider the case where both user X and user Y access the World Wide Web through a proxy server. First user X requests a certain Web page, which we'll call Page 1. Sometime later, user Y requests the same page. Instead of forwarding the request to the Web server where Page 1 resides, which can be a time-consuming operation, the proxy server simply returns the Page 1 that it already fetched for user X. Since the proxy server is often on the same network as the user, this is a much faster operation. Real proxy servers support hundreds or thousands of users. The major online services such as America Online, MSN and Yahoo, for example, employ an array of proxy servers.

Filter Requests: Proxy servers can also be used to filter requests. For example, a company might use a proxy server to prevent its employees from accessing a specific set of Web sites.

Share Level Permissions

This article continues the Networking for Beginner series by talking about the difference between file level and share level permissions.

In the previous part of this article series, I began showing you how to create a network share that you can use to share resources located on a server. So far, we have created a share, but we have yet to give anyone access to it. In this article, I will continue the discussion by discussing the differences between file level and share level permissions.

Secure A Sharing

Although the entire point of creating a share is to allow users on your network to access the resources contained within the share, you still have to be careful about what level of access the users are given to those resources. For example, suppose that your human resources department has created a spreadsheet that lists the salary information for every employee in your company. Now suppose that everybody in human resources needs to be able to access the spreadsheet, and to make updates to it. Since the finance department is responsible for printing paychecks, they need to have access to the spreadsheet too, but you probably do not want them to be making any changes to it. Given the sensitive nature of the information in the spreadsheet, you probably would not want anyone else in the company to have access to it. With that in mind, let us take a look at how this type of security could be implemented.

The first thing that you need to understand about the share that you have created, is that there are two different types of security that you can apply to it. You have a choice of using share level security, file level security, or both.

Share level security applies directly to the share point that you have created. When the users connect to the SharePoint to access the files, the share level permissions that you have set are applied. In contrast, file level permissions are applied directly to files and folders rather than to the share.

The reason why there are two different types of permissions has a little bit to do with the evolution of Windows. The Windows operating system supports two different hard drive formats; FAT and NTFS. FAT is a legacy file system that has been around since the early 1980s. Because of its age, FAT is a no-frills file system, and does not support file level security. NTFS on the other hand, was designed with security in mind. You can apply file level security directly to files and folders residing on an NTFS volume.

Since the FAT file system does not support file level security, Microsoft allows you to use share level security as a way of getting around the file system shortcomings. Today the NTFS file system is used almost exclusively, and the FAT file system is all but extinct. You can still use share level permissions if you want to, but it is usually considered to be better practice to use file level permissions instead.

So what makes file level permissions so much better than share level permissions? For starters, share level permissions only apply if a user is accessing the files through the share. This can be a problem because Windows allows you to create multiple share points on a single volume. If the share points are created carelessly, they can overlap with each other. This can lead to users having unexpected levels of permissions to files and folders.

Another reason why file level permissions are preferable to share level permissions is because share level permissions do not provide any protection unless the user is accessing the files through the SharePoint. If a user were to log on to a server console locally, then they could browse the local hard drive without having to pass through SharePoint. If share permissions were the only types of permissions being used, then the user could theoretically have full access to the files within the share.

File level permissions also protect data if the server is booted to an alternate operating system, or if the hard drive is removed from the server and placed into a different machine. Share level permissions simply do not provide this kind of protection.

Since file level permissions are far superior to share level permissions, you may be wondering why you would want to create a share at all. You need to create shares, because shares act as an entry point for accessing the file system over the network. If you need to give users access to files on a file server, there really is not any getting around creating shares. However, you can secure the share using file level permissions rather than depending on share level permissions.

As you may recall, we created a folder named Data in the previous article, and then shared that folder. To set the permissions in this folder, right-click on it, and choose the Properties command from the resulting shortcut menu. When you do, you will see the folder's properties sheet.

Now take a look at the properties sheet's Sharing tab, as shown in Figure A. As you can see in the figure, this tab contains a Permissions button. You can click this button to set share level permissions for the share.

Figure A: The Permissions button is used to set share level permissions for the share

Now take a look at the Security tab. This tab is used to set file level permissions, starting at the folder to which the SharePoint has been bound. The first thing that you need to know about file level permissions is that under normal circumstances they make use of the concept known as inheritance. Inheritance simply means that when you set a permission, that permission applies not only to the folder, but to everything in it. This includes any subfolders that may exist and any files or folders within the subfolders.

Another thing that you need to know about file level permissions is that because of inheritance some permissions will apply automatically. If you take a look at Figure B, you can see that Security tab for the properties sheet that we have been looking at. As you can see in the figure, several different sets of permissions have already been applied. I do not expect you to understand what all of these settings mean just yet, but I will be talking about them in detail later on in this series. For now just be aware of the fact that some permissions are applied automatically.

Figure B: The Security tab can be used to set file level security for the folder to which the share point is bound

If you look at the Security tab, you will notice that the top half of the tab contains a list of users and groups. The lower half of the tab contains a list of permissions. If you want to apply a set of permissions to a user or group, you simply select the user or group that you want to work with from the top half of the tab, and then set the permissions on the lower half of the tab. Of course, before you can set the permissions you need to understand what permissions actually mean. I will discuss the permissions in detail in the next part of this series.

In this article, I have explained that you can secure a SharePoint using either file level or share level permissions, or both. In the next article in this series, I will explain how the permissions themselves work, and how to apply permissions to files and folders.

Sharing Resources

This article continues the Networking for Beginners series by explaining how to make resources available on a network.

In the previous article, I talked about the OSI model and how it serves as a model for implementing abstraction between the hardware and the software. In this article, I had originally intended to talk about how protocol stacks are related to the OSI model. After giving it some thought I decided that the topic was relatively confusing, and that it didn't have a whole lot of real world value for new network administrators. That being the case, I want to talk about making resources available on a network instead. If you want to read about protocol stacks and how they relate to the OSI model, there are several good articles available on the Internet.

With that said, I want to turn my attention to making resources available over a network. If you really stop and think about it, the whole reason for building a network in the first place is so that resources can be shared among multiple computers. Resources come in a lot of different forms. Often, sharing resources means sharing files or folders, but not always. At the time that I first got started in networking, printers were very expensive, and it was not uncommon to see companies build networks so that a single printer could be shared by multiple employees. This saved the company from having to purchase and maintain a printer for every single employee.

Even small, home networks are all about sharing resources. The most common type of home network involves a wireless access point that also serves as an Internet router. On these types of networks, the Internet connection is the resource that is being shared. There is simply no reason to have a separate Internet connection for every computer, when the Internet connection can easily be shared.

As you can see, there are many different types of resources that can be shared on a network. The actual process for sharing the resource varies depending on the type of resource that is being shared and on the network operating systems that are being used. That being the case, I will begin my discussion by talking about how you can share files and folders on a network.

Before I Begin

Before I get started, I want to quickly mentioned that the information that I'm about to give you is based on Windows Server 2003. Windows Server 2003, Windows XP, and every previous version of Windows handle file and folder sharing in basically the same way. The actual steps that you use in the sharing process varies slightly from one Windows operating system to another, but the basic underlying concepts are the same. Windows Vista takes a different approach to sharing files than its predecessors do. That being the case, I will talk about filesharing and Windows Vista later on in this series. For right now though, just keep in mind that most of what I'm about to show you doesn't apply to Vista.

Creating A File Share

If you want to share in the files that are stored on a server, you'll have to first create a file share. A file share is essentially a designated entry point through which users can access the files. The reason why a file share is necessary is because it would be a huge security risk to share the full contents of the server.

Creating a file share is simple. To do so, begin the process by creating a folder in the location where you want the shared data to reside. For example, many file servers have a designated storage array or a data drive whose sole purpose is to store data (as opposed to program files and operating system components).

In most cases, you'll probably have quite a few folders worth of data that you need to share. It is also common for each of these folders to have its own unique security requirements. You can create a separate share for each folder, but doing so is usually considered to be a bad idea unless each share resides on a different volume. There are exceptions to every rule, but in most cases you will only want to create one file share per volume. You can place all of your folders within this single file share, and then assign the necessary permissions on a per folder basis. As this discussion progresses, you'll begin to understand why creating multiple file sharers is such a bad idea.

If you've already got a bunch of folders in place, and don't worry about it. You can easily create a new folder and then move your existing folders into the new folder. Another option is to create a file share at the volume level, in which case you would not have to move the existing folders.

For the purposes of this article, I'm going to assume that you've created a folder that will contain subfolders beneath it, and that you will be sharing this top level folder. Once you have created your folder, right-click on it and choose the Sharing and Security command from the resulting shortcut menu. When you do, you will see the folder's properties sheet, as shown in Figure A.

Figure A: The Sharing tab gives you the option of sharing the folder

As you can see in the figure, the Sharing tab allows you to control whether or not the folder is shared. When you select the Share this Folder option, you will be prompted to enter a share name. The name that you choose is very important. Windows isn't nearly as picky as it used to be about share names, but even so, I would recommend that you keep the share name under 16 characters and avoid using spaces or symbols for backward compatibility purposes. I should also mention that if you were to make the last character of the share name a dollar sign, then the share that you are creating becomes invisible. This is known as a hidden share. Windows offers several different hidden shares by default, and I will talk more about hidden shares later in the series.

The Comment field allows you to enter a comment about what the share is used for. This is purely for administrative purposes. Comments are optional, but documenting shares is never a bad idea.

Now take a look at the User Limit section. You will notice in the figure that the user limit is set by default to Maximum Allowed. Anytime that you deploy a Windows server, you must have the necessary client access licenses in place. You have the option of either a purchasing licenses for each individual client, or licensing the server to support a specific number of connections. Assuming that you have multiple servers, it is usually less expensive to license clients rather than an individual servers. At any rate, when the user limit is set to Maximum Allowed, it means that an unlimited number of clients can connect to the share until the number of connections meets the number of licenses that you have purchased. If you're using a per client licensing model, then access to the share is technically unlimited, but it's still up to use make sure that you have a license for every client.

Your other option is to allow a specific number of users to connect to the share. This option has a lot less to do with licensing than it does performance. Lower end hardware may not be able to support a large number of client connections. Therefore, Microsoft gives you the option of limiting the number of simultaneous connections to the share, so as not to overwhelm your hardware.

The OSI Model

How the OSI model is used to help applications to communicate across a network.

In last month’s article, I talked about the way that Windows (and other network operating systems) use a process called abstraction to allow applications to be developed without the vendor having to worry about creating drivers for specific hardware components. Although this concept is widely used throughout the Windows operating system, it is especially important when it comes to networking.

To see why this is the case think about what I talked about in the previous article in regard to hardware abstraction. Suppose that an application needs to be able to communicate across the network. The application developer does not build network drivers into the application, they merely write the application in a way that allows it to make certain calls to the Windows operating system. The manufacturer of the machine’s network adapter provides a driver that also links to Windows, and Windows performs the necessary match ups that allow the application to communicate with the network adapter.

Of course that is just the quick and dirty version. Things are actually quite a bit more complex than that. After all, the network adapter is just a device that is designed to send and receive packets of data. The card itself knows nothing of Windows, the application, or even of the protocols that are being used.

The example that I provided a moment ago implies that there are three layers at work; the application, the operating system, and the physical hardware. While these layers do exist (but not necessarily by those names), they can be subdivided into several more layers.

Before I explain what these layers are and what they do, I want to point out that the concepts that I am about to teach you are not abstract. In fact, if you open the Local Area Connection properties sheet, shown in Figure A, you can see that a network connection is made up of several different components, such as the network client, the network adapter driver, and the protocol. Each of these components corresponds to one or more individual layers.

Figure A: The Local Area Connection properties sheet offers a glimpse at the way that the various network layers are implemented in Windows

The network model that Windows, and most other network operating systems use is called the OSI Model. The term OSI Model is short for Open System Interconnection Basic Reference Model. The OSI Model consists of seven different layers. Each layer of the model is designed so that it can perform a specific task, and facilitate communications between the layer above it and the layer below it. You can see what the OSI Model looks like in Figure B.

Figure B: The OSI Model

The Application Layer

The top layer of the OSI model is the Application layer. The first thing that you need to understand about the application layer is that it does not refer to the actual applications that users run. Instead, it provides the framework that the actual applications run on top of.

To understand what the application layer does, suppose for a moment that a user wanted to use Internet Explorer to open an FTP session and transfer a file. In this particular case, the application layer would define the file transfer protocol. This protocol is not directly accessible to the end user. The end user must still use an application that is designed to interact with the file transfer protocol. In this case, Internet Explorer would be that application.

The Presentation Layer

The presentation layer does some rather complex things, but everything that the presentation layer does can be summed up in one sentence. The presentation layer takes the data that is provided by the application layer, and converts it into a standard format that the other layers can understand. Likewise, this layer converts the inbound data that is received from the session layer into something that the application layer can understand. The reason why this layer is necessary is because applications handle data differently from one another. In order for network communications to function properly, the data needs to be structured in a standard way.

The Session Layer

Once the data has been put into the correct format, the sending host must establish a session with the receiving host. This is where the session layer comes into play. It is responsible for establishing, maintaining, and eventually terminating the session with the remote host.

The interesting thing about the session layer is that it is more closely related to the application layer than it is to the physical layer. It is easy to think of connecting a network session as being a hardware function, but in actuality, sessions are usually established between applications. If a user is running multiple applications, several of those applications may have established sessions with remote resources at any time.

The Transport Layer

The Transport layer is responsible for maintaining flow control. As you are no doubt aware, the Windows operating system allows users to run multiple applications simultaneously. It is therefore possible that multiple applications, and the operating system itself, may need to communicate over the network simultaneously. The Transport Layer takes the data from each application, and integrates it all into a single stream. This layer is also responsible for providing error checking and performing data recovery when necessary. In essence, the Transport Layer is responsible for ensuring that all of the data makes it from the sending host to the receiving host.

The Network Layer

The Network Layer is responsible for determining how the data will reach the recipient. This layer handles things like addressing, routing, and logical protocols. Since this series is geared toward beginners, I do not want to get too technical, but I will tell you that the Network Layer creates logical paths, known as virtual circuits, between the source and destination hosts. This circuit provides the individual packets with a way to reach their destination. The Network Layer is also responsible for its own error handling, and for packet sequencing and congestion control.

Packet sequencing is necessary because each protocol limits the maximum size of a packet. The amount of data that must be transmitted often exceeds the maximum packet size. Therefore, the data is fragmented into multiple packets. When this happens, the Network Layer assigns each packet a sequence number.

When the data is received by the remote host, that device’s Network layer examines the sequence numbers of the inbound packets, and uses the sequence number to reassemble the data and to figure out if any packets are missing.

If you are having trouble understanding this concept, then imagine that you need to mail a large document to a friend, but do not have a big enough envelope. You could put a few pages into several small envelopes, and then label the envelopes so that your friend knows what order the pages go in. This is exactly the same thing that the Network Layer does.

The Data Link Layer

The data link layer can be sub divided into two other layers; the Media Access Control (MAC) layer, and the Logical Link Control (LLC) layer. The MAC layer basically establishes the computer’s identity on the network, via its MAC address. A MAC address is the address that is assigned to a network adapter at the hardware level. This is the address that is ultimately used when sending and receiving packets. The LLC layer controls frame synchronization and provides a degree of error checking.

The Physical Layer

The physical layer of the OSI model refers to the actual hardware specifications. The Physical Layer defines characteristics such as timing and voltage. The physical layer defines the hardware specifications used by network adapters and by the network cables (assuming that the connection is not wireless). To put it simply, the physical layer defines what it means to transmit and to receive data.

It works both ways

So far I have discussed the OSI Model in terms of an application that needs to transmit data across the network. The OSI Model is also used when a machine receives data. When data is received, that data comes in through the Physical Layer. The remaining layers work to strip away the encapsulation, and put the data into a format that the application layer can use.

In this article, I have explained how Windows uses the OSI model to implement networking. It is important to understand that the OSI model is only a guide as to how networking should be implemented. In the real world, protocol stacks sometimes combine multiple layers into a single component. I will show you how protocol stacks fit into the model in the next article in the series.

The Windows Operating System's Role in Networking

Last month I received an e-mail message from a reader who wanted to know why most of the articles in this series have focused on Windows. It was not so much that the person who sent me the message hated Microsoft, or preferred Linux, or anything like that, but wondered why Windows was necessary. As he correctly pointed out, networking has been around since long before Windows. To make a long story short, I thought that the message made a good point, so I wanted to take the opportunity to talk about the role that Windows plays in networking.

Before I Begin

Before I get started, there are a couple of things that I need to say up front. First, I am going to be spending some time talking about the early days of Windows. There are a lot of rumors alleging that Microsoft “borrowed” parts of the Windows Operating System from companies like IBM and Apple. Personally, I do not know if these rumors are true or not, and to be perfectly frank, I do not really care. I just wanted to acknowledge the point up front in an effort to reduce the number of e-mail messages that I receive in response to this article.

The other thing that I want to clarify up front is that today, every operating system implements networking in roughly the same way. Although one operating system might be more efficient than another, the end result is basically the same. After all, it is no coincidence that Windows, Macintosh, Linux, and UNIX can all communicate across the same Internet, using the same protocols.

By writing about Windows, I am not trying to start an operating system war, as I seem to have inadvertently done so many times in the past. I just choose to write about Windows because it is the most commonly used operating system, and articles about Windows would therefore theoretically benefit the largest number of people, and this is primarily a Windows focused website.

What Windows did for the World?

Now that I have hopefully appeased most of the haters, let us get down to business. The reason why Windows became such a dominant operating system was because it solved two major problems that plagued the IT industry.

The first of these problems is that prior to the creation of Windows, PCs were relatively difficult to use (at least for the lay person anyway). Prior to Windows 3.x, most PCs ran a Microsoft operating system known as MS-DOS. DOS was an acronym that stood for Disk Operating System.

The DOS operating system actually worked pretty well, but it did have some serious shortcomings. For starters, the operating system was text based. This meant that if you wanted to launch an application, you could not just point and click on an icon, you had to know the command or commands needed to launch that application. If you wanted to know how much free disk space you had, you could not just right click on a disk icon, you had to use the CHKDSK or DIR command.

The average person was intimidated by DOS. After all, using DOS even for the basics required learning quite a few commands. Many of those commands could do significant damage to your data if you accidentally used them incorrectly, so that added to the problem.

There is no denying that PC use was already becoming widespread before Microsoft introduced the graphical operating system, but Windows helped to make PCs much easier to use.

The second thing that Windows accomplished was far more important. Windows provided a level of abstraction that allowed device drivers to be separated from applications.

In the days of DOS, it was an application developer’s responsibility to include device drivers as a part of an application. For example, when I was in high school, the best word processor on the market was a now defunct product known as PFS Write. One of the things that made PFS Write such a good product was that it supported numerous printers. Even so, I recall purchasing a copy and installing it onto my computer, only to find out that it did not include a driver for my printer. As a result, I had to buy a new printer, just to be able to use a word processor.

Keep in mind that my previous printer was not junk. The problem was that most applications at the time shipped on floppy disks, which had an extremely limited capacity. As a result, application developers would typically only include drivers for the most commonly available hardware. At the time, it was not at all uncommon to find that some applications (especially video games) did not support particular video cards, sound cards, etc.

The way that drivers were tied to applications was bad for both application developers and for consumers. It was bad for application developers, because they had to spend time writing a zillion device drivers, which increased development cost and increased the amount of time that it took to get their product to market. Because an application could only support a limited set of hardware, the developer inevitably alienated some would be customers by not supporting their hardware.

Having device drivers tied to applications was bad for consumers as well. Typically, older hardware was not supported, often forcing consumers to purchase new hardware along with their new application. At the same time though, cutting edge hardware was not usually supported either. Application developers needed to create drivers that would work for the largest number of people possible, so it was rare for an application to contain drivers for the latest hardware. Often the new hardware was backward compatible with device drivers for older hardware, but it might take years for the cutting edge hardware’s full potential to be widely utilized by applications.

When Microsoft created Windows, they created an environment in which any application can interact with any hardware. Sure, applications still have minimum hardware requirements, but hardware brands and models do not really matter anymore. For example, if I wanted to print this document, it would not really matter what kind of printer I have, as long as I have a printer driver installed.

Windows is built in layers. Every Windows application generates print jobs in exactly the same way, regardless of what the application is, or what type of printer the job is being sent to. The Windows operating system then uses the specified print driver to translate the job into something that the printer can understand. The actual process is a little bit more complicated than this, but I wanted to convey the basic idea rather than going into a lot of boring architectural details.

The point is that abstracting applications from device drivers helps everyone. Application developers no longer suffer the burden of writing device drivers, and consumers are now free to use any hardware they want (so long as it meets minimum standards) without having to worry about whether or not it will work with a particular application.

As you can see, Microsoft was able to design Windows in a way that allowed applications to be abstracted from device drivers. In the next part of this article series, I will continue the discussion by showing you how this architecture assists with networking.

Universal Groups & Group Nesting

This article continues the discussion on Universal Groups and the concept of group nesting.

In the previous article in this series, I introduced you to the concept of using groups to manage network access control, rather than granting permissions directly to users. I then went on to explain that Windows Server 2003 supports a few different types of groups, and that each of these types of groups has its own strengths and limitations.

In that article, I talked a lot about local groups, domain local groups, and global groups. You could easily manage your entire network using only these types of groups. Even so, there is one more type of group that Windows Server 2003 supports; universal groups.

For those of you who found local groups, domain local groups, and global groups to be confusing or overly restrictive, then universal groups will initially seem like an answer to prayers. Universal groups are essentially groups that are not subject to the restrictions that apply to the other types of groups. For example, in the previous article, I mentioned that you can’t place a local group or a domain local group into another local group. You can however, put a universal group into a local group. The rules that apply to other types of groups simply don’t apply to universal groups.

Of course, this raises the question of why you would ever use any of the other types of groups if they have limitations that universal groups can overcome.

One of the reasons why there are so many different types of groups is because Windows Server is an evolutionary product. Universal groups were introduced in Windows 2000 Server, along with the Active Directory. Previous versions of Windows Server (namely Windows NT Server) supported the use of groups, but universal groups had not been invented yet when these versions were current. When Microsoft released Windows 2000 Server, they chose to continue to support other types of groups as a way of maintaining backward compatibility with Windows NT. Likewise, Windows Server 2003 also supports the use of legacy group types for backward compatibility reasons.

The fact that universal groups didn’t exist in the days of Windows NT Server, means that Windows NT doesn’t support universal groups. This presents a bit of a problem if you happen to have any Windows NT servers in your forest.

Windows 2000 Server was such a dramatic change from Windows NT Server that a number of the new features would only work on networks with no Windows NT Server domain controllers. To get around this problem, Microsoft created the concept of native mode. I will talk a lot more about native mode in Part 17, but the basic idea is that when Windows 2000 Server is initially installed, it is operating in something called mixed mode. Mixed mode is fully backward compatible with Windows NT, but many of Windows 2000’s features can’t be used until you get rid of the Windows NT domain controllers and switch to native mode. Although the terminology is a bit different, the same basic concept also applies to Windows Server 2003.

Universal groups are one of those features that is only available if your domain controllers are operating in Windows 2000 Server Native Mode or higher. That’s one reason why you can’t use universal groups in every situation.

Even if all of your servers are running Windows Server 2003, and your forest is fully native, it is still a bad idea in most cases to use universal groups exclusively.

Earlier in this series, I introduced you to the concept of global catalog servers. As you may recall, global catalog servers are domain controllers that have been assigned the task of keeping track of every object in the forest. Typically, each Active Directory site contains its own copy of the global catalog, which means that any time a global catalog is updated, the updated information must be replicated to the other global catalog servers.

When you create a universal group, both the group name and the group’s membership list are written to the global catalog. This means that as you create more and more universal groups, the global catalog becomes more bloated. As the global catalog becomes larger, the amount of time that it takes to replicate the global catalog from one global catalog server to another also increases. If left unchecked, this can lead to network performance problems.

In case you are wondering, other types of groups don’t place nearly as much of a load on the global catalog. For example, global groups are listed in the global catalog, but their membership list isn’t. Therefore, Microsoft’s basic rule of thumb is that it is OK to create universal groups, but you should use them sparingly.

Group Nesting

One last group related concept that I want to discuss is that of nesting. The easiest way that I can think of to explain nesting is to compare it to Russian matryoshka dolls, like the ones shown in Figure A. These types of dolls are designed so that they can all be placed inside of one another. The smallest goes into the second smallest, the second smallest goes into the third smallest, and so on. This idea of placing an object inside of a similar object is called nesting.

Figure A: Russian matryoshka dolls illustrate the concept of nesting.

There are many different reasons for nesting groups. One of the most common reasons involves matching up resources with departments. For example, a company might start by creating a group for each department. They might create a Finance group, a Marketing group, an IT group, and so on. Next, they would place users into the group that corresponds to the department that the user works in.

The next step in the process would be to create groups that correspond to the various resources that you need to grant access to. For example, if you knew that everyone in the finance department was going to need access to an accounting application, you could create a group that grants access to the application, and then place the finance group into that group. You don’t have to nest groups, but doing so sometimes allows you to keep things a little bit better organized, while saving a little bit of work in the process. For instance in the previous example, you didn’t have to manually place individual user accounts into the group for the accounting application. Instead, you just reused a group that already existed.

Keep in mind that not every group can be nested into every other type of group. The table below shows which types of groups can be nested into other groups.

Group Type	Can Be Nested into Local	Can Be Nested into Domain Local	Can Be Nested into Global	Can Be Nested into Universal
Local	No	No	No	No
Domain Local	Yes	Yes, if in the same domain	No	No
Global	Yes	Yes	Yes, if in the same domain	Yes
Universal	Yes	Yes	No	Yes

Table 1

Caveats

If Windows is operating in Windows 2000 mixed mode, the following limitations apply:

• Universal groups cannot be created
• Domain local groups can only contain global groups
• Global groups can not contain other groups

In this article, I have explained that it is sometimes advantageous to nest one group within another group. I then went on to discuss under which situations it is possible to do this.

In the next part of this article series, I am going to take a step back and talk about the role that the Windows operating system plays in networking.

Security Groups

The various types of security groups that Windows allows you to create.

In the previous article, I showed you how to create security groups in Windows Server 2003. When I walked you through the process though, you might have noticed that Windows allows you to create a few different types of groups, as shown in Figure A. As you might have guessed, each of these group types has a specific purpose. In this article, I will explain what each type of group is used for.

Figure A: Windows allows you to create a few different types of groups

If you look at the dialog box shown above, you will notice that the Group Scope area provides you with the option of creating a domain local, global, or universal group. There is also a fourth type of group that is not shown here, it is simply called a local group.

Local Groups

Local groups are groups that are specific to individual computer. As you know by now, local computers can contain user accounts that are completely separate from those accounts that belong to the domain that the computer is connected to. These are known as a local user accounts, and they are only accessible from the computer on which they reside. Furthermore, local user accounts can only exist on workstations and on member servers. Domain controllers do not allow for the existence of local user accounts.

With this in mind that should come as no surprise that local groups are simply groups that are specific to a particular member server or workstation. A local group is often used to manage local user accounts. For example, the local Administrators group allows you to designate which users are administrators over the local machine.

Although a local group can only be used to secure resources residing on the local machine, it doesn't mean that the group's membership must be limited to local users. While a local group can, and usually does, contain local users, it can also contain domain users. Furthermore, local groups can also contain other groups that reside at the domain level. For example, you could make a universal group a member of a local group, and the universal group’s members will basically become members of the local group. In fact, a local group can contain local users, domain users, domain local groups, global groups, and universal groups.

There are two caveats that you need to be aware of though. First, as you might have noticed, a local group cannot contain another local group. It would seem that you should be able to drop one group into another, but you can’t. Someone at Microsoft once told me that the reason for this is to prevent a situation in which two local groups become members of each other.

The other caveat that you need to be aware of is that local groups can only contain domain users and domain level groups if the machine containing the local group is a member of the domain. Otherwise, local groups can only contain local users.

Domain Local Groups

Given what you've just learned about local groups, the idea of a domain local group probably sounds contradictory. The reason why domain local groups exist though, is because domain controllers do not contain a local account database. This means that there are no such things as local users or local groups on a domain controller. Even so, domain controllers have local resources that need to be managed. This is where domain local groups come into play.

When you install Windows Server 2003 onto a computer, the machine typically begins life as either a standalone server or as a member server. In either case, local user accounts and local groups are created during the installation process. Now suppose that you wanted to convert the machine into a domain controller. When you run DCPROMO, the local groups and local user accounts are converted into domain local groups and domain user accounts.

It is important to keep in mind that all of the domain controllers within a domain share a common user account database. This means that if you add a user to a domain local group on one domain controller, the user will be a member of that domain local group on every domain controller in the entire domain.

The most important thing to keep in mind about domain local groups is that there are two different types. As I mentioned, when DCPROMO is run, the local groups are converted to domain local groups. Any domain local groups that are created by running DCPROMO are placed into the Builtin folder in the Active Directory Users and Computers console, as shown in Figure B.

Figure B: Domain local groups created by DCPROMO reside in the Builtin container

The reason why this is important to know is because there are some restrictions imposed on these particular domain local groups. These groups cannot be moved or deleted. Likewise, if you cannot make these groups members of other domain local groups.

These restrictions do not apply to domain local groups that you create though. Domain local groups that you create typically began life in the Users container. From there, you are free to move or delete them to your heart’s content.

I have to be perfectly frank and tell you though that in all the years I have been working with Windows Server, I have yet to find a good argument for creating domain local groups. In fact, domain local groups are basically identical to global groups, except that they are restricted to an individual domain.

Global Groups

Global groups are by far the most commonly used type of group. In most cases, a global group simply acts as a collection of Active Directory user accounts. The interesting thing about global groups is that they can be placed inside of each other. You can make one global group a member of another global group, so long as both global groups exist within the same domain.

Keep in mind, the global groups can only contain Active Directory resource. You cannot place a local user account or a local group into a global group. You can however, add a global group to a local group. In fact, doing so is the most common way of granting domain users permissions to resources stored on a local computer. For example, suppose that you wanted to give the managers in your company administrative rights to their workstations (not that I recommend doing that, this is just an example). To do so, you could create a global group called Managers, and place each of the manager’s domain user accounts into it. You could then add the Managers group to the workstation’s local Administrators group, thus making the managers administrators on those workstations.

In this article, I've explained that Windows supports the use of four different types of security groups. So far, I have explained the differences between local, domain local, and global groups. In the next part of this article series, I will continue the discussion by discussing universal groups. I will then go on to discuss the concept of group nesting