Active Directory Installation & Configuration Interview Questions Tutorials

Many Interviewers ask this question: Explain how you installed & configured your Active Directory Service so its better I share the answers with you. Please read the above post for the first segment.This is a continuation of the explanation from the above post.

5.The next screen will ask you to specify the full DNS domain name for your new domain.You do not have to use your company's registered public (Internet) domain name here,but you can if you would like. For this lab, type in MYCOMPANY.com and click Next.

6. The next screen will ask you to specify the NetBIOS name for the domain. This is the domain name that legacy systems (anything before Windows 2000) and applications that only support NetBIOS will use. The main difference is that the NetBIOS domain name can only contain up to 15 characters with no periods. By default the wizard will suggest a name for you, based on the domain name you entered earlier, only now it will use the NetBIOS name rules. In this case, it should come up as MYCOMPANY. You can modify this name if you would like, but it would most likely lead to confusion down the road, as your domain will effectively have two names. Leave the default name, MYCOMPANY. Click on Next.

7. The next screen will ask where you want to place the Active Directory database and log. It's recommended in a production environment, that you place the log file on a separate physical hard drive to increase the performance of Active Directory. This is optional for the lab, if you do not have two physical hard drives you can leave it at the default setting which will be the %systemroot%\WINNT\NTDS for both the database and the log, or c:\WINNT\NTDS. Click Next.
 
8. The next screen will ask you for the location of the SYSVOL folder. This system folder stores any user configurations, default profiles, and logon scripts that you may have on the network. The folder is automatically shared and replicates to other domain controllers throughout Active Directory. The default location of the folder is %systemroot%\WINNT\SYSVOL but you may still change the location of the folder.
You always want to try to keep things as simple as possible so leave the default location for the folder and click Next.

9. A dialog box will appear and tell you the wizard was unable to find the DNS server that handles the name benandbrady.com and then ask you to confirm that the DNS configuration is working properly, or install and configure a DNS server on this computer. Active Directory was designed to work with DNS and will not function without a DNS server that handles name resolution for the domain. Click OK.

10. Within the wizard, you will see a screen asking if you would like to install and configure DNS on this computer now or if you would like to install and configure DNS yourself. If you select yes, the wizard will install DNS for you but if you select no it will end the wizard and tell you that it cannot continue and the Active Directory installation will fail. Let the wizard install and configure the DNS server for you. Select Yes, install, and configure DNS on this Computer and click Next.
 
11. The next screen will ask you what the default permissions should be for users and groups. The first option is for permissions compatible with pre-Windows 2000 servers.This setting will loosen up security a little, but it will allow NT 4.0 RAS servers and other programs to be able to authenticate users. The second option is for permissions compatible only with Windows 2000 servers. This will give you tighter security but will not work with any NT 4.0 RAS servers and can cause problems within NT 4.0 domains. There are no NT 4.0 servers of any kind in the network, nor do you ever plan on having any on the network, so you may choose the second option of Permissions compatible only with Windows 2000 servers and click Next.

12. The next screen will ask you for a directory services restore mode administrator password. This password is used to protect against anyone other than an administrator from rebuilding the Active Directory database from the directory services restore mode. This password is different from any logon password and should be a different from the administrator's logon password in case the administrators' account gets compromised. Type in pass as the password and click Next.


13. The next screen will give you a summary of all the information you entered in the wizard. Review and confirm that everything is correct and click Next to start the Active Directory installation. You may be asked for the i386 folder during the installation of DNS, so you should have the Windows 2000 Server CD-Rom handy. The installation should take about 15-30 minutes.

14. You will eventually get a screen letting you know the installation is done. Click on Finish and you will see a dialog box appear telling you that the server must be restarted
before the changes made by the Active Directory installation wizard take effect. Click Restart Now for the computer to restart.

Configuring DNS to work with Active Directory
1. When the server restarts, log on as administrator and open the DNS management console. Go to Start > Programs > Administrative Tools > DNS. In the left pane open srv-1, then open Forward Lookup Zones folder and find the zone for mycompany.com. Check to make sure there is a host entry for srv-1.

2. Right click on the mycompany.com and select Properties. Here you can see that when DNS is installed automatically through the Active Directory installation wizard, the zone type is set to Active Directory-integrated and dynamic updates are set for Only secure updates by default. Click OK.

3. Now you will need to create a reverse lookup zone for the mycompany.com network. The reverse lookup zone is needed in order to use the NSLOOKUP utility to test that DNS is working properly and troubleshoot any problems that may arise. Right click on the Reverse Lookup Zones folder, select New Zone and the Reverse lookup zone wizard will start.

