Posts Tagged ‘Exchange Server’


The Active Directory Lightweight Directory Services (AD LDS), previously known as Active

Directory Application Mode or ADAM, can be installed using the Windows Server 2008

Server Manager. To install the AD LDS follow these steps:

1. Logon to the server, click the Start button and select the Server Manager.

2. In the Server Manger, click “Roles” and in the action click “Add Roles”.

3. Click Next on the “before you begin” page.

4. On the “select server role” page, select the “Active Directory Lightweight Directory

Services” and click Next.

5. On the Introduction page, click Next.

6. On the Confirmation page, click Install.

7. On the Installation Results page, click Finish.

The Active Directory Lightweight Directory Services role is now installed and the server is

ready for the Edge Server Role.


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

Using GUI

  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

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

Summary

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.

• Exchange Server 2010 only runs on Windows Server 2008 and Windows Server 2008
R2. Since Windows Server 2008 also needs some additional software to be installed, and
bearing in mind the improvements in Windows Server 2008 R2, the latter is the better
option.
• Any Active Directory domain containing Exchange objects has to be running in (at the
very least) Windows 2003 domain functional level.
• The Active Directory forest also has to be running in at least Windows 2003 forest
functional level.
• The Schema Master and the Global Catalog Server(s) have to have a minimum level of
Windows Server 2003 R2.
• Exchange Server 2010 cannot be installed in an organization where an Exchange Server
2000 exists.

During setup Exchange features are easily configured through the use of the Configure Email and Internet Connection Wizard. The wizard configures the following settings by default.

  • Deleted Items RetentionSet to 30 days. Changes can be made as well by running the Backup Configuration Wizard. Here you can change the value or turn the value on or off.
  • Circular LoggingEnabled to save drive space. It is recommended that you use this configuration only if a backup solution has not been selected. Circular logging is disabled after the Backup Configuration Wizard has been run.
  • Idle User SessionsThe timeout interval is set to 10 minutes.
  • SMTP ConnectorThe connector is created and configured with any send/receive options you select for Internet email.
  • Default Recipient PolicyThe default policy is created and set to your domain name. It also applies the policy to all for SMTP email addresses.
  • The Microsoft Connector for POP3 MailboxesThe connector is installed. Through the CEICW or the POP3 Connector manager you can define POP3 mailboxes that are to be downloaded to Exchange mailboxes.
  • Maximum Number of Concurrent ConnectionsFor Message Delivery the maximum number of concurrent connections is set to 500.
  • Outbound ConnectionsLimited to 10.
  • Email Attachment TypesAttachment filtering can be utilized.
  • Mail ClientsClients assigned an address within the specified local IP range are allowed to relay mail through the SMTP virtual server.

In addition to these settings, you should also be aware of the mailbox management process in Exchange and what it does for your mail server. By default, the mailbox management process is set to Never Run. However, the mailbox management process can perform some important tasks and should be enabled on the SBS server.

One of the most important tasks handled by the mailbox management process is the online defrag of the mail databases. Through the course of normal operation, mail data is added and removed from the mail database, and over time a large amount of unused space becomes scattered across the database. The online defrag process rearranges the storage within the database so that all the empty database records are moved to the end of the database file. You can also start the mailbox management process manually by right-clicking on the server object in Exchange System Manager and selecting Start Mailbox Management Process.

The Server Core installation lets you install a minimal OS for running just the chosen server

roles that would not even need a GUI. This means that you don’t have the huge ‘‘attack’’ surface

that will ensue from all the service requirements. One more thing: Once you install just Server

Core you can stand your server up in a secure environment, both physical and online, and

worry only about securing the services you are actually running. Once Server Core has been

installed you can then open Server Manager (remotely or via scripting) and install, among many

others, the following server roles:

■ Active Directory Domain Services (AD DS)

■ Application Server

■ DHCP Server

■ DNS Server

■ File Services

■ Print Services

Here are some more benefits of the Server Core installation alternative:

■ Lower maintenance. You only need to maintain on the server what is actually installed

on the server. Why worry about maintaining File Services on a server that is nothing more

than a simple domain controller?

■ You need less disk space. The Server Core requires only about 1 gigabyte (GB) of disk

space to install and approximately 2GB for operations after the installation.

■ Less management. Management costs in realms like security, availability, and service

