Pro Exchange 2013 SP1 PowerShell管理深度指南

需积分: 6 73 浏览量更新于2024-07-18 收藏 35.56MB PDF 举报

《Pro Exchange 2013 SP1 PowerShell Administration》是一本深度专注于Exchange 2013 SP1的PowerShell管理的专业书籍。作者以其深厚的IT行业经验和对Microsoft UC解决方案演变的敏锐洞察，将焦点放在了如何利用PowerShell进行高效、灵活且版本独立的Exchange Server 2013管理上。该书内容覆盖广泛，分为多个章节，旨在帮助读者掌握核心技能。首先，第一章介绍了Exchange 2013 SP1的基础和特点，为后续深入学习奠定了基础。第二章详细讲解了Exchange Server 2013的安装过程，确保读者了解系统部署的关键步骤。第三章和第四章分别聚焦于Client Access Server和Mailbox Server，涵盖了它们的功能、配置以及通过PowerShell进行的操作，对于搭建和维护邮件环境至关重要。第五章深入探讨了高可用性和灾备恢复策略，让管理员了解如何通过PowerShell实现系统的稳定性。第六章关注邮件卫生（Message Hygiene），涉及垃圾邮件过滤、病毒防护等关键环节的PowerShell操作。第七章重点在于备份、恢复和灾难恢复技术，强调了在云环境中数据保护的重要性。第八章讨论了统一消息（Unified Messaging），阐述如何利用PowerShell管理语音邮件、自动回复等功能。第九章则是合规性的关键部分，讲解如何通过PowerShell满足法规要求和数据保护政策。最后，第十章深入探讨了安全领域，包括权限管理、加密和日志审计等，确保Exchange Server的安全性。随着云计算的发展，书中还特别提到了Office 365和Exchange Online，说明了PowerShell在云环境中与传统环境的异同及迁移策略。全书附有详尽的索引，方便读者快速查找所需信息。总体而言，《Pro Exchange 2013 SP1 PowerShell Administration》是一本紧跟技术潮流，实用性强的IT参考书籍，适合Exchange管理员、IT专业人士和PowerShell开发者阅读，有助于提升他们在Exchange Server 2013 SP1管理中的技能和效率。

CHAPTER 1 ■ INTRODUCTION TO EXCHANGE 2013 SP1

Warning ■ There’s very little safeguarding in this tool, so it’s easy to destroy critical parts in Active Directory when

you’re just clicking around!

The Active Directory Users and Computers (ADUC) MMC has a focus on the domain partition. In Windows

Server 2012, the Active Directory Administrative Center (ADAC) is the preferred tool to manage the Active Directory

environment. But using either tool is relatively safe, since the tool prevents messing around with objects in a way

that Active Directory does not like. The Active Directory Sites and Services (ADSS) MMC snap-in reads and writes

information from the configuration partition. All changes made here are visible to all domains in the forest; the same

is true for the Active Directory domains and trusts MMC snap-in.

A very powerful tool regarding Active Directory is the Schema MMC snap-in, which is usually run on the Domain

Controller that holds the schema master role. Using the Schema MMC snap-in, it is possible to make changes to the

Active Directory schema partition.

Warning ■ Only do this when you’re absolutely sure of what you’re doing, and when you have proper guidance—for

example, from Microsoft support. Changes made to Active Directory can be irreversible!

Figure 1-3. The Exchange information is stored in the configuration partition

CHAPTER 1 ■ INTRODUCTION TO EXCHANGE 2013 SP1

Domain Controllers also have tools like LDIFDE and CSVDE installed as part of the AD management tools. These

are command-line tools that can be used to import and export objects into or out of Active Directory. LDIFDE can also

be used to make changes to the Active Directory schema, and the Exchange 2013 setup application uses the LDIFDE

tool to configure Active Directory for use with Exchange 2013. These tools are beyond the scope of this book.

