Friday, November 13, 2009

Database Server

Refers to the back-end system of a database application using client/server architecture. The back-end, sometimes called a database server, performs tasks such as data analysis, storage, data manipulation, archiving, and other non-user specific tasks.

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.

In a master-slave model, database master servers are central and primary locations of data while database slave servers are synchronized backups of the master acting as proxies.

Implementation of Database Server:

A database server can be implemented in a straightforward manner as separate node (on a network) dedicated to running database-management software. This node provides an interface to client nodes such that the same data is accessible to all nodes. The interface allows users to submit requests to the database server and retrieve information. These requests are typically made using a high-level query language such as SQL (standard query language).

The server manages the any processor-intensive work such as data manipulation, compilation, and optimization, and sends only the final results back to the client. Database servers are typically made to run on a UNIX operating system.

Benefits of using Database Server:

  • A database server allows users to store data in one central location.
  • It performs complex functions such as searching, sorting, and indexing on the server itself. This reduces network traffic because fewer items need to be transferred between the client and the server.
  • Because data is stored centrally, there is enhanced security.
  • A database server uses its own processing power to find requested data, rather than sending the complete data to the client so that the client searches for the data, as is done in a file server.
  • A database server allows concurrent access to data.
The types of databases available:

As database software has evolved, a number of different approaches to storing and linking information have emerged. Some of the more common include:

Relational databases. A relational database creates formal definitions of all the included items in a database, setting them out in tables, and defines the relationship between them. For instance, a typical business database would include tables for defining both customers and orders. Using ids or keys, the two tables can be related together. Such databases are called 'relational' because they explicitly define these connections (an order form can look up customer details from the customer table rather than having to store the information twice). Most relational databases now make use of SQL to handle queries (discussed in more detail below). Currently these are the most common form of database.

Object databases. Object databases store data in discreet, self-contained units - objects. These objects have specific data, attributes and behaviours associated with them. An extremely simple example might be a product database with a shirt object, which has attributes such as size, colour, and price. In practical use, the main difference between object and relational databases is the way in which data is accessed. Programmers use object-oriented programming languages to access the data objects from the object database by calling methods in their code. This takes much of the information that would have resided in the application code and transfers that information to the object database. Thus the application code is simplified. However, at the same time the fact that the database and application are tightly entwined can make accessing the data outside of the application more complex.

Object-relational databases. Object-relational databases attempt to combine object and relational approaches. This allows the benefits of using objects where necessary to be tied to the strengths of relational databases.

Hierarchical databases. While relational databases arrange data in tabular format, hierarchical databases arrange them in a tree format, with a parent node leading to further child nodes (which in turn may have further nodes of their own). The model is very similar to the way in which a program such as Windows Explorer displays the contents of a hard drive (double-clicking on a parent directory leads down the tree to further information, and so on down the directory tree). This allows for multiple types of subsidiary data, but makes it difficult to identify complex multiple relationships between individual data items (just as there is no obvious link between two subdirectories on a hard drive).

Until recently, hierarchical databases have been more common in computer science fields than in real-world applications. However, hierarchical methods have become more popular with the emergence of XML (Extensible Markup Language), which uses a hierarchical structure, as a common data exchange format.

About SQL

SQL (Structured Query Language) is used by relational databases to define queries and help generate reports. First developed in 1976, it provides a standardised means of sending queries to relational databases. SQL also defines more fundamental elements of databases, such as data types. SQL has become a dominant standard in the world of database development, since it allows developers to use the same basic constructions to query data from a wide variety of systems.

The central functions of SQL have been defined by international standards organisations: originally the American National Standards Institute (ANSI), and subsequently the International Standards Organisation (ISO). Like most computer-based standards, SQL also comes in a number of flavours. The two most recent iterations are SQL-99 (also sometimes known as SQL-3) and SQL-92, both named for the years in which they were first released. (SQL-99 had been originally planned for release in 1996).

While SQL-92 defined three individual levels of compliance (basic, intermediate and advanced), SQL-99 reverted to the model used in previous versions of providing just one large feature list. More importantly, SQL-99 also added some basic support for object features, extending SQL's usefulness and blurring the distinction between relational and object approaches to databases.