level are far less than previous installation scenarios. You would not have to worry about

supporting a bunch of services and code that you are not using.


Group policies simplify administration by giving administrators central control over privileges, permissions, and capabilities of both users and computers. Through group policies you can

  • Create centrally managed directories for special folders, such as My Documents. This is covered in the section of this chapter entitled “Centrally Managing Special Folders.”
  • Control access to Windows components, system resources, network resources, Control Panel utilities, the desktop, and the Start menu. This is covered in the section of this chapter entitled “Using Administrative Templates to Set Policies.”
  • Define user and computer scripts to run at specified times. This is covered in the section of this chapter entitled “User and Computer Script Management.”
  • Configure policies for account lockout and passwords, auditing, user rights assignment, and security. This is covered in Part II of this book, “Microsoft Windows Server 2003 Directory Service Administration.”

Understanding Group Policies

You can think of a group policy as a set of rules that helps you manage users and computers. You can apply group policies to multiple domains, to individual domains, to subgroups within a domain, or to individual systems. Policies that apply to individual systems are referred to as local group policies and are stored on the local system only. Other group policies are linked as objects in the Active Directory directory service.

To understand group policies, you need to know a bit about the structure of Active Directory. In Active Directory, logical groupings of domains are called sites and subgroups within a domain are called organizational units. Thus, your network could have sites called NewYorkMain, CaliforniaMain, and WashingtonMain. Within the WashingtonMain site, you could have domains called SeattleEast, SeattleWest, SeattleNorth, and SeattleSouth. Within the SeattleEast domain, you could have organizational units called Information Services (IS), Engineering, and Sales.

Group policies apply only to systems running Windows 2000, Windows XP Professional, and Windows Server 2003. You set policies for Windows NT 4.0 systems with the System Policy Editor (Poledit.exe). For Windows 95 and Windows 98, you need to use the System Policy Editor provided with Windows 95 or Windows 98, respectively, and then copy the policy file to the Sysvol share on a domain controller.

Group Policy settings are stored in a Group Policy Object (GPO). One way to think of a GPO is as a container for the policies you apply and their settings. You can apply multiple GPOs to a single site, domain, or organizational unit. Because policy is described using objects, many object-oriented concepts apply. If you know a bit about object-oriented programming, you might expect the concepts of parent-child relationships and inheritance to apply to GPOs—and you’d be right.

Through inheritance, a policy applied to a parent container is inherited by a child container. Essentially, this means that a policy setting applied to a parent object is passed down to a child object. For example, if you apply a policy setting in a domain, the setting is inherited by organizational units within the domain. In this case, the GPO for the domain is the parent object and the GPOs for the organizational units are the child objects.

The order of inheritance is as follows:

Site –> Domain –> Organizational Unit

This means that the group policy settings for a site are passed down to the domains within that site and the settings for a domain are passed down to the organizational units within that domain.

As you might expect, you can override inheritance. To do this, you specifically assign a policy setting for a child container that contradicts the policy setting for the parent. As long as overriding of the policy is allowed (that is, overriding isn’t blocked), the child’s policy setting will be applied appropriately. To learn more about overriding and blocking GPOs, see the section of this chapter entitled “Blocking, Overriding, and Disabling Policies.”

In What Order Are Multiple Policies Applied?

When multiple policies are in place, policies are applied in the following order:

  1. Windows NT 4.0 policies (Ntconfig.pol)
  2. Local group policies
  3. Site group policies
  4. Domain group policies
  5. Organizational unit group policies
  6. Child organizational unit group policies

If there are conflicts among the policy settings, the policy settings applied later have precedence and overwrite previously set policy settings. For example, organizational unit policies have precedence over domain group policies. As you might expect, there are exceptions to the precedence rule. These exceptions are discussed later in the section of this chapter entitled “Blocking, Overriding, and Disabling Policies.”

When Are Group Policies Applied?

As you’ll discover when you start working with group policies, policy settings are divided into two broad categories:

  • Those that apply to computers
  • Those that apply to users

