Archive for March, 2010

Problem

You want to reconnect a mailbox in the Exchange Store to a user object.

Solution

Using a graphical user interface
  1. Open the Exchange System Manager (ESM) snap-in.

  2. In the left pane, browse to the mailboxes container of the server, storage group, and database you want to reconnect a mailbox.

  3. In the right pane, scroll down until you find the mailbox that you wish to reconnect. The mailbox should have a small red circle with a white X on it indicating it is disconnected.

  4. Right-click the mailbox and select Reconnect.

  5. Choose a user object in the directory you wish to reconnect this mailbox to.

  6. A dialog box indicating the Reconnect Operation has completed successfully should pop up. Click OK.


Problem

You want to purge a deleted mailbox from the Exchange Store.

Solution

Using a graphical user interface

  1. Open the Exchange System Manager (ESM) snap-in.
  2. In the left pane, browse to the mailboxes container of the server, storage group, and database you want to purge a mailbox from.
  3. In the left pane, scroll down until you find the mailbox that you wish to purge. The mailbox should have a small red circle with a white X in it, indicating that it is disconnected.
  4. Right-click the mailbox and select Purge.
  5. When prompted if you are sure you want to continue click Yes.

Using VBScript

‘ This code purges a deleted mailbox.

‘ —— SCRIPT CONFIGURATION ——

strComputer = “<

Exchange Server>” ‘e.g. ExchServer2

strMailbox = “<Mailbox Alias>”    ‘e.g. jsmith

‘ —— END CONFIGURATION ——–

Set objWMI = GetObject(“winmgmts:\\” & strComputer & _

“\root\MicrosoftExchangeV2”)

