This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Library of Congress Cataloging-in-Publication data is on file.
Copy Editor
Printed in the United States of America
Bart Reed
First Printing: June 2011
Proofreader
Tonya Simpson
Leslie Joseph
Trademarks
Technical Editor
All terms mentioned in this book that are known to be trademarks or service marks have been appropriately capitalized. Que Publishing cannot attest to the accuracy of this information. Use of a term in this book should not be regarded as affecting the validity of any trademark or service mark.
Brien Posey Publishing Coordinator
Vanessa Evans Book Designer
Warning and Disclaimer
Gary Adair
Every effort has been made to make this book as complete and as accurate as possible, but no warranty or fitness is implied. The information provided is on an “as is” basis. The authors and the publisher shall have neither liability nor responsibility to any person or entity with respect to any loss or damages arising from the information contained in this book.
Compositor
Bulk Sales Pearson Certification offers excellent discounts on this book when ordered in quantity for bulk purchases or special sales. For more information, please contact U.S. Corporate and Government Sales 1-800-382-3419 [email protected] For sales outside the United States, please contact International Sales [email protected]
Bronkella Publishing
iii
Contents at a Glance
Introduction
xvi
Part I: An Overview of Windows PowerShell 2.0 for Exchange 2010 CHAPTER 1
New Features and the Exchange Management Shell
CHAPTER 2
Basic Techniques
1
11
Part II: Achieving a Comfort Level with PowerShell CHAPTER 3
Advanced Techniques
37
CHAPTER 4
Customizing the PowerShell Environment
51
Part III: PowerShell and the Exchange 2010 Deployment Process CHAPTER 5
Standard Deployments
65
CHAPTER 6
Disaster Recovery Deployments
83
Part IV: PowerShell and Recipient Objects CHAPTER 7
Working with Recipient Objects
93
CHAPTER 8
Bulk Management of Recipients
121
Part V: PowerShell and the Transport Roles Message Routing CHAPTER 9
The Hub Transport Role
CHAPTER 10 The Edge Transport Role
135 157
CHAPTER 11 Configuring Rules and Agents on Transport Servers
Part VI: PowerShell and the Client Access Server Role CHAPTER 12 CAS Services
179
CHAPTER 13 Working with Certificates
187
Part VII: PowerShell and the Mailbox Role CHAPTER 14 Mailbox Servers and Databases CHAPTER 15 Working with Mailboxes
193
203
CHAPTER 16 Using the Recovery Database (RDB)
213
169
iv
Part VIII: PowerShell and the Unified Messaging Role CHAPTER 17 Working with Unified Messaging (UM) Role Objects CHAPTER 18 Managing Unified Messaging (UM) Users
219
229
Part IX: PowerShell and Message Routing CHAPTER 19 Exchange Server 2010 Message Routing
239
CHAPTER 20 Integrating Exchange Server 2010 into an Existing Exchange
Server 2003 Environment
249
Part X: PowerShell and High Availability in Exchange 2010 CHAPTER 21 Database Availability Groups (DAGs) CHAPTER 22 Mailbox Database Copies
255
269
CHAPTER 23 Using DAG to Mitigate Failures
277
CHAPTER 24 Monitoring Highly Available Databases
289
Part XI: PowerShell and Public Folders CHAPTER 25 Public Folder Database Management CHAPTER 26 Managing Public Folders CHAPTER 27 Public Folder Permissions
297
303 309
Part XII: Troubleshoot Exchange Server 2010 Using PowerShell CHAPTER 28 Troubleshooting with the Test Cmdlets CHAPTER 29 Event Logging with PowerShell
315
325
Part XIII: PowerShell and Automating Exchange Server 2010 Administration CHAPTER 30 Using and Finding Scripts to Automate
331
Part XIV: Monitoring Role-Based Access Control (RBAC) Permissions, Mailbox Audit Logging, and Reporting with PowerShell in Exchange Server 2010 CHAPTER 31 Configuring Role-Based Access Control (RBAC)
Permissions
339
CHAPTER 32 Using Mailbox Audit Logging to Monitor Exchange Server CHAPTER 33 Reporting and Other Useful Cmdlets
355
APPENDIX A Lab Environment Used for This Book
367
APPENDIX B Create Your Own Journal Here
373
347
Table of Contents Introduction
xvi
Part I: An Overview of Windows PowerShell 2.0 for Exchange 2010 CHAPTER 1
New Features and the Exchange Management Shell What’s New in PowerShell 2.0 What Is a Cmdlet?
1
4
The Exchange Management Shell CHAPTER 2
Basic Techniques Using the GUI
1
6
11
11
Understanding the Basic Syntax of a cmdlet
12
Basic Syntax: Some Common Cmdlets Using the Get Verb Basic Syntax: Some Common Parameters Finding the Right Cmdlet
27
31
Finding Help for the Right Cmdlet
32
What’s Included in Each Version of Help Using the Tab Completion Feature
33
34
Part II: Achieving a Comfort Level with PowerShell CHAPTER 3
Advanced Techniques
37
Working with Pipelines
37
Running Programs
41
Creating and Running Scripts
42
Registry Modifications with PowerShell Understanding Quotes CHAPTER 4
48
48
Customizing the PowerShell Environment Creating and Using PowerShell Profiles Using Built-in Aliases
56
Working with User-Defined Aliases Filtering Output
59
Formatting Output
60
57
51
51
16
vi
Contents
Part III: PowerShell and the Exchange 2010 Deployment Process CHAPTER 5
Standard Deployments
65
Deploying Prerequisites for All Versions of Exchange Server 2010 on Windows Server 2008 Operating Systems 65 Deploying Prerequisites for Exchange Server 2010 RTM (Release-toManufacturing) on Windows Server 2008 SP2 66 Deploying Prerequisites for Exchange Server 2010 RTM on Windows Server 2008 SP2 67 Deploying Prerequisites for Exchange Server 2010 RTM on Windows Server 2008 R2 69 Deploying Prerequisites for Exchange Server 2010 SP1 on Windows Server 2008 R2 72 Setup Options for Exchange Server 2010 RTM
74
Upgrading from Exchange Server 2010 RTM to SP1 Using the Exchange 2010 Deployment Assistant CHAPTER 6
Disaster Recovery Deployments
78
80
83
Recovering from a Single Role Failure
83
Recovering from a Multiple-Role Failure on the Same Server
85
Recovering from a Database Availability Group (DAG) Member Server Failure 89 Part IV: PowerShell and Recipient Objects CHAPTER 7
Working with Recipient Objects
93
Identifying the Exchange 2010 Recipient Types Creating and Managing a User Mailbox
101
Creating and Managing a Mail-Enabled User
104
Creating and Managing a Mail-Enabled Contact Creating and Managing Resource Mailboxes Working with Distribution Groups Converting Recipient Types
106
108
109
112
Creating and Managing Email Address Policies Creating and Managing Address Lists CHAPTER 8
93
Bulk Management of Recipients Creating Multiple Recipients Modifying Multiple Recipients
113
116
121
121 129
Reconnecting Multiple Disconnected Mailboxes
133
Contents
Part V: PowerShell and the Transport Roles Message Routing CHAPTER 9
The Hub Transport Role
135
Configuring Accepted and Remote Domains Get-AcceptedDomain New-AcceptedDomain
136
Set-AcceptedDomain
137
Remove-AcceptedDomain Get-RemoteDomain
135
136
137
138
New-RemoteDomain Set-RemoteDomain
138 138
Managing Email Address Policies
141
Working with SMTP Connectors and Other Transport Objects Send Connectors
144
Receive Connectors
148
Other Transport Cmdlets
151
Working with Routing Group Connectors Managing Transport Queues
154
CHAPTER 10 The Edge Transport Role
157
Creating an Edge Subscription Edge Synchronization
157
159
Cloning an Edge Transport Address Rewriting
152
161
165
CHAPTER 11 Configuring Rules and Agents on Transport Servers
Transport Rules and Transport Agents Transport Rules Transport Agents
Journaling Agents Anti-Spam Agents
169
169 173
Journaling Rules and Journaling Agents Journaling Rules
169
174
174 176
177
Part VI: PowerShell and the Client Access Server Role CHAPTER 12 CAS Services
179
Configuring Outlook Access
179
Enabling and Configuring Outlook Anywhere Access
180
144
vii
viii
Contents
Enabling and Configuring OWA Access Configuring POP3 and IMAP4
181
182
Configuring the Autodiscover Service
183
Configuring the Offline Address Book (OAB) CHAPTER 13 Working with Certificates
Types of Certificates
184
187
187
Generating a Certificate Request Importing the Certificate Enabling the Certificate
187
191 192
Part VII: PowerShell and the Mailbox Role CHAPTER 14 Mailbox Servers and Databases
193
Configuring the Properties of a Mailbox Server Creating and Mounting a New Database Managing an Existing Database
196
Removing an Existing Database
201
CHAPTER 15 Working with Mailboxes
Exporting a Mailbox
203
Importing a Mailbox
207
Moving an Online Mailbox
203
208
Running the Clean-MailboxDatabase Cmdlet CHAPTER 16 Using the Recovery Database (RDB)
Creating the Recovery Database (RDB) Restoring a Database to the RDB Removing the RDB
193
194
211
213 213
216
218
Part VIII: PowerShell and the Unified Messaging Role CHAPTER 17 Working with Unified Messaging (UM) Role Objects
Configuring the Properties of a UM Server Creating and Managing Dial Plans
219
220
Creating and Managing UM IP Gateways Creating and Managing Hunt Groups
223
224
Creating and Managing UM Mailbox Policies
225
Monitoring and Troubleshooting a UM Server
226
219
Contents
CHAPTER 18 Managing Unified Messaging (UM) Users
Managing the UM Auto Attendant
229
229
Working with Call Answering Rules Exporting UM Call Data Records
234
234
Working with UM-Enabled Mailboxes
235
Part IX: PowerShell and Message Routing CHAPTER 19 Exchange Server 2010 Message Routing
Using Default Message Routing Using Exchange Hub Sites
239
239
241
Using Exchange-Specific Costs on Site Links Tracking Messages with PowerShell
242
246
CHAPTER 20 Integrating Exchange Server 2010 into an Existing Exchange
Server 2003 Environment
249
Configuring Routing with Exchange Server 2003
249
Suppressing Link State Updates On Exchange 2003 Bridgehead Servers 253 Part X: PowerShell and High Availability in Exchange 2010 CHAPTER 21 Database Availability Groups (DAGs)
Creating and Configuring a DAG
255
Adding or Removing a DAG Member Recovering a Failed DAG Member
255
260
263
Creating and Configuring a DAG Network Removing a DAG
265
268
CHAPTER 22 Mailbox Database Copies
269
Adding and Configuring a Mailbox Database Copy
269
Moving the Active Mailbox Database Copy to a New Location Suspending or Resuming a Mailbox Database Copy Updating a Mailbox Database Copy
276
Removing a Copy of a Mailbox Database CHAPTER 23 Using DAG to Mitigate Failures
272
274
276
277
Activating a Mailbox Database Copy on Another DAG Member 277 Activating a Lagged Mailbox Database Copy on Another DAG Member 279
ix
x
Contents
Switching Over to Another DAG Member Switching Over to Another Datacenter
Monitoring Using the Exchange Management Console Monitoring Using PowerShell Cmdlets Monitoring Using Event Viewer
285
289
290
291
Monitoring Using PowerShell Scripts
293
Part XI: PowerShell and Public Folders CHAPTER 25 Public Folder Database Management
Installing Public Folders
297
297
Creating a Public Folder Database
298
Configuring a Public Folder Database Removing a Public Folder Database CHAPTER 26 Managing Public Folders
299 301
303
Assigning a Default Public Folder Database to a Mailbox Database 303 Creating and Managing Public Folders Replicating Public Folders
307
Removing a Public Folder
308
CHAPTER 27 Public Folder Permissions
305
309
Adding Administrative Permissions to the Folder Structure Controlling Top-level Public Folders
312
Setting Client Permissions to Public Folder Content
312
Part XII: Troubleshoot Exchange Server 2010 Using PowerShell CHAPTER 28 Troubleshooting with the Test Cmdlets
Using Test Cmdlets for All Roles
315
315
Using Test Cmdlets for the Mailbox Role Using Test Cmdlets for the Transport Roles
317 318
Using Test Cmdlets for the Client Access Server Role Using Test Cmdlets for the Unified Messaging Role Using Test Cmdlets for Client Connectivity
321
Using Helpful Non-Exchange Test Cmdlets
323
320 321
309
Contents
CHAPTER 29 Event Logging with PowerShell
xi
325
Retrieving Events with Get-EventLog Setting Diagnostic Event Log Levels
325 328
Part XIII: PowerShell and Automating Exchange Server 2010 Administration CHAPTER 30 Using and Finding Scripts to Automate
331
Using Scripts to Automate Tasks in PowerShell
331
Finding Scripts to Automate Tasks in PowerShell
335
Part XIV: Monitoring Role-Based Access Control (RBAC) Permissions, Mailbox Audit Logging, and Reporting with PowerShell in Exchange Server 2010 CHAPTER 31 Configuring Role-Based Access Control (RBAC) Permissions
Creating and Managing a Management Role Group Adding Members to the Management Role Group
339
339 341
Retrieving Information about Role Groups and Role Group Members 343 Setting and Viewing Management Scopes
345
CHAPTER 32 Using Mailbox Audit Logging to Monitor Exchange Server
Enabling Mailbox Audit Logging
347
347
Initiating Administrative Actions to Test Mailbox Audit Logging Initiating a Search of the Mailbox Audit Log CHAPTER 33 Reporting and Other Useful Cmdlets
349
352
355
Obtaining Information about a Mailbox with Get-MailboxStatistics 355 Retrieving Logon Information about Currently Active Sessions with Get-LogonStatistics 359 Using Other Useful Cmdlets
361
APPENDIX A Lab Environment Used for This Book
367
The Platform on Which the Virtual Machines Ran During the Writing of This Book 367 The Lab Environment Used in this Book
368
Creating Test Users and Mailboxes for the Lab Environment Conclusion
372
APPENDIX B Create Your Own Journal Here
373
369
xii
About the Author
About the Author Richard Robb has been a respected technical trainer and messaging field consultant on Microsoft Exchange Server for the past 13 years after changing careers. In his “second career,” Mr. Robb has earned quite a number of technical certifications, including Microsoft Certified Trainer (MCT), Microsoft Certified IT Professional (MCITP) for Exchange Server 2010, as well as Exchange Server 2007. He is also certified on Exchange Server 2003. He has worked with every version of Exchange Server back to Exchange 5.5 and also has experience with other messaging systems, such as Lotus Notes. In addition to his Exchange certifications, Mr. Robb has earned other certifications, such as Microsoft Certified IT Professional (MCITP) for Windows Server 2008, Microsoft Certified Systems Engineer (MCSE) on Windows Server 2003, 2000, and NT 4.0, Microsoft Certified Systems Administrator (MCSA) on Windows Server 2003 and 2000, as well as Microsoft Certified Desktop Support Technician (MCDST). He also holds Certified Novell Engineer (CNE) and A+ certifications and has delivered classes for many top Fortune 500 companies as well as many governmental agencies in the United States and Canada. Mr. Robb currently works as an independent contractor providing Exchange Server training and consulting throughout the United States and Canada. He has also been part owner of a computer consulting company and part owner of a Microsoft and IBM Lotus training company with a six-room training center in southeastern Pennsylvania. A former restaurant general manager of a 400-seat full-service seafood restaurant, Mr. Robb was at the forefront of the move from simple point-of-sale cash registers to network operation systems in the food service industry and spearheaded the move to using computers in the restaurant for everything from cash registers to databases for managing inventory. Richard Robb, an accomplished computer hobbyist in the early 1980s, united his keen interest of computers with a methodical research into the exploding IT industry and made the move from food service to information technology full time. He worked as a field consultant for some time after leaving the restaurant industry, but when the opportunity arose to instruct, it coupled two things that he loves to do: work with computers and teach. Mr. Robb is a graduate of Gettysburg College in Gettysburg, Pennsylvania, with a dual major in Psychology and Economics. He also holds a Bachelor of Arts degree. Mr. Robb also authored the book MCITP Guide to Microsoft Windows Server 2008, Enterprise Administration, a lab guide for hands-on exploration of Windows Server 2008, with a focus on studying for and passing Microsoft Certification Exam 70-647. Darril Gibson is the CEO of Security Consulting and Training, LLC. He regularly teaches, writes, and consults on a wide variety of security and technical topics. He has been a Microsoft Certified Trainer for more than 10 years and holds several certifications, including MCSE (NT 4.0, 2000, 2003), MCDBA (SQL Server), MCITP (Windows 7, Server 2008, SQL Server), ITIL v3, Security+, and CISSP. He has authored, coauthored, or contributed to more than a dozen books. You can view a listing of most of his current books on Amazon (http://amzn.to/bL0Obo).
About the Technical Editor
xiii
About the Series Editor Scott Empson is the associate chair of the Bachelor of Applied Information Systems Technology degree program at the Northern Alberta Institute of Technology in Edmonton, Alberta, Canada, where he teaches Cisco routing, switching, and network design courses. Scott is also the program coordinator of the Cisco Networking Academy Program at NAIT, a Regional Academy covering Central and Northern Alberta. He has earned three undergraduate degrees: a Bachelor of Arts, with a major in English; a Bachelor of Education, again with a major in English/Language Arts; and a Bachelor of Applied Information Systems Technology, with a major in Network Management. Scott also has a Masters of Education degree from the University of Portland. He holds several industry certifications, including CCNP, CCAI, Network+, and C|EH. Scott is the series creator and one of the authors of the Portable Command Guide Series. Portable Command Guides are filled with valuable, easy-to-access information to quickly refresh your memory. Each guide is portable enough for use whether you’re in the server room or the equipment closet.
About the Technical Editor Brien Posey is a seven-time Microsoft MVP (Windows, IIS, Exchange Server, and File Systems/Storage) with more than two decades of IT experience. As a freelance technical writer, Brien has published many thousands of articles and written or contributed to dozens of books on a variety of IT topics. Before going freelance, Brien served as CIO for a national chain of hospitals and healthcare facilities. He has also served as a network administrator for some of the nation’s largest insurance companies and for the Department of Defense at Fort Knox.
xiv
Acknowledgments
Dedication From Richard Robb I am fortunate to have three very strong people supporting me in my ventures during my lifetime. These three people are my wife of 30 years (Janet), my daughter (Jeanna), and my mother (Winnie). During the writing of this book, my mother, Edwina A. (Winnie) Robb, passed away after a short illness. I’m thankful to have had her for so many years, but I still miss her very much. She was 91 years old. I love you, Mom! From Darril Gibson To my wife, Nimfa, of more than 18 years. Thanks for helping me find success and joy in so much that I do.
Acknowledgments From Richard Robb I was amazed when I turned in each chapter. My editor, Jeff Riley, and Darril Gibson were able to take my work and make it look so much more professional in the finished product. Their comments were invaluable. I am thankful that Darril saw something in me that made him feel I could be an author. Without Darril, I would not have written this book. I would also like to mention Scott Empson. He wrote the first book in this series, and it is the prototype for this book and others in the series. It took me a while to understand that this is not a book that someone might pick up and read from cover to cover as they might a novel, but once I got it, the format made so much more sense. From Darril Gibson Richard Robb is the real Exchange expert behind the entire contents of this book. His invaluable real-world experience and depth of knowledge from teaching Exchange so often over the years brought every page within this book to life. I am grateful to have been able to work with him again.
We Want to Hear from You!
xv
We Want to Hear from You! As the reader of this book, you are our most important critic and commentator. We value your opinion and want to know what we’re doing right, what we could do better, what areas you’d like to see us publish in, and any other words of wisdom you’re willing to pass our way. As an associate publisher for Pearson Certification, I welcome your comments. You can email or write me directly to let me know what you did or didn’t like about this book— as well as what we can do to make our books better. Please note that I cannot help you with technical problems related to the topic of this book. We do have a User Services group, however, where I will forward specific technical questions related to the book. When you write, please be sure to include this book’s title and author as well as your name, email address, and phone number. I will carefully review your comments and share them with the author and editors who worked on the book.
David Dusthimer Associate Publisher Pearson IT Certification 800 East 96th Street Indianapolis, IN 46240 USA
Reader Services Visit our website and register this book at pearsonitcertification.com for convenient access to any updates, downloads, or errata that might be available for this book.
xvi
Introduction
Introduction Thanks for buying the Exchange Server 2010 Portable Command Guide. This book joins the other books in the Portable Command Guide series. Before you delve into this book and start typing cmdlets, I would like to give credit to Scott Empson, who created the first book in the series, as well as Darril Gibson, who brought the series from its Cisco roots over to include the Microsoft product line. Like the other books in this series, this book doesn’t attempt to teach every concept or explain every detail. It is assumed that you already understand the basic concepts. Instead, the goal is to provide numerous examples of tasks that can be performed in Exchange Management Shell that allow you to view the syntax of cmdlets as well as to provide information to help you remember how to customize cmdlets for other purposes not directly addressed in this book. Hopefully, you will find the compact size of the Portable Command Guide to be convenient, so you are able to keep the book with you. A number of books have been published on Windows PowerShell, but very few of these are dedicated to Exchange Server 2010. I am an Exchange administrator. I am not a developer. Yet, I have found an increasing need to improve my development skills in order to be an effective administrator—first with Exchange Server 2007, then with Windows Server 2008, and now with Exchange Server 2010. Fortunately, with Windows PowerShell and Exchange Management Shell, I can do so without having to learn a complicated language and extensive developmental concepts—something I really have no desire to do as an administrator. With just a simple verb-noun combination, I can achieve fantastic things in the Exchange organization and still be able to sleep at night without pieces of code swirling around in my head as I dream. Many PowerShell books are written for developers by developers. I have long been searching for a book written for administrators by an administrator. So, I was quite excited when I was approached with the opportunity to write just such a book for Exchange Server 2010. This book is designed to be several things wrapped into one: ■
First, it is designed to be a quick reference guide for all those little cmdlet “gems” you just know are out there, but can never seem to find when you need them. (For example, you need a quick-yet-customizable cmdlet to produce only the relevant information for certain mailboxes that exist in your organization.)
■
Second, as you examine the five Exchange Server 2010 roles, this book provides a fairly complete list of the common cmdlets used to manage and work with those roles. I will attempt to analyze the syntax to make it more understandable for you and point out the common options available for those cmdlets.
■
Third, if you plan to take one or both of the Exchange Server 2010 Microsoft certification exams (70-662 and 70-663), you will likely want a study guide with the relevant cmdlets you might expect to see on those exams, along with a brief description of the cmdlets and the possible options for their use.
Introduction
xvii
If you’re like I was a few years ago, you might be asking yourself, “Why the command line again?” This is a good question to ask. It’s very relevant, too, because quite a few Exchange 2003 administrators are now making the leap to Exchange Server 2010 and to Windows PowerShell. There are several reasons to use a command-line utility. Let’s examine just one scenario to illustrate how the command-line interface (and specifically Exchange Management Shell) can help us do something that might have been tedious, difficult, or simply impossible to do in Exchange Management Console. Our company, a very large organization, has just acquired a small company that has 33 users. We need the 33 new mailboxes to receive a specific policy. However, there are 33,000 mailboxes in the organization, and the new users are not organized by subsidiaries. This means that some users are in the Managers OU in Active Directory and others are in regional OUs. Therefore, the 33 mailboxes do not have any attribute in common that is displayed in Exchange Management Console. However, because a Company attribute is designated in the AD, if we used it to represent the subsidiaries, we can leverage that attribute in Exchange Management Shell, as shown next. PS C:\Users\Administrator>Get-User -Filter {Company -eq "RomacSign"} | Enable-Mailbox "AssemblyDB"
I know. We’ve not even looked at the makeup of a cmdlet yet and I throw that at you! However, think of it this way: In that one short line of typed code, we have created 33 mailboxes for the new users who have been recently migrated into our Active Directory, and we have done so quite easily and economically. Without Exchange Management Shell, we would have had to find the 33 users who needed mailboxes (which could be quite tedious) and then manually apply the change. Within a short time, the preceding cmdlet will not only make sense to you, but you will be writing ones much like it with little effort. So, dive right in and start working with Exchange Management Shell, and very soon you will be amazed with all the tasks that are not only possible, but that are achievable in just a short period of time. One other point I’d like to make is that many of the examples in the book have values for parameters. These match the design documented in the appendix. To help you distinguish what part of the command you have to enter exactly as shown, and what part of the command is a parameter you need to provide, the parameters are underlined in the book. For example, in the previous command RomacSign and AssemblyDB are both underlined to let you know they are parameters that you’ll need to change to match your organization.
This page intentionally left blank
CHAPTER 1
New Features and the Exchange Management Shell
This chapter provides information and commands concerning the following topics: ■
What’s new in PowerShell 2.0
■
What is a cmdlet?
■
The Exchange Management Shell
In this chapter, you look at new features in PowerShell 2.0. Then, in preparation for a look at the Exchange Management Shell (EMS), you briefly review the makeup of a cmdlet. Finally, you investigate the Exchange Management Shell.
What’s New in PowerShell 2.0 Microsoft Windows PowerShell is a combined command-line shell and scripting language designed primarily for administrators, not developers. Prior to the introduction of Windows PowerShell into operating systems, administrators were forced to learn a programming language such as Visual Basic to fully manipulate objects in the Active Directory and Exchange environment if the graphical user interface (GUI) did not provide an easy means for administration. Mainly, an administrator found the need for additional tools, such as custom VB scripts, when he or she wanted to manage objects in bulk. PowerShell 2.0 includes significant changes from the original version. Several new operators have been added with PowerShell 2.0. New Operator
Description
Splatting operator The passing of a collection of parameters or “splatting” of a hashtable as input to a cmdlet. (Uses the @ symbol.) Example: A function can be created to import a CSV file and convert it to a series of hashtables, as might be the case if you wanted to add 100 users to a group. Each user to be added to the local group will become an individual hashtable (so, if 100 users need to be added to a group, 100 hashtables will be automatically created by the function). The hashtables can then be pipelined to a ForEach-Object cmdlet using the splatting operator (@) to achieve the same result more expeditiously than by using a PowerShell script. Split operator
Splitting strings into separate components. (Uses -split to break the string into an array.) Example: Displayname “Dorothy Buhler” can be split into firstname and lastname components “Dorothy” and “Buhler”.
2
What’s New in PowerShell 2.0
New Operator
Description
Join operator
Combining the components into one. This concatenates multiple strings into a single string, separated by a separator character, such as a comma. (Uses -join to perform the concatenation, adding separators as necessary.) Example: “Philadelphia” and “PA” become “Philadelphia, PA.”
PowerShell 2.0 also introduces new variables. The four new variables are described in the following table. New Variables
Description
$CommandLineParameters
Accumulates command-line and pipeline parameters.
$PSVersionTable
PowerShell version information is available through this variable.
$Culture
Current Culture information is available through this variable.
$UICulture
Current UI Culture information is available through this variable.
Also, 24 new cmdlets have been added in PowerShell 2.0. Some of the more notable new cmdlets are described in the following table. New cmdlet
Description
Get-PSBreakpoint
Retrieves the breakpoints that are set in the current session. (A breakpoint is a point in a command or script where execution stops temporarily so that you can examine the instructions. This is one of several cmdlets designed for debugging Windows PowerShell scripts and commands.)
New-PSBreakpoint
Sets a new breakpoint on a script, command, and on the read or write of certain variables.
Remove-PSBreakpoint Deletes an existing breakpoint. You must designate a breakpoint object or a breakpoint ID. (When you remove a breakpoint, the breakpoint object is no longer available or functional.) Enable-PSBreakpoint
Re-enables disabled breakpoints. (You can use it to enable all breakpoints collectively, or you can specify individual breakpoints using breakpoint objects or breakpoint IDs.) This cmdlet changes the value of the Enabled property of a breakpoint object to $true.
What’s New in PowerShell 2.0
New cmdlet
Description
Disable-PSBreakpoint
Disables currently enabled breakpoints so that the script will not stop at them when it is run. (You can use it to disable all breakpoints collectively, or you can specify individual breakpoints using breakpoint objects or breakpoint IDs.) This cmdlet changes the value of the Enabled property of a breakpoint object to $false.
Step-Into
Executes the current statement, stopping at the next statement. (If the current statement is a function or script call, the debugger steps into that function or script; otherwise, it stops at the next statement.)
Step-Out
Executes the current statement, stopping at the next statement. (If the current statement is a function or script call, the debugger executes the whole function or script, and it stops at the next statement after the function call.)
Step-Over
Steps out of the current function and up one level if the function is nested. (If in the main body, the script is executed to the end or to the next breakpoint. The skipped statements are executed but not stepped through.)
Continue
Continues execution to the end or to the next breakpoint. (The skipped functions and invocations are executed but not stepped through.)
Get-PSJob
Retrieves Windows PowerShell background jobs (PSJobs) that are running in the current console.
Start-PSJob
Starts a Windows PowerShell background job (PSJob) from the current console.
Stop-PSJob
Stops a Windows PowerShell background job (PSJob).
Wait-PSJob
Suppresses the command prompt until one or all of the Windows PowerShell background jobs (PSJobs) running in the console are complete.
Remove-PSJob
Deletes a Windows PowerShell background job (PSJob).
Receive-PSJob
Retrieves the results of the Windows PowerShell background jobs (PSJob) in the current console. (You can use this cmdlet to retrieve the output and errors of background jobs.)
3
4
What Is a Cmdlet?
New cmdlet
Description
Get-Runspace
Retrieves the runspaces that were created in the current console. (You would use a runspace to run multiple commands that share data, such as a function or the value of a variable.)
New-Runspace
Creates a persistent connection to a Windows PowerShell session on a local or remote computer.
Remove-Runspace
Closes one or more runspaces.
As you can see, a number of new cmdlets have been built in to Windows PowerShell 2.0. The ones of greatest interest to admins rather than developers are the ones dealing with background jobs, also known as PSJobs.
What Is a Cmdlet? The cmdlet (pronounced “command let”) is a basic tenant of Exchange Management Shell. It always is formatted as a verb-noun combination. (There are never any spaces between the verb and the noun.) The verb is an action and the noun is the object on which you perform the action. Unless a pipe character (|) appears in the statement, there cannot be more than one cmdlet in a single statement. Everything you do in Exchange Management Shell starts with a cmdlet. Some cmdlets have only a few parameters associated with them (such as the Mount-Database cmdlet), whereas others have many parameters that may be associated with them (such as the New-Mailbox cmdlet). The following table illustrates how two cmdlets could have many differences in terms of their available parameters. Mount-Database parameters: AcceptDataLoss Confirm DomainController Force Identity WhatIf Syntax: Mount-Database -Identity name
On the other hand, the NewMailbox cmdlet has 64 parameters, as shown. (There are many more configuration options necessary when you create a mailbox versus when you simply need to mount a database.)
6
The Exchange Management Shell
This is just a single example illustrating the wide variety of parameters available between two individual cmdlets. It is easy to see that with more than 1,000 available cmdlets in Windows PowerShell 2.0—each having a unique set of parameters— PowerShell and EMS will have nearly limitless possibilities as you manage your Exchange 2010 organization.
The Exchange Management Shell Figure 1-1 shows the Exchange Management Shell (or “Shell” as some call it), which is a management interface for Microsoft Exchange Server 2010. It is built on top of Windows PowerShell 2.0 and provides a command-line interface for Exchange Server. In the figure, the Get-ExchangeServer cmdlet has been executed and has been directed to display the output in a list format showing the server’s fully qualified domain name (FQDN), as well as the Exchange roles installed on the server.
Figure 1-1
The Exchange Management Shell
Figure 1-1 also shows the Welcome Message and “Tip of the Day” typically seen immediately after launching EMS. NOTE
NOTE
You also might see Exchange Management Shell abbreviated as EMS.
An administrator may perform any administrative task from the Exchange Management Shell. However, individual tasks are not especially the strength of Exchange
The Exchange Management Shell
7
Management Shell. The strength of Exchange Management Shell lies in its capability to automate administrative tasks. The following examples set the IssueWarningQuota parameter value to 500MB for mailboxes at different levels. (When the IssueWarningQuota parameter is set on a mailbox, a warning message is sent to the user when the mailbox reaches the designated size.) It is important to have the ability to set attributes at multiple levels. Sometimes you want everyone in the organization to have the same value for an attribute. Other times, you might want everyone in a particular database or with a mailbox on a particular server to have the same value for an attribute. Occasionally, you might need one mailbox to be unique. The different levels shown in the examples are as follows: ■
Recipient level with the Set-Mailbox cmdlet
■
OU level using Get-Mailbox -OrganizationalUnit and pipelining
■
Server level using Get-Mailbox -Server and pipelining
■
Organization level using Get-Mailbox without pipelining
You can use the Set-Mailbox cmdlet with the -IssueWarningQuota parameter, as shown in the following table. Set-Mailbox -Identity name -IssueWarningQuota size -UseDatabaseQuotaDefaults $boolean value Example: PS C:\Users\Administrator>
You can manage objects at the recipient level, including the modification of all attributes, as shown by changing the quota of a single mailbox. The mailbox that requires the quota change is represented by the name attribute. You can set any size by using an integer value and the appropriate measure (KB, MB, GB, etc.) as an acceptable size for the quota. You may also type unlimited as the size if you do not want to set a quota for this particular mailbox. The $false parameter says that the user will not inherit the quota values set on the database. If this option were left off, the database settings would be inherited and applied, even though you set individual settings on this mailbox. When this option is set to $false, inheritance is blocked. If the parameter value is set to $true, the database setting will be reapplied, overwriting the individual setting. Additional information regarding this cmdlet will be covered in Chapter 7, “Working with Recipient Objects.” In the example, you want to change the IssueWarningQuota parameter on Dorothy’s mailbox to 500MB and you do not want the database setting to be inherited.
8
The Exchange Management Shell
That is a lot of typing for just one mailbox. As you can see in Figure 1-2, you can perform this same task with little effort in Exchange Management Console.
Figure 1-2 Setting the IssueWarningQuota for a single mailbox in Exchange Management Console
However, if that same task is necessary for ten mailboxes (or 10,000), much less administrative effort will be required if the task is performed with Exchange Management Shell. The following cmdlets utilize a feature of PowerShell known as pipelining. Pipelining enables you to combine multiple cmdlets into a single line of code. It uses the | character to separate two or more cmdlets in the command that you type. For example, the Get-Mailbox cmdlet collects the appropriate mailboxes and then passes that list on to the Set-Mailbox cmdlet, which changes the IssueWarningQuota parameter value. The pipelining feature is presented in Chapter 3, “Advanced Techniques.” TIP
You can use the Set-Mailbox cmdlet with the pipelining feature as shown in the following three examples.
You can manage at the Organizational Unit (OU) level, setting IssueWarningQuota for all users in the Assembly OU to the same value. You might wonder whether the quotes around values such as OUName are necessary. A good rule of thumb is that if there are any spaces in the value, the quotes are necessary. If there are no spaces in the value, the quotes are optional. Because there are no spaces in the OU name Assembly, the quotes are optional here, but it would not be incorrect to use them. You might also wonder whether single quotes or double quotes may be used. In many cases, either may be used as long as you are consistent within the pair of quotes. (That is to say, if you open with a double quote, you must close with a double quote.) In some cases, the type of quote is important. For example, suppose you define a variable called DaysinWeek and assign a value of 7 to the variable because there are seven days in a week. When you reference that variable in PowerShell, if the result that you want to output is the name of the variable (DaysinWeek), enclose it in single quote marks. However, if the result that you want to output is the value of the variable (7), enclose the variable in double quotes.
9
10
The Exchange Management Shell
Mailbox Management at the Server Level: Get-Mailbox -Server servername | Set-Mailbox -IssueWarningQuota warning level -UseDatabaseQuotaDefaults $boolean value Example:
You can also manage at the server or database level. In this pair of cmdlets, the IssueWarningQuota parameter for all users with mailboxes on Romac-EX3 is set to the same value.
Mailbox Management at the Organization Level: PS C:\Users\Administrator> Get-Mailbox | Set-Mailbox -IssueWarningQuota 500MB -UseDatabaseQuotaDefaults $false
This would only apply to a single database on a server because the parameter is set at the database level.
You can even manage at the organization level, setting the IssueWarningQuota parameter for all users in the organization to the same value. (This is very easily accomplished. Don’t use any parameter with the Get-Mailbox cmdlet.)
With creative use of the Get-Mailbox cmdlet and other Active Directory parameters, you can achieve the granularity you require in the management of your Exchange objects. TIP It is not a good idea to manage at multiple levels regularly because you might unintentionally overwrite settings on objects by changing a value on an object higher in the hierarchy. (The Get statement retrieves all applicable objects and the Set statement applies the change. A database setting would be overwritten when you execute a cmdlet changing the value at the server level.)
CHAPTER 2
Basic Techniques
This chapter provides information and commands concerning the following topics: ■
Using the GUI
■
Understanding the basic syntax of a cmdlet
■
Finding the right cmdlet
■
Finding help for the right cmdlet
■
Using the Tab Completion feature
In this chapter, you explore the basics of working with cmdlets. You also investigate how to find the right cmdlet for the job as well as how to find help about using those cmdlets. Finally, you learn how to use Tab Completion as a means to reduce typing and errors while using PowerShell.
Using the GUI There are certainly times when using the GUI makes sense. Any work to be performed on an individual Exchange 2010 object will most likely be more easily performed from Exchange Management Console, also known as EMC. Changing a property on a server or on a database or even on a single recipient is generally much easier from the GUI interface. EMC in Exchange 2010 is laid out very much like EMC in Exchange Server 2007. It has a hierarchical structure that matches the hierarchy of Exchange Server (that is, Organization - Server - Recipient). However, there are significant differences if you are using the EMC 2010 version. One of the differences deals with a new object called a Database Availability Group (or DAG). A second and very significant difference is the removal of storage groups in Exchange 2010. Both of these very visible changes will be discussed in much greater detail, but it is important to use the appropriate version of the console when working with EMC to obtain the desired results. More importantly than when to use the GUI, is when not to use the GUI. You are quite honestly just unable to perform many tasks from EMC. Exchange Management Shell, or EMS, is required for these tasks. There is simply no other way to perform these tasks. Exchange 2010 SP1 has added more options to the GUI tools; however, you still will not be able to do everything from a GUI-based tool. As you progress through this book, many such tasks will be highlighted, alerting you to the fact that the highlighted task may only be performed from EMS and not from either of the graphical tools. EMS is most effective and provides the greatest value when you are managing multiple objects. The following table shows an example.
You need to set a Warning Quota for all machinists’ mailboxes. Some of the mailboxes are in the AssemblyDB and others are in the ManufacturingDB. However, all of the users are in the distribution group called MachinistsDG. You can very easily perform this task with a single cmdlet, as shown.
As you can see, without even knowing on which server or in which database the machinists’ mailboxes are located, you could perform this or many other operations on those distinct mailboxes quite easily. Imagine trying to do something like that in a GUI-based tool. Just locating the specific recipients to be managed in a large organization could be a challenge.
Understanding the Basic Syntax of a cmdlet The following table details the basic syntax of a cmdlet starting with a few of the common verbs. Get Example: PS C:\Users\
Read-only verb. Retrieves information about an Exchange 2010 object.
Administrator>Get-Mailbox
The example retrieves a list of all mailboxes in the organization.
Set
Modifies a property of an existing Exchange 2010 object.
The example directs Dorothy’s mailbox to not accept messages from Dale.
New
Creates a new Exchange 2010 object.
This example creates an Active Directory user account and an Exchange Administrator>New-Mailbox -Name 'Dale Syhre' -Alias 'Dale' 2010 mailbox for the user Dale Syhre. Example: PS C:\Users\
Sets the “Enabled” status of an Exchange 2010 object to $false. For example, if Dale already has a mailbox, the Disable-Mailbox cmdlet will disassociate the user and the mailbox. The -Confirm: $false option means that you won’t be prompted for confirmation of the disassociation. The user will still exist and the mailbox will be marked for removal after the deleted mailbox retention period has expired (30 days by default).
Sets the “Enabled” status of an Exchange 2010 object to $true. ($=string). For example, if a Windows user for Dale already exists, the Enable-Mailbox cmdlet will create a mailbox for Dale and mail-enable Dale’s user account. In the example where the user Dale was created, the NewMailbox cmdlet created the Active Directory user account and assigned the Exchange mailbox to it all in one operation. However, in this most recent example, the EnableMailbox cmdlet takes an existing Active Directory user account that had been previously created and assigned an Exchange mailbox to it. NOTE
It is important to distinguish between the two verbs. The New verb often requires Active Directory permissions, whereas the Enable verb often only requires Exchange permissions.
TIP
Remove
Deletes an Exchange 2010 object.
Example: PS C:\Users\
For example, if Dale already has a mailbox, the Remove-Mailbox cmdlet will delete the user and mark the mailbox for removal after the deleted mailbox retention period has expired.
The $false parameter says that the administrator will not be prompted to confirm the deletion. This is often desirable when a script is being run and no administrator will be present to confirm the deletion.
TIP
14
Understanding the Basic Syntax of a cmdlet
Test Example: PS C:\Users\ Administrator>Test-ServiceHealth -Server Romac-EX1
Predefined tests that you can perform for determining connectivity and latency for various clients, testing mailflow between transport components, and verifying Exchange Server service status. This example checks the status of Exchange services running on RomacEX1.
There is a distinct difference between the verbs Disable and Remove as seen in the warning messages in Figures 2-1 and 2-2. Disabling a mailbox will leave both the user and the mailbox intact, but no longer associated with each other. However, the mailbox will be marked for deletion at the end of the deleted mailbox retention period, which is 30 days by default. Removing a mailbox (despite the implications of the cmdlet) will actually delete the Active Directory user, not the mailbox. It will also mark the mailbox for deletion at the end of the deleted mailbox retention period.
TIP
Similar messages to what’s in Figure 2-2 are displayed when the MailboxUser is disabled or removed using Exchange Management Shell, as seen in Figure 2-3.
Figure 2-1 Warning message when a mailbox user is disabled in Exchange Management Console
Understanding the Basic Syntax of a cmdlet
Figure 2-2 Warning message when a mailbox user is removed in Exchange Management Console
Figure 2-3 Warning message when a mailbox user is both disabled and removed in Exchange Management Shell
15
16
Understanding the Basic Syntax of a cmdlet
Basic Syntax: Some Common Cmdlets Using the Get Verb Although the cmdlets in the following table don’t always use this feature, you often will want to either reduce the amount of data returned by the cmdlet or view attributes that are not returned by default by specifying which individual attribute(s) you would like to have returned. NOTE
Active Directory–Level Get Cmdlets PS C:\Users\ Administrator>Get-User
Use this very simple verb-noun combination to perform an LDAP query against the Active Directory and retrieve a list of all users in your Active Directory whether they have an Exchange mailbox or not. The list is unsorted and the parameter values returned are predefined. The two parameters returned are Name and RecipientType. NOTE
PS C:\Users\ Administrator>Get-User | Sort-Object Name
Use the same verb-noun combination that was performed in the preceding LDAP query against the Active Directory. But now, the cmdlet retrieves a list of all users in your Active Directory sorted alphabetically by first name because of the Sort-Object cmdlet. TIP This is an example of pipelining. (The pipelining feature is explained in greater detail in Chapter 3, “Advanced Techniques.”)
Get-User -Identity name PS C:\Users\ Administrator>Get-User -Identity Dorothy
Use this to retrieve the name of the user (Dorothy Buhler) as well as the RecipientType value of the recipient (UserMailbox).
Organization-Level Get Cmdlets PS C:\Users\ Administrator> Get-AcceptedDomain
Use this to retrieve the list of accepted domains configured in your organization and their domain types. An accepted domain is necessary in order for your Exchange server to receive mail for a namespace. The Mail Exchanger (MX) record on the public DNS directs the mail to your doorstep, but without an accepted domain, your server cannot accept it. NOTE
Understanding the Basic Syntax of a cmdlet
17
PS C:\Users\ Administrator> Get-AddressList
Use this to perform an LDAP query against the Active Directory and retrieve a list of all the address lists in your Active Directory.
Use this to perform an LDAP query against the Active Directory and retrieve a list of all the email address policies in your Active Directory.
PS C:\Users\ Use this to perform an LDAP query against the Active Directory and retrieve a list of all the mesAdministrator> Get-MessageClassification sage classifications in use in your organization. PS C:\Users\ Administrator> Get-OfflineAddressBook
Use this to perform an LDAP query against the Active Directory and retrieve a list of all the offline address books in use in your organization and their settings.
Use this to retrieve configuration data for an Exchange organization. This includes quite a bit of organization-level information such as MailTips, SCL JunkThreshold, and whether the organization is in Mixed Mode, to name just a few. NOTE
Use the first example to retrieve a list of all Exchange servers in your organization and their attributes. Use the other cmdlets to retrieve lists of servers hosting the appropriate roles. (As you can see in Figure 2-4, Romac-EX1 and Romac-EX2 hold the Mailbox, Hub, and Client Access roles. Romac-EX3HC holds the Hub and Client Access roles, but is not a Mailbox server. There are no Unified Messaging servers in this organization.)
18
Understanding the Basic Syntax of a cmdlet
Figure 2-4
Retrieving information about the Exchange servers in your environment
As you can see, it is very easy to retrieve information about all servers in your organization or about each individual server role in your Exchange organization. Mailbox Database-Level Get Cmdlets PS C:\Users\Administrator> Get-MailboxDatabase
Use this to display information about all of your mailbox databases. This will include, by default, the parameters Name, Server, Recovery, and ReplicationType. NOTE
Use this to display information about a specific mailbox database (AssemblyDB). This will also include, by default, the parameters Name, Server, Recovery, and ReplicationType. NOTE
If you would like to view other parameters, you must specify them by name, as shown in Figure 2-5. (The Format-List cmdlet will be explored further in Chapter 3.)
Understanding the Basic Syntax of a cmdlet
Figure 2-5
Using the Format-List cmdlet with the Get-MailboxDatabase cmdlet
Public Folder Database-Level Get Cmdlets PS C:\Users\Administrator> Get-PublicFolderDatabase
Use this to perform an LDAP query against the Active Directory and retrieve a list of all the public folder databases and their attributes.
Public Folder-Level Get Cmdlets PS C:\Users\Administrator> Get-PublicFolder
Use this to perform an LDAP query against the Active Directory and retrieve a list of all the public folders and their attributes.
Use this to retrieve information about items within a specified public folder. TIP You can view the subject, the last time the item was accessed or modified, the creation time of the item, any attachments, the message size, and the type of item with this cmdlet.
19
20
Understanding the Basic Syntax of a cmdlet
Mailbox-Level Get Cmdlets PS C:\Users\ Administrator>Get-Mailbox | Sort-Object Name
Use this to perform an LDAP query against the Active Directory and retrieve a list of all users with Exchange mailboxes in your Active Directory, sorting them alphabetically. The output is very different from the Get-User cmdlet. Instead of name and recipient type, the parameter values returned are now Name, Alias, ServerName, and ProhibitSendQuota. NOTE
Use this to retrieve the name of the user (Dorothy Buhler) as well as the Alias (Dorothy), ServerName (Romac-EX1), and ProhibitSendQuota value of the recipient (unlimited). TIP You might want to see other parameters. For example, in a singleserver environment, the ServerName will be the same for all of the users, but you might want to view the database in which the mailbox resides rather than the server.
(The Format-Table cmdlet will be explored further in Chapter 3.)
Other Recipient-Level Get Cmdlets PS C:\Users\ Administrator>Get-Contact
Use this to perform an LDAP query against the Active Directory and retrieve a list of all the mail-enabled contacts. TIP A mail-enabled contact is an Exchange object, but it has no Active Directory account or Exchange mailbox. However, it does appear in the Global Address List (GAL).
PS C:\Users\Administrator> Get-DistributionGroup
Use this to perform an LDAP query against the Active Directory and retrieve a list of all the existing distribution groups.
Use this to perform an LDAP query against the Active Directory and retrieve a list of all the members of a distribution group.
Understanding the Basic Syntax of a cmdlet
PS C:\Users\ Administrator>Get-MailUser
21
Use this to perform an LDAP query against the Active Directory and retrieve a list of all the mail-enabled users and their attributes. TIP A mail-enabled user is an Exchange object that does have an Active Directory account but does not have an Exchange mailbox. However, it does appear in the Global Address List (GAL).
PS C:\Users\ Administrator>Get-Recipient
Use this to perform an LDAP query against the Active Directory and retrieve a list of all Exchange recipients, which includes Mailbox Users, Mail-Enabled Users, Mail-Enabled Contacts, Resource Mailboxes, Distribution Groups, and Linked Mailboxes.
Information/Reporting-Level Get Cmdlets PS C:\Users\Administrator> Get-LogonStatistics
Use this to perform an LDAP query that retrieves logon statistics about the recipient. TIP This includes user name, logon time, last access time, client version, and adapter speed.
PS C:\Users\Administrator> Get-MailboxStatistics
Use this to retrieve mailbox statistics about the mailbox. TIP This includes the size of the mailbox, the number of messages it contains, and the last time it was accessed. It also will document the move history and provide a move report of any completed move requests.
PS C:\Users\Administrator> Get-MoveRequest
Use this to retrieve detailed information about a mailbox move that was initiated with a New-MoveRequest cmdlet. (There will be much more about this cmdlet in Chapter 7, “Working with Recipient Objects,” and Chapter 8, “Bulk Management of Recipients.”)
Use this to retrieve detailed information and statistics in this example for Dorothy’s mailbox. TIP This includes the move status, mailbox size, archive mailbox size, and the percentage of the move that has been completed.
22
Understanding the Basic Syntax of a cmdlet
CAS Role-Level Get Cmdlets PS C:\Users\Administrator> Get-ActiveSyncDevice
Use this to retrieve a list of all devices in your organization that have active Microsoft Exchange ActiveSync partnerships.
Use this to retrieve a list of all mobile phones configured to synchronize with a user’s mailbox. (This returns statistics about the phone, not the user.)
Use this to retrieve ActiveSync policy settings for a computer running Microsoft Exchange Server 2010 that has the Client Access Server role installed.
PS C:\Users\Administrator> Use this to retrieve the settings for the Get-AutodiscoverVirtualDirectory Autodiscover virtual directory on a
computer running Microsoft Exchange Server 2010 that has the Client Access Server role installed. PS C:\Users\Administrator> Get-CASMailbox
Use this to retrieve a complete list of the attributes of a Microsoft Exchange Server 2010 mailbox on a computer that has the Client Access Server role installed.
PS C:\Users\Administrator> Get-ClientAccessArray
Use this to retrieve information about the Active Directory object that represents a load-balanced array of Client Access Servers. TIP The CAS Array is a new highavailability object for Exchange 2010 and will be discussed in detail in Chapter 12, “CAS Services.”
PS C:\Users\Administrator> Get-Outlook Anywhere
Use this to retrieve all Outlook Anywhere settings on a computer running Microsoft Exchange Server 2010 that has the Client Access Server role installed.
PS C:\Users\Administrator> Get-OutlookProvider
Use this to retrieve the global settings from the AutoDiscoverConfig object under the Global Settings object in Active Directory.
PS C:\Users\Administrator> Get-OwaMailboxPolicy
Use this to retrieve all OWA mailbox policies in a Microsoft Exchange Server 2010 organization.
Use this to retrieve information from the Active Directory for the virtual directory EWS from a computer running Microsoft Exchange Server 2010 with the Client Access Server role installed.
Transport Role-Level Get Cmdlets (Hub and Edge Transport) PS C:\Users\ Administrator> Get-AddressRewriteEntry
Use this to view an existing address rewrite entry that rewrites the sender and recipient email addresses mail sent to or from an email organization. TIP This feature is only a function of the Edge Transport server role.
PS C:\Users\ Administrator> Get-AdSite
Use this to retrieve information about one or more Active Directory sites in which Exchange Hub Transport servers reside. TIP You can view your exchange Hub Sites with this cmdlet.
PS C:\Users\ Administrator> Get-AdSiteLink
Use this to retrieve information about one or more Active Directory IP site links that represent physical links over which mail is sent. TIP You can view your Exchange-specific site link costs with this cmdlet.
PS C:\Users\ Administrator> Get-EdgeSubscription
Use this to retrieve information about the Edge Subscriptions that have been configured in a Microsoft Exchange Server 2010 organization.
PS C:\Users\ Administrator> Get-JournalRule
Use this to display the journal configuration on a server that has the Hub Transport role installed.
PS C:\Users\ Administrator> Get-MailboxSearch
Use this to display mailbox searches that are in progress, have completed, or have been stopped.
PS C:\Users\ Administrator> Get-Message
Use this to view information about one or more messages in a queue on a computer that has the Hub Transport server role or the Edge Transport server role installed.
Use this to search message information stored in the message tracking log.
NOTE If you are unable to get this example to function, it may be because you do not have permission to run it. Even as an administrator, you must explicitly assign yourself this permission through Role-Based Access Control (RBAC) in order to even see this as a valid cmdlet.
24
Understanding the Basic Syntax of a cmdlet
PS C:\Users\ Use this to retrieve the list of Microsoft Outlook protection rules configured in an organization. Administrator> Get-OutlookProtectionRule PS C:\Users\ Administrator> Get-Queue
Use this to view detailed information for queues on a computer that has the Hub Transport server role or the Edge Transport server role installed.
PS C:\Users\ Administrator> Get-ReceiveConnector
Use this to view the configuration information for a Receive connector on a computer that has the Hub Transport server role or the Edge Transport server role installed.
PS C:\Users\ Administrator> Get-RemoteDomain
Use this cmdlet to view the configuration information for the remote domains in your organization.
PS C:\Users\ Administrator> Get-SendConnector
Use this to view the configuration information for a Send connector on a computer that has the Hub Transport server role or the Edge Transport server role installed.
PS C:\Users\ Administrator> Get-TransportAgent
Use this to view the configuration of a transport agent on a computer that has the Edge Transport server role or the Hub Transport server role installed in a Microsoft Exchange Server 2010 organization.
PS C:\Users\ Administrator> Get-TransportConfig
Use this to view the organization-wide email transport configuration settings on computers that have the Hub Transport server role or the Edge Transport server role installed.
PS C:\Users\ Administrator> Get-TransportRule
Use this to display the list of transport rules that have been configured for your Hub Transport servers in the Active Directory or locally on your Edge Transport server.
TIP You can view the remote domain configuration either from inside the Exchange organization or from a computer that has the Edge Transport server role installed on the outside of your organization.
Unified Messaging (UM) Role-Level Get cmdlets PS C:\Users\ Administrator> Get-UMDialplan
Use this to display the settings of all Unified Messaging (UM) dial plans associated with a Unified Messaging server.
PS C:\Users\ Administrator> Get-UMHuntGroup
Use this to display the settings for an existing Unified Messaging hunt group.
PS C:\Users\ Administrator> Get-UMMailbox
Use this to display the Unified Messaging settings for a UM-enabled recipient.
Understanding the Basic Syntax of a cmdlet
25
High Availability-Level Get Cmdlets Use this to retrieve a list of all Database Availability Groups.
TIP This cmdlet can also display the list of servers that are members of the Database Availability Group (DAG) as well as real-time status information about the DAG.
PS C:\Users\Administrator> Use this to retrieve a list of all Get-DatabaseAvailabilityGroupNetwork Database Availability Group net-
works. TIP This cmdlet can also display configuration and state information for a Database Availability Group (DAG) network.
Use this to retrieve status information about mailbox databases that have been configured with one or more database copies.
Permission-Level Get Cmdlets PS C:\Users\Administrator> Get-ADPermission
Use this to retrieve the permissions on an Active Directory object.
PS C:\Users\Administrator> Get-MailboxPermission
Use this to retrieve permissions on a mailbox.
PS C:\Users\Administrator> Get-ManagementRole
Use this to retrieve the list of management roles that have been created in your organization.
PS C:\Users\Administrator> Use this to retrieve the existing management Get-ManagementRoleAssignment role assignments. A management role assignment links a management role and a role group and is new to Exchange 2010. NOTE
Use this to retrieve the entries on a management role that allow access to cmdlets, scripts, and other permissions. This is what allows a user or group to perform a specific task. NOTE
26
Understanding the Basic Syntax of a cmdlet
PS C:\Users\Administrator> Get-ManagementScope
Use this to retrieve the list of possible management scopes that have been defined. A management role scope is the boundary defining where the action may be performed. For example, if the scope of management is in the Philadelphia OU, the action may only be performed on objects in that Organizational Unit (OU). NOTE
Use this to retrieve the existing management role assignment policy on a server running Microsoft Exchange Server 2010.
PS C:\Users\Administrator> Get-RoleGroup
Use this to retrieve a list of management role groups. A management role group is an Active Directory group that uses the RoleBased Access Control (RBAC) permissions model in Microsoft Exchange Server 2010. NOTE
PS C:\Users\Administrator> Get-RoleGroupMember
Use this to retrieve a list of members of a management role group.
Compliance-Level Get Cmdlets PS C:\Users\Administrator> Use this to retrieve the status of the Get-MailboxComplianceConfiguration AutoTagging attribute on a mailbox. PS C:\Users\Administrator> Get-ManagedContentSettings
Use this to retrieve the managed content settings associated with default and custom managed folders.
PS C:\Users\Administrator> Get-ManagedFolder
Use this to retrieve the list of managed folders and their attributes in use in your organization.
Use this to retrieve the list of all available transport rule actions that can be performed by a transport agent on a Hub Transport or an Edge Transport server.
Use this to retrieve the list of all available rule predicates (subject, body, header, etc.) that can be used within a transport rule on a Hub Transport server or an Edge Transport server.
Basic Syntax: Some Common Parameters In the short space that follows it is not possible to list all of the common parameters for every single object, so the MailboxUser object is used to demonstrate many of the common parameters that are possible in a cmdlet. -AccountDisabled
Specifies whether to create the MailboxUser in a disabled state. TIP Resource mailboxes are automatically flagged and do not have to have this switch set manually.
-ActiveSyncMailboxPolicy
Specifies the ActiveSyncMailboxPolicy that will be used for the mailbox. (If one is not specified, the default policy will be used.)
-Alias
Specifies the email alias of the user for the mailbox that will be created.
-Confirm
A value of $true for this parameter suspends processing of the command and requires acknowledgement of the command before processing continues.
(No spaces are allowed in an alias.)
A value of $false bypasses any screens requiring confirmation before continuing, such as when you wish to delete an object but do not wish to be bothered by an “Are you sure you want to delete this object?” dialog box. -Database
Specifies in which Exchange database the new user’s mailbox will be created. Acceptable values include the name of the database and the globally unique identifier (GUID) of the database.
28
Understanding the Basic Syntax of a cmdlet
-Discovery
Specifies that the mailbox will be created as a Discovery mailbox. Discovery mailboxes are a special type of mailbox created as the target for a Discovery search. A mailbox designated as a Discovery mailbox cannot be repurposed or converted to another type of mailbox. NOTE
-DisplayName
Specifies the Windows display name for the new user who is being created. (This is the name that appears in Active Directory Users and Computers as well as under Recipient Configuration in Exchange Management Console, as well as other places.)
-Equipment
Specifies that the mailbox will be created as a resource mailbox representing a piece of equipment, rather than a conference room (or other facility) or a user account.
-FirstName
Specifies the first name of the user who will be created.
-Force
Specifies whether to suppress warnings and confirmations. (This is usually used in scripts to bypass events requiring user interaction in order for the command to complete successfully.)
-Initials
Specifies the initials of the user who will be created.
-LastName
Specifies the last name of the user who will be created.
-ManagedFolderMailboxPolicy Specifies the ManagedFolderMailboxPolicy
that will be used for the mailbox. (If one is not specified, the default policy will be used.) -ModeratedBy
Specifies the users who are responsible for moderating messages sent to this mailbox. TIP If more than one moderator is desired, separate the users with commas.
Understanding the Basic Syntax of a cmdlet
-ModerationEnabled
29
Specifies whether moderation is enabled for the mailbox. (To enable moderation, use $true. To disable moderation, use $false. The default value is $false.)
-Name
Specifies the user’s name that will appear in Active Directory Users and Computers. (This is also the user name that appears in the properties of the recipient.)
-Office
Specifies the Office attribute for this mailbox.
-OrganizationalUnit
Specifies the Organizational Unit (OU) where the user will be created in the Active Directory.
-Phone
Specifies the user’s telephone number.
-PrimarySmtpAddress
Specifies the primary SMTP address of the user’s mailbox.
-RemotePowerShellEnabled
Specifies whether the user has the right to use Remote PowerShell. This permission is necessary in order to open Exchange Management Shell or the Exchange Management Console on Mailbox, Client Access, Hub Transport, or Unified Messaging servers. NOTE
The default value depends on the management role groups to which the user is assigned. -ResetPasswordOnNextLogon
Specifies whether the user must reset his or her password the next time he or she logs on.
-ResourceCapacity
Specifies the capacity of the resource, if this mailbox is a room mailbox.
-RetentionPolicy
Specifies the retention policy to be applied to the mailbox being created. (Retention policies include retention tags that are applied to folders in a user’s mailbox regulating how long items should be retained in the tagged folders.)
-RoleAssignmentPolicy
Specifies the management role assignment policy to be assigned to the mailbox being created. This determines what users may do with their mailbox and its contents, as well as whether they may modify their personal information, manage their public group membership, manage their voicemail, and their mobile phone. An assignment policy is created as the default and all existing mailboxes are configured to use the assignment policy unless another is specified. NOTE
30
Understanding the Basic Syntax of a cmdlet
-Room
Specifies that the mailbox will be created as a resource mailbox representing a conference room or other facility, rather than a piece of equipment or user.
-SamAccountName
Specifies the user logon name. If a SamAccountName is not designated, the Active Directory creates a SamAccountName attribute automatically, based on the User Principal Name (UPN) of the user account.
-Shared
Specifies that the mailbox will be created as a shared mailbox. A shared mailbox is a mailbox that allows multiple users to log on to it and is not associated with any of the users who access it. A disabled user account is created for it in Active Directory. This was often used to represent a resource object in previous versions of Exchange Server. NOTE
-UserPrincipalName
Specifies the User Principal Name (UPN) for the mailbox. (Generally, this is the logon name for the user account.)
-WhatIf
The WhatIf switch simulates the actions of the cmdlet without actually applying any changes to Exchange or to the Active Directory. (By using the WhatIf switch, you can view what changes would occur without risking damage to the Exchange organization. Because using a Get statement alone does not make any changes when you execute a cmdlet, the -Whatif option is used primarily—and is most valuable—when the Get cmdlet is pipelined to another cmdlet.)
The following example creates a new user and the associated mailbox using a number of the aforementioned attributes.
Finding the Right Cmdlet
31
This example uses the following PS C:\Users\Administrator> attributes from the previous list: New-Mailbox -Name "Leo Weishew" -Alias "Leo" -OrganizationalUnit ■ -Name "romacsign.com/Assemblers" ■ -Alias -UserPrincipalName "[email protected]" ■ -OrganizationalUnit -SamAccountName "Leo" -FirstName "Leo" -Initials "" ■ -UserPrincipalName -LastName "Weishew" ■ -SamAccountName -Password "System.Security.SecureString" ■ -FirstName -Phone "856-555-1212" -ResetPasswordOnNextLogon $false ■ -Initials -Database "AssemblyDB" ■
-LastName
■
-Password
■
-Phone
■
-ResetPasswordOnNextLogon
■
-Database
Some of the attributes (such as -SamAccountName and -UserPrincipalName) are mandatory attributes, whereas others (such as -FirstName, -LastName, and -Phone) are optional attributes.
NOTE
Finding the Right Cmdlet In this section, you find cmdlets that access the Help features of PowerShell. For example, the Get-Tip cmdlet allows you to view the Tip of the Day, which is a feature that is displayed whenever you launch Exchange Management Shell. PS C:\Users\ Administrator>Get-Command
Retrieves a list of all possible cmdlets available to EMS.
PS C:\Users\ Administrator>Get-Command >filepath
Creates a text file in the specified path with all of the possible cmdlets available to EMS.
Retrieves a list of all possible cmdlets using the specified verb (in this case, the New verb).
The output of this example would include: Get-CASMailbox Get-Mailbox Get-UMMailbox
PS C:\Users\ Administrator>Get-Command -Verb New PS C:\Users\Administrator> Get-ExCommand
Retrieves a list of all possible Exchange cmdlets available to EMS.
PS C:\Users\ Administrator>QuickRef
Opens a link to frequently used EMS cmdlets.
PS C:\Users\ Administrator>Get-Tip
Causes a new Exchange Management Shell “Tip of the Day” to be displayed.
The Exchange Management Tools must be installed and the latest version of the Quick Reference Guide must be downloaded from the Microsoft Download Center in order to use this feature.
(The Exchange Management Tools must be installed in order to use this feature.) PS C:\Users\ Administrator>Get-ExBlog
Opens a web browser and navigates to the Exchange Team blog site. (The Exchange Management Tools must be installed in order to use this feature.)
Finding Help for the Right Cmdlet In this section, you find ways to access Help for specific cmdlets. PS C:\Users\Administrator> Get-Help
Displays help about Windows PowerShell cmdlets.
PS C:\Users\Administrator> Get-Help cmdlet
Displays help about the specific cmdlet for which help is required.
PS C:\Users\Administrator> Get-Help New-Mailbox
(In this case, help for the New-Mailbox cmdlet.)
Finding Help for the Right Cmdlet
33
PS C:\Users\ Administrator>cmdlet -?
Displays help about the specific cmdlet for which help is required.
PS C:\Users\Administrator> New-Mailbox -?
(In this case, it’s help for the New-Mailbox cmdlet. This provides the same information as Get-Help, but does not allow access to advanced help features such as -detailed, -examples, and -full.)
Displays full help about the specific cmdlet for which help is required.
See the “What’s Included in Each Version of Help” table that follows.
See the “What’s Included in Each Version of Help” table that follows.
(In this case, it’s full help for the NewMailbox cmdlet.) See the “What’s Included in Each Version of Help” table that follows.
What’s Included in Each Version of Help The following table details what’s included in each version of Help. Included? →
Name Synopsis Syntax Description Parameters
Inputs/ Errors Examples Related Remarks Outputs Links
Standard Help
Yes
Yes
Yes
Yes
No
No
No
No
Yes
Yes
-Detailed
Yes
Yes
Yes
Yes
Yes (Basic)
No
No
Yes
No
Yes
-Examples Yes
Yes
No
No
No
No
Yes
Yes
Yes
Yes
Yes Yes (Complete)
Help Version
-Full
No
Yes
No
No
Yes
Yes
Yes
No
Figure 2-6 shows an example of a Get-Help cmdlet with the -examples option shown.
34
Using the Tab Completion Feature
Figure 2-6
Get-Help cmdlet with -examples option
Using the Tab Completion Feature If you have not found it already, there is a feature of Exchange Management Shell called Tab Completion (some call it Tab Expansion) that gives you the ability to finish a cmdlet without having to type the entire cmdlet, as shown in the following table. PS C:\Users\Administrator>Set-M
Type what you see to the left and press Tab until Set-Mailbox is displayed.
PS C:\Users\Administrator>Set-Mailbox
You should now see this.
PS C:\Users\Administrator>Set-Mailbox -I
Press the spacebar, and then type -I. Press Tab until -Identity is displayed.
Add the name for the recipient of the mailbox on which you wish to set a quota, press the spacebar, and then type -I and press Tab until -IssueWarningQuota is displayed.
PS C:\Users\Administrator>Set-Mailbox Add the size value for the quota, -Identity name -IssueWarningQuota size press the spacebar, and then type -U and press Tab until -UseDatabaseQuotaDefaults PS C:\Users\Administrator> Set-Mailbox -Identity Dorothy -IssueWarningQuota 500MB -U
You’ve just created a very powerful cmdlet with only a little typing! This also works with file paths in Exchange Management Shell, as shown in the following table. PS C:\Users\Administrator>cd C:\Pr
If you want to change directories, type cd and only C:\ and the first few letters of the directory and then press Tab until the full directory name Program Files is displayed.
PS C:\Users\Administrator>cd 'C:\Program Files'
You should now see this.
PS C:\Users\Administrator> cd 'C:\Program Files'\M
Type \M and press Tab until the directory Microsoft is displayed. (Don’t backspace over the quotation mark. It will be moved to the right when you press Tab.)
PS C:\Users\Administrator> cd 'C:\Program Files\Microsoft'
You should now see this.
PS C:\Users\Administrator> cd 'C:\Program Files\Microsoft'\ Ex
Type \Ex and press Tab until the directory Exchange Server is displayed.
PS C:\Users\Administrator> cd 'C:\Program Files\Microsoft\ Exchange Server'
You should now see this.
(Again, don’t backspace over the quotation mark. It will be moved to the right when you press Tab.)
As you can see, Tab Completion can significantly reduce the amount of typing you have to do. In Part II, “Achieving a Comfort Level with PowerShell,” you learn and practice some advanced techniques for working with PowerShell and EMS. You will explore how to pipeline, run .ps1 scripts, modify the registry with PowerShell, and customize your command-line environment. You also begin creating your PowerShell profile.
This page intentionally left blank
CHAPTER 3
Advanced Techniques
This chapter provides information and commands concerning the following topics: ■
Working with pipelines
■
Running programs
■
Creating and running scripts
■
Registry modifications with PowerShell
■
Understanding quotes
Working with Pipelines When you pipeline, you take the output of one cmdlet and use it in a subsequent cmdlet to perform another operation. This simple act ensures that you can string together very simple cmdlets into complex operations. Some of the reasons you may wish to pipeline include the following: ■
You need to pass data from the output of one cmdlet to a subsequent cmdlet.
■
You need to perform multiple actions on one or more Exchange objects without having to do so individually.
■
You need to pass data output between dissimilar nouns.
■
You need the system to report errors or warnings.
You can use pipelining to pass data from the output of one cmdlet to a subsequent cmdlet in order to perform another operation. This operation might work like what’s shown in the following table.
After acquiring a new assembly plant in Philadelphia, you need to create mailboxes in the AssemblyDB database for all users in the Assemblers OU, which is a child of the Philadelphia OU. This pipelined cmdlet retrieves a list of all users in the Assemblers OU and passes the resultset to the Enable-Mailbox cmdlet, which creates the mailboxes for those users. In Figure 3-1, you can see that there are two users in the Assemblers OU in Active Directory Users and Computers. However, in Figure 3-2, there are no mailboxes present for these users. Figure 3-3 demonstrates the cmdlet used for creating mailboxes for existing users using a Get-User cmdlet piped to an Enable-Mailbox cmdlet. Finally, in Figure 3-4, you can see that the mailboxes have been created.
Figure 3-1
Users in the Assemblers OU in Active Directory Users and Computers
Figure 3-2
No mailboxes present in the Exchange Management Console for the
Assemblers OU users
Working with Pipelines
Figure 3-3 cmdlet
39
Mailboxes for users in the Assemblers OU created with the Enable-Mailbox
Figure 3-4 Mailboxes now present in the Exchange Management Console for the Assemblers OU users
You can also use pipelining to combine several actions. In that way, you can use one cmdlet to gather the mailboxes for all managers, VPs, and anyone in the Assembly department in your organization who has an Exchange mailbox and then a second cmdlet to set multiple quota values on those distinct groups of mailboxes. Performing multiple actions on Exchange objects might work like what’s shown in the following table. Get-User -Filter {((Title -like Title1Name) -or (Title -like Title2Name) -or (Department -eq DepartmentName)) -and (RecipientTypeDetails -eq RecipientType)} | Set-Mailbox -IssueWarningQuota size1 -ProhibitSendQuota size2 -ProhibitSendReceiveQuota size3 -UseDatabaseQuotaDefaults $boolean value PS C:\Users\Administrator>Get-User -Filter {((Title -like "*Manager*") -or (Title -like "*VP*") -or (Department -eq "Assembly")) -and (RecipientTypeDetails -eq "UserMailbox")} | Set-Mailbox -IssueWarningQuota 900MB -ProhibitSendQuota 1GB -ProhibitSendReceiveQuota unlimited -UseDatabaseQuotaDefaults $false
You have very distinct groups of users who need unique quotas applied to their mailboxes. You cannot use a quota at the database level because these users are spread across multiple databases. All managers, VPs, and users in the Assembly department need these quotas applied to their mailboxes regardless of the server or database where their mailbox is located. You can combine the collecting of the distinct groups of users with the application of the unique quotas on the mailboxes with a piped cmdlet, as shown.
40
Working with Pipelines
You might not know what all of the options in the previous table are just yet, but use the cmdlets as examples of some of the ways you can perform very complex tasks using the pipelining capabilities of PowerShell. NOTE
You can pipe data between dissimilar nouns. You might find that you want to use the data from one cmdlet within another cmdlet, but the object types do not match. This can happen if one cmdlet references one noun (such as by importing information from a .csv file with an Import-CSV cmdlet, where “CSV” is the noun) and you then want to use that imported data to create a new user account as well as an Exchange mailbox, which you can do with the New-Mailbox cmdlet, where “Mailbox” is the noun. Finally, you might wish to add title and department attributes to the user account (not the mailbox), which references the “User” noun. Passing data output between dissimilar nouns might work like what’s shown in the following table. Import-CSV "C:\filename.csv" | ForEach-Object -Begin {$Pass = ConvertTo-SecureString password -asPlainText -force} -Process {New-Mailbox -Name $_.Name -UserPrincipalName "$($_.UserName)@DomainName" -OrganizationalUnit "OUName" -Database "DatabaseName" -Password $Pass -ResetPasswordOnNextLogon $true | Set-User -Title $_.Title -Department $_.Department} PS C:\Users\Administrator>Import-CSV "C:\FileFromHR.csv" | ForEach-Object -Begin {$Pass = ConvertTo-SecureString "Pa$$w0rd" -asPlainText -force} -Process {New-Mailbox -Name $_.Name -UserPrincipalName "$($_.UserName) @DomainName" -OrganizationalUnit "OUName" -Database "DatabaseName" -Password $Pass -ResetPasswordOnNextLogon $true | Set-User -Title $_.Title -Department $_.Department}
You need to import several users from a .csv file given to you by the HR department. The noun initially used is “CSV”. You then wish to create the user and the mailbox at the same time, but that requires setting a password for each user. You create a password and save it as a secure string, which the Active Directory will accept. You use a variable ($Pass) to store the secure string password. This involves the New-Mailbox cmdlet, which utilizes the “Mailbox” noun. Finally, you want to add values to title and department, which are properties of the user, so you need to reference the “User” noun to do that.
You can also report errors or warnings though pipelining, which might work like what’s shown in the following table.
Running Programs
$Name = "Custom Text" PS C:\Users\ Administrator> $Warn = "This is an example of a custom warning that you might create that could provide an onscreen warning when some condition exists."
41
This illustrates how you could pipe a string to the Write-Warning cmdlet. You could save the string in a variable, as shown in the first pair of cmdlets, and then pipe the string to Write-Warning, as shown in the second pair of cmdlets. TIP Pipelining could be used with the WriteError cmdlet as well.
Running Programs Unlike cmd.exe, Exchange Management Shell (EMS) can process cmdlets in one of two ways. It analyzes what you have typed and decides whether it should be interpreted as an expression (Typing 1 + 1 produces a result of 2 in Expression mode) or as a command, which works similarly to the way that cmd.exe works. In Command mode, if what you have typed has no errors, it will be executed. If you begin a line of code with a number, a quote, or a dollar sign ($), EMS will function in Expression mode. This can be observed when you type $compute = 1+1 and press Enter. When you subsequently type $computer and press Enter, the output will be the number “2”. What if you are interested in running a program and you have defined the variable $Prog to run it—how can you tell EMS to execute $Prog as a command and not display it as a value? The use of the ampersand (&) character is how you can do this, as shown in the following table. PS C:\Users\ Administrator>$Prog= C:\Windows\System32\ calc.exe PS C:\Users\ Administrator>$Prog PS C:\Users\ Administrator>&$Prog
If you define the variable $Prog as shown in the example, the Windows Calculator will not launch when you subsequently type $Prog, but the result that is displayed will be C:\Windows\System32\ calc.exe. EMS is displaying the value of the variable, not executing it. However, if you type &$Prog, the Windows Calculator will launch successfully.
To run a batch file, you need cmd.exe to launch first, so you could do something like what’s shown in the following table.
42
Creating and Running Scripts
PS C:\Users\ Administrator>cmd.exe /c MyTest.bat
Here, /c tells the batch file to carry out the command and then terminate cmd.exe It is not necessary to use & with cmd.exe.
For a VBScript executable, you also need cmd.exe to launch first, so you could do something like what’s shown in the following table. PS C:\Users\Administrator> &"cscript.exe MyVBScript.vbs param1 param2"
Because you are launching another executable, & is required.
To run PowerShell scripts from a cmd.exe prompt, you need to use powershell.exe. In previous versions of PowerShell, you used msh.exe. Powershell.exe is run as shown in the following table. PS C:\Users\ Administrator> powershell.exe-noexit "C:\MyScripts\MyTest.ps1"
Powershell.exe is the Windows PowerShell executable. TIP You can use Task Scheduler as you normally would to schedule the running of the script.
The -noexit switch is an optional parameter that tells the PowerShell console to remain open after the script finishes.
TIP If the focus of the cmd.exe prompt is on the same directory that the .ps1 file resides in, it is not necessary to type the path. Simply type .\ and the name of the .ps1 script, like this:PS C:\Users\Administrator>.\MyTest.ps1.
This technique will be illustrated in the section that follows.
Creating and Running Scripts In most cases, you will run individual cmdlets to achieve your desired result, and with the use of pipelining you can combine cmdlets together to allow for creative results. However, just like from a Windows command prompt, a single line of code may not be able to provide you with the ability to do everything you desire. From the Windows command prompt, it is common to use a .bat file to group multiple commands into a single file, but that will not work in Exchange Management Shell. But, do not fear. PowerShell offers support for a scripting language, based on the Microsoft .NET Framework, and those scripts can be used to automate tasks or run multiple cmdlets together when pipelining is not appropriate. The Shell lets you create scripts, assign variables in the scripts, perform looping operations, and use conditional logic in the scripts. This is all done within a text file using PowerShell cmdlets. When you save the text file with a .ps1 extension, it is executable from Exchange Management Shell.
Creating and Running Scripts
43
By creating your own library of these .ps1 scripts, you can automate tasks and efficiently run your scripts on any computer that has Exchange Management Shell installed on it. The following example illustrates how to create a script to perform the five steps necessary to configure Messaging Records Management. Create a text file with a .ps1 extension. In the example that follows, the file will be called C:\ Users\Administrator\MRM_Retention.ps1.
Five steps are involved in configuring Messaging Records Management. This is commonly configured from Exchange Management Console (prior to Service Pack 1) because each step is performed in a unique place and no single cmdlet will perform all five steps. However, in the Console, there is no single wizard that will perform all five steps either. Therefore, you want to create a script to perform all five steps together in a PowerShell script.
Step 1: Create a new managed custom folder. Name refers to the Exchange name of the object and FolderName refers to the name that the user sees on the folder in his or her mailbox. Many times they will be the same, but both have to be specified.
TIP
Create a variable to use in step 2. TIP The example uses $AgeLimit, but any name could be used for the variable. NOTE This is not normally a step required for Messaging Records Management. The example that was chosen requires a variable, and this provides the necessary variable for step 2.
Step 5: Schedule the Managed Folder Assistant to run each day. TIP $ServerName defines a variable with the name of the server as the value of the variable.
Alternate step 5: Start the Managed Folder Assistant manually.
# Step 1: Create a new managed custom folder. New-ManagedFolder -Name "Retention" -FolderName "Retention" # Create a variable, "$AgeLimit," to use in Step Number 2. $AgeLimit = New-TimeSpan -Day 1100 # Step 2: Create managed content settings for the 3 Year Retention Folder that permanently deletes all items after 3 years or 1100 days. New-ManagedContentSettings -Name "Retention Settings for Retention Folder" -FolderName "Retention" -MessageClass * -RetentionEnabled:$true -AgeLimitForRetention $AgeLimit -RetentionAction PermanentlyDelete # Step 3: Create a managed folder mailbox policy. New-ManagedFolderMailboxPolicy -Name "Executives Mailbox Policy" -ManagedFolderLinks "Retention" # Step 4: Apply the managed folder mailbox policy to a mailbox. Set-Mailbox -Identity Administrator -ManagedFolderMailboxPolicy "Executives Mailbox Policy" # Step 5: Start the Managed Folder Assistant manually. Start-ManagedFolderAssistant
The completed script with all steps combined in a file. The # sign indicates a remark, and that line will not be executed. Save this file with a name such as C:\Users\ Administrator>MRM_ Retention.ps1. TIP There is no need to use the path in each step of the script when you run it from within the .ps1 file.
The .ps1 file in the previous example could be created with Notepad.exe or any text editor. It does not have to be created from within EMS. NOTE
46
Creating and Running Scripts
PS C:\Users\Administrator>.\ MRM_Retention.ps1
Figure 3-5
Run the script as shown in Figure 3-5.
Running the MRM_Retention.ps1 script created in the example
Figures 3-6, 3-7, 3-8, and 3-9 show the results after the script has been run.
Figure 3-6 Custom folder and content settings on a folder viewed from the Exchange Management Console
Figure 3-7 Console
Managed folder mailbox policy viewed from the Exchange Management
Creating and Running Scripts
Executive Mailbox Policy
Figure 3-8 Executives mailbox policy linked to a user, as viewed from the Exchange Management Console
Retention Folder
Figure 3-9
Retention folder viewed on user’s Outlook Web App client
47
48
Registry Modifications with PowerShell
Registry Modifications with PowerShell It is very easy to modify the registry of a server by using Exchange Management Shell and the Set-ItemProperty cmdlet. Performing the registry change from within Exchange Management Shell means that you can incorporate the change into a .ps1 script, and you can also pipeline it to multiple servers as needed. You must have permission to make this change or your attempt will fail. The examples in the following table illustrate how to change the timeout values for the OWA cookies used by forms-based authentication on a Client Access Server. Changes made to the Windows registry happen immediately. Do not edit the Windows registry with Exchange Management Shell or any other registry-editing program unless you are confident about doing so. It is especially dangerous doing this in PowerShell because of the potential for typographical errors. NOTE
Use the following cmdlets at your own risk. Set-ItemProperty RegistryPath -Name TimeoutType -Value TimeInMinutes -Type RegistryValueType PS C:\Users\Administrator> Set-ItemProperty "HKLM:\SYSTEM\ CurrentControlSet\Services\ MSExchange OWA" -Name PrivateTimeout -Value 360 -Type Dword Set-ItemProperty RegistryPath -Name TimeoutType -Value TimeInMinutes -Type RegistryValueType PS C:\Users\Administrator> Set-ItemProperty "HKLM:\SYSTEM\ CurrentControlSet\Services\ MSExchange OWA" -Name PublicTimeout -Value 30 -Type Dword
This example sets the Private Computer cookie timeout value to 360 minutes, or 6 hours, for the Outlook Web App client. The default value for the Private Computer cookie timeout is 720 minutes, or 12 hours. NOTE
This example sets the Public Computer cookie timeout value to 30 minutes for the Outlook Web App client. The default value for the Public Computer cookie timeout is 15 minutes. NOTE
Understanding Quotes PowerShell uses four different types of quotes. As an administrator, you are most interested in single ordinary and double ordinary quotes. A developer would be more interested in the here-strings. The four types of quotes are explained in the following table.
Understanding Quotes
Single ordinary quotes: $a="Champs" 'World $a' => World $a
Double ordinary quotes: $a="Champs""World $a" => World Champs
Single here-strings: $b="Two" $x = @' " Easy as One $b Three ! " '@ $x produces: " Easy as One $b Three ! "
Double here-strings: $b="Two" $x = @" " Easy as One Two Three ! " "@ $x produces: " Easy as One Two Three ! "
49
In single quotes, variable names are not expanded and escape sequences are not interpreted. Inside double quotes, variable names are replaced with their values and PowerShell escape sequences are interpreted. In single here-strings, variable names are not expanded and escape sequences are not interpreted. A single here-string begins with @’ and ends with ’@. PowerShell here-strings are similar to heredocuments in Perl.
Inside double here-strings, variable names are replaced with their values and PowerShell escape sequences are interpreted. A double here-string begins with @” and ends with “@. PowerShell here-strings are similar to heredocuments in Perl.
This page intentionally left blank
CHAPTER 4
Customizing the PowerShell Environment
This chapter provides information and commands concerning the following topics: ■
Creating and using PowerShell profiles
■
Using built-in aliases
■
Working with user-defined aliases
■
Filtering output
■
Formatting output
Creating and Using PowerShell Profiles You have begun to create your own aliases, variables, and possibly even some functions, and you might be frustrated by the fact that they are only available in the current Exchange Management Shell (EMS) session. When you close the session, your customized settings are lost. This is because your custom-defined objects and their definitions exist and are stored only in memory on the system you are working on. If you would like to have them available in any session, you need to create a PowerShell profile script that utilizes a .ps1 file. As shown in the following table, the profile type is defined by where it is stored in the Windows file system. %windir%\System32\ WindowsPowerShell\ v1.0\ Microsoft.PowerShell_ profile.ps1
Here is the location of the PowerShell profile script that affects all users. It is available to all users on an Exchange server or administrator’s workstation that has the Exchange Management Tools installed on it. If no profile exists in that directory, the user receives the default profile. This does not imply that all users will have permission to run everything in the profile simply because they have access to the profile. NOTE
%userprofile%\ My Documents\ WindowsPowerShell\ Microsoft.PowerShell_ profile.ps1
Here is the location of the PowerShell profile script that affects only the current user. It is available only to the user who is logged on to an Exchange server or an administrator’s workstation that has the Exchange Management Tools installed on it.
52
Creating and Using PowerShell Profiles
When you start EMS, it checks these two locations on the server or workstation on which it has been started and loads the Microsoft.PowerShell_profile.ps1 profile files, if any are located. The one for all users is loaded first and then the current user profile file is loaded, if both are present. Usually, you would put the customizations that several users require in the System32 location and the customizations that only you require in the current user profile location. To create your own current user profile file, open Notepad and use the New-Item cmdlet as shown in the following table. PS C:\Users\ Administrator>New-Item -Path $profile -ItemType File-Force
Figure 4-1
Creates the profile file for the current user, as shown in Figure 4-1.
Creating the PowerShell profile file
The profile that has been created is shown in the following table. PS C:\Users\ Administrator>$profile
By typing the variable $profile, you can validate that the profile has been successfully created. TIP This variable is built in to Exchange Management Shell (PowerShell) and always points to the path for the current user.
PS C:\Users\ Administrator>Notepad $profile
Opens the PowerShell profile file in Notepad. Figure 4-2 shows the execution of this command as well as a completed PowerShell profile file. Save the Notepad file, relaunch Exchange Management Shell, and all of your “shortcuts” are loaded into memory and are ready to go.
Creating and Using PowerShell Profiles
Figure 4-2
53
Opening the PowerShell profile file and adding your custom settings
As shown in Figure 4-2, three types of settings have been configured: aliases, functions, and variables. There is no denying the fact that Exchange Management Shell requires a good deal of typing unless you have created one or more scripts. For that and other reasons, you are able to create aliases, functions, and variables and then incorporate them into your PowerShell profile. Alias: PS C:\Users\ Administrator> Set-Alias GetDB Get-MailboxDatabase
An alias does two things for you. It reduces the amount of repetitive typing required and it decreases the number of typos that occur. You might want to create your own aliases and make them available whenever you launch EMS. This example demonstrates one custom administratordefined alias. Whenever the administrator needs a list of all the mailbox databases in the organization, he or she need only type getdb from a PS prompt, as shown in Figure 4-3.
A function is a block of code that is given a name. When you run a function, you need only type the function name. The code is defined in your profile file. Functions can be very basic, such as this example, or as complex as an application. Like cmdlets, functions can have parameters. The function can return values that can be displayed, assigned to variables, or even passed to other functions or cmdlets. PowerShell 2.0 greatly enhances functions with the use of advanced functions. Without using a function, this very simple verbnoun combination (Get-Mailbox) would be easy enough to type if it weren’t for the large number of parameters used. These extensive parameters would require a lot of typing every time you wanted to retrieve this information. By creating a function, you can simply type Get-MyMailbox whenever you need to retrieve the updated information, as shown in Figure 4-4. TIP If you try this function, notice that GetMyMailbox will autocomplete when you type Get-M and press the Tab key after the function has been defined.
A variable is a place for storing data. PowerShell (and other programming languages) not only can store text strings and numeric data, but also objects. When you define a variable (whether you define it from the PowerShell profile or just type it from a PS prompt), you place a $ before its name. This helps distinguish between what’s a variable and what’s an alias or function. When you open Exchange Management Shell, a number of variables are automatically defined. By including variables in your profile, you make them available from wherever you access the Exchange Management Shell, as shown in Figure 4-5.
Figure 4-5
Using custom variables
The following table shows the Administrator’s PowerShell profile with all of the preceding aliases, functions, and variables defined. Create it as a .txt file and save it with a .ps1 extension. # This is the Administrator's PowerShell Profile. # It was created on 9/23/2010 and most recently, it was modified on 10/4/2010. # These are my Aliases: Set-Alias GetDB Get-MailboxDatabase # These are my Functions: Function Get-MyMailbox { param($Name) Get-Mailbox $Name | Format-List Name, Database, OrganizationalUnit, IssueWarningQuota } # These are my Variables: $SquareNumber1 = [int]1 $SquareNumber2 = [int]4 $SquareNumber3 = [int]9 $SquareNumber4 = [int]16 $SquareNumber5 = [int]25
The example here shows the complete PowerShell profile, including all remarks, indicated by the # symbol. Most profiles are much more complex. This example attempts to illustrate how easy a PowerShell profile is to create. The complexity of the profile comes from what you put into the .ps1 file.
56
Using Built-in Aliases
Using Built-in Aliases A number of aliases come built in. For example, when you type ft, you are actually using an alias that maps to the cmdlet Format-Table. You don’t need to include any built-in aliases in your PowerShell profile file. You already have access to them even if you are not using a PowerShell profile. PS C:\Users\ Administrator> Get-Alias PS C:\Users\ Administrator> Get-Alias | Measure
This cmdlet allows you to view the list of the built-in aliases included with Exchange Management Shell. There are 139 built-in aliases in Exchange Management Shell in the RTM version of Exchange 2010. The second example will count them for you. (Note the use of an alias to count the number of aliases. Measure is an alias for Measure-Object.)
Although not a complete list, the following table shows some of the more frequently used built-in aliases. In the following table, some of the aliases use symbols (such as %) rather than abbreviations. NOTE
Alias
Cmdlet
Alias
Cmdlet
%
ForEach-Object
gci
Get-ChildItem
?
Where-Object
gcm
Get-Command
cd
Set-Location
gl
Get-Location
chdir
Set-Location
gm
Get-Member
clc
Clear-Content
gsv
Get-Service
clear
Clear-Host
gv
Get-Variable
cls
Clear-Host
gwmi
Get-WmiObject
clv
Clear-Variable
ipal
Import-Alias
compare
Compare-Object
ipcsv
Import-Csv
copy
Copy-Item
kill
Stop-Process
cp
Copy-Item
list
Format-list
cpi
Copy-Item
lp
Out-Printer
del
Remove-Item
ls
Get-ChildItem
Diff
Compare-Object
md
Mkdir
dir
Get-ChildItem
measure
Measure-Object
echo
Get-ChildItem
move
Move-Item
epal
Write-Output
nal
New-Alias
epcsv
Export-Csv
nv
New-Variable
erase
Remove-Item
pwd
Get-Location
fc
Format-Custom
sal
Set-Alias
Working with User-Defined Aliases
Alias
Cmdlet
Alias
Cmdlet
fl
Format-List
set
Set-Variable
foreach
ForEach-Object
si
Set-Item
ft
Format-Table
sl
Set-Location
fw
Format-Wide
sv
Set-Variable
gal
Get-Alias
table
format-table
write
Write-Output
57
Working with User-Defined Aliases User-defined aliases stored in your PowerShell profile will be quite handy when it is necessary to perform repetitive tasks. Let’s say you need to run the following three reports each week. All three reports use the Get-MailboxStatistics cmdlet. Because the parameters in each report are fairly long to type and the required attributes do not autocomplete when you press the Tab key, this can become quite tedious. Look at the amount of typing that would be required to generate these reports each week. One frequently required and requested PS C:\Users\Administrator> report that you might need is a list of all Get-Mailbox | mailboxes that haven’t been accessed in Get-MailboxStatistics the last X days. (In the example, 100 days -IncludeMoveHistory | Where is used as the value.) But here is a wrinkle: {$_.LastLogonTime -lt You also need to see whether the mailbox (get-date).AddDays(-100)} | fl has been moved during that time. DisplayName, LastLogonTime, The output of this cmdlet is shown in LastLoggedOnUserAccount, Figure 4-6. ServerName, MoveHistory PS C:\Users\Administrator> At the same time, you also might need a list of all mailboxes that have never been Get-Mailbox | logged on to before. Get-MailboxStatistics | Where {$_.LastLogonTime -eq $null | fl DisplayName, LastLogonTime, LastLoggedOnUserAccount, ServerName PS C:\Users\Administrator> Get-Mailbox | Get-MailboxStatistics | Where {$_.DisconnectDate -gt (get-date).AddDays(-14)} | fl DisplayName, ServerName, DatabaseName, TotalItemSize
You may also have to run a report detailing all mailboxes that have been disabled in the past 14 days. In this example, you want to know what server the mailboxes are located on, in which databases they reside, and the amount of data in each mailbox.
58
Working with User-Defined Aliases
Figure 4-6
Mailboxes that haven’t been accessed in past 100 days
You could cut and paste these from Notepad, but there is an easier way. Create userdefined aliases for your three reports, as shown in the following table. PS C:\Users\Administrator>Set-Alias NoAccess100 NoAccess100 Get-Mailbox |Get-MailboxStatistics -IncludeMoveHistory | Where {$_.LastLogonTime -lt (get-date).AddDays(-100)} | fl DisplayName, LastLogonTime, LastLoggedOnUserAccount, ServerName, MoveHistory PS C:\Users\Administrator>Set-Alias NeverLoggedOn Get-Mailbox | Get-MailboxStatistics | Where {$_.LastLogonTime -eq $null | fl DisplayName, LastLogonTime, LastLoggedOnUserAccount, ServerName
Isn’t it nice to know that you don’t have to type these three long cmdlets each and every week? Simply type the aliases shown on the right after they have been properly defined. TIP Put these aliases in your PowerShell profile and they will be available from wherever you need to run them.
Filtering Output
59
Filtering Output With Exchange Management Shell, you get what you ask for. You want to request only the data you are required to work with and do not want to retrieve unneeded data, as shown in the following tables. PS C:\Users\ Administrator> Get-Mailbox
For example, this cmdlet retrieves a list of all users in your organization with Exchange mailboxes.
If you have 50 users, this may be what you need to retrieve. But, what if you have 50,000 users? There’s not much chance that this cmdlet executed without any filtering will produce meaningful results in a large environment.
Here are some basic options for doing that: -OrganizationalUnit filters by Active Directory OU.
-Database filters by Exchange database. -RecipientTypeDetails filters by the type of recipient. LegacyMailbox recipients are those recipients from Exchange 2000/2003. This can be helpful when you are moving recipients from Exchange 2000/2003 to 2010.
How can filtering be put to practical use? Suppose you have just migrated to a new storage area network (SAN). You want to increase the quotas on your sales peoples’ mailboxes, but right now, you only want to increase quotas for sales people with mailboxes on Romac-EX2. The problem is that no specific collection or group includes only sales people with mailboxes on Romac-EX2. If you execute the first cmdlet, with only the -OrganizationalUnit parameter, all sales peoples’ mailboxes will be returned, as shown in Figure 4-7. No problem. Add the -Server parameter as shown in the second cmdlet. Figure 4-7 also shows the results returned when the second attribute is added.
By adding the pipe character and using the SetMailbox cmdlet with the -ProhibitSendQuota attribute, you can easily achieve your goal, as shown in Figure 4-8. Moe’s mailbox’s ProhibitSendQuota has been increased to 200MB. (Moe is the only sales person with a mailbox on Romac-EX2.)
-ProhibitSendQuota 200MB
Figure 4-8
Setting the ProhibitSendQuota attribute on the desired mailboxes
Formatting Output Exchange Management Shell uses predefined output modes to display data from the command line. However, you are not limited to those modes. For example, if you issue a Get-Mailbox cmdlet, four columns will be displayed in a table as the output. Name
Alias
ServerName
ProhibitSendQuota
Larry Fine
Larry
romac-ex1
unlimited
Moe Howard
Moe
romac-ex1
unlimited
Curly Howard
Curly
romac-ex1
unlimited
Formatting Output
61
If you only need to view the mailboxes in your organization, this may be sufficient. However, it is not very likely that those four columns are exactly the columns you would like to retrieve. For example, if you only have a single Exchange server, the ServerName column has little significance for you. Every mailbox will have the same value for ServerName, as is the case with romac-ex1 in the previous table. Also, if you are not using quotas, the ProhibitSendQuota column is not relevant for you either. In a single-server environment, the following cmdlet might make more sense. PS C:\Users\ Administrator>Get-Mailbox | Format-Table Name, Database, PrimarySMTPAddress, OrganizationalUnit, IsResource
Formatted this way, you can see the Name and Database attributes, along with three other important attributes that you might wish to view. But now, the problem is that because there are five columns (which will not fit entirely on the screen), the data is truncated, as shown in the next table.
The output doesn’t look very attractive and sometimes important information will be truncated, as shown in the following table. Name
Try it again with Autosize. With the Autosize parameter, Exchange Management Shell will calculate the maximum number of columns that can be displayed without truncating the data. PS C:\Users\Administrator> Get-Mailbox | Format-Table Name, Database, PrimarySMTPAddress, OrganizationalUnit, IsResource-Autosize
Try the same cmdlet with the Autosize option.
The output looks much better now, as shown in the following table. Name
You can also use the -Wrap option to have the output scroll to the next line onscreen.
TIP
Sometimes formatting the output in a table just doesn’t make sense. If you need to view many attributes, for instance, formatting the output as a table would not make sense. Also, if the order of the output is important, formatting as a list can help. Use the Format-List option to make all attributes accessible from one output screen in the order you designate. PS C:\Users\Administrator> Get-Mailbox -Identity Moe | Format-List Name, Database, PrimarySMTPAddress, OrganizationalUnit, IsResource, ProhibitSendQuota, IssueWarningQuota
Figure 4-9
This cmdlet is the same as the previous one, with two additional attributes. The output is formatted as a list instead of as a table (see Figure 4.9).
Formatting the output as a list
There is also a Format-Wide option. The Format-Wide (or fw) option allows you to retrieve single-item data and display that data in multiple columns. By default, Format-Wide displays data in two columns, but you can specify more with the columns option.
TIP
You can also output to a file if that information must be exported. The file could be a .txt file, a .csv file, an .xml file, or even an .html file. The following examples illustrate how to take output from the cmdlet and write it to the appropriate type of file. PS C:\Users\Administrator>Get-Mailbox -Identity Moe | Format-List Name, Alias, Database, PrimarySMTPAddress, OrganizationalUnit, IsResource, ProhibitSendQuota, IssueWarningQuota | Out-File-FilePath C:\ Demos\moe.txt
You might think you could open the file you just created with an Open-File cmdlet, but no such cmdlet exists. You may either use the Get-Content cmdlet to view the content or use the appropriate application (such as Notepad.exe or Microsoft Internet Explorer) as shown in the following table. PS C:\Users\Administrator> Get-Content "C:\Demos\moe.txt"
Viewing the content or opening the .txt file.
or PS C:\Users\Administrator> Notepad "C:\Demos\moe.txt" PS C:\Users\Administrator> Get-Content "C:\Demos\services.csv"
Viewing the content or opening the .html file in Internet Explorer.
or PS C:\Users\Administrator> Invoke-Item C:\Users\Administrator\service_ red_alert.html
You can open the file in Microsoft Excel, but that will require writing a script to do so. Several examples of such a script can be found on the Web, but that borders on development, and this book is written primarily for administrators. NOTE
This page intentionally left blank
CHAPTER 5
Standard Deployments
This chapter provides information and commands concerning the following topics: ■
Deploying prerequisites for all versions of Exchange Server 2010 on Windows Server 2008 operating systems
■
Deploying prerequisites for Exchange Server 2010 RTM (Release-toManufacturing) on Windows Server 2008 SP2
■
Deploying prerequisites for Exchange Server 2010 RTM on Windows Server 2008 SP2
■
Deploying prerequisites for Exchange Server 2010 RTM on Windows Server 2008 R2
■
Deploying prerequisites for Exchange Server 2010 SP1 on Windows Server 2008 R2
■
Setup options for Exchange Server 2010 RTM
■
Upgrading from Exchange Server 2010 RTM to SP1
■
Using the Exchange 2010 Deployment Assistant
Deployments of Exchange Server 2010 are not performed using Windows PowerShell cmdlets; however, the installation of the prerequisites can now be facilitated using PowerShell on Windows Server 2008 R2. Even with simple deployments, there are different scenarios for installing prerequisites, depending on the operating system and version of Exchange Server. Before installing Exchange 2010, you must ensure that both your domain functional levels for all of your domains as well as the forest functional level have been raised to at least 2003 mode. Your Schema Master FSMO (Flexible Single Master Operation) role must be running a minimum of Window Server 2003 SP1.
Deploying Prerequisites for All Versions of Exchange Server 2010 on Windows Server 2008 Operating Systems The following table details the prerequisites for Exchange Server 2010. Microsoft .NET Framework 3.5 Service Pack 1 (SP1).
Microsoft .NET Framework 3.5 Service Pack 1 is a full cumulative update that incorporates elements from .NET Framework 2.0, 3.0, and 3.5.
66
Deploying Prerequisites for Exchange Server 2010 RTM on Windows Server 2008 SP2
Windows Remote Management (WinRM) 2.0.
WinRM is the Microsoft implementation of WS-Management Protocol.
Windows PowerShell V2 (Windows6.0KB968930.msu).
As discussed previously, Windows PowerShell V2 provides significant improvements, features, and options over Windows PowerShell V1.
If your Exchange server will be hosting either the Mailbox or Hub Transport role, you will need to install the Microsoft Filter Pack, as shown in Figure 5-1.
On Exchange 2010 RTM, you can meet this prerequisite by installing 2007 Office System Converter: Microsoft Filter Pack. It is recommended that you upgrade to Microsoft Office 2010 Filter Packs.
Figure 5-1
The WS-Management Protocol specification provides a common way for systems to access and exchange management information across an IT infrastructure.
You must uninstall PowerShell 1.0 (if present) to install V2.
In SP1 this requirement has been changed. The Office 2010 Filter Pack is now required.
Microsoft Filter Pack installation
Deploying Prerequisites for Exchange Server 2010 RTM (Release-to-Manufacturing) on Windows Server 2008 SP2 The prerequisites for Exchange Server 2010 RTM on Windows Server 2008 SP2 are presented in the following table for completeness, but it is highly suggested that you
Deploying Prerequisites for Exchange Server 2010 RTM on Windows Server 2008 SP2
67
install Exchange Server on Windows Server 2008 R2. With each new operating system or Exchange service pack, the prerequisite installation becomes easier. Microsoft .NET Framework 3.5 Family Update for Windows Vista x64, and Windows Server 2008 x64 updates
Resolves a set of known application compatibility issues with Microsoft .NET Framework 3.5 Service Pack 1.
Microsoft Knowledge AD RMS (Active Directory Rights Management Services) Base article 977624 clients do not authenticate federated identity providers in update Windows Server 2008 or in Windows Vista. Resolves the issue of AD RMS features that may stop working without this update. Microsoft Knowledge Resolves the issue of Windows Communication Foundation Base article 982867 (WCF) services that are hosted by computers together in a hotfix Network Load Balancing (NLB) cluster that can fail in .NET Framework 3.5 SP1 without this hotfix. Microsoft Knowledge Resolves the issue of a .NET Framework 2.0–based MultiBase article 979744 AppDomain application that may stop responding when you update run the application. Microsoft Knowledge Resolves issues that can occur when you deploy an ASP.NET Base article 979917 2.0–based application on a server that is running IIS 7.0 or IIS update 7.5 in Integrated mode. Microsoft Knowledge Resolves the issue of an exception error message that can Base article 973136 occur when a .NET Framework 2.0 SP2–based application update tries to process a response with zero-length content to an asynchronous ASP.NET Web Service request: “Value cannot be null”. Microsoft Knowledge Resolves the issue of RPC over HTTP clients that cannot conBase article 977592 nect to the Windows Server 2008 RPC over HTTP servers update that have RPC load balancing enabled.
Deploying Prerequisites for Exchange Server 2010 RTM on Windows Server 2008 SP2 These are not PowerShell cmdlets. You must launch a command prompt with elevated permissions and navigate to the \Setup\ServerRoles\Common folder on the Exchange 2010 installation media. From there, you would type the following commands at a command prompt (each line is a separate command) to install the necessary operating system components. NOTE
The following table shows how the command-line version of Server Manager is used to install Exchange Server 2010 prerequisites on Windows Server 2008 platforms.
68
Deploying Prerequisites for Exchange Server 2010 RTM on Windows Server 2008 SP2
sc config NetTcpPortSharing start= auto ServerManagerCmd -ip Exchange-Typical.xml -Restart
NET.TCP Port Sharing Service is manual, by default, so you must set it to Automatic start and then start the service. The first command does this using the Service Control Manager (sc) command. For a server that will have the Typical installation of Client Access, Hub Transport, and the Mailbox role, the second command will use the appropriate .xml file to install the necessary prerequisites. The ip stands for inputpath and must be followed by an .xml file. NOTE
The -Restart switch really does automatically restart the server after installation of the prerequisites. Make sure you have saved your work if any other applications are open on the server.
For a server that will host the Hub Transport and Mailbox server roles.
sc config NetTcpPortSharing start= auto ServerManagerCmd -ip Exchange-Typical.xml -Restart
For a server that will host the Client Access and Mailbox server roles.
sc config NetTcpPortSharing start= auto ServerManagerCmd -ip Exchange-CAS.xml -Restart
For a server that will host only the Client Access role.
ServerManagerCmd -ip Exchange-Hub.xml -Restart
For a server that will host only the Hub Transport role.
ServerManagerCmd -ip Exchange-MBX.xml -Restart
For a server that will host only the Mailbox role.
ServerManagerCmd -ip Exchange-UM.xml -Restart
For a server that will host only the Unified Messaging role.
ServerManagerCmd -ip Exchange-Edge.xml -Restart
For a server that will host the Edge Transport role.
The i stands for install and must be followed by the name of the feature that you wish to install. NOTE
Deploying Prerequisites for Exchange Server 2010 RTM on Windows Server 2008 R2
69
Deploying Prerequisites for Exchange Server 2010 RTM on Windows Server 2008 R2 These are PowerShell cmdlets. By using the Import-Module ServerManager cmdlet, you are accessing Server Manager from within PowerShell. Simply type the cmdlets below (all on one line for each cmdlet) from a PS prompt after you have imported the Server Manager module into Windows PowerShell. NOTE
The following table shows the PowerShell cmdlets used to install Exchange Server 2010 prerequisites on Windows Server 2008 R2 platforms. Import-Module ServerManager
From the Start Menu, navigate to All Programs, then Accessories, and then Windows PowerShell. Open an elevated Windows PowerShell console and run the Import-Module ServerManager cmdlet. Don’t forget that on servers that will host the Hub Transport or Mailbox server role, you must install the Microsoft Filter Pack. NOTE
For a server that will have the Typical installation of Client Access, Hub Transport, and the Mailbox roles, use the Add-WindowsFeature cmdlet to install the necessary operating system components, as shown on the left and in Figure 5-2. The -Restart switch really does automatically restart the server after installation of the prerequisites. Make sure you have saved your work if any other applications are open on the server.
TIP
Installing the prerequisites for a typical install on Windows Server 2008 R2
70
Deploying Prerequisites for Exchange Server 2010 RTM on Windows Server 2008 R2
The procedure for installing prerequisites for the other Exchange Server 2010 roles on Windows Server 2008 R2 is detailed in the following table. Add-WindowsFeature NET-Framework, RSAT-ADDS,Web-Server,Web-Basic-Auth, Web-Windows-Auth,Web-Metabase, Web-Net-Ext,Web-Lgcy-Mgmt-Console, WAS-Process-Model,RSAT-Web-Server, Web-ISAPI-Ext,Web-Digest-Auth, Web-Dyn-Compression, NET-HTTP-Activation, RPC-Over-HTTP-Proxy, Desktop-Experience -Restart
For a server that will host the Client Access, Hub Transport, Mailbox, and Unified Messaging server roles, use the AddWindowsFeature cmdlet to install the necessary operating system components, as shown on the left.
For a server that will host the Client Access and Hub Transport server roles, use the AddWindowsFeature cmdlet to install the necessary operating system components, as shown on the left.
For a server that will host the Hub Transport and Mailbox server roles, use the AddWindowsFeature cmdlet to install the necessary operating system components, as shown on the left.
For a server that will host the Client Access and Mailbox server roles, use the AddWindowsFeature cmdlet to install the necessary operating system components, as shown on the left.
Deploying Prerequisites for Exchange Server 2010 RTM on Windows Server 2008 R2
For a server that will host only the Client Access role, use the Add-WindowsFeature cmdlet to install the necessary operating system components, as shown on the left.
For a server that will host the Hub Transport or the Mailbox role, use the AddWindowsFeature cmdlet to install the necessary operating system components, as shown on the left.
For a server that will host only the Unified Messaging role, use the Add-WindowsFeature cmdlet to install the necessary operating system components, as shown on the left.
For a server that will host the Edge Transport role, use the Add-WindowsFeature cmdlet to install the necessary operating system components, as shown on the left and in Figure 5-3.
Figure 5-3 2008 R2
Installing the prerequisites for an Edge Transport install on Windows Server
You also must set the Net.Tcp Port Sharing Startup Type to Automatic and start the service. The cmdlet shown in the following table achieves that goal using PowerShell in Windows Server 2008 R2.
72
Deploying Prerequisites for Exchange Server 2010 SP1 on Windows Server 2008 R2
On servers that will have the Client Access Server role installed, after the system has restarted, log on as an administrator, open an elevated Windows PowerShell console, and configure the Net.Tcp Port Sharing Service for Automatic startup by running the command on the left. Figure 5-4 shows the Services console after the command has been run.
Figure 5-4 Viewing the startup type and condition of the Net.Tcp Port Sharing Service in the Services console
Deploying Prerequisites for Exchange Server 2010 SP1 on Windows Server 2008 R2 Installing prerequisite software for Exchange 2010 SP1 has become even more simplified, especially when you’re installing Exchange on Windows Server 2008 R2. If you have installed prerequisites on Exchange Server 2010 prior to SP1 and you haven’t used some of the automation techniques discussed earlier, you know how painful it can be. However, when you use the Exchange Server 2010 SP1 (GUI) Setup Wizard, a new feature called “Automatically install Windows Server roles and features required for Exchange Server” is available by checking a box (see Figure 5-5).Yes, by selecting the check box, all prerequisites will be installed automatically. That is very nice! NOTE
Deploying Prerequisites for Exchange Server 2010 SP1 on Windows Server 2008 R2
Figure 5-6 shows the features that have been installed after the “Automatically install Windows Server roles and features required for Exchange Server” check box has been selected and the installation has completed.
Figure 5-5
Exchange Server 2010 SP1 Setup Wizard with the new feature selected
Figure 5-6 Wizard
Features installed automatically by the Exchange Server 2010 SP1 Setup
73
74
Setup Options for Exchange Server 2010 RTM
Setup Options for Exchange Server 2010 RTM Exchange Server 2010 is available in two server editions: Standard Edition and Enterprise Edition. You define which edition is enabled by the product key you enter. Both RTM and SP1 versions are currently available. There are two versions of Setup. Setup.exe is the graphical user interface, and you are guided through the installation by the Setup Wizard. Setup.com is the unattended (command-line) interface, where you provide options for Setup by using command-line switches. Both versions are available from the Exchange 2010 DVD or across the network. As shown in the following table, a number of Active Directory preparations must be performed before any version of Exchange Server 2010 can be installed. D:\SetupFiles>Setup.com /PrepareLegacyExchangePermissions D:\SetupFiles>Setup.com /pl
If you have any computers in your organization running Exchange 2003, open an elevated command prompt and then run the command in the example. D:\SetupFiles could represent any location where the setup files would be found. NOTE
TIP /pl could be used in place of /PrepareLegacy ExchangePermissions, as shown in the second example.
This command connects to the Active Directory Schema Master FSMO role and imports LDAP Data Interchange Format (LDIF) files. These files update the schema with Exchange 2010–specific objects and attributes. TIP /ps could be used in place of /PrepareSchema, as shown in the second example.
This command creates the Microsoft Exchange container in Active Directory, if it doesn’t already exist. If no Exchange organization container exists, you must specify an organization name by using the / OrganizationName parameter. The organization container will be created with the name that you specify. This command also verifies that the schema has been updated. If it has not, this command will create the containers, objects, and attributes necessary for the installation of Exchange Server 2010. This command also verifies that the permissions have been updated if any previous versions of Exchange Server exist in the Active Directory. Next, this command creates the Microsoft Exchange Security Groups Organizational Unit (OU) in the root domain of the forest and populates the OU with all of the new 2010 management role groups. The command also prepares the local domain for Exchange 2010. /p could be used in place of /PrepareAD and /on could be used in place of /OrganizationName, as shown in the second pair of examples.
This command prepares the specified domain for Exchange 2010. /pd could be used in place of /PrepareDomain, as shown in the second pair of examples.
TIP
76
Setup Options for Exchange Server 2010 RTM
This command prepares all domains in the forest for Exchange 2010.
D:\SetupFiles>Setup.com /PrepareAllDomains
/pad could be used in place of /PrepareAllDomains, as shown in the second example.
TIP
D:\SetupFiles>Setup.com /pad
After the Active Directory preparations have been performed and replicated throughout the forest, the actual setup options can be employed to install Exchange Server 2010, as shown in the following table. D:\SetupFiles>Setup.com /mode:Install
Install Mode
D:\SetupFiles>Setup.com /m:Install
Use this mode when you’re installing a new server role or adding a server role to an existing installation.
This is the default mode for setup.
You can use this mode from both the Exchange Setup Wizard in maintenance mode and with the unattended install. /m could be used in place of /mode, as shown in the second example. NOTE
D:\SetupFiles>Setup.com /mode:Uninstall
Uninstall Mode Use this mode when you’re removing the Exchange installation or removing a single server role from an existing installation. You can use this mode from both the Exchange Setup Wizard in maintenance mode and with unattended install.
D:\SetupFiles>Setup.com /mode:Upgrade
Upgrade Mode Use this mode when you have an existing installation of Exchange and you’re installing the new version; for example, this mode is used for a service pack installation. You can use this mode from both the Exchange Setup Wizard and the unattended install. You cannot use this to upgrade from Exchange 2007 or Exchange 2003!
Setup Options for Exchange Server 2010 RTM
D:\SetupFiles>Setup.com /mode:RecoverServer
77
RecoverServer Mode Use this mode when there has been a complete failure of a server and you need to recover data. You must install a new server or rebuild an existing server using the same fully qualified domain name (FQDN) as the failed server. You run Setup with the /m:RecoverServer switch. No other information is required. The server is built as dictated by the server object in the Active Directory. To run in RecoverServer mode, you cannot have Exchange already installed on the server, but the Exchange server object must still exist in Active Directory from the failed server. You can only use this mode during an unattended installation. (This mode will be discussed more completely in Chapter 6, “Disaster Recovery Deployments.”)
D:\SetupFiles>Setup.com /roles:ClientAccess
Any of these examples install the Client Access role on a server using an unattended installation.
Any of these examples install the Unified Messaging role on a server using an unattended installation.
D:\SetupFiles>Setup.com /roles:U D:\SetupFiles>Setup.com /roles:H, M, C
Any of the preceding roles can be combined in any arrangement, if multiple roles need to be installed on a server as shown in the example. The command in the example would install the Hub, the CAS, and the Mailbox server roles on the same server.
Any of these examples install the Edge Transport role on a server using an unattended installation. The Edge Transport role must be installed as a standalone role. It is not supported or possible to combine the Edge Transport role with any other Exchange Server roles. NOTE
Any of these examples install the Exchange 2010 Management Tools on your 64-bit workstation. There is no longer a 32-bit version of the tools as there was in Exchange Server 2007. NOTE
Upgrading from Exchange Server 2010 RTM to SP1 You can use the Microsoft Exchange Server 2010 Service Pack 1 (SP1) Setup Wizard to perform an upgrade from the RTM version of Exchange 2010 to Exchange 2010 SP1. If you have one or more Exchange Server 2010 roles or the Exchange Management Tools installed, you can upgrade to Exchange Server 2010 SP1, as shown in Figures 5-7 and 5-8. (It is also possible to do a clean install, if desired.)
Upgrading from Exchange Server 2010 RTM to SP1
Figure 5-7
Upgrading to Exchange Server 2010 SP1
Figure 5-8
Introduction to the Exchange Server 2010 SP1 Upgrade Wizard
79
80
Using the Exchange 2010 Deployment Assistant
Figure 5-9 displays the Exchange Management Console highlighting the newly installed Exchange Server 2010 with SP1 installed on it. (Note the SP1 version number [14.1] and the Build Number [218.15]. Exchange Server 2010 RTM is version number 14.0 and Build Number 639.21.)
Figure 5-9
Version number displayed after an upgrade to Exchange Server 2010 SP1
TIP After you upgrade to Exchange 2010 SP1, you can’t uninstall the service pack to revert to Exchange 2010 RTM. If you uninstall Exchange 2010 SP1, you actually remove Exchange from the server.
Using the Exchange 2010 Deployment Assistant Microsoft has created an Exchange Deployment Assistant (also known as ExDeploy). This is a web-based tool that can help you with your Exchange Server 2010 deployment, as shown in the following table.
This web-based tool creates a customized checklist based on answers you provide about your existing messaging environment to assist in a smooth Exchange Server 2010 upgrade or deployment. The URL will take you to the starting page for the Deployment Assistant, as shown in Figure 5-10. If you are planning a deployment of Exchange Server 2010, take a look at this tool, especially if you are migrating from Exchange 2007 or Exchange 2003.
Figure 5-10
Exchange Server 2010 Deployment Assistant
This page intentionally left blank
CHAPTER 6
Disaster Recovery Deployments
This chapter provides information and commands concerning the following topics: ■
Recovering from a single role failure
■
Recovering from a multiple-role failure on the same server
■
Recovering from a Database Availability Group (DAG) member server failure
This chapter focuses on recovering from a role or server failure as well as briefly overviews recovery from the failure of a node in a high-availability environment. Future chapters will investigate backing up and restoring servers and databases, as well as other disaster recovery scenarios. This chapter only focuses on the deployment operation in a disaster recovery situation.
Recovering from a Single Role Failure One of the best ways to protect the organization from a failure of a single role is to have another server hosting that role in the Active Directory site already in place. If you have multiple servers hosting the role, failure of the role will reduce the impact of the failure to your organization. The remaining servers will simply have to take on the load of the failed server until it can be replaced. For a short- or long-term solution, the failed role can be added to any existing or new Exchange server, provided there are no conflicts with the roles currently hosted on it. It is important to know the impact of a failed role, as detailed in the following table. If the Mailbox Server role were to fail in an Active Directory site and it is the only Mailbox Server in that site:
All mailboxes and mailbox databases would be unavailable. (Public folder databases would be unavailable as well.)
If the Mailbox Server role were to fail in an Active Directory site and there are other Mailbox Servers in that site:
Mailboxes, mailbox databases, and public folder databases on the failed server would be unavailable.
Add the Mailbox Server role to a functioning Exchange server that could accept the role and restore or reconnect the databases, build a new server with the Mailbox role on it, or recover the server as described in the section on multiple role failure later in this chapter.
Add the Mailbox Server role to a functioning Exchange server that could accept the role and restore or reconnect the databases, build a new server with the mailbox role on it, or recover the server as described in the section on multiple role failure later in this chapter.
84
Recovering from a Single Role Failure
If the Client Access Server role were to fail in an Active Directory site and it is the only Client Access Server in that site:
No access to Exchange by any client of Exchange Server 2010 is possible. There would be a loss of Autodiscover service as well as Availability service. There would also be a loss of the default Offline Address Book (OAB) distribution point and other ancillary services. Add the CAS role to a functioning Exchange server that could accept the role, build a new server with the CAS role on it, or recover the server as described in the section on multiple role failure later in this chapter. Clients would need to be redirected to the replacement CAS role. This could mean changing host (A) records in DNS, as well as altering some of your firewall settings to direct appropriate traffic to the new Client Access Server. NOTE
If the Client Access Server role were to fail in an Active Directory site and there are other Client Access Servers in that site:
No loss of services. Other Client Access Servers would be required to handle more of the load.
If the Hub Transport server role were to fail in an Active Directory site and it is the only Hub Transport server in that site:
No mailflow within the site would occur. No mailflow to or from any other site to the site that the failed server is in would occur.
If the Hub Transport server role were to fail in an Active Directory site and there are other Hub Transport servers in that site:
No loss of services. Other Hub Transport servers would be required to handle more of the load.
If the Unified Messaging Server role were to fail in an Active Directory site and it is the only Unified Messaging Server in that site:
Loss of voice messaging, fax messaging, and integration of Exchange with telephony networks would occur.
Add the CAS role to a functioning Exchange server that could accept the role, build a new server with the CAS role on it, recover the server as described in the section on multiple role failure later in this chapter, or accept the loss, making sure you remove the failed server objects from the Active Directory.
Add the Hub Transport role to a functioning Exchange server that could accept the role, build a new server with the HT role on it, or recover the server as described in the section on multiple role failure later in this chapter.
Add the Hub Transport role to a functioning Exchange server that could accept the role, build a new server with the HT role on it, recover the server as described in the section on multiple role failure later in this chapter, or accept the loss, making sure you remove the failed server objects from the Active Directory.
Add the Unified Messaging role to a functioning Exchange server that could accept the role, build a new server with the UM role on it, or recover the server as described in the section on multiple role failure later in this chapter.
Recovering from a Multiple-Role Failure on the Same Server
85
If the Unified Messaging Server role were to fail in an Active Directory site and there are other Unified Messaging Servers in that site:
No loss of services. Other Unified Messaging Servers would be required to handle more of the load.
If the Edge Transport Server role were to fail that was affiliated with an Active Directory site and it is the only Edge Transport Server affiliated with that site:
No mailflow to and from the Internet. Internal mailflow would be unaffected.
If the Edge Transport Server role were to fail that was affiliated with an Active Directory site and there are other Edge Transport Servers affiliated with that site:
No loss of services. Other Edge Transport Servers would be required to handle more of the load.
Add the Unified Messaging role to a functioning Exchange server that could accept the role, build a new server with the UM role on it, recover the server as described in the section on multiple role failure later in this chapter, or accept the loss, making sure you remove the failed server objects from the Active Directory.
Deploy a new Edge Transport server and use the cloned configuration file to recover the failed role. (This topic is discussed more fully in Chapter 10, “The Edge Transport Role,” which deals with the Edge Transport Server role.)
Recovering from a Multiple-Role Failure on the Same Server Because nearly all of the configuration information and settings for Mailbox, Client Access, Hub Transport, and Unified Messaging server roles are stored in Active Directory, you can leverage that information to rebuild a failed server. The Setup parameter used is the /m:RecoverServer option. The information stored in the Active Directory about the failed server is used to re-create a new server (on either the same or alternate hardware as the failed server). The replacement server, although given a new security identifier (SID), is recognized by both the Exchange organization and the Active Directory as the old server, as if it never failed. In addition, this could be used in a planned scenario to replace an older server. The following table details the requirements and procedures to recover from a server failure.
86
Recovering from a Multiple-Role Failure on the Same Server
The Windows Server operating systems must be the same.
The server on which recovery is being performed must be running the same operating system as the server that is being replaced. For example, you cannot recover a server that was running Exchange 2010 and Windows Server 2008 on a server running Windows Server 2008 R2, or vice versa.
All drive letters must be available.
The same disk-drive letters for mounted databases on the server that is being replaced must exist or be created on the server on which you are running the recovery operation.
Performance of the replacement server should be similar.
The server on which recovery is being performed should have the same performance characteristics and hardware configuration as the server it is replacing.
This is for Mailbox, CAS, Hub Transport, and Unified Messaging roles only.
The Setup /m:RecoverServer procedure can be run on an Exchange 2010 server that has the Client Access, Hub Transport, Mailbox, Unified Messaging, or any combination of those server roles installed. You cannot use Setup /m:RecoverServer to recover an Edge Transport server. For Edge Transport server recoveries, use Edge Cloning, described in Chapter 10, “The Edge Transport Role.” The Setup /m:RecoverServer procedure cannot recover an Edge Transport Server role because the procedure leverages information about the failed server that remains in the Active Directory after the role failure. Because the Edge Transport Server has never been an AD member, there is no information in the AD to use for recovery purposes.
NOTE
Recovering from a Multiple-Role Failure on the Same Server
In Active Directory Users and Computers:
Reset the server’s computer account in Active Directory.
1 Find the computer object for the
This can be done either from Active Directory Users and Computers, as shown in Figure 6-1, or from a command prompt using the dsmod command, as shown in Figure 6-2.
failed Exchange Server. 2 Right-click the computer object that
you want to reset. 3 Click Reset Account.
Alternatively, type the following from the command prompt: dsmod computer ComputerDN -Reset
TIP Do not DELETE the account. Instead, use the RESET ACCOUNT option. If you delete the computer account, this recovery method cannot be used.
Figure 6-1 Resetting the computer account in Active Directory Users and Computers for Romac-EX3HC
87
88
Recovering from a Multiple-Role Failure on the Same Server
Figure 6-2 Resetting the computer account using dsmod from a command prompt for Romac-EX3HC
Ensure that the computer name is the same and then join the same domain.
Install the proper operating system and name the new server with the same name as the server it will be replacing. (The IP address is optional.) Join the server to the same domain as the failed server. All necessary prerequisites and operating system components, including the necessary service packs, hotfixes, and updates, should be installed. These should be documented well before the disaster occurs. NOTE
TIP You could use a generic image of a server, because when you join the server to the domain, a new SID will be generated. Ensure that you put the Exchange prerequisites on the image to speed up the recovery process.
D:\SetupFiles>Setup /m:RecoverServer
Open a command prompt window. Using the original Setup media or a network location, run the command shown on the left. D:\SetupFiles could represent any location where the Setup files would be found. NOTE
The result of running Setup /m:RecoverServer is shown in Figure 6-3. (The location of the Setup files in Figure 6-3 is at the root of the D:\ drive.)
After Setup has completed, but before the recovered server is put into production, it is a good idea to reconfigure any custom settings that were present on the original server, such as nonstandard permissions on virtual directories or nonstandard websites on a CAS, unique transport dumpster settings on a Hub Transport, or voice prompts unique to a location on a Unified Messaging role. You must perform this disaster recovery technique using the same version of Exchange as was on the server being replaced. The Active Directory objects are version specific. NOTE
Recovering from a Database Availability Group (DAG) Member Server Failure
89
Figure 6-3 Running Setup /m:RecoverServer on the replacement server for Romac-EX3HC
Recovering from a Database Availability Group (DAG) Member Server Failure If a Mailbox server that’s a member of a Database Availability Group (DAG) is lost or otherwise fails and is unrecoverable and needs replacement, you can perform a server recovery operation. For DAG member server recovery, Microsoft Exchange Server 2010 Setup also allows the use of switch /m:RecoverServer to perform the server recovery operation. Just as with a single server failure, running Setup with the /m:RecoverServer switch causes Setup to read the server’s configuration information from Active Directory for a server with the same name as the server from which you’re running Setup. After the server’s configuration information is gathered from Active Directory, the original Exchange files and services are then installed on the server, and the roles and settings that were stored in Active Directory are then applied to the server. This is different from Cluster Continuous Replication (CCR) in Exchange Server 2007, where you used Setup /RecoverCMS. You need to be assigned permissions before you can perform the steps in this procedure. The required permissions for each step are listed in the following table.
90
Recovering from a Database Availability Group (DAG) Member Server Failure
To Perform These Tasks...
...You Need to Be In:
Database availability group membership
Organization Management
Database availability group properties
Database Availability Groups Role
Database availability groups Database availability networks To Perform These Tasks...
...You Need to Be In:
Database switchover
Organization Management
Mailbox database copies
Database Copies Role
Server switchover Update a mailbox database copy
The following table details the requirements and procedures to recover from a DAG member server failure. Get-MailboxDatabase DatabaseName | Format-List *lag* PS C:\Users\Administrator> Get-MailboxDatabase AssemblyDB | Format-List *lag*
First, retrieve any replay lag or truncation lag settings for any mailbox database copies that exist on the server being recovered. You can achieve this by using the Get-MailboxDatabase cmdlet and pipelining it to the Format-List output. To recover the failed server, you must remove any mailbox database copies that exist on the server being recovered by using the Remove-MailboxDatabaseCopy cmdlet. TIP You would need to do this for each database copy on the failed server.
Remove-DatabaseAvailabilityGroupServer After the database copies have been removed, you need to remove the -Identity DAGName failed server’s configuration from -MailboxServer DAGMemberName
the DAG by using the RemovePS C:\Users\Administrator> DatabaseAvailabilityGroupServer Remove-DatabaseAvailabilityGroupServer cmdlet. -Identity DAG1 -MailboxServer Romac-EX1
Recovering from a Database Availability Group (DAG) Member Server Failure
In Active Directory Users and Computers: 1 Find the computer object for the failed
Exchange Server. 2 Right-click the computer object you want to
reset. 3 Click Reset Account.
Alternatively, type the following from the command prompt: dsmod computer ComputerDN -Reset C:\Users\Administrator> dsmod computer "CN=Romac-EX1, OU=Exchange Servers, DC=RomacSign, DC=com" -Reset D:\SetupFiles>Setup /m:RecoverServer
91
Reset the server’s computer account in Active Directory. This is the same procedure that you performed on the non-DAG member computer account (refer to Figure 6-1) in Active Directory Users and Computers. NOTE
It can also be done from a command prompt using the dsmod command (refer to Figure 6-2). TIP Do not DELETE the account. If you delete the computer account, this recovery method cannot be used.
Open a command prompt window. Using the original Setup media, run the command shown on the left. D:\SetupFiles could represent any location where the Setup files would be found. NOTE
If any lag time is desired, it could be added using the same cmdlet with the parameter -ReplayLagTime, as shown in the second pair of examples, or the parameter -TruncationLagTime (not shown).
This page intentionally left blank
CHAPTER 7
Working with Recipient Objects
This chapter provides information and commands concerning the following topics: ■
Identifying the Exchange 2010 recipient types
■
Creating and managing a user mailbox
■
Creating and managing a mail-enabled user
■
Creating and managing a mail-enabled contact
■
Creating and managing resource mailboxes
■
Working with distribution groups
■
Converting recipient types
■
Creating and managing email address policies
■
Creating and managing address lists
This chapter focuses on the creation and management of recipient objects in Exchange 2010. You investigate the recipient types and create them using Exchange Management Shell. In Chapter 8, “Bulk Management of Recipients,” you will investigate ways to create the recipient objects in bulk. You will discover that in Exchange 2010 there are common recipient types you will create and manage regularly and other recipient types you may rarely configure or manipulate. The chapter concludes with a look at email address policies and address lists.
Identifying the Exchange 2010 Recipient Types It is important to understand the recipient types available in Exchange 2010 and how to manage them using Exchange Management Shell (EMS). The following table details the cmdlets that allow you to identify the specific recipients by type. Get-Recipient
Retrieves a list of all recipients, regardless of type
Get-Mailbox
Retrieves a list of only the User Mailbox recipients
Get-MailUser
Retrieves a list of only the Mail User recipients
Get-MailContact
Retrieves a list of only the Mail Contact recipients
Get-DistributionGroup
Retrieves a list of all distribution groups
Get-DynamicDistributionGroup Retrieves a list of all dynamic distribution groups The two distinguishing features for a recipient type are as follows: ■
Which type of Active Directory object is created when the recipient is created
■
Whether an Exchange mailbox is created when the recipient is created
94
Identifying the Exchange 2010 Recipient Types
Some of the more common recipient types are detailed in the following table. Recipient Type
What Type of Active Directory Object Is Created?
Is an Exchange Description Mailbox Created for This Object?
User mailbox
AD User account
Yes.
A User mailbox is an Active Directory user account that has an Exchange mailbox enabled for it. In many organizations, this is the most common type of Exchange recipient object. The user logs on to Windows and accesses a mailbox in Exchange. NOTE The mailbox may be accessed using a variety of clients, such as Microsoft Office Outlook, Outlook Anywhere, OWA, or ActiveSync. The point is that the mailbox exists in the Exchange organization and is not an external email address.
Mail user
AD User account
No, but the user’s external email address appears in the Global Address List (GAL).
A mail-enabled user is a recipient object that represents an Active Directory user who has an external email address rather than an Exchange mailbox. All messages sent to the mail user are routed to this external email address. A mail user is similar to a mail contact, except that a mail user has Active Directory logon credentials and can access resources and the contact cannot. However, even without an Exchange Mailbox, this object appears in the Global Address List (GAL).
Identifying the Exchange 2010 Recipient Types
Recipient Type
What Type of Active Directory Object Is Created?
Is an Exchange Description Mailbox Created for This Object?
Mail contact
AD Contact object; no user account is created
No, but the contact’s external email address appears in the Global Address List (GAL).
95
A mail-enabled contact is a recipient object that contains information about people or organizations that exist outside the Exchange organization. The mail contact has an external email address. All messages sent to the mail contact are routed to this external email address. Even without an Exchange Mailbox or AD user account, this object appears in the Global Address List (GAL).
Room mailbox
AD User Account (Disabled)
Yes. It is labeled as a room.
A room mailbox is a resource mailbox that is associated with a meeting location, such as a conference room. Room mailboxes can be included as resources in meeting requests, providing a simplified way of creating and managing meetings for your users that includes the automation of the invitation and the resource’s acceptance of your users’ requests.
96
Identifying the Exchange 2010 Recipient Types
Recipient Type
What Type of Active Directory Object Is Created?
Equipment AD User Account mailbox (Disabled)
Is an Exchange Description Mailbox Created for This Object?
Yes. It is labeled as equipment.
An equipment mailbox is a resource mailbox that is associated with a nonlocation-specific resource. Often projectors, vehicles, and even items such as wireless aircards can be represented by this recipient type. Equipment mailboxes can be included as resources in meeting requests or can simply be a method of reserving a piece of equipment in your organization through Exchange. This can provide a simplified way of creating and managing meetings for your users that includes the automation of the invitation and the resource’s acceptance of your users’ requests.
Mailenabled universal distribution group
AD Group object Type=Distribution Scope=Universal
No, but an email alias is created.
A mail-enabled Active Directory distribution group object is a recipient object that can be used only to distribute messages to a group of recipients. Because it is only a distribution group, this recipient type cannot be used by Windows to assign permissions to a resource.
Identifying the Exchange 2010 Recipient Types
Recipient Type
What Type of Active Directory Object Is Created?
Is an Exchange Description Mailbox Created for This Object?
Mailenabled universal security group
AD Group object
No, but an email alias is created.
Type=Security Scope=Universal
97
A mail-enabled Active Directory security group object is a recipient object that can be used to grant access permissions to resources in Active Directory and can also be used to distribute messages. Because it is a security group, this recipient type can be used for both purposes.
Dynamic distribution group
AD msExch
Legacy mailbox
AD User account
DynamicDistributionList object
No, but an email alias is created.
A Dynamic distribution group is a special AD object that uses recipient filters and conditions to derive its membership at the time messages are sent.
Yes, but it was created in Exchange 2003.
A Legacy mailbox is a recipient object that represents an Active Directory user account that has an Exchange mailbox enabled for it on a server running Exchange Server 2003. NOTE In general, a mailbox on Exchange Server 2007 is not considered a Legacy mailbox. However, there could be reasons that Legacy mailboxes might exist on a 2007 server. You would observe this by looking at the Recipient Type Status column in the Exchange Management Console (EMC) for the 2007 mailbox server. If the description in the column displays LegacyMailbox instead of UserMailbox, you must convert it to a UserMailbox. (This may have occurred when you moved the mailbox to 2007 from 2003.)
98
Identifying the Exchange 2010 Recipient Types
Recipient Type
What Type of Active Directory Object Is Created?
Is an Exchange Description Mailbox Created for This Object?
Linked mailbox
Two AD User accounts:
Yes.
Primary forest— account is enabled.
(The mailbox is created in the resource forest.)
Resource forest— account is disabled.
A Linked mailbox is a recipient object that represents an Active Directory user account in one AD forest (primary forest) that is assigned or linked to an Exchange mailbox in a second forest (resource forest). The resource forest must have a trust relationship with the primary forest.
Other recipient types are detailed in the following table. Microsoft Exchange recipient
A Microsoft Exchange recipient is a special recipient object that replaces the System Administrator sender used for system-generated messages in earlier versions of Exchange. This recipient type allows Exchange to differentiate system-generated messages from other messages. It cannot be managed by using the EMC. You must use the Set-OrganizationConfig cmdlet in EMS to configure the Microsoft Exchange recipient object. The types of messages sent by the Microsoft Exchange recipient include any messages from agents (transport or journal), any Delivery Status Notification (DSN) messages, reports as a result of the journaling process, and any messages regarding quotas.
Shared mailbox
A Shared mailbox is a recipient object that is not associated with a single user account. It is configured to allow logon access for several users. In Exchange 2003, resources were often created as Shared mailboxes and had to be managed by a delegate. It is recommended that you convert your Exchange 2003 Shared mailboxes that generally represent resources to either room mailboxes or equipment mailboxes.
It is possible to convert the following: ■
A user mailbox to a shared mailbox
■
A user mailbox to a resource mailbox
■
A shared mailbox to a user mailbox
Identifying the Exchange 2010 Recipient Types
■
A shared mailbox to a resource mailbox
■
A resource mailbox to a user mailbox
■
A resource mailbox to a shared mailbox
99
These conversions must be performed using Exchange Management Shell. One of the most common conversions needed is when you move a shared resource mailbox from Exchange Server 2003 to Exchange Server 2010. In Exchange 2003, you used shared mailboxes to represent resources. If you were to simply move this mailbox to Exchange 2010, it would become an Exchange 2010 shared mailbox and no automation of its calendar would be possible. You must convert it from an Exchange 2010 shared mailbox to an Exchange 2010 resource mailbox (room or equipment) so that it can automatically book itself using the Resource Booking Attendant feature in Exchange 2010. You cannot use the EMC to convert a mailbox. Later in this chapter, you will view a shared-mailbox-to-resource-mailbox conversion. Some other recipient types are detailed in the following table. Mail forest contact
A Mail forest contact is a recipient object that represents a recipient object from another AD forest. Mail forest contacts are usually created by Microsoft Identity Integration Server (MIIS) synchronization and are used as part of GAL synchronization. Mail forest contacts are read-only recipient objects that are updated only through MIIS or a similar synchronization utility. You cannot use the Exchange Management tools to configure these recipients.
Mail-enabled non-universal group
A mail-enabled Active Directory non-universal group (global or local group) was a recipient type in Exchange 2007 and earlier. These recipient objects were deprecated in Exchange 2010. They can exist only if they were migrated from Exchange 2003 or earlier versions of Exchange. You cannot use Exchange 2010 to create non-universal distribution groups.
Mail-enabled public folder
A Mail-enabled public folder is a recipient type that represents an Exchange public folder that has been configured to receive messages.
100
Identifying the Exchange 2010 Recipient Types
System Mailboxes
System mailboxes are created by Exchange in the root domain of the Active Directory forest during installation. Users or administrators can’t log on to these mailboxes. System mailboxes are created for Exchange 2010 features such as message approval and Multi-Mailbox Search. System mailboxes may also be termed arbitration mailboxes. An arbitration mailbox is used for managing approval workflow with a moderated recipient.
TIP If you want to decommission the last Exchange 2010 Mailbox server in your organization, you must first disable these system mailboxes by using the Disable-Mailbox cmdlet. Before you decommission a Mailbox server that contains these system mailboxes, you should move them to another Mailbox server to make sure you don’t lose functionality.
The following table displays the cmdlets used to view the system mailboxes. PS C:\Users\ Administrator>Get-Mailbox -Arbitration | fl Name, DisplayName, RecipientType, RecipientTypeDetails
This Get-Mailbox command with the -Arbitration parameter allows you to view the system or arbitration mailboxes.
The default system mailboxes are displayed in Figure 7-1 and include those detailed in the following table. Mailbox
Purpose
Common Name (CN)
Discovery
This mailbox is used as the default target mailbox for cross-mailbox searches. An auditor might use discovery search when he or she wants to search for confidential emails across all the mailboxes in your organization.
You can create additional discovery mailboxes if required. Message Approval
This mailbox is used as part of the message moderation process for moderated groups.
SystemMailbox {1f05a927xxxx-xxxx- xxxxxxxxxxxxxxxx} where the x’s are randomly assigned numbers
Federated Email
This mailbox is used as part of the federated delegation setup for ADFS when two organizations are federated.
FederatedEmail 4c1f4d8b8179-4148-93bf00a95fa1e042
Creating and Managing a User Mailbox
Figure 7-1
101
The default system mailboxes
Creating and Managing a User Mailbox Although you would not usually create a cmdlet to create a single User mailbox, it is certainly possible to do so. Most people would use Exchange Management Console to create a single User mailbox. As you will see in Chapter 8, you can use several of the techniques shown in the following table to create recipient objects in bulk. Bulk management of recipient objects is one area where PowerShell and Exchange Management Shell can far exceed the capabilities of Exchange Management Console. PS C:\Users\Administrator> $Pass=ConvertTo-SecureString "Pa$$w0rd" -asPlainText -Force
This example defines a secure string password so that you don’t have to type a password for each user that follows. This password will only be valid from within this session, unless you incorporate it into your PowerShell profile. NOTE
102
Creating and Managing a User Mailbox
New-Mailbox -Name Name -Alias Name -UserPrincipalName [email protected] -SamAccountName Username -FirstName FirstName -LastName LastName -OrganizationalUnit OUName -Password password -ResetPasswordOnNextLogon $boolean value -Database DatabaseName
This New-Mailbox cmdlet creates a single User mailbox using EMS.
This dsadd command creates a user to test with the Enable-Mailbox cmdlet. This EnableMailbox cmdlet enables a single user’s mailbox for an existing AD User account.
As shown in the following table, there is a difference between the New-Mailbox cmdlet, which creates both the AD User and enables the Exchange mailbox, and the EnableMailbox cmdlet, which takes an existing AD User and enables the Exchange mailbox for the account. Remove-Mailbox Name PS C:\Users\ Administrator> Remove-Mailbox "Vinnie Vignola"
Sometimes it is necessary to remove the user from the Active Directory, as might be the case if the user leaves the company. This can be done with the Remove-Mailbox cmdlet. The user is removed, but the mailbox remains for the duration of the mailbox retention period, which is 30 days by default. Then, the mailbox is removed.
Creating and Managing a User Mailbox
Disable-Mailbox Name PS C:\Users\ Administrator> Disable-Mailbox "Vinnie Vignola"
103
Sometimes it is necessary to simply disassociate the user from the mailbox when he or she no longer needs an Exchange mailbox. This can be done with the Disable Mailbox cmdlet. The user is preserved, but is no longer associated with the mailbox. The mailbox remains for the duration of the mailbox retention period, which is 30 days by default. Then, the mailbox is removed.
Figures 7-2 through 7-6 show the differences between removing a user mailbox and disabling one.
Figure 7-2
Right-click menu displaying the Remove and Disable options in EMC
Figure 7-3
Removing a user mailbox from EMC
104
Creating and Managing a Mail-Enabled User
Figure 7-4
Removing a user mailbox from EMS
Figure 7-5
Disabling a user mailbox from EMC
Figure 7-6
Disabling a user mailbox from EMS
Creating and Managing a Mail-Enabled User As shown in the following table, it is also possible to create a single Mail-enabled user or Mail User with a similar cmdlet.
Once again, this step defines a secure string password so that you don’t have to type a password for each mail-enabled user that will be created if you are creating more than one. This password will only be valid from within this session, unless you incorporate it into your PowerShell profile. NOTE
New-MailUser -Name Name -Alias Name -OrganizationalUnit OUName -UserPrincipalName [email protected] -SamAccountName UserName -FirstName FirstName -LastName LastName -Password password -ResetPasswordOnNextLogon $boolean value -ExternalEmailAddress SMTP:[email protected]
This New-MailUser cmdlet creates a single Mail User using EMS.
This Enable-MailUser cmdlet enables an external email address for an existing AD User account.
As shown in the following table, there is also a difference between the New-MailUser cmdlet, which creates both the AD User and associates it with an external email address, and the Enable-MailUser cmdlet, which takes an existing AD User and associates it with an external email address. PS C:\Users\ Administrator> Remove-MailUser "Bob Fuoco"
Sometimes it is necessary to remove the user from the Active Directory, as might be the case if the user leaves the company. This can be done with the Remove-MailUser cmdlet. The user is removed and there is no longer any association with that external email address in the Exchange organization.
PS C:\Users\ Sometimes it is necessary to simply disassociate the user from the external email address. Administrator> Disable-MailUser This can be done with the Disable-MailUser cmdlet. "Bob Fuoco"
The user is preserved, but is no longer associated with the external email address.
Creating and Managing a Mail-Enabled Contact It is also possible to create a single Mail-enabled contact or Mail Contact with a similar cmdlet, as shown in the following table. It is not necessary to create a password for a Mail Contact because this object does not have an associated AD User account.
Creating and Managing a Mail-Enabled Contact
New-MailContact -ExternalEmailAddress "SMTP:[email protected]" -Name Name -Alias Name -FirstName FirstName -LastName LastName -OrganizationalUnit OUName
107
This New-MailContact cmdlet creates a single Mail Contact using EMS.
Sometimes it is necessary to remove the contact from the Active Directory, as might be the case if a consultant no longer works with the company. This can be done with the RemoveMailContact cmdlet. The contact is removed and there is no longer any association with that external email address in the Exchange organization.
Sometimes it is necessary to simply disassociate the contact from the external email address. This can be done with the DisableMailContact cmdlet. The contact is preserved, but is no longer associated with the external email address.
Creating and Managing Resource Mailboxes Creating a Resource mailbox is very much like creating a User mailbox. Only one parameter makes a Resource mailbox unique, and it depends on the type of resource. If you are creating an Equipment mailbox, you will use the parameter -Equipment, and if you are creating a Room mailbox, you will use the parameter -Room, as shown in the following table. New-Mailbox -Name Name -Alias Name -UserPrincipalName [email protected] -SamAccountName UserName -FirstName FirstName -LastName LastName -OrganizationalUnit OUName -Password password -ResetPasswordOnNextLogon $boolean value -Database DatabaseName -Equipment PS C:\Users\Administrator>New-Mailbox -Name "Projector 1234" -Alias "Projector1234" -UserPrincipalName "[email protected]" -SamAccountName "Projector1234" -FirstName "Projector" -LastName "1234" -OrganizationalUnit Assembly -Password $Pass -ResetPasswordOnNextLogon $false -Database "AssemblyDB" -Equipment
This New-Mailbox cmdlet creates a Resource mailbox (Equipment type) using EMS.
Working with Distribution Groups
New-Mailbox -Name Name -Alias Name -UserPrincipalName [email protected] -SamAccountName UserName -FirstName FirstName -LastName LastName -OrganizationalUnit OUName -Password password -ResetPasswordOnNextLogon $boolean value -Database DatabaseName -Room
109
This New-Mailbox cmdlet creates a Resource mailbox (Room type) using EMS.
Working with Distribution Groups Understanding how distribution groups work in Exchange 2010 can be a little tricky. A distribution group can be created in the Active Directory, but Exchange will not recognize it until it has been mail-enabled. This may seem strange. After all, it seems as if simply creating the group as a distribution group in the Active Directory should be sufficient. However, if you analyze the enabling process, it may make more sense. Just as you could create a user in Active Directory and later mail-enable the object, the same is true with groups. You can either create the group and mail-enable it in one operation, or you can create the group first and then mail-enable it later. You may have expected that this would be true with security groups, but it is also true with distribution groups. In Exchange, groups can be one of three types: ■
Mail-enabled distribution groups—Can only be used to distribute messages to a group of recipients
■
Mail-enabled security groups—Can be used for both distributing messages and configuring security on objects such as files, folders, and printers
■
Dynamic distribution groups—Can use recipient filters and conditions to derive membership at the time the message is sent
110
Working with Distribution Groups
The following table shows how to use Exchange Management Shell (EMS) to create a mail-enabled distribution group as well as a mail-enabled security group. New-DistributionGroup -Name Name -Type "Distribution" -SamAccountName Name -Alias Name
This New-DistributionGroup cmdlet creates a distribution group (Distribution type; Universal scope) using EMS.
PS C:\Users\Administrator> New-DistributionGroup -Name "Assemblers" -Type "Distribution" -SamAccountName "Assemblers" -Alias "Assemblers" New-DistributionGroup -Name Name -Type "Security" -SamAccountName Name -Alias Name
This New-DistributionGroup cmdlet creates a distribution group (Security type; Universal scope) using EMS.
Enabling a distribution group allows Exchange to route messages to the alias that represents the Active Directory group object. In EMS, this can be done with the Enable-DistributionGroup cmdlet. These Enable-DistributionGroup cmdlets enable first a distribution group and then a security group. Notice that when you mail-enable a distribution group that already exists, you do not specify the group type. The object has already been created in the Active Directory and there is already a group type associated with the object. Assembly Team 1 is a mail-enabled distribution group and Assembly Team 2 is a mail-enabled security group (as shown in Figure 7-7). Both are mail-enabled with the same cmdlet. Only the name need be different.
Working with Distribution Groups
Figure 7-7
111
Disabling a User mailbox from EMS
The following table shows how to use EMS to create a dynamic distribution group. New-DynamicDistributionGroup -Name GroupName -OrganizationalUnit OUName -RecipientFilter { ((RecipientType -eq RecipientType) -and (ServerName -eq ServerName) -and (Name -notlike "SystemMailbox")) } PS C:\Users\Administrator> New-DynamicDistributionGroup -Name "Mailbox Users in Assembly OU on Romac-EX1" -OrganizationalUnit romacsign.com/ Assembly -RecipientFilter { ((RecipientType -eq "UserMailbox") -and (ServerName -eq "Romac-EX1") -and(Name -notlike "SystemMailbox")) }
This NewDynamicDistributionGroup cmdlet creates a dynamic distribution group using a Recipient Filter in EMS that will include users in the Assembly OU with Exchange mailboxes on Romac-EX1, but will exclude the System mailboxes.
This is just one example of how you might use a dynamic distribution group. The benefit of using this type of group is that the membership does not need to be managed. If the recipient is included in the filter, it will receive the message; if the recipient is not included in the filter, it will not receive the message. A slight performance cost is involved with using dynamic distribution groups because the membership must be calculated at the time the message is sent.
112
Converting Recipient Types
By default, new dynamic distribution groups in Exchange Server 2010 require that all senders be authenticated. This prevents external senders from sending messages to dynamic distribution groups. Also, by default, a maximum of 1,000 recipients is displayed to keep performance at an optimum level. If you increase this value, the time it takes to display the results will be prolonged. There also may be a negative impact on the domain controller to which you are connected if you use many large dynamic distribution groups due to an excessive number of LDAP queries. NOTE
Converting Recipient Types In many organizations, the most common type of conversion is when you need to convert a 2003 Shared mailbox to a 2010 Resource mailbox. As previously detailed in this chapter, that is not the only conversion that can be performed on a recipient. When you move a Resource mailbox to Exchange 2010, it is migrated as a Shared mailbox. If you would like to take advantage of the automated booking features of Exchange 2010, you must manually convert it to a Room mailbox (or Equipment mailbox) because Exchange has no way of determining if that is your intention. Fortunately, it is a very simple process, as shown in the following table. New-Mailbox -Name RoomName -Alias RoomAlias -UserPrincipalName UPN -SamAccountName UserName -FirstName FirstName -LastName LastName -Password password -ResetPasswordOnNextLogon $boolean value -Database DatabaseName -Shared PS C:\Users\Administrator>New-Mailbox -Name "Conference Room 112" -Alias "Conf112" -UserPrincipalName "[email protected]" -SamAccountName "Conf112" -FirstName "Conference Room" -LastName "112" -Password $Pass -ResetPasswordOnNextLogon $false -Database "AssemblyDB" -Shared Set-Mailbox RoomName -Type Room PS C:\Users\Administrator>Set-Mailbox Conf112 -Type Room
This New-Mailbox cmdlet creates a Shared mailbox to test with the Set-Mailbox cmdlet as part of a conversion to a Room mailbox. Figure 7-8 shows the mailbox before running the cmdlet, and Figure 7-9 shows the result after running the cmdlet. NOTE
This Set-Mailbox cmdlet migrates a Shared mailbox to a 2010 Resource mailbox.
Creating and Managing Email Address Policies
Figure 7-8
Shared mailbox before conversion, as seen in EMC
Figure 7-9
Resource mailbox after conversion, as seen in EMC
113
Creating and Managing Email Address Policies If a recipient is to send or receive email, it is essential that the recipient have an email address. When you create an email address policy, an email address can automatically be configured for each of your recipients, rather than you having to assign them manually. The policy can generate both primary and secondary email addresses for your recipients so they can receive and send email. There is a default email address policy in Exchange 2010. The default policy specifies the recipient’s alias combined with the default accepted domain. For example, if a user’s alias is Rodney, his email address would be [email protected] in the test lab environment used in this book. You can change this, however. Many companies use the same user logon name as the Exchange alias and might not want to compromise security by exposing the logon names. Instead of using an alias, you could change how your recipients’ email
114
Creating and Managing Email Address Policies
addresses will be displayed by specifying that your recipients’ email will appear as [email protected], such as [email protected]. As shown in the following table, default variables are in place for generating email addresses. %m
Exchange alias.
%g
Given name. (If a number appears before the “g,” that number of characters from the recipient’s given name will be used in the email address.)
%i
Middle initial.
%s
Surname or last name. (If a number appears before the “s,” that number of characters from the recipient’s last name will be used in the email address.)
%d
Display name.
The following table shows how to use EMS to create, apply, and edit email address policies. New-EmailAddressPolicy -Name RegionName -IncludedRecipients RecipientTypes -ConditionalStateorProvince States -EnabledEmailAddressTemplates "SMTP:%s.%[email protected]" PS C:\Users\Administrator> New-EmailAddressPolicy -Name "Northeast Region" -IncludedRecipients MailboxUsers -ConditionalStateorProvince "Connecticut","Massachusetts", "New York","New Jersey", "Pennsylvania","Rhode Island","Maine" -EnabledEmailAddressTemplates "SMTP:%s.%[email protected]" Update-EmailAddressPolicy -Identity EmailAddressPolicyName PS C:\Users\Administrator> Update-EmailAddressPolicy -Identity "Northeast Region"
This New-EmailAddressPolicy creates an email address policy. The use of the ConditionalStateorProvince parameter allows a filter to specify a state or province for an email address policy, address list, or other Exchange-related LDAP query. All recipients with a ConditionalStateOrProvince attribute that match the value you specify will be included in the email address policy or address list. NOTE
This UpdateEmailAddressPolicy applies (or updates) an existing email address policy.
Creating and Managing Email Address Policies
115
This Set-Email Address Policy edits an existing email address policy.
Even though the e-mail address policy is already applied to recipients in Connecticut, Massachusetts, New York, New Jersey, Pennsylvania, Rhode Island, and Maine, you must include them again in the Set-EmailAddressPolicy cmdlet because the cmdlet overwrites the previous values. NOTE
TIP You might have to wait several hours for the new or updated email address policy to fully take effect.
The following table shows how to use EMS to remove an existing email address policy. Remove-EmailAddressPolicy -Identity EmailAddressPolicyName -Confirm: $boolean value PS C:\Users\Administrator> Remove-EmailAddressPolicy -Identity "Northeast Region" -Confirm:$False
This Remove-EmailAddressPolicy cmdlet removes an existing email address policy. Use the -Confirm:$False option to avoid being prompted about the deletion.
TIP
The following table shows how to use EMS to retrieve information about email address policies. PS C:\Users\Administrator> Get-EmailAddressPolicy
This Get-EmailAddressPolicy retrieves a list of all existing email address policies.
Creating and Managing Address Lists The following table shows how to use EMS to create an address list. New-AddressList -Name AddressListName -RecipientContainer OUName -IncludedRecipients RecipientType -ConditionalStateOrProvince State PS C:\Users\Administrator>New-AddressList -Name "Pennsylvania Assemblers Address List" -RecipientContainer RomacSign.com/Assembly -IncludedRecipients MailboxUsers -ConditionalStateOrProvince "Pennsylvania"
Figure 7-10
Created address list, as seen in EMC
This New-AddressList cmdlet creates an address list for all users with Exchange mailboxes located in Pennsylvania that have accounts in the Assembly OU. The result of the cmdlet is shown in EMC in Figures 7-10 through 7-12. NOTE
Creating and Managing Address Lists
Figure 7-11
Recipient container where filter is applied, as seen in EMC
Figure 7-12
Conditions and address list preview, as seen in EMC
117
118
Creating and Managing Address Lists
The following table shows how to use EMS to update and edit an address list. This Update-AddressList cmdlet updates the Update-AddressList -Identity AddressListName recipients included in the specified address list. PS C:\Users\ Administrator> Update-AddressList -Identity "Pennsylvania Assemblers Address List" Set-AddressList -Identity AddressListName -DisplayName NewDisplayName -ForceUpgrade:$true PS C:\Users\ Administrator> Set-AddressList -Identity "Pennsylvania Assemblers Address List" -DisplayName "PA Assemblers" -ForceUpgrade:$true
Figure 7-13
This Set-AddressList cmdlet modifies an existing address list. In this example, the Display Name needs to be changed to PA Assemblers, as shown in Figure 7-13. The -ForceUpgrade parameter causes a dialog box to be ignored that states the following: “To save changes on object, the object must be upgraded to the current Exchange version. After upgrade, this object can’t be managed by a previous version of Exchange System Manager. Do you want to continue to upgrade and save the object?”
TIP
This may occur when you upgrade an address list from Exchange Server 2003 to Exchange 2010.
Changing the display name of an address list
The following table shows how to use EMS to move an address list.
This chapter provides information and commands concerning the following topics: ■
Creating multiple recipients
■
Modifying multiple recipients
■
Reconnecting multiple disconnected mailboxes
This chapter focuses on the ways you can create and manage recipient objects in bulk. You will discover that using Exchange Management Shell (EMS) is a very efficient way to manage recipient objects in Exchange 2010. Also, you can “batch” PowerShell cmdlets together and save them as text files with a .ps1 extension and they will be executable from EMS. You will also investigate how to create templates to assist in bulk creation of user accounts and Exchange mailboxes.
Creating Multiple Recipients Creating one recipient at a time is not efficient in EMS. There are too many chances you will type something incorrectly or misconfigure an attribute. But, suppose the HR department provides you with a file each week with all new hires. You will probably want to find a way to extract the data from the file and use it to create both the Active Directory user accounts as well as the Exchange mailboxes. In this next section, you will investigate some of the ways to create recipients in bulk. The following table shows the contents of a .csv file that might be imported into Active Directory. Both an Active Directory user account as well as an Exchange mailbox will be created with this single file.
122
Creating Multiple Recipients
FirstName,LastName,Password, Department Linda,Rose,Pa$$w0rd,Shipping Larry,Ludin,Pa$$w0rd,Shipping Karen,Zadnik,Pa$$w0rd,Shipping Jim,Schaffer,Pa$$w0rd,Shipping Carolyn,Smith,Pa$$w0rd,Shipping Fred,Klein,Pa$$w0rd,Shipping Heather,Flinkman,Pa$$w0rd,Shipping Leo,Weishew,Pa$$w0rd,Shipping
(Name this file C:\Users\Administrator\ NewHires.csv.)
You are given a text file that is generated by the HR department from a database of information about newly hired employees, as shown on the left and in Figure 8-1. You want to import the data from the file, creating both Active Directory User accounts and Exchange mailboxes from the data in the file. Later, HR will give you a second file, shown in Figure 8-2, as more new hires begin work and also require an AD account and an Exchange mailbox. NOTE The attributes are very limited in this file to give you a general idea of how this works. You will want to import more attributes to make the accounts more usable in a production environment.
Figure 8-1
Text file with users to be imported
The script shown in this table takes the contents of the NewHires.csv file previously created and constructs Active Directory users accounts and Exchange mailboxes for each entry in the file.
Creating Multiple Recipients
## Section 1 ## Define Database for new mailboxes $db="ShippingDB" ## Define User Principal name $upndom="romacsign.com"
123
The text file shown on the left is one way to use the data in the NewHires.csv file to import users into Active Directory and assign Exchange mailboxes to the new users.
## Define OU for new users $ou="Shipping" ## Define CSV File with user information $csvFile="C:\Users\Administrator\ NewHires.csv" ## Section 2 ## Import csv file into variable $users $users = import-csv $csvFile ## Section 3 ## Function to convert Password string to secure string function SecurePassword([string]$plainPas sword) { $secPassword = new-object System.Security.SecureString Foreach($char in $plainPassword.ToCharArray()) { $secPassword.AppendChar($char) } $secPassword } ## Section 4 ## Create new mailboxes and users foreach ($i in $users) { $sp = SecurePassword $i.Password $upn = $i.FirstName + "@" + $upndom $display = $i.FirstName + " " + $i.LastName New-Mailbox -Password $sp -Database $db -UserPrincipalName $upn -Name $i.FirstName -FirstName $i.FirstName -LastName $i.LastName -OrganizationalUnit $OU }
If you use a file similar to this one, save it with a .ps1 extension and it will become executable from within EMS—much like a .bat file can be executed from the command line. The New-Mailbox cmdlet in Section 4 must all be typed on one line. It is word-wrapped here for readability.
TIP
Lines that begin with pound signs (##) are remarks. NOTE
The third character in “.ps1” is the number one and not a lowercase L. NOTE
(Rename this file C:\Users\Administrator\ NewHires.csv.)
Now that you have the .ps1 file, in the future when you are given another text file from HR containing a second batch of new hires, you can use the same .ps1 file to import data from this new .csv file into the Active Directory, as shown on the left and in Figure 8-2. Exchange mailboxes will be created for the new users as well. The only thing you must do in order for the .ps1 file to work correctly is rename the file to NewHires.csv. The contents of both the earlier .csv file with the first group of new hires and the current .csv file with the second group of new hires are shown in Figure 8-2. Execute the .ps1 file again. Figure 8-3 displays the results of the two executions of the NewHires.ps1 file. You can also see the newly hired employees in EMC, as shown in Figure 8-4.
Figure 8-2
Text files with both groups of new hires
Creating Multiple Recipients
Figure 8-3
EMS showing that two sets of users and mailboxes have been created
Figure 8-4
EMC showing mailboxes for both sets of users
125
The benefit of using a .ps1 file is that it is reusable. The .csv file contents may change, but the .ps1 file used to import the users and create the mailboxes does not change.
126
Creating Multiple Recipients
However, you can achieve similar results of bulk importing users from a .csv file without the use of a .ps1 script by using the steps shown in the following table. $Pass=ConvertTo-SecureString password -asPlainText –Force PS C:\Users\Administrator> $Pass=ConvertTo-SecureString "Pa$$w0rd" -asPlainText -Force
Name,UserName,Department Karen Michelfelder,KarenM,Shipping Michael Doyle,MikeD,Management Linda Cordon, LindaC,Reception Donna Ecksterowicz,Donna,Management Pete Dispenza,Pete,Management Tom Petock,Tom,Management Al Sorichillo,Al,Receiving Pattie Kass,Pattie,Shipping
This example defines a secure string password so that you don’t have to type a password for each user in the .csv file. This password will only be valid from within this session, unless you incorporate it into your PowerShell profile. NOTE
In the next example, you will again use a .csv file to import users and create mailboxes. This file is slightly different from the previous two. Look at the attribute line of the file. (The attribute line is the first line and has been bolded for your convenience.)
Another way to import the data from a .csv file is to use the Import-CSV cmdlet that incorporates a ForEach-Object cmdlet, as shown on the left and in Figure 8-5. This is a bit easier than using the .ps1 file, but less automated. You would need to type this each time you needed to import users from a .csv file.
PS C:\Users\Administrator>Import-CSV Note the use of the New-Mailbox "C:\Users\Administrator\ cmdlet embedded in the code. MoreNewHires.csv" | ForEach-Object -Process {New-Mailbox -Name $_.Name -UserPrincipalName "$($_.UserName)@romacsign.com" -OrganizationalUnit romacsign.com/ Users -Database OfficeDB -Password $Pass -ResetPasswordOnNextLogon $true}
This also works when you need to import Active Directory information in from the .csv file, as shown on the left and in Figure 8-5. The Department attribute is a property of a user, not a mailbox. Note the use of the Set-User cmdlet in this example, rather than the New-Mailbox cmdlet in the previous example. You will be populating an Active Directory User account attribute, rather than an Exchange Mailbox attribute if you execute this cmdlet. To view the result of the preceding cmdlet, use the Get-User cmdlet with a Where clause, as shown on the left and in Figure 8-5.
Figure 8-5 is a multipart illustration of the previous three steps. The first step creates the users and mailboxes from the MoreNewHires.csv file. The second step imports the department attribute to the Active Directory for the user account. The third step displays the department attribute for all users in the Management department. NOTE
Figure 8-5
127
Creating and managing recipients in bulk using EMS
128
Creating Multiple Recipients
You can even use a template to create mailboxes. To do this, take the Import-CSV cmdlet you created and executed earlier and assign a variable to it. (You can store this in your PowerShell profile.) Create a template and variable for each department for which you regularly create accounts and mailboxes. The following table shows how to create a template for the Shipping department. $Pass=ConvertTo-SecureString password -asPlainText –Force PS C:\Users\Administrator> $Pass=ConvertTo-SecureString "Pa$$w0rd" -asPlainText -Force Name,UserName,Department Kathy Crawford,KathyC,Shipping Ed Shields,EdS, Shipping Madge McCann,MadgeM, Shipping Andre Brown,AndreB, Shipping Terri Hines,TerriH, Shipping Bill Krupitzer,BillK, Shipping Morey Goldberg,MoreyG, Shipping Jim Masters, JimM, Shipping
Redefines the secure string password so that you don’t have to type a password for each user in the .csv file.
In the next example, you will again use a .csv file as a template to import users and create mailboxes.
By defining a variable for your Import-CSV cmdlet, you can simply type the variable name from a PS prompt, without having to type the entire cmdlet each time.
Modifying Multiple Recipients
PS C:\Users\Administrator> $NewShippers
Figure 8-6
129
When you are given a new .csv file for new hires in the Shipping department, you need only type the variable name for that department, as shown on the left and in Figure 8-6.
Creating and managing recipients in bulk using a template in EMS
Modifying Multiple Recipients It is also possible to modify multiple recipients using EMS. One modification you may want to make is to take a collection of existing users who do not have mailboxes and use EMS to enable them in bulk. The commands in the first section of the following table create 10 user accounts in Active Directory. The cmdlet that follows in the second section enables the mailboxes for the 10 newly created users.
130
Modifying Multiple Recipients
cd\ Dsadd ou "ou=Sales Training,dc=romacsign,dc=com" Dsadd ou "ou=Observers, ou=Sales Training, dc=romacsign,dc=com" Dsadd user "cn=salestrainee01,ou=Sales Training,dc=romacsign,dc=com" -pwd Pa$$w0rd -dept "Sales Training" Dsadd user "cn=salestrainee02,ou=Sales Training,dc=romacsign,dc=com" -pwd Pa$$w0rd -dept "Sales Training" Dsadd user "cn=salestrainee03,ou=Sales Training,dc=romacsign,dc=com" -pwd Pa$$w0rd -dept "Sales Training" Dsadd user "cn=salestrainee04,ou=Sales Training,dc=romacsign,dc=com" -pwd Pa$$w0rd -dept "Sales Training" Dsadd user "cn=salestrainee05,ou=Sales Training,dc=romacsign,dc=com" -pwd Pa$$w0rd -dept "Sales Training" Dsadd user "cn=salestrainee06,ou=Sales Training,dc=romacsign,dc=com" -pwd Pa$$w0rd -dept "Sales Training" Dsadd user "cn=salestrainee07,ou=Sales Training,dc=romacsign,dc=com" -pwd Pa$$w0rd -dept "Sales Training" Dsadd user "cn=salestrainee08,ou=Sales Training,dc=romacsign,dc=com" -pwd Pa$$w0rd -dept "Sales Training" Dsadd user "cn=salestrainee09,ou=Observers, ou=Sales Training,dc=romacsign,dc=com" -pwd Pa$$w0rd -dept "Sales Training" Dsadd user "cn=salestrainee10,ou=Observers, ou=Sales Training,dc=romacsign,dc=com" -pwd Pa$$w0rd -dept "Sales Training"
(Name this file C:Users\Administrator\ SalesTraineeEnableMB.bat.)
The Directory Services Administrator has created eight new salespeople and two observers as user accounts in the Active Directory. He or she may have done this with a .bat file similar to the one shown on the left. This is not an EMS cmdlet. This is done using the dsadd utility from Windows Server 2008. NOTE
Modifying Multiple Recipients
Use the following if all of the users are not in the same OU, as is the case in the preceding file: Get-User | Where-Object {$_.DistinguishedName -ilike OUName} | Enable-Mailbox -Database DatabaseName PS C:\Users\Administrator>Get-User | Where-Object {$_.DistinguishedName -ilike "*OU=Sales Training,dc=romacsign,dc=com"} | Enable-Mailbox -Database "TrainingDB"
Figure 8-7
131
Once the users have been created, you can use the EnableMailbox cmdlet to enable their mailboxes, as shown in Figure 8-7. NOTE The EnableMailbox cmdlet was written this way because not all of the users are in a single OU.
Mail-enabling users in bulk using EMS
The cmdlet to enable the users’ mailboxes becomes even easier when all of the users are in the same Active Directory OU, as shown in the following table. Use the following if all the users are in the same OU, as is not the case in the previous file: Get-User -OrganizationalUnit OUName | Enable-Mailbox -Database DatabaseName PS C:\Users\Administrator> Get-User -OrganizationalUnit "Sales Training" | Enable-Mailbox -Database "TrainingDB"
If all of the users were in the Sales Training OU, you could use this much simpler example. Figure 8-8 shows the created mailboxes in Exchange Management Console (EMC).
132
Modifying Multiple Recipients
Figure 8-8
Viewing the created mailboxes from EMC
Bulk modifying a mailbox attribute is equally simple if you know the syntax for the attribute that you want to modify. The cmdlets shown in the following table allow you to make a bulk modification to a group of mailboxes as well as view the change after it has been made. Get-Mailbox Mailboxes | Set-Mailbox-IssueWarningQuota QuotaSize PS C:\Users\Administrator> Get-Mailbox SalesTrainee* | Set-Mailbox -IssueWarningQuota 49MB Get-Mailbox Mailboxes | fl Name, IssueWarningQuota C:\Users\Administrator> Get-Mailbox SalesTrainee* | fl Name, IssueWarningQuota
If you wanted to change the default IssueWarningQuota to 49MB for all of the sales trainees, you could do so as shown on the left. 49MB was used because it is a unique number and would not correspond to any default values. NOTE
To verify that the settings took effect, use the example shown on the left and in Figure 8-9. Note the use of the asterisk (*), which will collect any mailbox with SalesTrainee in its name.
Reconnecting Multiple Disconnected Mailboxes
Figure 8-9
133
Viewing the result of the bulk modification
In Chapter 15, “Working with Mailboxes” you will investigate how to move multiple mailboxes from one database to another, as well as how to import and export a mailbox, which could also be done in bulk.
Reconnecting Multiple Disconnected Mailboxes In addition to using Exchange Management Console (EMC), it is also possible to reconnect disconnected mailboxes using EMS (as shown in the following table). This is especially helpful when multiple user accounts need to be reconnected to their mailboxes.
The sales trainees’ mailboxes have been disconnected because of an accidental deletion of the OU containing all sales trainees. You restore the Active Directory OU and sales trainee accounts with an authoritative AD restore and now you need to find all disconnected mailboxes for the sales trainees (in the TrainingDB) and reconnect them to their respective user accounts. The results of the ConnectMailbox cmdlet are shown in Figure 8-10.
Reconnecting mailboxes with the original user accounts
CHAPTER 9
The Hub Transport Role
This chapter provides information and commands concerning the following topics: ■
Configuring accepted and remote domains
■
Managing email address policies
■
Working with SMTP connectors and other transport objects
■
Working with routing group connectors
■
Managing transport queues
This chapter focuses on the creation and management of transport objects. Starting with creating Accepted Domain and Remote Domain objects, you will also learn how to configure email address policies as well as SMTP Send and SMTP Receive connectors from Exchange Management Shell. You will work with Routing Group connectors in a mixed environment with Exchange 2003, and you will also see how to manage transport queues from the command line.
Configuring Accepted and Remote Domains If it is an MX record that brings the email to your doorstep, it is the accepted domain that allows it to enter the Exchange organization. An accepted domain is any SMTP domain for which Microsoft Exchange accepts incoming messages. The three types of accepted domains in Exchange 2010 are as follows: ■
Authoritative domain—You use this type when you want to allow email to be delivered to a recipient that has a domain account and a mailbox in your Exchange organization.
■
Internal Relay domain—You use this type when you want to allow email to be delivered to a recipient in your organization or to be relayed to a server in another email system, but still under the authority of your company or organization.
■
External Relay domain—You use this type when you want to allow email to be delivered to a recipient outside of this Exchange organization, such as a business partner’s email system.
You can view, create, manage, and delete accepted domains with the following cmdlets: ■
Get-AcceptedDomain
■
New-AcceptedDomain
■
Set-AcceptedDomain
■
Remove-AcceptedDomain
136
Configuring Accepted and Remote Domains
Get-AcceptedDomain The following table shows the uses of the Get-AcceptedDomain cmdlet. PS C:\Users\Administrator> Get-AcceptedDomain
This example retrieves a list of all accepted domains.
New-AcceptedDomain The following table shows the uses of the New-AcceptedDomain cmdlet. PS C:\Users\Administrator> New-AcceptedDomain -Name "Romac Neon" -DomainName romacneon.com -DomainType Authoritative
Creates the domain name RomacNeon.com as a second Authoritative accepted domain in your Exchange organization.
Creates the domain name Sign1Suppliers.com as an External Relay accepted domain.
The successful creation and management of accepted domains can be viewed in Exchange Management Console (EMC), as shown in Figure 9-1.
Figure 9-1
Accepted domains as seen from Exchange Management Console
Configuring Accepted and Remote Domains
137
Set-AcceptedDomain The following table shows a use of the Set-AcceptedDomain cmdlet. PS C:\Users\ Administrator> Set-AcceptedDomain -Identity "Romac Sign Company" -DomainType Authoritative -MakeDefault $true
Edits the RomacSignCompany.com domain name, changing it from an Internal Relay to an Authoritative accepted domain and uses the MakeDefault parameter to specify the name as the new default domain. The first accepted domain created in the organization is created with a default value of $true. Subsequent accepted domains are created with a default value of $false unless you use the MakeDefault parameter equal to $true. NOTE
The successful creation configuration change of an Internal Relay accepted domain to the default Authoritative accepted domain can be viewed in Exchange Management Console, as shown in Figure 9-2.
Figure 9-2 Changing a namespace to the default accepted domain as seen from Exchange Management Console
Remove-AcceptedDomain The following table shows a use of the Remove-AcceptedDomain cmdlet. PS C:\Users\Administrator> Remove-AcceptedDomain -Identity "Sign 1 Suppliers"
Removes the domain name Sign1Suppliers.com as an accepted domain when it is no longer required
Remote domains allow you to define the settings for message transfer between your organization and mail domains outside your Active Directory forest. Accepted domains control what names come in to your organization, but remote domains control what types of messages go out to the other domain(s). Most commonly, this object controls Out of Office messages to specific Internet domains when you do not want out-of-office messages going to all Internet domain names. You can also apply message format
138
Configuring Accepted and Remote Domains
policies and acceptable character sets for messages that are sent from users in your organization to the remote domain.
Get-RemoteDomain The following table shows a use of the Get-RemoteDomain cmdlet. PS C:\Users\Administrator> Get-RemoteDomain
Retrieves a list of all remote domains
New-RemoteDomain The following table shows the uses of the New-RemoteDomain cmdlet. PS C:\Users\Administrator>New-RemoteDomain -DomainName SignDistributors1.com -Name "Sign Distributors 1"
These examples create two new remote domains for a business partner.
Set-RemoteDomain The following table shows the uses of the Set-RemoteDomain cmdlet. PS C:\Users\ Administrator> Set-RemoteDomain -Identity "Sign Distributors 1" -AllowedOOFType ExternalLegacy -DeliveryReportEnabled $true PS C:\Users\ Administrator> Set-RemoteDomain -Identity "Sign Distributors 2" -AllowedOOFType None -DeliveryReportEnabled $false
The first example edits the SignDistributors1.com remote domain, changing the AllowedOOFType parameter to ExternalLegacy. With this option enabled, only out-of-office messages configured as external by Outlook 2007 or OWA for mailboxes located on Exchange 2010 or Exchange 2007 Mailbox servers are delivered to the remote domain. Out-of-office messages set by Outlook 2003 or earlier clients, regardless of the server version of their mailbox store, are delivered to the remote domain. Out-of-office messages sent by Exchange 2003 or earlier servers, regardless of the client version used to set the out-of-office message, are delivered to the remote domain. It also sets the DeliveryReportEnabled parameter to $true. These settings are illustrated in Figure 9-3. The second example edits the SignDistributors2.com remote domain, changing the AllowedOOFType parameter to None and the DeliveryReportEnabled parameter to $false. These settings are illustrated in Figure 9-4.
Configuring Accepted and Remote Domains
Figure 9-3
139
Remote domain settings for SignDistributors1.com as seen from Exchange
Management Console
Figure 9-4 Remote domain settings for SignDistributors2.com as seen from Exchange Management Console
Select other parameters for the Set-RemoteDomain cmdlet are detailed in the following table.
140
Configuring Accepted and Remote Domains
-Identity
This required parameter specifies the display name of the remote domain. NOTE
The length of the name cannot exceed 64 char-
acters.
-AllowedOOFType (Example in previous Set-RemoteDomain table.)
This parameter specifies the type of out-of-office notification returned to users at the remote domain. The valid values are External, ExternalLegacy, None, and InternalLegacy. The default value is External.
-AutoForwardEnabled
This parameter specifies whether to allow messages that are automatically forwarded in your organization. Setting this parameter to $true enables auto-forwarded messages to be delivered to the remote domain. The default setting is $false.
-AutoReplyEnabled
This parameter specifies whether to allow messages that are automatic replies in your organization. Setting this parameter to $true enables automatic replies to be delivered to the remote domain. The default value is $false.
-DeliveryReportEnabled This parameter specifies whether to allow delivery reports in your organization to the remote domain. (Example in previous Set-RemoteDomain The default value is $true. table.) -IsInternal
This parameter specifies whether the recipients in this remote domain should be considered as an internal recipient. When you set this parameter to $true, all transport components, like transport rules or transport agents, treat this remote domain as an internal domain. The default value is $false.
-Name
This parameter specifies a unique name for the remote domain object.
-NDREnabled
This parameter specifies whether to allow non-delivery reports (NDRs) from your organization. Setting this parameter to $false suppresses NDRs to the remote domain. The default value is $true.
As shown in the following table, the Remove-RemoteDomain cmdlet deletes the remote domain object from the Active Directory.
Removes the remote domain SignDistributors1.com as a remote domain when it is no longer required. The -Confirm: $false option does not prompt you to confirm the removal of the remote domain. NOTE
TIP When you remove a remote domain, it does not disable mail flow to that domain. It only removes the settings for message transfer between your organization and the remote domain.
Managing Email Address Policies When a recipient is created, it must have an email address if it is to send or receive email. Recipients (which include users, resources, contacts, and groups) are any mailenabled object in Active Directory to which Microsoft Exchange can deliver or route messages. For a recipient to send or receive email messages, the recipient must have an email address. If you had to manually assign an email address policy to each recipient, it would not only be tedious, but it would also lead to inconsistencies in how email addresses were generated. An email address policy is used to automatically generate addresses for your recipients. The default policy uses the recipient’s alias before the “@” and the default accepted domain after, but that can be changed or a new policy can easily be created. The following table shows some of the cmdlets you might use when creating or managing an email address policy. PS C:\Users\Administrator> Get-EmailAddressPolicy
Retrieves a list of all email address policies in use in the organization.
Creates an email address policy using a recipient filter, which will generate an email address that includes firstname.lastname for all Sales users, as shown in Figure 9-5. An example of an address that would be generated for Larry Ludin would be Larry.Ludin@ romacsign.com.
An Active Directory administrator has redesigned the Philadelphia office, breaking it into three departments (Assembly, Manufacturing, and Office Staff) and your email address policy must be edited to include the third department. The existing departments must be included in the cmdlet. When you execute the cmdlet, it overwrites all existing values for the ConditionalDepartment attribute. The new ConditionalDepartment settings are illustrated in Figure 9-6. NOTE
Figure 9-5 New email address policy created using recipient filter, as seen from Exchange Management Console
Managing Email Address Policies
Figure 9-6 Console
143
New ConditionalDepartment settings as seen from Exchange Management
Other email address policy cmdlets are detailed in the following table. PS C:\Users\ Administrator> Update-EmailAddressPolicy -Identity "Philadelphia Office"
You have added a new department to the Philadelphia Office email address policy in the previous example using the SetEmailAddressPolicy, but it does not take effect. This example shows the use of the UpdateEmailAddressPolicy cmdlet, which you would apply after you use the Set-EmailAddressPolicy cmdlet to set the changes.
You have redesigned your email address policies and now you want to remove the Philadelphia Office policy. This example shows the removal of an email address policy. The -Confirm: $false option does not prompt you to confirm the removal of the email address policy. NOTE
144
Working with SMTP Connectors and Other Transport Objects
Working with SMTP Connectors and Other Transport Objects Two types of SMTP connectors can be created in Exchange 2010. Send connectors are required on Exchange 2010 transport servers to deliver messages to the next hop as they make their way through the transport pipeline. A Send connector controls outbound connections from the Exchange organization. Receive connectors are required on Exchange 2010 transport servers to receive messages from the Internet, from email clients, and from other email servers. A Receive connector controls inbound connections to the Exchange organization.
Send Connectors Send connectors are required in Exchange 2010 to send mail to other SMTP hosts. These Exchange objects are stored in the Active Directory at the organization level (for Hub Transport servers) and they create a logical connection between Exchange and other SMTP hosts. On Edge Transport servers, Send connectors can be configured to send mail to the Internet. On Edge Transport servers, the Send connector is stored locally in AD LDS. Creating a Send connector is a fairly simple process from the Exchange Management Console or from Exchange Management Shell. Get-SendConnector The following table shows the uses of the Get-SendConnector. PS C:\Users\ Administrator> Get-SendConnector PS C:\Users\ Administrator> Get-SendConnector -Identity "External Domain.com Send Connector" | fl
Allows you to view the configuration of all Send connectors in the organization. The example allows you to view the configuration of a specific Send connector to the domain ExternalDomain.com on a Hub Transport or Edge Transport server. Use this cmdlet after you have created a Send connector to view its configuration.
New-SendConnector The following table shows the uses of the New-SendConnector cmdlet.
Working with SMTP Connectors and Other Transport Objects
Allows you to create a new Send connector on a Hub Transport or Edge Transport. The first example creates a Send connector to two partner organizations with the following properties: ■
It sends email to the Internet.
■
It only processes messages addressed to the sign1suppliers.com and signdistributors.com domains.
The second example creates the Send connector “Secure to Sign1Suppliers.com” with the following properties: ■
It only processes messages for the Sign1Suppliers.com domain.
■
It uses Basic authentication.
■
It uses a specific authentication credential.
To assign the specific authentication credential for the Send connector, you must first run the Get-Credential cmdlet and store the user’s input as a temporary variable. When you run the GetCredential cmdlet, the command asks for the user name and password of the account used during authentication with the Sign1Suppliers.com mail server, as shown in Figure 9-7. NOTE
The temporary variable can then be used in the New-SendConnector cmdlet to create the new connector.
146
Working with SMTP Connectors and Other Transport Objects
Figure 9-7
Prompted for a credential
The following table details select other parameters for the New-SendConnector cmdlet. -AddressSpaces (Example in previous New-SendConnector table.)
This is a required parameter that specifies the names to which the Send connector will route mail.
-AddressSpaceType
This parameter specifies the type of address space and may be SMTP, X400, or any other text string. The default is an SMTP address space.
-AddressSpaceCost
This parameter specifies a relative cost for using
"SMTP:sign1suppliers.com;1" this connector. The valid input range for the cost
is from 1 through 100. A lower cost indicates a better route. (If you specify the address space type with the address space cost, you must enclose the address space in quotation marks [“] as shown in the example.) -AuthenticationCredential (Example in previous New-SendConnector table.)
This parameter specifies the creation and passing of a credential object.
-Custom
This parameter specifies the Custom usage type. The usage type specifies the permissions and authentication methods assigned to the Send connector.
-DNSRoutingEnabled
This parameter specifies whether the Send connector uses DNS to route mail. The valid values for this parameter are $true and $false and the default value is $true.
(Example in previous New-SendConnector table.)
Working with SMTP Connectors and Other Transport Objects
147
-Internal
This parameter specifies the Internal usage type. The usage type specifies the permissions and authentication methods assigned to the Send connector.
-Internet
This parameter specifies the Internet usage type. The usage type specifies the permissions and authentication methods assigned to the Send connector.
-MaxMessageSize
This parameter specifies the maximum size of a message that can pass through the connector. The default value is 10MB.
-Partner
This parameter specifies the Partner usage type. The usage type specifies the permissions and authentication methods assigned to the Send connector.
-SmartHostAuthMechanism
This parameter specifies the smart host authentication mechanism to use during authentication with a remote server. This parameter is used only when a smart host is configured and the DNSRoutingEnabled parameter is set to $false.
(Example in previous New-SendConnector table.)
The valid values are None, BasicAuth, BasicAuthRequireTLS, ExchangeServer, and ExternalAuthoritative and each value is mutually exclusive with the others. -SmartHosts (Example in previous New-SendConnector table.)
This parameter specifies the smart hosts that the Send connector may use to route mail and is required if you set the DNSRoutingEnabled parameter to $false. The SmartHosts parameter can use FQDNs or IP addresses, or combinations of both. You must separate entries with a comma.
-SourceIPAddress
This parameter specifies the local IP address to use as the endpoint for an SMTP connection to a remote messaging server. The default IP address is 0.0.0.0. This value means that the server can use any available local IP address. This parameter is only valid for Send connectors configured on Edge Transport servers.
-SourceTransportServers
This parameter specifies the names of the Hub Transport servers that can use this Send connector. If you specify more than one Hub Transport server, you must separate entries with a comma.
148
Working with SMTP Connectors and Other Transport Objects
Set-SendConnector The following table shows the uses of the Set-SendConnector cmdlet. Allows you to modify a Send connector on a Hub Transport or Edge Transport server.
Set-SendConnector -Identity ConnectorName -MaxMessageSize Value PS C:\Users\Administrator> Set-SendConnector -Identity "Secure to Sign1Suppliers.com" -MaxMessageSize 25MB
The example allows you to edit the configuration of a specific Send connector on a Hub Transport, changing its MaxMessageSize attribute to 25MB from its default value of 10MB.
You might set the same parameters with the Set-SendConnector cmdlet as you did when you created the connector with the New-SendConnector cmdlet.
TIP
Remove-SendConnector The following table shows a use of the Remove-SendConnector cmdlet. PS C:\Users\ Administrator> Remove-SendConnector -Identity "Secure to Sign1Suppliers.com" -Confirm: $false
Allows you to remove a Send connector on a Hub Transport or Edge Transport server. The example allows you to edit the configuration of a specific Send connector on a Hub Transport or Edge Transport server. The -Confirm: $false option does not prompt you to confirm the removal of the Send connector.
NOTE
Receive Connectors Receive connectors are required in Exchange 2010 to receive mail from other SMTP hosts. These Exchange objects are stored in the Active Directory at the server level (for Hub Transport servers) and they create a logical connection between Exchange and other SMTP hosts. On Edge Transport servers, Receive connectors can be configured to receive mail from the Internet. On Edge Transport servers, the Receive connector is stored locally in AD LDS. Creating a Receive connector is also a fairly simple process from either the Exchange Management Console or from Exchange Management Shell. The following table shows a use of the Get-ReceiveConnector as well as a use of the New-ReceiveConnector cmdlets. PS C:\Users\Administrator> Get-ReceiveConnector -Server Romac-EX1
Allows you to view the configuration information for all Receive connectors on the specified Hub Transport or Edge Transport server.
Working with SMTP Connectors and Other Transport Objects
Creates a new Receive connector on a server that has the Hub Transport or the Edge Transport role installed on it. Port number, listening IP address (Bindings), and accepted remote IP addresses (RemoteIPRanges) must be specified in the cmdlet. NOTE
New-ReceiveConnector The following table includes select other parameters for the New-ReceiveConnector cmdlet. -Bindings (Example in previous NewReceiveConnector cmdlet.)
This required parameter specifies the local IP address and TCP port numbers used by the Receive connector to listen for inbound messages. An IP address of 0.0.0.0 indicates that the Receive connector uses all IP addresses configured on all network adapters to listen for inbound messages. If you specify an incorrect local IP address, the Microsoft Exchange Transport service may fail to start when the service is restarted.
-RemoteIPRanges (Example in previous NewReceiveConnector cmdlet.)
The required parameter specifies the remote IP addresses from which this connector accepts messages. You can specify a single IP address or multiple IP address ranges separated by commas.
-Usage (Example in previous NewReceiveConnector cmdlet.)
This required parameter specifies the default permission groups and authentication methods that will be assigned to the Receive connector. The valid values for the Usage parameter are Client, Custom, Internal, Internet, and Partner. If you don’t specify a value for a required parameter, the cmdlet fails.
150
Working with SMTP Connectors and Other Transport Objects
AuthMechanism
This parameter specifies the advertised and accepted authentication mechanisms. The valid authentication options are None, TLS, Integrated, BasicAuth, BasicAuthRequireTLS, ExchangeServer, and ExternalAuthoritative. You can enter multiple values for the AuthMechanism parameter by separating the values with commas.
-ConnectionTimeout (Example in Set-ReceiveConnector cmdlet that follows this table.)
This parameter specifies the maximum time that a connection can remain open. This applies even if the connection is actively transmitting data over the connector. The default value for a Receive connector configured on a Hub Transport server is 10 minutes. The format for the time span is dd.hh:mm:ss (where d = days, h = hours, m = minutes, and s = seconds). The maximum value is 1 day and the minimum value is 1 second.
-DeliveryStatusNotificationEnabled This parameter specifies whether the delivery status notification (DSN) EHLO keyword is advertised in the EHLO response to the remote server and is available for use. This parameter can be set to either $true or $false. -PermissionGroups
This parameter specifies the groups or roles that can submit messages to the Receive connector and the permissions assigned to those groups. A permission group is a predefined set of permissions and valid values for this parameter, which include None, AnonymousUsers, ExchangeUsers, ExchangeServers, ExchangeLegacyServers Partners, and Custom.
Set-ReceiveConnector The following table shows a use of the Set-ReceiveConnector cmdlet.
Working with SMTP Connectors and Other Transport Objects
PS C:\Users\Administrator> Set-ReceiveConnector -Identity "Inbound from Sign1Suppliers.com" -ConnectionTimeout 00:20:00
151
Changes the default timeout value for the Receive connector specified from its default of 10 minutes to 20 minutes.
Remove-SendConnector The following table shows a use of the Set-ReceiveConnector cmdlet. PS C:\Users\Administrator> Remove-ReceiveConnector -Identity "Inbound from Sign1Suppliers.com" -Confirm: $false
Removes the specified Receive connector when it is no longer required. The -Confirm: $false option does not prompt you to confirm the removal of the Receive connector. NOTE
Other Transport Cmdlets The following table includes transport cmdlets other than those specifically designed for the creation, management, and removal of Send and Receive connectors. PS C:\Users\Administrator> Get-TransportConfig Get-TransportConfig | fl MaxSendSize
Allows you to view organizationwide email transport configuration settings on a Hub Transport (or Edge Transport) server. The second example allows you to view the specified attribute.
Allows you to view some transport configuration information for a Hub Transport server. The second example displays all attributes for the specified server. The third example displays information about a specified attribute that you will later change with a SetTransportServer cmdlet. Allows you to change the specified attribute from its default of 1000MB (1GB) to 2000MB (2GB). NOTE You could again use the Get-TransportServer Romac-EX1 | fl Name, MessageTrackingLogMaxDirectorySize
cmdlet to view the change. PS C:\Users\Administrator> Get-NetworkConnectionInfo
Allows you to view the network configuration data for all network adapters configured on an Exchange server.
Working with Routing Group Connectors Routing Group connectors are not needed in Exchange Server 2010. However, older Exchange messaging systems still require routing groups. The first Routing Group connector between Exchange 2010 and Exchange 2003 is created for you during the installation of your first Hub Transport server role in an existing Exchange 2003 organization, and all Exchange 2010 Hub Transport servers are automatically put into that single 2010 routing group. A Hub Transport role acts as a bridgehead server in the 2010 routing group to connect with bridgeheads in the 2003 routing groups. This 2010 routing group is hidden from the Exchange Management Console, but is seen as Exchange Routing Group (DWBGZMFD01QNBJR) in Exchange System Manager, the Exchange 2003 GUI management tool. You cannot use Exchange System Manager to manage the Exchange 2010 routing group and will no longer be able to use it to manage any Routing Group connectors that include a 2010 Hub Transport server as either the source server or the target server. TIP Add one letter to each character and the “DWBGZMFD01QNBJR” name spells “EXCHANGE12ROCKS.” It should be noted that this name cannot be changed.
As shown in the following table, you can use several cmdlets in Exchange Management Shell to create and manage Routing Group connectors.
Working with Routing Group Connectors
153
New-RoutingGroupConnector -Name ConnectorName -SourceTransportServers SourceServerName -TargetTransportServers TargetServerName -Cost Value -Bidirectional $boolean value -PublicFolderReferralsEnabled $boolean value
Creates reciprocal Routing Group connectors (because of the bidirectional parameter) between the Exchange 2010 routing group and the routing group associated with the specified Exchange Server 2003 server.
A cost of 44 is assigned to the connector, and public folder referrals are enabled over the connector.
Get-RoutingGroupConnector -Identity RGCName
Allows you to view the attributes of the Routing Group connector created in the previous example.
PS C:\Users\Administrator> Get-RoutingGroupConnector -Identity "Exchange Administrative Group (FYDIBOHF23SPDLT)\Exchange Routing Group (DWBGZMFD01QNBJR)\E2k10 to E2k3 RGC" Set-RoutingGroupConnector -Identity RGCName -Cost Value -MaxMessageSize Value -SourceTransportServers SourceServerName -TargetTransportServers TargetServerName PS C:\Users\Administrator> Set-RoutingGroupConnector -Identity "Exchange Administrative Group (FYDIBOHF23SPDLT)\Exchange Routing Group (DWBGZMFD01QNBJR)\E2k10 to E2k3 RGC" -Cost 57 -MaxMessageSize 7MB -SourceTransportServers "Romac-EX1.romacsign.com" -TargetTransportServers "Romac-Legacy2k3-EX01.romacsign.com"
Allows you to edit one or more attributes for the Routing Group connector created in the first example. The cost is changed from 44 to 57, and the MaxMessageSize has been changed from the default value of 10MB to 7MB.
154
Managing Transport Queues
TIP You must use the Exchange Management Shell to configure these connectors. The permissions necessary to allow mailflow between the server versions are automatically configured when the Routing Group connector is created.
Managing Transport Queues Transport servers host queues. Messages may be brought into the organization in several different ways: ■
Messages can be placed in the Submission queue by the store driver when it retrieves messages from users’ outboxes on a mailbox server.
■
Messages can be brought into the organization and placed in the Submission queue from another SMTP host using an SMTP Receive connector.
■
Properly formatted messages in the Pickup directory are placed in the Submission queue.
To view and manage the queues on a transport server, you will need to know several cmdlets (as detailed in the following table). PS C:\Users\Administrator> Get-Queue | fl
Allows you to view configuration information for queues on the local Hub Transport server or Edge Transport server.
Get-Queue -Filter {MessageCount -gt Value}
Lists all queues that contain more than 500 messages in them.
TIP Queue management is often more efficient from Exchange Management Shell than with Queue Viewer due to the overhead of the GUI environment in Queue Viewer.
This page intentionally left blank
CHAPTER 10
The Edge Transport Role
This chapter provides information and commands concerning the following topics: ■
Creating an Edge Subscription
■
Edge Synchronization
■
Cloning an Edge Transport
■
Address Rewriting
This chapter focuses on the configuration of an Edge Transport server. You will first create an Edge Subscription, which makes the Active Directory aware of the existence of the Edge Transport server and affiliates it with an Active Directory site. Next, you will set up Edge Synchronization, which is a secure replication of data from the Active Directory through Hub Transport servers to the Edge Transport. Then, you will clone an Edge Transport, which will back up the configuration data to an .xml file and can be used to rebuild a failed Edge Transport or create a second Edge Transport using the configuration data from the first server. Finally, you will create Address Rewrite entries, a feature unique to Edge Transport servers.
Creating an Edge Subscription You begin the process of creating an Edge Subscription from the Edge Transport server. In addition to other things, this creates a key pair that is used as part of Edge Synchronization to securely pass data from the secure Active Directory network to the Edge Transport, which is in the DMZ. An .xml file is created, and that file is used in the next step, when you subscribe the server to the Active Directory site. All Hub Transports present at the time of the subscription can then synchronize with the Edge Transport. If a Hub Transport is removed after the subscription, the other Hub Transports will still be able to synchronize with the Edge Transport. However, if a new Hub Transport is added, you have to remove the subscription and subscribe the Edge Transport again. The subscription process is surprisingly easy. From the new Edge Transport server, you must create an Edge Subscription .xml file that you will use to create the Edge Subscription on one of your Hub Transport servers (as shown in the following table). New-EdgeSubscription -Filename FileName PS C:\Users\Administrator> New-EdgeSubscription -Filename "C:\NewEdge.xml"
Creates the file on the Edge Transport server that will be used in the creation of the subscription on a Hub Transport server.
158
Creating an Edge Subscription
Now that the subscription file has been created, it must be brought to any Hub Transport server in the organization. Because there is normally a firewall between your core network and your DMZ, it may not be easy to copy the .xml file to a Hub Transport server. You can use removable media such as a flash drive if your security administrators permit it. When you move the file to one of your Hub Transport servers, you should make sure you don’t leave a copy of the file behind on your Edge Transport server. The information contained in this file could compromise the integrity of your organization. The file should be destroyed after you use it or it should be moved to a secure location. NOTE
From any Hub Transport server, you will take the Edge Subscription .xml file created previously and use it to create the actual subscription (as shown in the following table). New-EdgeSubscription -Site SiteName -FileData $(Get-Content -Path FileName -Encoding Byte) PS C:\Users\Administrator> New-EdgeSubscription -Site "Default-First-Site-Name" -FileData $(Get-Content -Path "C:\NewEdge.xml" -Encoding Byte) PS C:\Users\Administrator> Get-EdgeSubscription | Format-List
Creates the subscription for the new Edge Transport in the Active Directory. Path refers to the location and file name where you copied the subscription file from the Edge Transport server. NOTE
Retrieves a list of all Edge Subscriptions registered in the Active Directory, including the one you just created in the previous example.
The successful creation of the Edge Subscription can be viewed in Exchange Management Console (EMC), as shown in Figure 10-1.
Figure 10-1
Successful Edge Subscription as seen from EMC
Edge Synchronization
159
Modification of an Edge Subscription is not possible. The only available option is to remove the subscription and subscribe the server again. As shown in the following table, you can remove an Edge Subscription from any Hub Transport because it is stored in the Active Directory. PS C:\Users\ Administrator> Remove-EdgeSubscription -Identity Romac-Edge
Removes an Edge Subscription. After you remove the Edge Subscription, all synchronization from the Active Directory to the Edge Transport server stops. All the accounts stored in AD LDS are removed. The Edge Transport server is removed from the source server list of any Send connector.
Edge Synchronization Once the subscription has been created, the Configuration partition replicates every 60 minutes by default. The Recipient partition replicates every 4 hours by default. The information passed to the Edge Transport server during synchronization includes the following: ■
Send connector configuration data
■
Accepted domains
■
Remote domains
■
Message classifications
■
Safe senders lists (hashed)
■
Blocked senders lists
■
Recipients (hashed)
■
List of Send and Receive domains used in domain secure communications with partners
■
List of SMTP servers identified as internal in your organization’s transport configuration
■
List of Hub Transport servers in the subscribed Active Directory site
The following table shows you how to start Edge Synchronization manually. PS C:\Users\Administrator> Manually starts an Edge Synchronization. A successful Edge Synchronization is shown in Figure Start-EdgeSynchronization
10-2. TIP If you receive a CouldNotConnect error message during Edge Synchronization, as shown in Figure 10-3, it is most likely due to the fact that there is no host (A) record in DNS for your Edge Transport server. Create a DNS host record for the Edge Transport server, as shown in Figure 10-4, flush the DNS cache on your Hub Transport server, and then try the Start-EdgeSynchronization cmdlet again.
160
Edge Synchronization
Figure 10-2
Successful Edge Synchronization as seen from EMS
Figure 10-3
Unsuccessful Edge Synchronization as seen from EMS
Cloning an Edge Transport
Figure 10-4
161
Creation of Static DNS host record for the Edge Transport server
The following table shows you how to test Edge Synchronization. PS C:\Users\Administrator> Test-EdgeSynchronization Test-EdgeSynchronization -VerifyRecipient RecipientEmailAddress PS C:\Users\Administrator> Test-EdgeSynchronization -VerifyRecipient [email protected]
Uses a cmdlet that provides a report of the synchronization status of your subscribed Edge Transport servers. One option you could use is the VerifyRecipient parameter to verify that a single recipient has been successfully synchronized to the Edge Transport server. This cmdlet compares the data stored in Active Directory and the data stored in AD LDS. Inconsistent data is reported in the output of the cmdlet.
Cloning an Edge Transport Two scripts are provided in Exchange 2010 for cloning an Edge Transport server. They are located by default in the C:\Program Files\Microsoft\Exchange Server\V14\Scripts directory on your Edge Transport server and are detailed in the following table.
Copies the clone configuration data from your Edge Transport server to an .xml file. Copy the ImportEdgeConfig.ps1 script to the root folder of your user profile on the server you are restoring and then run the .ps1 file. After the clone configuration data file has been created, place it in a secure location until it is needed. When needed, perform a clean installation of an Edge Transport server. If the file is to be used to rebuild a failed server, build the server with the same name as the failed server. Otherwise, give the new server an appropriate name.
Validate the configuration file and create an answer file, as shown in Figure 10-5, which will provide server-specific information when the file is imported. The isImport $false option validates the file.
Note Success Figure 10-5 file
Successful validation of the configuration file and the creation of an answer
The following table shows the original answer file, followed by the modified answer file after the server name has been changed. Once the answer file has been modified, you would use the Import-EdgeConfig.ps1 file to import data from one Edge Transport server to another.
Cloning an Edge Transport
Original Answer File: <MachineSpecificSettings> Romac-NewEdge.romacsign.com
Import the Edge Transport server configuration by using the ImportEdgeConfig.ps1 script. The isImport $true option performs the actual import. “C:\RomacEdge.xml” represents the full path of the intermediate .xml template file that will be used by the ImportEdgeConfig. ps1 script. NOTE
“C:\RomacEdgeAnswer.xml” represents the full path of the .xml answer file. When the import is completed, the confirmation message “Importing Edge configuration information succeeded” appears as shown in Figure 10-6.
164
Cloning an Edge Transport
Note Success Figure 10-6
Successful import of the Edge configuration file
Once the new Edge Transport server has been configured, you should subscribe it as you did with the original Edge Transport server, as shown in the following table. PS C:\Users\ Administrator> New-EdgeSubscription -Filename "C:\RomacNEWEdge.xml"
Figure 10-7
Create a subscription for the new server, as you did with Romac-Edge earlier, as shown in Figure 10-7. This example creates the subscription file. You would do this on Romac-NEWEdge.
Successful Edge subscription of second Edge Transport as seen from EMC
The following table shows the successful subscription and synchronization of the new Edge Transport server.
Allow the Hub Transports to synchronize with the new Edge Transport server either on a schedule or manually. (Manually is shown in the example and in Figure 10-8.)
Figure 10-8
Successful Edge subscription of second Edge Transport as seen from EMC
At this point the cloning process is complete. The second Edge Transport server is subscribed, synchronized, and identically configured to the first Edge Transport server.
Address Rewriting With Address Rewriting in Microsoft Exchange Server 2010, you can modify the addresses of senders and recipients for messages entering or leaving the organization through an Edge Transport server. This is performed by creating and configuring one or more Address Rewriting agents and creating Address Rewrite entries, as shown in the following table.
Retrieves a list of all existing address rewrite entries that rewrites sender and recipient email addresses for messages sent to or from an organization. If there are no address rewrite entries present, you will be brought back to a PS prompt and no output will be displayed. NOTE
Creates an address rewrite entry for all email addresses in the romacvinylsigns. com domain and all subdomains.
The address will be rewritten for messages in both directions.
With the -OutboundOnly attribute set to $true, only outbound email messages will be rewritten. There is a 64-character limitation on the Name attribute. NOTE
You can change one or more properties of an Address Rewrite entry by using the SetAddressRewriteEntry cmdlet, as shown in the following table. PS C:\Users\Administrator> Set-AddressRewriteEntry "Address rewrite romacvinylsigns.com and subdomains" -Name "Address rewrite romacdigitalsigns.com" -InternalAddress "romacvinylsigns.com"
Modifies the internal domain name to be written for the Address Rewrite entry for romacvinylsigns.com.
PS C:\Users\Administrator> Get-AddressRewriteEntry | ft Name, InternalAddress, ExternalAddress
Allows you to view the address rewrite entries created previously.
It also modifies the descriptive name to reflect the new domain name to be rewritten.
These changes are also shown in Figure 10-9.
Address Rewriting
Figure 10-9
167
Successful creation of address rewrite entries on an Edge Transport server
TIP Address Rewriting can only be performed by Edge Transport servers, not Hub Transport servers.
This page intentionally left blank
CHAPTER 11
Configuring Rules and Agents on Transport Servers
This chapter provides information and commands concerning the following topics: ■
Transport rules and transport agents
■
Journaling rules and journaling agents
■
Anti-spam agents
This chapter focuses on the configuration of rules and agents on Hub Transport servers. There are many rules and many combinations of conditions and actions that make up rules. The intent of the first portion of the chapter is not to explore each combination, but to provide the cmdlet and parameter syntax so that you can create transport rules using Exchange Management Shell.
Transport Rules and Transport Agents Transport rules can restrict message flow as a message passes through your organization. They can also modify the contents of the message. This puts great power in the hands of those who create these rules. These rules allow you to comply with company or government regulations, by applying messaging policies to messages that flow through the transport pipeline on Hub Transport or Edge Transport servers. Here are some of the things that can be achieved with a transport rule: ■
Applying one or more disclaimers in your organization as the messages pass through the organization
■
Preventing confidential or inappropriate messages from entering or leaving the organization
■
Restricting inbound or outbound messages from being delivered until they are inspected
■
Tracking messages that are sent to or received from specific individuals
■
Archiving specific messages for specific individuals
Transport Rules Transport rules are made up of three components, as detailed in the following table.
170
Transport Rules and Transport Agents
Conditions
Conditions identify the messages to which a transport rule action should be applied. Within a condition is a component called a predicate. A predicate stipulates which part of the message should be examined.
Actions
Actions are performed on messages that match the conditions of the rule, provided they are not specifically excluded by an exception. One of the most common actions that a company will want to take is to insert a disclaimer into the message.
Exceptions
Exceptions are very much like conditions. They look for the same predicates. The difference is that instead of applying the action, exceptions prevent the action from taking effect. Exceptions override conditions.
The following table details the various transport rule cmdlets. PS C:\Users\Administrator> Get-TransportRuleAction
Retrieves a list of transport rule actions that can restrict message flow or modify message content as the message passes through the transport pipeline. The version of Exchange Server determines which transport rule actions are available. Each new version adds additional options. NOTE
Retrieves a list of all transport rule predicates that determine the available conditions and exceptions. The version of Exchange Server determines which transport rule predicates are available. Each new version adds additional options. NOTE
PS C:\Users\Administrator> Get-TransportRule
Retrieves a list of all transport rules configured on all Hub Transport servers or a single Edge Transport server.
Get-Transport Rule -Identity Transport rule GUID or Name | Format-List
Displays the properties of the specified transport rule.
PS C:\Users\Administrator> New-TransportRule -Name 'Disclaimer Rule' -Comments 'This rule applies the company disclaimer to all messages from internal users.' -Priority '0' -Enabled $true -FromScope 'InOrganization' -ApplyHtmlDisclaimerLocation 'Append' -ApplyHtmlDisclaimerText ' %%displayname%%%%title%% %%company%%%%street%% %%city%%, %%state%% %%zipcode%% <span style="font-size:12pt; font-family: ''Cambria'',''times new roman'',''garamond'',serif; color:#ff0000;">Confidentiality Notice:
This message contains confidential information and is intended only for the individual(s) addressed in the message. If you are not the named addressee, you should not disseminate, distribute, or copy this e-mail. If you are not the intended recipient, you are notified that disclosing, distributing, or copying this e-mail is strictly prohibited.
Creates a new transport rule that stamps a disclaimer on every message from an internal user, no matter where the message will go. All of the text in the -ApplyHtmlDisclaimerText parameter is the HTML code that makes up your disclaimer. The rule’s condition and action in the example are for illustration only. You would create rules with the appropriate conditions and actions to meet your needs. NOTE
172
Transport Rules and Transport Agents
The newly created rule can be viewed in Figure 11-1 and the disclaimer can be viewed in Figure 11-2.
Figure 11-1
Newly created transport rule as seen in EMC
Figure 11-2
Disclaimer applied by the transport rule
The following table details the use of the Get-TransportRule cmdlet.
Retrieves specified parameters for a rule you wish to modify, as shown in Figure 11-3. (Notice that the SentToScope parameter has no associated value.)
Original transport rule showing the specified parameters
The following table uses the Set-TransportRule cmdlet to change the SentToScope attribute and verifies the change with the Get-TransportRule cmdlet. PS C:\Users\Administrator> Set-TransportRule -Identity "Disclaimer Rule" -SentToScope NotInOrganization
Modifies a transport rule so that it will be applied to messages sent only to recipients outside of your Exchange organization.
Retrieves specified parameters for the modified rule, as shown in Figure 11-4.
Figure 11-4
(Notice that the SentToScope parameter now has a value of NotInOrganization.)
Modified transport rule showing the specified parameters
Transport Agents Transport rules are applied on Hub Transport and Edge Transport servers by transport agents. On the Hub Transport servers, which are members of the Active Directory,
174
Journaling Rules and Journaling Agents
rules are applied uniformly by the Transport Rules agent. The agent fires on the OnRoutedMessage transport event. Because the transport rules are stored in Active Directory, they are available to all Hub Transport servers in the organization, and this allows all Hub Transport servers to consistently apply a single set of rules across the entire organization. The server processing the message queries the Active Directory to retrieve the organization’s transport rules and then applies the rule(s) to all messages that it processes. PS C:\Users\ Retrieves all of the enabled transport agents and the SMTP events on which they are registered. Administrator> Get-TransportPipeline NOTE The information retrieved by the GetTransportPipeline cmdlet is retrieved only after a message has been sent through the transport pipeline. Prior to the first message being sent in an organization, no transport information will be available.
Journaling Rules and Journaling Agents Exchange 2010 provides three journaling options: ■
Standard journaling—Configured on the mailbox database. The journaling agent journals all messages sent to and from mailboxes located in the specific mailbox database.
■
Premium journaling—Enables the journaling agent to perform a more granular level of journaling by using journal rules. You must have an Exchange Enterprise client access license (CAL) for each mailbox that will require premium journaling.
■
Journaling as a part of Messaging Records Management—Allows you to incorporate journaling into your managed folder mailbox policies. You must also have an Exchange Enterprise client access license (CAL) to use this form of journaling.
Journaling Rules The following table shows an example of standard journaling. Before performing the next steps, create a User mailbox recipient that will act as the journal mailbox. In the example, it will be called ProductionJournalMB. NOTE
Enables journaling for the mailbox database called ProductionDB and sets ProductionJournalMB as the journal recipient. The JournalRecipient parameter specifies where the journal reports are sent. NOTE
Journaling Rules and Journaling Agents
175
The following table shows an example of premium journaling. Before performing the next steps, create a User mailbox recipient that will act as the journal mailbox. In the examples, it will be called JournalMailbox. NOTE
Configures delivery restrictions on a journaling mailbox called Journal Mailbox. It restricts the mailbox to accept messages only from the Microsoft Exchange recipient. This optional procedure should only be performed in organizations where the journaling mailbox is required to receive email only from the Microsoft Exchange recipient. Be aware that this step cannot be performed from EMC, because the system mailbox called “Microsoft Exchange” is hidden in the GAL. NOTE
Disables mailbox quotas for the journaling mailbox and is an optional step that should be taken only when the journaling mailbox has ample storage and will not consume all of the space in the database.
Creates a journal rule to journal all messages sent to and received by the recipient VP@ romacsign.com.
This also is an optional step. NOTE
TIP The scope parameter determines which messages are journaled for the recipient. A scope of Internal means that both sender and recipient must be internal. A scope of External means that either the sender or the recipient of the message must be external. A scope of Global, as in the example, means that all messages to and from the recipient will be journaled, regardless of where the recipient is located.
176
Journaling Rules and Journaling Agents
The following table shows you how to disable, enable, modify, or remove a rule after it has been created. PS C:\Users\Administrator> Disable-JournalRule "Journal VP E-mail" -Confirm: $false
The -Confirm: $false option means that you will not be prompted to confirm the disabling of the rule and is an optional parameter. NOTE
Messages sent internally are no longer journaled.
The following table shows you how to set an alternate journaling mailbox. PS C:\Users\Administrator> Set-TransportConfig -JournalingReportNdrTo [email protected]
Allows you to configure Exchange to redirect rejected journal reports to an alternate journaling mailbox named [email protected]. Rejections may occur due to inaccessibility of the journal mailbox or because the mailbox has become full. You cannot use the EMC to configure an alternate journaling mailbox. You also may not have more than one alternate journaling mailbox. NOTE
Journaling Agents In an Exchange 2010 organization, all email traffic is routed by one or more Hub Transport servers. Every message passes through at least one Hub Transport. The journaling agent processes all of these messages, looking for those messages to be copied as part of standard journaling at the database level as well as specific journaling as dictated by rules that have been created as part of premium journaling. The agent fires on the OnSubmittedMessage and OnRoutedMessage transport events.
Anti-Spam Agents
177
The journaling agent is a built-in agent and cannot be viewed with the GetTransportAgent cmdlet, as was the case in Exchange Server 2007.
Anti-Spam Agents To install the anti-spam agents on a Hub Transport server, navigate to the C:\Program Files\Microsoft\Exchange Server\Scripts directory (on a default installation) in Exchange Management Shell and run the install-antispamagents.ps1 PowerShell executable script. After installation, you can view and configure the anti-spam agents on the Anti-spam tab under the Organization Configuration | Hub Transport node in Exchange Management Console. (Close and reopen the console if the Anti-spam tab does not appear.) The following .ps1 file installs all the built-in anti-spam agents on transport servers in Exchange Server 2010. PS C:\Users\Administrator> .\install-antispamagents.ps1
Installs the anti-spam agents on the Hub Transport server and Edge Transport servers.
The Anti-spam tab and associated agents are shown in Figure 11-5.
Figure 11-5 Console
Anti-spam agents on the Anti-spam tab as seen in Exchange Management
As shown in the following table, you can also uninstall the Anti-spam agents if you no longer require them. PS C:\Users\Administrator> .\uninstall-antispamagents.ps1
Uninstalls the anti-spam agents on a transport server.
TIP If you are using an Edge Transport server, it is not necessary to install the agents on a Hub Transport server.
This page intentionally left blank
CHAPTER 12
CAS Services
This chapter provides information and commands concerning the following topics: ■
Configuring Outlook access
■
Enabling and configuring Outlook Anywhere access
■
Enabling and configuring OWA access
■
Configuring of POP3 and IMAP4
■
Configuring the Autodiscover service
■
Configuring the Offline Address Book (OAB)
This chapter focuses on the configuration of the Client Access Server from the various clients’ perspective. You will observe how to configure various clients to connect to and receive information from the CAS.
Configuring Outlook Access There are times when you would like to restrict certain clients from accessing Exchange. In many cases, this is done simply by disabling a service on a server. However, what if you would like to restrict certain client modes or certain client versions from accessing Exchange? This can be accomplished with the Set-CASMailbox cmdlet. The Set-CASMailbox cmdlet has many purposes, most dealing with Outlook Web App. However, it can also restrict Outlook modes or versions as necessary. The following table shows how to enable/disable Cached Exchange Mode. PS C:\Users\Administrator> Get-Mailbox -OrganizationalUnit "Inside Sales" | Set-CASMailbox -MAPIBlockOutlookNonCachedMode $true
Prevents recipients in the Inside Sales OU from accessing Exchange using Cached Exchange Mode.
The following table shows how to enable and disable versions of Outlook.
Restricts MAPI access to Exchange to just Outlook 2007 versions. For example, your organization has decided that Outlook 2003 is not permitted to connect to Exchange 2010, and Outlook 2010 will not be permitted until testing can take place in the lab environment. The first URL links to Microsoft TechNet and displays Outlook version information: http://support.microsoft.com/ kb/870929 NOTE
The second URL displays proper formatting for the version IDs:http://support.microsoft. com/?kbid=288894
TIP The other versions of Outlook are listed in Chapter 33, "Reporting and Other Useful Cmdlets."
Enabling and Configuring Outlook Anywhere Access To allow users to access Exchange using Outlook when they are not on the local network, you may want to enable Outlook Anywhere. Outlook Anywhere was called RPC over HTTP in Exchange 2003. The following table shows you how to enable/disable the clients’ access to Exchange with Outlook Anywhere. PS C:\Users\Administrator> Enable-OutlookAnywhere -Server:Romac-EX1 -ExternalHostname: mail.romacsign.com -ClientAuthenticationMethod: Basic,Ntlm -SSLOffloading:$true
Enables the server Romac-EX1 for Outlook Anywhere. The external host name is set to mail.romacsign.com and both Basic and NTLM authentication are used. TIP With both authentication modes set, users on computers joined to the domain will not be prompted for authentication, and users on computers not joined to the domain will be prompted for authentication when connecting with Outlook Anywhere.
-SSLOffloading is set to $true. By setting this option to $true, you are indicating to Exchange that you have an SSL accelerator that can handle the encryption/decryption process. If you don’t, set this option to $false; otherwise, Outlook Anywhere won’t function correctly. NOTE
Enabling and Configuring OWA Access By default, users can use Outlook Web App or OWA. You can restrict access to Exchange using OWA by again using the Set-CASMailbox cmdlet. The following table shows you how to enable/disable OWA access. PS C:\Users\ Administrator>Get-Mailbox | Set-CASMailbox -OWAEnabled $false
Figure 12-1
Disables all recipients in the organization from accessing Exchange using Outlook Web App. Figure 12-1 shows the effect on one user.
After disabling OWA for everyone, use this example if it is necessary for one specific Organizational Unit (OU) to use OWA. Figure 12-2 shows the effect on the same user when the user is moved into the affected OU and the cmdlet is rerun.
182
Configuring POP3 and IMAP4
Figure 12-2
The recipient moved into the affected OU can access Exchange via OWA
Configuring POP3 and IMAP4 Support for the POP3 and IMAP4 protocols may still be required in your organization. Many setting are available for both of these services. The intent of this portion of the chapter is not to explore each setting, but to provide the cmdlets so that you can configure these services using Exchange Management Shell (EMS). TIP Often, you can incorrectly enter a cmdlet that’s close to the actual one, if you do not know it, and the built-in EMS Help feature will provide the correct cmdlet.
This table shows you how to view service status using the Get-Service cmdlet as well as how to start and stop services using EMS. PS C:\Users\ Administrator>Get-Service msexchangepop3
Retrieves the status of the POP3 and IMAP4 services on the server on which they are run.
Shows how you can also start and stop these services from EMS. Substitute imap4 in place of pop3 if appropriate. NOTE
Configuring the Autodiscover Service
183
The following table shows three examples of the many options used to configure POP and IMAP settings. PS C:\Users\Administrator> Set-PopSettings -Server "Romac-EX2" -UnencryptedOrTLSBindings 10.10.0.10:993
Sets the plain text or TLS connection to the Client Access Server Romac-EX1.
After changing the log file location, you may also want to change the max log file size that will be reached before a new log file is created. This example changes that setting to create a new log file when the current file reaches 2MB.
In this example, the connection uses an IP address of 10.10.0.10 and a port number of 993.
It also changes the path to the IMAP4 protocol logging directory to D:\ Imap4Logfiles.
Configuring the Autodiscover Service The Autodiscover service was introduced with Exchange Server 2007. It is a remarkably simple concept that probably took too long to come into existence. The Active Directory “knows” who you are when you authenticate. With Autodiscover, Outlook receives configuration data at logon and on a continuous basis as long as it is running. When the client authenticates, it queries for the existence of a Service Connection Point (SCP). The SCP has the location of the Autodiscover URL. Normally, this would be something like Romac-EX1.romacsign.com/Autodiscover/Autodiscover.xml. You might want to move the Autodiscover virtual directory to a public web server to make it accessible from the Internet. To do this, you must change the service location and remove the current virtual directory on your CAS. In the following table, RomacEX2 represents the company’s public web server. PS C:\Users\Administrator> Set-ClientAccessServer -Identity Romac-EX2 -AutodiscoverServiceInternalURI "http://romac-ex2.romacsign.com"
Specifies the internal URL for the Autodiscover service.
PS C:\Users\Administrator> Remove-AutodiscoverVirtualDirectory -Identity "Romac-EX1\Autodiscover (Default Web Site)" -Confirm:$false
Uses the RemoveAutodiscoverVirtualDirectory cmdlet to remove the Autodiscover virtual directory associated with the Autodiscover service on a Client Access Server.
184
Configuring the Offline Address Book (OAB)
As shown in the following table, after removing the original virtual directory on the CAS, you must create a new one on a public web server if external users must access the Exchange organization and be configured automatically. PS C:\Users\Administrator> New-AutodiscoverVirtualDirectory -WebSiteName "autodiscover.romacsign.com" -WindowsAuthentication $true -DigestAuthentication $true
Illustrates that when you have more than one email domain in your organization and each requires its own Autodiscover site and its own virtual directory, you can use the NewAutodiscoverVirtualDirectory cmdlet to create a new Autodiscover virtual directory under a new website. You should always enable Secure Sockets Layer (SSL) for the Autodiscover service. NOTE
PS C:\Users\Administrator> Retrieves the settings for the Get-AutodiscoverVirtualDirectory Autodiscover virtual directory on a CAS. -DomainController Romac-DC1 -Server Romac-EX2
Configuring the Offline Address Book (OAB) The Offline Address Book (OAB) is initially a copy of the default Global Address List (GAL) that a client can download and use when the network is not present. In Exchange Server 2003, the OAB was stored in a System Public folder. In Exchange Server 2010, it is stored as a virtual directory on a Client Access Server. When you install the CAS role, the virtual directory named OAB is created in the Default website, but it is not available from outside of your Exchange organization until an External URL is set. Also, the OAB virtual directory does not require SSL by default. The following table shows that both of these settings can be configured with the Set-OabVirtualDirectory cmdlet. PS C:\Users\Administrator> Set-OABVirtualDirectory -Identity "Romac-EX1\OAB (Default Web Site)" -ExternalUrl "https://www.romacsign.com/ OAB"
Configures the OAB virtual directory to be available from outside the Exchange organization.
PS C:\Users\Administrator> Set-OABVirtualDirectory -Identity "Romac-EX1\OAB (Default Web Site)" -RequireSSL $true
Configures the OAB virtual directory to require SSL security.
The following table shows other cmdlets that are useful when working with the OAB.
Configures the OAB properties. You may wish to change the name of your Offline Address Book. In this example, the name of the OAB is changed to the specified name.
PS C:\Users\Administrator> Get-OfflineAddressBook
Retrieves the list of OABs in your organization, but in this case you can view that the name change did take effect.
The second example changes the OAB distribution point to Romac-EX2. Normally, you would use the first example, but because you changed the name of the default OAB in the previous example, you would have to use the new OAB name in your cmdlet, as shown. NOTE
Figure 12-3 shows the properties of the Romac Sign Offline Address Book before the configuration of Romac-EX2 as a web distribution point and after the configuration in a side-by-side format.
186
Configuring the Offline Address Book (OAB)
Figure 12-3 Configuring a CAS as a web distribution point for an OAB (showing the before and after)
The OAB is generated only once per day, by default. A service running on the CAS is responsible for copying the changes from the generation server (usually the Mailbox role) to the OAB distribution point (usually the CAS). This schedule can be modified. The following table edits the generation schedule of the OAB. PS C:\Users\Administrator> Set-OfflineAddressBook -Identity "Romac Sign Offline Address Book" -Schedule "Sun.5:00 AM-Sun.6:00 AM, Mon.5:00 AM-Mon.6:00 AM, Mon.8:00 PM-Mon.9:00 PM, Tue.5:00 AM-Tue.6:00 AM, Tue.8:00 PM-Tue.9:00 PM, Wed.5:00 AM-Wed.6:00 AM, Wed.8:00 PM-Wed.9:00 PM, Thu.5:00 AM-Thu.6:00 AM, Thu.8:00 PM-Thu.9:00 PM, Fri.5:00 AM-Fri.6:00 AM, Fri.8:00 PM-Fri.9:00 PM, Sat.5:00 AM-Sat.6:00 AM"
Illustrates how you would change the generation schedule of the OAB to occur at 5:00 a.m. and 8:00 p.m. each weekday, instead of once per day, as is the default schedule, and once per day on Saturday and Sunday.
CHAPTER 13
Working with Certificates
This chapter provides information and commands concerning the following topics: ■
Types of certificates
■
Generating a certificate request
■
Importing the certificate
■
Enabling the certificate
This chapter focuses on the configuration of the Client Access Server from the perspective of certificates. You will work with the various aspects of certifying servers in your Exchange organization.
Types of Certificates Certificates in the Exchange organization have traditionally been difficult to create and manage for messaging administrators. To understand how to work with certificates, it is important to first understand the different types of certificates that could be used to certify the servers in your organization. ■
Single certificate—You can request one certificate for all types of client connections and protocols. Each CAS will need only a single name and a single certificate.
■
Multiple certificates—You can request a separate certificate for each type of client connection and protocol. Each CAS will likely need multiple certificates and multiple websites.
■
Multiple Subject Alternative Name (SAN) certificate—You can request one certificate with multiple names for each protocol. Each client connection and protocol can use a unique name, but only one certificate is required.
■
Wildcard certificate—You can request a certificate with your domain name and certify all servers in your namespace with it (*.romacsign.com). That certificate could then be used to secure any client connection or protocol.
Generating a Certificate Request After a Client Access Server has been installed, the role has a self-signed certificate installed on it. OWA (Outlook Web App in Exchange 2010) and Exchange ActiveSync (EAS) can use the self-signed certificate if the certificate is trusted by the client. The trust can be
188
Generating a Certificate Request
accomplished by installing the certificate into the computer or mobile device’s certificate store or by using a GPO to deliver it to domain-based computers. Outlook Anywhere does not work with Exchange Server 2010/2007’s self-signed certificate. It requires a valid certificate issued by a Certification Authority (CA)—either an enterprise root CA or a trusted third-party CA. Of course, OWA users can also click through the warning that alerts them about certificate-related errors and proceed through to access OWA. In general, it is recommended to remove the self-signed certificate and replace it with either a certificate generated by your own “in-house” CA or one from a third-party CA. The following table shows how to replace the self-signed certificate. PS C:\Users\ Administrator> New-ExchangeCertificate
Figure 13-1
This example runs the New-ExchangeCertificate cmdlet without any parameters. A self-signed certificate will be generated and the old certificate will be replaced with a new one, as shown in Figure 13-1. NOTE
New self-signed certificate is generated
The following table shows how to renew the self-signed certificate when it expires. PS C:\Users\Administrator> This example shows how to renew the self-signed Get-ExchangeCertificate certificate. -Thumbprint 6F109C9B82E6C4224ECEDA708C68318CD7BC4018 | NOTE Even though this “renews” the selfNew-ExchangeCertificate signed certificate, a new certificate is actually generated, as seen in Figure 13-2. In the previous example, you may notice the use of the “thumbprint” parameter as part of the Get-ExchangeCertificate cmdlet. The thumbprint is a unique identifier for the certificate. No two certificates may share the same thumbprint. NOTE
Generating a Certificate Request
Figure 13-2
189
Self-signed certificate is renewed
The following table shows how to request a certificate from a Certification Authority (CA). PS C:\Users\Administrator> New-ExchangeCertificate -GenerateRequest -SubjectName "c=US, o=Romac Sign Company, cn=Romac-EX2.romacsign.com" -DomainName romacsign.com, romacneon.com -PrivateKeyExportable $true
Outputs the certificate request in Base64 format. You could then send the certificate request to a CA within the organization, to a trusted CA outside of the organization, or to a commercial CA. You would cut and paste the certificate request output into a certificate request web page of the CA or send it via email. This request has multiple subject alternate names (Romacsign.com and Romacneon.com) and has an exportable private key.
After creating the variable in the previous example, you can use the Set-Content cmdlet to write data from the variable to the certificate request file RomacCertRequest.req in the specified folder.
190
Generating a Certificate Request
Although you can use the New-ExchangeCertificate cmdlet to request a certificate, a new wizard is built in to Exchange Management Console (EMC) (new to Exchange 2010) that allows you to create a certificate request. How to access the wizard and its first two pages are shown in Figures 13-3 through 13-5.
TIP
Figure 13-3
Accessing the New Exchange Certificate Wizard
Figure 13-4
The New Exchange Certificate Wizard welcome page
Importing the Certificate
Figure 13-5
191
Configuring names in the New Exchange Certificate Wizard
Importing the Certificate After the certificate request has been generated, the certificate is created by the CA if you are not using a self-signed certificate. You may have pasted the request directly into the CA’s website for that purpose. The CA returns a digital certificate. The certificate contains the key pair for the Client Access Server. You must then import the certificate into the Client Access Server’s certificate store. This task must be performed from the same server that made the request because the information is machine specific. NOTE
As shown in the following table, the Import-ExchangeCertificate cmdlet imports a certificate that has been issued either from an outstanding request or from a PKCS #12 file. PS C:\Users\Administrator> Import-ExchangeCertificate -FileData ([Byte[]]$(Get-Content -Path "C:\certificates\Issued_Cert.p7b" -Encoding Byte -ReadCount 0))
Imports a chain of certificates from the PKCS #7 file Issued_Cert.p7b.
Illustrates the removal of a certificate with the specified thumbprint if it has been imported incorrectly or if the wrong certificate has been imported.
Figure 13-3 also shows that an Import Exchange Certificate Wizard is built in to the Exchange Management Console, which is new to Exchange 2010. This wizard allows you to import the certificate after you have received it from the CA without needing to run the Import-ExchangeCertificate cmdlet.
TIP
Enabling the Certificate The cmdlet in the following table enables a certificate for Exchange services such as OWA, POP, and IMAP. PS C:\Users\Administrator> Enables a certificate for POP, IMAP, SMTP, and IIS services. Enable-ExchangeCertificate -Thumbprint NOTE OWA is included as part of IIS. 6F109C9B82E6C4224ECEDA708C683 18CD7BC4018 -Services POP,IMAP,SMTP,IIS
The cmdlet in the following table shows how to import a chain of certificates from a file. PS C:\Users\Administrator> Import-ExchangeCertificate -FileData ([Byte[]]$(Get-Content -Path "c:\certificates\ IssuedCert.p7b" -Encoding byte -ReadCount 0))
Imports a chain of certificates from the PKCS #7 file IssuedCert.p7b.
CHAPTER 14
Mailbox Servers and Databases
This chapter provides information and commands concerning the following topics: ■
Configuring the properties of a mailbox server
■
Creating and mounting a new database
■
Managing an existing database
■
Removing an existing database
This chapter focuses on the configuration of the Mailbox Server role. You will investigate how to change properties of a server first and then move on to the creation and configuration of a mailbox database.
Configuring the Properties of a Mailbox Server Often, you will not need to configure mailbox server properties, or if you are changing an attribute for an individual server, it will be easier to perform this task using Exchange Management Console (EMC). However, there may be situations where it would be to your advantage to work with server properties from the command line using Exchange Management Shell (EMS). The following table shows some of the ways to retrieve and edit parameters for the Mailbox Server role. PS C:\Users\Administrator> Get-MailboxServer -Identity Romac-EX1 | fl
Retrieves the list of attributes for a mailbox server. In a subsequent example, you will set the -SubmissionServerOverrideList attribute to configure the mailbox server to use a specific Hub Transport server in the same AD site.
In certain situations, you may need to configure a mailbox server to use one or more specific Hub Transport servers in an Active Directory site. By setting a static list of Hub Transport servers to be notified when messages are ready for retrieval, you can control mailflow throw the specified Hub Transport servers in a site. Normally, the use of Hub Transport servers in a site is on a round-robin basis. Once this attribute is set, a mailbox server may only use those servers in the list, and mailflow may fail even when other Hub Transport servers are available in the site. NOTE
TIP The list can contain more than one HT server. Simply separate the servers in the list with commas.
Retrieves the updated list of attributes for a mailbox server.
Creating and Mounting a New Database Creating a new mailbox database is quite easy from either EMC or EMS. One difference is that if you create the database in EMC, it will be mounted automatically. If you create it using Exchange Management Shell, you will have to execute the Mount-Database cmdlet to mount the database. The following table shows how to create and mount a mailbox database. New-MailboxDatabase -Name MailboxDatabaseName -EdbFilePath MailboxDatabasePath
TIP Notice the default location of the transaction logs is not in the specified location (as shown in Figure 14-1) because the -LogFolderPath parameter was not specified.
Creating and Mounting a New Database
Figure 14-1
195
Locations of files when the LogFolderPath parameter is not specified
The following table shows how to create a mailbox database and place its log files in a separate location from the database file. The database will also be mounted. PS C:\Users\Administrator> New-MailboxDatabase -Name "ManufacturingDB" -Server Romac-EX1 -EdbFilePath "C:\Databases\ManufacturingDB\ ManufacturingDB.edb" -LogFolderPath "C:\LogFiles\ ManufacturingDB"
Creates the database in the specified location and also places the transaction logs in a unique location, as shown in Figure 14-2.
Mounts the specified database. The Microsoft Exchange Information Store service must be running to mount a database. NOTE
196
Managing an Existing Database
Figure 14-2
Locations of files when the LogFolderPath parameter is specified
Managing an Existing Database Other tasks that may be performed on a database are shown in the following table. PS C:\Users\Administrator> Dismount-Database "ManufacturingDB" -Confirm:$false
Dismounts a mailbox database. The Microsoft Exchange Information Store service must be running to dismount a database. NOTE
Including the -Confirm:$false option means that you will not be prompted to confirm the dismount operation. PS C:\Users\Administrator> Set-MailboxDatabase -Identity "AssemblyDB" -MaintenanceSchedule "Sun.1:00 AM-Sun.4:00 AM","Wed.1:00 AM-Wed.4:00 AM"
Sets the database maintenance schedule for the specified mailbox database on the specified server to run between 1:00 a.m. and 4:00 a.m. on Sunday morning and Wednesday morning, as seen in Figure 14-3.
Managing an Existing Database
197
Figure 14-3 The adjusted database maintenance schedule as seen in Exchange Management Console
The first example mounts the specified database without the 24×7 background check-summing mode and performs the ESE checksum maintenance only during the online maintenance period that you specify, as shown in Figure 14-4. The second example mounts the specified database with the 24×7 checksum mode enabled. With either of these examples, you will receive a warning in EMS that the change will not take place until the database is dismounted and then remounted. NOTE
198
Managing an Existing Database
Figure 14-4 The adjusted database maintenance option as seen in Exchange Management Console
Background database maintenance can now be continuously run in Exchange Server 2010. You can use either EMC or EMS to set the maintenance schedule for a database to occur at a specific time or allow 24×7 database maintenance. The online defragmentation no longer runs only during the maintenance window (as it did in Exchange Server 2007) unless you schedule it to do so. If you leave 24×7 ESE database maintenance enabled, it will be performed continuously as the data is read from and written to the database. It is strongly suggested that you do not disable this new feature. NOTE
Modifying the database size limit is shown in the following table. Get-MailboxDatabase -Identity "database name" | Format-Table Name, GUID PS C:\Users\Administrator> Get-MailboxDatabase -Identity "ShippingDB" | Format-Table Name, GUID
Retrieves the database GUID.
Managing an Existing Database
This step is performed from Registry Editor or regedit. 1 Open regedit and locate the follow-
ing registry subkey: HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\ MSExchangeIS\<Server Name>\ Private- HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\ MSExchangeIS\Romac-EX2\ Private-825fb102-92e8-463ebe4d-d9b18db4a9e9 2 Find the Database Size Limit in GB
DWORD and change its value to 2048 or the desired size in gigabytes. 3 If the Database Size Limit in GB
DWORD does not exist for the subkey, create a new DWORD with that name and then set its value to 2048 or the desired size in gigabytes.
199
You can use Registry Editor or regedit to modify a database size limit in Microsoft Exchange Server 2010. The database size is checked against its limit periodically, and if the size limit is reached, the database is dismounted. This example changes the maximum size limit for Exchange 2010 Standard Edition to 2048 gigabytes (GB). TIP The default database size limit for Exchange 2010 Standard Edition is 1,024 gigabytes (GB). There is no default database size limit for the Exchange 2010 Enterprise Edition.
There are no hard limits in Exchange Server 2010. This soft limit exists to protect the database from growing too large without an administrator noticing. Sometimes, it is necessary to go beyond the soft limit. This registry change fulfills that need.
NOTE
Registry Editing Warning: If you use Registry Editor incorrectly, you can cause serious problems that may require you to reinstall your operating system or Exchange Server. Use Registry Editor at your own risk and make sure you can back up the registry before making any changes.
Modifying other database parameters is shown in the following table. Move-DatabasePath -Identity "DatabaseName" -EdbFilePath "DatabasePath"-Confirm:$false PS C:\Users\Administrator>Move-DatabasePath -Identity "ShippingDB" -EdbFilePath "C:\Databases\Shipping\ Shipping.edb" -Confirm:$false
Sets a new path for the specified mailbox database. You could also identify and move the database by using its GUID. NOTE
Sets the length of time that deleted items are retained to the specified value. The default value is 14 days. NOTE
Prior to Exchange Server 2010 SP1, you repaired a database using the ISInteg command. The functionality formerly incorporated into ISInteg is now made available using two Exchange Management Shell cmdlets: ■
New-MailboxRepairRequest
■
New-PublicFolderDatabaseRepairRequest
Using these new PowerShell cmdlets, you no longer need to dismount the database when repairing it. You can repair logical corruption at the mailbox level, fix corrupt search folders, fix the provisioned folder, and fix aggregate counts. The cmdlets shown in the following table focus on the New-MailboxRepairRequest cmdlet. This cmdlet can detect and repair mailbox corruptions and can be run against a specific mailbox or against an entire mailbox database. (The NewPublicFolderDatabaseRepairRequest cmdlet will be examined in Chapter 25, “Public Folder Database Management.”) TIP This task cannot be performed from Exchange Management Console and requires Exchange Server 2010 Service Pack 1.
Detects and repairs the folder view for the specified mailbox. This type of repair might be performed when the views on folders are not returning the correct content. NOTE
In addition to CorruptionType=FolderView, repairs will also be made to Search folder corruptions with CorruptionType=SearchFolder, aggregate counts on folders that aren’t reflecting correct values with CorruptionType= AggregateCounts, as well as provisioned folders that are incorrectly pointing into parent folders that aren’t provisioned with CorruptionType= ProvisionedFolder.
The -Database parameter is incompatible with the -Mailbox parameter.
TIP
Detects and reports only on ProvisionedFolder and SearchFolder corruption issues for Joyce’s mailbox. No repairs are performed on this mailbox because of the DetectOnly instruction. NOTE
After you start the repair request, it cannot be stopped unless you dismount the database. While the mailbox is being repaired, the user will not have access to it. If the cmdlet is being run against a database, only the mailbox actually in the process of being repaired is unavailable. NOTE
Removing an Existing Database When a mailbox database is no longer required, you can use the Remove-Database cmdlet to delete the database (as shown in the following table).
This example removes the specified mailbox database. The RemoveMailboxDatabase cmdlet removes only the database object from Active Directory. It will not delete the physical database files from the file system. You must remove the database and log files manually after you run this cmdlet. NOTE
If the mailbox database has a database copy, the Remove-MailboxDatabase cmdlet also removes the copy. NOTE
CHAPTER 15
Working with Mailboxes
This chapter provides information and commands concerning the following topics: ■
Exporting a mailbox
■
Importing a mailbox
■
Moving an online mailbox
■
Running the Clean-MailboxDatabase cmdlet
This chapter focuses on the configuration of mailboxes. You will examine the process used to export and import data to and from the mailbox. Then you will observe the new procedure in Exchange Server 2010 for moving mailboxes. Finally, you will investigate how to use the Clean-MailboxDatabase cmdlet when disconnected mailboxes do not appear properly in Exchange Management Console (EMC).
Exporting a Mailbox By default, the Mailbox Import Export management role is not part of any of the built-in role groups. Even the Organization Management role group does not have permission to run the Export-Mailbox and Import-Mailbox cmdlets by default. In order to export or import mailbox data, you need to add the Mailbox Import Export management role to a role group. It is not possible to add roles to the built-in role groups. Therefore, to assign the Mailbox Import Export management role, you need to create a new role group (as shown in the following table). PS C:\Users\ Administrator> New-RoleGroup -Name MailboxManagement -Roles "Mailbox Import Export"
Creates a new management role group with the specified name and assigns the Mailbox Import Export management role to the role group.
Adds a mailbox as a member of the specified role group. You cannot use someone in the Domain Administrators group. You are explicitly restricted as a domain admin from importing or exporting mailboxes for security reasons. NOTE
In this example, a user named Paul MailboxMgr has been created. This user has been added to the Organization Management built-in role, as well as to the MailboxManagement custom role.
Now that the role group has been created, ensure that the user who will export the data (MailboxAdmin in the following examples) is a member of the MailboxManagement role group and that the role group has the correct role assignment. One way you could do this is to use the Get-RoleGroup cmdlet, as shown in the following table. PS C:\Users\ Administrator> Get-RoleGroup "RomacSign.com\ MailboxManagement" | fl name, role
TIP
Confirms the creation of the management role group and the assignment of the Mailbox Import Export role from the previous examples.
This can also be done quite easily in Exchange Control Panel, as shown in Figure 15-1.
Figure 15-1
Membership of the role group and role assignment
Exporting a Mailbox
205
To perform the following tasks, you must create the MailboxExports mailbox and a folder named ExportedData in the MailboxExports mailbox, as shown in the following table. PS C:\Users\MailboxAdmin> Export-Mailbox -Identity [email protected] -TargetMailbox MailboxExports -TargetFolder ExportedData
Exports the contents of the specified mailbox (Maureen) to the specified folder (ExportedData) in the mailbox named MailboxExports.
To perform the next task, you must send an email to the user Joyce with the words “Amazing Toy World” in the body of the message. When you perform the task, a filter will capture all messages with the content keywords in them and export the messages to the specified location (as shown in the following table). PS C:\Users\MailboxAdmin>Export-Mailbox -Identity [email protected] -TargetMailbox MailboxExports -TargetFolder ExportedData -ContentKeywords "Amazing Toy World"
Figure 15-2
Uses a filter to specify which items in the mailbox should be included in the export, as shown in Figure 15-2.
Mailbox content found and exported successfully
You could also export messages based on subject keywords.
Exports all messages from the specified mailbox’s Inbox folder to a .pst file.
It will find the message, export it to the specified mailbox, and then delete it from the source mailbox. NOTE
Because both the sender and recipient mailboxes are in the same database, this will locate the sent item in the sender’s mailbox and delete that as well.
When you run this cmdlet from a remote machine such as your workstation, the -PSTFolderPath still references a location on your server, not the workstation. NOTE
TIP To export to a .pst file, the 64-bit version of Outlook 2010 or later must be installed on the server (yes, on the server) to which you are connecting; otherwise, you will get an error message stating as much, as shown in Figure 15-3.
Figure 15-3 Error message regarding installation of Outlook 2010 on the server when importing or exporting to a .pst file
This same task may be performed in Exchange Server 2010, Service Pack 1. However, you do not use the Export-Mailbox cmdlet. Instead, you will use the NewMailboxExportRequest cmdlet (as shown in the following table). The New-MailboxExportRequest cmdlet replaces the Export-Mailbox cmdlet in Service Pack 1.
Creates a mailbox export request, which begins the process of exporting the specified mailbox data to a .pst file. You cannot use the Exchange Management Console (EMC) to create a mailbox export request. NOTE
TIP When you export a mailbox to a network location, create the network shared folder and grant read and write permissions to the Exchange Trusted Subsystem group. If you don’t grant these permissions, an error will be received stating that Exchange is unable to establish a connection to the target mailbox.
Importing a Mailbox Just as you had to create a new role group and assign the Mailbox Import Export management role to export mailboxes, you have to do the same to import mailboxes. However, if you did this when you exported the mailboxes, it is not necessary to perform this again (as shown in the following table). Perform the previous examples under the section “Exporting a Mailbox” if you need to create the new role group and add role group members to import a mailbox and have not already done so previously. NOTE
Imports the data from the specified .pst file to the existing, connected mailbox of the user.
PS C:\Users\MailboxAdmin> Dir "C:\ ExportedMailboxes" | Import-Mailbox -StartDate 01/21/2009
Imports the data from all the .pst files that are located in the specified directory into existing mailboxes.
When you run this cmdlet from a remote machine such as your workstation, the -PSTFolderPath still references a location on your server, not the workstation. NOTE
TIP To import from a .pst file, the 64-bit version of Outlook 2010 or later must be installed on the server to which you are connecting; otherwise, you will get an error message stating as much.
Only messages that were received after 01/21/2009 will be imported into the mailbox. NOTE
Imports a .pst file into Maureen’s personal archive folder.
The .pst files must be named using the format Alias.pst, such as Maureen.pst. Only .pst files whose alias corresponds to a user in the specified Organizational Unit (OU) will be imported. NOTE
The content is merged under existing folders, and new folders are created if they don’t already exist.
Moving an Online Mailbox As shown in the following table, you can use the New-MoveRequest cmdlet to begin the process of an asynchronous mailbox move to a different database in the same Active Directory forest. This also can be used to move the personal archive mailbox to a different database in the same Active Directory forest beginning with Exchange Server 2010, Service Pack 1. (Prior to Service Pack 1, the primary mailbox and the archive mailbox had to be in the same database.) NOTE
Verifies that the mailbox is ready to be moved to another database within the same forest. By using the -WhatIf switch, if the mailbox is not ready to be moved, you will receive an error message when you try to move the mailbox; however, no data will be affected. NOTE
In Exchange Server 2010, Service Pack 1, this example moves only the specified recipient’s primary mailbox from one database to another. The archive mailbox is not moved.
In Exchange Server 2010, Service Pack 1, this example moves only the specified recipient’s archive mailbox from one database to another. The primary mailbox is not moved.
Moves the specified recipient’s primary mailbox to another mailbox database and sets the bad item limit to 50. Because this is not a normal scenario, you must set the -AcceptLargeDataLoss parameter.
You may remove, suspend, or resume a move request by using the appropriate cmdlet (as shown in the following table). PS C:\Users\Administrator> Remove-MoveRequest -Identity "[email protected]"
Removes the mailbox move request for the specified mailbox. This cancels the mailbox move for a mailbox queued up for moving by the New-MoveRequest cmdlet.
Suspends the move request for the specified mailbox. You may use the SuspendMoveRequest cmdlet to suspend a move request any time after the move request was created, but before it reaches the status of Completing. NOTE
Suspends all move requests that are in progress by using the GetMoveRequest cmdlet to retrieve all move requests with a MoveStatus value of InProgress and then pipelining the output to the Suspend-MoveRequest cmdlet.
You would use this cmdlet to resume a move request that has been suspended or has failed. NOTE
Running the Clean-MailboxDatabase Cmdlet When disconnected mailboxes do not appear properly, you can use the CleanMailboxDatabase cmdlet to update the information between Exchange Server and the Active Directory. Disconnected mailboxes typically occur when the Active Directory user account is deleted, thus orphaning the mailbox. The mailbox is preserved for 30 days by default and is moved to the Disconnected Mailboxes node of Exchange Management Console. The following table shows how to run the Clean-Mailbox cmdlet, which scans the Active Directory for mailboxes that are disconnected from user accounts but do not yet appear as disconnected in EMC or EMS. It is normally not necessary to run this cmdlet unless the mailbox does not appear in Disconnected Mailboxes. NOTE
Scans the Active Directory for disconnected mailboxes that aren’t yet marked as disconnected. It then updates the status of those mailboxes. Running this cmdlet requires that the Microsoft Exchange Information Store service is started and that the database is mounted.
This page intentionally left blank
CHAPTER 16
Using the Recovery Database (RDB)
This chapter provides information and commands concerning the following topics: ■
Creating the recovery database (RDB)
■
Restoring a database to the RDB
■
Removing the RDB
This chapter focuses on the creation and deletion of the recovery database as well as the restoration of a database using the RDB. Because there are no storage groups in Exchange Server 2010, the Recovery Storage Group (RSG) has been deprecated. The functionality of the RSG has been moved to a new feature in Exchange 2010 called the Recovery Database.
Creating the Recovery Database (RDB) A recovery database (RDB) is an unusual mailbox database. It allows you to have a second copy of a database mounted for the purpose of extracting data from one or more mailboxes in the restored database and merging that data back into production mailboxes as part of a recovery operation. This can be done without affecting a user’s access to his or her mailbox. There are two possibilities, as shown in the following table. If a recovery database already exists:
The RDB database can be dismounted, the data can be restored onto the recovery database, and then the database can be remounted.
If a recovery database does not already exist:
The database can be restored to any disk location. Exchange can analyze the restored data, replay the transaction logs, and then the RDB can be configured to point to the database files.
An RDB is different from other mailbox databases in numerous ways: ■
The RDB does not count as a database. You may still have five databases on Standard Edition servers and 100 databases on Enterprise Edition servers.
■
An RDB is for mailbox databases only. You cannot use this recovery technique for public folder databases.
■
A recovered database mounted as an RDB is not linked to the original database, even though the database filenames may be the same. It is a separate database and can only be created by using EMS.
■
MAPI access from Outlook or Outlook Web App (OWA) is not allowed, and mail cannot be sent to or from an RDB mailbox.
214
Creating the Recovery Database (RDB)
■
It is not possible to connect mailboxes in an RDB to user accounts. You can merge the data from the mailbox into the user’s production mailbox or you can export data from the RDB mailbox to a folder or .pst file.
■
Policies are not applied to RDB mailboxes. You cannot make an RDB database a member of a Database Availability Group (DAG) and you cannot back up an RDB database. DAGs are discussed in greater detail in Chapter 21, “Database Availability Groups (DAGs).”
■
Online maintenance is not performed for the RDB, and circular logging is disabled and cannot be enabled for the RDB.
■
Only one RDB can be mounted per mailbox server per restore operation. It must be destroyed before the next restore if you want to create another RDB on the same server.
■
Mailbox databases from previous versions of Exchange aren’t supported, and both source and target mailboxes must be in the same forest in Active Directory.
You would use the RDB in three possible recovery operations, as shown in the following table. Dial tone restores
You can repair or restore a database while a dial tone database is in use, with the goal of merging the two databases together at the end of the repair or restore operation.
Recovering a database on another server
You can recover the database to an alternate server and then merge the recovered data back to the original server, if so desired.
Recovering deleted or corrupted items
You can recover an individual mailbox (or item in a mailbox) from backup when the deleted mailbox retention period has expired. You would extract data from the restored mailbox and copy it to a target folder or merge it with another mailbox.
The first step is to create the RDB, as shown in the following table. PS C:\Users\Administrator>New-MailboxDatabase -Recovery -Name RomacRDB1 -Server Romac-EX1
Creates the recovery database on the specified mailbox server using the default paths for the database file and the transaction log folder. The -Recovery switch is what designates the database as an RDB. You cannot use the EMC to create a recovery database. NOTE
Creates the recovery database on the specified mailbox server using a custom path for the database file and transaction log folder, as shown in Figure 16-1.
Figure 16-1 Creation of an RDB with a custom path for the database and transaction log folder on a server
It is not possible to view the RDB in Exchange Management Console (EMC). However, you can view it from Exchange Management Shell (EMS), as shown in the following table. PS C:\Users\ MailboxAdmin> Get-MailboxDatabase | fl name, recovery
Figure 16-2
Retrieves a list of all mailbox databases as well as their recovery status. RomacRDB1 is the recovery database on Romac-EX1, and RomacRDB2 is the recovery database on Romac-EX2, as shown in Figure 16-2. (The two RDBs exist on separate servers because you may only have one RDB per server per restore operation.) NOTE
Recovery Databases in the enterprise displayed in EMS
216
Restoring a Database to the RDB
Restoring a Database to the RDB In the previous examples, you created an RDB. Now, the database and log files containing the recovered data must be restored or copied into the RDB folder structure that was created when the RDB was created. If you are performing these tasks, copy the AssemblyDB database and transaction log files to “C:\Databases\RDB_AssemblyDB” on Romac-EX2 and ensure the database name remains AssemblyDB.edb. If you moved the AssemblyDB database file in an earlier chapter, it will be located at C:\Databases\ManufacturingDB and the log files will be located at C:\ LogFiles\ManufacturingDB on Romac-EX1. The database must be dismounted to move the files. NOTE
You must also determine the log file prefix number, as shown in the following table. Determines the log file prefix number as shown in Figure 16-3.
Performs a soft recovery that puts the database into a clean shutdown state. Because an RDB is an alternate restore location for all databases, all restored databases will be in a dirty shutdown state and a soft recovery must be performed. TIP In the example, the logfileprefix is E02, and the “i” instructs the command to “ignore errors.” Also, the “d” instructs the command to use the current directory as the path for the database files.
Retrieves the list of available mailboxes on the RDB, as shown in Figure 16-4.
List of available mailboxes on the RDB
To simulate corrupted or missing messages, you will delete emails from a mailbox, as shown in the following table. If you have performed some of the tasks from previous chapters, Maureen’s mailbox was moved to the ManufacturingDB, so simply delete one or more messages from her mailbox. NOTE
PS C:\Users\Administrator> Restores a mailbox for the specified recipient from the Restore-Mailbox RDB. -Identity Maureen -RecoveryDatabase "RDB_ManufacturingDB" PS C:\Users\Administrator> Restore-Mailbox -Identity Maureen -RecoveryDatabase "RDB_ManufacturingDB" -RecoveryMailbox "Joyce Celecz" -TargetFolder Recovery
Restores a recipient’s mailbox content into another recipient’s mailbox under the Recovery folder.
Bulk restores all the mailboxes in the mailbox database DB1 that are also present in the recovery database RDB1.
218
Removing the RDB
Removing the RDB When you are finished with the RDB, you should remove it in preparation for your next recovery operation, as shown in the following table. PS C:\Users\Administrator> Dismount-Database RDB_ManufacturingDB -Confirm:$false
Dismounts the specified RDB in preparation for removing the recovery database.
Removes the specified RDB. The -Confirm:$false option ensures that you are not prompted for the deletion.
When you remove the mailbox database, you receive a warning that the specified database has been removed but that you must remove the database file from your computer manually if it still exists. If appropriate, remove the file.
CHAPTER 17
Working with Unified Messaging (UM) Role Objects
This chapter provides information and commands concerning the following topics: ■
Configuring the properties of a UM server
■
Creating and managing dial plans
■
Creating and managing UM IP gateways
■
Creating and managing hunt groups
■
Creating and managing UM mailbox policies
■
Monitoring and troubleshooting a UM server
This chapter focuses on the configuration of the Unified Messaging (UM) role. You will investigate how to create and configure UM objects such as dial plans, UM IP gateways, hunt groups, and UM policies. Before you can work with the UM objects, the UM role must be installed onto your Exchange server. This can be installed separately or added to any existing Exchange server running any role except the Edge Transport role. Before installing the UM role, you must install the Desktop Experience feature on your Windows Server 2008 computer. This provides components that the UM role requires. NOTE
Configuring the Properties of a UM Server Once the UM role is installed, you will want to configure the properties of the server. You can configure several options, including the number of concurrent calls that the UM server can answer. You can also remove the UM server from all dial plans. Many of the configuration settings can be performed from either EMC or EMS, as shown in the following table. PS C:\Users\Administrator> Prevents the specified UM server from Set-UMServer -Identity Romac-EX2 accepting new calls, which effectively disables it. -Status NoNewCalls
Enables the specified UM server when PS C:\Users\Administrator> Set-UMServer -Identity Romac-EX2 you no longer need the -NoNewCalls option set. -Status Enabled Sets the maximum number of incoming PS C:\Users\Administrator> Set-UMServer -Identity Romac-EX2 voice calls to the specified UM server. -MaxCalls 75 NOTE The default value is 100 concurrent calls.
220
Creating and Managing Dial Plans
This example removes the specified UM PS C:\Users\Administrator> Set-UMServer -Identity Romac-EX2 server from all UM dial plans. -DialPlans $null
Creating and Managing Dial Plans Once the UM role is installed, you will want to create a dial plan. A UM dial plan is necessary to allow it to process incoming calls. Dial plans are used to link user mailboxes to their extension numbers. They are also used to configure default settings such as dial codes for accessing external lines and international numbers, default languages for voice prompts, and the audio codec for voice messages, such as MP3. A dial plan may also be used to configure a default greeting that will be played when dial-plan subscribers call in to the server. You must have at least one UM server and at least one dial plan for that server. Dial plans can be managed from either EMC or EMS, as shown in the following table. PS C:\Users\ Administrator> Get-UMServer | fl
Figure 17-1
This example allows you to verify that your server has the UM role installed. You can view that the default status is “Enabled,” that the default language is “en-US,” and that there are no dial plans present by default, as shown in Figure 17-1. NOTE
Verifying the default settings and status on a UM server
The second example creates a new UM dial plan for the Orlando office that uses three-digit extension numbers.
The country/region code is unique for each country.
In addition to the number of digits in the extension, you could also specify the URI Type if you need a SIP URI dial plan to support Session Initiation Protocol (SIP) routing or if you’re integrating Microsoft Office Communications Server (OCS) and Exchange Unified Messaging. NOTE
Some common country/region codes are shown in the following table. Code
Country
1
USA
7
Russia
33
France
34
Spain
44
United Kingdom
45
Denmark
46
Sweden
47
Norway
48
Poland
49
Germany
55
Brazil
61
Australia
81
Japan
86
China
Add a server to a dial plan and configure the dial plan to set the outside-line access code to use 9, as shown in the following table.
Configures the specified dial plan to set the outside-line access code to 9, as also shown in Figure 17-2.
Figure 17-2 Server added to dial plan and outside-line access code configured on specified dial plan, as shown in EMC
To retrieve settings for a dial plan, change other settings for a dial plan, and remove a dial plan, use the appropriate cmdlet (as shown in the following table). PS C:\Users\Administrator> Get-UMDialplan
Retrieves the complete list of dial plans in the organization.
Creating and Managing UM IP Gateways A UM IP gateway is an Active Directory object that represents your physical IP gateway hardware device. This could be either an IP PBX or a VOIP gateway. An IP gateway processes calls from the hardware device. It must be associated with at least one dial plan and can contain one or more hunt groups. The IP gateway can be managed from either EMC or EMS, as shown in the following table. PS C:\Users\Administrator> New-UMIPGateway -Name PhiladelphiaUMIPGateway -Address 10.5.0.50 PS C:\Users\Administrator> New-UMIPGateway -Name OrlandoUMIPGateway -Address "OrlandoUMIPGateway.RomacSign.com"
Figure 17-3
The first example creates a new UM IP gateway that enables a UM server to begin accepting calls from an IP gateway with the specified IP address, as shown in Figure 17-3. The second example creates a new UM IP gateway that enables a UM server to begin accepting calls from an IP gateway with the specified name.
The new UM IP gateway as seen in EMC
To perform other configuration settings on a UM IP gateway, use the appropriate cmdlet (as shown in the following table).
The first example prevents the specified UM IP gateway from accepting incoming calls and prevents outgoing calls. The second example reverses the initial changes.
Deletes the specified UM IP gateway without prompting for a confirmation of the deletion.
Creating and Managing Hunt Groups A UM hunt group is an Active Directory object that logically represents the PBX hunt group to link IP gateways and dial plans together. It is also used to locate the PBX hunt group. This object can also be managed from either EMC or EMS, as shown in the following table. PS C:\Users\Administrator>New-UMHuntGroup -Name PhiladelphiaUMHuntGroup -PilotIdentifier 12119 -UMDialPlan PhiladelphiaUMDialPlan -UMIPGateway PhiladelphiaUMIPGateway PS C:\Users\Administrator>New-UMHuntGroup -Name OrlandoUMHuntGroup -PilotIdentifier 11919 -UMDialPlan OrlandoUMDialPlan -UMIPGateway OrlandoUMIPGateway
These examples create the specified UM hunt groups with the specified pilot identifiers, as shown in Figure 17-4.
Creating and Managing UM Mailbox Policies
Figure 17-4
225
The hunt group as seen in EMC
To perform other configuration settings on a UM hunt group, use the appropriate cmdlet (as shown in the following table). PS C:\Users\Administrator>Get-UMHuntGroup
Displays all the UM hunt groups in the organization.
Removes the specified UM hunt group without prompting for the deletion.
Creating and Managing UM Mailbox Policies UM mailbox policies apply settings to configure UM-enabled users. You can specify settings such as dial plan, number of unsuccessful logon attempts, number of digits required in a PIN, password history, regional/international calling restrictions, and the like with a UM mailbox policy.
226
Monitoring and Troubleshooting a UM Server
The following table shows how to create, edit, view, and delete a UM mailbox policy. PS C:\Users\Administrator> New-UMMailboxPolicy -Name PhiladelphiaUMMailboxPolicy -UMDialPlan PhiladelphiaUMDialPlan
These examples create two new UM mailbox policies that are associated with their respective dial plans.
Removes the specified UM mailbox policy without prompting for the deletion.
Monitoring and Troubleshooting a UM Server You can use several cmdlets to monitor the status of your UM server as well as troubleshoot issues on the server. Some of these cmdlets are shown in the following table. PS C:\Users\Administrator> Get-UMCallSummaryReport -GroupBy Month -UMDialplan
PhiladelphiaUMDialPlan
Returns statistics about all calls received or placed by Unified Messaging (UM) servers in an organization. This includes number of messages, missed calls, subscriber access, auto attendant, and fax calls and also includes audio quality metrics for the specified calls. The results will be collected only for the PhiladelphiaUMDialPlan and will be grouped by Month, rather than by Day or by Total. NOTE
Returns data about the calls that are active and being processed by the Unified Messaging (UM) servers. If the UM server is specified, this cmdlet returns only the active calls being processed by the specified server.
Tests the operation of a server that has the Unified Messaging (UM) server role installed. When you run this cmdlet and include the UMIPGateway parameter, the Unified Messaging server tests end-to-end functionality of the Unified Messaging system. The -Secured parameter specifies whether the test will be run in SIP Secured Mode and the -Phone parameter specifies the telephone number or SIP Uniform Resource Identifier (URI) used when the test call is redirected. NOTE
There is also the Exchange 2010 UM Troubleshooting Tool, which can be used to diagnose configuration errors specific to call-answering scenarios. In addition, it allows you to test whether voicemail is functioning correctly in Exchange 2010 SP1. This cmdlet emulates calls and runs a series of diagnostic tests that help diagnose misconfigurations in telephony equipment, Exchange Server 2010 SP1 Unified Messaging settings, and connectivity issues. You can download this utility from the Microsoft Download Center by searching for “Unified Messaging Troubleshooting Tool.”
This page intentionally left blank
CHAPTER 18
Managing Unified Messaging (UM) Users
This chapter provides information and commands concerning the following topics: ■
Managing the UM Auto Attendant
■
Working with call-answering rules
■
Exporting UM call data records
■
Working with UM-enabled mailboxes
This chapter focuses on the configuration of Unified Messaging (UM) users and UM-enabled mailboxes. You will investigate how to create and configure a UM Auto Attendant, allow or restrict the user’s use of call-answering rules, work with Call Data Records, and configure and enable UM-enabled mailboxes.
Managing the UM Auto Attendant The UM Auto Attendant allows internal and external callers to navigate through the voice menu system for your organization. The attendant enables you to set welcome greetings and custom organizational voice-prompt menus as well as gives you the ability to allow the system to connect the caller with the telephone of the subscriber. It also permits the ability to search your organization’s directory for the subscriber. The following table shows the creation of two UM Auto Attendants. PS C:\Users\Administrator> New-UMAutoAttendant -Name PhiladelphiaUMAutoAttendant -UMDialPlan PhiladelphiaUMDialPlan -PilotIdentifierList 19000 New-UMAutoAttendant -Name OrlandoUMAutoAttendant -UMDialPlan OrlandoUMDialPlan -PilotIdentifierList 90000
These two examples create new UM Auto Attendants that can accept incoming calls but are not speech enabled, as shown in Figure 18-1. The pilot identifiers have been specified at the time of creation of the attendants. NOTE
Creates a new speechenabled UM Auto Attendant using the specified pilot identifier. When the Auto Attendant is speech enabled, callers can respond to the system or custom prompts used by the UM Auto Attendant via touchtone or voice inputs. NOTE
By default, the Auto Attendant is not speech enabled when it’s created unless you specify the -SpeechEnabled parameter as $true. PS C:\Users\Administrator> Set-UMAutoAttendant -Identity OrlandoUMAutoAttendant -OperatorExtension 99999 -AfterHoursTransferToOperatorEnabled $true
Sets the specified UM Auto Attendant’s operator’s extension to 99999 and configures transfers to this extension number after business hours, as shown in Figure 18.2.
Configures a new UM Auto Attendant that has business hours configured as 9:00 a.m. to 5:00 p.m. Monday–Friday and 9:00 a.m. to 2:00 p.m. on Saturday; as well as “Facility Closed for Holiday” configured from December 24, 2010 through January 2, 2011. In this example, the .wav file contains your custom holiday greeting detailing the dates and times that the facility will be closed for the holidays. NOTE
These changes can be seen in Figure 18-3.
231
232
Managing the UM Auto Attendant
Figure 18-3
Other Auto Attendant configurations as seen in EMC
TIP Auto Attendants are created with a status of disabled and must be enabled.
It is possible to create a new Auto Attendant without setting up an extension number for it. An extension number for a UM Auto Attendant might otherwise be known as a pilot identifier or pilot number. It is also possible to associate more than one telephone or extension number with a single Auto Attendant. You can either add the extension
Managing the UM Auto Attendant
233
numbers when you create the UM Auto Attendant or add them after you configure the Auto Attendant. TIP The number of digits in the extension number you configured on the UM Auto Attendant must match the number of digits for an extension number that’s configured on the UM dial plan associated with the UM Auto Attendant.
The following table shows how to add one or more pilot identifiers to an existing UM Auto Attendant. PS C:\Users\Administrator> Set-UMAutoAttendant -Identity PhiladelphiaUMAutoAttendant -PilotIdentifierList "11255", "17325", "28000"
Figure 18-4 EMC
Configures the specified UM Auto Attendant with multiple extension numbers, as shown in Figure 18-4.
The updated pilot identifier list for the specified Auto Attendant as seen in
You can also enable or disable directory lookups on a UM Auto Attendant, as shown in the following table. PS C:\Users\Administrator>Set-UMAutoAttendant -Identity PhiladelphiaUMAutoAttendant -NameLookupEnabled $true
Enables directory lookups on the specified UM Auto Attendant.
Disables directory lookups on the specified UM Auto Attendant.
Working with Call Answering Rules You can allow users associated with a UM dial plan to create and configure call-answering rules, as well as restrict them from doing so. By default, UM-enabled users can create a rule and apply it to an incoming call to their phone number, similar to configuring an Inbox rule for incoming messages to their mailbox. A user can transfer the call, have the caller leave a voice message, or allow the caller to locate him or her at a different phone number with a call-answering rule. You also might want to restrict the user from creating and configuring call-answering rules. This could be done by configuring a UM mailbox policy and associating it with the user’s mailbox, as shown in the following table. PS C:\Users\Administrator> Set-UMDialPlan -Identity PhiladelphiaUMDialPlan -CallAnsweringRulesEnabled $true
Allows users who are associated with the specified UM dial plan to configure call-answering rules.
Prevents the specified user from using call-answering rules. The user must have a UM-enabled mailbox for this cmdlet to succeed. NOTE
Exporting UM Call Data Records The Export-UMCallDataRecord cmdlet exports UM call data records for the date you specify. This can be filtered by dial plan or by UM IP gateway. Each UM call data record provides detailed information about all calls either placed to or received by the specified user.
Working with UM-Enabled Mailboxes
235
This includes the date and time that the call was taken, the duration of the call, the audio codec used, the dial plan, the call type, the calling number as well as the called number. You can use the Export-UMCallDataRecord cmdlet to export the UM call data records and the Get-UMCallDataRecord cmdlet to search for records for a specific mailbox, as shown in the following table. PS C:\Users\Administrator> Export-UMCallDataRecord -Date 04/18/10 -UMDialPlan PhiladelphiaUMDialPlan
Exports all UM call data records for the specified date for the specified UM dial plan.
Retrieves UM call data records for the last 90 days for the specified UM-enabled mailbox.
Working with UM-Enabled Mailboxes You might need to configure properties on a UM-enabled mailbox. Some of the more common options that can be configured are shown in the following table. AirSyncNumbers
Specifies whether to register a mobile phone number with a hosted voicemail service.
AllowUMCallsFromNonUsers
Specifies whether to include or exclude the mailbox from directory searches.
AnonymousCallersCanLeaveMessages Specifies whether diverted calls without a caller ID should be allowed to leave a message. AutomaticSpeechRecognitionEnabled
Specifies whether users can use Automatic Speech Recognition (ASR) when they log on to their mailbox. NOTE This parameter can only be set to $true if there is ASR support for the language selected by the user in Microsoft Office Outlook Web App options.
CallAnsweringAudioCodec
Specifies the audio codec used to encode voicemail messages that are left for the user. The audio codec that’s used is the audio codec set at the UM dial plan level. The default value is .mp3. NOTE
CallAnsweringRulesEnabled
Specifies whether users can configure callanswering rules for their accounts.
FaxEnabled
Specifies whether a user may receive incoming faxes.
NOTE
The default value is set to $true.
236
Working with UM-Enabled Mailboxes
MissedCallNotificationEnabled
Specifies whether to send missed call notifications.
OperatorNumber
Specifies the string of digits for the personal operator.
PlayOnPhoneEnabled
Specifies whether a user can use the Play on Phone feature to listen to voice messages.
SubscriberAccessEnabled
Specifies whether the users are allowed subscriber access to their individual mailboxes.
NOTE
The default value is set to $true.
When this option is set to $true, users are able to retrieve voicemail over the telephone after they have been authenticated. NOTE
The default value is $true.
TUIAccessToCalendarEnabled
Specifies whether the UM-enabled user has the ability to access his or her calendar using the Microsoft Outlook Voice Access telephone user interface (TUI) or touchtone interface.
UMMailboxPolicy
Specifies the UM mailbox policy linked to the UM-enabled user’s mailbox.
UMSMSNotificationOption
Specifies whether a UM-enabled user gets SMS or text messaging notifications.
NOTE
The default value is $true.
The accepted values for this parameter include: ■
VoiceMail
■
VoiceMailAndMissedCalls
■
None
NOTE
The default value is None.
The following table shows how to configure one or more of these parameters on a UM-enabled mailbox. PS C:\Users\Administrator> Set-UMMailbox -Identity [email protected] -CallAnsweringAudioCodec Wma -CallAnsweringRulesEnabled $false -FaxEnabled $false -UMSMSNotificationOption VoiceMail
Configures the specified UM-enabled user so that the call-answering audio codec is set to Wma, call-answering rules are disabled, incoming faxes are blocked, and voicemail notifications are allowed, but missed call notifications are not allowed using text messaging.
Disables UM on the mailbox for the specified user.
The user must have a UM-enabled mailbox for this cmdlet to succeed. NOTE
It also assigns a UM mailbox policy named PhiladelphiaUMMailboxPolicy to the user’s mailbox.
You can use the Set-UMMailboxPIN cmdlet to reset the PIN for a UM-enabled mailbox as well as lock and unlock the UM-enabled mailbox, as shown in the following table. PS C:\Users\Administrator> Set-UMMailboxPIN -Identity [email protected]
Resets the PIN on the specified UM-enabled mailbox.
Resets the initial PIN to 1010101 on the UM-enabled mailbox for the specified user and then sets the PIN as expired, so the user will be prompted to change the PIN the next time he or she logs on.
Displays the UM mailbox PIN-related status for the specified user.
CHAPTER 19
Exchange Server 2010 Message Routing
This chapter provides information and commands concerning the following topics: ■
Using default message routing
■
Using Exchange hub sites
■
Using Exchange-specific costs on site links
■
Tracking messages with PowerShell
Mailflow within an Active Directory site is handled by the Hub Transport server that picks up the message. The Microsoft Exchange Mail Submission service on the Mailbox server notifies all Hub Transports in the local site whenever messages are available for retrieval from a sender’s Outbox. The store driver retrieves the message and because it is destined for a local recipient, the Hub Transport that picked up the message can also deliver it to the Mailbox server that holds the recipient’s mailbox. When a message is destined for another Active Directory site or the Internet, other transport servers become involved, so you must understand how message routing takes place. This chapter first looks at default message routing and then moves on to alternatives you can take to modify default message routing when necessary.
Using Default Message Routing The first thing to understand about remote mailflow to another Active Directory site is that routing groups are no longer used. To support coexistence between Exchange 2010 routing and Exchange 2003, all Exchange 2010 servers are automatically added to a single routing group when they are installed. The Exchange 2010 routing group is recognized in Exchange System Manager in Exchange 2003 as Exchange Routing Group (DWBGZMFD01QNBJR) within Exchange Administrative Group (FYDIBOHF23SPDLT), but it is not recognized in Exchange Management Console (EMC) or Exchange Management Shell (EMS). Both the routing group and the administrative group are hidden in the Exchange 2010 tools. Do not move Exchange 2010 servers out of Exchange Routing Group (DWBGZMFD01QNBJR). Do not move Exchange 2003 servers into it (except when you’re decommissioning the last 2003 routing group). Also, don’t rename either the hidden routing group or the hidden administrative group with any utilities that may be able to do so. TIP Increasing each letter/number in the routing group’s name by one spells “EXCHANGE12ROCKS,” in case you were wondering what the deal was with all the letters. This might have made sense in Exchange Server 2007, even if you didn’t care for it. However, the name is still the same in Exchange Server 2010 (Exchange 14.)
240
Using Default Message Routing
Very little configuration is performed from the Exchange server for default message routing. Use Active Directory Sites and Services (ADSS), which allows you to create sites, site links, and site link costs. Figure 19-1 illustrates a scenario for Romac Sign Company, where five Active Directory sites and six WAN links are represented logically in Active Directory. Initially, all site link costs are 10 units.
Figure 19-1
AD sites, site links, and site link costs
Mail can take three possible paths when being routed from Toronto to Dallas: ■
TOR→SDO→DAL
■
TOR→PHL→DAL
■
TOR→ATL→DAL
This is illustrated in Figure 19-2 and represents the default mailflow scenario for this organization.
Using Exchange Hub Sites
TORONTO
10
241
10
10
SAN DIEGO
PHILADELPHIA
ATLANTA
10
10
Figure 19-2
DALLAS
10
Default message flow
Using Exchange Hub Sites One of two ways to modify message routing in Exchange 2010 is the use of an Exchange hub site. It is remarkably easy to create a hub site, but it has far-reaching implications. Oftentimes, the AD design for your organization is not mail friendly. For example, in Figure 19-1, it may be desirable to replicate AD information evenly across the three paths. However, consider how mailflow will be potentially delayed if the bulk of your Hub Transport servers are located in Philadelphia and messages from Toronto to Dallas will be evenly spread across all three paths. Message delivery from Toronto to Dallas will potentially be slow if routed through either San Diego or Atlanta because there are not enough Hub Transports in either site to handle the volume. You can configure Philadelphia as an Exchange hub site to resolve the problem. This task can only be performed with EMS. EMC has no interface for enabling an Exchange hub site. NOTE
PS C:\Users\Administrator> Get-ADSite
Displays all Active Directory sites in the forest.
PS C:\Users\Administrator> Get-ADSite -Identity Philadelphia
Displays the configuration details for the specified Active Directory site.
PS C:\Users\Administrator> Set-AdSite -Identity Philadelphia -HubSiteEnabled $true
Designates the AD site Philadelphia as an Exchange hub site.
242
Using Exchange-Specific Costs on Site Links
Removes the Exchange hub site designation from the AS site Philadelphia.
PS C:\Users\Administrator> Set-AdSite -Identity Philadelphia -HubSiteEnabled $false
Philadelphia is represented as an Exchange hub site in Figure 19-3.
10
TORONTO
10
10
SAN DIEGO
ATLANTA
PHILADELPHIA EXCHANGE HUB SITE 10
10
Figure 19-3
DALLAS
10
Philadelphia designated as an Exchange hub site
Using Exchange-Specific Costs on Site Links Another way to modify default message flow is to set an Exchange-specific cost on an Active Directory site link. You may not want to set an Exchange-specific cost on every AD site link. You might instead use this technique so that message routing will avoid the use of a specific WAN connection where bandwidth may be saturated. When looking at the previous examples, consider what would occur if there was a network slowdown on the ATL-DAL link every afternoon. Mail traversing the other two paths would be relatively unaffected, but users in Dallas receiving mail from Toronto over the ATLDAL link would experience delivery problems or delays. If this was the case, you could configure the ATL-DAL link (as shown in the following table) to use a different cost for mail than for AD replication (see Figure 19-4).
Using Exchange-Specific Costs on Site Links
243
This task can only be performed with EMS. EMC has no interface for enabling Exchange-specific costs. NOTE
PS C:\Users\Administrator> Get-ADSiteLink
Returns a list of all IP site links in your organization.
PS C:\Users\Administrator> Get-AdSiteLink | Where {$_.ExchangeCost -ne $null}
Returns a list of all IP site links in your organization that have a specific Exchange cost assigned.
Assigns an Exchange-specific cost to an Active Directory IP site link.
The ATL-DAL WAN link is shown with its Exchange-specific cost in Figure 19-4.
10
TORONTO
10
10
SAN DIEGO
ATLANTA
PHILADELPHIA
10
SLOW CONNECTION
EXCHANGE 10
DALLAS
100
10
COST
Figure 19-4
Configuring an Exchange Specific cost for a slow connection
The outcome of both the Set-ADSite and Set-ADSiteLink cmdlets is shown in Figure 19-5.
244
Using Exchange-Specific Costs on Site Links
Figure 19-5
Configuring a hub site and an Exchange-specific cost, as shown in EMS
The following table shows how to return the cost to its original setting. PS C:\Users\ Administrator> Set-AdSiteLink -Identity ATL-DAL -ExchangeCost $null
Assigns an Exchange-specific cost to an Active Directory IP site link. TIP To return to the original setting, you would not use a value of 0 for the cost for two reasons. First, 0 is less than the original value of 10. Second, it is not an acceptable value for this cmdlet. The acceptable values are 1–99999.
The following table shows how to set both the Exchange-specific cost as well as the maximum message size that could be sent across the link. PS C:\Users\Administrator> Set-AdSiteLink -Identity ATL-DAL -ExchangeCost 100 -MaxMessageSize 15MB
Assigns an Exchange-specific cost to an Active Directory IP site link as well as configures the maximum message size that can pass across the link.
The following table shows other cmdlets involved with mailflow.
Creates a delivery agent connector called “Business Partner X.400 Connector” that will be hosted only on Romac-EX1 and Romac-EX3, but not Romac-EX2.
Delivery agent connectors are used to route messages addressed to foreign systems that don’t use the SMTP protocol. NOTE
The delivery agent connector is designed to handle X.400 connections to your business partner and uses the carrier Data1. The address space for the connector is c=US;a=Data1;p=BusPartner.
Configures restrictions on the specified delivery agent connector, setting the maximum message size allowed through the connector to 15MB, configuring the maximum number of messages allowed per connection to 75, and setting the maximum concurrent connections to 20.
Creates a foreign connector called “Romac Fax Connector” that will be hosted only on Romac-EX2 and Romac-EX3, but not Romac-EX1. The fax connector is designed to handle X.400 fax connections to your business partner. The address space for the connector is c=US;a=Data1;P=BusPartner.
Tracking Messages with PowerShell The message-tracking log is located in C:\Program Files\Microsoft\Exchange Server\ V14\TransportRoles\Logs\MessageTracking by default on each computer that has the Hub Transport, Edge Transport, or Mailbox server role installed. The message-tracking log is a .csv file that contains the history of each email message as it travels through the individual server, but could be converted to another format such as HTML for ease of viewing or better functionality. The message-tracking report retrieves and displays information about specific messages in the message-tracking log. This cmdlet requires you to specify the ID for the messagetracking report you want to view. You would use the Search-MessageTrackingReport cmdlet to find the messagetracking report ID for a specific message and then pass the message-tracking report ID from the output of the Search-MessageTrackingReport cmdlet to the GetMessageTrackingReport cmdlet to retrieve the proper report. The use of these cmdlets is shown in the following table. PS C:\Users\Administrator> Get-MessageTrackingLog -Start "11/15/2010 9:00AM" -End "11/21/2010 5:00PM" -Sender "[email protected]"
Retrieves message-tracking log entries that were created between the specified dates and times, with a Sender parameter value of [email protected].
Uses the SearchMessageTrackingReport cmdlet to find the message-tracking report based on the search criteria provided. You would then pass this message-tracking report ID to the Get-MessageTrackingReport cmdlet to retrieve the messagetracking information.
Uses a variable to define a search and can pass the message-tracking report ID from the output of the SearchMessageTrackingReport cmdlet to the GetMessageTrackingReport cmdlet.
The following table shows an example of how you might use the message-tracking option in PowerShell to export a message-tracking report to an HTML file. PS C:\Users\Administrator> Get-ExchangeServer | Where {$_.IsHubTransportServer -eq "true"} | Sort-Object Name | Get-MessageTrackingLog -Sender:[email protected] -EventID "RECEIVE" -Start "3/1/2011 1:00:00 PM" -End "3/3/2011 1:00:00 PM" | ConvertTo-HTML TimeStamp,ServerHostName,Sender, {$_.recipients},MessageSubject | Out-File "C:\Users\Administrator\ Maureen.html"
Figure 19-6
Converting to an HTML file
Retrieves message-tracking log entries from all Hub Transport servers that were created between the specified dates and times, with a Sender parameter value of [email protected]. The result set is converted to an HTML file and includes the timestamp, the server that processed the message, as well as the sender, recipient, and subject of the message, as shown in Figure 19-6.
This page intentionally left blank
CHAPTER 20
Integrating Exchange Server 2010 into an Existing Exchange Server 2003 Environment This chapter provides information and commands concerning the following topics: ■
Configuring routing with Exchange Server 2003
■
Suppressing link state updates on Exchange 2003 bridgehead servers
During a migration from Exchange Server 2003 to Exchange Server 2010, messages must be able to be routed regardless of where the recipient’s mailbox currently exists. Exchange 2003 uses routing groups to route messages, whereas Exchange 2010 uses AD sites and site links. However, mailflow cannot be interrupted simply because a mailbox has been moved from 2003 to 2010. Also, mail must still be routed between a recipient’s mailbox on a 2003 server and a mailbox that has been moved to 2010.
Configuring Routing with Exchange Server 2003 When you install the first Exchange 2010 server into the existing organization, the Exchange installation program (Setup.exe) prompts you for the 2003 bridgehead server that the 2010 Hub Transport server will connect with and then it creates a bidirectional routing group connector (RGC) between the two servers. This configuration page is shown in Figure 20-1.
Figure 20-1 Assigning the first Exchange 2010 Hub Transport server to an Exchange 2003 bridgehead server
250
Configuring Routing with Exchange Server 2003
In the previous chapter, you learned that the RGCs are hidden connectors and that the routing group is also hidden from the 2010 management tools. Without this bidirectional connector (actually two one-way connectors), mail could not be routed between the versions of Exchange Server because 2003 knows no other way to route mail other than by using a routing group connector. Figure 20-2 shows the existence of the routing groups and RGCs from Exchange System Manager, the 2003 GUI for Exchange Server management. 2010 Administrative and Routing Groups
Figure 20-2 Routing groups and RGCs as seen from Exchange System Manager (2003) after installation of the first Exchange 2010 Hub Transport
Sometimes, it is necessary to create additional connectors. Before creating any connectors, you should verify network configuration of the transport server that will host the connectors. As shown in the following table, this can be performed with a cmdlet called Get-NetworkConnectionInfo in Exchange Management Shell (2010).
Retrieves the network configuration information for all NICs configured on the local server. The retrieved information includes the name of the NIC, the configured DNS servers, IP addresses, as well as the MAC address of the adapter. You can use this information to verify network configuration before trying to configure additional routing group connectors from the hidden 2010 routing group to the appropriate 2003 routing groups.
Creates the specified routing group connector. The connector will connect the 2010 Hub Transport to the 2003 bridgehead server. The routing group connector that will be created is a two-way connector (actually, two one-way connectors) between the Exchange 2010 routing group and the 2003 routing group associated with the specified Exchange 2003 server. The cost assigned will be 15. These connectors are shown in Figure 20-3.
Newly Created Routing Group Connectors
Figure 20-3
Newly created RGCs
252
Configuring Routing with Exchange Server 2003
As shown in the following table, you can also change or view properties on existing routing group connectors, as well as remove them when they are no longer required. When Exchange Server 2003 is being decommissioned from the organization, you must remove the remaining RGCs, the last 2003 routing group, and the last Exchange 2003 server. The reasons for removal may be apparent, but the individual tasks must be implemented in a prescribed manner. NOTE
Although some of these tasks can be performed from Exchange Management Shell, you will want to become more familiar with the order, procedures, and details for removing these objects before attempting to do so.This topic should be fully researched before you attempt to remove your last 2003 Exchange server from the organization.
PS C:\Users\Administrator> Set-RoutingGroupConnector -Identity "Exchange Administrative Group (FYDIBOHF23SPDLT)\Exchange Routing Group (DWBGZMFD01QNBJR)\2010 to 2003 RGC" -Cost 75 -MaxMessageSize 15MB -SourceTransportServers "Romac-EX2010HT.Romac2k3.com" -TargetTransportServers "Romac-EX2003.Romac2k3.com"
Figure 20-4
RGC properties
Changes the configuration of the specified routing group connector, setting the cost to 75 (from 15) and setting the maximum message size limit to 15MB (from the default), as shown in Figure 20-4. This could also be used to specify new source and target servers for the connector, if desired. NOTE
Suppressing Link State Updates On Exchange 2003 Bridgehead Servers
253
PS C:\Users\Administrator> Get-RoutingGroupConnector -Identity "Exchange Administrative Group (FYDIBOHF23SPDLT)\Exchange Routing Group (DWBGZMFD01QNBJR)\2010 to 2003 RGC" | fl
Retrieves the configuration information for the specified routing group connector.
PS C:\Users\Administrator> Remove-RoutingGroupConnector -Identity "Exchange Administrative Group (FYDIBOHF23SPDLT)\Exchange Routing Group (DWBGZMFD01QNBJR)\2010 to 2003 RGC" -Confirm:$false
Removes the routing group connector Ex2010 to Ex2003 RGC.
Suppressing Link State Updates On Exchange 2003 Bridgehead Servers Before you begin creating RGCs using the preceding method, you should be aware of a compatibility issue with routing in Exchange Server 2003 and in Exchange Server 2010—that is, 2010 uses site and site links for message routing and 2003 uses routing groups. The 2003 bridgehead servers, by default, try to calculate alternate paths for mailflow when a routing group connector is found to be unavailable. This won’t work with Exchange 2010, and a routing loop may result if Exchange 2003 bridgeheads were to begin marking RGCs as unavailable. Fortunately, an easy fix can be performed using regedit.exe. You need to suppress minor link state updates so that Exchange 2003 only uses least cost routing to route messages and does not try to calculate alternative routes. When you suppress minor link state updates, the servers running Exchange 2003 do not mark routing group connectors as unavailable as they would do normally and mailflow between the routing groups will function as designed in Exchange 2010. You should perform this procedure on every Exchange 2003 bridgehead server in the organization prior to the creation of additional routing group connectors. NOTE
This is not performed using Exchange Management Shell.
The following table shows you how to suppress link state updates on Exchange 2003.
254
Suppressing Link State Updates On Exchange 2003 Bridgehead Servers
The purpose of suppressing link state updates is to ensure that routNavigate to HKEY_LOCAL_MACHINE\ ing loops do not take place because System\CurrentControlSet\Services\ Exchange 2003 bridgehead servers RESvc\Parameters. take control of the connectors. Right-click Parameters and select New | Exchange 2010 doesn’t use a link DWORD. state routing table and doesn’t Name the new DWORD value support the relaying of link state SuppressStateChanges. (This is caseinformation. sensitive.) Registry Editing Warning: If you Double-click SuppressStateChanges. use Registry Editor incorrectly, In the Value data field, type 1 to suppress you can cause serious problems that may require you to reinstall link state updates. your operating system or Exchange Close RegEdit.exe. Server. Use Registry Editor at your own risk and make sure you can Restart the SMTP service, the Microsoft back up the registry before making Exchange Routing Engine service, and the Microsoft Exchange MTA Stacks ser- any changes. vices for the change to take effect.
1 Open RegEdit.exe. 2
3 4
5 6 7 8
Figure 20-5 shows the appropriate area of the registry.
Figure 20-5 servers
Suppressing minor link state updates on Exchange Server 2003 bridgehead
CHAPTER 21
Database Availability Groups (DAGs)
This chapter provides information and commands concerning the following topics: ■
Creating and configuring a DAG
■
Adding or removing a DAG member
■
Recovering a failed DAG member
■
Creating and configuring a DAG network
■
Removing a DAG
A Database Availability Group (DAG) provides the infrastructure for replicating mailbox databases to other servers in the DAG. When a DAG is created, you can think of it as a replication boundary for databases on servers in the DAG. In this chapter, you will review the procedures for creating and managing the DAG and one or more DAG networks.
Creating and Configuring a DAG You need to be aware of the following rules when creating a DAG: ■
A server may belong to only one DAG at any time.
■
Databases may not be replicated outside of the DAG.
■
There is a limit of 16 copies of any database placed on 16 separate servers, called DAG members.
■
Only one copy of each database may be mounted at any time. Others will hopefully appear as “healthy” copies. (This is not a multimaster database environment, such as the one that exists in the Active Directory.)
■
The database copies must all be stored in the same path on each server.
The following table shows how to create a new DAG.
Creates a new DAG with the name RomacDAG1, using the specified server as the witness server and the specified directory as the witness directory. If you did not specify a witness server, one of your Hub Transport servers would be automatically assigned as a witness server, assuming that you have at least one Hub Transport server present that does not have the Mailbox Server role installed on it. RomacDAG1 will be assigned an IP address from DHCP because no IP address was specified. NOTE
TIP If the witness server is not an Exchange Server, you will receive a warning message during the execution of this cmdlet, as shown in Figure 21-1.
Exchange had not yet been installed on Romac-EX3HC in order to view this warning.
Figure 21-1 ness server
Warning received when a non-Exchange server is designated as the wit-
Creates a new DAG with the name RomacDAG2, using the specified server as the witness server and the specified directory as the witness directory. NOTE RomacDAG2 will use the specified static IP address because it was assigned in the cmdlet. You might do this when all DAG members are on the same subnet on your network.
Creates a new DAG with the name RomacDAG3, using the specified server as the witness server and the specified directory as the witness directory, as shown in Figure 21-1. RomacDAG3 will use the three specified static IP addresses because they were assigned in the cmdlet. NOTE
TIP If the members of the DAG are on multiple subnets, you must assign multiple IP addresses for the DAG for each subnet. Simply separate the IP addresses by commas in the cmdlet, as shown.
This example creates a new DAG with the name RomacDAG4, but does not specify any parameters. You can always add the unspecified parameters later with a SetDatabaseAvailabilityGroup cmdlet. NOTE
In this example, a Hub Transport should have been automatically designated as a witness server because none was specified. However, no Hub Transport was found without a mailbox role on it as well. In such cases, you will receive an error, as shown in Figure 21-2.
TIP
After the Hub Transport role was added to a server (RomacEX3HC), the cmdlet was rerun and it completed without any errors. Also, in this example, RomacDAG4 will be assigned an IP address from DHCP because no IP address was specified.
In Service Pack 1, it is now possible to create a DAG with a static IP address in Exchange Management Console (EMC). NOTE
258
Creating and Configuring a DAG
Figure 21-2 Error received when the system attempts to designate a Hub Transport server as the witness server and no Hub Transports are found without the mailbox role also installed on them
Once one or more DAGs have been created, you may want to view the properties of all DAGs or of a specific DAG. You can also specifically view the status of the DAG if you wish. Figure 21-3 shows them from Exchange Management Console (EMC), but you could also use the Get-DatabaseAvailabilityGroup cmdlet, which shows them from the command line (as shown in the following table).
Figure 21-3
DAGs as seen from EMC
PS C:\Users\Administrator> Lists all DAGs in your organization. Get-DatabaseAvailabilityGroup | fl PS C:\Users\Administrator> Get-DatabaseAvailabilityGroup -Identity RomacDAG3 | fl
Shows the complete list of all attributes for a single DAG.
Shows the status-related attributes for a single DAG.
To change properties of an existing DAG, you can use the SetDatabaseAvailabilityGroup cmdlet (as shown in the following table). PS C:\Users\Administrator> Set-DatabaseAvailabilityGroup -Identity RomacDAG4 -WitnessServer Romac-EX3HC -WitnessDirectory C:\FSW-DAG4 -DatabaseAvailabilityGroupIPAddresses 10.5.0.99
Adds the specified server as the witness server and the specified directory as the witness directory.
Assigns an alternate witness server for the specified DAG. This is useful in case of a site failure and will be discussed in greater detail in Chapter 23, “Using DAG to Mitigate Failures.”
NOTE RomacDAG4 will now use the static IP address of 10.5.0.99, because it was added with the SetDatabaseAvailabilityGroup cmdlet.
The AlternateWitnessServer parameter can be used to specify the name of a new witness server for the DAG in the DR site. By using this parameter, you can specify the server in advance. You can also assign the alternate witness directory for the specified DAG on the new witness server. NOTE
It is not possible to view the IP address of the DAG from Exchange Management Console after it has been configured using Exchange Management Shell (EMS), but you can use the examples to do so from EMS. These examples (displayed in Figure 21-4) show the IP address specifically assigned to DAG4 (previously) and the dynamic address assignment configured on Romac-DAG3.
Figure 21-4 IP addresses assigned to RomacDAG4 and dynamic assignment to RomacDAG3, as seen from EMS
Adding or Removing a DAG Member In Figure 21-3, no DAG members are in the highlighted DAG (or any other DAG) at the moment. Servers in the DAG are called “members,” and after the DAG has been created, the members need to be added to the DAG with the Add-DatabaseAvailabilityGroup Server cmdlet. This is not an automated process because Exchange cannot know which mailbox servers you want to join each individual DAG. When a server is added as a DAG member, it joins the other servers already in the DAG, and they function together to ensure high availability of one or more databases. The Primary Active Managers (PAMs) and Secondary Active Managers (SAMs) on DAG members provide automatic, database-level failovers and switchovers whenever a database, server, or even a network failure is detected. Here are the requirements for a server to become a DAG member:
Adding or Removing a DAG Member
261
■
The potential DAG member must be a mailbox server running a 64-bit operating system version of Windows Server 2008 Enterprise Edition or Windows Server 2008 R2 Enterprise Edition because failover clustering is required for Database Availability Groups.
■
The potential DAG member may not be a member of any other DAG.
■
The potential DAG member must not be a domain controller.
■
The potential DAG member must be in the same Active Directory domain as all of the other DAG members.
NOTE
Do not install the Failover Clustering feature in advance.
The following table shows how to add a server to the DAG as a member. PS C:\Users\Administrator> Add-DatabaseAvailabilityGroupServer -Identity RomacDAG4 -MailboxServer Romac-EX1 PS C:\Users\Administrator> Add-DatabaseAvailabilityGroupServer -Identity RomacDAG4 -MailboxServer Romac-EX2
Figure 21-5
Adds the specified mailbox servers as DAG members, as shown in Figure 21-5. This task will take several minutes because the Windows Failover Clustering component must be added to each server before the server may become a member of the DAG. NOTE
RomacDAG4 with member servers Romac-EX1 and Romac-EX2 added
262
Adding or Removing a DAG Member
After the members have been added to the DAG, a computer object will appear in Active Directory Users and Computers (ADUC), as shown for RomacDAG4 in Figure 21-6. Notice that there are no similar objects for RomacDAG1, RomacDAG2, and RomacDAG3 because you never added any members to those DAGs.
Figure 21-6
Viewing the DAG in Active Directory Users and Computers (ADUC)
The following table shows how to remove a server from the DAG, such as might be necessary when a server must be added as a member of another DAG. PS C:\Users\Administrator> Remove-DatabaseAvailabilityGroupServer -Identity RomacDAG4 -MailboxServer Romac-EX2 -Confirm:$false
Uses the AddDatabaseAvailbilityGroupServer cmdlet to add the specified server back into the DAG.
To remove a Mailbox server from a DAG, all replicated copies of databases must be removed first. NOTE
The -ConfigurationOnly switch removes the DAG member server attribute from Active Directory without actually removing the DAG member from the DAG, as shown in the following table.
Forcibly removes the specified DAG member from the DAG when the DAG member will be out of service for an extended period of time and you are unable to use the Remove-DatabaseA vailabilityGroupServer cmdlet normally. The -ConfigurationOnly option allows the remaining DAG members to establish a quorum without the missing member. NOTE Be careful with this one. This should only be performed if the Mailbox server role is down or unavailable for an extended period of time because you will be unable to reestablish the failed server as a DAG member by using conventional means.
If the server is up, you should remove it from the DAG properly.
If you performed the preceding example, you will need to do a little cleanup before proceeding. You must recover the “failed” RomacEX2 and add it back as a member server in Romac-DAG4 or use another mailbox server, as is done with RomacEX4 in the next two chapters. NOTE
Recovering a Failed DAG Member The procedure to remove a failed DAG member is not complex, but does involve several steps. Before you can recover the failed DAG member, you must identify any replicated databases located on the member server. This can be done by using the GetMailboxDatabase cmdlet. Once you have identified copies of any replicated databases hosted locally, you must switch any mounted copies to another DAG member. This will be discussed in Chapter 22, “Mailbox Database Copies.” Any remaining copies must be removed with the Remove-MailboxDatabaseCopy cmdlet. At that point, the server may be removed from the DAG using the Remove-DatabaseAvailabilityGroupServer cmdlet. You could rebuild the server in a variety of ways, but one way that would be relatively easy would be to use the Setup.com /m:RecoverServer option to perform an unattended rebuild of the affected server on either new or existing hardware. This procedure is outlined in the table that follows. If you wish to perform this task, be advised that it will take an extensive amount of time because Exchange will be reinstalled as part of the recovery operation. NOTE
Retrieves information about a replicated database, including all of its replicated copies. When you observe a replicated database copy on a failed DAG member, you must first remove the copy before the server can be recovered.
Removes a Mailbox server from a Database Availability Group (DAG).
Perform this step from cmd.exe, not from Exchange Management Shell: D:\Setup.com /m:RecoverServer
Rebuilds the failed DAG member by running a special version of Setup.com specifically designed to rebuild a failed Exchange server using the information from Active Directory.
To remove a Mailbox server from a DAG, the Mailbox server must not host any replicated mailbox databases. NOTE
Before reinstalling Exchange Server on the failed server, it is very important to use the Reset Account option in ADUC and not the Delete option before rebuilding your server, as shown in Figure 21-7. Deleting the computer account will cause this type of rebuild to no longer be an option.
TIP
After the installation completes, you would follow the steps in Chapter 22 to add and configure database copies to the repaired server. NOTE
Creating and Configuring a DAG Network
Figure 21-7
265
Resetting the affected computer account in ADUC
Creating and Configuring a DAG Network In preparation for the next two chapters, you will reset the environment to have only one DAG configured. Remove all DAG members and remove all DAGs. Then, you may proceed with the steps shown in the following table. Creates a new DAG PS C:\Users\Administrator> with the specified New-DatabaseAvailabilityGroup name. -Name RomacDAG -DatabaseAvailabilityGroupIPAddresses 10.5.0.100 -WitnessServer Romac-DC1 -WitnessDirectory C:\FSW-RomacDAG PS C:\Users\Administrator> Add-DatabaseAvailabilityGroupServer -Identity RomacDAG -MailboxServer Romac-EX3HC
These examples add the two specified servers as DAG members.
A DAG network is a collection of one or more subnets on your network that are utilized for either RPC/MAPI connections or for replication traffic between DAG members. Initially a DAG is automatically assigned one DAG network; it is utilized for both RPC/ MAPI connections as well as replication traffic, by default.
266
Creating and Configuring a DAG Network
Often, it is desirable to separate the replication traffic from the clients accessing the server. This would require a second DAG network and a second NIC in all DAG members. It is also fully supported to have more than two DAG networks. PS C:\Users\Administrator> New-DatabaseAvailabilityGroupNetwork -DatabaseAvailabilityGroup RomacDAG -Name RomacDAGNet01 -Description "Romac DAG Replication Network 01" -Subnets 10.5.0.0/24 -ReplicationEnabled:$true
Creates two new DAG networks with the specified names.
Lists the DAG networks and retrieves standard configuration information for all networks in the specified DAG, as shown in Figure 21-8. The 10.155.0.0 subnet has an “Unknown” status because it does not actually exist on the network. NOTE
Figure 21-8 shows the newly created and configured DAG networks in EMC.
Figure 21-8
DAG networks as seen in EMS
Creating and Configuring a DAG Network
267
The following table provides additional information about your DAG networks and how to configure DAG network properties. PS C:\Users\Administrator> Get-DatabaseAvailabilityGroupNetwork -Identity RomacDAG | fl
Retrieves all configuration information for all networks in the specified DAG.
Configures the existing DAG network to include the specified new IP subnet as part of the DAG network. The 10.156.0.0 subnet has an “Unknown” status because it does not actually exist on the network. NOTE
Figure 21-9 shows the newly created and configured DAG networks in EMC.
Figure 21-9
DAG networks as seen in EMC
268
Removing a DAG
Removing a DAG When a DAG is no longer required, you may remove it from service with the RemoveDatabaseAvailabilityGroup cmdlet, as shown in the following table. PS C:\Users\Administrator> Remove-DatabaseAvailabilityGroupNetwork -Identity RomacDAG\RomacDAGNet02 -Confirm:$false
Before removing the DAG, this example removes the DAG network. This example removes the specified DAG network from a DAG.
Removes the DAG from service after all member servers have been removed from the DAG.
CHAPTER 22
Mailbox Database Copies
This chapter provides information and commands concerning the following topics: ■
Adding and configuring a mailbox database copy
■
Moving the active mailbox database copy to a new location
■
Suspending or resuming a mailbox database copy
■
Updating a mailbox database copy
■
Removing a copy of a mailbox database
In this chapter you investigate how easy it is to create a mailbox database copy within the infrastructure of a Database Availability Group (DAG). You observe how to configure the copies, as well as how to move a copy of a mailbox database to another server using a DAG, while the database never goes offline. You also investigate how to suspend, resume, and update a copy of a mailbox database and, finally, you see how to remove a copy when it is no longer needed.
Adding and Configuring a Mailbox Database Copy You can use the Add-MailboxDatabaseCopy cmdlet to create a copy of a mailbox database on another server. This will only work with mailbox databases, not public folder databases. TIP Use public folder replication to create a copy of a public folder database as you did in previous versions of Exchange Server.
For you to successfully create a copy of a mailbox database, the server that will host the copy must be in the same Database Availability Group as the server hosting the original copy. A server is not able to host two copies of the same database any longer, as was the case with Local Continuous Replication (LCR) in Exchange Server 2007. All copies of a single database must use the same path in the file system of the DAG member servers. If a database exists in D:\Databases\AssemblyDB on one server, that path must not currently be in use on the server that will receive the copy; otherwise, the database copy operation will fail. Creating a copy of a mailbox database as well as editing the attributes of a database are shown in the following table.
Adds a copy of the specified mailbox database to the Mailbox server named Romac-EX3HC. Because they are not specified, the Replay lag time and Truncation lag time are set to their default value of 0. The activation preference is set to a value of 2.
The Replay lag time is set to 7 days and the Truncation lag time is set to 30 minutes. The activation preference is set to a value of 2.
The second example configures the Replay lag time back to 0 for the specified copy of a mailbox database hosted on Romac-EX3HC. Configures the Activation preference for the specified copy of a mailbox database hosted on Romac-EX3HC. Because the Activation Preference number is set at 6, this cmdlet will only work if you have six or more copies of the database. NOTE
The copies of the ResearchDB, as they appear in EMC, can be seen in Figure 22-1. Note that the original copy, which appears as “Mounted,” is on Romac-EX4, and the replicated copy appears as “Healthy” on Romac-EX3HC.
Adding and Configuring a Mailbox Database Copy
Figure 22-1
271
Mailbox database copies as seen from EMC
You can check the status of your database and all its copies as well as remove an individual copy using the cmdlet shown in the following table. PS C:\Users\ Administrator> Test-ReplicationHealth -Identity Romac-EX3HC
Allows you to check the replication and replay status of a database copy, as shown in Figure 22-2. This cmdlet is designed for on-going monitoring of all copies of the specified database. This cmdlet can be run locally or remotely against any Mailbox server in the DAG. NOTE
Figure 22-2
Romac-EX3HC passes all replication health tests
272
Moving the Active Mailbox Database Copy to a New Location
You can remove a database copy by using the cmdlet shown in the following table. PS C:\Users\Administrator> Remove-MailboxDatabaseCopy -Identity ResearchDB\Romac-EX3HC -Confirm:$false
Removes the specified copy of the mailbox database that is hosted on Romac-EX3HC.
Moving the Active Mailbox Database Copy to a New Location You can use the Move-ActiveMailboxDatabase cmdlet to implement a database-level switchover, thus activating a database copy on another mailbox server. You can also use the same cmdlet to implement a server-level switchover, thus activating all database copies on another mailbox server. Switchovers are administrative events usually implemented in order to perform maintenance on a database or server. Prior to the moving of databases, Romac-EX4 has the active copy of both the OfficeDB and the ShippingDB, as seen in Figure 22-3.
Figure 22-3 tchovers
Romac-EX4 hosts both active database copies prior to the database swi-
The following table shows how to move active databases to another server with multiple database-level switchovers and no downtime.
Moving the Active Mailbox Database Copy to a New Location
Performs a switchover of the specified database to the Mailbox server named Romac-EX3HC. When the command completes, Romac-EX3HC will host the active copy of the ResearchDB. The -MountDialOverride parameter has the following five possible options: None—The copy on the specified server mounts the database using its own defined database automount dial settings. Lossless—The copy on the specified server mounts the database when all log files from the original server have been copied and replayed on the new server. (This is the default value for this setting and allows for no data loss.) Good Availability—The copy on the specified server mounts the database immediately after a failover if the copy queue length is less than or equal to six logs. Best Availability—The copy on the specified server mounts the database immediately after a failover if the copy queue length is less than or equal to 12 logs. Best Effort—The copy on the specified server mounts the database automatically, regardless of the size of the copy queue length. Because the database will mount with any amount of transaction log loss, using this option could potentially result in an excessive amount of data loss, but it is presented as an option for those cases where mounting the database is necessary at any cost.
Performs a switchover of the specified database to the Mailbox server named Romac-EX3HC. When the command completes, Romac-EX3HC will host the active copy of the ShippingDB database. Because the MountDialOverride parameter isn’t specified, the Lossless option (default) will be used.
Now, Romac-EX4 has the “healthy” copies of both the OfficeDB and the ShippingDB, as seen in Figure 22-4. The mounted copies have been moved to Romac-EX3HC.
274
Suspending or Resuming a Mailbox Database Copy
Figure 22-4 Romac-EX4 now hosts “healthy” database copies after the database-level switchover and prior to the server-level switchover
The following table shows how to move active databases back to the original server with a server-level switchover and no downtime. PS C:\Users\Administrator> Performs a server switchover for the specified Move-ActiveMailboxDatabase Mailbox server role, as shown in Figure 22-5. -Server Romac-EX3HC Active mailbox database copies on the server
will be automatically activated on other Mailbox server roles that host healthy copies of the active databases on the specified server.
Figure 22-5
Performing a server-level switchover using EMS
Suspending or Resuming a Mailbox Database Copy You can use the Suspend-MailboxDatabaseCopy cmdlet to halt the replication of a database and the replaying of transaction logs on the target database copy. You can use
Suspending or Resuming a Mailbox Database Copy
275
the Resume-MailboxDatabaseCopy cmdlet to resume replication of a database copy and the replaying of transaction logs for a mailbox database. The cmdlets in the following table show how to suspend a database copy, which you may want to do when you are performing maintenance on the server, and then resume the copy after the maintenance has been performed. PS C:\Users\Administrator> Suspend-MailboxDatabaseCopy -Identity ShippingDB\Romac-EX3HC -SuspendComment "Windows Service Pack applied to Romac-EX3HC"
Suspends the replication and transaction log replay for the specified database copy of a database on Romac-EX3HC, as shown in Figure 22-6.
Resumes both replication and transaction log copying and replaying for the specified copy hosted on RomacEX3HC.
An optional reason (-Suspend Comment) is included in the cmdlet.) NOTE
The -ActivationOnly parameter is included to suspend only the activation portion. Log shipping and replay will still occur.
However, after the copy is resumed, activation of the copy is blocked because of the -ReplicationOnly parameter.
Figure 22-6
A suspended database copy as seen from EMC
276
Removing a Copy of a Mailbox Database
Updating a Mailbox Database Copy You can use the Update-MailboxDatabaseCopy cmdlet to seed or reseed a mailbox database copy. The seeding operation copies a database from one DAG member to another. Once the mailbox database copy is fully seeded, transaction log shipping and replay can commence. If logs are missing, resuming the database copy is not possible. The following table shows how to force a reseeding of the database. In the second example, the database is reseeded from a specific server (Romac-EX4). PS C:\Users\Administrator> Update-MailboxDatabaseCopy -Identity ShippingDB\Romac-EX3HC
Shows how to seed the specified copy of a database on the server Romac-EX3HC.
Shows how to seed the specified copy of a database on the server Romac-EX3HC using Romac-EX4 as the source server for the seeding operation.
To seed the database only and not the content index, you would use the -DatabaseOnly switch. To seed the content index only and not the database, you would use the -CatalogOnly switch. NOTE
Removing a Copy of a Mailbox Database You can use the Remove-MailboxDatabaseCopy cmdlet to remove a mailbox database copy from a server. This will function on all copies except for the active/mounted copy. To remove the active copy, dismount the database using the Remove-MailboxDatabase cmdlet (as shown in the following table). PS C:\Users\Administrator> Remove-MailboxDatabaseCopy -Identity ShippingDB\Romac-EX3HC -Confirm:$false
Removes the specified copy of mailbox database from the Mailbox server role named Romac-EX3HC.
CHAPTER 23
Using DAG to Mitigate Failures
This chapter provides information and commands concerning the following topics: ■
Activating a mailbox database copy on another DAG member
■
Activating a lagged mailbox database copy on another DAG member
In the previous chapter, you saw how easy it was to activate a mailbox database copy on another server. In this chapter, you take a more in-depth look at the process before investigating lagged database copies. Lagged database copies were mentioned previously, but not examined to any great detail. This chapter looks at the procedure for activating a lagged mailbox database copy on another DAG member, with the intent of performing a point-in-time recovery of a database that has been found to have corrupt or missing data. After looking at database-level failovers and switchovers, you will move to server-level failovers and switchovers. Finally, you will look at configuring datacenter switchovers when a disaster strikes your datacenter.
Activating a Mailbox Database Copy on Another DAG Member As you saw in the previous chapter, activation is the process of changing a mailbox database copy from a passive copy to an active copy. This operation can be an administrative event, such as you saw in Chapter 22, “Mailbox Database Copies,” when you used the Move-ActiveMailboxDatabase cmdlet to perform a switchover. Other times, this operation can be a system-related event, such as when a corrupt database is found by Active Manager. This system-related event is called a “failover” and occurs automatically in many circumstances. Sometimes, you may want to prevent a database copy from activating automatically. Executing the cmdlet prevents a database copy from becoming the active copy during a database or server failover. With lagged database copies, you will want to prevent a copy from becoming active too soon. Suspending and resuming such database copies manually is shown in the following table. You must use EMS as part of the activation process. You cannot use EMC to suspend or resume a database in preparation for activation. NOTE
278
Activating a Mailbox Database Copy on Another DAG Member
Resumes the copy of the specified database, so that it may become the active (mounted) copy as part of the normal automatic activation process.
All automatic failovers and manual switchovers are controlled by a new component in Exchange 2010 called the Active Manager. It is important to understand that this is the component that provides the capability formerly provided by integration with the Windows Cluster service in previous versions of Exchange. Exchange Server 2010 no longer uses the traditional cluster resource model for high availability, as was the case with Exchange Server 2007. The Windows Failover Cluster model is still used by Exchange, but there are no cluster groups or storage resources for Exchange. All of the clustering capabilities are completely managed by Exchange and not by any Windows cluster utilities. Active Manager runs as a role on all Mailbox servers. On Mailbox servers that are not configured for high availability, there is a single Active Manager role called the Standalone Active Manager. However, on servers that are members of a Database Availability Group (DAG), there are two possible Active Manager roles. These roles are the Primary Active Manager (PAM and the Standby Active Manager [SAM]). PAM is the Active Manager in a DAG that decides which copies will be active and which will remain passive in failover and switchover scenarios. PAM is also responsible for receiving and updating topology change notifications and responding to server failures. The DAG member that holds the PAM role is always the member that currently owns the cluster quorum resource. If the server that owns the cluster quorum resource fails, the PAM role automatically moves to another server. If the PAM role moves, it will move to the server that takes ownership of the cluster quorum resource. If you need to take the server that hosts the cluster quorum resource offline for maintenance purposes, you should move the PAM role to another server in the DAG.
Activating a Lagged Mailbox Database Copy on Another DAG Member
279
Activating a Lagged Mailbox Database Copy on Another DAG Member A lagged mailbox database copy is a mailbox database copy configured with a replay lag time value greater than 0. Activating a lagged mailbox database copy is not difficult if you intend to replay all of the outstanding log files to make the database copy identical to the other copies of the database. However, the benefit of employing a lagged database copy is the ability to perform a point-in-time recovery for that database. For example, suppose someone deletes several hundred mailboxes accidentally or on purpose. Without a lagged copy, those deletions are transactions that will replicate to all nonlagged copies and be replayed immediately. With a lagged copy of the database, you can replay the log files right up to a specific point in time (in this case, the deletion), which can be a huge benefit to you because it may reduce or eliminate the need for a database restore if you know when the data became corrupted or was lost. However, it is a much more complex environment when you use lagged database copies. You must work with log files manually and you must employ certain options built in to the utility eseutil, which you might not be familiar with using. Also, you must know the timeframe in which corruption or loss occurred. Add to this the fact that there are no built-in utilities to tell you which log file contains each transaction. Therefore, you have to use your best judgment to anticipate which log files should be replayed in order to get the database to the exact point in time you require. Point-in-time recoveries must be performed using EMS; this option is not available in EMC. The mailbox database copy that you wish to use in your point-in-time recovery must be activated and also must be configured with a replay lag time greater than 0. It must also have all of its log files available right up to the point in time to which you want to recover the database. You can use EMS to activate a lagged mailbox database copy to a specific point in time. The following table shows how to do this. PS C:\Users\Administrator> Suspend-MailboxDatabaseCopy -Identity OfficeDB\Romac-EX3HC -SuspendComment "Activation of the lagged copy of the OfficeDB on Romac-EX3HC" -Confirm:$false
Suspends replication on the lagged copy that will be activated, as shown in Figure 23-1. You should carefully consider whether you want to back up the database and transaction log files or copy them to another location. This is important in case you don’t restore the logs to the correct point in time the first time. NOTE
280
Activating a Lagged Mailbox Database Copy on Another DAG Member
Figure 23-1
Suspending replication of the lagged copy on Romac-EX3HC
Before performing this step, identify which log files are required to be replayed into the database to meet your point-in-time recovery. Move the log files created later to a different directory. If all goes well, you won’t need them again. This example determines the log file prefix number for the database, as shown in Figure 23-2.
Determining the log file prefix for a database
Activating a Lagged Mailbox Database Copy on Another DAG Member
Performs a soft recovery of the database, as shown in Figure 23-3.
If the log file prefix number is E01, this file would be called E01.chk. NOTE
The “/r” instructs eseutil to perform the soft recovery, and the “/a” instructs eseutil to run in log recovery mode. NOTE
TIP This step may take a really long time depending on the database size, replay lag time, the number of log files, and the speed of your hardware. You can use the 2010 version of JetStress (64-bit), which includes a Recovery Performance option for calculating the approximate time that the soft recovery will take.
Figure 23-3
Soft recovery of the database using Eseutil /r
282
Switching Over to Another DAG Member
When eseutil has completed, the database is This step will vary depending on your recovery needs for the database in a clean shutdown state. You can do one of three things at this point: copy. Your options are displayed.
You can copy it to a server and attempt to mount it.
■
You can create a recovery database using this database, attempt to mount it, and recover the data.
■
You can replace the corrupt database files with the lagged database files and then attempt to mount the database.
This example may be performed after the recovery process has completed. You may want to resume replication for the database that was used as part of the recovery process.
This can become a long and tedious process and is not a procedure you will want to do very often. Fortunately, not too many situations require it. Lagged copies were never designed for the recovery of deleted items, although in a disaster you may need to use a lagged copy for just that type of recovery operation. However, you have previously seen other ways to recover deleted items before you will need to resort to performing this type of restore. Lagged copies are a protection against data corruption and, when combined with DAGs, can begin the process of moving toward a backup-less Exchange organization. Just because you can do a point-in-time recovery of a database with a lagged database copy does not always mean that you will want to immediately move to a backup-less Exchange organization. You will need to consider many factors before using high-availability DAGs in place of traditional disaster recovery strategies. What it can mean, however, is that you might be able to reduce your reliance on traditional backup and restore operations as you shift your resources toward high availability. NOTE
Switching Over to Another DAG Member A server-level switchover is initiated when you want all active databases on a DAG member to be activated on one or more other DAG members. This can be for many reasons. You may want to take a server out of service permanently, you may want to patch a server, or you may even be experiencing intermittent problems on a server and want to get it out of the production environment until you figure out what the problem is with the server. A server-level switchover can occur within the datacenter, but it could also occur between datacenters. Just like a database-level switchover, the server-level switchover can be started from either EMC or EMS. Several PowerShell cmdlets in EMS are shown in the following table.
Performs a server switchover for the specified server.
Because no target server was specified, the Active Manager automatically selects the best server for each active database. NOTE
If the cmdlet completes successfully, the target server will host the active copy of all databases that were previously active on the original server.
Switching Over to Another Datacenter Significant differences exist between database or server failures and failures of the datacenter, so you will need to manage the datacenter switchover differently. With other types of failures, you require some form of automatic recovery that requires no administrative intervention. Recovering from these events will normally complete with the component (database or server) in a fully functional state. Compare that to the datacenter failure, which is a much rarer event and often will require administrative intervention to bring the alternate datacenter online for clients. In order to understand this process, you must know which scenario you are faced with as part of the DR strategy. One possible scenario is that both sites survive the failure but have no connectivity to each other. Another scenario is that the primary site has experienced a partial failure, but some roles still exist. A third possible scenario is that the primary datacenter has been completely lost. There may be no way for Exchange to distinguish between these scenarios from the DR site. In order to recover, you must first know if Datacenter Activation Coordination (DAC) mode has been enabled for the DAG. DAC mode is designed to prevent split brain syndrome from occurring, where both sites believe that they are the surviving site and that the other site is gone. With DAC mode enabled, after a site or communication failure, when the DAG recovers, it blocks the automatically remounting databases in the primary site even though the DAG has a quorum in that site. DAC mode is disabled by default, but should be enabled for all DAGs that use continuous replication in multiple sites where three or more database copies exist. When DAC mode is not enabled, and a failure occurs impacting one or more servers in the DAG, the DAG will restart and attempt to mount all of its databases when a majority of the DAG members return to service. In the case of a partial datacenter failure, you want to terminate any remaining DAG members in the primary datacenter and fail over to the alternate site. The following table shows how to do this.
Forces a quorum start of the Cluster service on a DAG member in the alternate datacenter.
No tasks need to be performed from Exchange Management Shell (EMS) in this step.
You would then open the Failover Cluster Management tool in Windows Server 2008, connect to the DAG’s underlying cluster, expand the cluster, and then expand Nodes. Next, right-click each node in the primary datacenter, select More Actions, and then select Evict. This evicts the remaining DAG members in the primary datacenter.
You would then activate the servers in the alternate datacenter. (Again, these steps assume that DAC mode is not enabled.) The following table shows how this is done. PS C:\Users\Administrator>cluster RomacDAG /quorum /nodemajority
If there are an odd number of DAG members in the alternate datacenter, this example changes the DAG quorum model from a Node and File Share Majority to a Node Majority quorum. Proceed to the step that starts the Cluster service.
If there is an even number of DAG members in the alternate datacenter, this example reconfigures the witness server and directory. Proceed to the step that starts the Cluster service.
PS C:\Users\Administrator>net start clussvc
Starts the Cluster service on any remaining DAG members in the alternate datacenter.
Mounts the mailbox databases on each DAG member in the alternate datacenter.
Enabling Datacenter Activation Coordination (DAC) Mode As discussed previously, DAC mode is designed to prevent split brain syndrome. This is done by using the Datacenter Activation Coordination Protocol (DACP). DACP is used to determine the current state of the DAG and whether Active Manager should attempt to mount the databases. Return to two of the possible scenarios discussed previously to understand why DAC mode exists. The datacenter could actually be lost or the network connection between the two sites could be down. The DAG members in the alternate datacenter have no way of determining which scenario has taken place. Therefore, automatic activation of the alternate datacenter is not desired until an administrator figures out what is happening in the primary site. If the decision is made to activate the alternate site’s servers, a new problem arises. What will happen if the primary site is returned to an active status? It is very possible that the primary servers will come online before network connectivity between the two sites has been reestablished. Without DAC mode, there would be two active sites, each unable to talk to the other. Add to this the fact that the primary site contains the majority of the DAG quorum voters, which is why it was active to begin with, and even without network connectivity to the alternate site, servers in the primary site would come online and begin activating their copies of their databases as they would do with a database or server failover scenario. This is a problem because the alternate site has been manually activated by an administrator and is functioning for clients. DACP was created to prevent this very scenario. Active Manager stores a bit in memory—either a 0 or a 1. This bit allows or blocks a DAG member from mounting its copy of the database. When a DAG is running in DAC mode, which would be appropriate for any multisite DAG with three or more members, each time Active Manager starts on a server, the bit is automatically set to a 0, which indicates to the server that it is not allowed to mount its databases. Because the DAG is in DAC mode, the server attempts to communicate with all other members of the DAG. If it can connect to a server whose bit is set to a 1, this server can also set its bit to a 1. Databases can now be activated on the server. If the server cannot connect to any other DAG members or can only connect to other servers whose bit is set to a 0, then this server’s bit must remain a 0 and databases may not be activated on this server. In this scenario, all servers in the primary datacenter will have their bits set to 0 when they come back online and will have no way to change the bit to a 1, until network connectivity is reestablished to the alternate datacenter. At that point, the members realize that there are active servers online in the alternate site. It is a simple but important configuration to enable DAC mode, and this can only be performed using EMS, as shown in
the following table. Other very important cmdlets shown in the following table include those allowing you to stop and start the DAG, as well as cmdlets for restoring the DAG to a member in an alternate datacenter after a failure. PS C:\Users\Administrator> Set-DatabaseAvailabilityGroup -Identity RomacDAG1 -DatacenterActivationMode DagOnly
Uses the StopDatabaseAvailabilityGroup cmdlet to stop a member of a DAG or to stop an entire Active Directory site. This cmdlet is used during a datacenter switchover and marks the members of the DAG in a failed datacenter as stopped. NOTE
PS C:\Users\Administrator> Stop-DatabaseAvailabilityGroup -Identity RomacDAG -ActiveDirectorySite Philadelphia
This cmdlet can be run against a DAG only when the DAG is configured with a -DatacenterActivationMode value of DagOnly, as performed in the previous example. Uses the StopDatabaseAvailabilityGroup cmdlet to stop an entire Active Directory site.
Uses the RestoreDatabaseAvailabilityGroup cmdlet to activate DAG member servers in the alternate datacenter. NOTE This cmdlet is used following a failure or deactivation of the active DAG members in a primary datacenter.
This cmdlet can be run against a DAG only when the DAG is configured with a -DatacenterActivationMode value of DagOnly.
Activates member servers in the specified DAG and configures an alternate witness server and alternate witness directory on the specified server in the specified location.
Uses the StartDatabaseAvailabilityGroup cmdlet to start a member of a DAG. This cmdlet is used to activate member Mailbox servers in a recovered datacenter after a datacenter switchover. The server is added to the DAG and joined to the DAG’s cluster. NOTE
This cmdlet can also be used to reactivate servers from a previously failed datacenter that has been restored to service. In that scenario, after this cmdlet is run, you would then run the Move-ActiveMailboxDatabase cmdlet to activate databases in the primary datacenter.
This page intentionally left blank
CHAPTER 24
Monitoring Highly Available Databases
This chapter provides information and commands concerning the following topics: ■
Monitoring using the Exchange Management Console
■
Monitoring using PowerShell cmdlets
■
Monitoring using Event Viewer
■
Monitoring using PowerShell scripts
In this chapter, you investigate the ways to monitor the health of your highly available databases, servers, and DAGs. Some of these methods can be performed through either EMC or Event Viewer, whereas others will go deeper and use either individual cmdlets or multiple cmdlets batched together into one of two scripts.
Monitoring Using the Exchange Management Console There are several ways to monitor DAG members and their databases. One very easy way is to observe them from the viewpoint of the database in Exchange Management Console (EMC), as shown in Figure 24-1. You can also observe them from the viewpoint of the server in EMC, as shown Figure 24-2.
Figure 24-1 DAG Mailbox Database Copy Status from the viewpoint of the database as seen from EMC
290
Monitoring Using PowerShell Cmdlets
Figure 24-2 DAG Mailbox Database Copy Status from the viewpoint of the server as seen from EMC
Observing this information in a visual format makes it very easy to determine the basic state of your DAG and its member servers.
Monitoring Using PowerShell Cmdlets You can also use Exchange Management Shell (EMS) to view status information about DAGs in your organization and their members. As you might expect, ensuring that your DAG members are functioning correctly and that your database copies are healthy is crucial for maintaining highly available mailbox servers. This involves monitoring hardware, server operating systems, and Exchange Server. Windows Server 2008 and Exchange Server 2010 include several utilities to ensure your highly available databases and servers are functioning properly. Two main monitoring cmdlets are used for evaluating the performance of your DAGs and their member servers. The first is the Get-MailboxDatabaseCopyStatus cmdlet. This allows you to view status information about mailbox database copies, including information about all copies of a particular database as well as information about a specific copy of a database on a specific server, as shown in the following table. PS C:\Users\Administrator> Get-MailboxDatabaseCopyStatus -Identity ShippingDB | fl
Returns status information for all copies of the specified database.
Returns status, log shipping, and seeding information for the specified database DB3 on the specified Mailbox server.
The second is the Test-ReplicationHealth cmdlet, which allows you to view continuous replication status information about various mailbox database copies. It is used to evaluate all of the components involved in the replication and log replay process between members of the DAG. This cmdlet can be run locally on any Mailbox server in the DAG or remotely against any Mailbox server in a DAG from a client that has Exchange Management Shell installed on it. NOTE
Evaluates the health of replication for the specified Mailbox server.
Monitoring Using Event Viewer A new feature in Windows Server 2008 allows you to customize logs in Event Viewer. In addition to the standard logs, such as the System Log, the Security Log, and the Application Log, Server 2008 allows for these custom logs. There are new Windows logs, but the category of logs you will want to take advantage of are the Applications and Services Logs. These logs collect data from an application (or service component). In Windows Server documentation, you may see this termed “crimson channel logging.” To set up the logging of Exchange-related events as part of crimson channel logging, you can view or configure the Application and Services Logs entry as shown in the following table.
292
Monitoring Using Event Viewer
These steps are performed in Event Viewer and do not require any PowerShell cmdlets. NOTE
Open Event Viewer, expand Applications and Services Logs, expand Microsoft, expand Exchange, and select either HighAvailability or MailboxDatabaseFailureItems, depending on the category of event you want to monitor, as shown in Figure 24-3. The HighAvailability crimson channel will contain events related to startup and shutdown of the Microsoft Exchange Replication service, which will include Active Manager–related events for the DAG. NOTE
The MailboxDatabaseFailureItems crimson channel will contain events related with replicated mailbox database failures.
Figure 24-3
Monitoring a DAG using Event Viewer
Figure 24-4 shows a High Availability error that occurred on Romac-EX4.
Monitoring Using PowerShell Scripts
Figure 24-4
293
DAG Member Server High Availability error as seen from Event Viewer
Monitoring Using PowerShell Scripts Finally, two scripts are provided by Microsoft as a part of Exchange Server 2010 to read a DAG member’s event logs and collect and review data about the health of the DAGs in your organization. The first script is called CollectOverMetrics.ps1 and, as is the case with both scripts, can be found in the Scripts folder in the file system of an Exchange server under the path where Exchange was installed. The CollectOverMetrics.ps1 script reads the DAG member’s event logs and collects some or all of the following information: ■
Identity of the database
■
Start time for the operation
■
Completion time for the operation
■
Mounted copy of database at start of operation
■
Mounted copy of database at completion of operation
■
Purpose of the operation
■
Completion status of the operation
■
Error messages if the operation failed
294
Monitoring Using PowerShell Scripts
This script writes information to a .csv file, with each operation written as a row in the file. An individual .csv file is created for each DAG. You can customize the script to collect only the data that you require, such as information regarding a specific database and all of its copies. The following table shows some examples of ways to customize this script. PS C:\Program Files\Microsoft\ Exchange Server\V14\Scripts\> .\CollectOverMetrics.ps1 -DatabaseAvailabilityGroup RomacDAG -Database:"*DB" -GenerateHTMLReport -ShowHTMLReport
Figure 24-5 script
Uses a wildcard to collect metrics for all databases that match *DB (which would include OfficeDB, ShippingDB, ResearchDB, and the like) in the specified DAG. After the metrics are collected, an HTML report will be generated and displayed, as shown in Figure 24-5.
Resulting HTML report from the running of the CollectOverMetrics.ps1
Other uses for the CollectOverMetrics.ps1 script are shown in the following table. PS C:\Program Files\ Microsoft\Exchange Server\ V14\Scripts\> .\CollectOverMetrics.ps1 -SummariseCsvFiles (dir *.csv) -Database OfficeDB,ShippingDB
Illustrates one way that you could specify a list of databases and have the report summarize only the selected databases.
Filters the report in a different way, filtering out the OfficeDB and any other database name that starts with Office. The -SummariseCSVFiles option specifies a list of .csv files to generate a summary report. NOTE
The other script is called CollectReplicationMetrics.ps1, and it collects data from one or more Mailbox servers. Data that can be collected using this script includes the name of the DAG from which you want to collect metrics, the list of databases the report will include (wildcards characters are supported), an email alias to which the report should be sent, the folder used to store the results of this script, the amount of time the collection process should run, and the frequency at which the data is collected. This script writes each server’s data to a .csv file and can summarize the information about one or more servers in a report. You can specify an individual server, or you can specify the entire DAG. Behind the scenes, the script starts PowerShell jobs to collect relevant data from each server, as shown in the following table. PS C:\Program Files\Microsoft\ Exchange Server\V14\Scripts\> .\CollectReplicationMetrics.ps1 -DagName RomacDAG -Duration "02:00:00" -Frequency "00:01:00" –ReportPath "C:\Logs"
Collects data from servers in the specified DAG for 2 hours and then generates a summary report. The use of the -ReportPath parameter tells the script to save the files to the specified directory.
TIP If you’re not running a monitoring solution such as SCOM, you can create a Windows scheduled task to automate and schedule the execution of these scripts.
This page intentionally left blank
CHAPTER 25
Public Folder Database Management
This chapter provides information and commands concerning the following topics: ■
Installing public folders
■
Creating a public folder database
■
Configuring a public folder database
■
Removing a public folder database
In this chapter, you work with public folder databases. You see how to create a database during the installation of your first mailbox server, create a database after installation of your mailbox server, retrieve information and configure your public folder databases, and then see how to remove a public folder database.
Installing Public Folders If you installed Exchange 2010 using Setup.exe, on the first mailbox server, you were asked the question shown in Figure 25-1. If you answered “No” to the question indicating that you had no Outlook 2003 or Entourage clients, no public folder database was installed on the first server and you were never asked that question again during subsequent installations in your organization. As you will see, however, you can very easily create a public folder database even though none was created for you during setup. On the other hand, if you answered “Yes” to the question, Exchange 2010 created a public folder database on the Mailbox server because both Outlook 2003 and Entourage require public folders. For these clients, a public folder database is required in order for them to connect to Exchange 2010. Public folders provide free/busy information, which is stored in a dedicated system folder called SCHEDULE+FREE BUSY. The OAB distribution point for these clients is also provided by the public folder. However, all Exchange public folder requirements are removed for Outlook 2007 and later clients. Public folders remain in Exchange Server 2010 for business-related reasons rather than Exchange- and Outlook-related reasons.
298
Creating a Public Folder Database
Figure 25-1
Question presented during setup asking if Outlook 2003 or Entourage cli-
ents are present in the organization
Creating a Public Folder Database To create a public folder database using Exchange Management Shell (EMS), you would use the cmdlet New-PublicFolderDatabase, as shown in the following table. PS C:\Users\Administrator> New-PublicFolderDatabase "HR" -Server Romac-EX1 PS C:\Users\Administrator> New-PublicFolderDatabase "Projects" -Server Romac-EX3HC PS C:\Users\Administrator> Mount-Database "HR" PS C:\Users\Administrator> Mount-Database "Projects"
These examples create two public folder databases on the specified servers using the default locations for the database files and logs.
These examples mount the two databases from the first group of examples.
According to Microsoft, it is considered to be a best practice to place the database on a drive or LUN that’s separate from the transaction logs. NOTE
Configuring a Public Folder Database Configuring public folder databases using Exchange Management Shell can be performed using the Set-PublicFolderDatabase cmdlet. Not a lot of configurations are necessary for a database; however, you may want to put quotas on the database to restrict posting to the public folders in the database after the size of a folder reaches the specified limit. (The quota can be set to a value from 0 to 2,097,151MB, or 2TB). You can set the maximum item size to limit the maximum size of items users can post to the public folders in the database. You can also change settings such as the Deleted Item retention period for the database, as well as configure the maintenance schedule to perform maintenance on the database only during off-peak hours. To view the configuration settings of your database, you can use the GetPublicFolderDatabase cmdlet, as shown in the following table. PS C:\Users\Administrator> Set-PublicFolderDatabase Marketing -IssueWarningQuota 1500MB -ProhibitPostQuota 2GB
Changes the quota for the specified public folder database and also configures a warning to be issued when folders in the database reach the specified limits, as shown in Figure 25-2. From EMS, you can use MB or GB, but it will be converted to KB in the EMC. NOTE
300
Configuring a Public Folder Database
Figure 25-2
Quotas set on public folder database as seen from EMC
Allows you to view all of the properties for an individual public folder database in your organization. Figure 25-3 shows the properties that were changed with the preceding examples. NOTE
Using the Get-PublicFolderDatabase cmdlet to validate database changes
Removing a Public Folder Database To remove a public folder database, you can use the Remove-PublicFolderDatabase cmdlet, as shown in the following table. PS C:\Users\Administrator> Remove-PublicFolderDatabase -Identity Projects -Confirm:$false
Removes the specified public folder database.
This page intentionally left blank
CHAPTER 26
Managing Public Folders
This chapter provides information and commands concerning the following topics: ■
Assigning a default public folder database to a mailbox database
■
Creating and managing public folders
■
Replicating public folders
■
Removing a public folder
In this chapter, you first assign a new default public folder database to a mailbox database, and then you create public folders in the public folder databases that you created in the preceding chapter. You replicate folders from one Mailbox server to another, and, finally, you see how to remove a public folder or a public folder replica when it is no longer required.
Assigning a Default Public Folder Database to a Mailbox Database Once the public folder database exists on a server, a mailbox database is assigned a public folder database as the default database for users with mailboxes on that server. In Figure 26-1, you can see that the ShippingDB mailbox database resides on Romac-EX4. When you navigate to the Client Settings tab on the Properties page of the database, you can see that the HR public folder database has already been assigned as the default.
304
Assigning a Default Public Folder Database to a Mailbox Database
Figure 26-1
Default public folder database for users with mailboxes in the ShippingDB
The Outlook client opens a connection to the default public folder database (in this case, HR) and uses it for all operations that require connecting to a public folder. These operations might be simply viewing public folders and content, but they may also include creating and deleting public folders, as well as querying for the location of public folder content. HR may not be the appropriate public folder database for the ShippingDB users to use as their default database and therefore might need to be changed. For example, the shippers need to collaborate with the Marketing department to coordinate shipping products to correspond with a new marketing campaign. Therefore, you would like the Marketing public folder to be the default database for users with mailboxes in the ShippingDB mailbox database, as shown in the following table. PS C:\Users\Administrator> Set-MailboxDatabase -Identity "ShippingDB" -PublicFolderDatabase "Marketing"
Sets the specified public folder database as the default public folder database for the mailboxes in the ShippingDB, as seen in Figure 26-2.
Creating and Managing Public Folders
Figure 26-2
305
Setting a new public folder database for users with mailboxes in the
ShippingDB
Creating and Managing Public Folders Now that the public folder database exists and you have configured the mailbox database with a new public folder database, it is a simple matter to create a public folder. Then, after you create the folder, you can mail-enable it, as shown in the following table. PS C:\Users\Administrator> New-PublicFolder -Name "\Marketing Department Shipping Strategy" -Server "Romac-EX4"
These examples create two public folders on the specified server.
Creates the specified public folder in the existing public folder 2009 Marketing Strategy on the specified Mailbox server. Figure 26-3 shows the public folders created in the preceding examples.
306
Creating and Managing Public Folders
Figure 26-3 Public folders as seen from the Public Folder Management Console (accessed from EMC)
Mail-enabling a public folder involves running the Enable-MailPublicFolder cmdlet. Setting a specific SMTP address for the public folder consists of turning the email address policy off for the specific public folder and then specifying a custom SMTP address. Disabling mail to a public folder can be achieved by running the DisableMailPublicFolder cmdlet, as shown in the following table. PS C:\Users\Administrator> Enable-MailPublicFolder -Identity "\Marketing Department Shipping Strategy"
These examples mail-enable the specified public folders.
Disables the email address policy of the specified mail-enabled public folders so that you can set custom email addresses for them independent of any email address policy in your organization.
Replicating Public Folders To create a public folder replica using Exchange Management Shell, you can use the cmdlet Set-PublicFolder with the -Replicas parameter, as shown in the following table. PS C:\Users\Administrator> Set-PublicFolder -Identity "\Marketing Department Shipping Strategy" -Replicas Marketing, HR
These examples replicate the specified folders to the specified public folder databases.
Sets the specified public folder so that it replicates only on Sunday. Figure 26-4 shows the result of this command.
308
Removing a Public Folder
Figure 26-4 Public folder replication schedule as seen from the Public Folder Management Console (accessed from EMC)
Removing a Public Folder You can use the Remove-PublicFolder cmdlet to remove the public folder data from all servers in your organization. If you only want to remove data from one server, you can use the Set-PublicFolder cmdlet with the -Replicas parameter, as shown in the following table. PS C:\Users\Administrator> Remove-PublicFolder -Identity "\2009 Marketing Strategy\ Year End Push" -Confirm: $false PS C:\Users\Administrator> Remove-PublicFolder -Identity "\2009 Marketing Strategy" -Confirm: $false PS C:\Users\Administrator> Set-PublicFolder -Identity "\Marketing Department Shipping Strategy" -Replicas Marketing
These examples remove the specified public folders and all replicas from the databases that hold replicas. A public folder must be empty before you can remove it. NOTE
Removes only the replica of the specified public folder that exists in the HR database. The Marketing database replica will be preserved.
CHAPTER 27
Public Folder Permissions
This chapter provides information and commands concerning the following topics: ■
Adding administrative permissions to the folder structure
■
Controlling top-level public folders
■
Setting client permissions to public folder content
In this chapter, you investigate public folder permissions. You look at administrative permissions to the public folder structure (hierarchy) and then you investigate how to set content permissions for both administrators and clients. You also look at top-level public folders and observe the importance of configuring permissions on them to lock down the public folder hierarchy.
Adding Administrative Permissions to the Folder Structure You cannot use Exchange Management Console (EMC) to add administrative permissions for an administrator to access the public folder hierarchy. Exchange Management Shell (EMS) can be used to assign administrative permissions. You can use the AddPublicFolderAdministrativePermission cmdlet to add administrative permissions to a public folder or a public folder hierarchy. When you use the Add-PublicFolderAdmin istrativePermission cmdlet with the -AccessRights parameter, you can set permissions on public folders and the hierarchy. The following table shows a number of options for this cmdlet. Option
Description
None
The administrator cannot modify any of the public folder attributes.
ModifyPublicFolderACL
The administrator can modify client access permissions for the specified folder.
ModifyPublicFolderAdminACL
The administrator can modify administrator permissions for the specified public folder.
310
Adding Administrative Permissions to the Folder Structure
Option
Description
ModifyPublicFolderDeletedItemRetention
The administrator can modify the Public Folder Deleted Item Retention attributes, which include the RetainDeletedItemsFor and the UseDatabaseRetentionDefaults attributes.
ModifyPublicFolderExpiry
The administrator can modify the Public Folder Expiration attributes, which include the AgeLimit and UseDatabaseAgeDefaults attributes.
ModifyPublicFolderQuotas
The administrator can modify the Public Folder Quota attributes, which include the MaxItemSize, PostQuota, PostWarningQuota, and UseDatabaseQuotaDefaults attributes.
ModifyPublicFolderReplicaList
The administrator can modify the replicas for the specified public folder using the -Replicas attribute for the Set-PublicFolder cmdlet.
AdministerInformationStore
The administrator can modify any other public folder property not previously listed.
ViewInformationStore
The administrator can view the public folder’s properties but cannot modify any of them.
AllExtendedRights
The administrator can modify all public folder properties.
These examples illustrate how to set administrative permissions on public folders. In order for you to perform these tasks as shown, you need the users Joyce and Maureen, which were created in an earlier chapter, and a new user named Jeanna. You also have to create a public folder database named “Policies” on Romac-EX2 as well as a parent public folder named “Company Policies” and two child folders named “US Polices” and “Canada Policies.” NOTE
The permission assignments in the following table illustrate that permissions are set on specific public folders and do not inherit unless specified. PS C:\Users\Administrator> Add-PublicFolderAdministrativePermission -User Maureen -Identity "\Company Policies" -AccessRights ViewInformationStore
Grants Maureen the ViewInformationStore permission for the specified public folder, as seen in Figure 27-1.
Adding Administrative Permissions to the Folder Structure
Denies the specified user the ViewInformationStore permission for the specified public folder, as seen in Figure 27-1.
Administrative permissions to a public folder structure with no inheritance
Maureen is given permission to the Company Policies public folder, but was not given permission to the US Policies public folder because no inheritance was specified. She was also specifically denied access to the Canada Policies public folder. NOTE
The permission assignment shown in the following table illustrates that permissions can be set on a specific public folder and inheritance can be specified. PS C:\Users\Administrator> Add-PublicFolderAdministrativePermission -User Jeanna -Identity "\Company Policies" -AccessRights AllExtendedRights -InheritanceType SelfAndChildren
Grants the specified user the AllExtendedRights permission for the specified public folder and all child public folders under it, as seen in Figure 27-2.
312
Setting Client Permissions to Public Folder Content
Figure 27-2
Administrative permissions to a public folder structure with inheritance
Jeanna is given permission to the Company Policies public folder, and because inheritance was specified she has permission to both the US Policies and the Canada Policies public folders. NOTE
Controlling Top-level Public Folders It is important to restrict top-level public folder creation and management to a select group of administrators. This can be done by controlling the root of the database and setting inheritance as shown in the following table. If you don’t control top-level public folders, you will end up with a very shallow hierarchy with many different folders being placed directly under the root. By controlling the top level, you can have a much more organized hierarchy based on geography, departments, or any other organizational configuration you might need. PS C:\Users\Administrator> Add-PublicFolderAdministrativePermission -User Administrator -Identity "\" -AccessRights AllExtendedRights -InheritanceType SelfAndChildren
Grants the specified user the AllExtendedRights permission for the root and all child public folders under it.
Setting Client Permissions to Public Folder Content In Exchange Server 2010 Service Pack 1, you can set client permissions using the Public Folder Management Console. This is new to Service Pack 1. Previously, you could use either Exchange Management Shell or Microsoft Office Outlook to do this. When you use the Add-PublicFolderClientPermission cmdlet with the -AccessRights parameter, you can set client permissions on public folders and their contents. The following table shows a number of options for this cmdlet. Option
Description
ReadItems
The user can read items within the specified public folder.
CreateItems
The user can create items within the specified public folder.
Setting Client Permissions to Public Folder Content
313
Option
Description
EditOwnedItems
The user can edit items that he or she owns in the specified public folder.
DeleteOwnedItems
The user can delete items that he or she owns in the specified public folder.
EditAllItems
The user can edit all items in the specified public folder.
DeleteAllItems
The user can delete all items in the specified public folder.
CreateSubfolders
The user can create subfolders in the specified public folder.
FolderOwner
The user can view and move the public folder and create subfolders, but cannot necessarily read items, edit items, delete items, or create items in the folder.
FolderVisible
The user can view the specified public folder but cannot necessarily read or edit items within the folder.
The following table shows how to set client permissions using Exchange Management Shell. PS C:\Users\Administrator> Add-PublicFolderClientPermission -Identity "\Company Policies" -User Maureen -AccessRights ReadItems
This example adds the permission for the user Maureen to read items in the public folder called Company Policies.
This example adds multiple permissions for the user Jeanna. She can create items, edit items, and delete items in the public folder called Company Policies.
This permission is equivalent to the Reviewer role, so Maureen is automatically added as a reviewer, as shown in Figure 27-3. NOTE
This permission has no equivalent role, so Joyce is shown as having “Custom” permissions. NOTE
This combination of permissions has no equivalent role, so Jeanna is shown as having “Custom” permissions. NOTE
The three permission configurations set in the previous table are shown Figure 27-3. You can also set permissions based on roles, which include multiple access rights. The following table details the available roles in Exchange 2010 and which client permissions are associated with those roles.
314
Setting Client Permissions to Public Folder Content
Figure 27-3
Client permissions as viewed from Microsoft Office Outlook 2010
Permissions set using the preceding roles are most easily configured using the Microsoft Office Outlook client. NOTE
CHAPTER 28
Troubleshooting with the Test Cmdlets
This chapter provides information and commands concerning the following topics: ■
Using Test cmdlets for all roles
■
Using Test cmdlets for the Mailbox role
■
Using Test cmdlets for the Transport roles
■
Using Test cmdlets for the Client Access Server role
■
Using Test cmdlets for the Unified Messaging role
■
Using Test cmdlets for client connectivity
■
Using helpful non-Exchange Test cmdlets
Starting with Exchange Server 2007 and continuing in Exchange 2010, a series of cmdlets is available that use the verb “Test.” These cmdlets are designed to diagnose and troubleshoot Exchange systems that are having problems or to validate whether those systems are in fact healthy. In this chapter, you investigate some of these Test cmdlets as they apply to each Exchange Server role.
Using Test Cmdlets for All Roles As shown in the following table, the Test-ServiceHealth cmdlet is a very handy tool to remember when you are troubleshooting servers. PS C:\Users\Administrator> Test-ServiceHealth
Tests whether all the Windows services that Exchange requires on a server are started. This cmdlet separates services by role and returns an error when any service required by that role has stopped. Figure 28-1 shows a successful completion of the test. TIP You can run this against a remote server by using the -Server switch.
316
Using Test Cmdlets for All Roles
Figure 28-1
The Test-ServiceHealth cmdlet with no errors
Next, stop the Microsoft Exchange Transport Service and rerun the cmdlet (as shown in the following table). PS C:\Users\Administrator> Test-ServiceHealth
In this example, the Transport Service is not running, and this will appear as an error in the output, as shown in Figure 28-2. (Don’t forget to start the service when you are finished.)
Other “Test” cmdlets that may be used on all roles include those shown in the following table.
Using Test Cmdlets for the Mailbox Role
317
Figure 28-2 The Test-ServiceHealth cmdlet with an error (Microsoft Exchange Transport Service stopped)
PS C:\Users\Administrator> Test-SystemHealth
Collects data in the Exchange system and analyzes it against Microsoft best practices. This cmdlet checks for updates from the Internet. NOTE
Performs the same tests but produces a more detailed output.
Using Test Cmdlets for the Mailbox Role One Mailbox role cmdlet you can use is the Test-ReplicationHealth cmdlet. As shown in the following table, this cmdlet tests the replication and replay status for a specific Mailbox server in a DAG. It checks the availability of the Active Manager as well as the status of the underlying cluster service.
Allows you to check the replication and transaction replay status of a database copy. The successful completion of this cmdlet is shown in Figure 28-3. NOTE
Successful run of the Test-ReplicationHealth cmdlet
Using Test Cmdlets for the Transport Roles As shown in the following table, several important Test cmdlets are available for transport servers. The first tests Edge Synchronization of a Hub Transport server to an Edge Transport server. Others test the spam-filtering capabilities of the built-in spam filters and the mailflow in the transport pipeline. PS C:\Users\Administrator> Test-EdgeSynchronization
Tests the Edge Synchronization process and produces a report showing the synchronization status of subscribed Edge Transport servers.
Tests the settings for the specified IP Allow list provider on a Hub Transport or Edge Transport server. This configuration is used by the Connection Filter agent, one of the builtin spam filters on Hub Transport and Edge Transport servers.
Tests the settings for the specified IP Block list provider on a Hub Transport or Edge Transport server. This configuration is used by the Connection Filter agent, one of the builtin spam filters on Hub Transport and Edge Transport servers.
Tests the IRM configuration for messages sent from the specified sender. Performs a series of tests to determine IRM functionality. Information Rights Management (IRM) is a file-level technology from Microsoft that restricts content from being printed, forwarded, or copied by unauthorized recipients. The restrictions follow the email message as part of the contents of the file. NOTE
Tests whether mail can be successfully sent from and delivered to the system mailbox on a computer that has the Mailbox server role installed, as seen in Figure 28-4. Even though this cmdlet tests mailbox-to-mailbox mailflow, it is actually testing the latency of the transport mechanism and will produce a latency value you can use to compare against an acceptable latency threshold. NOTE
Figure 28-4 Output of a Test-Mailflow cmdlet checking mailflow between Romac-EX1 and Romac-EX2
320
Using Test Cmdlets for the Client Access Server Role
Using Test Cmdlets for the Client Access Server Role Several important Test cmdlets are also available for testing Client Access Servers. As shown in the following table, these cmdlets can test client connectivity to the Client Access Server, Exchange services status on the Client Access Server, whether the PowerShell remoting capability is functioning correctly, and so on. Use the following script to create the required user for the test: PS C:\Program Files\Microsoft\ Exchange Server\V14\Scripts> .\New-TestCasConnectivityUser.ps1
Then run the cmdlet: PS C:\Users\Administrator> Test-WebServicesConnectivity
TIP Before executing the TestWebServicesConnectivity cmdlet, run the script NewTestCasConnectivityUser.ps1 to create a user that the cmdlet uses to test connectivity.
Tests the functionality of Exchange Web Services (EWS) on a server that has the Client Access Server role installed. Exchange Web Services replaces many of the features found in WebDAV, CDOEX, and ExOLEDB, thus potentially reducing problems with applications requiring these earlier APIs. NOTE
Tests the health of an instance of the Mailbox Replication service on one or more Client Access Servers. In the example, you test all Client Access Servers.
Tests whether Windows PowerShell remoting on a Client Access Server is functioning correctly. This example tests the PowerShell (Default Web Site) virtual directory on the specified server. The switch -TrustAnySSLCertificate is used to skip the certificate check during connection. NOTE
TIP This cmdlet uses the same user account created when you ran the script NewTestCasConnectivityUser.ps1 previously.
Using Test Cmdlets for Client Connectivity
321
Tests for a connection to each service (note that quite a few are tested).
It also submits a request to the Availability service for the specified user to determine whether the user’s free/busy information is being returned correctly from the Client Access Server to the Outlook client.
Using Test Cmdlets for the Unified Messaging Role As shown in the following table, you can test functionality of a Unified Messaging server with the Test-UMConnectivity cmdlet. PS C:\Users\Administrator> Test-UMConnectivity
Tests the functionality of a computer that has the Unified Messaging (UM) server role installed. This cmdlet tests the functionality of a Unified Messaging server and related connected telephony equipment. You can test full end-to-end operation of the Unified Messaging system or test only the operation of the Unified Messaging components on the Exchange server.
Using Test Cmdlets for Client Connectivity You can use a number of the Test cmdlets to verify client connectivity. As shown in the following table, many of the client connection protocols have a cmdlet designed to test connectivity. PS C:\Users\Administrator> Test-ActiveSyncConnectivity -ClientAccessServer Romac-EX2 -URL http://mail.romacsign.com/ Microsoft-Server-ActiveSync -MailboxCredential:(Get-Credential romacsign\maureen)
Initiates a full synchronization against the specified mailbox to test the configuration of Exchange ActiveSync.
PS C:\Users\Administrator> Test-EcpConnectivity
Verifies that the Exchange Control Panel is running normally.
You are presented with a logon prompt for the specified user during this test. NOTE
Tests connectivity to all databases on the specified server.
You are presented with a logon prompt for the specified user during this test. NOTE
Dismount the AssemblyDB database and run the test again. The results of both tests are shown in Figure 28-5. (Don’t forget to mount the database after the test.)
Figure 28-5 Successful and failed Test-MapiConnectivity tests as seen from Exchange Management Shell
Other client connectivity tests include those shown in the following table. PS C:\Users\Administrator> Test-MapiConnectivity -Identity "romacsign\maureen"
Tests the POP3 connectivity for the specified Client Access Server using the credentials for the specified user.
You are presented with a logon prompt for the specified user during this test. NOTE
You are presented with a logon prompt for the specified user during this test. NOTE
Using Helpful Non-Exchange Test Cmdlets The following table shows two Test cmdlets that might come in handy. PS C:\Users\Administrator> Test-Path -Path "C:\Program Files\ Microsoft\Exchange Server\V14\Mailboxes\ ShippingDB"
Validates the existence of a path in the file system and could be incorporated into a script to check for a folder before something is put into it. Shows a successful discovery of an existing path. Output is True.
PS C:\Users\Administrator> Runs the same cmdlet and shows a result where the path does not exist. Test-Path -Path "C:\Program Files\ Output is False. Microsoft\Exchange Server\V14\ Mailboxes\ShippingPublicFolder" PS C:\Users\Administrator> Test-Connection Romac-EX1
Figure 28-6
Functions like Ping does from a command prompt, sending ICMP echo request packets to remote hosts, as shown in Figure 28-6.
“Pinging” with the Test-Connection cmdlet
This page intentionally left blank
CHAPTER 29
Event Logging with PowerShell
This chapter provides information and commands concerning the following topics: ■
Retrieving events with Get-EventLog
■
Setting diagnostic Event Log levels
Management of Event Logs from PowerShell can be beneficial to an Exchange administrator. The Get-EventLog cmdlet illustrates some of the options available to you. By changing the Diagnostic Event Log level, you can adjust the amount of Exchange information logged while you are troubleshooting.
Retrieving Events with Get-EventLog You can retrieve events from an Event Log on a local or remote computer using Exchange Management Shell. You can use the Get-EventLog cmdlet to search for events in one or more logs by using their property values. Get-EventLog retrieves only events from the traditional Windows Event Logs (that is, the System Log, Application Log, and Security Log). To get events from some of the newer Windows Event Logs in Windows Server 2008, you can use Get-WinEvent. NOTE
The following table shows some ways to use this cmdlet. PS C:\Users\ Administrator> Get-EventLog -List
Figure 29-1
Retrieves information about the available Windows Event Logs, including the number of entries, the maximum allowed size of the log, and whether entries will be retained for any period of time, as shown in Figure 29-1.
Retrieves and displays the specified number of most recent events with a Source value of MSExchange Unified Messaging, as shown in the upper half of Figure 29-2.
Retrieves and displays the specified number of most recent events with an -EntryType value of Error from a remote computer. You would run this from your workstation or another server. The example was run from Romac-EX2. NOTE
Retrieves and displays the specified number of most recent events with an -EntryType value of Error from a local and a remote computer. The cmdlet displays only the specified information, as shown in Figure 29-3. NOTE
Finding specific events from a list of recent events on multiple computers
The Application Log was used in these examples because many Exchangerelated events are logged there, but these examples could be used on other Windows Event Logs as well. NOTE
Setting Diagnostic Event Log Levels You can set Diagnostic Event Log levels to collect more or less information than the default levels allow. You would do this while troubleshooting Exchange servers and then you would return the log levels to their defaults. The following table shows how to view the default log levels. PS C:\Users\Administrator> Get-EventLogLevel
Displays all logged items’ logging levels.
The following table lists some of the available log information and the default log levels. MSExchange ActiveSync\Requests
Lowest
MSExchange ActiveSync\Configuration
Lowest
MSExchange Autodiscover\Core
Lowest
MSExchange Autodiscover\Web
Lowest
MSExchange Availability\Availability Service
Lowest
MSExchange Configuration Cmdlet - Management Shell\ General
MSExchange Configuration Cmdlet - Control Panel\ General
Lowest
MSExchange Configuration Cmdlet - Control Panel\RBAC
Lowest
MSExchange EdgeSync\Synchronization
Lowest
MSExchange EdgeSync\Topology
Lowest
MSExchange TransportService\TransportService
Lowest
MSExchange Messaging Policies\Journaling
Lowest
MSExchange Messaging Policies\Rules
Lowest
MSExchange Mailbox Replication\Service
Lowest
MSExchange Mailbox Replication\Mailbox Move
Lowest
MSExchangeIS\9001 Public\Send On Behalf Of
Lowest
MSExchangeIS\9001 Public\Send As
Lowest
MSExchangeTransport\Agents
Lowest
Setting Diagnostic Event Log Levels
329
These are just a few of the categories that are logged. You can change the logging level as shown in the following table. PS C:\Users\Administrator> Set-EventLogLevel -Identity "MSExchange Messaging Policies\Rules" -Level High
Changes the log level for the specified log to High, as shown in Figure 29-4. NOTE
Valid log levels are as follows:
■
Lowest Only—Critical events, error events, and events with a logging level of 0 are logged. This is the default level.
■
Low—Events with a logging level of 1 or lower are logged.
■
Medium—Events with a logging level of 3 or lower are logged.
■
High—Events with a logging level of 5 or lower are logged.
■
Expert—Events with a logging level of 7 or lower are logged.
Allows you to view the logging level for the specified log, as shown in Figure 29-4.
Configuring an Event Log level
This page intentionally left blank
CHAPTER 30
Using and Finding Scripts to Automate
This chapter provides information and commands concerning the following topics: ■
Using scripts to automate tasks in PowerShell
■
Finding scripts to automate tasks in PowerShell
In this chapter, you use some of the scripts that ship with Exchange Server 2010 and investigate how to find locations that have scripts that you can download and use for various purposes.
Using Scripts to Automate Tasks in PowerShell PowerShell scripts are cmdlets that are “batched” together as lines of code written in the PowerShell scripting language, not unlike a .bat or .cmd file. These files have the .ps1 extension (yes, even in PowerShell 2.0, they still use the .ps1 extension), but they are executed by Windows PowerShell instead of the Windows cmd.exe or command.com. In PowerShell 2.0, you can even execute a script by right-clicking the file and selecting the Run with PowerShell option. In Exchange Server 2007 with PowerShell 1.0, you had to run scripts from a PowerShell prompt. NOTE
These “batched” cmdlets allow you to perform very complex tasks, such as installing all the built-in anti-spam agents using a single .ps1 file called install-AntispamAgents.ps1. You should use caution when executing .ps1 scripts, because they can access critical Windows operating system components as well as critical Exchange Server components. A number of preconfigured .ps1 files are located under the Exchange installation directory, which by default is located at C:\Program File\Microsoft\Exchange Server\V14\ Scripts. You must include the path when running a .ps1 file, but if the focus of Exchange Management Shell (EMS) is on the directory that the file is located in, you may use “.\” to indicate that the file should be run from the current directory, as shown in the following table. The following table also shows some of the more interesting .ps1 files that come with Exchange Server.
Runs a script that attempts to fix two types of errors. First, if the recipient has multiple SMTP addresses listed as primary or if the primary SMTP is invalid, the script will try to set the WindowsEmailAddress as the primary SMTP address. Second, if a distribution group has the HideDLMembershipEnabled attribute set to true, but ReportToManagerEnabled, ReportToOriginatorEnabled, or SendOofMessageToOriginatorEnabled are also set to true, then the membership may not be truly hidden. The script will set the appropriate attributes to false to fix the distribution group.
Runs a script that allows an administrator to extract server and end-to-end latency information from the messagetracking log.
PS C:\Program File\Microsoft\ Runs a script that exports Message Classifications to an XML file that can Exchange Server\V14\Scripts> .\Export-OutlookClassification.ps1 be imported by Outlook 2007, so that
Outlook 2007 clients may classify messages for use with transport rules. Outlook will not support the use of message classifications unless the .xml file created by this cmdlet is imported on the client. NOTE
Runs a script that either attempts to reseed the database on the specified server or attempts to reseed all of the failed or suspended databases on the server.
Similar to the Move-Mailbox cmdlet in Microsoft Exchange Server 2007. Provides a synchronous management experience for moving mailboxes, but will move local mailboxes only. Runs a script that first creates a local move request, then waits as the mailbox is moved, and finally clears the move request after the move has completed.
Runs a script that creates a user, as shown in Figure 30-2, that can be used for testing connectivity by using some of the Test cmdlets, as covered in Chapter 28, “Troubleshooting with the Test Cmdlets.”
Figure 30-2 User created with a .ps1 script for testing purposes, as seen from Active Directory Users and Computers
Runs a script that resumes a mailbox database copy when it has been previously suspended.
Finding Scripts to Automate Tasks in PowerShell Many websites and blog sites offer .ps1 file scripts for download. Microsoft.com has the Script Center Repository as part of TechNet. This is a fantastic place to start looking for scripts. Chances are, you aren’t the first person to ask whether PowerShell can do some particular task—others have had to either figure it out for themselves or find someone with PowerShell skills to do it for them. If you are lucky, the script you need already exists in the Script Center Repository. Most of these sites do not charge anything for their scripts and provide helpful information on how they function. The drawback, however, is that most of these sites are not Exchange specific. Also, these sites do not guarantee that their scripts will function properly in your environment. When you’re working with a new or untrusted cmdlet, three switch options are available that allow you to reduce or prevent unintended results from occurring when you execute the cmdlet. You can use the -Whatif switch wherever possible to see what would happen if the script were run...before you actually run it for real! No changes are made to any Exchange objects when you execute a cmdlet with a -Whatif switch applied. The -Whatif switch is available in many cmdlets, and using it might just protect you from executing a script that permanently damages your Exchange organization. The -Whatif switch must be added to the actual cmdlet as an attribute, as shown in the following table. NOTE
Sets quotas for all mailboxes in the Management OU. With the use of the -Whatif switch, the change will be simulated, but will not actually take effect. NOTE
-UseDatabaseQuotaDefaults $false -Whatif
The -Whatif switch is beneficial for new Exchange administrators, because they can execute an unfamiliar cmdlet in the production environment using a simulated version of the cmdlet. However, this switch can also be useful for seasoned administrators, because they can test familiar cmdlets to determine whether there will be any unintended results when the cmdlets are actually executed. It is common to put the -Whatif switch at the very end of the cmdlet. You could then use the up arrow, backspace over -Whatif, and reexecute the cmdlet.
336
Finding Scripts to Automate Tasks in PowerShell
You can also use the -Confirm switch to avoid unintentional modification to Exchange objects. By default, EMS automatically applies the -Confirm switch to cmdlets that have the following verbs: ■
Clear
■
Disable
■
Dismount
■
Move
■
Remove
■
Stop
■
Suspend
■
Uninstall
When a cmdlet runs that includes any of these verbs, EMS stops execution of the cmdlet and waits for your acknowledgement before it continues to execute the cmdlet. As shown in the following table, there are several possible responses to a -Confirm confirmation prompt that states “Are you sure you want to perform this action?” Y (Yes)
Instructs the cmdlet to continue the operation. The next operation will present another confirmation prompt. NOTE
A (Yes to all) N (No) L (No to all) S (Suspend) ?
This is the default option.
Instructs the cmdlet to continue the operation and all subsequent operations. You will not receive any additional confirmation prompts for the duration of this command. Instructs the cmdlet to skip this operation and continue with the next operation. The next operation will present another confirmation prompt. Instructs the cmdlet to skip this operation and all subsequent operations. You will not receive any additional confirmation prompts for the duration of this command. Pauses the current pipeline and returns to the command line. You may type Exit to resume the pipeline. Displays the confirmation prompt Help on the command line.
(Help)
You can also manually use the -Confirm switch in a cmdlet, as shown in the following table.
Overrides the default option (Yes) and, in this example, deletes the specified mailbox with no prompting.
Finally, you can use the -ValidateOnly switch. This switch instructs the cmdlet to evaluate all of its conditions and requirements before making any changes. The -ValidateOnly switch is available (and most useful) on cmdlets that potentially could take a long time to execute. When you use the -ValidateOnly switch in a cmdlet, the cmdlet runs through the whole process, performing each step, as if it were actually executing. But no changes are actually being made. When the cmdlet completes its execution, it displays a summary of the results. If the summary shows no errors, you can run the cmdlet again without the -ValidateOnly switch. The use of the -ValidateOnly switch is shown in the following table. PS C:\Users\Administrator> Get-Mailbox "RomacSign\Madge" | New-MoveRequest -TargetDatabase "ManagementDB" -ValidateOnly
Evaluates all conditions and requirements for moving the specified mailbox to the specified location.
The -Whatif, -Confirm, and -ValidateOnly switches are often most valuable when used together with a Get statement and a pipeline to another cmdlet. This allows you to specifically modify the items returned by the Get command and yet still have control over which items will be modified. By adding some of these switches to your scripts, you may avoid the scripts stopping execution while awaiting a response at a prompt.
This page intentionally left blank
CHAPTER 31
Configuring Role-Based Access Control (RBAC) Permissions
This chapter provides information and commands concerning the following topics: ■
Creating and managing a management role group
■
Adding members to the management role group
■
Retrieving information about role groups and role group members
■
Setting and viewing management scopes
In this chapter, you review setting permissions using Role-Based Access Control (RBAC). After the management role groups have been created and the roles have been assigned, permissions are easily set either using PowerShell or through GUI-based tools. This chapter provides an overview of how to configure management role groups, assign management roles to those groups, add role group members, and view information about existing role groups and role group members.
Creating and Managing a Management Role Group A number of built-in management role groups are present in Exchange 2010. For example, Recipient Management, Organization Management, and Records Management are three such management role groups present by default. In this section, you investigate how to create a custom role group. The ability to import and export to and from a mailbox is not assigned to any user or group by default. The Mailbox Import Export management role allows you to import and export mailbox content as well as delete undesirable content from a user’s mailbox or from an administrative mailbox if you have recalled a message. This example illustrates Role-Based Access Control (RBAC) permissions in Exchange Server 2010. Management roles are assigned to one or more management role groups, similar to the way permissions are assigned to groups in Windows. One significant difference is that there are approximately 70 Exchange-specific management roles compared to the delegated permission assignment of previous versions of Exchange Server. Rather than assigning the permission for a user to print as you would in Windows, you assign the management role to a management role group in Exchange 2010. This provides flexibility in assigning permissions and a level of granularity for assigning permissions not seen in previous versions of Exchange Server. A second difference is that if you do not have the permission to do something, the cmdlet will appear to be unavailable in EMS or the option will not be present in Exchange Management Console (EMC) or in Exchange Control Panel. For example, if you want to export content from a mailbox and you do not have the Mailbox Import Export management role assigned to you, the cmdlet will error with a message stating that the cmdlet does not exist. The following
340
Creating and Managing a Management Role Group
table shows the initial failure of the Export-Mailbox cmdlet and illustrates the creation of a management role group. In Service Pack 1, the Export-Mailbox cmdlet has been replaced with the New-ExportRequest cmdlet, which is discussed further in Chapter 32. NOTE
Creates the management role group that will allow role holders to import or export content to and from a user’s mailbox, as shown in Figure 31-2.
This cmdlet was run by the user Paul Trzaska in the example. Paul does not yet have permission to export mailboxes, so the cmdlet fails. The error is shown in Figure 31-1. NOTE
No members have been added to the management role group at this time. NOTE
Figure 31-1
Mailbox export fails with error, as seen from EMS
The Mailbox Import Export management role will be used again in Chapter 32, “Using Mailbox Audit Logging to Monitor Exchange Server,” to test auditing. NOTE
Adding Members to the Management Role Group
Figure 31-2
341
Creation of the management role group
Another option for the New-RoleGroup cmdlet is to allow the role group members to be assigned at the time of the role group’s creation, as shown in the following table. PS C:\Users\Administrator> New-RoleGroup -Name "Recipient Config" -Roles "Mail Recipients", "Distribution Groups" -Members Jim, Karen
Allows role group members to perform some recipient-level configuration, but does not allow them to create or delete mail recipients. They can, however, create, modify, view, and remove distribution groups, as well as add or remove distribution group members in the organization. NOTE The role group members are added at the time of the role group’s creation in this example.
As shown in the following table, you can remove a management role group with the Remove-RoleGroup cmdlet. PS C:\Users\Administrator> Remove-RoleGroup "Recipient Config"
Removes the specified management role group.
Adding Members to the Management Role Group You can add a member to the newly created management role group in two ways. One way would be by using the Add-RoleGroupMember cmdlet, as shown in the following table. PS C:\Users\ Administrator> Add-RoleGroupMember "MBExporters" -Member Ed
Adds a member to the specified management role group. You can view the result of this cmdlet from Exchange Control Panel, as shown in Figure 31-3. Ed Nichols is now a member of the MBExporters management role group after this cmdlet has been run. This is one way to add a user to the specified management role group. NOTE
342
Adding Members to the Management Role Group
Figure 31-3
Viewing role group members
The following table shows that you can also use the Role-Based Access Control (RBAC) User Editor to add a second user in EMC. 1 Proceed to the Toolbox in Exchange
Management Console and launch the RoleBased Access Control (RBAC) User Editor. 2 Double-click Role-Based Access Control
(RBAC) User Editor and log on as RomacSign\administrator. 3 Click RomacSign\MBExporters and then
click Details. 4 Under Members, click Add, select a user (in
Figure 31-3, the user is Paul Trzaska), add him to the group, and then click OK. 5 Click Save and close the Internet Explorer win-
dow that opened when you launched the RoleBased Access Control (RBAC) User Editor.
This example shows how to open the Role-Based Access Control (RBAC) User Editor. This is another way to add the specified user to a management role group. NOTE
Figure 31-3 also shows that the user added with the Role-Based Access Control (RBAC) User Editor (Paul Trzaska) appears as a member of the role group.
Now that the user Paul Trzaska has been made a member of the MBExports group, he can execute the Export-Mailbox cmdlet that failed earlier. This cmdlet is shown again in the following table, only with a different outcome.
Retrieving Information about Role Groups and Role Group Members
Attempts to export the contents of the specified mailbox to the specified target folder. This cmdlet succeeds now that Paul has the proper permissions, as shown in Figure 31-4. NOTE
Mailbox export now succeeds, as seen from EMS
The Export-Mailbox cmdlet has been replaced in Exchange Server 2010 SP1. The New-ExportRequest cmdlet replaces it and has new features; however, the concept of RBAC holds true with SP1, and an administrator does not have the right to run the cmdlet until he or she is added to a management role group that includes the Mailbox Import Export role entry. NOTE
Retrieving Information about Role Groups and Role Group Members One of the easiest ways to view and manage the management role group membership after it has been created is to use Active Directory Users and Computers. Figure 31-5 shows that a third user has been added to the management role group.
344
Retrieving Information about Role Groups and Role Group Members
Figure 31-5 Computers
Viewing the management role group in Active Directory Users and
TIP The difficult part about working with custom role groups is creating the role groups. Once they are created, though, managing them is very much like other Windows groups. You simply need to add a user to the group to covey Exchange permissions.
Other ways to view information about management role groups and role group members are shown in the following table. PS C:\Users\Administrator> Get-RoleGroupMember "MBExporters"
Uses the Get-RoleGroupMember cmdlet to view the membership of a role group. It retrieves a list of all of the members in the specified role group.
PS C:\Users\ Administrator>Get-RoleGroup
Uses the Get-RoleGroup cmdlet to retrieve a list of all of the management role groups in your organization.
Retrieves only the specified role and passes the output of the Get-ManagementRole cmdlet to the Format-List cmdlet, which shows only the Name and RoleType attributes for the role.
Setting and Viewing Management Scopes You can create a management role group scope using the New-ManagementScope cmdlet. Management role scopes allow you to define what portion of the organization you can manage when you have been granted management rights. For example, you might want an administrator to manage only unclassified servers in the Philadelphia location. You could do this easily by creating a list of servers to be managed. When you apply a scope, the administrator can only work with the objects contained within that scope. You can use a management role group, a management role, a management
346
Setting and Viewing Management Scopes
role assignment policy, a user, or a universal security group with a scope of management. There are two types of scopes: ■
A regular scope, which is not exclusive. This means that if you are a member of more than one role group, you may receive additional permissions from other role groups to which you belong.
■
An exclusive scope, which allows you to deny access to objects contained within the exclusive scope, unless an administrator is specifically assigned a role associated with the exclusive scope.
Administrators can only perform tasks for which they have been granted rights on the servers included in the scope. NOTE
Administrators can perform tasks for all servers located in the Philadelphia Active Directory site. NOTE
When you create an exclusive scope, you receive the following warning: NOTE
“When you create exclusive management scopes, only users or universal security groups that are assigned exclusive scopes that contain objects to be modified will be able to access those objects. Users or USGs that aren’t assigned an exclusive scope that contains the objects will immediately lose access to those objects. Are you sure you want to create the Assemblers Mailboxes exclusive scope?” This example retrieves a list of all exclusive scopes in use within the organization.
CHAPTER 32
Using Mailbox Audit Logging to Monitor Exchange Server
This chapter provides information and commands concerning the following topics: ■
Enabling Mailbox Audit Logging
■
Initiating administrative actions to test Mailbox Audit Logging
■
Initiating a search of the mailbox audit log
In this chapter, you monitor when a delegate accesses another user’s mailbox. It is critical to monitor when someone other than the owner of the mailbox accesses it to determine whether he or she is performing appropriate and acceptable tasks on the mailbox or performing improper actions on the mailbox. This capability is much improved in Exchange 2010 SP1. For example, a CEO may ask a messaging administrator to allow her assistant to be able to send mail as the CEO. This delegation is acceptable if the CEO has approved the action. However, if the messaging administrator were to also give herself “Send As” permissions to the CEO’s mailbox, this would be unacceptable. The CEO did not indicate that she wanted the administrator to have that permission. A new feature called Mailbox Audit Logging allows you to track who logs on to a mailbox in your organization and view what actions are taken on the mailbox. As you will see, Mailbox Audit Logging allows you track three types of user access to another user’s mailbox.
Enabling Mailbox Audit Logging You can use Mailbox Audit Logging in Exchange 2010 SP1 to monitor logons to users’ mailboxes and collect data about their actions, even while they are logged on to their mailboxes. In many cases, you will want to monitor a user’s access to a mailbox other than his or her own. In addition to logging one user’s access rights to another user’s mailbox, this commonly could involve logging one user’s access rights to a resource mailbox. You might want to identify the recipients who currently have rights to the mailbox and compare this to the approved list of recipients who should have rights to the mailbox. One type of mailbox that should definitely be considered a candidate for Mailbox Audit Logging is the Discovery Search mailbox. Even if no other mailbox is configured with Mailbox Audit Logging, this one should be configured to ensure that the proper people are performing only the necessary cross-mailbox searches.
348
Enabling Mailbox Audit Logging
There are three types of individuals for whom you may log access: ■
Mailbox owners (the user of the mailbox)
■
Mailbox delegates (those given rights to the user’s mailbox)
■
Administrators (those who manage the user’s mailbox)
Mailbox Audit Logging is enabled at the mailbox level. You may specify the monitoring of your users’ actions—accessing the mailbox, moving the mailbox, moving a message in the mailbox, deleting a message—as well as other information such as the logon type specified, the client’s IP address, the client’s hostname, and the type of client used to access the mailbox. For items that were moved, the log entry also includes the name of the destination folder. By default, Mailbox Audit Logging is not enabled for any mailbox. For each mailbox you want to audit, you must enable audit logging and designate the mailbox owner, delegate, or administrator actions for which you want to audit, as specified earlier.
NOTE
When you enable Mailbox Audit Logging on a mailbox, an audit log is created for the mailbox. Each mailbox has a unique audit log. The log entries are stored in the Recoverable Items folder of the audited mailbox in a folder called Audit. Mailbox audit log entries are kept in the mailbox for 90 days, by default. This can be modified with the -AuditLogAgeLimit option. If litigation hold is enabled on a mailbox, audit logs are retained until the hold is removed. The following table shows how to enable and disable Mailbox Audit Logging. PS C:\Users\Administrator>Set-Mailbox -Identity "Jim" -AuditEnabled $true
Enables mailbox auditing for the specified mailbox.
Disables mailbox auditing for the specified mailbox.
Here are the events that can be logged for owners (users), delegates, and administrators, as appropriate. The following actions constitute mailbox owner or delegate access to a mailbox: ■
Accessing a folder in a mailbox
■
Accessing a message in the preview pane or opening a message
■
Copying a message to another folder
■
Deleting a message from the Deleted Items folder
■
Exercising the SendAs permission
■
Exercising the SendOnBehalf permission
■
Moving a message to another folder
Initiating Administrative Actions to Test Mailbox Audit Logging
■
Moving a message to the Deleted Items folder
■
Permanently deleting a message from the Recoverable Items folder
349
Here are the events that can be logged for administrators. The following actions constitute administrator access to a mailbox: ■
Using a New-MailboxExportRequest cmdlet to export a mailbox
■
Using Discovery Search to search a mailbox
■
Using the Microsoft Exchange Server MAPI Editor to access the mailbox
Initiating Administrative Actions to Test Mailbox Audit Logging You can test the logging process by exercising an action normally reserved for an administrator. In the examples that follow, you will export data to a .pst file. In Exchange 2003, you used the Exchange utility ExMerge. ExMerge was not PowerShell capable, so it was retired when Exchange 2007 was released. (The functionality of ExMerge is contained in three cmdlets in PowerShell: Move-Mailbox, Import-Mailbox, and Export-Mailbox.) Unfortunately, you couldn’t just type Export-Mailbox in Exchange 2007 and export data to a .pst file. A lot of preparation work had to be performed in order to export data to a .pst file. There were a great deal of restrictions and roadblocks. One such roadblock was that Outlook had to be installed on your server to get the .dll files necessary for importing and exporting .pst files. Add to that the fact that Import-Mailbox and Export-Mailbox do not always complete without errors, and also the fact that ExMerge is no longer a supported tool by Microsoft, and you can see why importing from a .pst file and exporting to a .pst file have been challenging over the past few years. The RTM version of Exchange 2010 continued to use the Import-Mailbox and ExportMailbox cmdlets as Exchange 2007 SP1 did, but that changes with Exchange 2010 SP1. With Exchange 2010 SP1, the Import-Mailbox and Export-Mailbox cmdlets have been retired and no longer function on SP1 machines. The replacement cmdlets are NewMailboxImportRequest and New-MailboxExportRequest. (Actually, quite a few other cmdlets are involved with importing and exporting mailboxes, but these two provide the main functionality.) The use of these cmdlets is not completely effortless, however. By default, no one is granted the permissions necessary to import and export data to and from mailboxes in Exchange 2010 SP1. This includes members of Organization Management. Therefore, it is necessary to grant permissions as you did in Chapter 31, “Configuring Role-Based Access Control (RBAC) Permissions,” using RBAC management role groups and role assignments. The examples shown in the following table export data to a .pst file, and then you see the effects of Mailbox Audit Logging after the export has completed.
350
Initiating Administrative Actions to Test Mailbox Audit Logging
Exports all messages from the specified user’s Inbox to the appropriate .pst file.
Figure 32-1 shows the exported .pst files from the preceding examples, which validates that administrative rights were used by an administrator.
Figure 32-1
Exported .pst files as seen in Windows Explorer
In addition to the New-ImportRequest and New-ExportRequest cmdlets, other new cmdlets in Service Pack 1 deal with importing and exporting mailboxes, as shown in the following table. PS C:\Users\Administrator> Get-MailboxExportRequest
Displays the status of an export request that is in progress. Use this after the New-MailboxExportRequest cmdlet has been executed.
Initiating Administrative Actions to Test Mailbox Audit Logging
351
PS C:\Users\Administrator> Displays detailed information about Get-MailboxExportRequestStatistics export requests that are in progress.
This information can be outputted to a .txt or .csv file. PS C:\Users\Administrator> Remove-MailboxExportRequest
Removes a fully or partially completed export request. Completed export requests aren’t cleared automatically. They need to be removed by using this cmdlet, just like completed mailbox moves must be cleared.
Displays the status of an import request that is in progress. Use this after the New-MailboxImportRequest cmdlet has been executed.
PS C:\Users\Administrator> Displays detailed information about Get-MailboxImportRequestStatistics import requests that are in progress.
This information can be outputted to a .txt or .csv file. PS C:\Users\Administrator> Remove-MailboxImportRequest
Removes a fully or partially completed import request. Completed import requests aren’t cleared automatically. They need to be removed by using this cmdlet, just like completed mailbox moves must be cleared.
Suspends an import request after the request was created but before the request reaches the status of Completed.
352
Initiating a Search of the Mailbox Audit Log
Initiating a Search of the Mailbox Audit Log You can also exercise Send As rights to test Mailbox Audit Logging, as shown in the following table. For example, suppose you investigate a complaint that someone is sending mail as the VP, Jim Masters. You determine that two people have been granted Send As permissions to the mailbox. The VP (Jim) states that Paul is legitimately sending mail as him. So, you search the mailbox audit log for instances of other users sending mail as the VP. By initiating a mailbox audit log search to asynchronously look for one or more mailboxes, you can check to see whether the complaint has validity. You can even designate the search results to be sent to you by email. It is not possible to create a mailbox audit log search using Exchange Management Console (EMC), but you can do it with Exchange Control Panel (ECP) in Exchange 2010 SP1. NOTE
Retrieves all “Send As” mailbox audit log entries for the specified user’s mailbox, as shown in Figure 32-2.
Searching the mailbox audit log for a user sending mail as another user
As shown in Figure 32-2, Maureen Doyle is sending mail as the VP (in addition to Paul, who is doing so legitimately).
Initiating a Search of the Mailbox Audit Log
353
You can use the New-MailboxAuditLogSearch cmdlet to search mailbox audit logs and have the search results sent by email to a distribution group consisting of the company’s auditors, if desired, as shown in the following table. PS C:\Users\Administrator> New-MailboxAuditLogSearch -Name "Possible Admin Abuse" -Mailboxes "Jim" -LogonTypes Admin -StartDate 12/1/2010 -EndDate 12/14/2010 -StatusMailRecipients [email protected] -ShowDetails
Creates a mailbox audit log search to look for the specified mailboxes for administrator logons during the specified dates in search of administrator abuse. Search results are delivered to [email protected] via email.
Finally, it is also possible to configure many of these mailbox audit log settings through the SP1 version of OWA, as shown in Figure 32-3.
Figure 32-3 Mailbox Audit Logging as configured using OWA connected to an Exchange 2010 SP1 mailbox
This page intentionally left blank
CHAPTER 33
Reporting and Other Useful Cmdlets
This chapter provides information and commands concerning the following topics: ■
Obtaining information about a mailbox with Get-MailboxStatistics
■
Retrieving logon information about currently active sessions with GetLogonStatistics
■
Using other useful cmdlets
In this chapter, you investigate the reporting capabilities of Exchange Management Shell with two cmdlets: the Get-MailboxStatistics cmdlet and the Get-LogonStatistics cmdlet. The final section of this chapter includes a list of useful cmdlets.
Obtaining Information about a Mailbox with Get-MailboxStatistics As shown in the following table, you can use the Get-MailboxStatistics cmdlet to obtain information about a mailbox, such as the size of the mailbox, the number of messages it contains, and the last time it was accessed. In addition, you can get the move history or a move report of a completed move request. PS C:\Users\Administrator> Get-MailboxStatistics -Identity RomacSign\Paul
Figure 33-1
Retrieves the mailbox statistics for the specified mailbox by using the user’s account name, as shown in Figure 33-1.
Use of the Get-MailboxStatistics cmdlet
PS C:\Users\Administrator> Get-MailboxStatistics -Identity Paul
Retrieves the mailbox statistics for the specified mailbox by using the user’s alias. This cmdlet produces identical results as the first example, but uses the alias attribute to identify the mailbox. NOTE
356
Obtaining Information about a Mailbox with Get-MailboxStatistics
Retrieves the mailbox statistics for all mailboxes on the specified server, as shown in Figure 33-2.
Use of the Get-MailboxStatistics cmdlet with the -Server switch
PS C:\Users\Administrator> Retrieves the mailbox statistics for all mailboxes over the specified value in Get-Mailbox | size, as shown in Figure 33-3. Get-MailboxStatistics | Where {$_.TotalItemSize -gt 500MB}
Figure 33-3 Use of the Get-MailboxStatistics cmdlet for filtering by mailboxes greater in size than 500MB
Retrieves a list of the mailboxes and their sizes in the organization.
The use of -ne in this context means “not equal.” NOTE
TIP To convert the output to MB, use the ToMB option, as shown in Figure 33-4. (ToGB would also work if you wanted the output converted to GB instead of MB, as shown in the example.)
Figure 33-4 Outputting a list of mailboxes and their sizes to a .csv file, with the size converted to MB
PS C:\Users\Administrator> Get-MailboxStatistics -Identity Ed -IncludeMoveHistory | Format-List
Returns the move history for the completed move request for the specified mailbox in addition to other mailbox statistics, as shown in Figure 33-5. Use the Format-List option, because Format-Table will truncate the move history data.
TIP
358
Obtaining Information about a Mailbox with Get-MailboxStatistics
Figure 33-5
Use of the Get-MailboxStatistics cmdlet showing move history
Enables you to view all mailboxes that have -LastLoggedOnUserAccount set to a specific user account, as shown in Figure 33-6. TIP This can be helpful when you’re migrating mailboxes. You can determine which mailboxes have not been logged on to by a user if -LastLoggedOnUserAccount is set to $null and then not move them.
Figure 33-6 Use of the Get-MailboxStatistics cmdlet showing a user logged on to another mailbox
Retrieving Logon Information about Currently Active Sessions with Get-LogonStatistics
359
PS C:\Users\Administrator>Get-Mailbox -OrganizationalUnit "Assemblers" | Get-MailboxStatistics | ft DisplayName,TotalItemSize
Retrieves statistics for all mailboxes in the specified Organizational Unit and then displays the user and size of mailbox in a table format.
Retrieves a list of mailboxes that have never been logged on to and displays the list with the specified attributes in a list format.
Retrieving Logon Information about Currently Active Sessions with Get-LogonStatistics The Get-LogonStatistics cmdlet retrieves logon information about currently active sessions. As shown in the following table, this cmdlet is run against mailbox servers. PS C:\Users\ Retrieves some information about the specific user. Administrator> NOTE This information includes the user name, server Get-LogonStatistics name, logon time, and last access time, as shown in Figure 33-7. -Identity Maureen | ft -AutoSize There are multiple entries (three) because the client
(Maureen) has connected multiple times, including one time when she accessed her Personal Archive mailbox.
Figure 33-7
Use of the Get-LogonStatistics cmdlet
360
Retrieving Logon Information about Currently Active Sessions with Get-LogonStatistics
Retrieves all information about the specific user. This information includes the preceding information as well as client mode, client IP address, and adapter speed. NOTE
This cmdlet provides real-time data about the logons. PS C:\Users\Administrator> Get-LogonStatistics -Server Romac-EX1
Retrieves some information about users with mailboxes on a specific server. This information includes the user name, server name, logon time, and last access time. This example returns logon statistics for all users connected to the specified server. NOTE
Allows you to determine what version of Outlook is connecting to Exchange, as shown in the following list. The output will be similar to 11.0.8010.8036, which is Outlook 2003 SP2. NOTE
TIP Mode = 0 (showing “unknown”) is a pre-Outlook 2003 or BlackBerry client.
Mode = 1 is a client in Online mode.Mode = 2 is a client in Cached Exchange mode.
The recent Outlook version numbers are as follows: ■
Office XP RTM—10.0.2627.1
■
Office XP SP1—10.0.3416.0
■
Office XP SP2—10.0.4115.0
■
Office XP SP3—10.0.6515.0
■
Office 2003 RTM—11.0.5604.0
■
Office 2003 SP1—11.0.6352.0
■
Office 2003 SP2—11.0.6555.0
■
Office 2003 SP3—11.0.8161.0
■
Office 2007 RTM—12.0.4518.1014
■
Office 2007 SP1—12.0.6211.1000
■
Office 2007 SP2—12.0.6423.1000
■
Office 2010 RTM—14.0.4760.1000
Using Other Useful Cmdlets
361
PS C:\Users\Administrator> Get-LogonStatistics -Server Romac-EX1 | Where {$_.ClientIPAddress -like "10.5.0.155"}
Retrieves a specific logon session from a specific IP address.
Retrieves a list of currently loggedon users and exports it to a .csv file. It displays the output in a list format.
Using Other Useful Cmdlets A lot of other useful cmdlets are available that might not fit into any specific category, but can be very helpful in a variety of situations. This chapter concludes with a number of these cmdlets documented in the following tables, in no particular order. Enjoy. PS C:\Users\Administrator> Get-ActiveSyncDeviceStatistics -Mailbox Paul | fl DeviceType, DeviceUserAgent, LastSuccessSync
Retrieves mobile device information for the specified mailbox.
PS C:\Users\Administrator> Get-MailboxDatabase -Identity *DB* | Get-Mailbox | ft Name,Database
Retrieves a list of all users with mailboxes in databases with “DB” in the name of the database.
PS C:\Users\Administrator>Send-MailMessage -From [email protected] -To [email protected] -Subject "Test Send" -Body "This example tests the sending of an e-mail via a PowerShell cmdlet" -SmtpServer Romac-EX1.romacsign.com
Sends an email from the specified user to the specified recipient using a PowerShell cmdlet, as shown in Figure 33-8.
Figure 33-8
Sending mail using a PowerShell cmdlet
The following table lists some other useful cmdlets for the configuration of an out-ofoffice schedule or an out-of-office message.
Retrieves a list of all mailboxes in the organization and exports the list (including all attributes) to a .csv file. There is no formatting to this text data, other than it is in a .csv format. NOTE
PS C:\Users\Administrator> Set-MailboxAutoReplyConfiguration -Identity Maureen -InternalMessage "I am headed to Hawaii for two weeks." -ExternalMessage "I am out of the office for the next two weeks."
Changes a user’s out-ofoffice message (internal and external) as necessary.
Retrieves a list of users who have their out-ofoffice message turned on, as shown in Figure 33-9. You now even have the ability to change the user’s message, set the audience (internal or external), and turn the message off using Exchange Management Shell. NOTE
Using Other Useful Cmdlets
Figure 33-9
363
Finding mailboxes with Out of Office set
The following table shows useful cmdlets for disabling the use of an out-of-office message and for calculating the amount of whitespace in the databases in your organization. PS C:\Users\Administrator> Set-MailboxAutoReplyConfiguration -Identity Maureen -AutoReplyState Disabled
Disables the out-of-office message for the specified user.
Calculates the amount of whitespace in the databases in your organization, as shown in Figure 33-10.
Figure 33-10 Calculating the available whitespace in databases
The following table shows some useful cmdlets for several different tasks that you might want to perform, such as retrieving the name of your Exchange organization, enabling
364
Using Other Useful Cmdlets
litigation hold on a mailbox, creating a CAS array, and assigning a database to a specific CAS array. PS C:\Users\Administrator> Get-OrganizationConfig | Select Name
It might take up to an hour for the litigation hold to take effect. NOTE
You would load-balance your CAS servers in a CAS array by using either hardware load balancing or Windows Network Load Balancing (NLB). You would then create a MAPI A record in your internal DNS infrastructure that resolves to the Virtual IP Address (VIP) of the CAS array. You would configure your loadbalancing array to load-balance the MAPI RPC ports TCP (135), UDP/TCP (6005–65535), or you could set static ports.
Sets the RpcClientAccessServer property to match the newly created CAS array. You need to do this for any databases that were created before the CAS array was created. NOTE
PS C:\Users\Administrator> Retrieves a list of all distribution groups that are hidden from Get-DistributionGroup | address lists. Select Name, HiddenFromAddressListsEnabled | Where {$_.HiddenFromAddressListsEnabled -eq $true}
Using Other Useful Cmdlets
365
PS C:\Users\Administrator>Get-Mailbox | Add-MailboxPermission -AccessRights FullAccess -User Paul
Grants full-access permissions for all mailboxes to the specified user.
PS C:\Users\Administrator>Get-Mailbox -OrganizationalUnit "Assemblers" | Add-MailboxPermission -AccessRights FullAccess -User Jim
Grants full-access permissions for all mailboxes in the specified OU to the specified user.
PS C:\Users\Administrator>Get-Mailbox | Add-ADPermission -ExtendedRights "Send As" -User Paul
Grants “Send As” permissions for all mailboxes to the specified user.
Scans Active Directory for any disconnected mailboxes that have not yet been marked as “Disconnected” in the Microsoft Exchange store. It updates the status of those mailboxes in the Exchange store.
You must restart the Microsoft Exchange Information Store service after entering the product key. NOTE
The Information Store service must be running and the database must be mounted for this cmdlet to function without errors. NOTE
Removes all messages from all queues on your Hub Transport servers. This might be useful in a lab environment. NOTE
This page intentionally left blank
APPENDIX A
Lab Environment Used for This Book
You may not be able to (or want to) use your production environment for working with cmdlets as you write and test them. For this reason, I have included a brief description of the lab environment I used in the writing of this book. Although this is the environment I used, you have a number of options in addition to this one. I used a virtual platform so that I could have multiple servers up and running at the same time. I also needed it to run on my laptop because I travel extensively.
The Platform on Which the Virtual Machines Ran During the Writing of This Book I initially thought of using Microsoft’s Hyper-V platform, but that requires Windows Server 2008, and my laptop runs Windows 7. I decided that I did not want to install Server 2008 on my laptop. I also looked at Windows Virtual PC, the new version of Microsoft Virtual PC available natively in some Windows 7 editions, but that only allows for 32-bit virtual machines (VMs), and of course Exchange Server 2010 only runs on 64-bit platforms. Therefore, I decided to try Oracle’s Virtual Box, which allows for 64-bit VMs to run on a 64-bit Windows 7 physical host. Virtual Box is a free download from http://www.virtualbox.org/, and I used the current version (which was 3.2.12, as of the writing of this book). My laptop is a two-year-old Dell D630 with 8GB of RAM. It has two internal 320GB hard drives that are spinning at 7200 RPM. I separated the virtual environment (Drive 2) from the operating system and page file (Drive 1). With VMs, more RAM and faster disk speed dramatically improve performance and allow more VMs to run simultaneously. This met my two main objectives: ■
Having multiple Exchange servers with enough resources to have at least three VMs running simultaneously and still maintain acceptable performance.
■
Installed on my laptop so it would travel with me (and not require Internet connectivity).
368
The Lab Environment Used in this Book
The Lab Environment Used in this Book Romac Sign Company was my father’s actual company before he and his partner passed away. The company was based in Philadelphia, Pennsylvania, and came into existence long before the Internet. I registered the domain name RomacSign.com for use in this book, so that you may use the actual examples in this book without fear of using someone’s real domain name on your lab’s Exchange servers. Here’s a list of the servers you will need (running either physically or virtually) to fully perform all of the cmdlets in this book: ■
Romac-DC1—A Windows Server 2008 R2 machine running AD DS (Active Directory Domain Services).
■
Romac-EX1—A Windows Server 2008 R2 machine running the Mailbox, Hub
Transport, and Client Access Server roles with the RTM version of Exchange Server 2010. ■
Romac-EX2—A second Windows Server 2008 R2 machine running the Mailbox,
Hub Transport, and Client Access Server roles with the RTM version of Exchange Server 2010. ■
Romac-EX3—A Windows Server 2008 R2 machine running the Mailbox, Hub
Transport, and Client Access Server roles with Service Pack 1 for Exchange Server 2010. (This server is optional; if you do not plan on using Service Pack 1 yet, you may omit this server.) ■
Romac-EX4—An additional Windows Server 2008 R2 machine running the
Mailbox, Hub Transport, and Client Access Server roles with the RTM version of Exchange Server 2010. (This server is optional; you could use either Romac-EX1 or Romac-EX2 in place of this server. It was more convenient to just use a clone of one of my VMs after the DAG had been created than to remove the DAG.) ■
Romac-EX5—Similar to Romac-EX4, this is an additional Windows Server 2008
R2 machine running the Mailbox, Hub Transport, and Client Access Server roles with the RTM version of Exchange Server 2010. (This server is also optional; you could use either Romac-EX1 or Romac-EX2, as was the case with Romac-EX4.) ■
Romac-CL1—A Windows 7 Enterprise Edition machine running Outlook 2010.
■
Romac-ET1—A Windows Server 2008 R2 machine running the Edge Transport role with the RTM version of Exchange Server 2010.
At this point, your lab environment would appear as represented in Figure A-1.
Creating Test Users and Mailboxes for the Lab Environment
Figure A-1
369
Romac Sign Company Exchange 2010 lab
Primary Data Center
ROMAC SIGN COMPANY EXCHANGE 2010 LAB
Internet
Romac-ET1 Exchange 2010 Edge Transport Server
DMZ
Romac-EX5 Exchange 2010 Mailbox/Hub Transport/Client Access Server Romac-EX1 Exchange 2010 Mailbox/Hub Transport/Client Access Server
Romac-EX3 Exchange 2010 SP1 Mailbox/ Hub Transport/Client Access Server
Romac-EX4 Exchange 2010 Mailbox/Hub Transport/Client Access Server
Romac-EX2 Exchange 2010 Mailbox/Hub Transport/Client Access Server Romac-CL1 Outlook 2010 Client on Windows 7
Romac-DC1 Windows Server 2008 R2 Domain Controller
The aforementioned machines may all use evaluation software and do not have to be activated. If the evaluation period is close to expiration, simply type the cmd.exe slmgr -rearm, reboot the VM, and you will extend the grace period. NOTE
There is a limit as to the number of times you can extend the grace period.
Creating Test Users and Mailboxes for the Lab Environment Use the following text along with the .ps1 file to populate your Active Directory environment and give the newly created users Exchange mailboxes if you wish to have some test mailboxes to practice your cmdlets. Copy the exact text that follows and save it as C:\Users\Administrator.RomacSign.com\management.csv. If you do not use the same path indicated here, you may save the file to any location for which you have permission. Alter the path for the $csvfile variable in the management.ps1 script to reflect the alternate path you have chosen. NOTE
Use the following script to create the users and mailboxes. If you save it as a .ps1 file, it will be executable from PowerShell. In the example that follows, save the script as C:\ Users\Administrator.RomacSign.com\management.ps1. If you do not use the same path indicated here, you should save this file to the same alternate location you used when you saved the management.csv file earlier. NOTE
Figure A-2 shows the result of running the management.ps1 file. Figure A-2
New users and mailboxes created with the management.ps1 file
If you are performing these steps, you will need to create an OU called “Management” and a database called “Management DB” on Romac-EX1 before running the management.ps1 script. To create the OU, follow these steps: 1. Open Active Directory Users and Computers and right-click your domain. (In
the lab environment used to create this book, this is RomacSign.com.) 2. Select New and then select Organizational Unit. 3. In the Name box, type Management. 4. Accept all other defaults and click OK to complete the creation of the
Management OU. To create the database, follow these steps: 1. Open Exchange Management Console, right-click Mailbox beneath
Organization Configuration, and select New Mailbox Database. 2. In the Mailbox database name box, type ManagementDB.
Creating Test Users and Mailboxes for the Lab Environment
371
3. Browse to one of your mailbox servers. (In the preceding example, Romac-EX1
was used.) 4. With the server selected, click OK. 5. Click Next, accept the default paths and all other default options, and then click
Next again. 6. Click New and then click Finish.
TIP Better yet, why not use the techniques you learned in Chapter 14, “Mailbox Servers and Databases,” to create and mount the database?
## Section 1 ## Define the Database for your new mailboxes $db="ManagementDB"
## Define the User Principal Name for your users $upndom="romacsign.com"
## Define OU for your new users $ou="Management"
## Define the CSV File with the user information in it $csvFile="C:\Users\Administrator.RomacSign.com\management.csv"
## Section 2 ## Import the CSV
file into the variable $users
$users = Import-CSV $csvFile
## Section 3 ## Function to convert Password string to secure string function SecurePassword([string]$plainPassword) { $secPassword = new-object System.Security.SecureString
Foreach($char in $plainPassword.ToCharArray()) { $secPassword.AppendChar($char) }
Conclusion Most of the examples in the book could run very well on a single server running both the Active Directory and Exchange Server 2010, if you do not have the time or resources to set up a fully functional lab. (Keep in mind that it is highly recommended that the Active Directory Domain Controller and the Exchange Server do not coexist on the same physical or virtual machine in the real world for a variety of reasons.) I chose a private addressing scheme that should be unique to most of you, so that the lab would not conflict with your own internal addressing scheme in your company; however, this can be customized as you wish. The subnet used in this book is 10.5.0.0/16 and includes the range of IP addresses 10.5.0.1 to 10.5.255.254. If you use machines that are similar to the ones I used in each chapter, you could have your lab PCs running (either physically or virtually) so that you can type the cmdlets as you read them in the book. Hopefully, you will see similar results when you execute them as I did when I wrote the chapters. In any case, I feel that it will be invaluable to have at least one Exchange 2010 server available to practice the cmdlets you learn in this book. This is especially true when you are working with Exchange Management Shell at the outset. It is likely that you will have problems with syntax and will need to work with your cmdlets in order to achieve the desired results. There is no doubt that working with Exchange Management Shell in the beginning can be a challenging and admittedly frustrating experience. You may want to run back to the comfort and safety of Exchange Management Console, but give the Shell a fair shake. With a little time spent learning and practicing your cmdlets, you will realize what an amazingly powerful command-line shell Microsoft has brought to the messaging environment.
APPENDIX B
Create Your Own Journal Here
Use this appendix to make notes about your day-to-day tasks and information specific to your job to make this journal truly your own. _______________________________________________________________________ _______________________________________________________________________ _______________________________________________________________________ _______________________________________________________________________ _______________________________________________________________________ _______________________________________________________________________ _______________________________________________________________________ _______________________________________________________________________ _______________________________________________________________________ _______________________________________________________________________ _______________________________________________________________________ _______________________________________________________________________ _______________________________________________________________________ _______________________________________________________________________ _______________________________________________________________________ _______________________________________________________________________ _______________________________________________________________________ _______________________________________________________________________ _______________________________________________________________________ _______________________________________________________________________ _______________________________________________________________________ _______________________________________________________________________ _______________________________________________________________________ _______________________________________________________________________