Although computer policies are normally applied during system startup, user policies are normally applied during logon. The exact sequence of events is often important in troubleshooting system behavior. The events that take place during startup and logon are as follows:

  1. The network starts and then Windows Server 2003 applies computer policies. By default, the computer policies are applied one at a time in the previously specified order. No user interface is displayed while computer policies are being processed.
  2. Windows Server 2003 runs startup scripts. By default, startup scripts are executed one at a time, with each completing or timing out before the next one starts. Script execution isn’t displayed to the user unless specified.
  3. A user presses Ctrl+Alt+Del to log on. After the user is validated, Windows Server 2003 loads the user profile.
  4. Windows Server 2003 applies user policies. By default, the policies are applied one at a time in the previously specified order. The user interface is displayed while user policies are being processed.
  5. Windows Server 2003 runs logon scripts. Group policy logon scripts are executed simultaneously by default. Script execution isn’t displayed to the user unless specified. Scripts in the Netlogon share are run last in a normal command-shell window as in Windows NT 4.0.
  6. Windows Server 2003 displays the start shell interface configured in Group Policy.

By default, Group Policy is refreshed only when a user logs off or a computer is restarted. You can change this behavior by setting a Group Policy refresh interval as discussed in the section of this chapter entitled “Refreshing Group Policy.” To do this, open a command prompt and type gpupdate.

Group Policy Requirements and Version Compatibility

Group policies were introduced with Windows 2000 and apply only to systems running Windows 2000, Windows XP Professional, and Windows Server 2003. As you might expect, each new version of the Windows operating system has brought with it changes to Group Policy. Sometimes these changes have made older policies obsolete on newer versions of Windows. In this case, the policy only works on a specific version of the Windows operating system, such as only on Windows 2000.

Generally speaking, however, most policies are forward compatible. This means that policies introduced in Windows 2000 can, in most cases, be used on Windows 2000, Windows XP Professional, and Windows Server 2003. It also means that in most cases Windows XP Professional policies aren’t applicable to Windows 2000, and that policies introduced in Windows Server 2003 aren’t applicable to Windows 2000 or Windows XP Professional.

If a policy isn’t applicable to a particular version of the Windows operating system, you can’t enforce the policy on computers running those versions of the Windows operating system.

How will you know if a policy is supported on a particular version of Windows? Easy. The properties dialog box for each policy has a Supported On field in the Setting tab. This text-only field lists the policy’s compatibility with various versions of the Windows operating system. If you select the policy with the Extended display in the Group Policy Object Editor, you’ll also see a Requirements entry that lists compatibility.

You can also install new policies when you add a service pack, install Windows applications, or add Windows components. This means that you’ll see a wide range of compatibility entries.

Managing Local Group Policies

Each computer running Windows Server 2003 has one local group policy. You manage local policies on a computer by completing the following steps:

  1. Open the Run dialog box by clicking Start and then clicking Run.
  2. Type mmc in the Open field and then click OK. This opens the Microsoft Management Console (MMC).
  3. In MMC, click File, and then click Add/Remove Snap-In. This opens the Add/ Remove Snap-In dialog box.
  4. In the Standalone tab, click Add.
  5. In the Add Standalone Snap-In dialog box, click Group Policy Object Editor, and then click Add. This starts the Group Policy Wizard.
  6. Under Group Policy Object, Local Computer should be selected by default. If you want to edit the local policy on your computer, simply click Finish. To find the local policy on another computer, click Browse. After you find the policy you want to work with, click OK and then click Finish.
  7. Click Close and then click OK. You can now manage the local policy on the selected computer. For details, see the section of this chapter entitled “Working with Group Policies.”

Local group policies are stored in the %SystemRoot%\System32\GroupPolicy folder on each Windows Server 2003 computer. In this folder you’ll find the following subfolders:

  • Adm

Stores administrative template files currently being used. These files end with the .adm file extension. The Adm folder is only on domain controllers.

  • Machine

Stores computer scripts in the Script folder and registry-based policy information for HKEY_LOCAL_MACHINE (HKLM) in the Registry.pol file.

  • User

Stores user scripts in the Script folder and registry-based policy information for HKEY_CURRENT_USER (HKCU) in the Registry.pol file.

Warning: You shouldn’t edit these folders and files directly. Instead, you should use the appropriate features of the Group Policy console. By default, these files and folders are hidden. If you want to view hidden files and folders in Windows Explorer, select Folder Options from the Tools menu, click the View tab, choose Show Hidden Files And Folders, clear Hide Protected Operating System Files, and then click OK.

Creating and Editing Site, Domain, and Organizational Unit Policies