When promoting a server to a Domain Controller, or when installing the Remote Server Administration Tools

(RSAT) for Active Directory Directory Services (ADDS), the PowerShell Active Directory module is installed as well.

This module enables Active Directory functionality in PowerShell, making it possible to manage Active Directory

using PowerShell cmdlets.

Active Directory Permissions

There are three partitions in Active Directory. Each of these partitions has separate permissions requirements, and

not everybody has (full) access to these partitions. The following are the default administrator accounts or security

groups that have access to each partition.

•฀Schema Admins security group. The Schema Admins have full access to the schema

partition. The first administrator account is the top-level domain, which is the first domain

created. To make the necessary changes to the schema partition for installing Exchange

Server, the account that’s used needs to be a member of this security group. Any other domain

administrator in the forest is, by default, not a member of this group.

•฀Enterprise Admins security group. The Enterprise Admins have full access to the

configuration partition. Again, the first administrator account in the top-level domain is a

member of this group and as such can make changes to the configuration partition. Since

all Exchange Server configuration information is stored in the configuration partition, the

account used for installing Exchange Server needs to be a member of this group. Please note

that the Enterprise Admins security group does not have permission to make changes to the

schema partition.

•฀Domain Admins security group. The Domain Admins have full access to the domain

partition of the corresponding domain. If there are 60 domains in an Active Directory

environment, there are 60 domain partitions and thus 60 different Domain Admins security

groups. The first administrator account in the top-level domain is a member of the Domain

Admins security group in this top-level domain.

Why is this important to know? In the early days of Active Directory, Microsoft recommended using multiple

domains in an Active Directory forest, preferably with an empty root domain. This empty root domain is a domain

without any resources, and its primary purpose was for Active Directory management. All resources like servers,

computers, users, and groups were located in child domains. Needless to say, this has some implications for the use

of various administrator accounts. It is a delegated model, where the administrator accounts in the top-level domain

have control over all Active Directory domains, whereas the administrators in the other domains have administrative

rights only in their respective Active Directory domains. These other administrators do not have administrative

privileges in other domains, let alone permission to modify the configuration partition or the schema partition.

But things have changed, and although an empty root Active Directory domain environment can still be used, it

is no longer actively recommended. Mostly recommended these days is a “single forest, single domain” environment

unless there are strict legal requirements that dictate using another Active Directory model.

Chapter 10 will explain about security in great detail and will explore the various options available for delegated

administration and split permissions. But in short, the default administrator account that’s created in the top-level

Active Directory domain has enough permissions for installing Exchange 2013.

CHAPTER 1 ■ INTRODUCTION TO EXCHANGE 2013 SP1

Active Directory Sites

Active Directory sites play an important role in the larger Exchange 2013 deployments. As stated earlier, an Active

Directory site can be seen as a (physical) location with good internal network connectivity, high bandwidth, and low

latency—that is, a local LAN. An office or data center is typically a good candidate for an Active Directory site.

An organization can have multiple locations or multiple data centers, resulting in multiple Active Directory sites.

Sites are typically interconnected, with lower bandwidth, higher latency connections. An Active Directory site can also

have multiple domains, but at the same time an Active Directory domain can span multiple sites.

An Active Directory site also is a replication boundary. Domain Controllers in an Active Directory site replicate

their information almost immediately among Domain Controllers in the same site. If a new object is created, or if an

object is changed, the other Domain Controllers in that same site are notified immediately and the information is

replicated within seconds. All Domain Controllers in an Active Directory site should contain the same information.

Information exchanged between Domain Controllers in different Active Directory sites is replicated on a

timed schedule, defined by the administrator. A typical timeframe can be 15 minutes, but depending on the type

of connection or the bandwidth used to a particular location (you don’t want your replication traffic to interfere

with normal production bandwidth), it can take up to several hours. This means that when changes are made to

Active Directory—for example, when installing Exchange 2013—it can take a serious amount of time before all the

