Chapter 1. Exchange Server 2013 administration overview
Microsoft Exchange Server 2013 was a difficult product to work with as originally delivered, especially with regard to interoperability and update scenarios. Fortunately, a few things have happened that should markedly change your experience with Exchange Server 2013. First, Exchange Server 2013 has been updated significantly since its original release, and that’s fantastic news for anyone wanting to deploy this powerful messaging system. Second, I’ve been working with the product since the summer of 2012, and I’ve learned to zig and zag through the rough patches. In this chapter and the next, I’ll help you chart a course through the special challenges presented by Exchange Server 2013 and, in particular, the interoperability and update issues. Before we get to that, however, let’s begin at the beginning.
Although I discuss the impact of extensive architectural and administrative changes of Exchange 2013 throughout this and other chapters of this book, you need to know some of this information up front because it radically changes the way you implement and manage your Exchange organization. Why? With these changes, your Exchange 2013 organization will look very different than Microsoft Exchange Server 2010 or earlier organizations.
As you get started with Exchange Server 2013, you should concentrate on the following areas:
How Exchange Server 2013 architecture has changed
How Exchange Server 2013 works with your hardware
What versions and editions of Exchange Server 2013 are available and how they meet your needs
How Exchange Server 2013 works with Windows–based operating systems
How Exchange Server 2013 works with Active Directory
What administration tools are available
Getting started with Exchange 2013 and Exchange Online
You can implement Exchange services in several ways, including:
On-premises. With an on-premises implementation, you deploy Exchange server hardware on your network and manage all aspects of the implementation, including server configuration, organization configuration, and recipient configuration.
Online. With an online (or cloud-only) implementation, you rely on hardware and services provided by Microsoft. All aspects of the server configuration are managed by Microsoft. You manage the service-level settings, organization configuration, and recipient configuration.
Hybrid. With a hybrid implementation, you integrate on-premises and online implementations. The on-premises and Exchange Online organizations use a shared domain namespace, so mail is securely routed between them, and you can easily share data between the implementations.
When you use an online implementation, Microsoft manages the hardware configuration and ensures availability. Otherwise, you are responsible for any on-premises hardware.
Exchange Server 2013 builds on the radical changes in Exchange Server 2010 but is vastly different from Exchange Server 2010. Like Exchange Server 2010, Exchange Server 2013 does away with the concepts of storage groups, Local Continuous Replication (LCR), Single Copy Clusters (SCC), and clustered mailbox servers. This means that:
Databases are no longer associated with storage groups.
Database availability groups are used to group databases for high availability.
Databases are managed at the organization level instead of at the server level.
Exchange Server 2013 integrates high availability into the core architecture by enhancing aspects of Cluster Continuous Replication (CCR) and Standby Continuous Replication (SCR) and combining them into a single, high-availability solution for both on-site and off-site data replication. Exchange Server 2013 also provides for automatic failover and recovery without requiring clusters when you deploy multiple mailbox servers. Because of these changes, building a high-availability mailbox server solution doesn’t require cluster hardware or advanced cluster configuration. Instead, database availability groups provide the base component for high availability. Failover is automatic for mailbox databases that are part of the same database availability group.
The basic rules for database availability groups have not changed since implementation in Exchange Server 2010. Each mailbox server can have multiple data-bases, and each database can have as many as 16 copies. A single database availability group can have up to 16 mailbox servers that provide automatic database-level recovery. Any server in a database availability group can host a copy of a mailbox database from any other server in the database availability group.
This seamless high-availability functionality is possible because mailbox databases are disconnected from servers and the same globally unique identifier (GUID) is assigned to every copy of a mailbox database. Because there are no storage groups, continuous replication occurs at the database level. Transaction logs are replicated to each member of a database availability group that has a copy of a mailbox database and are replayed into the copy of the mailbox database. Failover can occur at either the database level or the server level.
Exchange Server 2013 has a significantly different architecture than its predecessors. While Exchange 2007 and Exchange 2010 components were split into different server roles for scaling out Exchange organizations, Exchange 2013 streamlines the server roles and architecture while still allowing you to fully scale Exchange organizations to meet the needs of enterprises of all sizes. Specifically, Exchange 2013 does not have separate server roles for Hub Transport servers or Unified Messaging servers. The related components are now part of the Mailbox Server role. This results in significant changes to mail flow and is one of many reasons the Information Store processes were rewritten in Exchange 2013. The new Information Store (Microsoft.Exchange.Store.Service.exe) is written in C# and is fully integrated with the Microsoft Exchange Replication service (MSExchangeRepl.exe) and the Microsoft Exchange DAG Management service (MSExchangeDagMgmt.exe). Additionally, each database now runs under its own process, which helps to isolate any issues with the Managed Store to a particular database.
Other than the Mailbox Sever role, the only other installable role for Exchange 2013 is the Client Access server role, which also can be installed on a Mailbox server. Every Exchange 2013 organization needs at least one Mailbox server and at least one Client Access server. While you can install both roles on a single server, you cannot later uninstall one role without uninstalling the other role. Further, Exchange 2013 as originally released doesn’t include an Edge Transport role or functionality (though this may be released in a future update to Exchange 2013). You can, however, use and deploy legacy Edge Transport servers, and I’ll discuss this in more detail in Chapter 2.
Although you can continue to use separate Client Access servers, the related architecture has changed considerably as well. The Mailbox server role includes the client access protocols and handles all activity for mailboxes. Client Access servers, on the other hand, are thin and stateless. They don’t queue any data. They don’t process or render data. They serve only to provide authentication, limited redirection, and proxy services.
These architecture changes mean that Exchange 2013 server roles are now loosely coupled rather than tightly coupled, which eliminates any previous session affinity requirements. The Mailbox server that stores the active database copy for a mailbox performs all the data processing, data rendering, and data transformation required. The Client Access server connects the client to the Mailbox server and performs authentication, redirection, and proxying only as needed. Because there is no required session affinity between the Mailbox server and the Client Access server, connections proxied by a Client Access server can be balanced using basic load-balancing technologies such as round robin Domain Name System (DNS) and least connection. Supported protocols for client connections include HTTP, POP, IMAP, RPC over HTTP, and SMTP. As RPC is no longer supported as a direct access protocol, all Outlook client connections must take place using RPC over HTTP.
It’s important to point out that Exchange 2013 is designed to work with Outlook 2007 and more recent versions and also continues to support Outlook Web App for mobile access. Rather than connecting to servers using Fully Qualified Domain Names as was done in the past, Outlook 2007 and more recent versions use Auto-discover to create connection points based on the domain portion of the user’s primary SMTP address and each mailbox’s Globally Unique Identifier (GUID).
The simplified architecture reduces the namespace requirements for Exchange site designs. If you’re coexisting with Exchange 2010 or you’re installing a new Exchange 2013 organization, you need only one namespace for client protocols and one namespace for Autodiscover. To continue to support SMTP, you also need an SMTP namespace.
For Exchange 2013, you’ll ideally want to deploy Mailbox servers on hardware that easily scales up while building Client Access servers with scaling out in mind.
Exchange Server 2013 and your hardware
Before you deploy Exchange Server 2013, you should carefully plan the messaging architecture. As part of your implementation planning, you need to look closely at preinstallation requirements and the hardware you will use. Exchange Server is a complex messaging platform with many components that work together to provide a comprehensive solution for routing, delivering, and accessing email messages, voice-mail messages, faxes, contacts, and calendar information.
Successful Exchange Server administration depends on three things:
Knowledgeable Exchange administrators
Strong architecture
Appropriate hardware
The first two ingredients are covered: you’re the administrator, you’re smart enough to buy this book to help you through the rough spots, and you’ve enlisted Exchange Online, Exchange Server 2013, or both to provide your high-performance messaging needs. This brings us to the issue of hardware. If you’re using Exchange Online, Microsoft provides the hardware. Otherwise, for on-premises implementations, Exchange Server 2013 should run on a system with adequate memory, processing speed, and disk space. You also need an appropriate data-protection and system-protection plan at the hardware level.
Exchange Server 2013 requires two different types of server hardware. You want to select hardware for Mailbox servers with scaling up in mind while selecting hardware for Client Access servers with scaling out in mind. Scaling up typically means adding additional or faster, better CPUs and memory to existing servers to meet capacity needs. Scaling out typically means adding additional servers to meet capacity needs.
Key guidelines for choosing hardware for Exchange Server are as follows:
Memory. The minimum random access memory (RAM) is 8 gigabytes (GB) for servers with both the Mailbox Server and Client Access Server roles, 8 GB for Mailbox servers, and 4 GB for Client Access servers. In most cases, you’ll want to have at least twice the recommended minimum amount of memory. The primary reason for this is performance. Most of the Mailbox server installations I run use 16 GB of RAM as a starting point, even in small installations. In multiple Exchange server installations, the Mailbox server should have at least 2 GB of RAM plus 5 megabytes (MB) of RAM per mailbox (with a minimum of 8 GB regardless). For all Exchange server configurations, the paging file should be at least equal to the amount of RAM in the server plus 10 MB.
CPU. Exchange Server 2013 runs on the x64 family of processors from AMD and Intel, including AMD64 and Intel 64. You can achieve significant performance improvements with a high level of processor cache. Look closely at the L1, L2, and L3 cache options available—a higher cache can yield much better performance overall. Look also at the speed of the front-side bus. The faster the bus speed, the faster the CPU can access memory.
Exchange Server 2013 runs only on 64-bit hardware. The primary advantages of 64-bit processors over 32-bit processors are related to memory limitations and data access. Because 64-bit processors can address more than 4 GB of memory at a time without physical address extension, they can store greater amounts of data in main memory, providing direct access to and faster processing of data. In addition, 64-bit processors can process data and execute instruction sets that are twice as large as 32-bit processors. Accessing 64 bits of data (versus 32 bits) offers a significant advantage when processing complex calculations that require a high level of precision.
SMP. Exchange Server 2013 supports symmetric multiprocessors, and you’ll see significant performance improvements if you use multiple CPUs—not just multiple cores in a single CPU. Although the clock speed of the CPU is important, so are the number of logical processor cores and the number of threads that can be simultaneously processed. That said, if Exchange Server is supporting a small organization with a single domain, one CPU with multiple cores may be enough. If the server supports a medium or large organization or handles mail for multiple domains, you will want to consider adding processors. When it comes to processor cores, I prefer two multicore processors to a single processor with the same number of cores, given current price and performance tradeoffs. An alternative is to distribute the workload across different servers based on where you locate resources.
Disk drives. The data storage capacity you need depends entirely on the number and size of the data that will pass through, be journaled on, or stored on the Exchange server. You need enough disk space to store all data and logs, plus workspace, system files, and virtual memory. Input/output (I/O) throughput is just as important as drive capacity. Rather than use one large drive, you should use several drives, which allows you to configure fault tolerance with RAID. As part of your hardware planning, it’s important to point out that Exchange 2013 supports multiple databases on the same volume, allowing you to have a mix of active and passive copies on a single volume. Keep in mind, however, the input/output per second (IOPS) capabilities for the underlying physical disks. Also note that even if you’ve been assigned multiple logical unit numbers (LUNs) for use from storage these different LUNs may be spread over the same physical disks.
Data protection. You can add protection against unexpected drive failures by using redundant storage. For the boot and system disks, use RAID 1 on internal drives. However, because of the new high-availability features, you might not want to use software RAID for Exchange data and logs. You also might not want to use expensive disk storage systems either. Instead, deploy multiple Exchange servers with the required server roles.
If you decide to use software-based redundant storage, you can use disk striping without parity or disk striping with parity for data volumes. Disk striping without parity offers good read/write performance, but a failed drive means that Exchange Server can’t continue operation on an affected database until the drive is replaced and data is restored from backup. Disk mirroring creates duplicate copies of data on separate drives; you can rebuild a mirrored unit to restore full operations and can continue operations if one of the drives fails. Disk striping with parity offers good protection against single drive failure, but it has poor write performance. For best performance and fault tolerance, RAID 10 (also referred to as RAID 0 + 1), which consists of disk mirroring and disk striping without parity, is also an option.
Uninterruptible power supply. Exchange Server 2013 is designed to maintain database integrity at all times and can recover information using transaction logs. This doesn’t protect the server hardware, however, from sudden power loss or power spikes, both of which can seriously damage hardware. To prevent this, connect your server to an uninterruptible power supply (UPS). A UPS gives you time to shut down the server or servers properly in the event of a power outage. Proper shutdown is especially important on servers using write-back caching controllers. These controllers temporarily store data in cache. Without proper shutdown, this data can be lost before it is written to disk. To prevent data loss, write-back caching controllers typically have batteries that help ensure that changes can be written to disk after the system comes back online.
If you follow these hardware guidelines and modify them for specific messaging roles, as discussed in the next section, you’ll be well on your way to success with Exchange Server 2013.
Real World
Mirroring can be implemented with software RAID 1 on Windows Server. As software-based RAID is implemented using dynamic disks, it’s important to note that beginning with Windows Server 2012 dynamic disks are being phased out in favor of Storage Spaces. However, for mirroring boot and system volumes on internal disks, Microsoft recommends continuing to use dynamic disks and RAID 1.
If you decide to use software-based redundant storage, remember that storage arrays typically already have an underlying redundant storage configuration and you might have to use a storage array–specific tool to help you distinguish between LUNs and the underlying physical disks. Herein, I focus on software-based redundancy implemented with RAID or Storage Spaces rather than the underlying hardware redundancy implemented in storage arrays.
Windows Server is transitioning to standards-based storage beginning with Windows Server 2012. This transition means several popular tools and favored features are being phased out. Officially, a tool or feature that is being phased out is referred to as deprecated. When Microsoft deprecates a tool or feature, it might not be in future releases of the operating system (while continuing to be available in current releases). Rather than not cover popular tools and features, I’ve chosen to discuss what is actually available in the current operating system, including both favored standbys and new options. One of these new options is Storage Spaces. With Storage Spaces:
Simple volumes can stretch across multiple disks, similar to disk striping with parity (RAID 0).
Mirrored volumes are mirrored across multiple disks. Although this is similar to disk mirroring (RAID 1), it is more sophisticated in that data is mirrored onto two or three disks at a time. If a storage space has two or three disks, you are fully protected against a single disk failure, and if a storage space has five or more disks, you are fully protected against two simultaneous disk failures.
Parity volumes use disk striping with parity. Although this is similar to RAID 5, it is more sophisticated in that there are more protections and efficiencies.
Exchange Server 2013 editions
Several editions of Exchange Server 2013 are available, including Exchange Server 2013 Standard and Exchange Server 2013 Enterprise. The various server editions support the same core features and administration tools, which means you can use the techniques discussed throughout this book regardless of which Exchange Server 2013 edition you are using. For reference, the specific feature differences between Standard Edition and Enterprise Edition are as follows:
Exchange Server 2013 Standard. Designed to provide essential messaging services for small to medium organizations and branch office locations. This server edition supports up to five databases.
Exchange Server 2013 Enterprise. Designed to provide essential messaging services for organizations with increased availability, reliability, and manageability needs. When you are running Cumulative Update 2 or later, this server edition supports up to 100 databases (including all active databases and copies of databases) on a particular server.
Note
Throughout this book, I refer to Exchange Server 2013 in different ways, and each has a different meaning. Typically, I refer to the software product as Exchange 2013 or as Exchange Server, which you can take to mean Microsoft Exchange Server 2013. When necessary, I use Exchange Server 2013 to draw attention to the fact that I am discussing a feature that’s new or has changed in the most recent version of the product. Each of these terms means essentially the same thing. If I refer to a previous version of Exchange Server, I always do so specifically, such as Exchange 2007 or Exchange 2010. Finally, I often use the term Exchange server (note the lowercase s in server) to refer to an actual server computer, as in “There are eight Exchange servers in this database availability group.”
Real World
Microsoft provides a single binary for x64 systems, and the same binary file is used for both the Standard and Enterprise editions. The license key provided during installation is what determines which edition is established.
You can use a valid product key to upgrade from a trial edition to the Standard edition or the Enterprise edition of Exchange Server 2013 without having to reinstall. Using a valid product key, you can also upgrade from the Standard to the Enterprise edition. You can also relicense an Exchange server by entering a new product key for the installed edition, which is useful if you accidentally used the same product key on multiple servers and want to correct the mistake.
There are several caveats. When you change the product key on a Mailbox server, you must restart the Microsoft Exchange Information Store service to apply the change. Additionally, you cannot use product keys to downgrade editions. To downgrade editions, you must uninstall Exchange Server and then reinstall it.
You can install Exchange Server 2013 on servers running full-server installations of Windows Server 2008 R2 as well as on a full-server installation of Windows Server 2012 RTM or R2. You cannot install Exchange 2013 on servers running server core or minimal server interface. With Windows Server 2008 R2, you must reinstall the server using the full installation option. With Windows Server 2012 RTM or R2, you must convert the server core or minimal server interface installation to a full installation by running the following command from an elevated PowerShell prompt:
Install-WindowsFeature Server-Gui-Mgmt-Infra, Server-Gui-Shell -Restart
The specific editions supported are as follows:
Windows Server 2012 RTM or R2 Standard or Datacenter
Windows Server 2008 R2 Standard with Service Pack 1 (SP1)
Windows Server 2008 R2 Enterprise with Service Pack 1 (SP1)
Windows Server 2008 R2 Datacenter RTM or later
A client accessing an Exchange server requires a Client Access License (CAL). With either Exchange Server edition, the client can use a Standard CAL, an Enterprise CAL, or both. The Standard CAL allows for the use of email, shared calendaring, contacts, task management, Microsoft Outlook Web App, and Exchange ActiveSync. The Enterprise CAL allows for the use of unified messaging, advanced mobile management, data loss prevention, and custom retention policies. An Enterprise CAL is sold as an add-on to the Standard CAL. A client must have one Standard CAL and one Enterprise CAL add-on to make full use of all Exchange Server features.
More Info
At the time of this writing, specific details on what’s included with each CAL are available at http://office.microsoft.com/en-us/exchange/microsoft-exchange-server-licensing-licensing-overview-FX103746915.aspx.
Beyond the editions and CALs, Exchange Server 2013 has several variants. Microsoft offers on-premises and online implementations of Exchange Server. An on-premises Exchange Server is one that you install in your organization. An online Exchange Server is delivered as a subscription service from Microsoft. In Exchange Server 2013, you can manage both on-premises and online implementations of Exchange Server using the same management tools. These implementations can be separate from each other or you can configure a hybrid installation that allows single sign-on and easy movement of mailboxes and database between on-premises and online implementations.
As a prerequisite for installing any server running any on-premises version of Exchange Server 2013, Active Directory must be at Windows Server 2003 forest functionality mode or higher. Additionally, the schema master for the Active Directory forest along with at least one global catalog server in each Active Directory site and at least one domain controller in each Active Directory site must be running one of the following operating systems:
Windows Server 2012 RTM or R2 Standard or Datacenter
Windows Server 2008 R2 Standard or Enterprise
Windows Server 2008 R2 Datacenter RTM or later
Windows Server 2008 Standard or Enterprise (32-bit or 64-bit)
Windows Server 2008 Datacenter RTM or later
Windows Server 2003 Standard Edition with Service Pack 2 (SP2) or later (32-bit or 64-bit)
Windows Server 2003 Enterprise Edition with SP2 or later (32-bit or 64-bit)
Note
Using Active Directory with Exchange Server 2013 is covered in more detail in the Exchange Server and Active Directory section of this chapter and the “Integrating Exchange Server roles with Active Directory” section of Chapter 2.
Additionally, Exchange Server 2013 supports IPv6 only when IPv4 is also installed. When you deploy IPv6, Exchange servers can send data to and receive data from devices, clients, and servers that use IPv6 addresses. Although you can disable IPv4 so that only IPv6 is enabled, Exchange still requires that IPv4 be installed. Further, the domain should be configured to use multiple-label DNS names, such as cpandl.com or adatum.local, rather than single-label DNS names, such as cpandl or adatum. However, single label names can be used.
You install Exchange 2013 using Exchange Setup. Exchange 2013 requires Microsoft .NET Framework version 4.5 and Windows Management Framework 3.0, which are included with Windows Server 2012 RTM or R2 (but not included with Windows Server 2008 R2). If needed, these components should be installed before you start Exchange Setup and are available at http://go.microsoft.com/fwlink/p/?LinkId=257868 and http://go.microsoft.com/fwlink/?LinkId=272757 respectively.
Other requirements depend on whether you are installing a Mailbox server or a Client Access server:
Mailbox servers require Microsoft Unified Communications Managed API 4.0, Core Runtime 64-bit (http://go.microsoft.com/fwlink/p/?linkId=258269), Microsoft Office 2010 Filter Pack 64-bit (http://go.microsoft.com/fwlink/p/?linkID=191548), and Microsoft Office 2010 Filter Pack SP1 64-bit (http://go.microsoft.com/fwlink/p/?LinkId=254043), which must be installed in the order shown.
Client Access servers require Microsoft Unified Communications Managed API 4.0, Core Runtime 64-bit (http://go.microsoft.com/fwlink/p/?linkId=258269).
If you don’t install these additional components prior to running Exchange Setup, the Readiness Checks will fail and links to these resources will be provided. If this happens, you can use the links provided to obtain and install the components and then simply tap or click Retry to have Setup perform the readiness checks again. Once these checks pass, you’ll be able to continue with the installation.
Exchange 2013 has a new set of management tools, including Exchange Admin Center, Exchange Management Shell, and Exchange Toolbox. When you install a Mailbox server or a Client Access server, the management tools are installed automatically. You can use Exchange Setup to install the management tools on domain-joined computers running 64-bit editions of Windows 7 SP1 and Windows 8 or later as well.
Although there are no prerequisites for Windows 8 or later, there are several prerequisites for Windows 7. Windows 7 computers must have Microsoft .NET Framework version 4.5 and Windows Management Framework 3.0 installed. You also must enable IIS 6 management compatibility by adding the IIS 6 Management Console, which is a feature that can be enabled using Control Panel. In Control Panel, select Program and then select Turn Windows Features On Or Off. In the Windows Features dialog box, under Internet Information Services, Web Management Tools, IIS 6 Management Compatibility, select IIS 6 Management Console, and then tap or click OK.
Exchange Server 2013 uses the Windows Installer (the Installer) and has a fully integrated installation process. This means you can configure Exchange Server 2013 much like you can any other application you install on the operating system. The installation can be performed from a command prompt as well.
Chapter 2 provides detailed instructions for installing Exchange Server 2013. You install Exchange 2013 only on domain-joined computers. Whether you use the Standard or Enterprise edition, you have similar options. You can install an internal messaging server by selecting the individual server roles to install and combining the Mailbox role and Client Access role as required for your environment. Generally, you will not want an internal Exchange server to also be configured as a domain controller with a global catalog.
When you start an installation, Setup checks the system configuration to determine the local time zone, the operating system, the logged-on user, and the status of the registry keys related to Exchange Server 2013. Installation will fail if you are trying to run Setup on an operating system that isn’t supported or if a required service pack is missing. You’ll also run into problems if you start Setup without using elevated administrator privileges.
After checking the system configuration, Setup allows you to check for updates to the installation process, provided the server has a connection to the Internet. Setup then checks available space on the %SystemDrive% to ensure a temporary folder under %SystemDrive%WindowsTempExchangeSetup can be used during the installation process. About 1.3 GB of space is needed for the working files.
When done copying its work files to the temporary folder, Setup tries to connect to a domain controller and validate the state of Active Directory. If Setup cannot find a domain controller or encounters other errors when validating Active Directory, the installation process will fail and you’ll see related errors during the readiness checks.
Important
By default, Setup chooses a domain controller in the local domain and site. In order to determine the domain information and contact a domain controller, the computer on which you are installing Exchange 2013 must be domain joined and have properly configured TCP/IP settings, and DNS name resolution must be properly configured in your organization. Because Active Directory site configuration also is important for installing Exchange 2013 and setting up an Exchange organization, ensure Active Directory sites and subnets are properly configured prior to installing Exchange 2013.
Once connected to a domain controller, Setup selects a global catalog server to work with and then looks for an Exchange Configuration container within Active Directory. Setup next determines the organization-level operations that need to be performed, which can include initializing Active Directory, updating Active Directory schema, establishing or updating the Exchange organization configuration, and updating the domain configuration.
As you continue through Setup, you’ll be able to select the server roles to install, the install location, and more. With the exception of the working files, which are copied to the temporary folder, no changes are made until the server passes the readiness checks. Normally, even when problems are encountered, Setup will continue all the way to the readiness checks. As part of the readiness checks, Setup checks for required components, such as those listed previously.
Other required components include Windows Features that Setup will install automatically if they aren’t already installed. These features include Desktop Experience, many components of IIS, Windows Identity Foundation, and the administrative tools for clustering. Although you can manually install these features, it’s a long list, and Setup will do the work for you if you let it.
Exchange 2013 includes the following anti-spam capabilities:
Sender filtering. Allows administrators to maintain a list of senders who are blocked from sending messages to the organization. Administrators can block individual senders by email address. Administrators also can block all senders from domains and subdomains.
Recipient filtering. Allows administrators to block message delivery to nonexistent recipients, distribution lists for internal users only, and mailboxes for internal use only. Exchange performs recipient lookups on incoming messages and block messages, which prevents certain types of attacks and malicious attempts at information discovery.
Sender ID verification. Verifies that incoming email messages are from the Internet domain from which they claim to come. Exchange verifies the sender ID by examining the sender’s IP address and comparing it to the related security record on the sender’s public DNS server.
Content filtering. Uses intelligent message filtering to scan message content and identify spam. Spam can be automatically deleted, quarantined, or filed as junk email.
Tip
Using the Exchange Server management tools, administrators can manage messages sent to the quarantine mailbox and take appropriate actions, such as deleting messages, flagging them as false positives, or allowing them to be delivered as junk email. Messages delivered as junk email are converted to plain text to strip out any potential viruses they might contain.
Sender reputation scoring. Helps to determine the relative trustworthiness of unknown senders through sender ID verification and by examining message content and sender behavior history. A sender can then be added temporarily to the Blocked Senders list.
The way you use these features will depend on the configuration of your Exchange organization. If you’ve deployed legacy Edge Transport servers, you enable and configure these features on your Edge Transport servers. Otherwise, you enable and configure these features on your Mailbox servers.
Exchange 2013 also has anti-malware capabilities, which are enabled by default. Malware scanning is performed on all messages at the server level, as messages are sent or received. When users open and read messages in their mailboxes, the messages they see have already been scanned. Exchange Server checks for updates to malware definitions every hour. Exchange downloads the malware engines and definitions using a TCP connection over port 80 from the Internet.
Tip
Normally, you’ll manually perform the first download of the anti-malware engine and definition updates prior to placing a server into production so you can verify that the initial process was successful and then configure default anti-malware policy prior to users having access to a server.
Although these anti-spam and anti-malware features are extensive, they are not comprehensive. For comprehensive protection, you can pair these features with a cloud-based service, such as Microsoft Exchange Online Protection. By combining the built-in anti-spam and anti-malware features with a cloud-based protection service you can set up substantial, layered protection. Additionally, if you use a third-party anti-malware solution for Exchange 2013, you can disable the built-in anti-malware filtering.
Exchange Server and Windows
When you install Exchange Server on a server operating system, Exchange Server makes extensive modifications to the environment. These modifications include new system services, integrated authentication, and new security groups.
Services for Exchange Server
When you install Exchange Server and Forefront Protection for Exchange Server on Windows, multiple services are installed and configured on the server. Table 1-1 provides a summary of key services, how they are used, and which server components they are associated with.
SERVICE NAME | DESCRIPTION |
IIS Admin | Enables the server to administer the IIS metabase. The IIS metabase stores configuration information for web applications used by Exchange. All roles need IIS for WinRM and remote Powershell. CAS needs IIS for Outlook Web App and Web services. |
Microsoft Exchange Active Directory Topology | Provides Active Directory topology information to Exchange services. If this service is stopped, most Exchange services will not be able to start. |
Microsoft Exchange Anti-Spam Update | Maintains the anti-spam data for Forefront Protection on an Exchange server. |
Microsoft Exchange DAG Management | Provides monitoring services for Database Availability Groups, including monitoring of storage management and database layout management. (Only applies to Exchange 2013 with CU2 or later.) |
Microsoft Exchange EdgeSync | Provides EdgeSync services between Mailbox and Edge servers. |
Microsoft Exchange Frontend Transport | Proxies inbound and outbound SMTP connections. |
Microsoft Exchange IMAP4 | Provides IMAP4 services to clients. |
Microsoft Exchange IMAP4 Backend | Provides IMAP4 services to mailboxes. |
Microsoft Exchange Information Store | Manages the Microsoft Exchange Information Store. This includes mailbox stores. |
Microsoft Exchange Mailbox Assistants | Manages assistants responsible for calendar updates, booking resources, and other mailbox processing. |
Microsoft Exchange Mailbox Replication | Enables online mailbox moves by processing mailbox move requests. |
Microsoft Exchange Mailbox Transport Delivery | Receives mail items from the Transport service and ensures they are processed and then delivered into mailbox. |
Microsoft Exchange Mailbox Transport Submission | Receives mail items being sent and ensures they are converted from MAPI to MIME and then submitted to the Transport service. |
Microsoft Exchange POP3 | Provides Post Office Protocol version 3 (POP3) services to clients. |
Microsoft Exchange POP3 Backend | Provides Post Office Protocol version 3 (POP3) services to mailboxes. |
Microsoft Exchange Protected Service Host | Provides a secure host for Exchange Server services. |
Microsoft Exchange Replication Service | Provides replication functionality used for continuous replication. |
Microsoft Exchange RPC Client Access | Manages client remote procedure call (RPC) connections for Exchange Server. |
Microsoft Exchange Search | Handles queries and controls indexing of mailboxes to improve search performance. |
Microsoft Exchange Server Extension for Windows Server Backup | Provides extensions for Windows Server Backup that allow you to back up and recover Exchange application data using Windows Server Backup. |
Microsoft Exchange Service Host | Provides a host for essential Exchange services. |
Microsoft Exchange Throttling | Provides throttling functions to limit the rate of user operations. |
Microsoft Exchange Transport | Provides mail transport for Exchange Server. |
Microsoft Exchange Transport Log Search | Provides search capability for Exchange transport log files. |
Microsoft Exchange Unified Messaging | Enables voice and fax messages to be stored in Exchange and gives users telephone access to email, voice mail, the calendar, contacts, or an automated attendant. |
Microsoft Exchange Unified Messaging Call Router | Provides capabilities necessary for routing calls. |
Secure Socket Tunneling Protocol Service | Provides support for Secure Socket Tunneling Protocol (SSTP) for securely connecting to remote computers. |
Web Management Service | Enables remote and delegated management for the web server, sites, and applications. |
Windows Remote Management Service | Implements the WS-Management protocol. Required for remote management using the Exchange console and Windows PowerShell. |
World Wide Web Publishing Services | Provides web connectivity and administration features for IIS. |
Exchange Server authentication and security
In Exchange Server 2013, email addresses, distribution groups, and other directory resources are stored in the directory database provided by Active Directory. Active Directory is a directory service running on Windows domain controllers. When there are multiple domain controllers, the controllers automatically replicate directory data with each other using a multimaster replication model. This model allows any domain controller to process directory changes and then replicate those changes to other domain controllers.
The first time you install Exchange Server 2013 in a Windows domain, the installation process updates and extends Active Directory to include objects and attributes used by Exchange Server 2013. Unlike earlier releases of Exchange Server, you do not use Active Directory Users And Computers to manage mailboxes, messaging features, messaging options, or email addresses associated with user accounts. You perform these tasks using the Exchange management tools.
Exchange Server 2013 fully supports the Windows Server security model and by default relies on this security mechanism to control access to directory resources. This means you can control access to mailboxes and membership in distribution groups and you can perform other Exchange security administration tasks through the standard Windows Server permissions set. For example, to add a user to a distribution group, you simply make the user a member of the distribution group in Active Directory Users And Computers.
Because Exchange Server uses Windows Server security, you can’t create a mailbox without first creating a user account that will use the mailbox. Every Exchange mailbox must be associated with a domain account—even those used by Exchange for general messaging tasks. In Exchange Admin Center, you can create a new user account as part of the process of creating a new mailbox.
You use Exchange Admin Center to manage Exchange servers according to their roles and the type of information you want to manage. You’ll learn more about this in Chapter 3, “Exchange Server 2013 administration essentials.”
Exchange Server security groups
Exchange Server 2013 uses predefined universal security groups to separate administration of Exchange permissions from administration of other permissions. When you add an administrator to one of these security groups, the administrator inherits the permissions permitted by that role.
The predefined security groups have permissions to manage the following types of Exchange data in Active Directory:
Organization configuration data. This type of data is not associated with a specific server and is used to manage databases, policies, address lists, and other types of organizational configuration details.
Server configuration data. This type of data is associated with a specific server and is used to manage the server’s messaging configuration.
Recipient configuration data. This type of data is associated with mailboxes, mail-enabled contacts, and distribution groups.
The predefined groups are as follows:
Compliance Management. Members of this group have permission to configure compliance settings.
Delegated Setup. Members of this group have permission to install and uninstall Exchange on provisioned servers.
Discovery Management. Members of this group can perform mailbox searches for data that meets specific criteria.
Exchange Servers. Members of this group are Exchange servers in the organization. This group allows Exchange servers to work together.
Exchange Trusted Subsystem. Members of this group are Exchange servers that run Exchange cmdlets using WinRM. Members of this group have permission to read and modify all Exchange configuration settings as well as user accounts and groups.
Exchange Windows Permissions. Members of this group are Exchange servers that run Exchange cmdlets using WinRM. Members of this group have permission to read and modify user accounts and groups.
Help Desk. Members of this group can view any property or object within the Exchange organization and have limited management permissions, including the right to change and reset passwords.
Hygiene Management. Members of this group can manage the anti-spam and antivirus features of Exchange.
Managed Availability Servers. Every Exchange 2013 server is a member of this group. Managed availability is new for Exchange 2013. It’s an internal process that provides native health monitoring and recovery for protocol processes to ensure availability of Exchange services. For more information, see Chapter 3.
Organization Management. Members of this group have full access to all Exchange properties and objects in the Exchange organization.
Public Folder Management. Members of this group can manage public folders and perform most public folder management operations.
Recipient Management. Members of this group have permissions to modify Exchange user attributes in Active Directory and perform most mailbox operations.
Records Management. Members of this group can manage compliance features, including retention policies, message classifications, and transport rules.
Server Management. Members of this group can manage all Exchange servers in the organization but do not have permission to perform global operations.
UM Management. Members of this group can manage all aspects of unified messaging, including Unified Messaging server configuration and unified messaging recipient configuration.
View-Only Organization Management. Members of this group have read-only access to the entire Exchange organization tree in the Active Directory configuration container and read-only access to all the Windows domain containers that have Exchange recipients.
Exchange Server and Active Directory
Exchange Server 2013 is tightly integrated with Active Directory. Not only does Exchange Server 2013 store information in Active Directory, but it also uses the Active Directory routing topology to determine how to route messages within the organization. Routing to and from the organization is handled using transport servers.
Understanding how Exchange stores information
Exchange stores four types of data in Active Directory: schema data (stored in the Schema partition), configuration data (stored in the Configuration partition), domain data (stored in the Domain partition), and application data (stored in application-specific partitions). In Active Directory, schema rules determine what types of objects are available and what attributes those objects have. When you install the first Exchange server in the forest, the Active Directory preparation process adds many Exchange-specific object classes and attributes to the Schema partition in Active Directory. This allows Exchange-specific objects, such as agents and connectors, to be created. It also allows you to extend existing objects, such as users and groups, with new attributes, such as attributes that allow user objects to be used for sending and receiving email. Every domain controller and global catalog server in the organization has a complete copy of the Schema partition.
During the installation of the first Exchange server in the forest, Exchange configuration information is generated and stored in Active Directory. Exchange configuration information, like other configuration information, is also stored in the Configuration partition. For Active Directory, the configuration information describes the structure of the directory, and the Configuration container includes all of the domains, trees, and forests, as well as the locations of domain controllers and global catalogs. For Exchange, the configuration information is used to describe the structure of the Exchange organization. The Configuration container includes lists of templates, policies, and other global organization–level details. Every domain controller and global catalog server in the organization has a complete copy of the Configuration partition.
In Active Directory, the Domain partition stores domain-specific objects, such as users and groups, and the stored values of attributes associated with those objects. As you create, modify, or delete objects, Exchange stores the details about those objects in the Domain partition. During the installation of the first Exchange server in the forest, Exchange objects are created in the current domain. Whenever you create new recipients or modify Exchange details, the related changes are reflected in the Domain partition as well. Every domain controller has a complete copy of the Domain partition for the domain for which it is authoritative. Every global catalog server in the forest maintains information about a subset of every Domain partition in the forest.
Understanding how Exchange routes messages
Within the organization, the Transport service on Mailbox servers uses the information about sites stored in Active Directory to determine how to route messages, and these servers can also route messages across site links. They do this by querying Active Directory about its site membership and the site membership of other servers, and then using the information they discover to route messages appropriately. Because of this, when you are deploying an Exchange Server 2013 organization, no additional configuration is required to establish routing in the Active Directory forest.
For mail delivery within the organization, additional routing configuration is necessary only in these specific scenarios:
If you deploy an Exchange Server 2013 organization with multiple forests, you must install Exchange Server 2013 in each forest and then connect the forests using appropriate cross-forest trusts. The trust allows users to see address and availability data across the forests.
In an Exchange Server 2013 organization, if you want direct mail flow between Exchange servers in different forests, you must configure SMTP send connectors and SMTP receive connectors on the Mailbox servers that should communicate directly with each other.
You can use two types of Mail Transport servers: Mailbox servers and legacy Edge Transport servers. You deploy Mailbox servers within the organization. The Transport service on Mailbox servers handles mail delivery and receipt of mail. Two new services are used to deliver mail items to and receive mail items from other servers:
Microsoft Exchange Mailbox Transport Delivery service. Handles inbound mail items. After receiving mail items for delivery to a mailbox on the current server, the service submits the mail items for processing and then delivers them into the appropriate mailbox database on the server.
Microsoft Exchange Mailbox Transport Submission service. Handles outbound mail items. After receiving mail items for submission, the service ensures messages are converted from MAPI to MIME and then passes them along to the Transport service. The Transport service then routes the mail items for delivery.
With Mailbox servers as your transports, no other special configuration is needed for message routing to external destinations. You must configure only the standard mail setup, which includes identifying DNS servers to use for lookups. With legacy Edge Transport servers, you can optimize mail routing and delivery by configuring one-way synchronization from the internal Mailbox servers to the perimeter network’s Edge Transport servers. Beyond this, no other special configuration is required for mail routing and delivery.
You deploy legacy Edge Transport servers in the organization’s perimeter network for added security. Typically a perimeter network is a secure network set up outside the organization’s private network. When you have Edge Transport servers, mail items from outside the organization are received first by the Edge transport servers, which can perform anti-malware and anti-spam checks before passing along mail items to internal Mailbox servers for delivery. Mail items for submission outside the organization are passed from internal Mailbox servers to Edge Transport servers which then submit the mail items for delivery outside the organization.
Exchange Online and Office 365
Exchange Online is a cloud-based service from Microsoft that allows you to implement an online or hybrid implementation of Exchange. Although Exchange Online can be your only solution for all your enterprise messaging needs, a hybrid implementation gives you an integrated online and on-premises solution.
You can get Exchange Online as a standalone service or as part of an Office 365 plan. Currently, Microsoft offers several Exchange Online plans, including a basic plan and an advanced plan. The key differences between the basic and advanced plans are the inclusion of in-place hold and data loss prevention options that may be needed to meet compliance and regulatory requirements. Both plans support Active Directory integration for single sign-on, synchronization with your on-premises Active Directory infrastructure, and creation of hybrid Exchange organizations.
Microsoft offers a variety of Office 365 plans. Some of these plans include access to Office Web Apps, the full desktop versions of Office, or both, as well as access to Exchange Online. You’ll likely want to use an Office 365 midsize business or enterprise plan. These plans include Active Directory integration, which is required if you want to create a hybrid Exchange organization.
Using the graphical administration tools
Exchange Server 2013 includes several types of tools for administration. You’ll use the graphical tools most frequently. They include Exchange Admin Center, Office Admin Center, and Exchange Toolbox.
Exchange Admin Center, shown in Figure 1-1, replaces Exchange Management Console. Although previous Exchange management tools were implemented using Microsoft Management Console (MMC), Exchange Admin Center is web based and works similar to Exchange Control Panel (ECP). However, Exchange Admin Center is much more advanced, and you’ll use this console for managing on-premises, online, and hybrid deployments of Exchange 2013.
Exchange Admin Center is a web application running on a Client Access server providing services for the Exchange organization. This application is installed automatically when you install a Client Access server. To manage Exchange installations from just about anywhere, you simply need to enter the Uniform Resource Locator (URL) path for the application in your browser’s Address field. You can then access Exchange Admin Center. For on-premises installations, the default internal URL for Exchange Admin Center is https://ClientAccessServerName/ecp and the external URL is https://yourserver.yourdomain.com/ecp. For example, if your Client Access server is named CASserver12, you’d enter https://casserver12/ecp as the URL for internal access.
When you are accessing an on-premises installation from within your organization (and behind your organization’s firewall), you use the internal URL. When you are accessing an on-premises installation outside your organization, you use the external URL. As discussed in Chapter 3, there are many ways to configure access to this app. You can change the default URL, restrict access to the internal URL only, and more.
Real World
If you deploy Exchange 2013 and Exchange 2010 in the same organization and your personal mailbox is on an Exchange 2010 Mailbox server, you’ll see the Exchange 2010 Exchange Control Panel by default. To access Exchange Admin Center, you must add the Exchange version to the URL.
You do this by appending ?ExchClientVer=15 to the internal or external URL. For example, if your external URL is https://mail.pocket-consultant.com, you’d enter https://mail.pocket-consultant.com/ecp?ExchClientVer=15 as the URL.
If your personal mailbox is on Exchange 2013 and you want to access the Exchange 2010 Exchange Control Panel, you can do this as well. In this case, you enter the client version as 14 rather than 15, as shown in this example: https://mail.pocket-consultant.com/ecp?ExchClientVer=14.
You manage Exchange Online using the cross-premises management options in Exchange Admin Center. With an online or hybrid installation, you’ll also be provided an access URL for Office Admin Center, such as https://portal.microsoftonline.com/admin/default.aspx. After you log in, you’ll see the Office Admin Center dashboard, shown in Figure 1-2.
From the Office Admin Center dashboard, you have full access to Exchange Online and Office 365 and can manage the related service-level settings. You’ll have options for configuring the Office tenant domain, managing subscriptions and licensing, viewing service health, getting Exchange usage reports, and more.
On any computer where you’ve installed the Exchange management tools, you’ll be able to access the Exchange Toolbox from Start. With Windows Server 2008 R2, select Start, choose All Programs, and then use the Microsoft Exchange Server 2013 menu. With Windows Server 2012 RTM or R2, you’ll find an Exchange Toolbox tile on the Start screen. Whether you are working with the Start menu or the Start screen, you can pin the Exchange Toolbox to the desktop taskbar by pressing and holding or right-clicking the related icon and then selecting Pin To Taskbar.
As Figure 1-3 shows, Exchange Toolbox has been streamlined considerably for Exchange 2013. The Toolbox provides access to a suite of related tools, including the following:
Details Templates Editor. Helps administrators customize client-side GUI presentation of object properties accessed through address lists. You can use this tool to customize the presentation of contacts, users, groups, public folders, and more in the client interface.
Remote Connectivity Analyzer. Allows administrators to perform connectivity tests for inbound email, ActiveSync, Exchange Web Services, Outlook Anywhere, and Outlook RPC over HTTP.
Queue Viewer. Allows administrators to track message queues and mail flow. Also allows administrators to manage message queuing and remove messages.
Other administration tools that you might want to use with Exchange Server are summarized in Table 1-2.
ADMINISTRATIVE TOOL | PURPOSE |
DNS | Manages the DNS service. |
Event Viewer | Manages events and logs. |
Failover Cluster Management | The Failover Cluster Management tools and the related command-line interface must be installed on your Exchange 2013 servers. This allows you to use scripts for managing availability groups. |
IIS Manager | Manages Web servers used by Exchange as well as the management service configuration. |
Server Manager | Provides setup and configuration options for the local server as well as options for managing roles, features, and related settings on remote servers. |
You access most of the tools listed in Table 1-2 from the Tools menu in Server Manager. Server Manager can be started by tapping or clicking the Server Manager icon in the taskbar. With Windows Server 2012 RTM or R2, you also can start Server Manager by typing Server Manager in the Apps Search box.
Using Exchange Management Shell
The graphical tools provide just about everything you need to work with Exchange organizations. Still, there are many times when you might want to work from the command line, especially if you want to automate installation, administration, or maintenance with scripts. To help with all your command-line needs, Exchange Server includes Exchange Management Shell.
Exchange Management Shell is an extension shell for Windows PowerShell that includes a wide array of built-in commands for working with Exchange Server. Windows PowerShell commands are referred to as cmdlets (pronounced commandlets) to differentiate these commands from less powerful commands built into the command prompt and from more full-featured utility programs that can be invoked at the command prompt.
Note
For ease of reading and reference, I’ll usually refer to command prompt commands, command shell cmdlets, and command-line invoked utilities simply as commands.
On any computer where you’ve installed the Exchange management tools, you’ll be able to access Exchange Management Shell from Start. With Windows Server 2008 R2, select Start, choose All Programs, and then use the Microsoft Exchange Server 2013 menu. With Windows Server 2012 RTM or R2, you’ll find an Exchange Management Shell tile on the Start screen. Whether you are working with the Start menu or the Start screen, you can pin Exchange Management Shell to the desktop taskbar by pressing and holding or right-clicking the related icon and then selecting Pin To Taskbar. Exchange Management Shell is shown in Figure 1-4.
Real World
Exchange Admin Center is a web-based management console that runs as an application on your Client Access servers. When you install the Client Access server role for Exchange 2013, the server is configured automatically with a Windows PowerShell gateway that acts as a proxy service. This proxy service allows you to run remote commands in web browsers and in remote sessions. Whenever you work with Exchange Admin Center or Exchange Management Shell, the commands are executed via this proxy—even if you log on locally. Thus, every time you work with Exchange Server, you are using a remote session.
When you log in to Exchange Admin Center, you are using the Default Web Site running on Internet Information Services (IIS) which processes your actions. Every command you perform in Exchange Admin Center is remotely executed via the Windows PowerShell gateway, as is any command you perform in Exchange Management Shell. Any task you can perform in Exchange Admin Center can be performed in Exchange Management Shell.
The basics of working with Exchange Management Shell are straightforward:
Type get-command to get a full list of all available cmdlets on the server.
Type get-excommand to get a full list of all Exchange-specific cmdlets available.
Type help cmdletName to get help information, where cmdletName is the name of the command you are looking up.
Type Update-ExchangeHelp to update the help files for Exchange-specific cmdlets (CU2 or later only).
Important
When you are working with Exchange Management Shell, the default recipient scope is set the same as your logon domain. If you are in a multi-domain environment and want to work with recipients throughout the Active Directory forest, make sure the Shell session has ViewEntireForest enabled. Enter Get-ADServerSettings to view the current Active Directory Server settings. Enter Set-ADServerSettings -ViewEntireForest $true to set the recipient scope to the entire forest.
You’ll find a comprehensive discussion of Exchange Management Shell and Windows PowerShell in Chapter 4 as well as examples of using cmdlets for Exchange Server management throughout the book. Although you can manage Exchange Online with PowerShell, you’ll need use special remoting techniques, which also are discussed in Chapter 4.
Whenever you remotely manage Exchange services using Powershell, you are relying on the Windows PowerShell remoting features. These features are supported by the WS-Management protocol and the Windows Remote Management (WinRM) service that implements WS-Management in Windows.
Windows Management Framework includes Windows PowerShell and WinRM. Computers running Windows 8 and later, as well as Windows Server 2012 and later, include Windows Management Framework 3.0 or later. You must install Windows Management Framework on computers running Windows 7 SP1 or later, as well as computers running Windows Server 2008 R2 SP1 or later. You can download the framework from http://go.microsoft.com/fwlink/p/?LinkId=272757.
With Windows Server 2012 RTM or R2, you can verify the availability of WinRM services and configure Windows PowerShell for remoting by following these steps:
Type PowerShell in the Apps Search box. To start Windows PowerShell as an administrator press and hold or right-click the Windows PowerShell shortcut and select Run As Administrator.
The WinRM service is configured for manual startup by default. You must change the startup type to Automatic and start the service on each computer you want to work with. At the PowerShell prompt, you can verify that the WinRM service is running by using the following command:
get-service winrm
As shown in the following example, the value of the Status property in the output should be Running:
Status Name DisplayName ------ ---- ----------- Running WinRM Windows Remote Management
If the service is stopped, enter the following command to start the service and configure it to start automatically in the future:
set-service –name winrm –startuptype automatic –status running
To configure Windows PowerShell for remoting, type the following command:
Enable-PSRemoting –force
Exchange 2013 is designed to be remotely managed from domain-joined computers. If your computer is connected to a public network, you need to disconnect from the public network, connect to a domain, and then repeat this step. If one or more of your computer’s connections has the Public connection type, but you are actually connected to a domain network, you need to change the network connection type in Network And Sharing Center and then repeat this step.
In many cases, you will be able to work with remote computers in other domains. However, if the remote computer is not in a trusted domain, the remote computer might not be able to authenticate your credentials. To enable authentication, you need to add the remote computer to the list of trusted hosts for the local computer in WinRM. To do so, type the following:
winrm s winrm/config/client '@{TrustedHosts="RemoteComputer"}'where RemoteComputer is the name of the remote computer, such as:
winrm s winrm/config/client '@{TrustedHosts="MailServer12"}'If you cannot connect to a remote host, verify that the service on the remote host is running and is accepting requests by running the following command on the remote host:
winrm quickconfig
This command analyzes and configures the WinRM service. If the WinRM service is set up correctly, you’ll see output similar to the following:
WinRM already is set up to receive requests on this machine. WinRM already is set up for remote management on this machine
If the WinRM service is not set up correctly, you’ll see errors and need to respond affirmatively to several prompts that allow you to automatically configure remote management. When this process completes, WinRM should be set up correctly.
Whenever you use Windows PowerShell remoting features, you must start Windows PowerShell as an administrator by pressing and holding or right-clicking the Windows PowerShell shortcut and selecting Run As Administrator. When starting Windows PowerShell from another program, such as the command prompt (cmd.exe), you must start that program as an administrator.