You create and edit site, domain, and organizational unit policies by completing the following steps:

  1. For sites, you start the Group Policy snap-in from the Active Directory Sites And Services console. Open the Active Directory Sites And Services console.
  2. For domains and organizational units, you start the Group Policy snap-in from the Active Directory Users And Computers console. Open the Active Directory Users And Computers console.
  3. In the appropriate console root, right-click the site, domain, or organizational unit on which you want to create or manage a group policy. Then select Properties on the shortcut menu. This opens a properties dialog box.
  4. In the properties dialog box, select the Group Policy tab. existing policies are listed in the Group Policy Object Links list.
  5. To create a new policy, click New. You can now configure the policy as explained in the section of this chapter entitled “Working with Group Policies.”
  6. To edit an existing policy, select the policy and then click Edit. You can now edit the policy as explained in the section of this chapter entitled “Working with Group Policies.”
  7. To change the priority of a policy, select the policy that you want to work with and then use the Up or Down button to change its position in the Group Policy Object Links list.

Site, domain, and organizational unit group policies are stored in the %SystemRoot%\ Sysvol\Domain\Policies folder on domain controllers. In this folder you’ll find one subfolder for each policy you’ve defined on the domain controller. The policy folder names are the policy’s Global Unique Identifier (GUID). The GUIDs can be found on the policy’s properties page in the General tab in the summary frame. Within these individual policy folders, you’ll find the following subfolders:

  • Adm

Stores administrative template files currently being used. These files end with the .adm file extension. The Adm folder is only on domain controllers.

  • Machine

Stores computer scripts in the Script folder and registry-based policy information for HKEY_LOCAL_MACHINE (HKLM) in the Registry.pol file.

  • User

Stores user scripts in the Script folder and registry-based policy information for HKEY_CURRENT_USER (HKCU) in the Registry.pol file.

Blocking, Overriding, and Disabling Policies

You can block policy inheritance at the site, domain, and organizational unit level. This means that you could block policies that would otherwise be applied. At the site and domain level, you can also enforce policies that would otherwise be contradicted or blocked. This gives top-level administrators the ability to enforce policies and prevent them from being blocked. Another available option is to disable policies. You can disable a policy partially or entirely without deleting its definition.

You configure these policy options by completing the following steps:

  1. Access the Group Policy tab for the site, domain, or organizational unit you want to work with as specified in Steps 1–4 of the “Creating and Editing Site, Domain, and Organizational Unit Policies” section earlier in this chapter.
  2. Select Block Policy Inheritance to prevent the inheritance of higher-level policies (unless those policies have the No Override option set).
  3. Use the No Override option to prevent lower-level policies from blocking the policy settings. Select or clear the No Override option by double-clicking in the appropriate column to the right of the group policy entry. A check mark indicates the option is selected.
  4. Use the Disabled option to prevent the policy from being used. Select or clear the Disabled option by double-clicking in the appropriate column to the right of the group policy entry. A check mark indicates the option is selected.
Disabling an Unused Part of Group Policy

Another way to disable a policy is to disable an unused part of the GPO. When you do this, you block the Computer Configuration or User Configuration settings, or both, and don’t allow them to be applied. By disabling part of a policy that isn’t used, the application of GPOs and security will be faster.

You can enable or disable configuration settings in Group Policy by following these steps:

  1. Access the Group Policy tab for the site, domain, or organizational unit you want to work with as specified in Steps 1–4 of the “Creating and Editing Site, Domain, and Organizational Unit Policies” section earlier in this chapter.
  2. Click Properties in the Global Policy tab, and then select or clear Disable Computer Configuration Settings and Disable User Configuration Settings.

Caution

Any settings of the blocked node aren’t applied and are essentially lost. To get these settings back, you’ll have to clear the Disable … Settings options.

Applying an Existing Policy to a New Location

Any group policy that you’ve created can be associated with another computer, unit, domain, or site. By associating the policy with another object, you can use the policy settings without having to recreate them.

You apply an existing policy to a new location by completing the following steps:

  1. Access the Group Policy tab for the site, domain, or organizational unit you want to work with.
  2. In the Group Policy tab, click Add. As shown in Figure 4-2, this opens the Add A Group Policy Object Link dialog box.
  3. Use the tabs and fields provided to find the group policy you want to apply to the current location. When you find the policy, click OK.
Deleting a Group Policy

