Back to description
Windows PowerShell is the next-generation command-line shell and scripting language for Windows. Exchange Server 2007... more
Windows PowerShell is the next-generation command-line shell and scripting language for Windows. Exchange Server 2007 is the first Microsoft application to utilize Windows PowerShell for deployment and administration. This chapter introduces Windows PowerShell and explains the basic concepts you’ll need to know to use Windows PowerShell effectively.
The first section, “What Is Windows PowerShell,” includes command shell history and describes the features that make Windows PowerShell the ideal management platform for Exchange Server 2007.
The section that follows, “Windows PowerShell Basics,” covers the fundamentals of Windows PowerShell. This section describes the components of Windows PowerShell and how to find commands and then learn how to use them.
To understand Windows PowerShell and the benefit to Exchange administrators, this chapter covers the following key areas:
Command shells vs. Graphical User Interfaces
Windows PowerShell components
Windows PowerShell built-in help
Composing commands using pipelines
... less
The Exchange Management Shell is overall the best tool for controlling your Exchange Server 2007 organization.... more
The Exchange Management Shell is overall the best tool for controlling your Exchange Server 2007 organization. This chapter provides an overview of the management functionality it provides.
This chapter explains why you should consider learning Exchange Management Shell an essential part of building your Exchange Server 2007 management skills.
The section “Shell versus Console” provides a comparison between the two interfaces in the context of the Exchange management functions they provide and when to choose the Exchange Management Shell.
The section “Working from the Command Line” provides some basic information for getting started using Exchange Management Shell. It covers navigation, using aliases and variables with Exchange cmdlets, and some general tips you’ll find useful.
The final section, “Working with Windows,” tells how to control services and processes, access the Windows Registry as a drive, and view Windows event logs.
In this chapter you learn:
Exchange cmdlet sets
Shell navigation
Variables, aliases, and functions
Profiles
Process and service control
Registry control
Event log control
Installing Exchange Server 2007 is different from installing previous generations of Exchange products.... more
Installing Exchange Server 2007 is different from installing previous generations of Exchange products. New hardware and new server roles are just the tip of the iceberg. There are new clustering and replication engines, more intelligent spam settings, the ability to encrypt communication between two Exchange Server 2007 organizations. It is indeed a very exciting time to be involved with Exchange.
This chapter discusses installation and deployment of Exchange Server 2007. The installation pieces are broken down into hardware requirements, software requirements, and domain requirements. Each one of these requires some planning because Exchange Server 2007 is 64-bit only. New servers may need to be purchased. You may need to perform compatibility testing of your company’s products to ensure that backups, antivirus, and monitoring tools will work, as well as a health check on the AD infrastructure to ensure that the domain is sufficient for Exchange deployment. After the requirements are displayed, the setup switches are explained along with information about what is required to prepare the environment. Though this may seem mundane, it is necessary because there are switches available to ensure compatibility with legacy clients. After the setup switches are discussed, we focus on deployment scenarios. Although we discuss how many servers and what roles should be deployed, it is not an exhaustive list of every deployment scenario. The scenarios are discussed as a prelude to the rest of the book. They are presented to give you a cursory understanding of what the server role provides; the remaining chapters in the book further discuss the individual parameters of their respective roles.
Exchange Server 2007 requirements
Server installation
Disaster recovery
Deployment scenarios
In Exchange Server 2000/2003, Exchange mailbox user objects are created in Active Directory and thereafter can be viewed... more
In Exchange Server 2000/2003, Exchange mailbox user objects are created in Active Directory and thereafter can be viewed in Exchange System Manager. The only operations that can be performed on these objects from the Exchange System Manager are to purge, reconnect, or run Exchange tasks. Available tasks performed by the Exchange Tasks Wizard are limited to move mailbox, delete mailbox, and configure Exchange features. No other Recipient type or group can be managed in the Exchange System Manager. Moreover, it is difficult to distinguish Recipient types simply by the object’s icon in Active Directory Users and Computers.
In Exchange Server 2007, however, creation and management of Recipient and group objects including their Exchange-related properties have been incorporated into the Exchange Management Console and Exchange Management Shell. The Exchange Management Shell enables you carry out various operations on Recipient and group objects, some of which are not available in the Management Console. In addition, distinguishing Recipient types is easy in Exchange Server 2007 because explicit Recipient Types properties have been added. Their icon in the Exchange Management Console makes them easy to recognize or you can look at the RecipientTypeDetails property for the Recipient in Exchange Management Shell.
RecipientTypeDetails
At the end of this chapter, you will be able to identify the Recipient and group object types associated with Exchange Server 2007. You will also become familiar with the Exchange Management Shell cmdlets that operate on these objects, differentiate between these object types, and carry out common tasks associated with these objects in the Exchange Management Shell.
This chapter covers:
Recipient scope in the Exchange Management Shell
All available Recipient types in Exchange Server 2007
Creating and modifying Exchange Server 2007 Recipient types including features introduced in Service Pack 1
Bulk management scenarios
Before Exchange 2007 was released there was much discussion about the fate of public folders. Was it finally time to remove... more
Before Exchange 2007 was released there was much discussion about the fate of public folders. Was it finally time to remove public folders from Exchange public folders can be an administrator’s nightmare because they tend to grow large in size, and can be difficult to manage. Also, Microsoft suggests Microsoft Office SharePoint Server as the path for migration (http://msdn2.microsoft.com/en-us/library/aa579360.aspx). On the other hand, Public folders still offer features that other solutions do not; one example is data replication.
http://msdn2.microsoft.com/en-us/library/aa579360.aspx
There are very few changes to the core Public-folder architecture in Exchange Server 2007. On the other hand, there is good news for administrators with Exchange Server 2007’s release. Exchange Server 2007 removed the hard requirement for new installations to have public folders. Of course, this depends on fully deploying the new Office Outlook 2007 client. As long as there are prior Outlook client versions, Public folders are required for system folders (that is, calendar free/busy, offline address book); I will show a method of removing Public folders once all clients are upgraded.
Unlike all previous versions of Exchange, prior to Service Pack 1 there was no public folder management in the GUI, so all Public folder management must be done through PowerShell.
Note
It is also possible to use a free third-party utility called PFDavAdmin for graphical administration.
This chapter discusses:
Database Administration
Working with Permissions
Folder and Content Administration
The Client Access Server (CAS) plays a similar role to the Exchange Server 2000 or 2003 Front-End computer.... more
The Client Access Server (CAS) plays a similar role to the Exchange Server 2000 or 2003 Front-End computer. It provides client access to Office Outlook Web Access (OWA), Exchange ActiveSync (EAS), Outlook Anywhere, IMAP4, and POP3. The CAS also provides new servicesAutodiscover, the Availability Service, and Exchange Web Services. Autodiscover will automatically create Office Outlook 2007 profiles for users by just entering their email address and password. The Availability Service provides calendaring information, such as free/busy for Office Outlook 2007 clients. Exchange Web Services is an interface for building applications integrated with Exchange with the Microsoft .NET platform.
Unlike the Exchange Server 2003 front-end server, the CAS handles more processing to lighten the work done by the Mailbox role. There must be at least one CAS deployed in the organization, and at least one per Active Directory site where there is a Mailbox role. This chapter helps an administrator understand and configure the services provided by the CAS. This chapter covers the following topics:
Working with user settings
Configuring POP3 and IMAP4
Configuring certificates
Working with Autodiscover, proxy, and redirection
Working with Outlook Anywhere
Working with the Offline Address Book
Working with LinkAccess for Outlook Web Access
Exchange Server 2000/2003 used the concept of bridgehead servers and connectors. A bridgehead server referred to an Exchange... more
Exchange Server 2000/2003 used the concept of bridgehead servers and connectors. A bridgehead server referred to an Exchange server that served as a connection point for delivering email from one routing group to another and to remote or external email systems. Bridgehead servers used connectors to make information flow between routing groups and remote or external systems possible. Several types of connectors were available: SMTP, Routing Group, and X.400.
Exchange Server 2007 introduces the concept of the Hub Transport role. Computers running Exchange Server 2007 with the Hub Transport role are called Hub Transport servers and are identical to bridgehead servers in Exchange 2000/2003; however, they differ greatly in core transport functionality. The Hub Transport server role is installed in any Active Directory site that contains the Mailbox server role and is responsible for mail delivery within the Active Directory site. It can be installed on separate hardware as the only server role or on the same server hardware in conjunction with other non-clustered Exchange Server 2007 roles. The Hub Transport server receives messages from and sends messages to servers running the Mailbox server role. Every message sent and received by an Exchange mailbox must pass through the Hub Transport server, hence transport rules and journal policies are not skipped for any message. In a multi-site organization, messages destined for a user in a different site are transferred to a Hub Transport server in that site for delivery. Messages destined for the Internet or other messaging systems are sent to the Edge Transport server for delivery. We discuss the Edge Transport role further in Chapter 9. The Hub Transport server role uses Send Connectors and Receive Connectors for email routing and delivery.
Understanding the core transport architecture implemented by the Hub Transport and Edge Transport servers.
Using and configuring the Hub Transport server
Configuring various types of connectors in Exchange Server 2007
Using email address policies and accepted domains
The Mailbox role is at the heart of the server roles. Mailbox and public folder data is stored on the Mailbox role.... more
The Mailbox role is at the heart of the server roles. Mailbox and public folder data is stored on the Mailbox role. Other processes, such as managed folders and address book generation run on the Mailbox role. Unlike previous versions, the mailbox server does not send or receive mail without going through a hub transport.
The Mailbox role can be configured for high availability using traditional clustering or a few new options. High-availability options are discussed in Chapter 12.
Creating a mailbox store and database
Configuring a mailbox store and database
Recovering mailbox data with Recovery Storage Groups
Chapter 7 discussed the transport architecture in Exchange Server 2007 and Hub Transport server role.... more
Chapter 7 discussed the transport architecture in Exchange Server 2007 and Hub Transport server role. This chapter discusses the Edge Transport server role, which is identical to the Hub server role in many respects and implements the core transport architecture. Although both roles share identical features, they differ in default configuration and functionality. Whereas the focus of the Hub Transport server role is intra-organizational email communication and compliance, the focus of the Edge Transport server is for inter-organizational email communication, message hygiene, and security. This implementation of the Edge Transport server new to the Exchange line of messaging products arose as a result of increasing Unsolicited Commercial E-mail (UCE) volume and the risk of denial of service attacks perpetrated via email. It reduces the attack surface of such threats by providing a means for organizations to segment such email traffic even before it enters the Exchange organization, while preventing access to internal resources. Some of the features of the Edge Transport server have been implemented in earlier versions of Exchange, however this role segmentation was never possible in any other version of Exchange. Message filtering functionality such as sender, Recipient, connection filtering, and so forth, which existed in Exchange Server 2003, have been improved and implemented on the Edge Transport server role.
By the end of this chapter, you’ll have an overview of the components of the Edge Transport server and be able to configure the Edge Transport server for email message flow into and out of an Exchange organization, using the Exchange Management Shell. You also gain an idea of how agents work in message hygiene.
This chapter covers the following:
A brief overview of the Edge Transport server role and its architecture
The Active Directory Application Mode (ADAM) service requirement for the Edge Transport server role
Configuration of the Edge Transport server
Message hygiene and transport agents
When Microsoft released Exchange Server 2007, one of the coolest features included was Unified Messaging.... more
When Microsoft released Exchange Server 2007, one of the coolest features included was Unified Messaging. For those who are not familiar with this, Unified Messaging, or UM (pronounced either as the two letters individually or as the interjection that speech coaches despise), is a role within Exchange that allows users to receive voicemail and faxes directly to their mailboxes! It will even let you dial a number and then play your messages, read your email, and dictate your schedule to you. This role also integrates with Microsoft Office Communicator Server to create one of the feature-rich IP voice systems to date. UM fills a very important niche because it allows IT departments to reduce the complexity of the infrastructure and enables them to retire aging voice mail platforms. For more information on UM please see microsoft.com/technet/prodtechnol/exchange/2007/evaluate/overview/default.mspx.
microsoft.com/technet/prodtechnol/exchange/2007/evaluate/overview/default.mspx
In order for you to get the most out of this chapter, you must have the UM role installed on a server (see Chapter 3 for installation information). It is also advantageous, not required, to have a cursory understanding of how phone systems, PBXs, and audio encoding work.
In Chapter 3 you learned how to install the UM role. Now you are going to build from there and configure UM with the minimum amount of options to make it work. From there you add onto these cmdlets, introduce new cmdlets, configure the UM Virtual Directory, and finish up the chapter with a list of the UM cmdlets. For an authoritative definition of every cmdlets option, refer to the Microsoft Exchange Server 2007 help file (also knows as the CHM file).
This chapter covers the following topics:
Creating UMDialPlan, UMIPGateway, UMMailboxPolicy, and UM Server
Using the Get-UM cmdlets to retrieve data
Get-UM
UM user management
AutoAttendant management
Removing and disabling UM features
Routing determines how a message gets from a source server to its destination server. Routing decides on the best and... more
Routing determines how a message gets from a source server to its destination server. Routing decides on the best and least expensive path a message takes when transferred between Exchange servers within an organization and to servers in other organizations. In Exchange Server 2000/2003, several components were involved in routing, including Link State, Routing Groups, Connectors, and Routing Group Masters. Routing Groups were logical groupings of Exchange servers determined by the administrator. In Exchange Server 2007, because the transport core functionality has changed as noted in Chapter 7, message routing has also been changed. Rather than using the Routing Engine found in Exchange 2000/2003, the Categorizer (see “The Transport Server Architecture” in Chapter 7) now has a routing stage that determines the ultimate destination for a message, selects a route to that destination, and selects and resolves the next hop for that destination to a server(s) and IP addresses.
One of the components of routing in Exchange 2000/2003 many Exchange administrators were happy to see go away was link state. Although link state had some benefits, managing it in some cases required a significant overhead. In some large Exchange Server environments, the orgInfo packet, which holds the routing information for the organization, became quite large and caused significant network bandwidth utilization during data transfer among servers. Also, transient network and Active Directory replication problems caused connector oscillations. Rather than use a logical groups of servers, Exchange Server 2007 takes advantage of Active Directory site topology in routing messages within and outside an Exchange organization.
By the end of this chapter, you will be familiar with message routing and its components in Exchange Server 2007 as well as the few Exchange Management Shell cmdlets that can be used to manage message routing. This chapter covers the following topics:
Routing changes in Exchange
Basics of Exchange Server 2007 routing
Routing troubleshooting
How Active Directory sites affect message routing
Coexistence with Exchange 2003 and link state considerations
Many companies have grown to recognize email as a business-critical application. Also, messaging platforms have integrated... more
Many companies have grown to recognize email as a business-critical application. Also, messaging platforms have integrated into areas such as Unified Messaging and workflow processes. New ways to access mail and documents through mobile phones and VPNs make user access 24x7x360. Because of this reliance on these services, companies need to make Exchange available without interruption. It is no longer acceptable to take a service offlineeven for maintenance. In response to customer needs, Microsoft designed Exchange to work in a Windows cluster. In this configuration, Exchange is fault tolerant to hardware failure by sharing a single copy of the database and log files. This solution also provides the benefit for administrators to minimize downtime due to regular server maintenance, such as applying security updates.
However, in recent years, catastrophic events like Hurricane Katrina and the World Trade Center bombing forced companies to think about site resiliency. In Exchange 2003 and earlier, organizations that wanted geographical fault tolerance needed to turn to third parties to provide data replication. A typical scenario in Exchange 2003 was an Exchange cluster attached to a SAN for hardware/software replication of Exchange data to a second SAN. This solution could be costly and some solutions had no support from Microsoft. Clustering in general is more complicated and requires well-defined processes. For example, the hardware selection and software installation differs significantly compared to a non-clustered server. Unfortunately, many administrators were not trained adequately, and outages could actually become longer or more severe due to administration mistakes.
In response to the growing demand for a supported, less costly, and easier to administer cluster design, Exchange Server 2007 introduces three forms of continuous replicationLocal Continuous Replication (LCR), Clustered Continuous Replication (CCR), and new in Service Pack 1Standby Continuous Replication (SCR). In addition, Exchange still offers traditional Single Copy Clusters (SCCs).
In this chapter you learn about:
Installing different types of continuous replication
Seeding replications
Monitoring system health
Failover and fallback
Single Copy Clusters (SCCs) are Microsoft Exchange Server 2007’s traditional approach to active/passive clustering... more
Single Copy Clusters (SCCs) are Microsoft Exchange Server 2007’s traditional approach to active/passive clustering of mailboxes. In this release of Exchange only active/passive configurations are supported. The active/active role is no longer supported; one passive node is always required in a cluster. Also, the Mailbox role is the only role supported for deployment in a Microsoft Cluster Service (MSCS) configuration. Clustering mailboxes, through SCC, provides a higher level of uptime and availability to end users. If there is a hardware failure on one of the nodes in the cluster, any resources that were on that node are relocated to another node in the cluster. Individual nodes can be taken down for patching without disrupting the overall application uptime to the client. This does not provide a 100 percent uptime guarantee, but will provide a higher level of service over a standalone mailbox server. Clients will still incur a slight pause in service while the resources are moved to another node, but to most users this will be nearly transparent.
One of the primary goals of this chapter is to demonstrate how to use PowerShell to interact with native operating system commands to accomplish automated tasks with the use of PowerShell variables.
SCCs reside as clustered resources within a traditional Microsoft Cluster Server (MSCS) environment. To guarantee a successful SCC deployment within MSCS, there are several prerequisite steps that must be followed. This first half of this chapter focuses on using PowerShell to install the various components of an MSCS cluster and then to perform the actual Exchange SCC install.
The second half of this chapter focuses on Exchange-specific resource management within an SCC environment. The Exchange administrator will learn how to use PowerShell to move and manage resources, as well as how to check the health of an SCC cluster.
In this chapter the following topics are discussed:
Automating a Single Copy Cluster (SCC) install
Resource management
This chapter deals with troubleshooting Microsoft Exchange Server 2007 through the use of cmdlets.... more
This chapter deals with troubleshooting Microsoft Exchange Server 2007 through the use of cmdlets. Microsoft has created several test cmdlets that allow the system administrator to programmatically test various Exchange roles and services. These cmdlets are built into Exchange. No longer do you need to write cumbersome multilanguage test scripts! This chapter covers the following:
Determining server health
Determining Exchange system health
Testing anti-spam functions
Troubleshooting Client Access Server Role functions
Testing Web Services
Troubleshooting MAPI connectivity
Testing Mailflow
Testing the Exchange Search service
Troubleshooting edge synchronization
Troubleshooting Unified Messaging connectivity
Using Get-EventLog
Get-EventLog
Using Get-Message
Get-Message
Tracking messages
Working with event log levels
To receive the greatest benefit from these cmdlets, a fully configured Exchange environment is required. CAS, Hub, and Mailbox roles are required for tests in this chapter. Also, Internet connectivity is recommended so the test cmdlets can retrieve updates from Microsoft.
All good administrators know scripts are used to automate everyday tasks and ensure consistent results with a minimum... more
All good administrators know scripts are used to automate everyday tasks and ensure consistent results with a minimum of effort. The built-in scripting capabilities of Windows PowerShell, and by extension Exchange Management Shell, offer a level of control previously unavailable when using administrative tools supplied in earlier versions of Exchange Server.
This chapter examines these scripting capabilities via a thorough examination of sample administrative scripts, starting at a basic level and expanding to scripts that accomplish more complex tasks.
This chapter explores scripts that complete these tasks:
Mailbox-enable users
Assign group membership based on user attributes
Load-balance mailbox creation across databases based on user names
Create a public folder for a user
By this point in reading this book you probably have a list of scripts that you want to put together because you want... more
By this point in reading this book you probably have a list of scripts that you want to put together because you want to try them out in your messaging environment. As you can imagine, once you really begin to harness the power of PowerShell you are going to have more and more ideas that you want to try out. In this chapter we discuss using PowerShell to create some reports and to help automate some administrative tasks. Because the sheer breadth of what you can accomplish with PowerShell scripting is immense, we are going to pick just a few examples to give you the tools you need to create your own scripts.
Reading in files for processing
Advanced output techniques
Examples for using these techniques
In this chapter you’ll see how to leverage Exchange PowerShell from within the .NET Framework and how to make a... more
In this chapter you’ll see how to leverage Exchange PowerShell from within the .NET Framework and how to make a basic web-based page to run PowerShell cmdlets. We also discuss some ideas on what can be done to use .NET. This chapter involves some programming, so previous experience would be helpful.
PowerShell is built on the .NET Framework, and the only management interface exposed for Exchange Server 2007 is the PowerShell cmdlets, so running PowerShell from within something like C# or VB.NET would be easy. Because this is the only interface that is exposed, the Exchange product team uses the PowerShell cmdlets to provide the Exchange Management Console graphical management tool. You can run PowerShell cmdlets easily from within the .NET Framework, and you will work through a few examples in this chapter.
Accessing PowerShell from the .NET Framework
Solving problems with PowerShell and the .NET Framework
Purchase Before purchasing this product, please be sure you have met all software and system requirements, and that you understand any limits placed upon its use.
Return Policy Wrox Chapters on Demand are non-returnable and non-refundable.
Reader Software Wrox Chapters on Demand are offered as PDFs, and they must be viewed using the Adobe Reader. If you do not have the Reader installed, it can be downloaded for free at Adobe.com.
Test Download As Wrox Chapters on Demand purchases are non-returnable, it is advisable that you test your system and software configurations with a free sample download before you place an order.
Usage Rights for a Wrox Chapter on Demand File Any Wrox Chapter on Demand product you purchase from this site will come with certain restrictions that allow Wiley to protect the copyrights of its products. After you purchase and download this title, you:
If you have any questions about these restrictions, you may contact Customer Care at (877) 762-2974 (8 a.m. - 5 p.m. EST, Monday - Friday). If you have any issues related to Technical Support, please contact us at 800-762-2974 (United States only) or 317-572-3994 (International) 8 a.m. - 8 p.m. EST, Monday - Friday).
Related Books