information is replicated across all the Domain Controllers and the new changes are visible to the entire organization.

Active Directory sites are created using the Active Directory Sites and Services MMC snap-in (see Figure

1-4).

The first step is to define the network subnets in the various locations in the snap-in, and then tie the actual Active

Directory site to the network subnet. For example, a data center in the Amsterdam site has IP subnet 10.38.96.0/24,

while the data center in the London site has IP subnet 10.38.97.0/24.

Figure 1-4. Two different subnets and sites, as shown in Active Directory Sites and Services

CHAPTER 1 ■ INTRODUCTION TO EXCHANGE 2013 SP1

A location like a data center in London or in Amsterdam (which corresponds with the Active Directory sites) can

be “Internet facing” or “non-Internet facing,” a descriptor that indicates whether the location has Internet connectivity

or not. This is important for Exchange 2013, since it determines how namespaces are configured and thus how

external clients are connected to their mailboxes in the different locations.

For example, the environment in Figure 1-4 has two Active Directory sites. If the data center in Amsterdam has

an Internet connection and the data center in London does not, all clients from the Internet are connected initially to

the Exchange 2013 servers in Amsterdam. If a user’s mailbox is located in London, the client request is proxied to the

Exchange 2013 servers in London.

But, if the data center in London also has an Internet connection and the Exchange servers are configured

accordingly, the London-based clients can access the Exchange 2013 servers from the Internet in Amsterdam, though

the request will be redirected to the Exchange 2013 servers in London and thus connect directly to the servers in London.

Also, the routing of SMTP messages through the Exchange organization is partly based on Active Directory sites.

In the example just given, it is not that difficult to do, but if you have an environment with dozens of Active Directory

sites, the SMTP routing will follow the Active Directory site structure unless otherwise configured.

Exchange 2013 Architecture

Exchange 2013 is using what they have termed “building blocks”; there are three such building blocks:

•฀Client Access server. The Client Access server (CAS) is the server where all clients connect.

The CAS consists of three parts: Client Access Front End (CAFE), Front End Transport Service

(FETS), and the UM Call Router (UMCR). The CAS performs authentication of a client request,

it locates the location of the client’s mailbox, and it proxies or redirects the client request to the

appropriate Mailbox server, where the actual client mailbox is located. The CAS in Exchange

2013 is sometimes also referred to as the “front end,” although according to the book, UMCR is

not officially a front end.

•฀Mailbox server. The Mailbox server is the server where the actual mailbox data is stored.

Clients do not access the Mailbox server directly; all requests are routed through the CAS. The

Mailbox server in Exchange 2013 is sometimes also referred to as the “back end.” Rendering

for clients like OWA, transport trancoding for SMTP, or voice processing for the UM role

always takes place on the Mailbox server.

•฀Edge Transport server. The Edge Transport server is used for message hygiene purposes

and acts as an SMTP gateway between your internal Exchange environment and the Internet.

When an Edge Transport server is used, all messages are routed through this server. Using an

Edge Transport server is not mandatory; there are lots of customers who have decided not to

use an Edge Transport server and use a third-party solution instead.

In Exchange Server 2007 and Exchange Server 2010, the Hub Transport server and the Unified Messaging server

were also dedicated server roles, next to the Client Access server and the Mailbox server. These four server roles were

tightly coupled and they used RPC for inter-server communication. Although this works fine, it presents some challenges

when it comes to an environment with multiple data centers and to site resiliency. One of the design goals for Exchange

2013 was to remove the tight coupling of the server roles and replace them with a more loosely coupled mechanism.

Hence, the four server roles are no longer available in separate server roles. The Client Access server continues

to exist as a dedicated server, but the other three server roles are incorporated into the Mailbox server role. When

installing the latter, the Hub Transport and Unified Messaging services are automatically installed as well. The

Mailbox server contains most of the business logic of Exchange 2013, and this is the server where all the processing