You can disable or delete group policies that you don’t use. To disable a policy, double-click in the Disabled column to the right of the group policy entry. A check mark indicates that the option is selected. To delete a policy, follow these steps:

  1. Access the Group Policy tab for the site, domain, or organizational unit you want to work with as specified in Steps 1–4 of the section of this chapter entitled “Creating and Editing Site, Domain, and Organizational Unit Policies.”
  2. Select the policy you want to delete and then click Delete.
  3. If the policy is linked, you have the option of deleting the link without affecting other containers that use the policy. To do this, in the Delete dialog box select Remove The Link From The List.
  4. If the policy is linked, you can also delete the link and the related policy object, which permanently deletes the policy. To do this, select Remove The Link And Delete The Group Policy Object Permanently.
Refreshing Group Policy

When you make changes to Group Policy, those changes are immediate. However, they aren’t propagated automatically. Client computers request policy when

  • The computer starts
  • A user logs on
  • An application or user requests a refresh
  • A refresh interval is set for Group Policy and the interval has elapsed

As you learned previously in this chapter, you can request that a policy be refreshed on a local computer using the Gpupdate command-line utility. Simply type gpupdate at the command prompt. You can also refresh a policy by setting a specific refresh interval, which thereby periodically forces a refresh. Either way, however, the refresh is only a background refresh and some policies might not be updated. The only way to ensure that all user policies are updated is to have the user log off. The only way to ensure that all computer policies are updated is to restart the computer.

To set a refresh interval in Group Policy, follow these steps:

  1. Access the Group Policy console for the site, domain, or organizational unit you want to work with as specified in the section of this chapter entitled “Creating and Editing Site, Domain, and Organizational Unit Policies.”
  2. Access the Group Policy node by expanding Computer Configuration\ Administrative Templates\System\Group Policy.
  3. In the details pane, double-click Group Policy Refresh Interval For Computers. This policy controls the background refresh rate for computer policies.
  4. In the Setting tab, Select Enabled. You can now set the refresh interval for computer policies using the options provided. With the default settings, Group Policy is updated every 90 minutes with a random offset of 0 to 30 minutes. The offset makes it less likely that multiple computers will request updates at the same time. Click OK.
  5. Access User Configuration\Administrative Templates\System\Group Policy.
  6. In the details pane, double-click Group Policy Refresh Interval For Users. This policy controls the background refresh rate for computer policies.
  7. In the Setting tab, select Enabled. You can now set the refresh interval for user policies using the options provided. Click OK when finished.
  8. When applying a refresh, network traffic is generated. During the update, the local computer might be less responsive than normal, which might affect the user’s work.

Note

The refresh interval for computers doesn’t apply to domain controllers. If you want domain controllers to regularly refresh a policy, access Computer Configuration\Administrative Templates\System\Group Policy and then double-click Group Policy Refresh Interval For Domain Controllers. You can now set the refresh interval.


Exchange Server supports public folders. Public folders are for common access to messages and files. Files

can be dragged from file−access interfaces, such as Explorer in Windows 98, NT 4, 2000, and 2003, and can

be dropped into public folders.

You can set up sorting rules for a public folder so that items in the folder are organized by a range of

attributes, such as the name of the sender or the creator of the item, or the date that the item arrived or was

placed in the folder. Items in a public folder can be sorted by conversation threads. You can also put

applications built on existing products such as Word or Excel or with Exchange or Outlook Forms Designer,

client or server scripting, or the Exchange API set into public folders. You can use public folders to replace

many of the maddening paper−based processes that abound in every organization.

For easy access to items in a public folder, you can use a folder link. You can send a link to a folder in a

message. When someone goes to the folder and double−clicks a file you put in the folder, the file opens.

Everyone who receives the message works with the same linked attachment, so everyone reads and can

modify the same file. As with document routing, applications such as Microsoft Word can keep track of each

person’s changes to and comments on file contents. Of course, your users will have to learn to live with the

fact that only one person can edit an application file at a time. Most modern end−user applications warn the

user that someone else is using the file and allow the user to open a read−only copy of the file, which, of

course, can’t be edited. Third−party applications offer tighter document checkout control (see the Appendix,

‘Cool Third−Party Applications for Exchange Server and Outlook Clients’).

If all this isn’t already enough, Exchange is very much Internet aware. With Exchange Server 2003, you can