It is comparatively rare for vendors to implement the precise standards laid down for SQL, which is a complex standard running into thousands of pages. Several companies choose not to implement every aspect of the existing standards, arguing that the functions in question are rarely if ever needed by developers or users. Simultaneously, many provide additional, functions (known as extensions) to make particular tasks easier. Despite what you might suspect, many companies will simultaneously add their own extensions while ignoring some aspects of the basic standard. Whether these additions and exclusions are important to your business will depend on the exact mix of applications you wish to run or develop, and what existing applications you already have in place.

How to choose Database Server?

When choosing a database server, the most important consideration will be whether it can deliver the specific application functions you require. These may be supplied in the form of pre-packaged software, or you may choose to develop your own (or more likely hire a consultant to do so). This may involve considerable expenditure, but this needs to be balanced against improved staff productivity and the ability to more accurately analyse your business.

Standards compliance. As discussed above, SQL support varies widely between database server suppliers. Databases which comply with SQL should allow relatively straightforward data exchange, so SQL compliance is important, especially in environments running more than one operating system.

Security systems. Databases often store highly valuable and sensitive commercial information, so it's important that there is some security system in place, even if this is only a basic username/password system. Most database servers will provide audit trails, allowing you to see who has entered, accessed or modified information. If your database server is going to be exposed to the Internet, then security mechanisms will need to be more robust and you will need to consider whether other mechanisms (such as encryption) are necessary as well.

Performance features. Databases are generally critical applications, and even a brief outage can be harmful to your business. To help prevent this, modern database servers have borrowed many features from the world of general network operating systems, including fault tolerance (systems to keep the server running in the event of unexpected errors) and load balancing (which allows database queries on high-volume systems to be handled by multiple servers, improving performance and response times). These are unlikely to be needed if you're just running a single database server, but as your needs expand they are likely to become more crucial considerations. If your database server is used for e-commerce applications, these availability issues will take on a heightened degree of importance.

While you may not require all these features immediately, you should consider future needs as well as your current plans. Retrofitting these features to your system is likely to be more difficult than installing a database server that supports them from the beginning, even if it takes time for you to actively deploy them.

XML: If you will be doing data interchange now or in the future you may want to look for a database that allows extraction of data as XML. This may make using XML as a data interchange format simpler.

Tuesday, November 10, 2009

Web Server

There are two common features of the web servers: One is Virtual Hosting to serve many web sites using one IP address and another is Bandwidth Throttling to limit the speed of responses in order to not saturate the network and to be able to serve more clients.

Virtual Hosting

Virtual hosting is a method that servers such as web servers use to host more than one domain name on the same computer, sometimes on the same IP address. Virtual web hosting is one of the most popular hosting options available at the moment probably because it is one of the most cost effective options on the market. Also known as shared web hosting, virtual hosting allows a website owner to have a site hosted on a web server that is shared with other websites. In simple terms, the virtual hosting company's server will allocate out hosting services and bandwidth to more than one website. Virtual web hosting is a cheaper hosting option because you won't have to pay for a dedicated server to host just your website. Virtual web hosting is a good solution for small- to medium-sized (and even some larger) websites that aren't constantly being visited or that have reasonable bandwidth needs.

There are two basic methods of accomplishing virtual hosting: name-based, and IP address or ip-based.

Name Based :

Name-based virtual hosts use multiple host names for the same webserver IP address. With web browsers that support HTTP/1.1 (as nearly all now do), upon connecting to a webserver, the browsers send the address that the user typed into their browser's address bar (the URL). The server can use this information to determine which web site, as well as page, to show the user. The browser specifies the address by setting the Host HTTP header with the host specified by the user. The Host header is required in all HTTP/1.1 requests.

If the Domain Name System (DNS) is not properly functioning, it becomes much harder to access a virtually-hosted website. The user could try to fall back to using the IP address to contact the system, as in http://10.23.45.67/. The web browser doesn't know which hostname to use when this happens; moreover, since the web server relies on the web browser client telling it what server name (vhost) to use, the server will respond with a default website—often not the site the user expects.