set objDiscMbx = objWMI.ExecQuery(“Select * from Exchange_Mailbox WHERE ” _

& “MailboxDisplayName='” & strMailbox & “‘”,,48)

for each objMbx in objDiscMbx

objMbx.Purge

next

Wscript.Echo “Successfully purged mailbox.”

Discussion

A mailbox that has been deleted still has physical presence in the Exchange store. This recipe wipes that mailbox from the store completely. Once a mailbox has been purged, the only way to retrieve it is through restoring from a backup, which could be a lengthy process given the need to recover the entire store. In other words, don’t do this unless you are sure of the consequences.

Purging a mailbox requires Exchange Full Administrator permissions..

Using a Graphical User Interface

You may run into a case where ESM doesn’t show you a mailbox is disconnected when in fact you know it is. This can happen if you delete the mailbox and immediately look at it in ESM. To clear that condition, you will need to right-click on the mailboxes container and select Run Cleanup Agent. This will cause some house cleaning to be done; the mailbox should then show up as disconnected.

Using VBScript

The Purge method is part of the Exchange_Mailbox class, which is new for Exchange 2003. In Exchange 2000, there was no method available to purge a mailbox via a script.

Be extremely careful with this script because it could easily remove all disconnected mailboxes on a given Exchange server. If the WHERE clause is removed in the SELECT statement of the WMI query, the purge loop below that would then clear every mailbox that was disconnected, so be careful.


Problem

You want to mail-disable a user.

Solution

Using a graphical user interface

  1. Open the Active Directory Users and Computers (ADUC) snap-in.
  2. If you need to change domains, right-click on Active Directory Users and Computers in the left pane, select Connect to Domain, enter the domain name, and click OK.
  3. In the left pane, browse to the parent container of the user, right-click on the user, and select Exchange Tasks.
  4. On the Welcome screen, click Next.
  5. Select Remove Exchange Attributes and click Next.
  6. Read the warning and click Next.
  7. On the Completion screen, click Finish.

Using a command-line interface

> exchmbx -b “<User DN>” -clear

Replace <User DN> with the user’s distinguished name.

For an alternative Microsoft-native tool method, create an LDIF file called clearmailattribs.ldf with the following contents:

dn: <UserDN>

changetype: modify

replace: altRecipient

altRecipient:

replace: authOrig

authOrig:

<SEE DISCUSSION, NOT A COMPLETE LDIF FILE>

Replace <UserDN> with the user’s distinguished name. Note that this is not a complete LDIF file as there are many attributes that must be cleared; see the “Discussion” section for further details. Once you’ve created the LDIF file, run the following command:

> ldifde -i -f clearmailattribs.ldf


Problem

You want to mail-enable a user.

Solution

Using a graphical user interface

  1. Open the Users and Computers (ADUC) snap-in.
  1. If you need to change domains, right-click on Active Directory Users and Computers in the left pane, select Connect to Domain, enter the domain name, and click OK.
  2. In the left pane, browse to the parent container of the user, right-click on the user, and select Exchange Tasks.
  3. On the Welcome screen, click Next.
  4. Select Establish E-mail Address and click Next.
  5. Verify the mail alias is what you want.
  6. Click Modify, select external email address type (generally SMTP Address), click OK, enter an external email address, and click OK.
There is an Advanced tab on the Internet Address Properties screen. On this tab, you have the option to override the default handling of email sent to this recipient (e.g., you can force all email to be delivered as HTML or plain text, etc.).
  1. On the Completion screen, click Finish.

Using a command-line interface

> exchmbx -b “<User DN>” -me <smtp email address>

Replace <User DN> with the user’s distinguished name and <smtp email address> with the user’s external email address.

To mail enable the user john with the email address john@indmail.bang.com, execute the following command. The command should be contained on one line:

> exchmbx -b “cn=john,cn=users,dc=bang,dc=com” -me john@indmail.bang.com

For an alternative Microsoft-native tool method, create an LDIF file called mailenable_user.ldf with the following contents:

dn: <User DN>

changetype: modify

replace: targetAddress

targetaddress: SMTP:<smtp email address>

replace: mailNickName

mailNickname: <mail nickname>

replace: mAPIRecipient

mAPIRecipient: FALSE

replace: legacyExchangeDN

legacyExchangeDN: <legacy exchange DN>

replace: internetEncoding

internetEncoding: 1310720

Replace <User DN> with the user’s distinguished name, <smtp email address> with the user’s external email address, and <legacy exchange DN> with the proper legacy exchange distinguished name value. Then run the following command:

>ldifde -i -f mailenable_user.ldf

Discussion

A mail-enabled user is a user object that has at least one email address defined within Exchange, but does not have a mailbox. This does not give any access rights to the user within the Exchange system; it simply allows Exchange users to select the mailenabled user from the GAL and easily send email to them. You would use a mailenabled user when you have a user who needs to log in to the domain, but has an email address external to the forest’s Exchange organization. The email address could be external to the company or it could just be external to the Exchange organization of that forest. Examples would be users with mailboxes on external email systems or users with mailboxes on internal non- Exchange servers.

To mail-enable a user, you need to have permissions of Exchange View-Only Administrator or higher for the target administrative group. In addition, you need to have Read and Write permissions to the following object attributes:

  • adminDisplayName
  • autoReplyMessage (ILS Settings)
  • displayName (Display Name)
  • dLMemDefault
  • homeMDB (Exchange Mailbox Store)
  • homeMTA
  • internetEncoding
  • legacyExchangeDN
  • mail (E-Mail Address)
  • mailNickname (Alias)
  • mAPIRecipient
  • msExchADCGlobalNames
  • msExchControllingZone
  • msExchFBURL
  • msExchHideFromAddressLists
  • msExchHomeServerName (Exchange Home Server)
  • msExchMailboxGuid
  • msExchMailboxSecurityDescriptor
  • msExchPoliciesExcluded
  • msExchPoliciesIncluded
  • msExchResourceGUID
  • proxyAddresses (Proxy Addresses)
  • showInAddressBook
  • targetAddress
  • textEncodedORAddress

When you create a mail-enabled user with ADUC or with VBScript, you call out to the CDOEXM interface, which is the Microsoft-supported method of managing Exchange attributes on users, groups, and contacts. The specific method in this case is MailEnable. In the background, the specific changes made by the MailEnable method are on the user object in Active Directory and include changes to the following attributes:

  • targetAddress
  • mailNickname
  • mAPIRecipient
  • legacyExchangeDN

In addition to those attributes, the internetEncoding attribute should also be set for proper message handling. This is the attribute that is updated if you go into the Advanced tab of the Internet Address Properties screen. The default value for this attribute is 1310720, which tells Exchange to use the default settings of the Internet Mail Service. You can specify other values to force email to be converted to various formats. Table contains the list of alternate values for the internetEncoding attribute.

Table. internetEncoding attribute values
Value Meaning
1310720 Use Internet Mail Service settings
917504 Allow plain text
1441792 Allow plain text or HTML
2228224 Allow plain text/uuencoding
131072 Allow plain text/uuencoding with BinHex

Once all of those attributes are in place, the RUS sets additional attributes on the user object to make it useable for Exchange.

Using a graphical user interface

Mail-enabling a user is a little more confusing if you are creating new users because you don’t get prompted to mail-enable them. To create a mail-enabled user from scratch, create the user and, when prompted to create a mailbox, clear the Create an Exchange Mailbox checkbox. Once the user is created, follow the directions described in the solution.

Using a command-line interface

Command-line administration tools for Exchange are rather rare. Luckily, the Exch-Mbx tool is available as a free download from http://www.joeware.net. This tool can turn a difficult process into something quite simple. If you need to modify the internetEncoding attribute, add the internetencoding option to the parameter list specifying the proper value from above table, For example:

>

exchmbx -b <UserDN> -me <SmtpEmailAddress> -internetencoding 917504

If you prefer Microsoft-native solutions, the LDIF solution we described will work, but can be dangerous because there is the possibility of duplicating critical values within the Exchange organization. If you put duplicate mailNickname or legacyExchangeDN values into the system, you will have bad results in your Exchange organization that will almost certainly start producing nondelivery reports (NDR) for the mail objects involved.

The mailNickname attribute can generally be set to be the same as the sAMAccountName, which has to be unique in the domain. But what should you do you with legacyExchangeDN? If you aren’t tied to a legacy 5.5 organization, you can follow the simple format the system currently uses. If you have a legacy 5.5 organization, you need to follow the structure for that organization. For assistance with this, contact Microsoft PSS or Microsoft Consulting Services.

The general format of legacyExchangeDN is:

/o=<Org>/ou=<AdministrativeGroup>/cn=<RecipientContainer>/cn=<mailnickname>

You should always verify by searching Active Directory that the legacyExchangeDN you chose is not already used. The reason for this is that someone may have changed an existing user’s mailNickname but, correctly, did not touch the legacyExchangeDN value. You could, of course, fix the legacyExchangeDN of that other user so that it properly fits the pattern, but you would impact the user’s email functionality.

The attribute legacyExchangeDN is used in Exchange internally for addressing email. If you try to respond to an email sent to you by a user within the same Exchange organization who has had her legacyExchangeDN changed, you will get an NDR and the mail will not be delivered. So, if a user has a name change from Chris Smith to Chris Jones and her sAMAccountName and mailNickname both change from csmith to cjones, her legacyExchangeDN must remain the same so that anyone within the Exchange organization will be able to easily respond to emails she sent as csmith. The point is that you should always check that the legacyExchangeDN value you are setting is unique. The simple solution to follow if the value is already present is to append a -1, -2, or whatever dash value is required to get to a unique value.

You have the option of not specifying the legacyExchangeDN in the LDIF file. If the attribute is empty, Exchange will populate it for you. If there is already a value, Exchange will not change the attribute.

Unfortunately, if you are mail enabling an object that was previously mail- or mailbox enabled, it could have an existing value for legacyExchangeDN; this value may or may not be unique. One very specific case is that some tools will set the legacyExchangeDN value to ADCDisabled when an object is mail or mailbox disabled to alert the ADC to the object’s status.

Problem

You want to stop or start Exchange Server.

Solution

Stopping and starting Exchange consists of stopping and starting the Exchangerelated services through the Services MMC snap-in or the net stop/net start com-mand-line utilities. See the “Discussion” of this recipe for the list of Exchange services.

Using a graphical user interface
  1. Open the Computer Management MMC snap-in (compmgmt.msc).

  2. Scroll to the service that you wish to manage, and click Stop, Start, or Restart.

Using a command-line interface

The following command will stop a service:

	> net stop <ServiceName>

The following command will start a service:

	> net start <ServiceName>

The following will stop and start a service in a single command:

	> net stop <ServiceName> && net start <ServiceName>

Using VBScript
	'-------------SCRIPT CONFIGURATION----------------------
	strComputer = "<ComputerName>"
	strServiceName = "<ServiceName>"

	Set objWMIService = GetObject("winmgmts:" _
	    & "{impersonationLevel=impersonate}!\\" & strComputer _
	    & "\root\cimv2")

	Set colServiceList = objWMIService.ExecQuery _
	    ("Select * from Win32_Service where Name='" & strServiceName _
	_ '")

	' The following code will start a service

	For Each objService in colServiceList
	    errReturn = objService.StartService()
	Next

	' The following code will stop a service

	For Each objService in colServiceList
	    errReturn = objService.StopService()
	Next

Discussion

There are several services involved with Exchange Server, and stopping different services will accomplish different things. The services are interdependent, so when you stop or start various services you may see a message about having to stop dependent services. If you do stop dependent services, don’t forget to restart them again when you restart the service that you began with.

To shut down Exchange completely on a given machine, you need to stop all of the following services:

Microsoft Exchange Event (MSExchangeES)

This service was used for launching event-based scripts in Exchange 5.5 when folder changes were detected. Exchange 2000 offered the ability to create Event Sinks directly, so this use of this service has decreased. This service is not started by default.

Microsoft Exchange IMAP4 (IMAP4Svc)

This service supplies IMAP4 protocol message server functionality. This service is disabled by default. To use IMAP4 you must enable this service, configure it to auto-start, and start the service.

Microsoft Exchange Information Store (MSExchangeIS)

This service is used to access the Exchange mail and public folder stores. If this service is not running, users will not be able to use Exchange. This service is started by default.

Microsoft Exchange Management (MSExchangeMGMT)

This service is responsible for various management functions available through WMI, such as message tracking. This service is started by default.

Microsoft Exchange MTA Stacks (MSExchangeMTA)

This service is used to transfer X.400 messages sent to and from foreign systems, including Exchange 5.5 Servers. This service was extremely important in Exchange 5.5, which used X.400 as the default message transfer protocol. Before stopping or disabling this service, review MS KB 810489. This service is started by default.

Microsoft Exchange POP3 (POP3Svc)

This service supplies POP3 protocol message server functionality. This service is disabled by default. To use POP3 you must enable this service, configure it to auto-start, and start the service.

Microsoft Exchange Routing Engine (RESvc)

This service is used for routing and topology information for routing SMTP based messages. This service is started by default.

Microsoft Exchange System Attendant (MSExchangeSA)

This service handles various cleanup and monitoring functions. One of the most important functions of the System Attendant is the Recipient Update Service (RUS), which is responsible for mapping attributes in Active Directory to the Exchange subsystem and enforcing recipient policies. When you create a mailbox for a user, you simply set some attributes on a user object. The RUS takes that information and does all of the work in the background with Exchange to really make the mailbox. If you mailbox-enable or mail-enable objects and they don’t seem to work, the RUS is one of the first places you will look for an issue. If you need to enable diagnostics for the RUS, the parameters are maintained in a separate service registry entry called MSExchangeAL. This isn’t a real service; it is simply the supplied location to modify RUS functionality. This service is started by default.

Microsoft Exchange Site Replication Service (MSExchangeSRS)

This service is used in Organizations that have Exchange 5.5 combined with Exchange 2000/2003. This service is not started by default.

Network News Transfer Protocol (NntpSvc)

This service is responsible for supplying NNTP Protocol Server functionality. This service is started by default.

Simple Mail Transfer Protocol (SMTPSVC)

This service is responsible for supplying SMTP Protocol Server functionality. This service is started by default.

Problem

You want to install Exchange Management tools onto a workstation or server that isn’t running Exchange.

Solution

Using a graphical user interface
  1. Install and configure prerequisite services. See the “Discussion” section for the list of these services.

  2. Go to the Windows Update site and install any critical security patches.

  3. Load the Exchange Server CD into your CD-ROM.

  4. On the Start menu, click Run and then type <driveletter>:\setup\i386\setup.exe and click OK. <driveletter> is the drive letter of your CD-ROM drive. This path may vary for certain versions of Exchange Server such as MSDN or Select versions.

  5. On the Welcome screen, click Next.

  6. On the License Agreement screen read through the agreement and if you agree, select “I agree” and click Next.

  7. If the Product Identification screen is presented, enter your Exchange Server product key and click Next.

    This screen may not appear for certain versions of Exchange Server such as the MSDN or Select versions.
  8. On the Component Selection screen, select Custom in the top row of the Action column. Next to Microsoft Exchange System Management Tools, select Install. Verify that the install path is correct for your installation and click Next.

  9. Review the Installation Summary screen and click Next.

  10. On the Completing the Microsoft Exchange Wizard screen, click Finish.

  11. Download and install latest Exchange 2003 service pack. As of the time of this writing it is Service Pack 2. See Recipe 22.4 for more information.

Using a command-line interface

Any Exchange Management Tool installations can be handled through the command line with the unattended installation process. You will need to generate and use the appropriate unattended install INI file. See Recipe 22.5 for more on creating an INI file.

Once you have an unattended file, use the following command to install:

	> <driveletter>:\setup\i386\setup.exe /unattendfile <unattendfile>

Note that if there is an error during the install process it will be recorded in the Exchange Server setup log, which by default will be located in the root of the system drive, generally C:\.

Discussion

Exchange Server has several software prerequisites for the Exchange Management Tools software, without which they will refuse to install. You must have the Windows Server 2003 Administration Tools Pack (adminpak.msi) installed on Windows XP SP1+, Windows 2000 SP3+, or Windows Server 2003 along with the following services:

  • IIS
  • WWW Service
  • SMTP Service

See the Windows Server Cookbook for Windows Server 2003 and Windows 2000 by Robbie Allen (O’Reilly) for more details on installation of these prerequisites.

Microsoft has a recommendation against installing Exchange tools on a machine that runs Outlook. We haven’t had an issue with loading the Exchange tools on a workstation that had Outlook, but it is a point that we must mention. See MS KB 266418 for more details.

You may or may not run into issues loading the Exchange management tools on a client computer that is running the Outlook email client, However, it is absolutely essential that you do not install Microsoft Outlook on the Exchange server itself.

Using a command-line interface

If you have only one or two machines you want to install the tools on, automating the Exchange Server Management Tools installation will probably not be any value to you. However, if you have several machines you need to load the tools on, using the unattended installation feature can certainly lead to time savings, efficiency, and consistency.


Problem

You want to install the first Exchange Server of an Exchange organization.

Solution

Using a graphical user interface

  1. Install and configure prerequisite services. See the “Discussion” section for more on these services.
  2. Log on to a server that is a member of an Exchange-enabled domain with an account that is a member of the delegated group. This account should also be a local administrator of the server.
  3. Go to the Windows Update site and install any critical security patches, or use your organization’s existing patch management solution such as WSUS. Click on Start All Programs Windows Update.
  4. Insert the Exchange Server CD into CD-ROM.
  5. On the Start menu, click Run, type <driveletter>:\setup\i386\setup.exe, and click OK. <driveletter> is the drive letter of your CD-ROM drive. The path to setup.exe may vary for certain versions of Exchange Server such as MSDN or Select versions.
  6. On the Welcome screen, click Next.
  7. On the License Agreement screen, read through the agreement and if you agree, click “I agree” and click Next.
  8. If presented, on the Product Identification screen, enter your Exchange Server product key and click Next.
This screen may not appear for certain versions of Exchange Server, such as the MSDN or Select versions.
  1. On the Component Selection screen in the Action column, verify that the action selected is Typical. Verify the install path is correct for your installation and click Next. It is a common practice to load Exchange onto a drive other than the system drive.
  2. On the Installation Type screen, verify Create a new Exchange Organization is selected, and click Next.
  3. On the Organization Name screen, enter the name you want for your Exchange organization, and click Next. You can leave the default name of ” First Organization” or name it something specific to your installation (e.g., “RALLENCORP-MAIL”).
  4. On the License Agreement screen, select “I agree” and then click Next.
  5. Review the Installation Summary screen and click Next.
  6. On the Completing the Microsoft Exchange Wizard screen, click Finish.
  7. Stop and disable the NNTP service unless you specifically wish to use newsfeeds within your Messaging environment.
  8. Download and install the latest Exchange 2003 service pack. (As of the time of this writing it is Service Pack 2.)
  9. Download and run the Exchange Best Practices Analyzer to determine its compliance with security and performance best practices.

Using a command-line interface

You cannot install the first Exchange Server of the Organization via the command line. However, you can install subsequent Exchange servers using an unattended installation.

Discussion

The first Exchange server you install is special. This is because in addition to installing the Exchange Server software on the server, the process is also creating Active Directory objects in the Configuration container for the Exchange organization. As such, the install is slightly different from any other Exchange Server installation you will do in the forest . The difference is in Steps 10 and 11, which will not be present for any other Exchange Server Installations within the Exchange organization. In these steps you will choose whether you want to create a new Exchange organization or join an existing Exchange 5.5 organization. The additional considerable amount of work involved in joining an existing Exchange 5.5 organization is outside the scope of this chapter.


Problem

You want to prepare your Active Directory forest and domains for installation of your first Exchange Server.

Solution

Using a graphical user interface

The first phase of the installation is ForestPrep and it needs to be run once on the Schema FSMO domain controller.

  1. Log on to the Schema FSMO forest root domain controller with an account that has both Enterprise Admin and Schema Admin rights.
  2. Prepare the domain controller for a schema update.
  3. Per your corporate standards, create either a global or universal group for the initial Exchange administration delegation. Name the group in a descriptive way like ExchangeRootAdmins.
  4. Insert the Exchange Server CD into the CD-ROM.
  5. On the Start menu, click Run, and type:

6.    <driveletter>:\setup\i386\setup.exe /forestprep

where <driveletter> is the drive letter of your CD-ROM drive. This path may vary for certain versions of Exchange Server such as MSDN or Select versions.

  1. On the Welcome screen, click Next.
  2. On the License Agreement screen, read through the agreement and if you agree, click “I agree” and click Next.
  3. If the Product Identification screen is presented, enter your Exchange Server product key and click Next.
This screen may not appear for certain versions of Exchange Server, such as the MSDN or Select versions.
  1. On the Component Selection screen, verify that the action specified is Forest-Prep, and click Next.
  2. On the Server Administrator Account screen, enter the group created in Step 3 and click Next.
  3. On the Completing the Microsoft Exchange Wizard screen, click Finish.

The second phase is DomainPrep and it needs to be run once for the forest root domain and once for every domain in the forest that will contain mail-enabled objects. Preferably you will run this process on every domain in the forest. You will want to wait for the schema updates from the ForestPrep to replicate prior to starting DomainPrep.

  1. Log on to a machine that is part of the domain with an account that is a member of the Domain Admins group.
  2. Insert the Exchange Server CD into CD-ROM.
  3. On the Start menu, click Run, and then type:

4.    <driveletter>:\setup\i386\setup.exe /domainprep

where <driveletter> is the drive letter of your CD-ROM drive. This path may vary for certain versions of Exchange Server such as MSDN or Select versions.

  1. On the Welcome screen, click Next.
  2. On the License Agreement screen, read through the agreement and if you agree, click “I agree” and click Next.
  3. If presented, on the Product Identification screen, enter your Exchange Server product key and click Next.
This screen may not appear for certain versions of Exchange Server, such as the MSDN or Select versions.
  1. On the Component Selection screen, verify that the action specified is Domain-Prep and click Next.
  2. Depending on how your domain is configured for Pre-Windows 2000 Compatible Access, you may get a pop-up with a message saying “The domain “<domainname>” has been identified as an insecure domain for mail-enabled groups with hidden DL membership. …” If you get this pop-up, click OK.
  3. On the Completing the Microsoft Exchange Wizard screen, click Finish.

Using a command-line interface

You cannot run ForestPrep from the command-line. You can, however, run an unattended DomainPrep. You will need to create an unattended installation configuration file, which is described in “Creating Unattended Installation Files for Exchange and Exchange Service Pack Installations.” For further details on this process, see the Exchange Server 2003 Deployment Guide.

You can load the Exchange schema extensions to your forest before running ForestPrep, allowing you to import the Exchange-specific schema modifications months in advance without needing to specify an organization name as you had to do in Exchange 2000.

Discussion

Microsoft Exchange will not run in an Active Directory forest unless the forest and the domains have been properly prepared. Microsoft did not make the assumption that everyone would use Exchange and therefore did not include all of the Exchange attributes and classes in the base Active Directory schema. The ability to dynamically extend the schema for Active Directory makes it possible for only those people running Exchange to install the Exchange infrastructure.

In addition to schema changes, you have to make security changes to Active Directory and the domain policy, as well as create some basic Exchange infrastructure objects. All of this is completed in the Exchange ForestPrep and DomainPrep processes. Do not confuse these with the Windows 2003 ForestPrep and DomainPrep processes (using the adprep command); the concept is the same but the specific changes are different.

You need to run the ForestPrep process once per forest to make the schema changes, create the Exchange organization structure in the Configuration container, and set up Exchange-specific permissions. The ForestPrep process is also responsible for the initial delegation of Exchange rights to a specific user or group for administrative control. We recommend that you create a security group in your root domain for this delegation. You could use a domain local group in a single domain forest in which you will never create another domain. In a multidomain forest, you must use a global group or a universal group. The group is used to assign rights to objects in the Configuration container. Whether you use a global or universal group is up to youeither will do the job. The ForestPrep process requires the person running the process to be part of both the Enterprise Admins and Schema Admins groups.

You need to run the DomainPrep process in the root domain of the forest and for every domain that will contain mail-enabled objects. Normally, DomainPrep is run on every domain in an Active Directory forest. The process creates Exchange security principals, modifies the domain security policy, creates some Exchange specific infrastructure objects, and assigns permissions to the domain’s Active Directory partition. The DomainPrep process requires the person running the process to be a member of the Domain Admins group of the domain being prepared.

Depending on whether your domain has Pre-Windows 2000 Compatible Access enabled, you may get a scary looking message during the DomainPrep process that tells you your domain is insecure for mail-enabled groups with hidden distribution list membership. Instead of making quick changes to your domain that could break other applications, investigate whether you need that compatibility access. If you do not need the access, by all means lock down the Pre-Windows 2000 Compatible Access group as specified.

Just like any application, there are requirements for the installation of Exchange Server 2003. The requirements are split into forest requirements and machine requirements.

For ForestPrep and DomainPrep, there are no machine requirements. However, the requirements for the forest are:

  • Domain controllers must be running Windows 2000 Server Service Pack 3 or Windows Server 2003.
  • Global catalog servers must be running Windows 2000 Server Service Pack 3 or Windows Server 2003. You should have at least one global catalog server per site that you intend to install Exchange into.
  • DNS and NetBIOS name resolution (typically using WINS) must be properly configured.

Due to the depth of changes made to the overall structure of Active Directory, the ForestPrep process requires Schema Admin and Enterprise Admin rights and the DomainPrep requires Domain Admin rights. This prevents anyone but the centralized administration group responsible for the overall Active Directory forest from initially installing Exchange into the forest.

For a more in-depth discussion of the Exchange Server 2003 deployment requirements, considerations, and the specifics of what the preparation processes do, please see the Exchange Server 2003 Deployment Guide. This is a free download from Microsoft and can be obtained by going to http://www.microsoft.com/exchange/library. You should also review the Exchange Server 2003 Deployment Tools and the Exchange Best Practices Analyzer, available from the same site.

Managing Exchange is a little different from managing most other Microsoft applications. The computer where you run the tools or scripts must be a member of a domain in the forest where the Exchange organization resides. This is true whether you are using a script or the GUI. Exchange doesn’t allow you to select other organizations to manage. This can be troublesome for someone managing multiple Exchange organizations or a mobile worker who moves between sites or companies and likes to run her workstation in workgroup mode instead of being a member of any specific domain.

Permissions are very important and often misunderstood in Exchange. Permissions can be set up very simply or in a very complicated way; it is tough to find a middle ground. The simplest method is to give your Exchange administrators Domain Admin access. This is pretty standard in small companies where the Exchange admins are doing all aspects of administration. But this practice is usually unacceptable in larger companies where separation of duties and more security is required.

Exchange Server has several software prerequisites that must be installed prior to its installation. You must have these prerequisites in place prior to installing Exchange or Exchange will refuse to install. The prerequisites vary by operating system.

Windows 2000 SP3+ prerequisites:

  • Windows Server 2003 Administration Tools Pack (adminpak.msi)
  • Internet Information Services (IIS)
  • World Wide Web (WWW) Publishing Service
  • Simple Mail Transport Protocol (SMTP) Service
  • Network News Transfer Protocol (NNTP) Service

Window Server 2003 requires the Windows 2000 prerequisites plus:

  • .NET Framework
  • ASP.NET

Problem

You want to restrict who can administer your DHCP servers in your domain.

Solution

Using a graphical user interface
  1. Open the Active Directory Users and Computers MMC snap-in.

  2. In the console tree, click Active Directory Users and Computers Domain-Name Users.

  3. In the details pane, click DHCP Administrators.

  4. Click Action Properties Members.

  5. Remove all users and groups you do not want to have administering your DHCP server by clicking their names and then clicking Remove.

  6. To add new DHCP administrators, click Add, provide the user or group name, and then click OK.

  7. Click OK.

Using a command-line interface

Add a member to a group with DSMod by passing the -addmbr option:

	> dsmod group "<GroupDN>" -addmbr "<MemberDN>"

To add a group member with AdMod, use the following syntax:

	> admod -b "<GroupDN>" member:+:"<MemberDN>"

Remove a member from a group with DSMod by passing the -rmmbr option:

	> dsmod group "<GroupDN>" -rmmbr "<MemberDN>"

To remove a group member with AdMod, use the following syntax:

	> admod -b "<GroupDN>" member:-:"<MemberDN>"

Replace the complete membership list with DSMod by passing the -chmbr option:

	> dsmod group "<GroupDN>" -chmbr "<Member1DN Member2DN … >"

To replace the membership of a group with AdMod, use the following two commands:

	> admod b "<GroupDN>" :-
	> admod -b "<GroupDN>" member++::"<Member1DN>;<Member2DN>;<Member3DN>"

Using VBScript
	' This code adds a member to the  
DHCP  
Administrators group.
	' ------ SCRIPT CONFIGURATION ------
	strGroupDN = "<GroupDN>" ' e.g. "cn= 
DHCP Administrators,cn=Users,<DomainDN>
	strMemberDN = "<MemberDN>" ' e.g. cn=jsmith,cn=users,dc=rallencorp,dc=com
	' ------ END CONFIGURATION --------

	set objGroup = GetObject("LDAP://" & strGroupDN)
	' Add a member
	objGroup.Add("LDAP://" & strMemberDN)

	' This code removes a member from the  
DHCP Administrators group.

	set objGroup = GetObject("LDAP://" & strGroupDN)
	objGroup.Remove("LDAP://" & strMemberDN)

Discussion

Windows Server 2003 is better than its predecessors about supporting role separation. Most roles can be assigned independently of one another rather than just making a user a Domain Admin or an Enterprise Admin. This is great for security administrators who want to ensure that users have only enough rights to perform their assigned tasks. For example, a user Fred might need to modify an enterprise-wide object. You could just add Fred to the Enterprise Admin groups to solve the problem. However, Fred now has access to virtually any object in the entire forest and could cause irreparable harm to your network, not to mention compromise all security in place. Instead, you can grant Fred access to just that object.

This can be done in separate ways. One method is the “Delegation of Control” wizard. Another way is that Windows has several built-in groups that are created and populated when specific services are installed. One such group is DHCP Administrators, which is created when the first DHCP server is brought up in a domain. You can control administrative access to the DHCP function of these servers through this group membership.