publish all or selected public folders on the Internet, where they become accessible with a simple Internet

browser. You can limit Internet access to public folders only to users who have access under Windows Server

2003’s security system, or you can open public folders to anyone on the Internet. Just think about it:

Internet−enabled public folders let you put information on the Internet without the fuss and bother of website

design and development. Any item can be placed on the Internet by simply adding a message or other object

to a public folder.

Before we leave public folder applications, I want to mention one more option: Exchange Server 2003 enables

you to bring any or all of those Usenet Internet newsgroups to your public folder environment. With their

Outlook clients, users then can read and reply to newsgroup items just as though they were using a standard

newsgroup reader application. Exchange Server comes with all the tools that you need to do this. All you need

is an Internet connection, access to a host computer that can provide you with a feed of newsgroup messages,

and a set of rules about which groups to exclude. Remember, this is where the infamous alt.sex newsgroups

live. But you don’t have to use public newsgroups. Rather, you can create your own private newsgroups for

internal communications.

Exchange Server 2003 is a complex product with a remarkably easy−to−use interface for administration and

management. All of this complexity and parallel ease of use requires an industrial−strength computer. The

minimum server computer suggested here is for testing, learning about, and evaluating the product. It’s also

enough for a small, noncritical installation. However, as I discuss in the book, when the server moves into

critical production environments, where it will be accessed by large numbers of users, you’ll need to beef up

its hardware and add a number of fault−tolerant capabilities. On the client side, with the broad range of clients

available for Exchange, the machines now on desktops in most organizations should be more than adequate.

At a minimum, to test, learn about, and evaluate Exchange Server, you need the following:

Either Microsoft Exchange Server 2003 and any version of Windows Server 2003 or Microsoft

Exchange Server 2003 Enterprise Edition and Windows Server 2003 Enterprise or Datacenter Edition.

  • ·A 1GHz Pentium III− or 4−based PC with 512MB of RAM and two 9GB disk drives. This allows you

to complete exercises involving a single Exchange server.

  • ·A minimum of three additional computers in the class just described. This allows you to complete

exercises involving multiple computers in multiple administrative groups and Windows Server 2003

domains.

  • · Tape backup hardware or at least one independent disk drive for backup.
  • · A local area network (preferably connected to the Internet).

At least one 800MHz Pentium III or 4 or equivalent computer with 128MB of memory running

Windows XP Professional.

As always, as new features come, old features go. There are inevitably a few that have

found themselves on the “deprecated list” this time around, and so will not be continued in

Exchange Server 2010 and beyond. Since this is a much shorter list than the “new features”,

Here they are:

• There are some major changes in Exchange Server clustering: in Exchange Server 2007

you had LCR (Local Continuous Replication), CCR (Cluster Continuous Replication) and

SCR (Standby Continuous Replication) – three diff erent versions of replication, all with

their own management interfaces. All three are no longer available in Exchange Server

2010.

• Windows Server Fail-over Clustering has been removed in Exchange Server 2010.

Although seriously improved in Windows Server 2008, a lot of Exchange Administrators

still found the fail-over clustering complex and diffi cult to manage. As a result, it was still

prone to error and a potential source of all kinds of problems.

Storage Groups are no longer available in Exchange Server 2010. The concepts of a database,

log fi les and a checkpoint fi le are still there, but now it is just called a database. It’s

like CCR in Exchange Server 2007, where you could only have one database per Storage

Group.

• Owing to major reengineering in the Exchange Server 2010 databases, the Single

Instance Storage (SIS) is no longer available. This means that when you send a 1 MB

message to 100 recipients, the database will potentially grow by 100 MB. This will surely

have an impact on the storage requirements in terms of space, but the performance

improvements on the Database are really great. I’ll get back on that later in this chapter.


Problem

You want to create a new storage group to allow for more mailbox stores, faster backups, or a logical organization of mailboxes.

Solution

Using a graphical user interface

  1. Open the Exchange System Manager (ESM) snap-in.
  2. In the left pane, browse to the server that you want to create a new storage group for.
  3. Right-click on the server and select New Storage Group.
  4. Enter a name, transaction log location, system path location for storage of temporary and recovered files and click OK.

Using a command-line interface

First create an LDIF file called add_sg.ldf with the following contents:

dn: CN=<

Storage Group Name>,<ParentDN>