4. The first screen is the welcome screen, just click on Next. The next screen will ask you to specify the type of zone you want to create. Choose the same type of zone that the forward lookup zone is set to. Select Active Directory integrated, by selecting an Active Directory integrated zone, dynamic updates will automatically be set to allow Only secure updates, click Next. The next screen will ask you to specify the Network ID for the reverse lookup zone. Type in the network ID 192.168.1 and click Next. The last screen will show a summary of all the information you entered on the wizard, confirm that it’s all correct and click Finish to create the reverse lookup zone.

5. On the DNS console, open the Reverse Lookup Zones folder and you should find the zone, 192.168.1.x Subnet. Open the Properties of the zone to confirm that the zone type is set to Active Directory integrated and dynamic updates are set to allow only secure updates. Close the Properties.

6. The next step is to create a pointer record for Server-1, this should be the only pointer record you will have to create manually because any other clients that support dynamic updates will automatically update and create their own host and pointer records. Server-1 did not update or create a pointer record automatically because there was no reverse lookup zone available when the host record was originally created. Right click on 192.168.1.x Subnet and select New Pointer.

7. A dialog box will appear asking you for the Host IP address and Host name of the Pointer record. Type in 201 for the host IP number and Server-1.mycompany.com for the host name then click OK.

8. On the DNS console, you should now have a pointer record for 192.168.1.201. Close the DNS Console.

9. From the desktop, open the command prompt; go to Start > Run, type in CMD and click OK. On the command prompt type in NSLOOKUP and press Enter.

10. The NSLOOKUP utility will look for the DNS server on the network and return the host name and IP address of the server. You should have the default server Server-1.mycompany.com and an IP address of 192.168.1.201 appear. You may now type in any host name and NSLOOKUP will query the preferred DNS server to resolve it to an IP address. Try resolving the host name for Server-1. Type in srv-1 and press Enter. You should get the full DNS name and IP address of the DNS server and underneath it will appear the full DNS name and IP address of the queried host. Type in Exit and press
Enter to exit NSLOOKUP. Then type Exit and press Enter again to close the command prompt.

Free tips on Performance bottlenecks in file servers Acceleration of network file systems

Free tips on Performance bottlenecks in file servers Acceleration of network file systems and Current NAS servers and NAS gateways, as well as classical file servers, provide their storage capacity via conventional network file systems such as NFS and CIFS or Internet protocols such as FTP and HTTP. Although these may be suitable for classical file sharing, such protocols are not powerful enough for I/O-intensive applications such as databases or video processing. Nowadays, therefore, I/O-intensive databases draw their storage from disk subsystems rather than file servers. Let us assume for a moment that a user wishes to read a file on an NFS client, which is stored on a NAS server with internal SCSI disks. The NAS server's operating system first of all loads the file into the main memory from the hard disk via the SCSI bus, the PCI bus and the system bus, only to forward it from there to the network card via the system bus and the PCI bus. The data is thus shovelled through the system bus and the PCI bus on the file server twice (Figure 4.7). If the load on a file server is high enough, its buses can thus become a performance bottleneck. When using classical network file systems the data to be transported is additionally copied from the private storage area of the application into the buffer cache of the kernel on the transmitting computer before this copies the data via the PCI bus into the packet buffer of the network card. Every single copying operation increases the latency of the communication, the load on the CPU due to costly process changes between application processes and kernel processes, and the load on the system bus between CPU and main memory. The file is then transferred from the network card to the NFS client via IP and Gigabit Ethernet. At the current state of technology most Ethernet cards can only handle a small part of the TCP/IP protocol independently, which means that the CPU itself has to handle the rest of the protocol. The communication from the Ethernet card to the CPU is initiated by means of interrupts. Taken together, this can cost a great deal of CPU time (cf. Section 3.5.2, 'TCP/IP and Ethernet as an I/O technology').

Acceleration of network file systems