takes place for all mailboxes located on that Mailbox server. And since all business logic and processing takes place on

the Mailbox server, the Client Access server has a relatively light service role.

Microsoft has a nice poster, which is a large PDF ready for printing, showing the entire Exchange 2013

architecture; it is available at

http://bit.ly/ExPoster.

CHAPTER 1 ■ INTRODUCTION TO EXCHANGE 2013 SP1

The Client Access Server

The Client Access server (CAS) performs only authentication of a client request; after authentication, the client

request is proxied to the Mailbox server where the destination mailbox is located. The CAS in itself does not perform

any processing with respect to mail data. Compared to previous versions of Exchange Server, the Exchange 2013

CAS is basically a “thin” server. According to Microsoft, its connections are stateless (not clueless, though). But the

connections are not really stateless because the SSL connection is terminated at the CAS and then processed. If a CAS

goes offline, all connections are terminated and they have to be set up again on another CAS (which would not be

the case in a true stateless setup). The reason that Microsoft calls it “stateless” is that there’s no persistent storage on

Exchange 2013 CAS.

Unlike Exchange Server 2010 and Exchange Server 2007, the CAS no longer communicates with the Mailbox

server using RPC; the original client request is instead proxied to the Mailbox server using the same protocol as was

used when the connection reached the CAS server. If the initial request from the client to the Client Access server is

from Outlook Web App (so HTTPS), the protocol between the CAS and the Mailbox server is also HTTPS. Note that

the request from Internet to the CAS is using the regular port 443, but that the proxied request to the Mailbox server is

using port 444.

The same is true for other protocols like POP3, IMAP4, and SMTP. After the Exchange 2010 Client Access server

receives the request, the Client Access server proxies the request to the Exchange 2013 Mailbox server, as shown in

Figure

1-5. An exception is the SIP protocol. When a SIP request is received from a Lync server, the Client Access

server determines the appropriate Mailbox server, but instead of proxying the request, the Client Access server

redirects the request to the appropriate Mailbox server. From this moment on the Lync server communicates directly

with the Mailbox server. This is also clearly visible in Figure 1-5.

Figure 1-5. The front-end and back-end architecture in Exchange 2013

This architecture means that the actual Exchange 2013 servers are now loosely coupled, which offers huge

advantages when multiple offices or multiple data centers are used.

As stated before, the CAS is a “thin” server and does not store any information from the sessions, except for the

various protocol proxy logs like Autodiscover, Outlook Anywhere, or IIS logging. This is true for both regular client

requests and SMTP requests. SMTP requests are accepted by the Client Access Front End service on the CAS, but the

message itself is not stored or queued on the CAS, as it is on an Exchange 2010 Edge Transport server, for example.

The Front End Transport service that is responsible for handling SMTP messages on the CAS doesn’t store

messages on the server itself, but passes the SMTP messages directly to the appropriate Mailbox server where the

intended recipient’s mailbox is located, or to a down-level Hub Transport server if the recipient is located on a

down-level Mailbox server. The Front End Transport service does not inspect message content.

www.allitebooks.com

剩余627页未读，继续阅读

Shell2088

粉丝: 0
资源: 3

Pro Exchange 2013 SP1 PowerShell管理深度指南

ProExchange2013SP1PowerShellAdministrationFreePDFBooks.pdf 英文原版

Exchange Server 2013 PowerShell 管理与administration 第二版

ex-2013-ps-cookbook:Exchange 2013 PowerShell Cookbook 中的代码示例

Microsoft Exchange Server 2016 PowerShell Cookbook

powershell-scripts:解决ADExchange任务的Powershell脚本

Pro SharePoint 2013 Administration 2nd Edition

exchange powershell

Microsoft Exchange Server 2016 PowerShell Cookbook ( PDFDrive.com ).pdf

exchange remote powershell

pro-win-powershell:Hristo Deshev的“ Pro Windows PowerShell”源代码-windows source code

最新资源