changetype: add

objectClass: msExchStorageGroup

cn: <

Storage Group Name>

showInAdvancedViewOnly: TRUE

systemFlags: 1610612736

msExchESEParamEnableIndexChecking: TRUE

msExchESEParamEnableOnlineDefrag: TRUE

msExchESEParamSystemPath: <Path to store system files>

msExchESEParamPageFragment: 8

msExchESEParamPageTempDBMin: 0

msExchRecovery: TRUE

msExchESEParamZeroDatabaseDuringBackup: 0

msExchESEParamBaseName: E01

msExchESEParamCircularLog: 0

msExchESEParamEventSource: MsExchangeIS

msExchESEParamCheckpointDepthMax: 20971520

msExchESEParamCommitDefault: 0

msExchESEParamLogFilePath: <Path to log files>

msExchESEParamDbExtensionSize: 256

msExchESEParamLogFileSize: 5120

Replace < Storage Group Name> with the name of the storage group, <ParentDN> with the distinguished named for storage groups container for the appropriate server, <Path to store system files> with the filesystem path where you want system files (temporary and recovered files), and <Path to log files> with the filesystem path where you want exchange log files. Then run the following command:

>ldifde -i -f add-sg.ldf

Using VBScript

‘ This code creates a Storage Group.

‘ —— SCRIPT CONFIGURATION ——

strServer = “<

Exchange Server>”   ‘ e.g. ExchServer2

strName = “<Storage Group Name>”  ‘ e.g. SG1

strPath = “<File Path>” & strName ‘ e.g. D:\Program Files\ExchSrvr

‘ —— END CONFIGURATION ———

‘ Create URL to Storage Group

Set objSrv = CreateObject(“CDOEXM.ExchangeServer”)

objSrv.DataSource.Open strServer

‘ This for loop is a bit of a hack to retrieve the first Storage Group

‘ in the collection. VBScript doesn’t let you access specific elements

‘ of a collection the way Jscript can.

for each strSg in objSrv.StorageGroups

strTemp = strSg

exit for

next

strTemp = mid(strTemp,instr(2,strTemp,”cn”,1))

strSGUrl = “LDAP://cn=” & strName & “,” & strTemp

‘ Create/configure

Storage Group and save it

set objSG = CreateObject(“CDOEXM.StorageGroup”)

objSG.MoveSystemFiles(strPath)

objSG.MoveLogFiles(strPath)

objSG.DataSource.SaveTo strSGUrl

Wscript.Echo “Successfully created storage group.”

Discussion

Storage groups are used for physically breaking your databases up into smaller management groups. This is done for several reasons. Chief among them are so you will have more numerous but smaller databases, a logical organization of mailboxes, or faster Exchange backups and restores since the Exchange Server can run one simultaneous backup for each storage group. For example, if you have four mailbox databases in a single storage group, you can only have one backup running for that storage group; if you spread those four mailbox databases across two storage groups, you can run two simultaneous backups. For more detailed information on Exchange backups and file structures, see the Exchange Server Cookbook by Paul Robichaux et al. (O’Reilly).

Depending on the version (Standard or Enterprise) of Exchange, you can have up to four storage groups per server and up to five mailbox stores per storage group. ESM enforces these limits, but it is possible to directly modify Active Directory to exceed them. If you create more databases or storage groups than allowed by your version, the additional databases will not mount. In Exchange 2003, Microsoft recommends that you spread your mailboxes across as many stores and storage groups as possible; this is because of memory management improvements since Exchange 2000.

Storage groups are represented in Active Directory by the msExchStorageGroup class. This class has several attributes that have fairly intuitive string values and names and can be matched up to the options in ESM. Unfortunately, the raw Active Directory objects and attributes and their valid values for Exchange are not well documented. You can experiment with their settings, but you should do so only in a lab environment.

Using a Command-Line Interface

One negative aspect of creating storage groups by direct Active Directory object manipulation is that you will not get warnings concerning the maximum number of storage groups allowed.

Using VBScript

The process of calling the CDOEXM interfaces to create storage groups is rather straightforward once you have the URL for the location of the object in Active Directory. In this solution, to get the distinguished name of the storage group container for the server, the script loops through all storage groups on the sever and sets strTemp to the URL value of the last storage group. This value is then parsed to get the parent container for the storage groups to build the new storage group URL.