If we look at the I/O path from the application to the hard disks connected to a NAS server (Figure 4.15 on page 130), there are two places to start from to accelerate file sharing: (1) the underlying communication protocol (TCP/IP); and (2) the network file system (NFS, CIFS) itself. TCP/IP was originally developed to achieve reliable data exchange via unreliable trans- port routes. The TCP/IP protocol stack is correspondingly complex and CPU-intensive. This can be improved first of all by so-called TCP/IP offload engines (TOEs), which in contrast to conventional network cards process a large part of the TCP/IP protocol stack on their own processor and thus significantly reduce the load on the server CPU (Section 3.5.2). It would be even better to get rid of TCP/IP all together. This is where communication techniques such as Virtual Interfaces (VI) and Remote Direct Memory Access (RDMA) come into play (Chapter 3.7). Today there are various approaches for accelerating network file systems with VI and RDMA. The Socket Direct Protocol (SDP) represents an approach which combines the benefits of TOEs and RDMA-enabled transport (Section 3.7). Hence, protocols based on TCP/IP such as NFS and CIFS can – without modification–benefit via SDP from RDMA-enabled transport. Other approaches map existing network file systems directly onto RDMA. For example, a subgroup of the Storage Networking Industry Association (SNIA) is working on the protocol mapping of NFS on RDMA. Likewise, it would also be feasible for Microsoft to develop a CIFS implementation that uses RDMA instead of TCP/IP as the communication protocol. The advantage of this approach is that the network file systems NFS or CIFS that have matured over the years merely have a new communication mechanism put underneath them. This makes it possible to shorten the development and testing cycle so that the qualitative requirements of production environments can be fulfilled comparatively quickly. A greater step is represented by newly developed network file systems, which from the start require a reliable network connection, such as the Direct Access File System (DAFS, Section 4.2.5), the family of the so-called shared disk file systems (Section 4.3) and the virtualization on the file-level (Section 5.5). 4.2.5 Case study: the Direct Access File System (DAFS) The Direct Access File System (DAFS) is a newly developed network file system that is tailored to the use of RDMA. It is based upon NFS version 4, requires VI and can fully utilize its new possibilities. DAFS makes it possible for several DAFS servers together to provide the storage space for a large file system (Figure 4.8). It remains hidden from the application server – as the DAFS client – which of these DAFS servers the actual data is located in (Figure 4.9).

The communication between DAFS client and DAFS server generally takes place by means of RDMA. The use of RDMA means that access to data that lies upon a DAFS server is nearly as quick as access to local data. In addition, typical file system operations such as the address conversion of files to SCSI block addresses, which naturally also require the CPU, are offloaded from the application server to the DAFS server. An important function of file sharing in general is the synchronization of simultaneous accesses to file entries – i.e. metadata such as file names, access rights, etc. – and file contents, in order to protect the consistency of the data and metadata. DAFS makes it possible to cache the locks at the client side so that a subsequent access to the same data requires no interaction with the file server. If a node requires the lock entry of a different node, then this transmits the entry without time-out. DAFS uses lease-based

locking in order to avoid the permanent blocking of a file due to the failure of a client. Furthermore, it possesses recovery mechanisms in case the connection between DAFS client and DAFS server is briefly interrupted or a different server from the cluster has to step in. Similarly, DAFS takes over the authentication of client and server and furthermore can also authenticate individual users in relation to a client-server session. Two approaches prevail in the discussion about the client implementation. It can either be implemented as a shared library (Unix) or DLL (Windows) in the user space or as a kernel module (Figure 4.10). In the user space variant – known as uDAFS – the DAFS library instructs the kernel to set up an exclusive end-to-end connection with the