A workaround in this case is to add the IP address and hostname to the client system's hosts file. Accessing the server with the domain name should work again. Users should be careful when doing this, however, as any changes to the true mapping between hostname and IP address will be overridden by the local setting. This workaround is not really useful for an average web user, but may be of some use to a site administrator while fixing DNS records.

Another issue with virtual hosting is the inability to host multiple secure websites running Secure Sockets Layer or SSL. Because the SSL handshake takes place before the expected hostname is sent to the server, the server doesn't know which certificate to present when the connection is made. One workaround is to run multiple web server programs, each listening to a different incoming port, which still allows the system to just use a single IP address. If running multiple web server programs is considered clumsy, a more efficient solution is to select TLS. Another option is to do IP aliasing, where a single computer listens on more than one IP address.

IP Address

In IP-based virtual hosting each site (either a DNS hostname or a group of DNS hostnames that act the same) points to a unique IP address. The web server is configured with multiple physical network interfaces, virtual network interfaces on the same physical interface or multiple IP addresses on one interface.

The web server can obtain the address the TCP connection was intended for using a standard API and use this to determine which website to serve. The client is not involved in this process and therefore (unlike with name based virtual hosting) there are no compatibility issues.

Path Installation

Web servers are able to map the path component of a Uniform Resource Locator (URL) into:

  • a local file system resource (for static requests);
  • an internal or external program name (for dynamic requests).

For a static request the URL path specified by the client is relative to the Web server's root directory. Consider the following URL as it would be requested by a client:

http://www.example.com/path/file.html

The client's web browser will translate it into a connection to www.example.com with the following HTTP 1.1 request:

GET /path/file.html HTTP/1.1
Host: www.example.com

The web server on www.example.com will append the given path to the path of its root directory. On Unix machines, this is commonly /var/www. The result is the local file system resource:

/var/www/path/file.html

The web server will then read the file, if it exists, and send a response to the client's web browser. The response will describe the content of the file and contain the file itself.

Bandwidth Throttaling :

Bandwidth throttling is a method of ensuring a bandwidth intensive device, such as a server, will limit ("throttle") the quantity of data it transmits and/or accepts within a specified period of time. For website servers and web applications, bandwidth throttling helps limit network congestion and server crashes, whereas for ISP's, bandwidth throttling can be used to limit users' speeds across certain applications (such as BitTorrent), or limit upload speeds.

A server, such as a web server, is a host computer connected to a network, such as the Internet, which provides data in response to requests by client computers. Understandably, there are periods where client requests may peak (certain hours of the day, for example). Such peaks may cause congestion of data (bottlenecks) across the connection or cause the server to crash, resulting in downtime. In order to prevent such issues, a server administrator may implement bandwidth throttling to control the number of requests a server responds to within a specified period of time.

When a server using bandwidth throttling has reached the allowed bandwidth set by the administrator, it will block further read attempts, usually moving them into a queue to be processed once the bandwidth use reaches an acceptable level. Bandwidth throttling will usually continue to allow write requests (such as a user submitting a form) and transmission requests, unless the bandwidth continues to fail to return to an acceptable level.

Likewise, some software, such as peer-to-peer (P2P) network programs, have similar bandwidth throttling features, which allow a user to set desired maximum upload and download rates, so as not to consume the entire available bandwidth of his or her Internet connection.

Load Limits:

A web server (program) has defined load limits, because it can handle only a limited number of concurrent client connections (usually between 2 and 80,000, by default between 500 and 1,000) per IP address (and TCP port) and it can serve only a certain maximum number of requests per second depending on:

  • its own settings;
  • the HTTP request type;
  • content origin (static or dynamic);
  • the fact that the served content is or is not cached;
  • the hardware and software limits of the OS where it is working.
When a web server is near to or over its limits, it becomes overloaded and thus unresponsive.

Kernal-mode and user-mode web servers:

