Interview Question for active directory and exchange
Interview Question ‘N’ Answer Bank
Q.1 What is the latest Service Pack for Exchange 2000?
Ans : Service Pack 3.
Q.2 What are the versions of ISA servers and their service packs?
Ans : ISA Server 2000 SP1
ISA Server 2004 SP1
Q.3 What are the core services that run a ISA server?
Ans : Microsoft ISA Server Control
Microsoft Web Proxy
Q.4 What is the function of the .edb and .stm files in Exchange 2000?
Ans: .edb files :-
Q.5 What is the core function of the Active directory Connector in Exchange 2000?
Ans: The ADC is the service that lets you perform directory synchronization between the Exchange Server 5.5 DS and AD. The ADC uses connection agreements (CAs) to define individual configurations for replication.
Q.6 What is the SRS service in Exchange 2000?
Ans : The SRS is an Exchange 2000 service that allows integration with Exchange Server 5.5 sites. The SRS runs on an Exchange 2000 server but presents itself as an Exchange Server 5.5 DS to other Exchange Server 5.5 servers. You can use the SRS only if you're running Exchange 2000 in mixed mode.
The SRS in Intrasite Replication :-
Figure 1.
<>
<>
Figure 1 shows an Exchange Server 5.5 site (i.e., a site that contains only Exchange Server 5.5 servers) with a CA homed against one of the servers, S4. The CA to the AD is well defined because it has a valid source of Exchange Server 5.5 directory information. The ADC obtains information from the Exchange Server 5.5 DS on server S4.
But what happens when you upgrade the server S4 from Exchange Server 5.5 to Exchange 2000? Upgrading compromises the integrity of the CA because S4 doesn't have an Exchange Server 5.5 DS (because Exchange 2000 uses AD), and the CA becomes unusable. Your only option is to rehome the Exchange Server 5.5 end of the CA to another server (e.g., server S5). This action would reestablish the integrity of the CA, but you would need to rehome this CA when you subsequently upgrade server S5 to Exchange 2000. This rehoming activity could repeat itself for some time unless you initially homed your CA against a server that you knew would be the last one in the site you migrate to Exchange 2000.
Retaining CA integrity. Let's assume that server S4 is the first Exchange Server 5.5 server in the site you're upgrading to Exchange 2000. This assumption satisfies one of the rules for enabling the SRS: You're upgrading the first server in the site. When you perform the upgrade in this situation, the SRS (which is the Exchange Server 5.5 DS in disguise) becomes active. And because the SRS takes part in Exchange Server 5.5 directory replication just like any other Exchange Server 5.5 service, it has a valid view of the Exchange Server 5.5 directory in its SRS database.
Figure 2.
<>
<>
Figure 2 shows the SRS active on S4.
Because the SRS is active on server S4, you can retain the existing CA that is homed against S4. Because the SRS is there, you have a valid source of Exchange Server 5.5 directory information, so you don't need to manually rehome the CA. Having one server that you know can always provide a source of Exchange Server 5.5 directory information is a big plus.
When you home a CA against a regular Exchange Server 5.5 server, you must bind the Exchange Server 5.5 end of the CA against the Lightweight Directory Access Protocol (LDAP) of the Exchange Server 5.5 DS. The ADC uses LDAP to access the Exchange Server 5.5 DS. By default, the Exchange Server 5.5 LDAP listens on port 389, but you can enable LDAP on another port (e.g., if you're running an Exchange Server 5.5 server on a Windows 2000 domain controller). AD on a Win2K domain controller also listens on port 389, and as Win2K is starting up, it seizes control of port 389 before the Exchange Server 5.5 DS can get to it.
The SRS behaves similarly. The SRS runs only on a Win2K system, and this system might be a domain controller. A CA always wants to connect to a source of Exchange Server 5.5 directory information over LDAP. To avoid confusion, the Exchange engineering team designed the SRS so that it offers its LDAP service from port 379. Therefore, if you had previously homed your CA against an Exchange Server 5.5 DS on port 389, you must modify the CA so that it now points to port 379 to get to the SRS DS. "More Tips for Using the Active Directory Connector," Reader to Reader, April 2000, explains how to change the LDAP port.
This modification requires only that you use the CA management tool to redirect the CA to a different port after the upgrade to Exchange 2000. However, this modification is a small change to an existing CA, compared with rehoming the CA to an altogether different server.
Within an Exchange Server 5.5 site, an Exchange Server 5.5 server communicates with other Exchange Server 5.5 servers to keep the information in its DS consistent with the information in the other Exchange Server 5.5 servers' directories. This behavior is the essence of intrasite replication. The component responsible for controlling this process is the Knowledge Consistency Checker (KCC)—which is on every Exchange Server 5.5 server. The KCC maintains a table of all Exchange Server 5.5 servers that take part in the replication chain.
As you upgrade many Exchange Server 5.5 servers in the site to Exchange 2000, most servers won't have the SRS enabled. In these cases, the upgrade code removes the entry for each respective server from the KCC table. For example, for the systems you see in Figure 2 (presuming that they're not bridgehead servers), the code removes servers S1, S2, S3, and S5 from the Exchange Server 5.5 intrasite replication chain. (More precisely, the code removes the servers' directory service agent—DSA—object from the KCC table.) Removing the servers' DSA ensures that they no longer take part in Exchange Server 5.5 intrasite replication because they're no longer Exchange Server 5.5 servers. If the upgrade process didn't remove these DSA objects from the KCC table, you'd see many errors in the event log, signifying that Exchange Server 5.5 directory replication failed against the newly upgraded servers.
The SRS in Intersite Replication :-
When you upgrade an Exchange Server 5.5 directory replication bridgehead server to Exchange 2000, the bridgehead server must maintain a means for communicating site information to its Exchange Server 5.5 bridgehead replication partner. The SRS provides this means because it appears to the replication partner as an Exchange Server 5.5 DS to communicate with.
Figure 3.
<>
<>
Two Exchange Server 5.5 directory replication bridgehead servers (S9 and S1) communicating across a DRC.
When you upgrade server S1 from Exchange Server 5.5 to Exchange 2000, as Figure 4 shows, the SRS becomes indispensable because once again, it reduces the administrative effort associated with upgrading servers. Because the pure Exchange Server 5.5 site (i.e., Site B) has no CA, all site and topology information for Site B must come from traditional Exchange Server 5.5 directory replication.
In the absence of an SRS service, you need to rehome Exchange Server 5.5 DRCs onto different servers as you upgrade bridgehead servers from Exchange Server 5.5. In this example, upgrading server S1 to Exchange 2000 without an SRS service would require rehoming the DRC to another server in the site (e.g., S2).
Components of the SRS even optimize CAs and DRCs. If a CA becomes available to Site B, Exchange can deliver directory information into that site two ways: across a DRC and through a CA. Exchange Server 5.5 directory replication is object-based, whereas replication through a CA is attribute-based. Therefore, using CAs to provide directory information is more efficient than using DRCs because attribute-based replication involves less data on the wire. If you use a CA, as Figure 5 shows, the SRS disables the DRC between the two Exchange Server 5.5 sites and uses ADC-based replication instead.
You can see that, with respect to intersite replication, the SRS is a useful tool. Without it, the management of DRCs would increase administrative overhead. The SRS proves its worth just for managing CAs within a site, but coupled with managing connections between Exchange Server 5.5 bridgehead servers, it's essential.
Behind a Bridgehead Server Upgrade :-
<>
<>
<>
<>
When you upgrade server S1 to Exchange 2000, the Setup program modifies the existing local dir.edb database (i.e., the traditional Exchange Server 5.5 DS), copies the new executables for the SRS service from the installation CD-ROM, and creates several objects in AD's configuration-naming context. (The configuration-naming context contains all Exchange 2000 configuration information.)
Specifically, an instance of an object of class ms-Exch-Site-Replication-Service within the Exchange tree in the AD configuration-naming context represents the SRS. Figure 6 shows an example of a default SRS object, Microsoft DSA, from ADSI Edit. ADSI Edit, part of the Microsoft Windows 2000 Resource Kit, is a useful tool for looking at objects, attributes, and their values in AD.
In this case (i.e., when S1 is the first Exchange 2000 server in the site), the Setup process also creates a Configuration Connection Agreement (ConfigCA) between AD and the new SRS service installed locally. The SRS takes on the ownership of the DRC to server S9. Because the SRS object in AD has a legacyExchangeDN attribute of /o=
The SRS connects to bridgehead server S9 over a DRC and to AD through a ConfigCA. The ConfigCA is two-way, replicating configuration information for the Exchange Server 5.5 view of Site A from the SRS to AD and back-replicating information for administrative group A (the Exchange 2000 view of the site) from AD to the SRS.
Q.7 Where are the NTFRS transactions stored?
Ans : In the Ntfrs.jdb Jet database and in a set of log files in the default paths %SystemRoot%\Ntfrs\Jet\Log.
Q.8 What are the different MS Exchange server 5.5. files that are installed after running setup?
Ans : 1. Private Information Store ( C:\exchsrvr\MDBDATA)
2. Public Information Store (C:\exchsrvr\MDBDATA)
3. Information Store Logs (C:\exchsrvr\MDBDATA)
4. Directory Service (C:\exchsrvr\DSADATA)
5. Directory Service Logs (C:\exchsrvr\DSADATA)
6. MTA (C:\exchsrvr\MDBDATA)
Q.9 What are the core MS exchange 5.5 services/components?
Ans :- 1. Directory Service (DS)à Microsoft Exchange Directory
2. Microsoft Exchange Event Service
3. Information Store (IS)à Microsoft Exchange Information Store
4. Message Transfer Agent (MTA)àMicrosoft Exchange Message Transfer Agent
5. System Attendant (SA)à Microsoft Exchange System Attendant.
Q.10 What is the latest Service Pack for Windows NT Server 4.0?
Ans : Service pack 6a
Q.11 What is the latest Service Pack for Windows 2000 Server?
Ans : Windows 2000 Service Pack 4
Q.12 What is the IIS version on Win2K servers?
Ans : IIS 5.0 On Windows 2000 Server
IIS 6.0 On Windows 2003 Server
Q.13 What is the TCP/IP port for A Global Catalogue Server (GC)?
Ans : Port 3268
Q.14 Explain the Active Directory Log files?
Ans : The key files are:
- ntds.dit
- edb.log
- res1.log
- res2.log
- edb.chk
When a change is made to the Win2K database, triggering a write operation, Win2K records the transaction in the log file (edb.log). Once written to the log file, the change is then written to the AD database. System performance determines how fast the system writes the data to the AD database from the log file. Any time the system is shut down, all transactions are saved to the database.
During the installation of AD, Windows creates two files: res1.log and res2.log. The initial size of each is 10MB. These files are used to ensure that changes can be written to disk should the system run out of free disk space. The checkpoint file (edb.chk) records transactions committed to the AD database (ntds.dit). During shutdown, a “shutdown” statement is written to the edb.chk file. Then, during a reboot, AD determines that all transactions in the edb.log file have been committed to the AD database. If, for some reason, the edb.chk file doesn’t exist on reboot or the shutdown statement isn’t present, AD will use the edb.log file to update the AD database.
The last file in our list of files to know is the AD database itself, ntds.dit. By default, the file is located in %systemroot%\NTDS, along with the other files we’ve discussed. During the installation of AD (by running DCpromo), you can specify that the log files and database files be installed in different locations, as shown in Figure 1.
| <> |
| Figure 1. The default locations for the Active Directory database and log files. |
<> Q15.
No comments:
Post a Comment