DAFS server for each system call (or for each API call under Windows) by means of a VI provider layer (VIPL), which is also realized as a library in user space. The VI- capable NIC guarantees the necessary protection against accesses or faults caused by other processes. The user space implementation can utilize the full potential of DAFS to increase the I/O performance because it completely circumvents the kernel. If offers the application explicit control over the access of the NIC to its private storage area. Although control communication takes place between the VI provider layer in the user space and he VI-NIC driver in the kernel, the CPU cost that this entails can be disregarded due to the low data quantities. The disadvantage of the methods is the lack of compatibility with previous applications, which without exception require an upgrade in order to use DAFS. Such a cost is only justified for applications for which a high I/O performance is critical.In the second, kernel-based variant the implementation is in the form of a loadable file system module (fDAFS) underneath the Virtual File System (VFS layer) for Unix or as an Installable File System (IFS) for Windows. Each application can address the file system driver as normal by means of the standard system calls and VFS or API calls and the I/O manager; DAFS then directs a query to the DAFS server. The I/O performance is slowed due to the fact that all file system accesses run via the VFS or the I/O manager because this requires additional process changes between user and kernel processes. On the other hand, there is compatibility with all applications. Some proponents of DAFS claim to have taken measurements in prototypes showing that data access over DAFS is quicker than data access on local hard disks. In our opinion this comparison is dubious. The DAFS server also has to store data to hard disks. We find it barely conceivable that disk access can be quicker on a DAFS server than on a conventional file server. Nevertheless, DAFS-capable NAS servers could potentially support I/O-intensive applications such as databases, batch processes or multi-media applications. Integration with RDMA makes it irrelevant whether the file accesses take place via a network. The separation between databases and DAFS servers even has the advantage that the address conversion of files to SCSI block addresses is offloaded from the database server to the DAFS server, thus reducing the load on the database server's CPU. However, file servers and database servers will profit equally from InfiniBand, VI and RDMA. There is therefore the danger that a DAFS server will only be able to operate very few databases from the point of view of I/O, meaning that numerous DAFS servers may have to be installed. A corresponding number of DAFS-capable NAS servers could be installed comparatively quickly. However, the subsequent administrative effort could be considerably greater. The development of DAFS was primarily advanced by the company Network Appliance, an important NAS manufacturer. The standardization of the DAFS protocol for communication between server and client and the DAFS API for the use of the file system by applications was performed by the DAFS Collaborative . Since the release of Version 1.0 in September 2001 (protocol) and in November 2001(API) the standardization efforts have slowed down. Initially the DAFS standard was submitted to the IETF in September 2001, but it did not get enough support across the storage industry. Instead of this we can observe more activity for an alternative approach,124 FILE SYSTEMS AND NAS the enablement of NFS to run RDMA-native and the adding of DAFS-like local sharing semantics. DAFS is an interesting approach to the use of NAS servers as storage for I/O-intensive applications. Due to a lack of standardization and widespread support across the industry, current DAFS offerings (2003) should be considered as a temporary solution for specific environments until alternatives like NFS over RDMA and CIFS over RDMA emerge. Furthermore, iSCSI is of interest to those who see DAFS as a way of avoiding an investment in Fibre Channel, the more so because iSCSI – just like NFS and CIFS – can benefit

from TCP/IP Offload Engines, the Socket Direct Protocol (SDP) and a direct mapping of iSCSI on RDMA (iSER) (Section 3.7). Shared-disk file systems (Section 4.3) also offer a solution for high-speed file sharing and in addition to that, storage virtualization (Chapter 5) provides high-speed file sharing while it addresses the increasingly expense management of storage and storage networks as well.

Understanding Active Directory Concepts

Understanding Active Directory Concepts:-

In the Windows Server 2003 family and Active Directory, there are several new con­cepts and some changes to the concepts used in Windows NT. These concepts include replication, trust relationships, change and configuration management, group policies, DNS, and object naming. It is important that you understand the meaning of these con­cepts as they apply to Active Directory. In addition, you should also familiarize yourself with the Active Directory administration tasks, which correspond to the chapters in this training kit.After this lesson, you will be able to ■  Explain Active Directory replication ■  Explain the security relationships between domains in a tree (trusts) ■  Explain the components of change and configuration management ■  Explain the purpose and function of Group Policy ■  Describe how DNS is used by Active Directory ■  Describe how objects are named in Active Directory ■  Describe the tasks required for Active Directory administratior

 

Replication Users and services should be able to access directory information at any time from any computer in the domain tree or forest. Replication ensures that changes to a domain controller are reflected in all domain controllers within a domain. Directory informa­ tion is replicated to domain controllers both within and among sites. What Information Is Replicated The information stored in the directory (in the Ntds.dit file) is logically partitioned into four categories. Each of these information categories is referred to as a directory parti­tion. A directory partition is also referred to as a naming context. These directory par­titions are the units of replication. The directory contains the following partitions: Schema partition  This partition defines the objects that can be created in the directory and the attributes those objects can have. This data is common to all domains in a forest and is replicated to all domain controllers in a forest.  Configuration partition  This partition describes the logical structure of the deployment, including data such as domain structure or replication topology. This 1-22  Chapter 1  Introduction to Active Directory data is common to all domains in a forest and is replicated to all domain control­ lers in a forest. Domain partition  This partition describes all of the objects in a domain. This data is domain-specific and is not replicated to any other domains. However, the data is replicated to every domain controller in that domain.  Application Directory partition  This partition stores dynamic application-specific data in Active Directory without significantly affecting network perfor­mance by enabling you to control the scope of replication and the placement of replicas. The application directory partition can contain any type of object except security principals (users, groups, and computers). Data can be explicitly rerouted to administrator-specified domain controllers within a forest in order to prevent unnecessary replication traffic, or it can be set to replicate everything to all domain controllers in the same fashion as the schema, configuration, and domain partitions