A web server can be either implemented into the OS kernel, or in user space (like other regular applications).

An in-kernel web server (like TUX on Linux or Microsoft IIS on Windows) will usually work faster because, as part of the system, it can directly use all the hardware resources it needs, such as:

  • non-paged memory;
  • CPU time-slices;
  • network adapters buffers.

Web servers that run in user-mode have to ask the system the permission to use more memory or more CPU resources. Not only these requests to the kernel take time, but they are not always satisfied because the system reserves resources for its own usage and has the responsibility to share hardware resources with all the other running applications.

Also applications cannot access the system internal buffers, which is causing useless buffer copies that create another handicap for user-mode web servers. As a consequence, the only way for a user-mode web server to match kernel-mode performances is to raise the quality of its code to much higher standards than the code used into another web server that runs in the kernel.

This is more difficult under Windows than under Linux where the user-mode overhead is 6 times smaller than under Windows.

Overload Causes:

At any time web servers can be overloaded because of:

  • Too much legitimate web traffic. Thousands or even millions of clients hitting the web site in a short interval of time. (e.g. Slashdot effect);
  • DDoS. Distributed Denial of Service attacks;
  • Computer worms that sometimes cause abnormal traffic because of millions of infected computers (not coordinated among them);
  • XSS viruses can cause high traffic because of millions of infected browsers and/or web servers;
  • Internet web robots. Traffic not filtered/limited on large web sites with very few resources (bandwidth, etc.);
  • Internet (network) slowdowns, so that client requests are served more slowly and the number of connections increases so much that server limits are reached;
  • Web servers (computers) partial unavailability. This can happen because of required or urgent maintenance or upgrade, hardware or software failures, back-end (e.g. DB) failures, etc.; in these cases the remaining web servers get too much traffic and become overloaded.
Mostly Used Server in the World:

Vendor Product Web Sites Hosted Percent
Apache Apache 108,078,535 46.90%
Microsoft IIS 49,723,999 21.58%
Tencent qq.com 30,069,136 13.05%
Google GWS 13,819,947 6.0%
nginx nginx 13,813,997 5.99%


Sunday, November 8, 2009

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.

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.


  • Friday, November 6, 2009

    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

    Saturday, October 3, 2009

    Creating Groups

    In the previous article in this series, I showed you how to use the Active Directory Users and Computers console to create and manage user accounts. In this article, I want to continue the discussion by teaching you about groups.

    In a domain environment, user accounts are essential. A user account gives a user a unique identity on the network. This means that it is possible to track the user’s online activity. It is also possible to give a user account a unique set of permissions, assign the user a unique e-mail address, and meet all of the user’s other individual needs.

    Although custom tailoring a user account to meet a user’s individual needs sounds like a good idea, it isn’t really practical in a lot of cases. Setting up and managing user accounts is a time consuming task. It isn’t a big deal if you’ve only got a couple dozen users in your organization, but if your organization has thousands of users, then account management can quickly become an overwhelming burden.

    My advice is that even if you manage a very small network, you should treat the small network as if it were a big network. The reason for this is that you never know when the network will grow. Using good management techniques from the very beginning will help you to avoid a logistical nightmare later on.

    I have actually seen the consequences of unexpected, rapid growth in the real world. About fifteen years ago, I was hired as a network administrator for an insurance company. At the time, the network was very small. There were only a couple dozen workstations attached to the network. The woman who was in charge of the network had no prior IT experience and was thrown to the wolves, so to speak. Not having an IT background, and not knowing any better, she had configured the network so that all of the configuration settings existed on a per user basis.

    At the time, this was no big deal. There weren't many users, and it was easy to manage the various accounts and permissions. Within a year there were over two hundred PCs on the network. By the time I left the company a couple of years later, there were well over a thousand people using a network that was only initially designed to handle a few dozen.

    As you can imagine, the network experienced some severe growing pains. Some of these growing pains were related to hardware performance, but most were related to the inability to effectively manage that many user accounts. Eventually, the network became such a mess that all of the user accounts had to be deleted and recreated from scratch.

    Obviously, rapid unexpected growth can cause problems, but you are probably wondering why in the world things became so unmanageable that all of the accounts had to be deleted so that we could “just start over”.

    As I mentioned before, all of the configuration and security settings were user based. This meant that if a department manager came to me and asked me to tell him who had access to a particular network resource, I would have to look at every account individually to see whether or not the user had access to the resource. When you only have a couple dozen users, checking every account to see which users have access to something is tedious and disruptive (at the time, checking took about 20 minutes). When you’ve got a couple hundred users checking every user account can take most of the day.

    Granted, the events that I just described happened well over a decade ago. As the IT industry goes, these events might as well have occurred in prehistoric times. After all, the network operating systems that were in use at the time are now extinct. Even so, the lessons learned back then are as relevant today as they were then.

    All of the problems that I just described could have been prevented if groups had been used. The basic idea behind groups is that a group can contain multiple user accounts. Since security settings are assigned at the group level, you should never manually assign permissions directly to a user account. Instead, you would assign permission to a group, and then make the user a member of the group.

    I realize that this might sound a little confusing, so I will demonstrate the technique for you. Suppose that one of your file servers contains a folder named Data, and that you need to grant a user read access to the Data folder. Rather than assigning the permission directly to the user, let’s create a group.

    To do so, open the Active Directory Users and Computers console. When the console opens, right click on the Users container, and select the New | Group commands from the resulting shortcut menus. Upon doing so, you will see a screen similar to the one that is shown in Figure A. At a minimum, you must assign a name to the group. For ease of management, let’s just call the group Data, since the group is going to be used to secure the Data folder. For right now, don’t worry about the group scope or the group type settings. I will teach you about these settings in the next part of this series.



    Figure A: Enter a name for the group that you are creating

    Click OK, and the Data group will be added to the list of users, as shown in Figure B. Notice that the group’s icon uses two heads, indicating that it is a group, as opposed to the single headed icon used for user accounts.

    Figure B: The Data group is added to the list of users

    Now, double click on the Data group, and you will see the group’s properties sheet. Select the properties sheet’s Members tab, and click the Add button. You are now free to add user accounts to the group. The accounts that you add are said to be group members. You can see what the Members tab looks like in Figure C.


    Figure C: The Members tab lists all of the group’s members

    Now it’s time to put the group to work. To do so, right click on the Data folder, and select the Properties command from the resulting shortcut menu. When you do, you will see the folder’s properties sheet. Go to the properties sheet’s Security tab, and click the Add button. When prompted, enter the name of the group that you just created (Data) and click OK. You are now free to establish a set of permissions for the group. Whatever permissions you apply to the group, also apply to group members. As you can see in Figure D, there are some other rights that are applied to the folder by default. It is best to remove the Users group from the access control list to prevent any accidental contradictions of permissions.

    Figure D: The Data group is added to the folder’s access control list

    Remember earlier when I mentioned how much work it was to try to figure out which users had access to a particular resource? Well, when groups are in use, the process becomes simple. If you need to know which users have access to the folder, just look to see which groups have access to the folder, as shown in Figure D. Once you know which groups can access the folder, determining who has rights to the folder is as simple as checking the group’s membership list (shown in Figure C). Any time additional users need access to the folder, just add their names to the list of group members. Likewise, you can remove permissions to the folder by deleting a user’s name from the list of group members.

    In this article, I have shown you how to create security groups in a Windows Server 2003 environment. In the next article in the series, I will continue the discussion by showing you the impact of selecting a different group type.

    User Account Management

    Creating a User Account

    One of the most common uses for the Active Directory Users in Computers console is to create new user accounts. To do so, expand the container corresponding to the domain that you are attached to, and select the Users container. When you do, the console's details pane will display all of the user accounts that currently exist in the domain, as shown in Figure A


    Figure A: Selecting the Users container causes the console to display all of the user accounts in the domain.

    Now, right click on the Users container and select the New command from the resulting shortcut menu. When you do, you will see a submenu that gives you the choice of many different types of objects that you can create. Technically, the Users container is just a container and you can put pretty much any type of object in it. It is generally considered bad practice though to store objects other than user objects in the Users container. That being the case, select the User command from the submenu. When you do, you will see the dialog box shown in Figure B.



    Figure B: The New Object – User dialog box allows you to create a new user account.

    As you can see in the figure, Windows initially only requires you to enter some very basic information about the user. Although this screen asks for things like first name and last name, these are not technically required. The only piece of information that is absolutely required is the User Logon Name. Although the other fields are optional, I recommend filling them in anyway.

    The reason why I recommend filling in as many fields as you can is because a user account is nothing more than an object that will reside within the Active Directory. Things like first name and last name are attributes of the user object that you are creating. The more attribute information that you fill in, the more useful the information stored in the Active Directory will be. After all, the Active Directory is a database that you can query for information. In fact, many applications work by extracting the various attributes from the Active Directory. When you have filled in the various fields, click the Next button, and you will be taken to the screen shown in Figure C.



    Figure C: You will be prompted to assign a password to the new user account.

    As you can see in the figure, assigning a password is fairly simple. All you really have to do is type, and retype the password. By default, the user is required to change the password at the next logon. You can prevent this behavior by clearing the User Must Change Password at Next Logon check box. There is another check box allowing you to prevent the user from changing their password at all. You also have the option of setting passwords to never expire, or disabling the account completely.

    Although there is nothing overly complex about the password screen, there is one important thing to keep in mind. When you assign a password to a new user account, the password must comply with your corporate security policy. If the password that you use does not meet the requirements dictated by the applicable group policies, then the user account will not be created.

    Click next and you will see a screen displaying a summary of the options that you have chosen. Assuming that everything looks good, click Finish and the new user account will be created.

    Editing User Account Attribute

    Earlier, I discussed the importance of filling in the various attributes as you create a new user account. You might have noticed that the screens involved in creating a new user account did not really have many attributes that you were able to fill in. However, the Active Directory contains dozens of built in attributes related to user accounts.

    I am not saying that you have to go through the console and populate dozens of attributes for every single user account. There are some attributes that do come in handy. I recommend populating attributes that are related to basic contact information. In fact, some corporations create corporate directories that are based solely on information stored in these Active Directory attributes. Even if you are not interested in building applications that extract information from your Active Directory, it is still a good idea to populate the Active Directory with user contact information. For example, suppose that you need to reboot a server, and a user is still logged into an application that resides on the server. If you have the user's contact information stored in the Active Directory, then you can simply look up the user's phone number, and call the user to ask them to log out.

    Before I show you how to populate the various Active Directory attributes, I want to mention that the same technique can also be used for modifying existing attributes. For example, if a female employee were to get married, she might change her last name. You could use the techniques that I am about to show you to modify the contents of the Last Name attribute.

    To access the various user account attributes, simply right click on the user account of choice and select the Properties command from the resulting shortcut menu. Upon doing so, Windows will display the screen shown in Figure D.

    Figure D: The user's properties sheet is used to store attribute and configuration information for the user account.

    As you can see in the figure, the properties sheet's General tab allows you to modify the user’s first name, last name, or display name. You can also fill in (or modify) a few other fields such as Description, Office, Telephone Number, E-mail, or Web Page. If you are interested in storing more detailed information about the user, then check out the Address, Telephones, and Organization tabs. These tabs all contain fields for storing much more detailed information about the user.

    Resetting a User's Password

    You probably noticed in Figure D that there are a lot of different tabs on the user’s properties sheet. Most of these tabs are related to the security and configuration of the user account. One thing that most new administrators seem to notice right away when exploring these tabs is that there is no option on any of the tabs to reset the user’s password.

    If you need to reset a user’s password, then close the user’s properties sheet. After doing so, right click on the user account and select the Reset Password command found on the resulting shortcut menu.

    In this article, I have walked you through the processes of creating a user account, populating the various Active Directory attributes related to that account, and resetting the account password. In the next article in the series, I will continue the discussion by demonstrating more of the Active Directory Users and Computers console’s capabilities.