Microsoft Exchange Server 2007 Infrastructure Design : A Service-Oriented Approach [1 ed.] 9780470382158, 9780470224465

Citation preview

®

Microsoft Exchange Server 2007 Infrastructure Design A Service-Oriented Approach David W. Tschanz

Wiley Publishing, Inc.

®

Microsoft Exchange Server 2007 Infrastructure Design

®

Microsoft Exchange Server 2007 Infrastructure Design A Service-Oriented Approach David W. Tschanz

Wiley Publishing, Inc.

Acquisitions Editor: Tom Cirtin Development Editor: Kim Wimpsett Technical Editor: Brian Tirch Production Editor: Eric Charbonneau Copy Editor: Foxxe Editorial Production Manager: Tim Tate Vice President and Executive Group Publisher: Richard Swadley Vice President and Publisher: Neil Edde Book Designer: Maureen Forys, Judy Fung Proofreader: Jen Larsen, Word One Indexer: Ted Laux Cover Designer: Ryan Sneed Cover Image: © Creatas Images / Getty Images Copyright © 2008 by Wiley Publishing, Inc., Indianapolis, Indiana Published by Wiley Publishing, Inc., Indianapolis, Indiana Published simultaneously in Canada ISBN: 978-0-4702-2446-5 No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, except as permitted under Sections 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 646-8600. Requests to the Publisher for permission should be addressed to the Legal Department, Wiley Publishing, Inc., 10475 Crosspoint Blvd., Indianapolis, IN 46256, (317) 572-3447, fax (317) 572-4355, or online at http://www.wiley.com/go/permissions. Limit of Liability/Disclaimer of Warranty: The publisher and the author make no representations or warranties with respect to the accuracy or completeness of the contents of this work and specifically disclaim all warranties, including without limitation warranties of fitness for a particular purpose. No warranty may be created or extended by sales or promotional materials. The advice and strategies contained herein may not be suitable for every situation. This work is sold with the understanding that the publisher is not engaged in rendering legal, accounting, or other professional services. If professional assistance is required, the services of a competent professional person should be sought. Neither the publisher nor the author shall be liable for damages arising herefrom. The fact that an organization or Website is referred to in this work as a citation and/or a potential source of further information does not mean that the author or the publisher endorses the information the organization or Website may provide or recommendations it may make. Further, readers should be aware that Internet Websites listed in this work may have changed or disappeared between when this work was written and when it is read. For general information on our other products and services or to obtain technical support, please contact our Customer Care Department within the U.S. at (800) 762-2974, outside the U.S. at (317) 572-3993 or fax (317) 572-4002. Wiley also publishes its books in a variety of electronic formats. Some content that appears in print may not be available in electronic books. Library of Congress Cataloging-in-Publication Data is available from the publisher. TRADEMARKS: Wiley, the Wiley logo, and the Sybex logo are trademarks or registered trademarks of John Wiley & Sons, Inc. and/or its affiliates, in the United States and other countries, and may not be used without written permission. Microsoft is a registered trademark of Microsoft Corporation in the United States and/or other countries. All other trademarks are the property of their respective owners. Wiley Publishing, Inc., is not associated with any product or vendor mentioned in this book. 10 9 8 7 6 5 4 3 2 1

Dear Reader Thank you for choosing Microsoft Exchange Server 2007 Infrastructure Design. This book is part of a family of premium quality Sybex books, all written by outstanding authors who combine practical experience with a gift for teaching. Sybex was founded in 1976. More than thirty years later, we’re still committed to producing consistently exceptional books. With each of our titles we’re working hard to set a new standard for the industry. From the paper we print on, to the authors we work with, our goal is to bring you the best books available. I hope you see all that reflected in these pages. I’d be very interested to hear your comments and get your feedback on how we’re doing. Feel free to let me know what you think about this or any other Sybex book by sending me an email at [email protected], or if you think you’ve found a technical error in this book, please visit http://sybex.custhelp.com. Customer feedback is critical to our efforts at Sybex. Best regards,

Neil Edde Vice President and Publisher Sybex, an Imprint of Wiley

For my son Eric, for support and patience and understanding; and to Neil and Kim, for keeping faith throughout the project.

Acknowledgments Writing a book is never a one-person task no matter whose name appears on the cover. This book idea came about as a result of the need to find some way to bridge the gap between technically savvy people and the people who weren’t into IT technospeak but had to look at new projects from a business viewpoint. Getting the two groups on the same page has been a desire of mine for a number of years, especially since it became obvious that the two had to coexist and effectively interact for either to be successful. So I’m going to start off by thanking Neil Edde at Sybex for listening to the idea with an open mind. If it wasn’t for his enthusiasm and perceptiveness, this book would never have happened. I can only hope that it lives up to its expectations. I also want to thank Kim Wimpsett who, as development editor, has kept a firm but light hand on the project and has made sure that it finished on time, on budget, and at the expected level of quality (see Chapter 2). This book has gone through many phases. I want to thank Tom Cirtin, Sybex acquisitions editor, for his support in guiding it through the early phases. I owe a special thanks to Lafe Low of Redmond Magazine, Angelica Micallef Trigona of GFI Malta, and Jim McBee for their comments on the initial outline and concept. During the writing process I had the help of a large number of people who reviewed, commented, critiqued, and guided the work. Their assistance is responsible for much of the quality of the book. These kind, bright, and skilled people include Karen Chiarello, Jacqueline Mullen, and Mary McDermott. Karen Langhamer reviewed the draft and never hesitated to point out its shortcomings and occasional moments of excellence. I owe a special thanks to Linda Maeder, Esq. for her expert review of the legal aspects of compliance and discovery as it relates to the Federal Rules of Civil Procedure. Jack Lockhart of JC Lockhart & Associates provided significant input regarding change management and managing user expectations. This is my 30th year as a writer, and one thing I learned awhile back is that, with the possible exception of a crazed hermit on a deserted island, no one writes in a vacuum. I also realized that support for every writing project comes in many different ways stretching way back in years. I have been fortunate to have the support and patience of so many different people during that time. I’d like to thank my father Alfred W. Tschanz for his support. Special thanks to my son Eric who doesn’t mind when his father disappears for hours at a time to ‘‘work on a project’’ and to my son Karl who while grown and married probably wonders where I disappear to as well. Additional thanks to Joanne Lurix, Salah Al-Dughaither, Khalid G. Al-Buainain, Paul Sauser, Art Clark, Mike Gunderloy, Emad Al-Dughaither, Jim Dunnigan, Pat Cocchiarella, Rob Lebow, Cyndy Tschanz, Josephine Skerencak, Andy Nunez, Jim Werbaneth, Dave Kaiser, Kara A. Langhamer and the many others who have encouraged and helped in my development as a writer. Being a writer often means that you have to ask people to accept the fact that you may not always be able to devote the time to them that you would like and which they deserve. It also requires that you have friends and associates willing to provide you with the right working atmosphere. For that kindness and generosity of spirit I also owe thanks to these very special people: Dan Boothby, Peter and Lilly Pomeroy, Bruce Dobbins, Ahmed Ghanim, Denise Perdikis, and the inimitable Hans Stockenberger.

viii

ACKNOWLEDGMENTS

Finally I want to thank the team at Sybex. I was fortunate to have as technical editor Brian Tirch who has been described by Jim McBee as ‘‘the most experienced Exchange 2007 person outside of Microsoft.’’ I also want to thank production editor Eric Charbonneau, copy editor Jeri Friedman, and proofreader Jen Larsen for their professionalism and diligence. Thanks to everyone for all your help. Please note that whatever errors of fact or judgment remain are mine and mine alone. David W. Tschanz Dhahran, Saudi Arabia

About the Author David W. Tschanz, PhD, MCSE has been helping to bridge the gap between technology experts and nontechnical managers for three decades. With a doctorate in history and an advanced degree in epidemiology, his work has included analysis of population dynamics, voting behavior studies, and epidemiological research. Along the way he picked up his MCSE and eight additional certifications from Microsoft, CompTIA, and Prosoft. He has been writing on IT topics for the past 15 years. This is his sixth IT book. He is the coauthor of Mastering SQL Server 2005 and a regular contributor to Redmond magazine. He also operates a small IT consulting firm specializing in business-oriented infrastructure development. Dave currently lives outside the United States, where his eclectic nature allows him to pursue projects involving databases, IT infrastructure, web development, archaeology, the ancient Nabataean capital of Petra, medical history, military science, and demography. He can be reached by email at [email protected], or look for him in Connecticut, Saudi Arabia, Jordan, or Long Island, his favorite haunts.

Contents at a Glance Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiii

Chapter 1

•

Mastering the Business-Oriented Approach . . . . . . . . . . . . . . . . . . . . . . . 1

Chapter 2

•

Determining Business Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Chapter 3

•

Planning the Exchange Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Chapter 4

•

Applying Planning Principles to Exchange Server 2007 . . . . . . . . . . . . . 77

Chapter 5

•

Planning Server Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

Chapter 6

•

Building the Business Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

Chapter 7

•

Developing a Change Management Program . . . . . . . . . . . . . . . . . . . . 181

Chapter 8

•

Managing User Expectations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205

Chapter 9

•

Setting Up a Change Request Process . . . . . . . . . . . . . . . . . . . . . . . . . . 221

Chapter 10

•

Deploying Exchange Server 2007 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241

Chapter 11

•

Tweaking the Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301

Chapter 12

•

So, You Want to Be a Consultant? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361

Appendix A

•

Measuring Team Effectiveness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387

Appendix B

•

Sample Business Case Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393

Appendix C

•

Change Request Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401

Appendix D

•

Operations Checklists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405

Appendix E

•

Lessons Learned Meeting Agenda . . . . . . . . . . . . . . . . . . . . . . . . . . . 413

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415

Contents Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiii

Chapter 1

•

Mastering the Business-Oriented Approach . . . . . . . . . . . . . . . . 1

The Past as Prologue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Understanding Business Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 A Short Quiz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Aligning IT with Business Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Taking Fiscal Responsibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Learning about the Business . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Working with Nontechnical Managers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Ensuring Good Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Knowing the Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Managing the Project Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Choosing the Right People . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Providing Excellent Project Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Establishing Clear Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 You: What Can You Do? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Chapter 2

•

Determining Business Requirements . . . . . . . . . . . . . . . . . . . . 21

The Whys and Hows of Business Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Understanding the Current Business Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Analyzing Business Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Analyzing the Company Model and Geographic Scope . . . . . . . . . . . . . . . . . . . . . Analyzing Organizational Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Determining the New Business Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Identifying and Communicating Possible System Features . . . . . . . . . . . . . . . . . . . Identifying Information Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Determining Business Priorities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Interviewing Stakeholders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Moving from High-Level Goals to Actionable Items . . . . . . . . . . . . . . . . . . . . . . . . Identifying the Company’s Tolerance for Risk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Identifying Internal and External Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating Data Flow Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Assessing Personnel and Training . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Determining Regulatory Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining Messaging Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Forecasting and Planning for Growth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Performing a Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

22 23 23 27 27 34 34 35 36 37 37 39 40 42 42 43 44 45 47 48

xiv

CONTENTS

Chapter 3

•

Planning the Exchange Infrastructure . . . . . . . . . . . . . . . . . . . 49

A Rose by Any Other Name. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Visualizing the Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . An Overview of the Scope Statement Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Developing the Scope Statement Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Writing the Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating the Project Vision Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining the Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining the Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . An Overview of the Planning Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Planning Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Basic Overview of Typical Phases in Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Developing the Statement of Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Statement of Work Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Design Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Implementation Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Chapter 4

•

50 52 52 53 54 54 55 56 59 62 62 65 66 70 73 75

Applying Planning Principles to Exchange Server 2007 . . . . . . . 77

Reviewing the Changes in Exchange Server 2007 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . An Overview of the New Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Choosing an Installation Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reviewing Exchange and Operating System Requirements . . . . . . . . . . . . . . . . . . . . . Hardware Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Operating System (OS) Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Version Selection Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Edition Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Product Licensing Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Client Access License Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Virtualization Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Third-Party Product Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Determining Disk Storage Needs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Planning Disk Capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Storage Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Storage Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Understanding Active Directory (AD) Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . How Exchange Server 2007 Uses Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . Schema Preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Forest Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . AD Domain Structure Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . AD Site and Replication Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Domain Name System (DNS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hardware Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Planning for Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Messaging Records Management (MRM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Transport Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

78 78 80 81 81 82 83 84 84 85 85 86 87 87 88 89 90 91 92 93 94 94 95 95 96 98 99

CONTENTS

Managed Folders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Journaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Licensing and Compliance Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Exchange Hosted Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Message Classifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Overview of Disclaimers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Planning Mail Archiving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Why Archive Email? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Email Archiving Planning Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Deploying and Managing Email Archive Solutions . . . . . . . . . . . . . . . . . . . . . . . . In-House vs. Outsourced Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pros and Cons of Outsourcing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Service-Level Agreements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Comfort Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Chapter 5

•

100 101 103 104 105 106 109 111 113 113 114 115 116 118 119

Planning Server Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

Client Access Server (CAS) Role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Exchange ActiveSync Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Outlook Web Access Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Outlook Anywhere Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . POP3 and IMAP4 Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Exchange 2007 Web Services Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CAS Security Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Edge Transport Server Role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Topology Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Server Capacity Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Transport Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Edge Subscription Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Address Rewriting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Planning for Antispam and Antivirus Features . . . . . . . . . . . . . . . . . . . . . . . . . . . Deployment Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adding an Edge Transport Server to an Existing Exchange 2003 Organization . . Hub Transport Server Role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mailbox Server Role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Unified Messaging Server Role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Assessing the Benefits of Unified Messaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Planning Unified Messaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Availability and Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Integrating Unified Messaging and Office Communications 2007 Server . . . . . . . Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Selecting the Appropriate Processor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Recommended Processor Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Selecting the Appropriate Memory Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . Recommended Memory Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

122 123 124 124 124 124 125 125 127 128 128 128 129 129 132 134 136 137 137 140 141 143 144 144 146 147 148 149 150

xv

xvi

CONTENTS

Server Role Ratios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CAS, Mailbox and Hub Transport Count . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Unified Messaging Server Count . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Edge Server Count . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tools You Can Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Chapter 6

•

Building the Business Case . . . . . . . . . . . . . . . . . . . . . . . . . . 155

Overview of the Business Case Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . How to Make a Business Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tips and Hints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Writing the Business Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Executive Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B. Business Case Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C. Costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E. Cost-Benefit Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . F. Sensitivities, Risks, and Contingencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . G. Conclusions and Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Double-Checking the Business Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Presenting the Business Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PowerPoint Presentations Do’s and Don’ts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tips for Presentation Day . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Chapter 7

•

151 151 152 152 152 152

156 156 158 160 161 162 163 166 168 170 173 174 174 175 176 177 178

Developing a Change Management Program . . . . . . . . . . . . . . 181

Understanding Change Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Change Management Defined . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Principles of Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Obstacles to Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Basic Principles of Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adopting Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . How People Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . How People Adopt Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . You, the Change Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Political Skills . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Analytical Skills . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . People Skills . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . System Skills . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Business Skills . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Basic Change Management Strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Empirical-Rational . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Normative-Reeducative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Power-Coercive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Environmental-Adaptive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

182 182 183 187 190 191 191 193 195 196 197 197 199 199 199 199 200 201 201

CONTENTS

Selecting a Change Management Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203

Chapter 8

Managing User Expectations . . . . . . . . . . . . . . . . . . . . . . . . . 205

•

The Power of Expectations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . What Are User Expectations? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sources of Expectations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Effect of Unmet Expectations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Understanding Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Communicating with Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . How to Communicate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . What Should Be Communicated? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Educating Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Prototyping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Training . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Service-Level Agreements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Quick Guide to Managing Expectations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Chapter 9

Setting Up a Change Request Process . . . . . . . . . . . . . . . . . . . 221

•

What Is the Change Request Process? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Building a Change Request Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Determinants of the Change Request Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . Who’s in Charge? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Building a Change Request Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Receiving the Change Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Evaluating the Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Summing up the Required Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Determining the Impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Determining the Impact on the Triple Constraints . . . . . . . . . . . . . . . . . . . . . . . . . Making a Decision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Notifying Others and Following Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Other Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Limiting the Disruptive Nature of Change Requests . . . . . . . . . . . . . . . . . . . . . . . Creating Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Enforcing the System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Stopping Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Case Study: Setting Up a Change Request Process . . . . . . . . . . . . . . . . . . . . . . . . . . . After the Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Chapter 10

205 206 207 207 208 209 210 211 213 213 213 217 217 219

•

222 222 223 224 225 225 226 226 226 227 227 229 230 231 233 233 236 236 238 239

Deploying Exchange Server 2007 . . . . . . . . . . . . . . . . . . . . . 241

The Tao of Upgrading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Final Preparations for Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Double-Checking the Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Selecting the Exchange Organization Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

241 243 243 247

xvii

xviii CONTENTS

Deploying a New Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250 Transitioning an Exchange Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252 Migrating from Lotus Notes to an Exchange Organization . . . . . . . . . . . . . . . . . . 256 Migrating from Exchange Server 5.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257 Installing Exchange Server 2007 with Service Pack 1 . . . . . . . . . . . . . . . . . . . . . . . . . 258 Installing Using the Setup Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258 Installing Exchange Server 2007 Using the Setup Command . . . . . . . . . . . . . . . . . 265 Postinstallation Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266 Verifying the Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266 Configuring Authoritative Domains for the Exchange Organization . . . . . . . . . . 268 Configuring Authoritative Domains on the Edge Transport Server Role . . . . . . . 270 Using the Security Configuration Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271 Performing Exchange Management Console Postinstallation Tasks . . . . . . . . . . . 272 Deploying Outlook Anywhere . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 Deploying Exchange ActiveSync . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277 Moving Mailboxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278 Strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278 Caveats and Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279 Shared Mailboxes and Resource Mailboxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279 Moving a Mailbox within a Single Forest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280 Moving a Mailbox across Forests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281 Merging Mailboxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283 Taking Extreme Measures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284 Modifying and Removing Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284 Modifying an Exchange Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285 Removing Exchange Server Roles from Windows 2003 and Windows 2008 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287 Completely Removing Exchange Server 2007 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290 Removing the Last Legacy Exchange Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292 Preparing the Exchange Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292 Removing the Last Exchange 2000 or 2003 Server . . . . . . . . . . . . . . . . . . . . . . . . . 294 Implementing Ongoing Change Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294 Enforcing Change Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295 Dos and Don’ts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296 Gauging Success . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297 Lessons Learned . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297 Lessons Learned Meeting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298 Do It for Yourself . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299

Chapter 11

•

Tweaking the Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . 301

Tools, Tools, and More Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuration Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Disaster Recovery Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mail Flow Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

301 302 304 307

CONTENTS

Performance Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Troubleshooting Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Performing Disaster Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A Stitch in Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . How Can I Lose Thee? Let Me Count the Ways . . . . . . . . . . . . . . . . . . . . . . . . . . . What Should You Protect? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Backup! Backup! Backup! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Restoring the Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Recovery Strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Recovery Storage Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Continuous Replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Achieving High Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Types of ECR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Setting Up Local Continuous Replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Managing Cluster Continuous Replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Managing Standby Continuous Replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Single Copy Clusters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Managing and Maintaining the Messaging System . . . . . . . . . . . . . . . . . . . . . . . . . . Daily Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Weekly Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Monthly Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tasks to Do ‘‘As Needed’’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Monitoring Continuous Replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Improving Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Troubleshooting Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Developing a Troubleshooting Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Taking a Proactive Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Chapter 12

•

310 311 314 315 316 317 318 320 322 324 325 326 326 328 333 336 338 338 339 343 343 343 345 346 350 351 356 359

So, You Want to Be a Consultant? . . . . . . . . . . . . . . . . . . . . 361

Understanding Consulting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . What Does a Consultant Do? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Why Become a Consultant? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . What Is the Consultant Personality? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Understanding IT Consulting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Advisory Skills . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Technical Skills . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Business Skills . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Communication Skills . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Becoming a Consultant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Getting ‘‘Free’’ Experience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Managing Your Finances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Marketing Yourself . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

361 362 362 363 364 365 370 371 372 373 373 373 374 377

xix

xx

CONTENTS

Professional Conduct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384 Last Word . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385

Appendix A

•

Measuring Team Effectiveness . . . . . . . . . . . . . . . . . . . . . . 387

1: Goal Setting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2: Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3: Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4: Interpersonal Relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Appendix B

•

389 390 391 392

Sample Business Case Proposal . . . . . . . . . . . . . . . . . . . . . 393

Business Case for Exchange Server 2007–Based Messaging System for Oakland Playground Equipment, Inc. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395 Executive Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395 A. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395 B. Business Case Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396 C. Cost Projections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397 D. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398 E. Cost-Benefit Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399 F. Sensitivities, Risks, and Contingencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400 G. Conclusions and Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400

Appendix C

•

Change Request Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401

Change Request Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402

Appendix D

•

Operations Checklists . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405

Daily Operations Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Physical Environmental Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Check Backups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Check CPU and Memory Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Check Disk Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Check Event Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Check IIS Logs and Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Exchange Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . MAPI Client Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Check Queue Viewer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Message Paths and Mail Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Checklist: Security Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Weekly Operations Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Create Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Incident Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Antivirus Defense . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Status Meeting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Monthly Operations Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Capacity Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

406 406 406 406 407 407 407 408 408 408 409 409 410 410 410 410 410 411 411

CONTENTS

Hot fixes, Service Packs, Update Rollups, and Security Updates . . . . . . . . . . . . . . 411 Summary Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412

Appendix E

•

Lessons Learned Meeting Agenda . . . . . . . . . . . . . . . . . . . . 413

How to Use This Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413 Example Agenda for a Lessons Learned Meeting . . . . . . . . . . . . . . . . . . . . . . . . . 414 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415

xxi

Introduction ‘‘Come, let Us go down and there confuse their language, so that they will not understand one another’s speech.’’ — Genesis 11:7 This book is the indirect result of some 30 years of working in highly technical fields, business environments, and occasionally as a member of management. During that time, one of the things I noticed was that technical people weren’t really very good at talking to business people and business people weren’t very good at explaining their needs to technical people. The result was usually frustration on both sides of the table. Nontechnical people who were running multimillion (or billion) dollar companies or projects couldn’t make heads or tails out of the technospeak and what seemed to them like gobbledygook that came from the geeks. All they knew was that computerization seemed to be the way to go. In the early years of the computer age, management and regular users were often seduced into believing what they were told was better than what it could be. Sometimes they let their enthusiasm get out of hand. When things inevitably went wrong, there was a sense of betrayal. There was also a little lingering suspicion that a con had been perpetrated. Of course, the technically oriented people didn’t see things that way. They felt that they had made the best possible recommendations. It wasn’t really their fault that management wasn’t clear on what they want or that many a project was the victim of scope creep and impossible expectations. Besides, all this emphasis on money was missing the point that technology could be its own reward. Things continued this way, pretty much uninterrupted until about the turn of the twenty-first century. Then a number of key things happened to start to change that cycle. First, software development slowed to a manageable pace. New operating systems weren’t being produced every year; in fact, as time went by the interval between new versions grew longer and longer. Hardware improvements slowed down as well. Replacing desktop computers once a year became a thing of the past. Application software, including Exchange Server, reached maturity and equilibrium with the organizations they were installed in. When this happened, and as technology reached the point where most things were functioning adequately within an enterprise, organizations began to turn a more critical eye toward the whole question of IT-related expenditures. Terms like total cost of ownership and return on investment became a part of the day-to-day lexicon that businesses were using in discussions with vendors, contractors, and their own IT departments. IT departments, once the recipients of a ‘‘throw money at the problem’’ largesse suddenly had to answer the question ‘‘what value does IT bring?’’ By the end of that period, the size of the budget, in fact the willingness of organizations to spend money on IT, was, to a great extent, determined by how well clients understood the value they were getting for the money. And that value was increasingly determined by understanding exactly what the technology delivers, believing that the cost is fair, and evaluating the contribution of those deliverables to the business’s bottom line both financially and in accordance with its mission statement. Except in a very few instances that wasn’t happening in most large enterprises, and it became progressively worse the smaller an organization became. People running businesses weren’t getting the answers they needed from IT personnel to answer basic questions about how new or

xxiv

INTRODUCTION

proposed technologies added value. Many IT personnel had no idea how to answer those questions and to align their project with business goals. The old impasse was for the most part still there. A bridge had to be built between the two, and that’s what this book is all about. I started designing this book once I realized that there was a need for material like this that could be used by technically oriented people to help guide them through what might seem like a unending labyrinth of business processes. It isn’t their fault either since very few, if any, were prepared for this in school or in their career. A lot of this book was deliberately written so that it could apply not to only one technology but to any hardware or software solution that you may find yourself proposing. For example, the techniques and methods I describe about how to determine business requirements could, with a little tweaking, be used in any IT project, not just an Exchange Server 2007–based messaging system. I also think it is important that IT personnel learn how to speak to business rather than the other way around. As experts, they have an obligation to make themselves understood and to adhere to the demands of the organization that funds them, not the other way around. The next question was what technology to apply it to and Exchange Server 2007 seemed the obvious choice. It’s still a relatively new technology, so there’s no automatic tendency to embrace it — the existence of so many systems still running on Exchange Server 5.5 shows that there is no rush to change when the essential goal of a mail system — the movement of email — is being met. It’s relatively expensive, and despite the many advantages it can bring to an organization’s bottom line, is going to require considerable discussion and planning. Because it represents a sea change in hardware, requiring 64-bit machines, it will also represent a considerable new investment in hardware and software. The combination of circumstances was ideal for a book on how to bridge the gap between the technical and nontechnical world. In writing this book, I had a few goals for both the book and the knowledge we want to impart to the reader: ◆ The book is designed to help you master the basics of planning and implementing an Exchange Server 2007–based messaging solution. I want you to get all of the basic skills necessary to plan, deploy, and tweak an Exchange Server 2007 system. ◆ The skills and tasks covered in this book should be applicable to 80 percent of all organizations running Exchange Server 2007. ◆ The book will educate not only ‘‘new to product’’ administrators but also those ‘‘new to version’’ administrators who are upgrading from a previous version. ◆ The book will introduce you to that 20 percent feature set that will be applicable only to certain types of organizations such as clustering and Unified Messaging. ◆ The book will provide you with information that allows you to successfully assess and determine the business requirements that your Exchange Server 2007–based messaging system should meet. ◆ The book will guide you in how to prepare a plan for implementing a solution, how to adapt it to business needs, and how to make a business case for its implementation. ◆ This book will explain the way to manage changes in your business environment, both changes in corporate attitudes toward the project and postdeployment change requests.

TERMINOLOGY CHANGES

What this book doesn’t pretend to be, nor is it intended to be, is a comprehensive book on using Exchange Server 2007 Service Pack 1. You can find excellent reference material on this robust new messaging system in Jim McBee’s Mastering Exchange Server 2007 (Wiley, 2007) or other texts. The goal in this book is to guide you in developing an infrastructure that meets the needs of your business or organization, which you can ‘‘sell’’ to the decision makers, and to help you develop the skills and understand the techniques that let you straddle both the IT and non-IT worlds. If you can do both, I’m sure you’ll discover you’re in for a rewarding and exciting future.

What You Need to Run Exchange Server Exchange Server 2007 is a complex product but the user interface has been completely revamped to make it easier to administer Exchange. All of this complexity and parallel ease of use requires an industrial-strength computer. The minimum server requirements suggested here is for testing, learning about, and evaluating the product. It’s also enough for a small, noncritical installation. However, as we discuss in the book, when the server moves into critical production environments, where it will be accessed by large numbers of users, you’ll need to beef up its hardware and add a number of fault-tolerant capabilities. On the client side, with the broad range of clients available for Exchange, the machines in most organizations should be more than adequate. At a minimum, to test, learn about, and evaluate Exchange Server, you need the following: ◆ Either Microsoft Exchange Server 2007 and Windows Server 2003 SP1 or Windows 2003 R2 or Microsoft Exchange Server 2007 Enterprise Edition and Windows Server 2007 Enterprise or Datacenter Edition. ◆ An AMD Athlon x64– or Intel x64–compatible processor with 2 GB of RAM and two 9 GB disk drives. This allows you to complete exercises involving a single Exchange server. ◆ A minimum of three additional computers in the class just described. This allows you to complete exercises involving multiple computers in multiple administrative groups and Windows Server 2003 domains. ◆ Tape backup hardware or at least one independent disk drive for backup. ◆ A local area network (preferably connected to the Internet). ◆ At least one 800 MHz Pentium III or 4 or equivalent computer with 128 MB of memory running Windows XP Professional for testing Outlook and other client side functions. During the development of this book, I used the 32-bit version of Exchange Server 2007 Service Pack 1 for testing. The 32-bit version of Exchange Server 2007 Service Pack 1 can be downloaded for evaluation, classroom, lab, and testing purposes, but it is not to be used in public.

Terminology Changes Exchange Server 2007 Service Pack 1 (SP1) contains several new features. There are also several features that have been enhanced, renamed, or that no longer exist. Furthermore, Windows Server 2008 introduces new features and functionality that are of interest to administrators of Exchange. This topic provides a roadmap for administrators to understand the various terminology changes in Exchange 2007 and Windows Server 2008. The following table provides a list of the terminology changes among various versions of Microsoft Exchange. Although this table does not include every feature, it can serve as a starting place to help you locate the features that you are looking for.

xxv

xxvi

INTRODUCTION

Terminology changes in Exchange 2007 Exchange Server 5.5

Exchange 2000 Server

Exchange Server 2003

Exchange Server 2007

Mailbox Manager

Mailbox Manager

Mailbox Manager

Messaging Records Management

Internet Mail connector

SMTP connector

SMTP connector

Connectors

Sites

Routing groups

Routing groups

Active Directory sites

Site connector

Routing Group connector

Routing Group connector

Active Directory IP Site Links

Directory Service

Link state routing

Link state routing

Handled through the Active Directory directory service

Exchange Administrator

Exchange System Manager

Exchange System Manager

Exchange Management Console

Custom Recipient

Mail-enabled contact Mail-enabled contact Mail-enabled contact

Message transfer agent (MTA)

SMTP Routing Engine

SMTP Routing Engine

Hub or Edge Transport service

Unavailable

RTC Services

Unavailable

Unavailable

Unavailable

M Drive

Unavailable

Unavailable

Internet Mail Service

SMTP virtual servers SMTP virtual servers SMTP Receive Connectors

Site addressing

Recipient policies

Recipient policies

E-mail address policies and Accepted domains

Windows NT 4.0 clustering (shared storage)

Active/Active or Active/passive cluster (shared storage)

Active/Active or Active/passive cluster (shared storage)

Single copy cluster (SCC)

Unavailable

Unavailable

Unavailable

Cluster continuous replication (CCR)

Unavailable

Unavailable

Unavailable

Local continuous replication (LCR)

Unavailable

Unavailable

Unavailable

Standby continuous replication (SCR)

Manual synchronization

Manual synchronization

Always Up To Date

Direct Push

HOW THIS BOOK IS ORGANIZED xxvii

Exchange Server 5.5

Exchange 2000 Server

Exchange Server 2003

Exchange Server 2007

Handled by recipient creation process

Recipient Update Service

Recipient Update Service

Address List Service

Free/busy public folder

Free/busy public folder

Free/busy public folder

Availability service

How This Book Is Organized This book is comprised of 12 chapters and five appendices. As you proceed through the book, you’ll move between basic general project management concepts to Exchange-specific implementations and examples of these concepts and topics. The book has been designed to be read as an organic whole, with the possible exception of Chapter 12, which segues from Exchange Server 2007 Service Pack 1 into future uses of the skills you should have mastered from following this book and thinking about its content. Chapters 2, 3, 6, 7, 8, and 9 tend to concentrate on the business and management aspects of your Exchange Server 2007–based messaging system, while Chapters 4, 5, 10, and 11 emphasize Exchange Server 2007 technical information or how to apply general principles to your development of the infrastructure. If you’re reasonably familiar with Exchange Server 2007 but weak on your business skills, don’t make the mistake of skipping Chapters 4, 5, 10, and 11. There are a number of good examples and subsections on such topics as ‘‘lessons learned.’’ Here’s a guide to what’s in each chapter: Chapter 1, ‘‘Introducing a Service- or Business-Oriented Approach,’’ presents some basic information about how IT workers and business managers can work together to establish a common ground. The chapter will introduce come new concepts and touch on new features and new terminology in Exchange Server 2007 Service Pack 1. Chapter 2, ‘‘Determining Business Requirements,’’ looks at what you need to do in order to determine what your business needs are in terms of an Exchange Server 2007–based messaging system. The chapter discusses who to contact, key stakeholders, and the entire development process. This is important because of course you don’t want to have an infrastructure that doesn’t enhance and meet the needs of the enterprise. Chapter 3, ‘‘Planning the Exchange Infrastructure,’’ covers how to go about planning a solution that meets the business requirements. The chapter discusses the creation of a statement of work, scope statement, design document, and implementation document as part of the design requirements. This process is required for any project, whether it be for an Exchange Server 2007–based messaging system or not. Chapter 4, ‘‘Applying Planning Principles to Exchange Server 2007,’’ provides the details on how to apply the information contained in Chapters 2 and 3 to your Exchange Server 2007–based messaging system. Chapter 5, ‘‘Planning Server Roles,’’ covers one of Exchange Server 2007’s newest and perhaps knottiest new enhancements: the five server roles. Included in this chapter are a number of tips on how to plan them into your infrastructure. Chapter 6, ‘‘Building the Business Case,’’ helps you to turn your solution and plans into a business proposal that will satisfy the needs of your organization and help win you the necessary funding. Included are tips on how to prepare and give a winning presentation.

xxviii INTRODUCTION

Chapter 7, ‘‘Developing a Change Management Program,’’ covers many of the tasks that you need to do to ensure that any change, including the adoption of the new Exchange Server 2007–based messaging system, is properly communicated. Included are tips and advice on how to recognize the causes of resistance to change and what to do about them. Chapter 8, ‘‘Managing User Expectations,’’ is a short chapter that deals with two big issues. The biggest cause of failure of a new system is usually not technical. It is mishandling the expectations and the users. I will walk you through some key ways to properly handle both. If you can successfully manage user expectations, you can save yourself and your project considerable aggravation. Chapter 9, ‘‘Setting Up a Change Request Process,’’ covers revision management and how to use it to create a process or methodology that ensures all changes are appropriate, are timely, and are made with the highest levels of certainty to achieve good results. Chapter 10, ‘‘Deploying Exchange Server 2007,’’ will walk you through a typical installation and deployment. I’ll also cover two nontechnical processes that you will have to do to ensure the successful conclusion of the project; implementing a change control system; and conducting a Lessons Learned analysis and review so that you can use the current project to get ready for the next one. Chapter 11, ‘‘Tweaking the Infrastructure,’’ examines the procedures you should perform immediately after deployment. Included are a review of tools and other means to tweak your new infrastructure. Also included is a basic troubleshooting methodology that applies to nearly every problem. Chapter 12, ‘‘So, You Want to Be a Consultant?’’ looks at what, for some, is the Holy Grail and for others is the most frightening concept imaginable. Either way, the skills and concepts you’ve mastered in this book might make it possible for you to leverage your career if you so desire. I’ll discuss some of the realities of being a consultant and help you decide whether this is the life for you. This book’s appendices contain a number of forms and useful documents that you can make use of in your planning and implementation. These include the following: ◆ Team effectiveness measurement score sheets ◆ Sample business case proposal ◆ Change request form ◆ Lessons learned meeting agenda ◆ Maintenance and monitoring checklists Feel free to adapt these forms and materials to meet your specific needs.

Conventions Used in This Book We’ve included many notes in this book. Generally, they are positioned after the material to which they refer. There are three kinds of notes: notes, tips, and warnings.

Note Notes give you information pertinent to the procedure or topic being discussed.

CONVENTIONS USED IN THIS BOOK xxix

Tip Tips indicate practical hints that might make your work easier.

Warning Warnings alert you to potential problems that you might encounter while using the program.

You’ll also find real-world sidebars that explain, illustrate, and elaborate on topics discussed in the text. These take the points being made and put them in context; you’ll soon see that we’re not discussing lofty, theoretical concepts here. Sometimes applying the right principles to your job can make or break a million-dollar project! Remember, Exchange Server 2007 is designed to help your organization do what it does better, more efficiently, and with greater productivity. Have fun, be productive, and prosper!

Chapter 1

Mastering the Business-Oriented Approach ‘‘The business of business is business.’’ — Milton Friedman Exchange Server 2007 is the latest release of the most commonly used corporate email platform, and represents, according to many in the industry, the future direction of not only email but also business communications. By the end of 2008, industry projections are that 50 percent of organizations that use Exchange will move to Exchange Server 2007. From a purely technological point of view, Exchange Server 2007 is one more step in the natural evolution of email. Its adoption and implementation by companies that want to keep up and maintain their competitive advantage and market share, as well as leveraging the promise of unified business communications, seems obvious and inevitable for the technologically oriented person. Taking full advantage of Exchange Server 2007’s new features and its many improvements over Exchange Server 2003 is going to require a substantial investment. Unlike previous upgrades, Exchange Server 2007 requires the complete replacement of existing 32 bit servers with 64 bit hardware and software, in effect rendering previous investments valueless, while demanding a steep infusion of new capital. In addition, new options for server roles and high availability will require many organizations to rearchitect their entire Exchange environment — a task that will be expensive to implement in most enterprises. There are also the inevitable concerns about whether there are going to be additional needs for security, high-availability, archiving, and compliance features that are businessand industry-specific and that Exchange Server 2007 can’t provide. To the business-oriented person, purchasing and implementing Exchange Server 2007 isn’t quite so inevitable. The price tag is steep, the benefits are not always clear, and the value of most features is somewhat hazy. They’re not really sure that this is a good idea and resist until someone can show them otherwise. Too often IT personnel can respond to these business-based questions with only a blank stare. Too often IT personnel show a marked lack of ability to operate within the business environment. They might even resent the managers and other nontechnical business personnel as mere ‘‘bean counters.’’ By comparison, the rest of the organization might see the IT staff as ‘‘geeks’’ or outsiders. It’s clearly not the best of both worlds. What to do? This book casts you in the role of an IT project manager responsible for creating and implementing an Exchange Server 2007–based messaging system. To be successful, you’ll have to learn to straddle the divide between ‘‘geeks’’ and ‘‘bean counters.’’ To do that, you’ll have to understand the business-oriented approach to IT.

2

CHAPTER 1 MASTERING THE BUSINESS-ORIENTED APPROACH

The Past as Prologue The role of IT in the business environment started off humbly enough. In most companies, today’s IT manager was ‘‘the computer guy’’ of yesterday, pocket protector and all. Back in the 1970s and into the 1980s, these future managers were typically rulers of backroom fiefdoms that were rarely concerned with business decisions and objectives, and the business rarely involved itself with them other than as a necessary expense like company vehicles, medical insurance, or typewriters. The early IT centers were called ‘‘data processing centers,’’ and their principal task and primary value to the organization was their ability to automate transactions. The smart companies that were successful understood that information about transactions would be as valuable as the physical goods themselves. Data processing soon evolved to management information systems/services (MIS), as companies realized that someone actually needed to manage their burgeoning computerized underbellies. MIS eventually shrunk to just IS (although the dual meaning — information services and information systems — remained). Expectations for IT rocketed in the mid-to-late 1990s as large enterprises spent millions on massive implementations. IT budgets grew by leaps and bounds, and money was spent by the barrelful without much question. There wasn’t even much oversight or concern about wastage. IT budgets and expenses became as profligate as that of the Department of Defense with about as much accountability. There were a number of reasons for this. First and foremost was the belief that large IT investments would provide large returns and create major competitive advantage. The seemingly unstoppable and never-ending wave of new hardware and software innovations coming out throughout the 1980s and especially the 1990s fueled that belief. IT and computers were here to stay, went the reasoning, and business’s faith in its IT staff and their solutions was unshakable and blind. Computerization and its widespread adoption revolutionized the nature of work and contributed dramatically to the boom of the world economy throughout the 1990s. Many things that were unthinkable were suddenly doable.

Note This book, for example, was written over the past few months in Saudi Arabia, New York, Connecticut, and the outskirts of Petra; transmitted to California; edited and reviewed there; and put into production in New Jersey. Reviewers were scattered all over the world, including the Isle of Man, Malta, Indiana, and elsewhere. Globe-reaching collaboration of this type would never have been possible without IT. Then the tide that had raised all the boats rushed back out. First, there was the hype about Y2K and its associated impending disasters — which turned out to be a nonevent. Eyebrows were raised, and there was the sudden sense that perhaps the emperor had no clothes. Dot-coms boomed and then busted and the NASDAQ went into free fall. Hardware and software innovation slowed. The security — or rather lack of it — of databases and systems was embarrassingly and frighteningly highlighted as virus and Trojan onslaughts brought businesses to their knees. Even mighty Microsoft itself was humbled by the Slammer worm assault on its servers. The emergence of outsourcing, and then offshoring, undercut IT’s organizational ability to take advantage of new web-enabled technologies because it had thinned out the ranks of its programming and application development staffs. It was ‘‘a perfect storm’’ that led to a deep and widespread dissatisfaction with enterprise IT.

UNDERSTANDING BUSINESS VALUE

In boardrooms across the country, IT’s budget, technology investments, and basic worth were being questioned. The value of IT was suddenly a topic for debate. Every system, every application, and every IT project once labeled mission critical were put under the microscope and, in many cases, found wanting and too expensive. Business’s belief that ‘‘We can’t do anything without IT’’ quickly changed to ‘‘How much can we do without IT?’’ An article by Nicholas Carr appeared in the May 2003 Harvard Business Review, titled ‘‘IT Doesn’t Matter,’’ followed by his book the following year, Does IT Matter? His answer was a resounding ‘‘no.’’ In the past few years, a new model has emerged for the successful IT manager. The IT manager has to straddle both worlds and approach IT as something that brings value to the business; he or she has to be prepared to answer the questions ‘‘Why should we do this? What’s the business reason? Where is the business value?’’

The Natural History of the Computer Over the centuries, technological innovation has spawned changes in how and where people live, play, work, and provide for their families. The late Harvard Business School professor Jai Jaikumar described how fire, the wheel, the lathe, the steamboat, the locomotive, the automobile, the telephone, and the airplane were transformational inventions. But his research shows that societies generally took 30 to 40 years to understand the possibilities of these inventions and leverage their use. In the early 1980s, Jaikumar described the invention of the computer as a transformational technology. He predicted that the computer would go through infancy, a childhood, and an adolescence before eventually reaching maturity. He estimated that this cycle would take a full human generation. If Jaikumar was correct, as it seems he was, then the computer age is now leaving its adolescence and will enter adulthood during this decade. That will require a new attitude and approach.

Understanding Business Value Very often, when I speak to IT and non-IT personnel, I am struck at how references to ‘‘the business’’ usually exclude IT and technology teams. The two are seen as separate entities and IT is somehow not part of the business. It’s a peculiar perception since technology is basically a strategic business tool designed to gain market share and advantage. Thankfully this mindset of ‘‘us (tech) vs. them (the business)’’ is starting to change in the current business lexicon. The simple reality is that ‘‘the business’’ includes IT as integrally as it includes sales, marketing, finance, and human resources in the organization. To successfully build an Exchange Server 2007–based messaging system or any IT project, you have to promote and understand its value to the business. In your discussion and your design, you must remember that IT is a business enabler, not an entity that exists in a silo. Approval is not automatic, and you must prove your business value. Let’s take a look at some of the ways that IT provides value to a business and why you need to be able to discuss the new messaging system in that context.

A Short Quiz If you want to add value to your business or organization, be it through an Exchange Server 2007–based messaging system, another IT technology, or something as mundane as changing the company’s website design, you need to know what its business is. You may be puzzled at this

3

4

CHAPTER 1 MASTERING THE BUSINESS-ORIENTED APPROACH

statement. ‘‘Of course, I know what my organization’s business is all about,’’ you may be thinking. ‘‘What a silly comment!’’ Indulge me then and see how many of the following questions you can answer: ◆ What is your company’s mission? ◆ What is its competitive strategy and position? ◆ What are its sales numbers and profitability? ◆ Who are the company’s key clients? ◆ Is it publicly or privately held? ◆ What’s its share price and direction? ◆ What is the company’s organizational makeup and who are its key managers? ◆ What is its history? ◆ What are its strategic priorities for the coming year? ◆ How are managers compensated and motivated? If you’ve come up with a few blanks, don’t worry too much — yet. This business awareness deficiency, sad to say, is very common, if not universal, among many budding managers and consultants. But you need to change it if that’s where you’re at. The first reason is that these are important issues to executive and corporate leadership, and if you demonstrate a glaring lack of knowledge about them, then this insufficiency will raise eyebrows. ‘‘How can this guy deliver a solution that contributes to my business without knowing anything about it?’’ The second reason is you can’t speak to them if you can’t speak to them in their language. You must find common ground. What better place then to come together than where you have a vested and personal interest — the company’s ability to earn a profit and meet its objectives.

Aligning IT with Business Values There are any number of white papers, books, and articles on the subject of alignment, making it appear to be an arcane art form practiced by those dabbling in the Dark Arts. I’ve always wondered why something so simple is made so difficult. The concept is simple and logical: for any business to be successful, it has to make money. Any activity it undertakes should help promote its revenue production, promote its fundamental mission, and adhere to its goals. In other words, your Exchange Server 2007–based messaging system must contribute to and enhance the business. Every organization has principles, plans, strategies, goals, and values. You must assure first yourself, and then management, that the project will help or support the business’s pursuit of these values. How do you do that? It needn’t be difficult. First, find out what’s needed. Ask your internal clients what their needs are and whether your IT organization or project is focused on these issues. For example, make sure that your Exchange Server 2007–based messaging system is going to deliver the communications features that the organization needs, wants, and can afford. Next, validate your plans. Unless you’re perfect (in which case you should be in a different line of work anyway), I’m sure you’ve been wrong before. Have you ever thought you knew an answer to something but when you asked questions about it discovered that your answer was ‘‘off center’’ or completely wrong? If so, then validation is for you as it is for all mortals.

UNDERSTANDING BUSINESS VALUE

We all have the ability to size up a situation and come up with a technology strategy to address that situation. But, the solutions you and I develop for an issue can be very different. Both solutions may work to resolve the issue, but one of these solutions may be totally inappropriate for the company at the time. The only way to know this is to develop a specific IT plan, or strategy, that addresses the key technology issues you have identified in the company. The plan needs to identify the issues you are addressing, the IT initiatives you plan to execute and their priority, the benefits expected to achieve, resources required, and the cost of your plan.

Note Chapter 2 will review how to determine business requirements; Chapter 3 will show you how to go about writing a plan for your proposed infrastructure.

Once it is completed, you should present the plan to the senior management team and ask for their validation in at least these areas: ◆ Does this plan address the company’s critical needs? ◆ Do the initiatives appear to be prioritized appropriately? ◆ Do they agree with this plan and will they support it fully?

Taking Fiscal Responsibility At the top of every CEO and business owner’s mind is the fact that for every dollar coming in, a portion is going out as a cost. Studying that equation can help you discover ways to save and generate revenue. As I mentioned earlier, one of the greatest problems is that very often IT staffs do not have a good understanding of how their company makes money or how IT enables the company to make money. This handicaps them badly in the area of ‘‘fiscal responsibility.’’ Fiscal responsibility should be considered a critical and mandatory part of any IT project. By fiscal responsibility, I’m not talking about simply slashing costs or exercising a frugality that would make Scrooge McDuck look like a spoiled spendthrift heiress. Fiscal responsibility means the ability to show how IT affects revenues, profits, costs, customer service, sales, manufacturing, and everything else under the business’ umbrella. It means talking about and looking at IT entirely in business terms. This is a complete change from the way IT was perceived 20 years ago when it was seen as an expense that was usually resented and almost never fully understood. To avoid this lack of clarity of what fiscal benefits your project brings to the company, you should do the following: ◆ Explicitly define the products and services the project will provide. This listing must be comprehensive and at a level of granularity that portrays specific client purchase decisions. It’s not sufficient to define high-level categories, which don’t portray all the many things IT does within each category. For example, ‘‘email’’ is too broad. A full list would distinguish a basic email account, extended storage, and PDA forwarding as three distinct services. ◆ Define exactly what the budget pays for and how much. For example, you could specify the cost of basic email for everybody, extended storage for only the customer service department, and PDA forwarding only for executives. Additionally, you can summarize the cost by application for each major project, for necessary repairs and patches, and for

5

6

CHAPTER 1 MASTERING THE BUSINESS-ORIENTED APPROACH

discretionary enhancements. Breaking out the budget in such a way makes it clear exactly what IT delivers (and, by implication, what it doesn’t). The final aspect of fiscal responsibility refers right back to the fundamental question: ‘‘Is this IT project (or IT in general, if you prefer a global approach) contributing to business value? If so, how?’’ Remember the object of this exercise is to ensure that the enterprise is spending the right amount of money on the project and that the project money is being spent on the right things.

Learning about the Business Learning how your company does business and makes its money is extremely important to your role as a project manager and to the overall success of your project. You’re not going to go through the amount of work it takes to develop a successful plan and conduct a successful implementation so that the project fails or is perceived as a white elephant. You, and your business, want it to be successful. Another advantage in knowing where the money comes from and where it goes is that you are better able to see opportunities to help the company. You can then use that information to generate new innovations and revenue opportunities. Your focus is better directed toward business goals, and hence your contributions are more valuable and useful. It also helps increase the value of IT to the organization as a whole. How can you obtain that knowledge? Here are a few suggestions: ◆ Find copies of the organization’s annual reports, stock prospectuses, and any other publication or document you can get that describes its activities. Study them until you are comfortable with what the business is all about. ◆ Visit financial officers and interview them about the business. ◆ Try to observe and interact with every level of the business. For example, observe how users use the current messaging system. Can it be improved? Are there new features that you should integrate in your system because they can increase revenue, reduce cost, or improve overall productivity? ◆ If you have a weak background in business and finance, read books and take classes. Often your company will reimburse you for successful completion of these courses. ◆ Talk to other successful IT project managers both within and outside the company. ◆ Read trade journals and magazines. Following these procedures won’t guarantee the success of your project. Only you can do that. It will however help you orient your project toward the business’ needs and improve its chances of widespread acceptance and use — the real hallmarks of a successful project.

The Runway No One Wanted Lambert-St. Louis International Airport Runway 11/29 was conceived on the basis of projections made in the 1980s and 1990s that warned of impending strains on the airport and the national air traffic system as a result of predicted growth in traffic at the airport. The $1 billion runway expansion was designed in part to allow for simultaneous operations on parallel runways in bad weather.

WORKING WITH NONTECHNICAL MANAGERS

Construction began in 1998 and continued even after traffic at the airport declined following the 9/11 attacks, the purchase of Trans World Airlines by American Airlines in April of 2001, and subsequent cuts in flights to the airport by American Airlines in 2003. The project required the relocation of seven major roads and the destruction of approximately 2,000 homes in Bridgeton, Missouri. In addition to providing superfluous extra capacity for flight operations at the airport, use of the runway is shunned by fuel-conscious pilots and airlines because of its distance from the terminals. John Krekeler, one of the airport commissioners, eventually called the project a ‘‘white elephant’’ — a rare, expensive possession that is a financial burden to maintain. The moral to this story is to always make sure that your project and plans are in alignment with business needs. You should always assess changes in the business environment that effect the requirements or even the need for the project.

Working with Nontechnical Managers You have been named the project manager for your company’s Exchange Server 2007–based messaging system because you are technically competent. You may not, at this point in time, fully understand everything there is to know about Exchange Server 2007, but you can learn it in short order and use your technical savvy to execute the project. Along the way, you are going to have to work with nontechnical managers and users. There is no getting around this; it is something you are going to have to do. The quality of your relationship with nontechnical managers is the key to your project’s success and your personal job satisfaction. The key components of a successful relationship with nontechnical management are communication, and setting and meeting expectations.

Ensuring Good Communication Typically, management, as well as the managers you work with, are principally concerned with whether you (and your team if you have one) can accomplish what they need when they need it. They don’t have a large interest in the technical details of what you will need to do. They expect you to know them and figure out how to make it work. It is a good idea to make sure that any deadlines you set for yourself or your team are on the pessimistic side. It is generally better to give pessimistic estimates and surprise people by being early than to disappoint management by being late. Be careful, however; if this is taken to extremes, management and nontechnical managers will start to consider you obstructive. They will also be unable to commit to meeting their own deadlines and may go around you to make things happen. The people overseeing the project expect you to meet the deadlines they set for you. They do no want to have to deal with complaints relating to you or your team. They want to know that they can delegate things to you and that those things will be accomplished on schedule. Hence, if you won’t meet a deadline or accomplish a task, be sure to advise the management team as soon as possible so that they can manage the impact of a slipped schedule. You will be expected to set direction for the project based on company objectives. If senior management asks you for a status report, they want to know how you are doing meeting the requirements, goals, and deadlines that were set and agreed to. The technical details don’t necessarily interest them, only the bottom line. If, on the other hand, they ask you to go into depth on technical points, don’t be afraid to drill down to the minutest details. Trust me, if you go too deep they will stop you. Be definite and precise and avoid generalities. You really don’t baffle them with BS despite how clever you might think you are, but you do annoy them and mar your reputation.

7

8

CHAPTER 1 MASTERING THE BUSINESS-ORIENTED APPROACH

Warning ATTORNEY: Is your appearance here this morning pursuant to a deposition notice which was transmitted to your attorney? WITNESS: No, this is how I dress when I go to work.

Budget issues should always be discussed and changes or requests justified in terms of how the items will help the company meet its goals or help your project team meet the goals that have been set for it. Management will need to be kept updated about the large-scale tasks that are being worked on at the time; other managers will need this information so they can update peers and superiors with the correct information. This updating is also important if you want to keep you and your project team from being overburdened with extra work. If management doesn’t know what the group is doing and how the resources allocated to it are employed, they may assume that you have excess manpower or material and volunteer you or your team for extra work, to the detriment of the project. So fill out those monthly reports!

Condescending Jargon: Handmaiden of Contempt ‘‘Yesterday we jury-rigged the Edge Transport Server’s Jefferies Tube to increase security by a factor of 12,345,678 killkens.’’ You probably wouldn’t say that since it doesn’t mean anything. But a lot of technical jargon is just gibberish to a nontechnical manager or user. If you’re in the habit of saying something like ‘‘the blade server died’’ or ‘‘the mailbox store was corrupted’’ or ‘‘some idiot applied a patch’’ then you’re spouting gibberish — but they did catch the word ‘‘idiot.’’ As a project manager (this actually applies to any technical person) you need to learn to write and speak language that makes sense to people without being condescending. How do you do that? Simple, put yourself in the shoes of the other person. While you’re preparing a message on some aspect of the project, stop and ask yourself, ‘‘What is the user going to think when he reads this message?’’ If your answer is ‘‘he’ll have no idea what this means’’ then rewrite the whole message or portions thereof. Failing in basic communication leads to a failure for the whole group. When reasonable people in your organization simply don’t understand what’s being said by the IT group, there is a lack of trust and alignment taking place. ‘‘IT people make me feel stupid’’ simply means that the IT group will not be used to their fullest. It also appears condescending, the handmaiden of contempt. Want to turn someone off completely? Make them feel you think they are beneath you. That’s what jargon does. It also helps to perpetuate the myth that the IT pro is some kind of arrogant, out of touch person. That’s not going to help the project or your career.

MANAGING THE PROJECT TEAM

Knowing the Requirements A basic expectation nontechnical managers have of technical personnel is that they know the requirements behind the tasks they are performing. In the case of a project such as creating an Exchange Server 2007–based messaging system, this means understanding what the business needs, how the services will be used, how it needs to scale, and so on. This is critical, and Chapter 2 is devoted solely to determining business requirements. Knowing the requirements and keeping them in front of you as you work helps keep you and your team focused on the specific problem at hand. Management expects you to use the requirements to direct the project so that it meets its goals on time and on budget and at the expected level of quality. Staying focused on the requirements serves as an ongoing guard against scope creep. Communications with management should be based on the requirements as well. For example, you may be asked why you are doing a task one way rather than another. If you believe that your approach is better than what the other person proposes, use the requirements to express the why of what you’re doing. For example, instead of saying ‘‘it’s a better design,’’ explain which requirements led you to choose this design rather than the other one. Explain how the selected design is easier to support, how it interoperates more efficiently with other services, how it scales to the required size, how it has higher availability, or how it simply has more of the required features. Even if you think you’re saying too much don’t worry, it’s probably information they will appreciate having. Overcommunicating is better than undercommunicating. Showing you know what you are talking about and have thought things through enhances your reputation and standing. That in turn reduces the number of questions you will get in the future. As the project progresses, you will eventually be able to gauge the amount of information that each individual prefers. Understanding user requirements is a significant part of the project. Finding out what these needs are involves asking the right questions and listening to the answers. Always ask for clarification when necessary. The process of gathering user and business requirements provides you with an opportunity to build a cooperative relationship with users and management. It should also be used as a platform for providing feedback and setting realistic expectations, a topic that is expanded on further in Chapter 8. Clearly identifying the requirements and using them to direct your work and that of your team will result in faster problem resolution and better services, with happier results for all concerned.

Managing the Project Team For the purposes of this book, it’s not particularly important how you came to be named the person responsible for the development of the new Exchange Server 2007–based messaging system. The assumption is made that you were selected for the role by senior management because it was felt that you were prepared for the role. This may be your first or your fiftieth project. Except in the case of a small or medium-sized business, where it might be possible for you to create the messaging system completely by yourself, you will most likely be in charge of a project team. Creating this project team is simple in concept and difficult in execution. All you have to do is create a detailed job description of each project role and appoint a human resource to each role based on relevant skills and experience. Of course, it’s never that easy. In the case of ad hoc and temporary teams, such as the one you’re gathering, it’s easy to be seduced by the idea that you have done what is needed by simply organizing the team. If you don’t give much thought to the process until a problem arises, then it’s too late.

9

10

CHAPTER 1 MASTERING THE BUSINESS-ORIENTED APPROACH

Preventing a problem at the beginning of the project requires little effort and is much preferable to solving it in the middle of the project when it will demand a higher cost in time and energy. Because your project team is likely to be together anywhere from 6 to 12 months, getting it set up correctly at the beginning will pay enormous dividends throughout the project. These are the four essential elements of all successful teams: ◆ Choosing the right people ◆ Providing excellent project management ◆ Having clear goals ◆ You Let’s examine these simply stated, but complex to execute elements and see how you can use them to assemble the best project team.

Choosing the Right People These are the five factors of effective team members: ◆ Expertise ◆ Respect ◆ Problem-solving skills ◆ Openness ◆ Ability to support the group Team members will usually be selected from throughout the organization, or brought in as contractors, because of their knowledge of the technology. If the project team includes non-IT people, such as representatives of finance, the users, or marketing, they must reflect the expertise of the groups they represent. They must be well respected throughout the organization. If the person is isolated, he or she is not going to be a good conduit to pass information in either direction, or ideas the individual brings back form the project team will not be listened to, and even less accepted. At the same time, information about critical business needs will not be heard by the team. It is also essential that you guard against ‘‘dumping.’’ It is often tempting for another manager to view a new project team as a way to solve performance or personnel problem by assigning that person to your team. Only rarely will this tactic work to your advantage. Typically, it has the effect of negating the credibility of the project by undermining the five factors above. For a successful project, insist upon the best people. There is no way around it. Team members must be good problem solvers as well. The ability to analyze and troubleshoot issues in a systematic, logical manner is a key factor in the team’s success. Chapter 11 contains a section on troubleshooting methodology that you may want to adapt for use by your team members. Every team member has to be able to listen to the others and understand their point of view. Because your project team will be composed of members from different departments and disciplines, each may speak a different business language. Each will also have differing perspectives and approaches that must be respected. The best team members are those that are open to viewpoints other than their own. ‘‘I never looked at it that way before,’’ is a good indicator that the team member is open to new ideas and respectful of other opinions. That doesn’t necessarily mean that he or she agrees. In fact, they may disagree completely. But they are persuasive and nondefensive in stating their viewpoint. They can explain and illustrate their own

MANAGING THE PROJECT TEAM

view and question assumptions (including their own). They have the ability to walk in other member’s shoes and thus are able to help the team reach consensus while avoiding the phenomena of group think.

Group Think Group think, first described by psychologist Irving L. Janis, is the process by which groups of intelligent people make terrible decisions. Group members try to minimize conflict and reach consensus by not critically testing, analyzing, and evaluating ideas. When group think happens, members of the group avoid promoting viewpoints outside the comfort zone of consensus thinking. A variety of motives for this may exist such as a desire to avoid being seen as foolish, or a desire to avoid embarrassing or angering other members of the group. Group think may cause groups to make hasty, irrational decisions, whereby individual doubts are set aside, for fear of upsetting the group’s balance.

Eight Main Symptoms of Group Think These are the eight main symptoms of group think: Illusion of invulnerability overly optimistic. Collective rationalization thinking.

Members ignore obvious danger, take extreme risk, and are Members discredit and explain away warnings contrary to group

Illusion of morality Members believe their decisions are morally correct, ignoring the ethical consequences of their decisions. Excessive stereotyping group.

The group constructs negative stereotypes of rivals outside the

Pressure for conformity Members pressure any in the group who express arguments against the group’s stereotypes, illusions, or commitments, viewing such opposition as disloyalty. Self-censorship

Members withhold their dissenting views and counterarguments.

Illusion of unanimity Members perceive falsely that everyone agrees with the group’s decision; silence is seen as consent. Mindguards Some members appoint themselves to the role of protecting the group from adverse information that might threaten group complacency.

The Bay of Pigs One of the best-known examples of group think was the decision-making process that led up to the 1961 Bay of Pigs invasion. The main idea of the Bay of Pigs invasion was to train a group of Cuban exiles to invade Cuba and spark a revolution against Fidel Castro’s communist regime. The plan was fatally flawed from the beginning, but none of President John F. Kennedy’s top advisers spoke out against the plan. Kennedy’s advisers also exhibited the classic characteristics of group think; they had all been educated in the country’s top universities, causing them to become a very cohesive

11

12

CHAPTER 1 MASTERING THE BUSINESS-ORIENTED APPROACH

group. They were also all afraid of speaking out against the plan, because they did not want to upset the president. Janis felt that Kennedy’s top advisors were also unwilling to challenge bad ideas because it might disturb perceived or desired group concurrence. The president’s brother, Attorney General Robert Kennedy, took on the role of a ‘‘mindguard,’’ telling dissenters that opposition and counterargument were a waste of their time, because the president had already made up his mind. At one crucial meeting, the president called on each member of his National Security Council for his vote for or against the invasion. Each member, that is, except presidential adviser Arthur Schlesinger whom he knew was opposed. Many members assumed that other members agreed with the invasion plan and went along rather than appear obstructionist. Of the 1,400 invaders, 1,200 were captured with remainder either escaping or being killed.

The Missile Crisis Interestingly, it was Kennedy’s recognition of the failures of the process that led to a completely different approach to the following year’s Cuban Missile Crisis. Kennedy revised his group decisionmaking process to encourage dissent and debate. He challenged military leaders who pressured him to bomb and invade. He heard the CIA’s case for air strikes and Stevenson’s counsel for negotiation. Advocates for different views developed their arguments in committees, then met back together. Robert Kennedy later wrote, in Thirteen Days: A Memoir of the Cuban Missile Crisis, ‘‘The fact that we were able to talk, debate, argue, disagree, and then debate some more was essential in choosing our ultimate course.’’ As a result, the world wasn’t destroyed in a nuclear war. The final characteristic that makes an effective team member is the ability to support the group or project leader’s decision fully. The person can put aside any personal reservations or feeling once the decision is made. This does not mean that they should not continue to work to bring to attention decisions they believe are unwise. However, having had their say and heard the opposing viewpoints, they must set aside their own desires for the good of the whole. They also need to be able to communicate the project decisions back to their organization clearly and convincingly.

Providing Excellent Project Management As project leader, you will bear the responsibility for the success of the project and the demands placed on it. These are the keys to effective project management: ◆ Discipline ◆ Structure ◆ Diplomacy ◆ Performance management Team members are also responsible for ensuring that these elements are effectively applied. If each member reminds the others of these four elements, the resulting ‘‘shared leadership’’ helps the group stay on track.

Discipline Discipline is the ability to direct the project team, provide support to the team, and manage differences within the team.

MANAGING THE PROJECT TEAM

Directing involves such basic task-oriented activities as these: ◆ Clearly communicating the desired outcomes ◆ Setting and enforcing deadlines ◆ Keeping the team on track ◆ Encouraging participation from all members and avoiding dead wood While directing is task oriented, supporting is more about doing things that build and maintain relationships. As project leader, you must listen to all team members to understand their differing opinions and viewpoints. You may have to help them clarify and refine their thoughts. You will need to provide equal time for minority and dissenting opinions. Good support also requires confronting a team member’s approaches or attitudes when they are not helpful to others or create distractions that move the team off its focus. Managing differences doesn’t mean imposing your will. It means encouraging and allowing productive conflict that exposes all viewpoints so that an informed decision can be made. It means treating all input as valuable. One person, for example may argue for an approach that rapidly cuts costs. Another may argue that change needs to be in a phased rather than rapid manner. As project manager one of your key jobs will be to help team members in developing their positions and opinions for presentation to the group. The Greek philosopher Socrates said that to ‘‘know yourself’’ was the most important thing a person could do. You will do a better job at managing differences if you are aware of your personal biases. You should also help others become aware of theirs. One team member, for example, may have a bias toward the simplest approach to a problem, and another may prefer to provide as many choices as possible. If individuals realize these differences are not essential to success, but are merely preferences, conflict can be minimized.

Structure You are also responsible for providing structure for the team members. You can create structure through these activities: ◆ Project methodology tools ◆ Team meetings ◆ Communications outside of the team There are a number of effective project management tools available, including Microsoft Project. Whichever tool you opt to use it should include time lines, task breakdowns with team member assignments, task interdependencies, and an indication of the critical path. It takes discipline to use a project management tool well. Updates must be entered in a timely fashion and changes made when they occur. There is no benefit to going off on a sidetrack to gather enough information to make a proper decision without adding the task to the chart. That way, you will see the changes in the timeline, and you do want to see them, even if the news is not good. Meetings must be organized events. Each one should be scheduled, with an agenda and expected outcomes. A useful, though underused, approach is to set an agenda with time frames for each segment. For example, an announcement could take 5 minutes, questions to clarify it could take 10 minutes, and the discussion could be set for 30 minutes. When the discussion reaches the 30 minute mark with no signs of any conclusion, the meeting should pause. The attendees should then decide how much more time should be allotted to finish the discussion and what to do about

13

14

CHAPTER 1 MASTERING THE BUSINESS-ORIENTED APPROACH

the remaining items. Do not decide that five minutes more will complete the subject, because it is usually not adequate. Meeting minutes should be taken and shared with all attendees, as well as other team members who may not have been present. They should be filed as part of the documentation of the project. Communications to others outside of the project team should also be structured in order to ensure that the focus continues to stay on the overall goals. Another purpose is to keep management, users, and customers aware of the impending changes. Assess each potential communication method (for example, correspondence, meetings, briefings, websites, and newsletters) for its ability to deliver the correct message to the correct audience. You should maintain records of when each was used and by whom. Reviewing the records allows you to see where gaps in your coverage are. Overlaps shouldn’t be a concern, but you don’t want to overburden people in the company or they will simply tune out once they reach a saturation point. One advantage of these techniques is that you will create a sense that the complex and difficult project process is under control and being managed well. You may not always feel that way and your team may occasionally have its doubts, but having a structure will help get you and your team through those moments of self doubt and worry.

Diplomacy My mother was fond of reminding me that you can catch more flies with honey than you can with vinegar. I took the lesson to heart though I have yet to understand why I was supposed to want to attract flies. Diplomacy is one of the key skills that you will need to manage your team and, of course, your relationships with the rest of the company. The most difficult aspect of any project, especially one that involves fundamental changes such as an Exchange Server 2007–based messaging system, is that it inevitably creates political issues that have to be dealt with. What that means is conflicts and opposing points of view need to be identified and resolved when they occur, all while avoiding doing anything that can cause unwanted changes to schedule, budget, or scope of the project. To do that, you will have to deal effectively with intra-team conflicts, cross-functional issues, and managing senior management. The art of diplomacy turns on the ability to manage conflicts early and rapidly. If left to fester, they will become more intractable and far more difficult to resolve. Success means that you will have to resolve these conflicts in a way that is perceived as fair and firm. The sales senior vice president who will lose her battle for PDAs and Outlook Anywhere in Chapter 9 will, if you do your job properly, realize the greater good for the company by the decision and feel that you listened to her concerns seriously even though the decision was not what she preferred. You also need to guard against one of the sources of real difficulty, conflicts you are unaware of. Think of the difficulties in your own life when a spouse or partner is upset with you and you don’t know it. The resulting explosion is extremely unpleasant. It is also much easier to address and manage overt resistance or problems far easier than covert resistance and unknown difficulties. For this reason, you and your team members should spend time with the various user managers explaining the system and gaining their confidence. These managers will be more likely to raise concerns before they become life and death issues. Dealing with senior management is usually more an exercise in influence and suggestion, rather than direction. Senior managers are not likely to be personally involved in every twist and turn of the project. But don’t think that means you can simply disappear into the bowels of the project office and expect things to run smoothly with them. First, if you’re out of sight, you’re likely to be out of mind — and that is very, very dangerous for the health and success of the project. Senior managers may have every good wish for the

MANAGING THE PROJECT TEAM

success of the project, and the active championship by the designated executive sponsor will be important, but by not communicating with them directly, you risk your project being considered irrelevant. This doesn’t mean that you have to constantly be in their offices, but it does mean that you need to be proactive in communicating with them. You should make a point to frequently meet or otherwise communicate with senior management to discuss the status of the project and report significant successes or potential problems. A senior manager will usually have to be coached as to what to say in a public forum about the project, and perhaps even handed a script or brief outline (never more than one page) about the essential facts of the project. The executive sponsor and other members of management friendly to the project are your best potential allies. Cultivate them.

Failed Diplomacy and Successful Intervention In one implementation project I worked on, the project manager had grown increasingly frustrated with what he perceived as the lackadaisical attitude of the user managers. Virtually none attended the project review meetings; few had taken any of the online training and he was frustrated to the point that they did not fully understand the implications of the changes he was asked to complete. As a result, he sent out an email stating that in order to meet project goals the user managers and their key personnel had to attend a series of ‘‘mandatory training sessions.’’ The project manager, who was new to the company, did not realize that in that particular corporate culture ‘‘mandatory’’ was a word with a coercive and negative connotation. His email and training sessions were seen as high-handed and out of line and earned much resentment. Within 30 minutes of the project manager’s email establishing the dates of the sessions, the executive sponsor for the project sent out his own email supporting the need for everyone to gain a better understanding of the system and requesting that everyone sign up to attend the informational meetings. The email reinforced the project manager’s required training, emphasized management’s perception of the project as important, and at the same time defused any resentment by restating the requirement as a request. The morals to the story are that you need to understand the corporate culture, you must exercise diplomacy, and rapid support from the executive sponsor is a valuable ally.

Performance Management One of your most important duties as project manager is to ensure that clear, obtainable objectives are set for each team member. Regular status checks with the team members, individually or collectively, will help you discover any missed deadlines. When the problem is a lack of training, that need must be met immediately. More likely, the cause is an overload of work that causes the team member to be unable to complete a task on time. When this is the case, the schedule must be assessed to see if tasks have too many subtasks or were not evaluated correctly in the first place. You must stay on top of such problems and troubleshoot them immediately. Don’t try to hide or laugh off missed deadlines. If you determine that the cause isn’t lack of training or an excessive workload, then you need to take other steps. No matter how nice you want to be, any inability to perform must be assessed and dealt with decisively so that the overall project schedule is not negatively impacted. This requires a combination of empathy and strictness.

15

16

CHAPTER 1 MASTERING THE BUSINESS-ORIENTED APPROACH

The key to managing team performance is creating a balance between team and individual responsibilities. For instance, the team may have to come to consensus on a particularly difficult decision that requires full participation from all. Certain team members may need to complete tasks or conduct research to make the decision. It is the team’s responsibility to ensure that the decision-making process is conducted with integrity. It is the individual’s responsibility to deliver his or her assignments on time. The more you can convince team members to manage their collective performance, the easier your job becomes relative to managing individual performance. This balance is accomplished by setting clear goals and expectations, and establishing consistent feedback mechanisms.

Establishing Clear Goals Finally, the project goals themselves must be very clear to everyone involved. Organizations often find themselves in difficulty over this admonition and cannot understand why. The cause may be the difference between the level of understanding in the executive’s mind and in the project team members’ minds. For example, the sponsor of the project may have charged the team to improve the way that the materials management process at one end of the manufacturing process interacts with the daily inventory status at the other end, so as to result in more accurate quotes to the customer. At the initial meetings and in the resulting project definition documents, sponsors and project team members may have believed they had a clear picture of the project’s goals. Difficulties arise when the project team explores the details of what it will take to improve these processes, because the goals may change. The team may find out that to change materials management and inventory, it will have to change the manufacturing system. Since that was defined as outside of the scope of the project, the team members are left with a conflict. They will not be able to make as much improvement as was originally expected because they are constrained by the exclusion of manufacturing.

You: What Can You Do? Even though it’s listed as the last item, you are the most critical aspect in the success and failure of your project team. Working with and influencing your team is a significant part of the job, even if it’s the one you like least. One of your key jobs is to keep the team’s morale high and keep them happy working for you. You also need to encourage them to perform will in the jobs and make sure that they know what’s expected of them. How do you do this?

Be a Good Role Model As project leader, you will influence the behavior of the group by the way you act. If you show up late for work, your team will show up late for work. If you seem to project a lackadaisical and lovely attitude the team will, too. If you are short-tempered and irritable, team members will behave in a similar fashion. On the other hand, if you treat your staff well, they will be attentive to user and customer needs. If you go out of your way to help others or explain things, the team will do the same. What this means is that you should take care to exhibit the behavior you want your group to emulate. Lead by example.

Treat the Team with Respect Aretha Franklin had it right; it always boils down R-E-S-P-E-C-T. Thankfully, treating others with respect is simple; treat them as if they are individuals that have worth, and treat them the way you want to be treated.

MANAGING THE PROJECT TEAM

There are a lot of ways of looking at respect and confidence in another person, but I prefer the simple approach. You give other people respect automatically and without question. You believe in their ability to do whatever tasks and jobs you give them. You should never make or think they have to prove themselves worthy of your trust and respect. A team member should automatically have both until he or she consistently proves unworthy of it. One way you can show respect is by how you address problems or correct mistakes. If the mistake isn’t serious pull the team member aside — never in public — and tell then not to worry about it, that everyone makes mistakes. Permit the team member to consider their error in peace and what they could have done differently. If it was a serious error, reprimand him or her. Then, take the heat for the mistake; he or she is, after all, your team member. The team member will know what you are doing and you will usually find that in most cases the team member will be determined not to put you in that position again. Reprimands should be done face to face and be timely, specific, and about a behavior that needs to be changed. Reprimands should never given in public, unless your intention is to show your lack of respect for the employee and by extension everyone else on the team. Not only will it demotivate the team, but the lack of respect will be mirrored back at you. Another way to show respect is by keeping team members informed about important events that are happening in the project and in the organization in general. Listening is another way of showing respect. Team members need to be able to discuss what is on their minds. They should feel that they can come to you with their problems. Hence, you need to make yourself available to your team. Doing so reinforces that you think their needs are important to you. My mother was also fond of telling me ‘‘Mind your manners.’’ As a project leader this includes, but goes beyond, the simple please and thank you that is required in social intercourse. You need to be polite in other ways. For example, don’t try to force your political or religious beliefs on your coworkers or team members. Another common impolite behavior is to stop talking to someone to answer the phone without asking permission. There is nothing like making the person feel unimportant to show disrespect and project contempt. Finally, avoid micromanagement. It sends the message that you have a lack of confidence in team members’ ability to do their jobs and solve their problems.

Show Appreciation Everyone likes to know that they’re doing a good job. Showing appreciation, even in little ways, helps maintain morale and loyalty. In fact studies have shown that recognition and being made to feel important are bigger motivators than money. An easy way to show appreciation is to keep track of each member’s hire date and do something on their anniversaries. Celebrating birthdays and personal events may be good ideas as well if you have that sort of relationship with your team and your company allows it. Another way is to publicly acknowledge then when they do good work. Your compliments should be specific, sincere, and timely. Vague, late, or insincere, sarcastically delivered compliments are not only insulting, but they can also be demotivators.

Be Positive A good way to create and maintain high morale on a project team is to be positive about the team’s abilities and direction. Let your team know that you believe in them. Let them know that you will do what needs to be done to get them what they need to be successful.

17

18

CHAPTER 1 MASTERING THE BUSINESS-ORIENTED APPROACH

Give Clear Direction Every incompetent project manager I have ever known, worked for, or hired has had one thing in common. They didn’t have a clue what they wanted. ◆ No one on the team understood the division of responsibilities within the project. ◆ No one on the team knew what was expected of them. ◆ Team members were given inconsistent and contradictory instructions ◆ Mind reading was an expected job qualification Why? Primarily because the project manager lacked the ability to communicate well and was incapable of recognizing it. Never assume that you are communicating well because you know exactly what you want. It is not always obvious to others. If you think that you are giving clear direction about what you want but aren’t getting it from the team, it’s almost certainly not their fault. You are probably not explaining yourself clearly. If you believe that you are explaining yourself but still aren’t getting the results you want, ask the team member to explain back, in detail, what it is the team member thinks you want. This can lead to a useful dialogue if there is a misunderstanding. If there isn’t a misunderstanding, then at least you know there is problem and can deal with directly. It’s a lot easier and more efficient than repeating yourself over and over again.

Note If you want to get a sense of what you’re doing right and where you might be going wrong, Appendix A contains a series of four questionnaires for assessing team behavior. These can help you gauge whether your team is operating at optimal effectiveness and provide you with important clues on how to correct the errors.

Bring Me a Rock The lack of clear direction is best explained by illustration. In the ‘‘bring me a rock’’ school of leadership and project management, conversations usually go something like this: A team leader says to a team member ‘‘Bring me a rock.’’ The team member dutifully brings a ‘‘rock.’’ ‘‘No, no! Not that rock! I wanted a rock!’’ says the project manger in an exasperated tone. The team member dutifully brings another ‘‘rock.’’ The project leader looks at it and says, in a slightly shriller tone, ‘‘No, no! Not that! I wanted a rock!’’ and mutters to herself but loud enough to be heard, ‘‘Doesn’t anyone around here know what a rock is?’’ Once again the team member goes off and this time comes back with three rocks, thinking one of them might be the right answer. And again the same result.

SUMMARY

Over time team members, if they are lucky, usually figure out what the project manager is looking for when they ask for a rock. That is, of course, if the project manager is consistent about the types of rock she likes. The rock could be a style of writing, a way of laying out project proposals, a budget request, and so on. The result of course is that nothing gets done except the hunt for just the right rock. In some cases, this is because the manger has a perverse and twisted sense of self-importance; in others, it’s because of an inability to give clear directions. In all cases it is destructive to an organization’s ability to accomplish its goals.

Summary As you’ve discovered in this chapter, a business-oriented approach to creating the infrastructure for an Exchange Server 2007–based messaging system involves considerably more than simply purchasing a few installation DVDs and the proper hardware. It is going to call on a number of ‘‘soft skills.’’ The reason for this is obvious. The role of technology, especially IT technology, is to support the business. The reason that you are going to do the things that you are doing is to help your organization reach its goals. At the end of the day if the organization’s decision makers aren’t convinced that this is the correct solution and that they can accomplish their corporate goals with tin cans and string, they will cancel your project and invest in the latter. As a project manger, you are going to have to master the art of aligning your project with the company’s business and showing how your solution will provide value. You are going to have to earn how to negotiate, demonstrate, be diplomatic, and think like a user, financier, and manager. You will need to understand the business environment that you are working in as well as you understand the technical aspects of Exchange Server 2007. You will need to enhance your people skills. If you are heading up a project team, you’ll need to understand how to get the best from others. The first place to start on this complex, but ultimately rewarding, journey is determining exactly what it is your business needs and wants in its Exchange Server 2007–based messaging system; that’s what the next chapter is about.

19

Chapter 2

Determining Business Requirements You can’t always get what you want. And if you try sometime you find You get what you need. — The Rolling Stones IT personnel, including designers, often focus on only the technical issues that surround a design project and neglect the business-side issues. This is a narrow and inherently incorrect approach to any design process. With Exchange Server 2007, as with any technology, you should clearly define the types of business problems you‘re trying to solve before you even think about implementing solutions. The first step is to determine what your enterprise needs. Simply saying ‘‘we can meet your needs’’ or worse yet receiving an instruction ‘‘Give us a something that meets our needs’’ is a recipe for a badly flawed solution, if not an economic disaster. That may sound simplistic, but often requirements aren’t assessed until much later in the development phase, and if that happens, nothing really works well. Most enterprises will have strict reliability and availability requirements for their email systems. Equally important is the increased demand for new messaging system features to meet the needs of an increasingly mobile work force, as well as businesses that are more geographically dispersed businesses. And, as you are already aware, user requirements are continually evolving. These factors are essential to understand when designing highly reliable and consistently available messaging systems that meet a business’s needs. So as you start designing a solution and the infrastructure to support it, there are a few questions you should ask first, starting with, what do you need to have in your organization in terms of messaging systems? Some answers might include internal email and instant messaging or a more elaborate system supporting a broad array of technologies. You will need to consider regulatory requirements, internal auditing, monitoring systems, and the volume of communications. If you determine that some of these features are basic requirements that the business needs, you’ll need to create an infrastructure that meets those needs and is flexible. And you need to design the one your enterprise needs. As you saw in the last chapter, Exchange Server 2007 has a number of separate elements — server roles, messaging systems, and so on. Before you begin the design of a messaging infrastructure and populate it with these elements, you should ask yourself the following questions: What is the purpose of the infrastructure (and each element)? Often, the answer to this high-level question is obvious. For example, you might be setting up collaborative workspaces or there might be a need for instant messaging or automatic call forwarding. In any case, you should understand the purpose of everything you are doing or being asked to do.

22

CHAPTER 2 DETERMINING BUSINESS REQUIREMENTS

Who are the subject matter experts? No matter what you might think, you are almost never the person who knows what needs to be done to design the perfect infrastructure. To get around that, you need to identify the individuals in the company who can answer questions that you might have. For example, if you‘re looking at mobile messaging feature, you might need to know the numbers of people and distances covered. Knowing who to ask the question of is often half the solution. What are the detailed requirements for the system? Be sure you can identify all of the entities involved in the messaging system. You should also understand how these entities are related. It‘s important to be specific when you answer this question as a few small changes in the requirements can call for significant rework of an Exchange Server 2007 infrastructure design. What are the plans for the future of this messaging system? Is it expected that users will be happy with the types of messaging system you are planning to provide them? Or, is it likely that they‘ll want to add more systems or integrate them with other entities within and without the company? If you have all the answers to these questions, you‘re probably in good shape and at least you know what you need. As you may have already surmised from this brief summary, focusing your efforts entirely on the technical considerations of an Exchange Server 2007-based messaging infrastructure will doom it to failure. If the infrastructure doesn’t thoroughly consider the business requirements for the infrastructure, the result will be a system that is either too simple to support the demands placed on it or too complex (and unnecessarily expensive) to deliver results efficiently and cost-effectively. Without proper consideration of business requirements, you can count on designing a system that is either too weak or too expensive and thus little more than useless. In this chapter, you will have to trade in your technical skills and expertise and think like an enterprise manager. And the first questions, of course, for you to answer are why exactly does that enterprise exist and what is it trying to do? The corollary is what you are trying to do with reporting services to help achieve those goals.

The Whys and Hows of Business Requirements The process of gathering and analyzing business requirements consists of two specific phases: analyzing the current business state and analyzing business requirements for the solution. Once that is done, you use the information to determine the gap between where the organization is now (the current business state) and where the organization wants to be (the desired business state). This makes it clearer what steps you need to complete to get to the desired business state. You start the business requirements–gathering phase with an analysis of the current business state so that you have a definition of the organization’s current status.

Note It is only rarely that you will have the opportunity to design a messaging infrastructure completely from scratch. In most cases, you will have to design an infrastructure that will either have to interact with or upgrade an existing messaging infrastructure. After you’ve analyzed the current business state, the next step in understanding what needs to be done is to understand where the organization wants to go–a process called the requirementsgathering phase.

UNDERSTANDING THE CURRENT BUSINESS MODEL

The requirements-gathering phase is usually the most challenging process of any information systems project. If this process is not successfully carried out, every subsequent step in the project development life cycle will be flawed. A key part of this process is determining the business requirements, which describe the business purposes for developing a new computer system or enhancing an existing one. The process begins with gaining a thorough understanding of the current business state. The current business state is how the key functions of your organization, including messaging systems, are presently achieving or attempting to achieve the organization’s business goals. You use the current business state as a starting point to determine what needs to change to get to the eventual desired business state. Following that logic, an excellent method for determining what users want the new system to do is comparing the new system to the existing system. By using the current system as your model, you can identify and document problems, determine problem causes, and define new opportunities for a better messaging system.

Understanding the Current Business Model One of the key elements you will need to have a grasp of is the business model or models that the enterprise uses. Examining the current business model, and any model that the enterprise plans to implement in the future, is key to the process. Information that you can get from examining the current business model will help you determine the messaging systems and methods that are already in place so that you can be sure to include them in your design. Another consideration is that businesses often look at a project of major impact, such as an Exchange Server 2007 infrastructure design project, as an opportunity to change its strategies or business model to improve its position in the industry or change its own internal operations. In those cases, you must also examine any new business models that the company intends to employ so that your new design can incorporate them and accommodate interaction with the existing services being offered on the network. Reviewing and understanding the client’s business model will also provide you with a very high-level understanding of the industry in which the client is doing business. As you review the business model and interview key stakeholders, it is important that you take this opportunity to also research the client’s business and competition. This might prompt these key personnel to think of an important, but overlooked, requirement for the messaging infrastructure, thus helping you improve the overall design. The other benefit is that the more you know about their needs and their business, the more you can anticipate their needs, participate in the solution and help them achieve their goals. Obviously, the more you know about the business environment, the more you can tailor your design of the messaging infrastructure to their needs. Last, but not least, by showing an interest in and tailoring your Exchange Server 2007 infrastructure design to the company’s culture and needs, you will not be perceived as an outsider whose role is of little benefit to the organization. You will make the transition to someone with an IT background whose interests align with those of the organization — which will remove a major psychological obstacle. As a result, you’ll probably find your job is a lot easier.

Analyzing Business Processes When analyzing the current business state, the best place to start is by analyzing the business processes. A business process is a set of work activities designed to produce a specific output for a particular customer or market. The output of a business process is a product or service. The purpose of a business process analysis is to aid in understanding the way a business unit fulfills its mission. It is also used to determine the location of system problems or other potential problems. The business process analysis can also identify which business processes are effective so

23

24

CHAPTER 2 DETERMINING BUSINESS REQUIREMENTS

that they can be replicated in other systems. Business process analysis in this early phase of your design will help reduce the risk of not including beneficial aspects of existing business processes in the documentation. Analyzing the current business processes can also be useful for identifying the gaps between the current state of a business and the desired state.

Business Process Reengineering After completing the business process analysis, some organizations undertake the task of business process reengineering. Business process reengineering is the process of studying current business practices and procedures to find methods for improving existing business processes. The methods for improving the business might be radically different from the current processes. In many instances, the need for a new or modified messaging infrastructure might be part of an overall business process reengineering activity being conducted by the business. Business process reengineering focuses on the following steps: ◆

Comprehensively reviewing the current business processes.

◆

Achieving an overall understanding of the business operations.

◆

Identifying all tasks that are part of the business processes.

◆

Reviewing them to identify those that reengineering can improve.

◆

Developing strategies to improve the effectiveness of these processes.

Many different processes are executed each day in the operation of any business. An example of an IT process is:

1. If a network user calls the help desk to report a computer problem, the help desk technician follows a process in which the call is logged and assigned a ticket number so that it can be tracked.

2. Information is then gathered to aid in determining the nature of the problem. 3. The ticket is assigned to a technician who has the appropriate skills to solve the problem, and the solution is implemented.

4. The ticket is then closed, and the resolution documented. This process is repeated for every call that is made to the help desk. Similar processes exist for every task taking place in the day-to-day operation of the business. How these processes are conducted, and the results they create can be a prime determinant in who needs what sort of messaging capability. It is essential that the designer understand these processes in order to create an effective messaging infrastructure design. While there is no definitive list of business processes, they tend to fall into one of four groups: information flow, communication flow, service and product life cycles, and decision making.

Information Flow Information flow (or work flow) processes have to do with the way information is distributed throughout the company. These processes describe what information is available, who needs

UNDERSTANDING THE CURRENT BUSINESS MODEL

it, and in what order they receive it. As you can readily surmise, these processes are obviously extremely important considerations when building a messaging infrastructure. It is important to understand the information flow for all the major functions taking place within a business so that the messaging infrastructure can be designed to make sure that it enables the delivery of information when and where it’s needed. Information almost always needs to be delivered and available in the shortest possible time and consume the least amount of resources. The messages delivered must also be accurate, at least in the sense that they accurately reflect what was sent. The messaging infrastructure must meet these objectives and support the current demands for information flow, as well as provide for the increase in demand for information that will likely come in the future. For example, let’s look at how a request for a particular item might be handled by the messaging infrastructure. A sales representative receives a message from a new customer who wants to purchase some goods. The salesperson collects the customer’s information, including name, address, phone number, credit card number, and shipping preferences. He or she will also find out what type of items the customer wants to purchase. The salesperson will then either reference a database or contact someone to ensure that the items are indeed available in the type and quantity the customer wants. He’ll also have to know how much to charge and the shipping options that are available. If the order can be completed, he will send information (in this case, a confirmation) back to the customer. If not, the salesperson will utilize the messaging system to find other sources who might be able to help him meet the customer’s needs. Once the needs have been met, the salesperson will use the messaging system to ensure that the customer is informed of the status of his order. The database might also trigger a number of internal messages to the warehouse so that the items can be removed from inventory, packaged, and shipped to the customer. Throughout the process of accepting and fulfilling a customer order, information must flow throughout the network to various people at various locations in a specific order.

Communication Flow Communication flow tracks the path that message elements follow through the network infrastructure during the course of day-to-day operations of the business. You should document communication flow as a way of helping you describe the performance of the existing messaging infrastructure in specific terms. By documenting the communication flow, you have real quantified data on which to base your performance evaluation. The results of your evaluation will help you ensure that your new Exchange Server 2007 infrastructure design will maintain the high performance of the existing infrastructure or correct any performance deficiencies in the existing infrastructure. You can also use this data to create a design that redirects communication flow to a more efficient pattern.

Service and Product Life Cycles In business, any product or service that you might sell has a value for a finite period of time. After that, the product or service is either discontinued or has been rendered obsolete by a new product or service. The period of time for which a product or service has value is referred to as its lifetime. When a company wants to offer a service or product for sale, it doesn’t just pull the product or service out of thin air. Time is spent on conceptualization, research and development, design,

25

26

CHAPTER 2 DETERMINING BUSINESS REQUIREMENTS

prototyping, and production. Likewise, when a product or service is no longer of value, it doesn’t simply go away and vanish into the night. The product or service is gradually retired over a period of time. In business jargon, the period from the initial concept of the product or service to the complete removal of the product or service from the market is called its life cycle. You should always consider the life cycle of the products and/or services offered by your client when designing the messaging infrastructure. Questions you need to answer before you can effectively complete your messaging infrastructure design include: Do the company’s products enjoy a long life cycle, with events occurring gracefully over an extended period of time, as in the case of a car manufacturer? Do the company’s products go through a very short life cycle, with events occurring in rapid succession in a matter of months or weeks, as in the case of a technical publishing company? How does each scenario affect the demands that will be placed on the messaging infrastructure?

Decision Making In some organizations, decisions are made quickly, and changes occur rapidly. In others, a complicated process must be executed before the slightest thing can be done. Most companies fall somewhere in between these two extremes in how they approach decision making. You will need to learn the company’s decision-making processes and incorporate those processes into your design. As you create your messaging infrastructure, when you present the finished design to management, and at many points in between, decisions must be made that will require you to follow some of these processes yourself. This will help you become acquainted with the way decision making is handled within the organization. However, you need to go beyond this rather personal and me-centered view and keep in mind the many decisions that must be made every day, all over the company. Every business function that occurs during the day-to-day operation of the business will involve a set of decision-making processes that must be followed. Determine what role, if any, various elements will have in those processes and at what point in the information flow decision-making processes place demands for Exchange Server 2007 messaging solutions. Once you have this information, you can develop your design accordingly. An example of a typical decision-making process that you are likely to come across in most organizations you work with consists of the following steps:

1. Proposal 2. Review by first-level management 3. Revision 4. Referral to next higher management level 5. Questions/comments/feedback and revisions 6. Financial analysis 7. Proposal to management committee 8. Decision by committee 9. Ratification by decision maker

UNDERSTANDING THE CURRENT BUSINESS MODEL

Analyzing the Company Model and Geographic Scope You will encounter different business models depending on the geographic scope of your design project. If you are designing an enterprise messaging infrastructure, you will likely encounter and need to consider several different models. The following are the most common business models: Branch offices The Branch Office is the smallest business model. In this model, you focus on the specific function of the branch office and what services it must offer to or receive from the company headquarters and other branch offices. Regional This business model will be applied if your design includes locations in a particular region of a single country. Examples of regions in the United States include the New England or the Pacific Northwest. This model will include considerations that are specific to the region. National A National business model is applied to a business whose scope spans an entire country. This business model will involve all the types of concerns that are included in the Regional model but will also include multiple regions. This increases the importance of each region’s concerns, because all regions must interoperate. International Businesses that operate in multiple locations worldwide will employ the International business model. In the International model, you are likely to see all issues that could possibly be considered. This model increases the complexity of the issues in the National model by including the requirement that all National sites must interoperate. New issues that arise in this model include cultural and language barriers and international politics. Subsidiary This model differs from the others since in a Subsidiary model, concerns such as internal company politics tend increase in importance as you shape your design to allow the subsidiary company to interoperate with the infrastructure owned by the parent company.

Analyzing Organizational Structures During the analysis of the current business state, one area that needs a through understanding is the current organizational structure. Organizational structures define the roles and activities required of people so that business objectives can be met. Assessing the current organizational structure during this part of the design process makes a good deal of sense. The need for a new messaging infrastructure design system was probably triggered by some business need, such as an entry into new markets, new products, or some other change in the organization’s focus, and hence its needs. The long-term success of the Exchange Server 2007 infrastructure design might similarly be affected by a change in the organizational structure. An organizational structure should ideally accomplish four main tasks: ◆ Providing a defined method for allocating tasks, roles, and responsibilities ◆ Coordinating efforts and tasks among departments or functional units ◆ Establishing a clear reporting structure ◆ Providing a clear path for distribution of information

27

28

CHAPTER 2 DETERMINING BUSINESS REQUIREMENTS

Understanding Organizational Structure Organizational structure is extremely important when an organization changes its strategic direction. Without a strong organizational structure to help management implement the required process changes, the attempt to change strategic direction will likely fail.

The major source of information about the organizational structure is usually the organization chart. This chart can show several important details about the organization, such as the levels of authority, the span of control, the division of labor within the organization, and the formal communication channels. Figure 2.1 is an example of the U.S. Department of Justice’s organization chart, which lays out responsibilities for the various offices and activities under the attorney general.

U.S. DEPARTMENT OF JUSTICE Attorney General Deputy Attorney General

ASSOCIATE ATTORNEY GENERAL

SOLICITOR GENERAL

OFFICE OF THE SOLICITOR GENERAL

OFFICE OF JUSTICE PROGRAMS

COMMUNITY ORIENTED POLICING SERVICES

CIVIL RIGHTS DIVISION

CIVIL DIVISION

EXECUTIVE OFFICE FOR UNITED STATES TRUSTEES

OFFICE OF INFORMATION AND PRIVACY

ANTITRUST DIVISION

ENVIRONMENT AND NATURAL RESOURCES DIVISION

OFFICE OF DISPUTE RESOLUTION

FOREIGN CLAIMS SETTLEMENT COMMISSION

TAX DIVISION

COMMUNITY RELATIONS SERVICE

OFFICE OF LEGAL POLICY

OFFICE OF PUBLIC AFFAIRS

OFFICE OF LEGISLATIVE AFFAIRS

OFFICE OF LEGAL COUNSEL

OFFICE ON VIOLENCE AGAINST WOMEN

Figure 2.1 U.S. Department of Justice organization chart

OFFICE OF INTER GOVERNMENTAL AND PUBLIC LIAISON

FEDERAL BAUREU OF INVESTIGATION

CRIMINAL DIVISION

NATIONAL SECURITY DIVISION

OFFICE OF PROFESSIONAL RESPONSIBILITY

DRUG ENFORCEMENT ADMINISTRATION

BUREAU OF PRISONS

OFFICE OF THE INSPECTOR GENERAL

OFFICE OF THE PARDON ATTORNEY

EXECUTIVE OFFICE FOR UNITED STATES ATTORNEYS

UNITED STATES MARSHALS SERVICE

JUSTICE MANAGEMENT DIVISION

UNITED STATES PAROLE COMMISSION

UNITED STATES ATTORNEYS

U.S. NATIONAL CENTRAL BUREAU INTERPOL

EXECUTIVE OFFICE FOR IMMIGRATION REVIEW

NATIONAL DRUG INTELLIGENCE CENTER

BUREAU OF ALCOHOL, TOBACCO, FIREARMS, & EXPLOSIVES

OFFICE OF FEDERAL DETENTION TRUSTEE

PROFESSIONAL RESPONSIBILITY ADVISORY OFFICE

UNDERSTANDING THE CURRENT BUSINESS MODEL

Bear in mind that organization charts have several weaknesses as a means of explaining organizational structure. The chart might not be current, and it could imply a formality that does not really exist. It’s possible to have a formal organizational structure reflected in the organization chart and an informal structure that reflects reality.

Current Structure Model When assessing the organization’s current structure, knowing what type of structure model the organization follows is important. The current structure usually falls into one of these common structure types: Functional A functional organizational structure usually organizes itself around skills or other resources (see Figure 2.2). This structure type is most effective in single-business firms, in which key activities revolve around a well-defined set of processes.

Figure 2.2

Project Coordination

Functional organizational structure. Note that the different functions and activities are grouped together.

Director

Manager Marketing Salesperson Salesperson Salesperson Salesperson

Manager Design Architect Architect Architect Architect

Manager Development Developer Developer Developer Developer

Manager Testing Tester Tester Tester Tester

Matrix The matrix structure is organized with two or more chains of command and has a complicated network of reporting relationships (see Figure 2.3). Usually the most complex of the organizational structures to manage, the matrix structure does allow a company to be flexible and respond quickly to change.

Figure 2.3 Matrix organizational structure. Note that there are overlapping chains of command and the relationship between the parts is much more complex.

Functional Area Manager

Functional Area Manager

Work Package Task Description Schedule Budget

Work Package Task Description Schedule Budget

Project Manager

29

30

CHAPTER 2 DETERMINING BUSINESS REQUIREMENTS

Geographic The geographic organizational structure is usually organized specifically for the market being supported. This structure works well for organizations pursuing different strategies in different geographic markets, as shown in Figure 2.4.

Figure 2.4 Geographical organizational structure. In this example, the company is divided among several regions. Each region has a series of subunits similar to that shown for the North region, and each operates independently of other similar units in different regions.

CEO

Corporate Staff

East

West

North

South

Production

Marketing

Central

District Staff

Engineering

Decentralized business units In a decentralized business unit organizational structure, as shown in Figure 2.5, each business unit is operated as a standalone profit center. This type of organizational structure works well for diversified organizations and allows an organization to make strategic decisions closer to the environment of the business unit.

Figure 2.5 Decentralized business unit organizational structure

CEO

Corporate Services

General Manager, Business A

General Manager, Business B

General Manager, Business C

Departments

Departments

Departments

Strategic business units The strategic business unit organizational structure, as shown in Figure 2.6, is usually set up to focus on addressing strategic issues immediately. This structure can work well for highly diversified organizations that still want to enforce strategic coordination across related businesses yet have more cohesiveness among business units than a decentralized business unit structure has. The above categories are far too neat, of course. The most common organizational structure is a hybrid of one or more of these types.

UNDERSTANDING THE CURRENT BUSINESS MODEL

Figure 2.6 Strategic business unit organizational structure

CEO

Corporate Services

VP: SBU 1

VP: SBU 2

VP: SBU 3

Strategically Related Business Units

Strategically Related Business Units

Strategically Related Business Units

Ineffective Organizational Structure It’s also possible that the organizational structure has become ineffective, and the process of analyzing the current business situation can be the catalyst for reevaluating the organizational structure. Besides new organizational strategies, there are several warning signs that changes to the organizational structure might be needed. Some of these warning signs include the following: ◆

Redundant efforts between departments

◆

Too much conflict

◆

Overloaded managers

◆

Low morale

◆

Slow decision making

◆

High personnel costs

◆

Downsizing

The various organizational structures already in place usually determine the distribution of messaging components and access to devices and other elements For example, it might be that only vice presidents will be given full unified messaging capabilities or that certain things need to be done because regulatory requirements mandate a division or subsidiary generate particular reports or archive certain materials or be able (or not able) to communicate with particular persons or locales. Proposed changes to the company’s organizational structures can also have a significant impact on whether or not the current or proposed messaging infrastructure has any value. You must plan for any known anticipated changes and at the same time design your system with the flexibility to accommodate unanticipated ones. Solicit the client for input in this area. Try to get an understanding of what the current structures are and how effective they are within the organization. If there are areas that do not seem to be working from an organizational point of view, try to find out if there will be a change in that organization in the future. Always get the details of any known changes that are scheduled to occur in the future so that you can incorporate those details in your design.

31

32

CHAPTER 2 DETERMINING BUSINESS REQUIREMENTS

Several key factors can affect the shape of organization structures: ◆ Management model ◆ Company organization ◆ Vendor, partner, and customer relationships

Management Model Determine whether there is separation of ownership and control. Is there a board of directors, shareholders, and a chief executive officer. Or is this a family-run business? Is the CEO the founder and primary stockholder? Separation of ownership and control is the model found in the vast majority of large American industries. Alternatively, smaller businesses may still be owned and operated by the founders. Another consideration is to determine whether the management style is bureaucratic or authoritarian. Does it stress accounting and close control? Is it democratic, encouraging initiative and enterprise? Does it follow the tried and true, or is it willing to take risks?

Getting Work Done in Spite of an Autocratic Management Style I once worked in an organization where the head of my organization — one of many in a much larger company — had family ties to the next level and penultimate layer of the whole enterprise. He was a combination of an intellectual lightweight, suffering from a lack of knowledge about the organization he was in charge of, but possessing supreme self-confidence in his own ideas, a sort of divine right of management. His management style could best be summarized as his decisions and ideas were the only ones worth discussing, while pretending to encourage initiative and discussion. Weekly management meetings were held in which each manager was required to discuss his or her progress in meeting his mandated rigid goals and to offer suggestions for improving the business. Managers learned to dread these meetings, which might drag on for four or five hours (the previous organization head never let a meeting last more than an hour). Any manager who had not met goals was castigated. Managers whose ideas were considered frivolous, impossible, or undesirable were belittled and mocked. Sometimes it did not seem to matter if the new idea reduced cost, increased productivity, or created new markets. What was important was whether or not the boss had thought of it. And the quality of that idea was not important. Managers soon learned to offer only ideas that reflected the CEO’s thoughts (or those of his cronies). It was a contest in presenting old ideas as if they were new. Others spent time seeding the field, or somehow introducing ideas in short segments outside and prior to the meeting, and then bringing them up as something the CEO had mentioned. It was old psychology developed by the first employee — the easiest way to get what you want from the boss was to let him think it was his idea. Nevertheless, progress was made in introducing new ways of doing things. The trick was to balance something radical with something only slightly variant from the norm. This, of course, was the desired step. The radical item was ranted about; the other was ignored, but not turned down. The second part of the process was to keep introducing the desired change from other directions and to be in the right place at the right time.

UNDERSTANDING THE CURRENT BUSINESS MODEL

Physical Location Organization How the company is physically organized will be another major consideration for your Exchange Server 2007 infrastructure design. As you might expect, the distribution of resources will closely follow the company organization. Some companies are organized along the lines of business function. The various business units or departments are physically segregated. Here are some examples of ways that you might find a company segregated: ◆ Different departments in separate sections of a single floor ◆ Different departments on separate floors of a single building ◆ Different departments in separate buildings on a single campus ◆ Different departments in separate buildings in different sites Depending on your design, it may be necessary to design your Exchange Server 2007 infrastructure so that the resources are near the groups using them most. You may also find it necessary to duplicate existing work so that each group thinks of the element as ‘‘theirs.’’

Vendor, Partner, and Customer Relationships The relationships that a company maintains with its vendors, partners, and customers will have an impact on the types of reports the company wants to provide its vendors, partners and customers. Knowing the relationships that exist will help you design a network infrastructure that supports the required connectivity and interoperability.

Note There is one last factor to consider. If the assessment determines that the organizational structure needs to be changed, expect resistance at all levels of the organization. Most people don’t like change, for a variety of reasons, and usually resist it as much as possible. I’ll address managing change in Chapter 7.

Company Politics Don’t make the mistake of ignoring an organization’s political climate when assessing the current business state. Like it or not, the messaging system is going to be perceived as changing the flow of information. Restructuring the distribution of information in an organization will be seen as shifting some of the political power in that organization. For example, a group within the organization might lobby for ownership of a particular technology, say maximum mobility packages, arguing that it makes the most sense for the organization. However, the actual reason for wanting ownership might be to increase the group’s political power and weaken another’s. Conversely, if other groups within the organization feel that under the new design they are losing information access, and thus some of their power base, this could lead them to not support, or even openly oppose, your design. These groups might take steps to disrupt, sabotage, or otherwise change the messaging infrastructure’s intended focus. When you’re ready to introduce the messaging infrastructure, these same groups may withhold support or use other methods to prevent a successful project implementation.

33

34

CHAPTER 2 DETERMINING BUSINESS REQUIREMENTS

Never dismiss the possibility that people may put their own interests or self-preservation ahead of the organization’s well-being. Tread carefully.

Determining the New Business Requirements The purpose of any messaging infrastructure is the same as any other IT function — to help the business perform its day-to-day activities and meet its objectives with the greatest efficiency. What those activities are will vary depending on the company’s business strategies, and those variations will directly impact the role of the Exchange Server 2007 infrastructure and the demands placed on it. After completing your analysis of the current business state, it’s time to turn your attention to gathering requirements for the messaging infrastructure you are designing. To successfully determine business requirements for the design, you need to answer several questions. These questions focus on areas such as the following: ◆ How do you envision the business working in the future? ◆ What business problems are you trying to solve? ◆ What new organizational processes or changes to existing organization processes will be needed? ◆ What changes do you have to make to the current messaging infrastructure and organizational processes? ◆ What existing processes will have to be integrated into the new design? To successfully answer these questions, you must focus your attention on these tasks: ◆ Identifying messaging infrastructure features ◆ Identifying information sources ◆ Determining business priorities ◆ Identifying the organization tolerance for risk ◆ Creating a vision/scope document ◆ Identify internal and external dependencies ◆ Defining messaging requirements ◆ Assessing personnel and training ◆ Determining regulatory requirements

Identifying and Communicating Possible System Features One difficulty you can almost guarantee you’ll encounter when you start planning the new messaging infrastructure is that the users are not exactly sure what it is they want in terms of clear requirements. This is probably not a surprise to anyone who has dealt with users. Typically, when asked, users will describe what they would like a new system to do but in terms too vague to actually be used as system requirements; instead, they express requirements in terms of desired system behavior.

DETERMINING THE NEW BUSINESS REQUIREMENTS

A user might say, ‘‘We need to have a better idea of who our customers are’’ or ‘‘We want to be able to be able to reach the decision makers quickly.’’ These ‘‘requirements’’ are essential to the users, and the need to resolve those issues probably had a lot to do with the decision to build a new messaging infrastructure, but they can’t be easily translated into requirements. These high-level expressions of desired system behaviors are called system features. System features can be defined as services a system provides to fulfill one or more of the users’ needs. Features are not always well thought out, and some features might seem to be in conflict with other features, but they are a representation of real needs. Features are a good way to describe required functionality without getting too detailed and can promote a better understanding of the planned system. You can think of features as forming a neutral ground where what users need and how you will eventually translate those needs into business requirements can be discussed with a mutual level of understanding (see Figure 2.7). Starting requirements discussion with features being the common ground will improve your chances of identifying and addressing the right business requirements with your design, thus improving the chances of its being accepted.

Figure 2.7 Features form a neutral ground where user needs can be translated into requirements.

Needs

Features

Requirements

Make sure that you understand how the user’s (and presumably the business’s) need will be addressed by implementing a feature. If you don’t, then the odds are high that you won’t meet the objective for the new reporting services infrastructure even though you implemented the feature they asked for — or rather what it was you thought they wanted. Take for example the user stated need ‘‘We need to be able to contact our people quickly with new information.’’ Based on this alone, you could take any of several paths. You could design a system and create a new structure that reaches out through the planet and uses every known means of contact, searches every conceivable database, and keeps looking until it finds them regardless of the cost. Sounds impressive, doesn’t it? But what if what the user’s real need was to know that the employees being targeted were simply aware of this new information when they accessed the enterprise’s network. You may have satisfied the need, but your new system is extremely expensive and out of proportion to what was required. You can also use the concept of features to help review and prioritize system requirements. Users will have a better idea which requirements are critical, which are required, and which can be deferred, if you allow them to prioritize them as system features. You can then use this information to prioritize your system requirements. Features are also a good way to communicate the project’s purpose to upper management.

Identifying Information Sources Another key step is identifying the sources of information that you need to determine what the infrastructure should be doing. One good place to start is with the project sponsor or sponsors. These are the persons who championed the idea of redesigning the messaging infrastructure. They usually have a major stake in the project, financially or careerwise or both. Usually in a large corporation they will have control of the budget for your project and serve as the liaison between you and higher levels of management. Often they have a say in whether or not to continue or shut down the project. As a result they must understand and support the project’s business value.

35

36

CHAPTER 2 DETERMINING BUSINESS REQUIREMENTS

The next group to contact is the current business users, so you can discover their needs and turn those needs into project requirements. You need to determine the critical success factors that make it possible for users to do their jobs successfully. Critical success factors are information needs and systems that are crucial for business continuity. You need to understand the users’ objectives and challenges and how they go about making business decisions. It’s also important to continue to communicate with users as often as possible throughout the requirements-gathering phase and beyond. When discussing requirements with users, note that application requirements can change over time and that earlier requirements might no longer meet users’ needs at the conclusion of the process. You should verify that the desired application functionality is truly relevant to current business needs. Managing users’ expectations and making them aware of the possible impact on their work environment after project implementation should also begin at this time and will be discussed at length in Chapter 6. Here are other key information sources: ◆ Existing IT personnel ◆ Company legal staff ◆ Corporate management ◆ Customers (when relevant)

Determining Business Priorities Despite the claims of marketing and publicity departments, you are never going to be able to design a messaging infrastructure that delivers everything imaginable all the time. Hence, you’re going to have to compromise. But you can’t just compromise unilaterally — or even compromise bilaterally — unless you have a touchstone to guide you. The way to do that, of course, is to ensure that your design, and the compromises it contains, are determined by the company’s business priorities. To determine those priorities, you should meet with senior management. Ask about and document all the business’s goals, and assign a priority number to each one. Inevitably, several goals will share the same priority, but don’t worry about this in the initial stages of the design process. In fact, you really don’t need to assign a unique priority number to the goals on your list, but you must have an appreciation of the relative priority of each goal in terms of each of the other goals. Once you have assigned a priority level to each of the business goals, you will be able to determine whether any conflicts might arise when you’re trying to deliver reporting services for each of the company’s goals. When these conflicts occur, refer to the priority level of each of the items that are in conflict. Goals with higher priority levels get built into the design first. Goals with lower priority values are included in the design only if they can be delivered after goals at the higher priority levels have been satisfied. Always remember that the reason for any messaging infrastructure is to help the company achieve its goals in the marketplace. After gathering the business requirements, you should classify and prioritize them. This classifying exercise should break the requirements down into functional, performance, constraining, informational, and subjective requirements. Some of the requirements from one business unit might contradict the requirements from another business unit. Understanding the importance of the requirements, as well as resolving contradictory requirements, enables you to generate a consolidated set of requirements. Any decision processes can then be based on these requirements. Make sure that all key business users agree on the consolidated set of requirements to ensure that no ambiguity exists in the requirements before the design phase begins.

DETERMINING THE NEW BUSINESS REQUIREMENTS

Interviewing Stakeholders At this point, let’s turn the discussion from the abstract to the concrete. Up to this point, you’ve been working on learning from key stakeholders what goals they have that are specific to the messaging environment that will be put in place and how Exchange 2007 might improve their day-to-day business processes. Let’s look at how this might turn into usable information for you. During the interviews, you will notice that high-level goals tend to come up immediately. They also tend to be fairly vague in nature, but thankfully they can be clarified and honed down to help determine the specific requirements with the right amount of analysis. A CEO of the company might simply state ‘‘I need access to all of my email anywhere — oh, and make sure it includes my calendar, notes, and other stuff.’’ The chief technology officer might be more concerned with his area of concern and ask that the result has ‘‘zero downtime of the Exchange servers and easy integration with other automated business systems.’’ The Treasurer is likely to tell you that he wants ‘‘a reduced-cost email system and associated technologies with no loss of quality.’’ If you involve the next layer of organizational management, there will be a second level of goals. These will be somewhat more narrowly defined and expressed. The IT manager might want four-node clustering, the ability to restore a single user’s mailbox, and reduced user complaints about spam and performance. The marketing manager might want better tools to organize the ever-increasing amount of ‘‘stuff’’ in his employees’ Inboxes and mail folders. This information will be critical to ensuring that the outcome of the project has the technology that matches up with the business’ goals. It’s also important to make sure that you understand who is gathering the information. The answers can be very different if the question is asked by the CEO of the company rather than an outside consultant who has no direct influence over the career of the interviewee. You should make sure that you involve personnel whose employees will be most affected by the change. Involving them and listening to their needs has the advantage of creating very powerful allies in getting approval for the technology and hardware necessary to support their goals and objectives.

Moving from High-Level Goals to Actionable Items As mentioned, high-level messaging goals include a desire to have no downtime of the Exchange servers, access to email and calendars from anywhere, better functionality of the OWA client, and increased virus and spam protection. One thing to keep an eye out for as personnel discuss their goals and ambitions is where the focus is. Are they interested in fixing and stabilizing the existing system or on adding some new functionality? If the company is primarily interested in ‘‘making things work properly,’’ it might make sense to hold off on implementing a variety of new features (for example, videoconferencing, mobile messaging, and so on) at the same time as you’re correcting other issues. It can’t be often enough that you must listen to your audience and design an environment that supports their needs and addresses their concerns. Don’t fall into the trap of wasting time and resources to enable or install new functions simply because they are the latest and greatest and seem to be ‘‘cool.’’ As you saw earlier, after the higher-level goals have been identified, discussion should expand to include departmental managers and team leads. Almost immediately there should be a realization enterprise-wide of the complexity of the project and what details needed to complete the statement of work (discussed in Chapter 3) for the project. For any project to be completely successful, these individuals, as well as the end users, need to benefit in measurable ways. At the same time, the business and technology goals will also serve to reveal the relative importance of different departments. Some organizations are IT-driven, especially if they are dependent on the network infrastructure to deliver the company’s products and services. Others can survive quite well if technology isn’t available for a day or even longer.

37

38

CHAPTER 2 DETERMINING BUSINESS REQUIREMENTS

Examples of some departmental goals include the following: ◆ Ensuring encrypted transmission of human resource and personnel emails ◆ OWA client with the same capabilities of an Outlook client ◆ Support for Smartphone and Windows Mobile devices. ◆ Better mailbox recovery tools ◆ Exchange-specific management tools that can be used from Microsoft Operations Manager (MOM) Or there might be a department level combination of needs: The sales department might want to add the ability to receive voice mails through the Outlook client and updates on product data, and, therefore, need the best possible reliability and performance. This includes ensuring that viruses don’t make it into employee Inboxes and that spam be reduced as much as possible. Certain key executives might want to ensure that their BlackBerry wireless devices or Windows Mobile phones remain fully functional during and after the project. The marketing staff might be using the messaging system to share large graphic files on public folders, which they then share with strategic partners outside of the company. This practice won’t change, and the amount of data to be managed will continue to grow over time. Their primary concern is whether or not the new system will allow them to continue these practices and add to the store of graphic files. The finance and human resources departments will probably be insistent on security. Some organizations might require ethical firewalls. The IT department might have a very aggressive service level agreement (SLA) to meet and be interested in clustering, reducing the number of servers that need to be managed, and improving the management tools in place. As you can see the goals are many — and very dependent on the focus of the person being asked. Hence you should be working with the stakeholders and as many others as feasible to in a continuous process of clarifying goals. As you do the features of the Exchange messaging system that are going to be most important to the different departments and executives will become apparent. A user focus group might also be helpful, which can be composed of employee volunteers and select managers, to engage in detailed discussions and brainstorming sessions. In this way, the end users can participate in the initial planning process and help influence the decisions that will affect their day-to-day work experience. Other outcomes you should be hoping for include an understanding of which stakeholders will be involved in the project and the primary goals that are important for each person and each department. Ideally these discussions should begin to start and fuel the flames of excitement over the new technologies that will soon be available to them. Do not hesitate to discuss how the new system will contain technologies and processes that will both ease management workload and make workers more productive. Another indirect benefit form this process of involving and interviewing stakeholders and users about what they want is that this gives people at all levels a sense of how big the project really is and where they’ll see the benefits that affect them the most. A major change like implementing an Exchanger Server 2007–based messaging system should always be well communicated to the end-user community so that they will know what changes to expect, when to expect them, and how to prepare for them.

DETERMINING THE NEW BUSINESS REQUIREMENTS

Identifying the Company’s Tolerance for Risk Anytime you design something like a messaging infrastructure, you must be aware of any risks that are involved in implementing your design. While Exchange Server 2007 has been designed to reduce the overall risk associated with the deployment a messaging server and its various components, there are still risks involved. Knowing the company’s position and tolerance for risk can help you avoid serious problems as the design and implementation processes unfold. A good plan for managing the risks involved, created at the design phase, can help you avoid rejection of the project when it comes time to start the implementation phase. The first step in creating a risk management plan is to conduct a risk assessment. The risk assessment will identify the risk factors that might affect the intended messaging infrastructure and allow you to develop contingency plans to deal with those factors if they arise, or to prevent them from arising in the first place. The goal of an effective risk management plan is to eliminate risk factors if possible and to minimize the consequences of risk factors that cannot be eliminated. You should consider creating a risk assessment matrix that includes the following information: ◆ The risk factor. ◆ The probability that the risk factor will occur. ◆ The impact on the project that the risk factor carries. ◆ What strategy can be employed to mitigate this risk factor? Risk management should become part of your design and should be kept up to date as your design evolves. Risk management will need to be carried out effectively by the implementation team(s) when your design is finally complete and accepted by company management. When attempting to identify risk factors to consider in your design, keep in mind that soliciting input from company employees might be difficult. Most companies lack an environment that encourages employees to identify risks. Often an employee who points out risk factors is thought of as a naysayer or is not considered a team player. Other companies actually reward employees who identify risk factors and develop solutions to the problems presented by these factors. In most cases, however, this situation does not exist. Try to overcome the difficulties that identifying risk factors will present. Encourage the company’s employees to share their thoughts regarding risk factors for your design and assist you in developing solutions to those problems. Your design will benefit tremendously from this input.

The Case of the Police Land Rover In 1997 a large, oil-rich kingdom on the Arabian peninsula decided to upgrade its police car fleet. The kingdom, in conjunction with potential vendors, determined the business requirements were as follows: ◆

The vehicles needed to be large enough to hold not only police officers but also equipment, detainees, and other personnel.

◆

The vehicles should all be white since the color reflected better in the harsh sun and could be readily painted in the appropriate livery.

39

40

CHAPTER 2 DETERMINING BUSINESS REQUIREMENTS

◆

The vehicle needed to be able to go off road or through sand that might drift across paved roads.

◆

The vehicle engine needed to be powerful enough to sustain high speeds and overtake most commercially available vehicles.

◆

The vehicle should be adaptable to a number of needs; for example, it should be easily converted to holding a K-9, special equipment, and so on.

After much consideration, the contract, for approximately 1,000 vehicles, was awarded to a local vendor offering British made Land Rovers, since the Land Rover met the requirements. After a short time, the first batch of vehicles arrived in the country and upon inspection were immediately rejected. The reason? The vehicles delivered to the kingdom had two doors. Two-door vehicles are not acceptable for use in police work for a variety of practical reasons (such as the loading and unloading of prisoners). What had happened is that the police and the vendor had not adequately identified all the requirements. The police never specified the number of doors they needed, assuming that the vendor was aware that all police vehicle worldwide have four doors. The vendor assumed that the police wanted the least expensive vehicle and asked for the two-door vehicle without confirming that this met the police requirements. The result was a loss of income to the vendor, who had to reorder the more expensive vehicles and ‘‘unload’’ the two-door vehicles on the market, thus glutting it and slashing profit margins for all dealerships. The error also resulted in further delays in securing the needed police vehicles. What’s the moral to the story? When determining business requirements make sure that you ask all the questions and determine all the parameters of the solution. Assume nothing. If you do, you might end up looking for a job.

Identifying Internal and External Dependencies The next step in the requirements analysis phase is to identify any dependencies that might have an impact on the project’s success. A dependency is a form of constraint for any project. There are two types of dependencies: internal and external. An internal dependency is any relationship between two or more activities that could affect scheduling or completing these activities. For example, you can’t create your test report models until Microsoft SQL Server 2005 is available on the network. An external dependency is an activity or some event that is outside the direct control of the project, but its satisfactory completion has a direct bearing on whether the project can be completed. For example, another project might need to be completed before a key piece of software that the project requires becomes available.

DETERMINING THE NEW BUSINESS REQUIREMENTS

You should be aware that most internal dependencies are a direct result of resource availability. People get involved in other projects, get sick, go on vacation, or quit. If you have identified tasks in your project that depend on a certain person being available at a specific time to work on that task, you have identified an internal dependency. Having alternative resources available or providing adequate training to increase your resource pool can eliminate many internal dependencies. The nature of an external dependency is that you don’t have direct control over resolving the issue that’s causing the dependency, so they’re more difficult to control and eliminate. You can try to minimize an external dependency by creating contingency plans, reconfiguring the project plan to allow for longer time frames that resolve those dependencies, or reworking the project to eliminate the dependency entirely. Sometimes all you can do, however, is document the issue, cross your fingers, and hope for the best. Keep in mind that it’s probably not necessary to worry about and document every single dependency. On a large project, this could mean tracking literally hundreds of dependencies. The emphasis should be on documenting and attempting to resolve only those dependencies considered critical to the project’s success. High-level tasks, deliverables, milestones, or anything on the critical path would require specific attention. Lower-level or less critical tasks would not need special attention, unless a substantial delay has elevated their importance. Remember that schedules are planned with certain assumptions about dependencies, which might later prove to be incorrect. If this happens, you might need to adjust the schedule as well as reevaluate which project activities now have dependencies.

The Case of the Overheating Helicopters In 2007 the United States Army spent approximately $2.6 billion to purchase hundreds of Europeandesigned helicopters for homeland security and disaster relief. The helicopters had been used commercially for years without any significant problems. The new aircraft was designated the UH-72A Lakota. The Army took understandable pride in its project, because the Lakota represented the Army’s first major effort to adapt commercially available helicopters for military use. There was only one problem. The new helicopters weren’t safe to fly on hot days. During flight tests in Southern California in mild, 80-degree weather, cockpit temperatures in the UH-72A Lakota soared to greater than 104 degrees, a temperature at which communication, navigation, and flight control systems can overheat and shut down. Although no cockpit equipment failed during the nearly 23 hours of testing, the Army concluded that the aircraft ‘‘is not effective for use in hot environments.’’ To fix the cockpit overheating problem, the Army took the highly unusual step of adding air conditioners to many of the 322 helicopters ordered. Air conditioning is standard in commercial versions of the aircraft, which have not had overheating problems. But the military usually avoids air conditioning in military aircraft to reduce weight and increase performance, typically considered a high priority for military aircraft. One reason the Army didn’t think about overheating was because it didn’t need air conditioning in Blackhawk helicopters that the Lakota was intended to replace. ‘‘We didn’t think it would be an

41

42

CHAPTER 2 DETERMINING BUSINESS REQUIREMENTS

issue,’’ explained a Defense Department spokesperson. ‘‘But when we got the helicopter into the desert, we realized it was a problem.’’ The Lakota has another problem: testers said it fails to meet the Army’s requirement that it be able to simultaneously evacuate two critically injured patients. The Lakota can hold two patients, but the cabin is too cramped for medics to actually work on more than one of them at a time, the testers said. It is estimated the air conditioning will cost an additional $10 million. The moral to the story is simple. Failure to adequately establish the needs of the business when measured against the proposed solution resulted in a failed solution that might have had fatal consequences.

Creating Data Flow Diagrams A data flow diagram (DFD) is a way of representing a system by the use of graphical symbols. A data flow diagram is a logical representation of what a system does, not a physical representation of how it’s done. The goal of data flow diagramming is to have a commonly understood model of the report service infrastructure that both nontechnical users and technical people can use. Users make use of the diagrams to verify that the system is being modeled properly as expected; the requirementsgathering team members use them to determine whether they correctly understand the system. Data flow diagrams are a flexible diagramming tool for modeling current as well as future systems. You might ask, ‘‘Why do we need to diagram the existing system, if it’s being replaced?’’ The answer is that the best way to determine a new system’s requirements is to start with the old system. By understanding what the old system did that the new system still needs to do and what the new system needs to do that the old system didn’t do, you have a much better chance of successfully determining the new system’s requirements. Drawing data flow diagrams also helps you draw a boundary around the system being modeled. Projects often fail to determine a definite system boundary, which results in projects having an inappropriate scope, thus increasing the chance of failure for the entire project. Figure 2.8 shows a simple data flow diagram, relating a student’s acceptance at a university.

Assessing Personnel and Training When gathering the new requirements, it’s also important to evaluate what additional employee skills may be needed to work with the reporting services infrastructure. It might not be possible to develop the required skill level by training alone. This is especially true in the IT environment, where a certain level of experience is often needed to successfully implement a project. When training is enough to close the knowledge gap, a key deliverable is a thorough training plan. This should include a strategy and a plan for developing any necessary training materials for end users, administrators, and support personnel. A good training plan defines training objectives for the identified group and describes the training methods to be used, the materials needed, and the resources required. The training plan should include a training schedule in the overall project schedule. A training schedule should consider the number of users who need to be trained and then schedule the first training sessions to begin right before deployment of the new reporting services infrastructure — that way users can retain their new skills and knowledge by putting them to use. One way to develop a training plan is to conduct a training-needs analysis of the group to be trained. The analysis can help you determine current levels of knowledge, attitudes, skills, and

DETERMINING THE NEW BUSINESS REQUIREMENTS

Figure 2.8 Applying to college Student

Progress Report

Applies to University

Application

Approval Denial Letter Student Information

Acceptance Letter Registration Student Information

Student Database

preferred learning styles, which can be converted into parameters for your training plan. Knowing your users’ preferred learning styles helps determine what training materials will be most successful for that user group. Other factors, such as education, age and previous experiences, also have an impact on how people learn. By examining the results of your training-needs analysis, the training method you choose has a much better chance of successfully educating your user group and meeting their needs. Training can also help you manage user expectations.

Determining Regulatory Requirements In addition to business requirements your organization may be subject to other requirements imposed by third parties. These regulatory requirements may be mandated by governmental agencies and legislation or by internal policies and procedures imposed by financial bodies, risk management staff, or insurance companies. In some businesses, the operation is affected by only a few relevant laws or regulations. Other businesses, however, must adhere to a very complex and strict set of laws and regulations. Financial organizations are an example of such businesses. As a business’s territory expands, it finds itself governed not only by the laws and regulations local to its company headquarters but also by laws and regulations that are local to each of its remote offices. International organizations are another good example of businesses that need to adhere to complex and strict laws and regulations. You might not be able to (or need to) become intimately familiar with all the laws and regulations that are applicable to any given business. This is the job of an attorney, or sometimes a team of attorneys. However, you should work closely with the company’s legal department to become aware of any laws and regulations that are pertinent to the reports, particularly what is being reported on, who gets the reports and how access to data and reports are secured. In the case of messaging systems, there are generally three broad areas of compliance requirements: information retention, access control, and data integrity. For example, in the United States, SEC Rule 17A-4 specifies data retention policies for certain stock exchange members, brokers and

43

44

CHAPTER 2 DETERMINING BUSINESS REQUIREMENTS

dealers, and it requires financial organizations to be able to capture, index, archive, search, and retrieve their email. Controlling access to data is incorporated into a number of well-known pieces of legislation, including the Health Insurance Portability and Accountability Act (HIPAA), the Gramm-Leach-Bliley Act (or GLB Act), and California Senate Bill 1386 (or SB 1386). HIPAA and the GLB Act regulate the security and confidentiality of personal data, while SB 1386 mandates public disclosure of computer security breaches involving confidential data. Furthermore, data integrity requirements have been incorporated into other important pieces of legislation, such as Sarbanes-Oxley (SOX), the PATRIOT Act, and Basel II. But these high-profile regulations are just the tip of an enormous compliance requirement iceberg. Some estimates put the number of regulations enforced worldwide at more than 35,000. Clearly there is motivation for companies to control the risk associated with how they retain information, control data access, and ensure data integrity. So how can you, as an administrator, manage this risk and what can you do to meet all these regulatory obligations? The first step is to document compliance and retention policies. The next step is to implement and continually manage these policies. As you will see, Exchange Server 2007 can help you enact these policies, through the use of managed folders, the Transport Rules agent, message classification, and the Journaling agent. You might also face regulations regarding the software you choose, as is the case, for example, with a drug company that is dealing with regulated chemical compounds. The FDA needs to know who has access to those formulas. This means that you may have to ensure that the implemented messaging infrastructure supports limiting access to certain users and auditing the nature of the access to certain resources. These features will need to be built into the messaging services (and Exchange Server 2007) infrastructure design to ensure that the company is compliant with FDA regulations. Working with the company’s legal team can help make you aware of any legal issues that might apply to your project. This will allow you to take advantage of their expertise in dealing with these issues.

Defining Messaging Requirements At this point, it’s time to start looking at what messaging elements you’re going to need. You need to determine how these elements will support the organization and help it meet its objectives. This is a critical question since for most organizations, the information they use to meet their objectives is their most important resource. You do that primarily by asking a series of questions about each item. Generally, you will find that applying the journalist’s mantra of ‘‘who, what, where, when, how and why?’’ will provide you with all the information you need. The questions also serve to provide you with ways of setting priorities and determining the business value of the reporting item. The following list, while far from exhaustive, is typical of the questions you should be able to answer relating to every item: ◆ Who is the messaging element for? ◆ Who will have access to the messaging element? ◆ Who determines whether the messaging element meets the business needs? ◆ Who is responsible for the messaging element? ◆ What does the messaging element contain?

FORECASTING AND PLANNING FOR GROWTH

◆ What is the messaging element’s purpose? ◆ What is the sensitivity of the messaging element and its content ◆ What is the delivery method of the messaging element? Is it printed? Emailed? ◆ What business requirement(s) does the messaging element serve or meet? ◆ What roles are assigned access to the messaging element? ◆ Where is/are the server(s) physically located? ◆ When does the messaging element need to be made available? ◆ How is the message obtained? ◆ Why does this messaging element exist in this organization?

Forecasting and Planning for Growth When designing a messaging infrastructure, make sure to determine whether the company might have any plans to purchase other companies. Although a company might hesitate to reveal confidential business plans if you are an outside consultant rather than an inside staffer (and even then certain employees might not be willing to discuss many details with people from outside their department), these plans can be critical to your design. If a purchase is planned for the very near future or if it is already underway, you might be able to get some details on the matter and change your design to match them or at least have sufficient flexibility to integrate them. You will greatly benefit from being aware of any acquisition plans before you create your infrastructure design, and you should be able to communicate this in financial terms to the customer. Furthermore, you cannot prepare a meaningful design plan if you are not informed of all the requirements for that design. You should insist that company advise you on any details they can regarding any planned acquisitions. In most cases, when one company acquires another, the messaging system of the acquired is absorbed into acquirer. Sometimes it is simply eliminated and replaced with an infrastructure that conforms to the standards of the acquiring company, but this is often impractical and expensive. When examining a company’s acquisition plans, consider the following questions after you understand the current environment: ◆ Which of the new company’s messaging services components will need to be retained? Why? ◆ Which will need to be retired? Why? ◆ Which of the new company’s messaging infrastructure will replace any existing messaging infrastructure? ◆ What are the support structures for the acquired messaging infrastructure, and how will they integrate or conflict? ◆ What barriers exist to integrating the two companies’ messaging infrastructure? How large are they? One of the most important things to do once you have identified the business requirements and priorities is to understand both the company’s projected growth and the strategy it intends to employ to achieve that goal.

45

46

CHAPTER 2 DETERMINING BUSINESS REQUIREMENTS

For example, let’s say that your company’s present revenue is 10 million dollars a year, and you have 200 employees. The company’s target for the next year is to achieve a 30 percent growth in revenue and a 10 percent growth in manpower. Obviously this means that 20 more people will be on the payroll, and you will need to build that much more planning into messaging and the supporting infrastructure. It can go the other way, of course. What if the company’s president tells you to plan for 400 percent growth in employees and that most these will require mobile messaging, requiring significantly more infrastructure than you have? So you devote the money and resources to support the president’s vision. But what happens is they add a mere 10 percent growth in manpower over two years. So what, you ask. Well, in the real world someone is eventually going to come looking for you and ask why you expended that money and those resources. The justification ‘‘You told me we were going to need it’’ isn’t going to fly. In fact, you can rest assured that you’ll be asked to explain why you accepted this. There are some things you need to remember when dealing with growth projections: A projection is a prediction, not a fact All projections are ‘‘best guesses.’’ None of them is factual. Develop your design with enough flexibility to survive bad projections. You may need to spend money to meet the reality, but you need to be sure that you are not locking yourself into an architecture that isn’t flexible. Make sure to involve the right people You will need input from the same business managers who identified the priorities in the last section. Always involve the key decision makers and analysts and avoid listening to only one side of the story so that your projections, or your interpretations of existing projections, are as accurate as possible. Analyze trends To establish accurate growth projections, you will want to look at recent trends and future planned business events as they apply to the company’s growth and ask a number of questions: ◆ What growth rate has the company projected for the next year? The next three years? ◆ Where does the senior management of the company think the growth will be? ◆ How much has the company grown in the recent past — not only revenue but in terms of employees, services, locations, customers, and anything else that may be important. ◆ How much has it grown in the past year? ◆ Has the company been meeting its growth projections? If you work for a company that is able to predict its growth accurately (as rare as that generally is), it is important to know. If they continually miss the goal, you know to approach the projections with a little common sense and plan appropriately. ◆ How does the company plan to achieve this growth? If the company plans to meet its goals by acquisitions, you can expect to be spending a lot of time working on integrating disparate reporting systems architectures. ◆ ‘‘Where will the growth be?’’ If you are an international company or are planning on becoming an international company, you have an entirely new set of issues to deal with, including language, available infrastructure in the country (or countries) where the growth will take place, and finding employees.

PERFORMING A GAP ANALYSIS

Performing a Gap Analysis Now that you know where you are and where you want to be, the next step is to perform a gap analysis. This last step in determining business requirements is the simplest to describe. It is also the most concrete step in analysis and the one requiring the most meticulous attention to detail and precision. Briefly defined, a gap analysis is the process of determining, documenting, and assessing the variance between business requirements and the current ‘‘as-is’’ system capabilities. More fully explained, a gap analysis, in the context of this book, is a comparison of the difference between the ‘‘as-is’’ description of the organization’s current software/hardware asset base for its messaging system and the ‘‘to-be’’ analysis that describes the target architecture, and business and regulatory requirements that need to be achieved in the final implementations. The ‘‘gap’’ in essence determines nearly all of the planning, paths, and methods for what is implemented and not implemented. There are many different ways to perform a gap analysis, but the simplest method is probably the best. List what you currently have, identify what you need to meet business requirements, and then summarize the result. Compare your current computing environment to your future environment based on your project objectives. The gap between the existing environment and your goals will help identify which Exchange Server 2007 you will need to deploy, as well as other changes you might need to make. For example, if you establish that you will need to deploy four different Exchange Server 2007 production machines, and the company has no 64 bit machines, the gap analysis is ‘‘four 64 bit computers capable of running Exchange Server 2007.’’ If the organization has Exchange Server 2000 or earlier and wants to transition to Exchange Server 2007, the gap analysis will need to highlight the lack of a direct upgrade path and the need for a migration strategy. The primary steps of doing a gap analysis should include the following:

1. Identify the gap between the way employees work today and how the organization wants them to work. A successful deployment closes the gap between them, and ideally, when the solution is implemented, the work will be better and more effective. Later, when you or the organization assesses the level of success of the system, the primary measure will be how it has improved the work of those who are using the system.

2. Review documents, if any, from previous messaging system deployments. In addition to providing useful information about the current environment, these documents could provide a template to follow as you move through the decision-making process.

3. Review documents obtained from hardware or software vendors. Documents that relate to the current hardware and software in the enterprise’s infrastructure will help you decide what needs to be upgraded or replaced. It’s also useful to determine whether there are any short terms fixes (e.g., enabling a feature in the existing messaging system that hasn’t been used) as a stopgap measure to fulfill business requirements while the full implementation is being completed.

4. Throughout the process, make sure to keep any relevant documents up to date. You may be surprised to discover that some key pieces of information about current state or management requirements have never been recorded or updated

5. Once you’ve created any gap analysis documents you deem valuable, it’s always a good idea to circulate them among the appropriate decision makers and/or key stakeholders in

47

48

CHAPTER 2 DETERMINING BUSINESS REQUIREMENTS

the organization for comment and, possibly, approval. Either way, you should always be prepared to make changes to the documents and put them through the approval process again so that you fully understand the nature of your goals. This procedure of course is simply a suggestion, because there is no set of concrete rules for doing a gap analysis. What you are after is to do whatever it takes to give you a reasonably accurate picture of the difference between ‘‘what is’’ and ‘‘what will be.’’

Summary In this chapter, we’ve begun the process of designing a purpose-built, service-oriented Exchange Server 2007–based messaging system. You learned about how to assess the current business state and understand its role, as a starting point in developing your infrastructure. You learned about the need to gather business requirements and how to use that information to begin formulating an understanding of what is needed. You also learned how to do a gap analysis so that you know what needs to be done. Now that you’ve taken these basic and essential steps, it’s time to look at how you use this information to start writing the plan for your Exchange Server 2007–based messaging system.

Chapter 3

Planning the Exchange Infrastructure ‘‘Plans must be simple and flexible . . . . They must be made by the people who execute them.’’ — George S. Patton, Jr. ‘‘By failing to prepare, you are preparing to fail.’’ — Benjamin Franklin Now that you’ve determined what the enterprise has and what it needs, it’s time to start developing a solution and a plan for how to execute it. The plan will, in turn, serve as the basis for the business proposal you will learn how to develop in Chapter 5. Planning and designing an Exchange Server–based messaging system used to be a fairly simple task. When an organization needed email and the decision was made to go with Exchange Server, the only real decision to make was how many Exchange servers to buy. Exchange Server 2007, on the other hand, takes messaging to a whole new level. No longer do organizations require only an email system; they require other messaging and unified communications functionality as well. After the productivity capabilities of an enterprise email platform have been demonstrated, the need for more productivity improvements arises. Consequently, it is wise to understand the integral design components of Exchange before beginning a design project. In this chapter, I’ll explain several topics so you can plan your Exchange infrastructure. First, you’ll get an overview of what developing a ‘‘scope statement document’’ entails. This document, which I first mentioned in Chapter 2, is effectively a road map — some might say blueprint of what you are trying to achieve. It can also be your most valuable ally as you move toward implementation and turning requirements into outcomes and solutions. Second, I’ll review planning in its larger context. You may actually wonder why it’s necessary to spend so much time planning and what the fuss is all about. Alternatively, you may accept the idea that planning is a necessary evil, one you may not like but that you have to accept. You may need some guidance on how to go about it. Next, I’ll discuss the statement of work document, followed by the design document and finally the implementation document. By the time this chapter is over, you may think all your time developing an Exchange Server 2007 infrastructure is going to be spent preparing documents. It may also seem incredibly cumbersome. However, once you understand what you’re trying to do and how, you’ll find that the time spent planning the infrastructure and preparing these documents will serve you well, both in getting management to adopt your vision of an Exchange Server 2007–based messaging system and in implementing it.

50

CHAPTER 3 PLANNING THE EXCHANGE INFRASTRUCTURE

A Rose by Any Other Name. . . One of the more confusing aspects of planning and project management terminology is that the vocabulary and terms developed independently in several disciplines at once. As a result, the meaning isn’t always as clear as one would like, is frequently contextual, and occasionally seems whimsical and capricious. Making things even more difficult is that occasionally the terms are used interchangeably or as synonyms of one another. I’ll try to make it a little clearer here. In the previous chapter I discussed requirements, and although there is no real need to write a specific requirements document, you will have to record them at some point. In his chapter, you’ll learn about three additional documents: ◆ The scope statement ◆ The statement of work ◆ The implementation document Each is intended to address issues raised during and relevant to a particular phase of the process. Each document is a summary of the findings to date and a road map for the future. It is entirely possible that in small projects or when addressing relatively simple processes, all these elements may be combined in one document that you call the ‘‘scope’’ or the ‘‘statement of work’’ or ‘‘the plan.’’ However, in most large projects, such as when building an Exchange Server 2007–based messaging system, you will be preparing separate documents. You may call them something else, but you will be preparing them. In this book, I’ll use each of these documents in a specific way, so let’s take a few minutes to examine their differences. The requirements document, or statement of requirements, was covered in Chapter 2. It basically consists of a high-level description of the goals or objectives of the project. The scope statement document is written to document the project goals, deliverables, and requirements in project terms. It establishes a common understanding among the stakeholders and project team members regarding project requirements and deliverables. The criteria outlined in the scope statement will also be used to determine whether the project was completed successfully. The statement of work document describes the work to be performed and usually includes a timeline and level of effort. If the scope statement document answers the question ‘‘what is going to be done?’’ then the statement of work document answers the question ‘‘what work will need to be done to do that?’’ The implementation plan (aka ‘‘the plan’’) documents in detail the how to do the task and typically details the necessary steps. Still not clear? ‘‘The Case of the Portable Video Player’’ shows a simple example.

The Case of the Portable Video Player Eric is a college student who likes to produce movies using his portable video camera. He uses a computer to edit and enhance his projects. He likes to show his completed movies on a real television but finds either burning DVDs or hooking his computer up to a compatible television set to be difficult and cumbersome. He thinks there must be a portable device that meets his needs. Eric contacts his friend Karl, a hardware expert and explains his situation and desired outcome. Karl asks a few questions and determines what Eric’s desired outcome is. Eric and Karl have completed the requirements gathering phase, and have described the ‘‘as is’’ and ‘‘will be’’ statement. They have also completed the gap analysis.

A ROSE BY ANY OTHER NAME. . .

Eric asks Karl to solve the problem. Karl agrees to find Eric a portable device capable of allowing him to show his movies directly from a hard drive and without requiring special equipment or the creation of DVDs. The solution will cost less that $150. Karl will set the equipment up and show Eric how to use it. What Karl has done of course is create the scope statement and come to an agreement with the stakeholder, Eric, as to what the project consists of. Now that Eric and Karl agree on the solution, Karl writes up a short list of what needs to be done — his statement of work for this project: ◆

Research devices

◆

Purchase device

◆

Configure device

◆

Train user

If Karl were writing an implementation plan document, it would read something like this:

1. Research devices A. Research devices by checking Internet: check the following sites B. Research devices by checking consumer catalogs C. Compare features of potential devices D. Compare prices E. Assess third-party reviews and comments F. Select device to purchase

2. Purchase device A. Confirm budget with Eric B. Order item (or drive to store) C. Check warranty D. Test device’s operational state

3. Configure device A. Read user’s manual B. Apply default configuration C. Customize configuration as necessary D. Test configuration

4. Train user A. Make an appointment for Eric to pick up new device B. Review basic features and components C. Review key parts of user manual D. Give user’s manual to Eric E. Retain copy for future reference

5. Complete project A. Obtain agreement with Eric that the device meets his requirements B. Receive payment C. Transfer relevant warranties D. Issue invoice

51

52

CHAPTER 3 PLANNING THE EXCHANGE INFRASTRUCTURE

As you can see, each of the documents describes different things, and each is dependent on the other. So, the simplest thing is to remember that requirement describe what you want in general terms. The scope statement describes what the project, in this book an Exchange Server 2007–based messaging system, is going to look like and what the costs and overall goals and capabilities are supposed to be in order to constitute success. It is entirely possible that there may be other requirements that aren’t included in the scope statement because of cost or time considerations. The statement of work describes what is being done and the tasks that have to be done in general terms. The implementation plan describes the detailed specific steps that need to be done, typically in order. Now that you have a basic understanding of what the terminology means, it’s time to delve into a bit further.

Visualizing the Solution The success of any project depends on the ability of all involved to share a clear vision of the goals and objectives of the project. As you were going through the process of assessing the enterprise’s ‘‘current state,’’ defining its ‘‘desired state,’’ and calculating the gap, you almost certainly started to visualize the direction in which the Exchange Server 2007–based messaging system project should go. This initial visualization — and the steps outlined here that follow from it — serve many purposes: ◆ Identify the goals and constraints of the project. ◆ Answer feasibility questions, gain approval from key stakeholders, and acquire a common set of expectations from everyone involved. ◆ Form the basis upon which team members build the solution later in the project. ◆ Define the scope, which then helps in detailed planning. ◆ Estimate the resources that are required to develop the solution. ◆ Identify and schedule the major milestones for the project. So before you start writing out your plans, you should consider sketching for yourself (and your colleagues if this is a team project) an idea of what you are trying to achieve. Answering the previous questions and diagramming the answers is an excellent way to maintain a focus on what you are trying to achieve.

An Overview of the Scope Statement Document In the previous chapter, I discussed analyzing business requirements to get a picture of what the business wants, where the business is, and what the gaps are between the two that need to be filled in by the solution you are developing. At this stage in the process it’s useful to begin developing a scope statement document (sometimes also called a statement of work document or vision/scope document). The scope statement document specifies the goals and limitations or constraints of the solution that the plan will provide. As a ‘‘contract,’’ it defines what the proposed solution intends to do, how it will do it, and who will be involved. It also contains the goals and constraints of the business solution. This scope statement document is the first, and in many ways the most important, agreement among everyone involved in developing the Exchange Server 2007–based messaging

DEVELOPING THE SCOPE STATEMENT DOCUMENT

system. It serves as a road map for you, the planning team, stakeholders, and managers. You’ll probably find that the wording and creation of the scope document will have a great deal to do with whether the solution as you have envisioned it is approved. Once the solution is approved, it is going to be the most important document you have for planning throughout the rest of the project. You’ll also find that the scope statement is an important hedge against scope creep and misunderstood user expectations.

Stomping Crawly Creepies Scope creep, a risk in most projects, refers to uncontrolled changes in a project’s scope. Typically, the scope increase consists of either new products or new features being added to already approved products. Basically, the original solution has ‘‘just one more thing’’ added, and eventually the project drifts away from its original focus. If scope creep remains unchecked, more tasks must be completed at the same cost and in the same time frame as the original series of project tasks. The unsurprising and inevitable result is that the project falls behind schedule and exceeds its budget. Scope creep is typically the result of the following: ◆

Poor change control

◆

Poor or improper requirements gathering

◆

Weak project manager or executive sponsor

◆

Improper user expectations set by management

As the scope statement document is created, it may be necessary to conduct more interviews with customers and stakeholders. This is particularly important since you are now starting the move from understanding the high-level use to applying a lower level of detail. In the process, you will be further refining your understanding of the assumptions and constraints in the organization.

Note Remember that you continue to gather and analyze information during all phases of the project, not just the first!

Developing the Scope Statement Document The scope statement document meets two goals: it defines the problem, and it defines the parameters of the solution. Although there are no hard and fast rules of how a scope statement document should be written, it will typically consist of the following elements: ◆ The problem statement ◆ The project vision statement ◆ The definition of the users ◆ The definition of the scope

53

54

CHAPTER 3 PLANNING THE EXCHANGE INFRASTRUCTURE

Writing the Problem Statement A problem statement is exactly that. It is a clear description of the issues that will be addressed by the project, in this case, an Exchange Server 2007–based message system. Usually it summarizes the current situation that it finds unacceptable and that is being targeted by the solution. I have found that this may be one of the most important statements you have to write. Furthermore, a well-crafted problem statement that accurately defines what needs to be corrected allows you to present, assess, and define how the problem is impacting the business needs of the organization. Why? Since your project plan will be designed to solve a business problem, how you understand (and explain) the problem will in turn determine how the solution is defined. The problem statement must provide sufficient information about the business problem. The test of whether you’ve created a good problem statement is whether anyone reading it, such as a stakeholder or a new team member, can use it to put the project into context. The following are some examples of problem statements: ◆ ‘‘Telephone operators cannot deal with the high number of calls because of the time it takes them to navigate through and interact with the current application.’’ ◆ ‘‘The organization needs to eliminate the ongoing costs associated with earlier versions of hardware and software.’’ ◆ ‘‘Key executives are rarely in the office and are not be happy with the existing OWA client. They carry BlackBerry wireless devices or Windows Mobile phones and need to make sure that they can use these devices to stay in contact and be accessible at all times.’’

Creating the Project Vision Statement You can think of a project vision statement as being a description of what the solution will result in. It’s a summary, written for all involved of the Promised Land — life under the solution. It’s also a useful tool to help reach consensus and agreement from the organization and to present it as a task that is valuable, doable, and achievable. Its last valuable aspect is that it helps ensure agreement about the direction and future of the project. A project vision statement must be short enough to be remembered, clear enough to be understood, and strong enough to be motivational. Although there is no one correct way how a vision should be written, a common and very useful means is to summarize the project’s SMART characteristics: Specific A vision statement should be specific and include the ideal state of the business problem so that the end result is meaningful. Measurable By creating a vision statement that is measurable, the success of the project and whether it met the business goals can be determined. Achievable Given the resources, the time frames, and the skills of the implementers, the vision statement should be achievable. Relevant The vision statement should relate to the business problem being addressed. If not the project might lose sponsorship and support since no one knows what it is doing. Time-based The vision statement should clearly indicate the estimated time frame for the delivery of the solution.

DEVELOPING THE SCOPE STATEMENT DOCUMENT

The following are examples of vision statements: ◆ An organization’s e-commerce website has markedly lower online sales than the websites of its competitors: ‘‘Before the end of the year, we will become the top revenue-producing company in the industry by increasing our online sales.’’ ◆ An online library has a huge catalog of books, magazines, articles, white papers, and journals. The library wants its subscribers to be able to track all items in the catalog that they want to be able to find again, regardless of which computer they used to access the website. ‘‘During the current fiscal year, we will enable all our subscribers to create bookmarks to selected pages from our website for access from any computer or device the end user might use.’’ As you can see, the project vision statements are specific, measurable, achievable, and relevant to the business problem, and have an estimated time of availability — in other words, they’re SMART.

Defining the Users This part of the scope document, sometimes called creating user profiles, describes the users for whom the solution is being created and to which type of user the solution (or its component parts) applies. For example, you may have a different type of solution for messaging with sales personnel who work out of the office that differs from that needed for secretarial staff that differs from that for finance department staff. To capture a clear description of each type of user, you create functional user profiles. User profiles identify the users so that the team can assess the expectations, risks, goals, and constraints of the project as they apply to each of them: Goals

The items that the user expects to accomplish by interacting with the solution.

Constraints These are the factors that limit a user’s ability to use your solution. It may range from possessing the right hardware and software to knowledge of how to use the product. It is important to understand factors that might affect a user’s ability to use the solution, such as hardware and software. Support issues product.

This defines what support features users might require while using the new

Geographical factors bandwidth different?

Does the user’s location impact the design? For example, is the

User functions It is valuable to summarize the tasks that the user performs with the messaging system or what tasks might be required of them. Organizational communication

What rules, if any, define communication flow?

Other factors Document the availability and usage of resources at each user location, and identify any additional factors, such as incompatible protocols, network operating systems, and applications that might affect the success of a geographically based solution.

55

56

CHAPTER 3 PLANNING THE EXCHANGE INFRASTRUCTURE

Defining the Scope One of the critical factors in the success of a project is clearly defining the scope of the project. The scope takes the vision statement and incorporates the constraints imposed on the project by resources, time, and other limiting factors to determine what is doable. The scope usually includes the features or requirements that the enterprise considers mandatory. Make sure that you address these features or requirements in the solution. If there are requested features that are out of scope, they should be documented. It may be necessary to include them in subsequent revisions. Defining the scope is really nothing more than identifying what needs to be done and what will be done by the solution to address the organization’s requirements. You may have to stipulate that certain requirements cannot be met. You might also have to prioritize business requirements and identify those that can be dealt with given existing constraints. Frequently I have found that it is useful to show what can be done and in what period with differing levels of resources in order to allow decision makers the option of changing the constraints to meet additional goals or compress the time frame. It might, for example, be a goal of management to have unified messaging across the enterprise including remote areas. Assume that adding the remote areas will add six months to the implementation schedule because of the travel involved as well as the need to recruit qualified personnel willing to be in remote areas for long periods. Without this requirement, the cost of the project would be both lower and it would be completed sooner. Presenting versions with the remote areas included and with them excluded allows management to see the consequences, intended and unintended, of their various decisions.

Balancing Needs Defining the scope also means balancing the needs of a diverse set of end users and considering other priorities defined by the organization. Several variables might affect the potential success of the project, including costs, resources, schedule, functionality, and reliability. The key is to find the right balance between these variables. The trade-off triangle in Figure 3.1 shows the three most critical elements in setting the scope of a project trade-off: resources, schedule, and features. These are three interconnected elements of any project, and constraining or enhancing one or more of these elements requires trade-offs. This is because in the real world there is not unlimited time, money, or resources.

Figure 3.1

Schedule

Resources

Features

Tweaking the Requirements Another important task when defining the scope is tweaking or refining the requirements. Remember that you are continually analyzing and tweaking requirements as you gather them and work them into a scope statement and eventually the plan.

DEVELOPING THE SCOPE STATEMENT DOCUMENT

For example, assume that you start with the following high-level requirement: ‘‘The messaging system must allow instant communication with senior management.’’ After refining this requirement during the envisioning phase, you have the following requirement: ‘‘The system must have procedures for globalization, localization, and accessibility.’’

Role of Assumptions and Constraints The proposed solution is rarely an ideal one. You never have enough resources or money or the right personnel, so trade-offs are necessary. In addition, assumptions add to the constraints of the project. For example, since this is an Exchange Server 2007–based messaging system, only certain software, hardware, and other requirements are compatible and must be included in the planning. You can’t, for example, opt to use your existing Windows 2000 servers with 32 bit architecture. You can’t write a plan that upgrades directly from Exchange 2000. Exchange Server 2007 has certain intrinsic limitations as to what the software itself can’t do. For example, you cannot combine the Edge server role with any other role. The textbook definition of constraint is ‘‘the parameters to which the final business solution must adhere.’’ What this means is that there are aspects of the business environment that cannot or will not be changed. Often, these constraints become design goals for the application. Make sure to identify the constraints properly; if you don’t, you might land up designing a product that can’t be implemented, something that is both embarrassing and a one way ticket to unemployment. Some possible constraints that you should document include the following: ◆ Budget limitations ◆ Characteristics of earlier supporting systems ◆ Network system architecture ◆ Security requirements ◆ Operating systems ◆ Planned upgrades to technologies ◆ Network bandwidth limitations ◆ Maintenance and support agreements and structures ◆ Knowledge level of development or support staff ◆ Learning limitations of users

Benefits of Defining the Scope Some of the benefits of defining the scope of a project are: ◆

The scope enables the development team to focus on identifying the work that must be done.

◆

The scope enables division of large, amorphous tasks into discrete, specific tasks.

◆

The scope clarifies what is and is not going to be available in the current deliverable.

57

58

CHAPTER 3 PLANNING THE EXCHANGE INFRASTRUCTURE

Tweaking the Scope Now that you’ve defined the scope you may think that you’re done with the scope. Wrong. As you’ve gone through this process you’ve no doubt discovered that things are taking shape and a lot of hitherto unknown and underappreciated variables and pieces of information have come to the fore. This is not surprising since defining and balancing the variables is an iterative process. As scope development proceeds, and moves into a planning phase, you will almost certainly need to revise the scope to do the following: ◆ Incorporate a better understanding of user requirements ◆ Incorporate a change in business requirements ◆ Adjust the solution according to technical issues or risks ◆ Adjust for new security policies ◆ Make trade-offs among the project variables, such as resources, schedule, and features, because project variables have changed The best approach to this is to include tweaking or revising in your overall development process and make sure you have a system in place that constantly tests the scope against the reality.

Validating the Work with the Stakeholders Once you’ve created a usable scope statement document, the last formal step in the process prior to designing an implementation plan is to conduct a meeting with the stakeholders and other key players in the organization. Having the stakeholders validate the completed work ensures that the stakeholders are fully aware of the constraints, limits, and trade-offs that are made in defining the scope. The meeting also provides an opportunity to educate the stakeholders about the project, the approach being used, and other details. I also find that it has the extra benefit of creating a feeling of involvement among stakeholders that can greatly ease achieving consensus and working through any difficulties that might appear in the future. Most importantly, it enables the stakeholders to get the sense that they are being listened to and that they are actively involved in the project. It’s also important to avoid burying the stakeholders in technical details that don’t add any value to their understanding of your scope document. The vision/scope meeting ensures that the team and the customer arrive at a shared understanding regarding how the proposed solution will address the business challenge and how it is applicable to the current business need now that the scope has been defined. This meeting is a mechanism for the team to share ideas and achieve a shared vision with the customer. The team uses this meeting to decide whether the project should proceed. The available resources and the potential gains may not be worth the total cost of the project. This validation step allows the team to redefine either the project solution or the resources and constraints. Don’t be afraid to suggest that certain initial ideas and goals are really ‘‘out of scope’’ and might work better as a separate project. This is something you shouldn’t be shy doing since keeping your project realistic makes it easier to complete successfully. If there is no consensus or the meeting uncovers factors that that will cause significant changes in the scope of the project, you will need to follow up with discussions and another meeting.

AN OVERVIEW OF THE PLANNING PROCESS

When consensus is reached among you, your team (if there is one), and the key stakeholders, make sure there is agreement on the following: ◆ A broad understanding of the business needs that will be met by the solution ◆ The vision of the solution ◆ The design goals for the solution ◆ The risks that might be incurred by undertaking the project ◆ Project management’s initial concept of the business solution ◆ Who will be responsible for planning and implementation

Acknowledging Success This is the last step, and corny or as unnecessary as it might sound, it’s one of the most important. Remember that the reason you’ve developed this document has been to address a current problem or pursue a development goal. The scope document and its acceptance is the first real milestone toward constructing the Exchange Server 2007–based messaging system that you’ve begun. The scope statement is a well thought out and possibly even creative achievement that moves you closer to achieving some of the enterprise’s goals. So now is a good time to pat yourself on the back and congratulate yourself (and your team) for the work you’ve done toward solving the problem or meeting the goal. Unfortunately, this step in the planning process is often ignored in the rush to get to the next stage. It shouldn’t be. If the planning was done as part of a project team, make doubly sure to acknowledge the accomplishment. Not doing it can cultivate apathy and skepticism — even cynicism — in your organization.

Tip Finally, it doesn’t hurt at all to thank all of the people you interviewed and worked with. Not only is it polite, but it also encourages them to think of you, and your team, as one of them.

An Overview of the Planning Process The Tower of Pisa was intended to be a work of art, a fitting campanile (bell tower) for the Italian city’s magnificent cathedral. Ramrod straight, its white marble was envisioned as a landmark that could be seen from miles away. Construction of the first floor began on August 9, 1173, while Pisa was at the height of its prosperity and success. When construction reached the third floor, something went wrong. The tower began to sink. In an effort to compensate for the tilt, the engineers built higher floors with one side taller than the other. This made the tower begin lean in the other direction. Because of this, the tower is actually curved. What happened? It wasn’t an engineering failure; towers that large had been constructed all over Europe and Asia. What caused the tower to lean, defying its builder’s wishes, was a poorly laid foundation and loose substrate. The moral of the story is that no matter what you choose to do a firm foundation is the key to any structure — be it a monument or an Exchange Server 2007–based messaging system. A key part of that foundation is careful and meticulous planning.

59

60

CHAPTER 3 PLANNING THE EXCHANGE INFRASTRUCTURE

Before I start talking about planning, it’s important that you understand the role that planning plays both as a tool for your use and as part of the expected corporate culture of an enterprise. If you understand how planning fits into both and how it integrates with them, you’ll reap enormous benefits not only for this process but also for every other application. Every business in the world has embraced planning as part of its core processes. Planning is best defined as setting the direction for something — in this case, creating a messaging system centered on Exchange Server 2007, and then working to ensure the system follows that direction. All systems have inputs, processes, outputs, and outcomes: Inputs

These include resources such as raw materials, money, technologies, and people.

Process These inputs go through a process where they’re aligned, moved along, and carefully coordinated, ultimately to achieve the goals set for the system. Outputs These are tangible results produced by processes in the system, such as products or services for consumers.

AN OVERVIEW OF THE PLANNING PROCESS

Outcomes Another type of result is outcomes or benefits for consumers such as jobs, improved quality of life, and so on. In the business world, systems can be taken to mean an entire organization, or its departments, groups, processes, and so on. In this book, of course, I’m referring to an Exchange Server 2007–based messaging system. For any system, good planning always works backward. What I mean is that a good planner always starts from the results (outcomes and outputs) sought and then reverses his or her way through the system to identify what processes are required to achieve the result. The next step is to identify what inputs (or resources) are needed to carry out the processes.

The Case of the Failed Felon A man, for whatever reason, decided to rob a bank. He rode around the area, doing some advance work on his getaway. He decided that he would park his car in the parking lot of the auto parts store next door. The store and the bank were divided by a small patch of woods, about 20 feet or so. A small path cut through the patch of woods. He decided that he would rob the bank, run around the side of the bank building, and then cut through the wooded path that led to the auto parts store’s parking lot. He walked into the bank about midafternoon. He walked up to the teller and gave her a note he had written on the back of his personal deposit slip. He gave the note to the teller. She couldn’t understand what he had written so she gave the note back and asked whether he could read it. He then took the note back, stuffed it into his front pocket, and then told her he was robbing the bank. She followed bank procedure and gave him a couple of thousand dollars while she stepped on the alarm. He immediately realized that he had a problem because he had worn tight jeans and he couldn’t get the money into his pockets. He stood there trying to stuff the money in his pockets all the while heading for the door. He made a spectacle of himself doing so and as a result everyone in the bank knew he had robbed the bank, meaning there were plenty of witnesses to confirm the bank photos, which were very useful because he didn’t bother to use any kind of facial disguise either. By now, the bank robber had walked out of the bank’s front door and around to the side where he headed for the wooded path and to his car. He was now running and dropping money and trying to pick up some of the money while trying not to stop running as he headed to his car. He dropped almost half of the money because in addition to having pants too tight to hold the bulky wrapped stacks of money, he had forgotten to demand a bag to hold the money. By now, he had reached the wooded path. He had dropped most of the money but still had some left that he had stuffed into his front jeans pockets. Unfortunately that small amount of money left in his pockets also contained the dye bomb that promptly blew up his pants. The money was now flying all around the wooded path, and his pants had been blown up. As if that weren’t enough, he was now blue. The blue and burned bank robber now limped across the parking lot of the auto parts store in full view of about five or six men having their cars looked at who stopped their to look at the blue man limping across the lot and into his car.

61

62

CHAPTER 3 PLANNING THE EXCHANGE INFRASTRUCTURE

This further sealed the man’s fate because men who hang around auto parts stores generally know a lot about cars, so not only could they later provide an accurate description of the car and color, but they also estimated the cubic inches, horsepower, tire size, and make, as well providing the latest Consumer Reports data on it. Remember the personal deposit slip he scribbled the note on and then put it back in his pocket? It had been blown out of his pocket and was lying on the ground next to the blue money waiting for the detectives to pick it up. He was caught a couple of days later. His mug shot still showed a lovely tint of blue. The moral to the story: bad planning can lead to the jailhouse blues (apologies to Bessie Smith and Clarence Williams).

Planning Terminology Getting the words right is extremely important. Although you may think that you already know what these words mean, they can have a specific meaning in planning with nuances you may not be familiar with. The following is a quick overview of what I mean in this book when I use these terms. Be aware that other usages might prevail in the corporate environment where you find yourself. Goals Specific accomplishments that must be accomplished in total or in some combination in order to achieve some larger, overall result desired from the system; for example, the mission of an organization. Goals are outputs from the system. Strategies or activities These are the methods or processes required in total or in some combination to achieve the goals. Strategies are processes in the system. Objectives Objectives are specific accomplishments that must be accomplished in total or in some combination to achieve the goals in the plan. Objectives are usually ‘‘milestones’’ along the way when implementing the strategies. Tasks Particularly in small organizations, people are assigned various tasks required to implement the plan. If the scope of the plan is very small, tasks and activities are often essentially the same. Resources and budgets Resources include the people, materials, technologies, money, and the like required to implement the strategies or processes. The costs of these resources are often depicted in the form of a budget. (Resources are inputs to the system.)

Basic Overview of Typical Phases in Planning Although there is no magic formula for planning, the basic planning process almost always consists of a set of similar activities conducted in a similar sequence (i.e., phases) independent of the system being planned for. These phases are usually detailed and carried out carefully for a large or complex system, or intuitively for very small, straightforward projects. The complexity of the various phases (and their duplication throughout the system) depend on the scope of the system. For example, in a large corporation for some projects (for example, to promote innovation), it might be necessary to do these phases at each corporate level such as divisions, departments, units, and so on. In the relatively simple framework in this book, these are the phases that you and project team members will need to go through.

AN OVERVIEW OF THE PLANNING PROCESS

Note It’s not unusual for different planning models to have different names for these phases. However, the nature of the activities and their general sequence will always remain the same.

Identify and Adhere to the Overall Goal of the Enterprise During planning, you need to keep in mind the overall goal that the project is seeking to achieve and how it relates to the mission, or overall purpose of the organization. The first place you should look is the enterprise’s vision statement. The vision (or mission) statement tells the world where the company excels (or wants to), what its aims are, and how it wants to differ from its competitors. There will typically be several key objectives behind this vision, which are not so publicly stated, that can be related to the Exchange Server 2007 upgrade. These should be looked for and clarified. If not, you’ll find it difficult, or near impossible, to judge whether your plan (and the project itself) will succeed or fail from a business standpoint.

Vision Statements from the Real World The following are some vision statements from various companies: ◆

‘‘To empower our employees to provide comprehensive service in a professional manner for our members, employers, and retirees through timely and accurate processing of payments, claims, inquiries, and other account information using effective and appropriate leading edge technology.’’ — South Carolina Retirement Systems

◆

‘‘We will be our community’s preferred health-care provider and will adapt to future changes and challenges by adopting the best health-care and business practices. We provide professional cost effective health-care services in accordance with internationally recognized healthcare standards. The well-being of our population results in a healthy and productive workforce.’’ — Dhahran Health Center

◆

‘‘The objectives of the Shell Group are to engage efficiently, responsibly and profitably in oil, oil products, gas, chemicals and other selected businesses and to participate in the search for and development of other sources of energy to meet evolving customer needs and the world’s growing demand for energy. ‘‘We believe that oil and gas will be integral to the global energy needs for economic development for many decades to come. Our role is to ensure that we extract and deliver them profitably and in environmentally and socially responsible ways. ‘‘We seek a high standard of performance, maintaining a strong long-term and growing position in the competitive environments in which we choose to operate. ‘‘We aim to work closely with our customers, our partners and policymakers to advance more efficient and sustainable use of energy and natural resources.’’ — Shell Oil Company

◆

‘‘As the nation’s record keeper, it is our vision that all Americans will understand the vital role records play in a democracy, and their own personal stake in the National Archives. Our holdings and diverse programs will be available to more people than ever before through modern technology and dynamic partnerships. The stories of our nation and our people are told in the records and artifacts cared for in NARA facilities around the country. We want all Americans to be inspired to explore the records of their country.’’ — National Archives of the United States

63

64

CHAPTER 3 PLANNING THE EXCHANGE INFRASTRUCTURE

High-level business goals pertaining to an Exchange Server 2007–based messaging system can include better leveraging of company resources and information through efficient communications and collaboration, controlling IT costs to lower overhead and enable products to be more competitively priced, or improving security to meet governmental requirements. If your planning takes into account these larger goals and your solution is geared to being a means of achieving these goals and practices through technology, then your plan becomes an amazing asset to your company. By creating your plan to match the business’s needs, you’ll make it easier to see where you are going and what you need to do to get there. It also keeps you focused on tasks that achieve or enable the enterprise’s mission. If the enterprise were a hospital, with a vision statement like the one in the ‘‘Vision Statements from the Real World’’ sidebar for the Dhahran Health Center, then your plan should show how it will help the hospital achieve its stated mission. It should also refer to it. For example: ‘‘Effective timely communication of information both within and without the hospital environment among medical professionals is an integral part of providing professional, cost-effective health-care services. This plan presents a solution utilizing a messaging system based on Exchange Server 2007 that will help ensure the meeting of these goals. ‘‘The plan is designed to present a solution that is efficient, cost-effective, adaptable and flexible enough to assure that it can meet any future changes and challenges in health care.’’

Assess the Political Climate I’ve mentioned this in the previous chapter as something you will be doing during the analysis phase. As you develop a plan, you must take the political climate into consideration. Make sure that you understand, and your initial planning takes into consideration, the various driving forces, or major influences within the organization. As you probably already know, given the often politically ‘‘hot’’ climate of Active Directory planning in large organizations, you may have to consider that in your Exchange infrastructure.

Analyze the Situation In the previous chapter, we talked about analyzing business requirements. Now, as you start the planning process reassess the plan in terms of the organization’s strengths and weaknesses. How can your solution address the weaknesses you’ve uncovered and maintain or enhance its strengths? What are the opportunities and threats to the organization that this solution presents and offers? Make sure that you fully understand the downside of any planning decision you make.

Establish Goals Based on your analysis of the situation and in keeping with the enterprise’s mission, you should sketch out a collection of goals that will use the organization’s strength to take advantage of opportunities, while building up weaknesses and warding off threats. Obviously in this case, you should have an idea of what the Exchange Server 2007–based messaging system is going to do. At this point, the business goals that will guide and justify the Exchange Server 2007–based messaging system should be clearly defined, and the manner in which Exchange Server 2007’s enhanced features will be valuable to the company should be made clear. The plan, of course, will reflect this.

DEVELOPING THE STATEMENT OF WORK

Establish Strategies to Reach Goals The particular strategies (that is, methods to reach the goals) chosen depend on affordability, practicality, and efficiency. This will be covered in the business proposal, which will be discussed in Chapter 6, but you need to keep the means and the goals realistic.

Establish Interim Objectives Whether you call them objectives, milestones, waypoints, or benchmarks, plans will always need to include certain targets that indicate success or failure.

Associate Responsibilities and Timelines with Each Objective During this phase, you should plan who is going to be responsible for what phase of the operation, as well as the various goals and objectives. Setting deadlines and time frames should be done.

Prepare the Planning Document In this phase, you will write up the plan. If this is prior to the business proposal presentation, you may decide to circulate the written plan to stakeholders or business decision makers before meeting. In any event, as you will see in Chapter 6, the plan must be presented and distributed.

Recognize Completion As I’ve already mentioned, you need to make sure that there is recognition of those who have been involved in developing the plan, including yourself. The value of recognition and praise has been acknowledged by many. Mark Twain said, ‘‘I can live for two months on a good compliment.’’ John Masefield said, ‘‘Once in a century a man may be ruined or made insufferable by praise. But surely once a minute something generous dies for want of it.’’ Recognition can take many forms, but usually the simplest and most effective is ‘‘Thank you.’’ If you have no team or have been doing the planning by yourself, resist the temptation to ignore this step and move on to the next project or the next phase if you’re also implementing it. Take a few moments or the afternoon off to celebrate.

Developing the Statement of Work Now that you know what you are going to be doing, you need to start compiling this into a statement of work (SOW). The purpose of a SOW is to detail the work requirements for projects and programs that have deliverables and/or services performed. Enterprise executives and other members of management generally require a documented statement of work that reflects strategic thinking, an understanding of the goals and objectives of the organization, and a sense of confidence that the project will be successful and beneficial to the company. The document should always be clear and specific and keep its audience in mind. This generally means not going into too much technical detail in the SOW. This document also needs to give an estimate of the duration of the project, the costs involved, and the resources required. The document should be written such that it can be understood by someone who knows nothing about the technology that is being proposed, in this case Exchange Server 2007.

65

66

CHAPTER 3 PLANNING THE EXCHANGE INFRASTRUCTURE

Note Microsoft has a statement of work template available to download from its website at http://office .microsoft.com/en-us/templates/TC011840321033.aspx?AxInstalled=1&c=0.

The Statement of Work Document The following is a standard outline for the statement of work document:

1. Scope statement 2. Requirements 3. Goals and Objectives 4. Timeline and Milestones 5. Resources 6. Risks and Assumptions 7. Dependencies 8. Initial Budget 9. Task The following sections cover the different components of the statement of work. This document is arguably the most important in the entire process because it can convince the executives who hold the purse strings to move forward with the project — or, of course, to stop the project in its tracks.

Summarizing the Scope Statement As already discussed, a great deal of effort has already gone into developing a scope statement document, which has clarified the basic extent of the project, the high-level business goals as they pertain to the messaging upgrade, and more specific goals for each department and of key stakeholders as required. The scope document should now be organized and summarized for inclusion in the SOW, but this time to restate the purpose and ambition of the project and also to get final sign-off and allow you move to the more detailed planning phase. It’s likely that you may have had to change the original scope statement document you created earlier. It may be that subsequent discussions with the executives, managers, and stakeholders revealed problems that weren’t obvious and requirements that hadn’t been foreseen. Although the scope started out as ‘‘implement Exchange Server 2007,’’ it might have expanded to include an upgrade to Active Directory, the addition of new features for remote access to the messaging environment, the rollout of new 64 bit–capable servers or management, and business continuity features. So these should be included. The scope portion of an SOW document will vary by company, but for an Exchange Server 2007–based messaging system, the SOW will almost always have to address these key questions: ◆ How many Exchange and Windows servers need to be upgraded? ◆ Where do these servers reside?

DEVELOPING THE STATEMENT OF WORK

◆ What additional applications need to be upgraded (especially backup, virus protection, disaster recovery, and remote access) as part of the project? ◆ What additional hardware needs to be upgraded or modified to support the new servers and applications (especially tape backup devices, Storage Area Networks (SAN), routers)? ◆ Will laptop configurations be changed? If so, will you need physical access to them? ◆ Will the desktop configurations be changed? ◆ What will be the impact to users? ◆ What is the backout strategy and recovery plan? How long will we wait before we implement it? Don’t worry too much if you don’t know all the answers to the questions at this point. The fact that you’ve included them will highlight their importance to a successful outcome to management. It can also be a useful tool for encouraging executives to consider possible ways of solving the problem, as well as to understand the full extent of the undertaking. You can address the actual answers to these questions as you finalize preparations for implementation.

Summarizing the Goals By now, one of the things you should have already established, in multiple conversations across the enterprise, is a collection of goals. Ironically, you may, especially in a very large organization, be the only person who is aware of all the goals, dreams, and desires that exist in the organization for the Exchange Server 2007–based messaging system. Including them in the SOW allows you to ensure that everyone knows what everyone else’s goals are. When the goal are mutually exclusive — for example, when the Finance Department wants free access to communication and the Law Department requires an ethical barrier — it’s better to let the respective parties recognize it at the management level, rather than find yourself in the role of mediator. You can organize the goals in various ways, but one possible way of organizing them is: ◆ Business continuity/disaster recovery (clustering, storage, backup, and restore) ◆ Performance (memory allocation improvements, public folders, email) ◆ Security (server, email) ◆ Mobility (Outlook Web Access, Pocket PC, and Smartphone support) ◆ Collaboration (real-time collaboration — replacement for Exchange instant messaging — SharePoint Portal) ◆ Serviceability (administration, management, deployment) ◆ Development (Collaboration Data Objects, managed application programming interface [API]) By using a framework such as this, any ‘‘holes’’ in the goals and objectives of the project will be more obvious. Some of the less glamorous objectives, such as a stable network, data-recovery abilities, or protection from the hostile outside world, might not have been identified in the discussions. This is the time to bring up topics that might have been missed, before moving into the more detailed planning phase. It might also be valuable to categorize portions of the upgrade as ‘‘fixes’’ for existing problems as opposed to ‘‘new’’ capabilities that will be added to the environment.

67

68

CHAPTER 3 PLANNING THE EXCHANGE INFRASTRUCTURE

Summarizing the Timeline and Milestones A bulleted list of tasks is typically all that is needed to help define the time frame for completion of the Exchange Server 2007–based messaging system. If the project is complex or involves a number of elements, you might want to create a high-level Gantt chart of the project.

Note A Gantt Chart (named for Henry Laurence Gantt) consists of a table of project task information and a bar chart that graphically displays project schedule, depicting progress in relation to time and often used in planning and tracking a project.

Break the time frame down by phases to show how much time is to be allocated for each. This is extremely important if you plan to prototype your deployment. The actual implementation date for the Exchange Server 2007–based messaging system should be estimated. The rule of thumb at this point is that no task shown in the chart should have a duration of less then one day. If it has a shorter duration, it’s probably too detailed to specify at this point in the process. Because every Exchange Server 2007–based messaging system project will be different, it’s impossible to provide rules for how much time to allocate to which phase. The best answer to the question ‘‘how long show the time frame be?’’ is dependent on a number of factors. For a complex Exchange Server 2007–based messaging system project, one to two months can be considered a ‘‘short’’ time frame. Two to four or even six months provides a more comfortable and flexible window if the Exchange Server 2007–based messaging system requires a large number of servers, users, and messaging-related applications. Make sure to always include additional time if an outside company is going to be involved in either the project or its final form. Hardware and software procurement can also pose delays, so for shorter time frames, they should be procured as soon as possible after the ideal configuration has been defined. These types of items can often be overlooked, yet they can easily add weeks to the timeline of an Exchange Server 2007–based messaging system project. My experience has shown that allocating additional time for the detailed planning and testing phase tends to make things go more smoothly. If little or no planning is done — something that won’t happen to you if you follow this book — the testing phase will most likely miss key requirements. The resulting messaging environment needs to be supported after the dust settles, so it makes sense for the administrative staff to receive training in the early phases rather than after the implementation. It is easier to perform most of the training in the prototype phase because you will have a working environment that doesn’t have any users on it. This allows the administrative staff to practice moving mailboxes, recovering data and entire servers, and rebuilding servers from scratch without impacting any production users. You should allocate time for training of end users either after or during implementation If you don’t already know them, make sure that you understand how long it takes the enterprise to do something and account for it. If the organization’s IT department requires, for example, that the security group perform a security audit on any server before it is released into production, be sure to account for this in the timeline. Also be sure to let other groups know that you will be submitting a potentially large number of servers for them to audit so that they can also prepare their own resources to be ready for you. Careful teamwork and communication around these types of activities can save a lot of time overall.

DEVELOPING THE STATEMENT OF WORK

The key to successfully meeting any timeline for an Exchange Server 2007–based messaging system is to understand the added risks involved and define the scope of the project so that the risks are controlled.

Summarizing the Resources Required Typical roles that need to be filled for an Exchange Server 2007–based messaging system project include the following: ◆ Project sponsor or champion ◆ Exchange Server 2007 design consultant ◆ Exchange Server 2007 technical lead ◆ Exchange Server 2007 consulting engineer ◆ Project manager ◆ Systems engineer(s) ◆ Technical writer ◆ Administrative trainer ◆ End-user trainer The organization should objectively consider the experience, skills, and time availability of its internal resources and personnel in determining whether outside help is required. It is not common for an organization to completely outsource the whole project. At the same time few companies have the internal resources to devote 100 percent of their energy to planning and testing the messaging technologies, not to mention supporting them, because they are likely fully utilized for their daily duties. Contracted resources, on the other hand, are able to focus just on the messaging project. Most successful projects include a mix of internal and external resources. This allows the internal resources to gain valuable knowledge from the external resources and end up with a strong knowledge of their own environment from their direct involvement with the design and deployment. For large Exchange Server 2007–based messaging system projects, separate teams might be created to design the detailed plan, another team created for the testing phase, and yet another to execute the implementation. Ideally, they should all be the same personnel and it’s preferred that testing team members have some role in the implementation to maintain continuity. By properly assigning the project tasks to the right resources, you can maximize the chances for overall success. By providing for a bit of overlap between tasks and resources, you can also cross-train your staff so that they can more easily support each other.

Summarizing the Risks and Assumptions You should make sure that you fully identify and understand any and all immediately obvious risks that could affect the successful outcome of the project during the planning phase and include them in the SOW. Basic risks might include the following: ◆ Existing Exchange problems, such as a corrupt database or lack of maintenance ◆ Lack of in-house expertise and bandwidth for the project

69

70

CHAPTER 3 PLANNING THE EXCHANGE INFRASTRUCTURE

◆ Using existing hardware that might not have enough random access memory (RAM), storage capacity, processor speed, or the ability to support a 64 bit operating system ◆ Wide area network (WAN) or local area network (LAN) connectivity issues, making downtime a possibility ◆ A production environment that cannot experience any downtime or financial losses will occur ◆ Customized applications that interface with Exchange Server and that need to be tested and possibly rewritten for Exchange Server 2007 ◆ Short timeline that will require cutting corners in the testing process It’s useful to assign a numeric value to risk probability and impact. Probability measures the likelihood that the event will occur, while impact measures the severity of that loss on the enterprise, should it occur. Then calculate the exposure of each risk by multiplying the two numbers. This process allows you to compare risks and determine their relative severity and priority. For example, use a number between 1 and 5 to designate probability and impact for each risk, with 5 being the highest and 1 being the lowest. By multiplying the numbers representing probability and impact for a risk, you obtain an exposure factor between 1 and 25. This system allows you to identify and address the most severe risks first. Identifying and prioritizing risks isn’t enough. It is also imperative that you specify how you are going minimize risks.

Summarizing the Initial Budget The decision makers will by now be wondering what all this is going to cost. Some information might already be quite clear, such as how many servers need to be purchased. If the existing servers are more than a few years old and don’t support a 64 bit operating system, chances are they need to be replaced, and price quotes can easily be gathered for new machines. Software upgrades and licenses can also easily be gathered, and costs for peripheral devices such as tape drives or SANs should be included. If external help is needed for the planning, testing, and implementation, some educated guesses should be made about the order of magnitude of these costs. Some organizations set aside a percentage of the overall budget for the planning phase, assuming outside assistance, and then determine whether they can do the testing and implementation on their own. As mentioned previously, training costs should also not be forgotten for both the administrative staff and the end users.

Getting Approval on the Statement of Work After the initial information has been presented in the statement of work, formally present it and discuss it with the stakeholders just as you did with the SOW. The SOW should be approved, but if there are any lingering questions, they should be clarified. Once the SOW has been agreed to you can now move to the last step before formal presentation (to be covered in Chapter 5), creating a design document.

The Design Document A design document presents a detailed picture of the end state of the Exchange Server 2007–based messaging system. As you might expect the design document starts from the SOW. It then expands on the SOW, summarizing what was done and how the various decisions were reached. I suggest

DEVELOPING THE STATEMENT OF WORK

including some information on what other options were considered and why they were rejected. This is useful for helping others who were not directly involved in the design process understand why decisions were made. The second key deliverable in the planning phase is the final implementation document, which explains how the end state will be reached. Typically, these documents are separate, because the design document gives the ‘‘what’’ and ‘‘why’’ information, and the implementation document gives the ‘‘how’’ and ‘‘when’’ information. This is a good example of writing documents slightly differently based on who the audience will be. I cover the implementation plan in the ‘‘The Implementation Plan’’ section later in this chapter.

Making the Design Decisions Just as the planning phase kicked off with discovery efforts and review of the networking environment, the design phase will start with more meetings with the stakeholders and the project team for collaborative design discussions. The meetings should review the features that Exchange Server 2007 offers and how these could be beneficial to the organization as a whole and to specific departments or key users in support of the already defined goals. Typically, several half-day sessions are required to discuss the new features and whether implementing them makes sense. I recommend creating periods of time between sessions to give participants a chance to let the information sink in and make sure that there won’t be any unintended side effects of a given decision. By this point in the process, quite a bit of thought has already gone into what the end state will look like and that is reflected in the SOW. Presumably, everyone attending the sessions agrees as to what the goals and expectations for the project are. If they aren’t, this is the time to resolve differing opinions, because the design document is the plan of record for the results of the messaging upgrade. The collaborative sessions should be led by someone with hands-on experience in designing and implementing Exchange Server 2007 solutions. This might be an in-house expert or it might be an external consultant. Agendas should be provided in advance to keep the sessions on track and enable attendees to prepare for specific questions. A technical writer should be invited to take notes and start to become familiar with the project as a whole because that individual will most likely be active in creating the design document and additional documents required. The specifics of the Exchange Server 2007–based messaging system should be discussed in depth, especially the role that each server will play in the transition. A diagram is typically created during this process (or an existing Visio diagram updated) that defines the locations and roles of all Exchange 2007 servers and any legacy Exchange servers that need to be kept in place. This is the time to account for overlapping projects that the company may have going on that might impact your Exchange 2007 rollout. It’s also a good time to ensure that you will have the required personnel and other resources that you defined previously. You don’t want to discover that your key Exchange Server 2007 personnel have all gone on vacation on rollout day.

Disaster Recovery Options Most people would agree that the average organization would be severely affected if the messaging environment were to go offline for an extended period of time. Communications between employees would have to be in person or over the phone, document sharing would be more complex, communication with clients would be affected, and the productivity of the remote workforce would suffer. Employees in the field rarely carry pagers any more, and some have even discarded their cell phones, so many employees would be hard to reach. This dependence on messaging

71

72

CHAPTER 3 PLANNING THE EXCHANGE INFRASTRUCTURE

makes it critical to adequately cover the topic of disaster recovery as it pertains to the Exchange messaging environment. Although a full disaster recovery assessment is most likely out of the scope of the Exchange Server 2007–based messaging system project, the topic should be covered at this phase in the project. Take this opportunity to review any existing disaster recovery plans determine if they need to change with the new design.

Design Document Structure The design document uses the content from the SOW document but goes into greater detail and provides historical information on the decisions that were made. This is helpful if questions come up later in the testing or implementation process, such as ‘‘whose idea was that?’’ or ‘‘why did we make that decision?’’

Sample Table of Contents of Exchange Server 2007 Design Document

1. Executive Summary 2. Goals and Objectives ◆ Business Objectives ◆ Departmental Goals

3. Background ◆ Overview of Process ◆ Summary of Discovery Process

4. Exchange Design ◆ Exchange 2007 Design Diagram ◆ Exchange Mailbox Server Placement and Configuration ◆ Exchange Client Access Server Placement and Configuration ◆ Exchange Edge Transport Server Placement and Configuration ◆ Exchange Hub Transport Server Placement and Configuration ◆ Exchange Unified Messaging Server Placement and Configuration ◆ Organization (definition of and number of Exchange organizations) ◆ Storage Groups (definition of and number of) ◆ Global Catalog Placement (definition and placement) ◆ Recipient Policies (definition and usage) ◆ Server Specifications (recommendations and decisions, role for each server defined, redundancy, disaster recovery options discussed) ◆ Virus Protection (selected product with configuration)

DEVELOPING THE STATEMENT OF WORK

◆ Administrative Model (options defined, and decisions made for level of administration permitted by administrative group) ◆ System Policies (definition and decisions on which policies will be used) ◆ Exchange Monitoring (product selection and features described) ◆ Exchange Backup/Recovery (product selection and features described) ◆ High availability, Cluster Continuous Replictaion (CCR), Local Continuous Replictaion (LCR), Standby Continuous Replication (SCR)

5. Budget Estimate ◆ Hardware and Software Estimate

The Implementation Document With the design document completed and agreed to by the decision makers, the next step is to create the implementation document (sometimes called ‘‘the plan’’ since it’s the detailed document being followed by everyone). The goal of the implementation document is to present the method best suited to the needs of the organization in terms of timeline, division of labor, and costs. The implementation plan, which is based on goals and objectives defined earlier, makes the project real. The implementation plan is fairly specific and defines ‘‘who does what’’ in the actual testing and migration process, assigns costs to the resources as applicable, and creates a specific timeline with milestones and due dates. Having accurate information now will make it much easier to ensure that resources, both people and hardware/software, are available in time. The implementation document should include enough detail about the Exchange Server 2007–based messaging system creation process so that those who are doing the work can use it for guidance in their tasks and can determine the purpose and goals of each step. Make sure that you appreciate that the implementation plan is not a step-by-step handbook of how to configure the servers, implement the security features, and move mailboxes. The implementation plan is still fairly high level; it is certainly not a ‘‘How to’’ manual and the persons involved in performing the tasks will need real-world experience and skills. Additional collaborative meetings might be needed at this point to brainstorm and decide both on the exact steps that will be followed and when the testing and upgrade will be. It is critical to plan the implementation as carefully as possible and to always make the decisions that support the goals the Exchange Server 2007–based messaging system is intended to achieve.

Implementation Schedule A schedule or Gantt Chart is a standard component of the implementation plan. It presents tasks organized by the order in which they need to be completed, effectively making detailed road map of how the organization will get from the current state to the implementation. Also included in the schedule are key items such as: ◆ Resources assigned to each task ◆ Start dates and durations ◆ Checkpoints ◆ Milestones

73

74

CHAPTER 3 PLANNING THE EXCHANGE INFRASTRUCTURE

Note Milestones by definition have no duration and represent events such as the arrival of hardware items, sign-off approval on a series of tasks, and similar events.

Additional time should be allocated in case stumbling blocks are encountered. A good place for this contingency planning is between steps or phases. Built-in contingency time helps limits the chances that the entire project will be knocked off schedule and disrupt the availability of downstream resources. A good rule of thumb is to have each task line represent a minimum of 4 hours of activities; otherwise, the schedule can become too long and cumbersome. Another good rule is that a specific task should not be less than 1 percent of the total project, thus limiting the project to 100 lines. The schedule is not intended to provide detailed information to the individuals performing the tasks, but to help schedule, budget, and manage the Exchange Server 2007–based messaging system project. Tracking the completion of the project plan items versus time is a great way to quickly spot when you are at risk of falling behind and compromising the timeline. Dependencies should also be defined and shown. For example, to ensure that users know that Task 40 needs to be completed before Task 50 can start. You should review the chart to identify any places where resources are overburdened (for example, being expected to work 30 hours in one day). You can also use them for resource balancing and resource leveling. It’s a good idea to set a baseline based on the initial schedule. The actuals can then be tracked and compared to the baseline to determine whether the project is ahead of, on, or behind schedule. If the timeline is very short, the Gantt chart can be used to see if multiple tasks take place simultaneously or if this will cause conflicts.

Creating the Implementation Plan With the project schedule completed, the implementation plan will come together quite easily since all you have to do now is fill out the ‘‘story’’ told by the Gantt chart. Typically, the implementation plan is similar to the structure of the design document (another reason why many organizations want to combine the two), but the design document relates the design decisions made and details the end state of the upgrade, and the implementation plan details the process and steps to be taken.

Sample Table of Contents for the Implementation Plan

1. Executive Summary 2. Goals and Objectives of the Implementation 3. Background 4. Summary of Implementation-Specific Decisions 5. Risks and Assumptions 6. Roles and Responsibilities 7. Timeline and Milestones 8. Training Plan

DEVELOPING THE STATEMENT OF WORK

9. Implementation Process ◆ Hardware and Software Procurement Process ◆ Prototype Proof of Concept Process ◆ Server Configuration and Testing ◆ Desktop Configuration and Testing ◆ Documentation Required from Prototype ◆ Pilot Phase(s) Detailed ◆ Migration/Upgrade Detailed ◆ Support Phase Detailed ◆ Support Documentation Detailed

10. Budget Estimate ◆ Labor Costs for Prototype Phase ◆ Labor Costs for Pilot Phase ◆ Labor Costs for Migration/Upgrade Phase ◆ Labor Costs for Support Phase ◆ Costs for Training

11. Project Schedule (Gantt Chart)

Summary In this chapter, you learned all about the entire planning process. You learned how to establish a scope statement, statement of work, design document, and implementation document. So far this may seem to you to be very theoretical and you may be wondering how this can apply to your Exchange Server 2007–based messaging system. Never fear, now that you have a good grasp of how to create a plan and all of its various components, you’ll be putting it all together in the next chapter when apply this theoretical framework to designing your enterprise’s Exchange Server 2007–based messaging system and making decisions regarding its features.

75

Chapter 4

Applying Planning Principles to Exchange Server 2007 ‘‘The more they overthink the plumbing, the easier it is to stop up the drain.’’ — Montgomery Scott, Star Trek III: The Search for Spock ‘‘There are two ways of constructing a software design; one way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.’’ — Sir Charles Anthony Richard Hoare Simplicity begets reliability. Many email system architects have learned that as increasingly sophisticated systems are incorporated to improve email reliability, the complexity of configuring and maintaining these systems has resulted in errors that cause the very system outages they were added to prevent. Part of your challenge as the planning guru and designer is to maintain as much simplicity and design in your plan and design as you can. The statement of work, although comprehensive, does not have to create a Frankenstein’s monster. As you write it, think it, discuss it, and redo all of it, a key question you should be asking is ‘‘is it simple enough?’’ Of course, that doesn’t mean the planning is going to be simple. Let’s be honest. Once, designing Exchange Server used to be a fairly simple task. When an organization needed email and the decision was made to go with Exchange Server, the only real decision to make was how many Exchange servers were needed. Primarily, organizations really needed nothing more than email and eschewed any ‘‘bells and whistles.’’ Exchange Server 2007, on the other hand, takes messaging to a whole new level. No longer do organizations require only an email system, but other messaging and unified communications functionality as well. After the productivity capabilities of an enterprise email platform have been demonstrated, the need for more productivity improvements arises. It’s a self-perpetuating feedback loop, and you’re going to have to manage it. In the previous two chapters, you learned how to analyze your business requirements and design plans for your enterprises from a high level. In this chapter and the next, you’ll move your planning to a much lower level and start applying what you’ve learned from the stakeholders, users, and other concerned personnel to develop specific items for the statement of work for an Exchange Server 2007–based messaging system.

78

CHAPTER 4 APPLYING PLANNING PRINCIPLES TO EXCHANGE SERVER 2007

Note I won’t be describing how to set work requirements for the nuts and bolts of the functionality. Instead, I’ll show you how to determine what you should include and why, as well as help you determine how you can justify those decisions and recommendations to management. For example, when I discuss disclaimers, the focus won’t be on how to configure them or set font size and color. The review will center on the fact that they are available, why they may or may not be needed, and various ways to utilize them. This chapter will cover several key topics that are critical to your design. You’ll learn about the different Exchange and operating system requirements. Another key concern is determining disk storage need. Naturally, Active Directory requirements are also a major factor. As you may already know, but will certainly be well aware by the end of the chapter if you do not, your planning will be heavily influenced by the need to comply with many legal and internal regulatory requirements, including court-related demands on your system. I’ll also cover email archiving. Mail archiving is now a major requirement and expectation of email messaging systems. Planning it is not only essential from the point of view of system management, but there is also a growing body of legal and regulatory — as well as corporate — rules and mandates governing the retention of and access to email records and contents. Getting this right is not simply a matter of good practice; doing it wrong can cost a company millions and in extreme cases result in its financial ruination. The final consideration is how you should implement your Exchange Server 2007–based messaging system. Should it be an in-house system, or should you outsource it? This is not an idle question. Exchange 2007 demands the latest and some of the most expensive hardware with full redundancy. Outlook 2007 can be obtained only by purchasing it separately or as part of the Microsoft Office suite. Analysts predict that 80 percent of midmarket companies will benefit if they outsource Microsoft Exchange. Some argue that a typical midsized company will save more than $100,000 by avoiding an in-house deployment, a figure that suddenly makes outsourcing an attractive option. We’ll be looking at how you make that assessment and what you need to have in place, such as a service-level agreement, to make it a worthwhile proposition.

Note Throughout this chapter, the word plan is used to refer to the statement of work document.

Reviewing the Changes in Exchange Server 2007 Exchange Server 2007 introduces some important changes that need to be incorporated into your statement of work. In fact, you will find that some of these changes and enhancements will probably drive the design process.

An Overview of the New Features Although they will be discussed in more detail later in this chapter and throughout the book, you should make a note of the new features of Exchange Server 2007 right at the outset. After all, part of the reason you’re moving to Exchange Server 2007 is to exploit these new capabilities and leverage these changes into something your organization can use.

REVIEWING THE CHANGES IN EXCHANGE SERVER 2007

The key new features are: ◆ Role-based deployment, which lets you choose the messaging services you want to provide and deploy server roles specific to those services. You can deploy the server roles individually on dedicated hardware, or install multiple roles on the same physical server, administered as separate entities. ◆ ‘‘Access to messages from anywhere’’ changes and improvements include an enhanced Outlook Web Access (OWA), Microsoft ActiveSync improvements, new Outlook Voice Access (OVA), Unified Messaging support, and Outlook Anywhere (formerly known as RPC over HTTP). These methods greatly increase the design flexibility of Exchange, allowing end users to access email through a variety of different methods. ◆ Integrated antispam, antivirus, and compliance mechanisms. ◆ Local continuous replication (LCR) and cluster continuous replication (CCR). The two methods provide log shipping capabilities for Exchange databases by enabling the creation of a replica copy of an Exchange database to be built from new logs generated from the server. Replication can thus be done in real time from one server to another server in a remote site or locally on the same server. ◆ Standby continuous replication (SCR) was introduced in Service Pack 1 for Microsoft Exchange Server 2007. As its name implies, SCR is designed for scenarios that use standby recovery servers. SCR extends the existing continuous replication features and enables new data availability scenarios for Mailbox servers. ◆ Continuous replication (log shipping and seeding) over redundant cluster networks in a cluster continuous replication environment. ◆ Support for IPv6 was introduced for SP1 versions running on Windows 2008. ◆ Exchange Server 2007 Service Pack 1 added some enhancements to Outlook Web Access, including the following: ◆

User creation and editing of personal distribution lists

◆

User creation and editing of server-side rules

◆

Recovery of deleted files

◆

Support for Public Folders

◆

S/Mime support

◆ The following features were added to Unified Messaging in Exchange 2007 SP1: ◆

Support for Secure Real-time Transport Protocol (SRTP)

◆

Exchange Management Console support for configuring Mutual Transport Layer Security (mutual TLS) for dial plans

◆

The ability to add a SIP or E.164 address for a user by using the Enable Unified Messaging Wizard

◆

The ability to modify extension numbers and SIP and E.164 addresses for a UMenabled user by using the Exchange Management Console

79

80

CHAPTER 4 APPLYING PLANNING PRINCIPLES TO EXCHANGE SERVER 2007

◆

In-band fax tone detection

◆

Quality of Service (QoS) support

◆ Exchange 2007 SP1 can be deployed with Office Communications Server 2007 environment. In that type of an integrated environment, the following are some of the features available to you: ◆

Ability to create SIP URI and E.164 dial plans by using the New Dial Plan Wizard

◆

Additional logic for resolving internal calling number

◆

Notification of forwarding when leaving voice messages in scenarios where the destination uses call forwarding

◆

Support for recording high-fidelity voice messages in Exchange Unified Messaging

◆

Access to Outlook Voice Access from Microsoft Office Communicator 2007 without requiring the user to enter a PIN

◆

Ability for Office Communicator 2007 clients to associate subjects and priorities to voice messages

◆

Support for media streams to traverse firewalls

◆

Integration of missed call notification email messages with Office Communicator 2007

◆

Ability to prohibit Play on Phone calls that are placed by using Office Communicator 2007 from being subjected to call forwarding rules that are configured

These are only a small number of the many new features that are now available in an Exchange Server 2007–based messaging system with Service Pack 1 installed. This list is by no means exhaustive, and you should always refer to the product documentation for more information.

Choosing an Installation Path A solid, well-thought-out installation is a key to effective Exchange Server 2007 planning. In fact, you really don’t have a choice since there is no in-place server upgrade path from an existing Exchange server to the new version. There is no direct upgrade path because Exchange Server 2007 requires an x64 architecture-based system with an Intel processor that supports Intel Extended Memory 64 Technology (Intel EM64T) or an AMD processor that supports the AMD64 platform. Note that the Intel Itanium (IA64) processor will not work with Windows 2003 x64 editions. Thus, it won’t work for Exchange 2007 deployments. Because earlier versions of Exchange didn’t support x64 architecture, there are no systems from which you can upgrade. What this means is, like it or not, you will have to write a plan that has you installing Exchange Server 2007 ‘‘fresh.’’ There are only three possible installation paths therefore: ◆ Create a new Exchange environment for a new company or one without an existing messaging infrastructure. ◆ Where there is an existing Exchange environment, you can transition by installing Exchange Server 2007 servers, having them coexist briefly, and then phasing out the previous versions. ◆ Install Exchange Server 2007 in a new organization, migrate all your mailboxes over to 2007, and then remove your old Exchange servers.

REVIEWING EXCHANGE AND OPERATING SYSTEM REQUIREMENTS

I’ll discuss installation paths and deployment in greater detail in Chapter 10. For now, one of your first decisions will be to decide which of the three methods is right for your organization. Now let’s turn our attention to the system and network requirements you’ll need to meet in order to successfully install Exchange 2007.

Note Please note that if you have not already done so, you can install Exchange Server 2007 SP1 on computers running Exchange Server 2007 to perform an in-place upgrade. For new installations, you can simply perform a fresh installation of Exchange 2007 SP1 without having to install the original version first.

Reviewing Exchange and Operating System Requirements Exchange Server 2007 has specific hardware and software requirements that must be taken into account when designing your statement of work, adapting the details as you work on the project. These requirements fall into several categories: ◆ Hardware considerations ◆ Operating system ◆ Version ◆ Edition ◆ Product licensing ◆ Active Directory ◆ Virtualization Each requirement must be addressed before Exchange Server 2007 can be deployed and so you’re going to have to consider them in your plan.

Hardware Considerations As you have already read, Exchange Server 2007 requires a 64 bit platform. There’s simply no way of avoiding that investment. One thing you should do is attempt to mitigate the overall Total Cost of Ownership (TCO) by creating a hardware design that scales out the Exchange load to what is forecasted at least 3 years from the date of implementation. Doing so helps retain the value of the investment in Exchange Server–supporting hardware and other systems that you will include in your plan. Specific hardware configuration advice is offered in later sections of this chapter. Previous versions of Exchange forced many organizations into deploying servers in sites with more than a dozen or so users. In addition it was often necessary to deploy Exchange servers and global catalog (GC) servers in remote locations with only a handful of users. Exchange Server 2007 modifies this with site consolidation, which allows clients in remote locations to access their mailboxes across wide area network (WAN) links or dial-up connections by using the enhanced Outlook 2003/2007 or OWA clients. It also means that smaller numbers of Exchange servers can service clients in multiple locations, even if they are separated by slow WAN links.

81

82

CHAPTER 4 APPLYING PLANNING PRINCIPLES TO EXCHANGE SERVER 2007

As you can see, site consolidation will have a profound effect on your overall Total Cost of Ownership (TCO) and on your plan in general since reducing the number of Exchange server machines you will need will help shrink the infrastructure costs of setting up Exchange. For small and medium-sized organizations, this means that one or two servers should suffice for the needs of the organization. Larger organizations will require a larger number of Exchange servers, depending on the number of sites and users.

Yes, More Expensive Really Means Cheaper It may seem counterintuitive that the higher costs of hardware to support Exchange Server 2007, particularly the substantially increased cost of the 64 bit platform, can actually reduce overall costs by producing a better outcome with less collateral damage in terms of system downtime, unexpected consequences, and the inability to scale effectively. Consider, however, the experience of the United States Air Force. In World War II cheap and plentifully produced iron bombs were used over enemy targets. On average it took 108 aircraft, dropping 648 bombs to destroy a single target. In one notable case, U.S. bombers flying about 800 missions were able to destroy only a tiny portion of a Japanese factory while leveling everything else around it. In attempt to reduce both civilian casualties and the costs in aircraft and pilots, precision munitions were developed and widely deployed in the early 1990s and beyond. Although much more expensive, these weapons are far more accurate than bombs guided by nothing more than gravity. By the time of the 2001 campaign in Afghanistan, 38 aircraft were able to hit 159 targets on the first night of bombing, using less than 200 weapons. That’s a feat that would have taken World War II aircraft more than 17,000 aircraft and 100,000 bombs. Civilian losses would have been comparatively higher as well. Sometimes the higher price tag is really a bargain, a point you may have to clarify to the stakeholders and in your Statement of Work. Another point to consider when planning location and placement of Exchange Server 2007 machines is both the administrative group and the routing group structure, both of which no longer exist in Exchange Server 2007.

Operating System (OS) Requirements Currently Exchange Server 2007 will install on only Windows Server 2003. Exchange Server 2007 Service Pack 1 is required to install the program on Windows 2008 Server. Note that Windows Server 2003 installations of Exchange Server 2007 Service Pack require that Service Pack 2 be installed on Windows Server 2003. Table 4.1 summarizes the compatibility between Exchange versions and various operating systems (OS).

Exchange Server 2007 and the Current Network Infrastructure Exchange Server 2007 incorporates industry-wide compatible protocols and services. In addition, familiar Internet standards, such as Domain Name System (DNS), Internet Message Access Protocol (IMAP), Simple Mail Transfer Protocol (SMTP), Lightweight Directory Access Protocol

REVIEWING EXCHANGE AND OPERATING SYSTEM REQUIREMENTS

(LDAP), and Post Office Protocol 3 (POP3), built into the product to provide coexistence with existing network infrastructure, making infrastructure design and planning relatively simple and painless. You will, however, need to identify all the systems that require access to email data or services. For example, it might be necessary to enable a third-party monitoring application to relay mail off the SMTP engine of Exchange so that alerts can be sent. Identifying these needs during the design portion of a project is extremely important.

Table 4.1:

Exchange Version Compatibility

Version

Windows NT 4.0 Windows 2000 Windows 2003

WIndows 2008

Exchange 5.5

Yes

Yes

No

No

Exchange 2000

No

Yes

No

No

Exchange 2003

No

Yes

Yes

No

Exchange 2007

No

No

Yes, only 64 bit SP1 or R2 editions supported

No

Exchange 2007 Sp1

No

No

Yes, only 64 bit SP2 supported

Yes

Version Selection Considerations Exchange 2007 comes in two platforms based on bits. The 64 bit version is intended for a live production environment. It is the only one that can be purchased as a matter of fact. The 32 bit version, basically intended for evaluation, is for nonproduction environments (such as evaluation, labs, training facilities, demo, and so on). There are two exceptions with respect to production and nonproduction use of the 32 bit platform because Microsoft does allow minimal supported use of the 32 bit version in production environments. Specifically: ◆ You can use the 32 bit version in production to administer Exchange 2007 servers from Windows Server 2003 or Windows XP. ◆ You can use the 32 bit version in production to extend your Active Directory directory service schema. All other uses of the 32 bit version of Exchange 2007 in production environments are unsupported. Automatic antispam updates from Windows Update are not available in the 32 bit version. Only a licensed 64 bit version can get automatic antispam updates from Microsoft Update. You can have a maximum of 5 databases per server in as many as 5 storage groups on the 32 bit version, which is less than the 50 databases per server as 50 storage groups. Although the 64 bit version can be the Standard Edition or the Enterprise Edition, the 32 bit version can only be the Standard Edition. You can also install Unified Messaging (UM) with the 32 bit version in a nonproduction environment so that you can evaluate the UM-related features.

83

84

CHAPTER 4 APPLYING PLANNING PRINCIPLES TO EXCHANGE SERVER 2007

Edition Considerations There are two Exchange Server 2007 editions: Standard and Enterprise. The Standard Edition is designed to meet the messaging and collaboration needs of small and medium corporations; it may also be appropriate for specific server roles or branch offices. The Enterprise Edition is intended for large enterprise corporations and enables the creation of multiple storage groups and databases. The primary differences, as summarized in Table 4.2, are: ◆ Only the Enterprise Edition can scale to 50 databases per server; the Standard Edition is limited to 5 databases per server. ◆ Only the Enterprise Edition can handle greater than 75 GB mailbox store. ◆ Single copy clusters (SCC) and cluster continuous replication (CCR) are supported only on the Enterprise Edition.

Table 4.2:

Exchange Server 2007 Edition Features

Feature

Standard Edition

Enterprise Edition

Storage Group Support

5 storage groups

50 storage groups

Database Support

5 databases

50 databases

Database Storage Limit

16 TB per database

16 TB per database

Single Copy Clusters

Not supported

Supported

Local Continuous Replication

Supported

Supported

Cluster Continuous Replication

Not supported

Supported

Note that Microsoft has made an exception in the 32 bit version code to allow SCC and CCR to be used for nonproduction use on the 32 bit version, even though the 32 bit version is the Standard Edition. This means that you can set up a 32 bit test lab for evaluating or testing SCC and CCR. Because it’s 32 bit, you can create the nonproduction environments in a Microsoft Virtual Server environment for your lab or demos.

Product Licensing Considerations Exchange Server 2007 edition types are licensing editions that are defined by a product key. There is a single set of binary files for each platform (one for x64 systems and one for x86 systems), and the same binaries are used for both editions. When you enter a valid, licensed product key, the supported edition for the server is established. Product keys can be used for same edition key swaps and upgrades only, and they cannot be used for downgrades. You can use a valid product key to go from the evaluation version (Trial Edition) to either the Standard Edition or the Enterprise Edition; you can also use a valid product key to go from the Standard Edition to the Enterprise Edition. You can also re-license the server using the same edition product key.

REVIEWING EXCHANGE AND OPERATING SYSTEM REQUIREMENTS

For example, if you had two Standard Edition servers with two keys, but you accidentally used the same key on both servers, you could change the key for one of them to be the other key that you were issued. You can take these actions without having to reinstall or reconfigure anything. After you enter the product key and restart the Microsoft Exchange Information Store service, the edition corresponding to that product key will be reflected. You cannot use product keys to perform a downgrade from the Enterprise Edition to the Standard Edition, nor to revert to the Trial Edition. A downgrade can only be done by uninstalling Exchange 2007, reinstalling Exchange 2007, and entering the correct product key.

Client Access License Considerations Exchange 2007 also comes in two client access license (CAL) editions, which are also called the Standard Edition and the Enterprise Edition. You can mix and match the server editions with the CAL editions. For example, you can use Enterprise CALs against the Standard server edition. Similarly, you can use Standard CALs against the Enterprise server edition. The Exchange Server Enterprise CAL is an additive CAL and requires that a Standard CAL is also purchased for each user or device. The Exchange Server Enterprise CAL provides access to Unified Messaging and advanced compliance, as well as Forefront Security for Exchange Server and Exchange Hosted Filtering for onsite and hosted antivirus and antispam protection. A CAL is required for each user or device (depending on the license) accessing the server. Either version of the CAL may be run against either version of the server. Table 4.3 illustrates what features are included with the Standard CAL and Enterprise CAL. The last column illustrates what features can be accessed if you own both the Standard CAL and the Enterprise CAL. Keep in mind that some features can only be purchased through a volume license program, and they are not available as retail purchases.

Virtualization Considerations Exchange Server 2007 is not supported in production in a virtual environment. You can plan to use Virtual Server for training, labs, and demos. Exchange Server 2007 is also not supported in production in a virtual environment using non-Microsoft virtualization software. The first 64 bit guest support is expected to be included with Hypervisor, which is an add-on for Windows Server 2008 from Microsoft that is scheduled to ship within 180 days of Windows Server 2008’s release.

Which Build Is It? The final RTM build of Exchange 2007 (before Service Pack 1) is build 685.25, but in some places it is listed as 685.24. Both are correct, actually. When you view the version information in the Exchange Management Console or examine the value of the AdminDisplayVersion property for Exchange servers in the Exchange Management Shell, it shows the version as 685.24. When you view the Exchange version information in the Windows registry, it shows 685.25. If you use Microsoft Operations Manager, it also shows version 685.25, but if you view version information in Microsoft Office Outlook, it shows 685.24. An exception to this version mismatch problem is present on the Edge Transport server. That will always and only display 685.25 for the version. This makes things interesting when looking at several Exchange servers in the Exchange Management Console that include one or more synchronized Edge

85

86

CHAPTER 4 APPLYING PLANNING PRINCIPLES TO EXCHANGE SERVER 2007

Transport servers because the Version column will show both 685.24 (for non-Edge Transport servers) and 685.25 (for Edge Transport servers). Also, when you click Help
About Exchange Server 2007, you’ll see a different version number altogether: 685.018. These versioning discrepancies have been expected to be resolved in Service Pack 1 for Exchange 2007. Finally, if you use the Get-ExchangeServer cmdlet and examine the ExchangeVersion property, you’ll notice yet another different version number: 0.1 (8.0.535.0). However, this number does not refer to the version of an installed product; rather, it refers to the minimum version of the product that can read the object. In this case, any Exchange server that is version 8.0.535.0 or later can read this object because the last changes to this object’s schema were made in build 8.0.535.0.

Table 4.3:

Exchange Server 2007 CAL Offerings Standard CAL

Enterprise CAL∗

Standard CAL + Enterprise CAL

Email, shared calendaring, contacts, tasks, management

Yes

No∗

Yes

Outlook Web Access

Yes

No∗

Yes

Exchange ActiveSync

Yes

No∗

Yes

Unified Messaging

No

Yes

Yes

Per-User/Per-Distribution List Journaling

No

Yes

Yes

Managed Email Folders

No

Yes

Yes

Exchange Hosted Filtering∗∗

No

Yes

Yes∗∗

Forefront Security for Exchange Server∗∗

No

Yes

Yes∗∗

Feature

*Additive CAL, purchase of the Standard CAL is required for Standard offerings **Offered only through Volume Licensing Programs, not available via retail purchase

Third-Party Product Functionality Microsoft built specific hooks into Exchange Server 2007 to enable third-party applications to improve upon the built-in functionality provided by the system. For example, built-in support for antivirus scanning, backups, and Unified Messaging exist right out of the box, although functionality is limited without the addition of third-party software. The most common additions to Exchange implementation are the following: ◆ Antivirus ◆ Backup

DETERMINING DISK STORAGE NEEDS

◆ Phone/PBX integration ◆ Fax software These will be discussed in detail in Chapter 5.

Determining Disk Storage Needs Computers running Microsoft Exchange Server 2007 need to be deployed correctly with sufficient storage capacity and performance capabilities. Capacity and performance are often at odds with each other when it comes to planning a storage solution, and both must be considered before making a purchase. You will need to ensure the following in your plan: ◆ Making sure there will be enough space to store all of the data. ◆ Making sure the solution provides acceptable disk latency and a responsive user experience. This is determined by measuring or predicting transactional input/output (I/O) delivered by the solution. ◆ Making sure that nontransactional I/O has both enough time to complete and enough disk throughput to meet any service-level agreements (SLAs). The optimal plan balances these factors and allows you to design the actual hardware solution for your servers.

Planning Disk Capacity Having sufficient capacity is critical. Not having it causes things to go awry. If a database disk runs out of space, the database goes offline. If a transaction log disk runs out of space, it causes all of the databases in that storage group to go offline. Both of these are disasters, and there really isn’t a way to add more space in a hurry. Even performing offline compaction to reclaim space can take a long time. The bottom line is simple: running out of disk space results in an interruption of availability of one or more databases for a period of time that typically exceeds most recovery time objectives (RTO). That can get you fired. There are several data points that you can use to determine how to size a database logical unit number (LUN), as well as a number of other factors. A safe decision and one that ensures that the needs of the business are fully planned for calls for an additional overhead factor for the database LUN of 20 percent. This value will account for the other data that resides in the database that is not necessarily seen when calculating mailbox sizes and white space; for example, the data structure (tables, views, and internal indices) within the database adds to the overall size of the database. For example, if after reading the following subsections, you determine that you need 200 GB, we recommend that you provision 250 GB, representing a 20 percent safety overhead for that storage group’s database LUN. The key data points are as follows: ◆ Mailbox Quota ◆ Database White Space ◆ Database Dumpster ◆ Actual Mailbox Size

87

88

CHAPTER 4 APPLYING PLANNING PRINCIPLES TO EXCHANGE SERVER 2007

◆ Content Indexing ◆ Maintenance ◆ Recovery Storage Group ◆ Backup to Disk ◆ Log LUN Capacity ◆ Backup and Restore Factors ◆ Move Mailbox Operations ◆ Log Growth Factor

Calculating Mailbox Size The following is a formula for database size using a 2 GB mailbox: Mailbox Size=Mailbox Quota+White Space+(Weekly Incoming Mail × 2) Mailbox Size=2,048 MB+(10 MB)+(52 MB × 2) 2,162 MB=2,048 MB+10 MB+104 MB (6 percent larger than the quota)

Table 4.4 can be used to estimate the number of transaction logs that will be generated on an Exchange 2007 Mailbox server.

Table 4.4:

Number of Generated Transaction Logs for Each Mailbox Profile

Mailbox Profile

Message Profile

Logs Generated/Mailbox

Light

5 sent/20 received

7

Average

10 sent/40 received

14

Heavy

20 sent/80 received

28

Very Heavy

30 sent/120 received

42

Storage Technology The key aspects to choosing storage technology include reliability, capacity, performance, complexity, manageability, and cost.

Hardware Options Exchange Server 2007 can make use of any of the following storage methodologies and options. It is important to note that unlike previous versions of Exchange Server, network-attached storage is not supported in Exchange Server 2007. The only network-based storage transport supported for Exchange Server 2007 is Internet SCSI (iSCSI).

DETERMINING DISK STORAGE NEEDS

◆ Serial ATA (SATA) ◆ Serial Attached SCSI (SAS) ◆ iSCSI ◆ Fibre Channel

RAID Selection As you can imagine, having redundancy in your storage design is a critical aspect of the plan and to ensuring high availability. Microsoft recommends a redundant array of inexpensive disks (RAID) behind a battery-backed controller for all Exchange Server 2007 machines. Selecting a RAID type is a balance of capacity and transactional I/O. Mailbox size has a large impact on capacity, while smaller form factor disks impact performance. Table 4.5 compares the three most commonly used types of RAID solutions based on speed, space utilization, and performance during rebuilds and failures.

Table 4.5:

Comparison of RAID Solutions

RAID type

Speed

Capacity utilization

Rebuild performance

Disk failure performance

I/O performance

RAID10

Best

Poor

Best

Best

Best

RAID5

Good

Best

Poor

Poor

Poor

RAID6

Poor

Good

Poor

Poor

Poor

Storage Tools In order to assist administrators, planners and other users in designing their storage layout for Exchange Server 2007, Microsoft has put together a number of tools to help assess and calculate needs.

Storage Calculator for Exchange 2007 The Exchange 2007 Mailbox Server Role Storage Requirements Calculator (storage calculator) enables you to determine your storage requirements (I/O performance and capacity) and an optimal LUN layout based on a set of input factors. As described before, there are many input factors that need to be accounted for before you can design an optimal storage solution for an Exchange 2007 Mailbox server. The storage calculator enables you to input values specific to your organization and provides you with recommendations for optimal LUN layout. The calculator does not make any recommendations toward storage design (RAID parity, number of disks, etc.) as the storage design is largely dependent on the type of storage array being utilized. For more information on some basic requirements around storage design, see the Storage Requirements Blog listed above. For more information about the storage calculator, including details about using it, see the Exchange 2007 Mailbox Server Role Storage Requirements Calculator at http://msexchange team.com/files/12/attachments/entry438481.aspx.

89

90

CHAPTER 4 APPLYING PLANNING PRINCIPLES TO EXCHANGE SERVER 2007

Storage-Related Tools Exchange Server Jetstress accurately simulates Exchange I/O characteristics. The tool includes both a stress test and a performance test, which show the maximum performance of a LUN within acceptable latencies. Additionally, a replacement for Load Simulator, called the Exchange Load Generator, has been created for simulating Outlook clients. Both tools simulate Outlook and require a fully configured Exchange Server 2007 environment for testing. Simulating Outlook clients is the only way to measure actual client latency (rather than just the server disk latency). You can download both of these tools using the following links: ◆ Microsoft Exchange Server Jetstress Tool (64 bit): http://go.microsoft.com/fwlink/ ?LinkId=80466 ◆ Microsoft Exchange Server Jetstress Tool (32 bit): http://go.microsoft.com/fwlink/ ?LinkId=27883 ◆ Exchange Load Generator (64 bit): http://go.microsoft.com/fwlink/?LinkId=80470 ◆ Exchange Load Generator (32 bit): http://go.microsoft.com/fwlink/?LinkId=80469 The Exchange Stress and Performance tool is used to simulate Internet protocols such as POP3, IMAP4, and SMTP. It is often used to simulate incoming MIME mail from the Internet to an organization. You can download this tool using the following links: ◆ Exchange Server Stress and Performance Tool (64 bit): http://go.microsoft.com/ fwlink/?LinkId=80468 ◆ Exchange Server Stress and Performance Tool (32 bit): http://go.microsoft.com/ fwlink/?LinkId=80467 Other useful tools can be found at Tools for Exchange Server 2007: http://go.microsoft.com/ fwlink/?LinkId=81741.

Understanding Active Directory (AD) Requirements Exchange originally maintained its own directory. With the advent of Exchange 2000, however, the directory for Exchange was moved to the Microsoft Active Directory (AD), the enterprise directory system for Windows. This gave greater flexibility and consolidated directories, but at the same time it increased the complexity and dependencies for Exchange. Exchange Server 2007 uses the same model, with either Windows 2000 Server or Windows Server 2003 AD as its directory component. Active Directory is a necessary and fundamental component of any Exchange 2007 implementation. That said, organizations do not necessarily need to panic about setting up Active Directory in addition to Exchange, as long as a few straightforward design steps are followed. Exchange Server 2007 has several key requirements for AD. First, all domains must be in Windows 2000 or 2003 functional levels (no NT domain controllers). Second, it requires that the schema in an AD forest be extended for Windows Server 2003 RTM or R2 editions, and that the schema master domain controller be running either Windows Server 2003 SP1 or R2 edition. In addition, at least one global catalog server in each site where Exchange will be installed must be running Windows Server 2003 SP1 or R2.

UNDERSTANDING ACTIVE DIRECTORY (AD) REQUIREMENTS

Furthermore, the following areas of Active Directory must be addressed to properly design and deploy Exchange 2007: ◆ Schema preparation ◆ Forest and domain design ◆ AD site and replication topology layout ◆ Domain controller and global catalog placement ◆ Domain name system (DNS) configuration Before moving on to these topics let’s review some basic aspects of how Exchange Server 2007 uses AD.

How Exchange Server 2007 Uses Active Directory When an Exchange Server 2007 server starts, it is stamped with a site attribute that helps other Exchange Server 2007 servers locate the services provided by it. Since only the Hub Transport server can use SMTP to transport a message within the organization, each Active Directory site with a Mailbox server must also contain a Hub Transport server and, if the mailbox users access their mailbox by using any non-MAPI method, each site must also contain a Client Access server. Anytime that a message needs to be processed for delivery, it will pass through a Hub Transport server, which will make a decision about how the message should be routed. If the message is destined for a Mailbox server in the same Active Directory site as the Hub Transport server, the Hub Transport server will deliver the message to the mailbox. If the message is destined for a Mailbox server that’s in a different site, the Hub Transport server will relay the message directly to a Hub Transport server in the remote site. The Hub Transport server makes use of the Active Directory IP site link cost information to calculate the lowest-cost route to the Active Directory site where the recipient mailbox is located. The message does not stop at each Hub Transport server along the way. It goes directly from source to destination. So why does it bother to calculate the lowest-cost route if it’s relying on the IP network to transport the message? There are a couple of reasons. One is to delay message bifurcation. A message that is being sent to more than one recipient may need to be delivered to Mailbox servers in more than one Active Directory site. Rather than bifurcate, or split, the message at the first Hub Transport server, Exchange 2007 will not split the message until it reaches a fork in the routing path. As a result, the message will be relayed directly to a Hub Transport server in the Active Directory site that represents the bifurcation point. This behavior is known as delayed fan-out.

Note By default, Microsoft Exchange uses the cost assigned to an IP site link for Active Directory replication purposes to compute a routing topology. If, after documenting the existing Active Directory site and IP site link topology, you verify that the link costs for the Active Directory site and the network traffic flow patterns are not optimal for Exchange 2007, you can make adjustments to the costs evaluated by Microsoft Exchange. As an Exchange administrator, you cannot and should not modify the cost assigned to the IP site link by using Active Directory tools. Instead, use the Set-ADSiteLink cmdlet in the Exchange Management Shell to assign an Exchange-specific cost to the IP site link.

91

92

CHAPTER 4 APPLYING PLANNING PRINCIPLES TO EXCHANGE SERVER 2007

The lowest-cost route is also used to determine where to queue the message in case the destination can’t be reached. If a Hub Transport server in the target Active Directory site can’t be reached, the sending Hub Transport server will then attempt delivery to a Hub Transport server in the next closest Active Directory site according to the routing path. Message delivery will continue along the lowest-cost route until it reaches an Active Directory site where a Hub Transport server is available. Finally, if no Hub Transport servers along the route to the recipient Active Directory site are available, the message is queued locally. This method queues the message as close to the delivery point as possible, helping to make diagnosis of network failures more deterministic. This behavior is known as queue-at-point-of-failure. Exchange 2003 works in a completely different manner. It calculates the lowest-cost route from one routing group to another based on the costs assigned to the routing group connectors. A bridgehead server in each routing group along the routing path will receive and then relay the message. If the next connector in the path is not available, an attempt is made to calculate an alternative route. Link state update messages are also communicated throughout the Exchange organization to notify the other Exchange servers that the connection is down. The bridgehead servers will attempt to route around the down connector until a link state notification is received indicating that the connection is up. The challenge when transitioning a large organization is to maintain mail flow during the coexistence period. To achieve this continuity when Exchange 2007 is introduced into the environment, all Exchange 2007 servers become members of a single routing group. This means that regardless of which Active Directory site the Exchange 2007 server is in, Exchange 2003 will see it as belonging to that single routing group. This allows you to establish a routing group connector between that routing group and the Exchange 2003 routing groups so that Exchange 2003 can figure out how to route messages to Exchange 2007. Exchange 2007 will also use the routing group connector to determine how to get messages to Exchange 2003. However, Exchange 2007 will always prefer to route a message through another Exchange 2007 server, and will never backbone across an Exchange 2003 routing group to reach another Exchange 2007 server.

Schema Preparation To prepare AD for the move to Exchange Server 2007, the Schema Master has to have Microsoft Windows Server 2003 SP1 or Windows Server 2003 R2 installed. There must also at least one domain controller in each AD site that contains Exchange Server 2007 running Windows Server 2003 SP1. The AD domain functional level must be at Windows 2000 Server–native or higher for all domains in the AD forest where you’ll be installing Exchange 2007. With regard to preparing the schema and AD before installing Exchange Server 2007, the program has several different preparation switches you can run with the setup.com, including the following: ◆ /preparelegacyexchangepermissions (to grant Exchange permissions where necessary) ◆ /prepareschema (to update the schema for Exchange 2007) ◆ /prepareAD (to configure global Exchange objects in AD) Besides preparing your AD, you’ll need to prepare the domains into which you plan on installing Exchange 2007. Use the /preparedomain and/or /preparealldomains command (which will provide permissions on the domain container for your Exchange servers, permission for Exchange Organization Administrators and a list of other necessary configuration and permission changes) to prepare your domains for Exchange 2007.

UNDERSTANDING ACTIVE DIRECTORY (AD) REQUIREMENTS

Forest Design Because Exchange Server 2007 relies on the Windows Server 2003 AD for its directory, it is important to include AD in the design plans. Happily, if an AD based on either Windows 2000 Server or Windows Server 2003 already exists in the organization, all you have to do is plan for the inclusion of Exchange Server into the forest. If an AD structure is not already in place, a new AD forest must be established. Designing the AD forest infrastructure can be complex and can require you to put nearly as much thought into the design as the actual Exchange Server 2007 configuration itself. Therefore, it is important to fully understand the concepts behind AD before beginning an Exchange 2007 design. Exchange 2007, while requiring an AD forest in all deployment scenarios, has certain flexibility when it comes to the type of AD it uses. It is possible to deploy Exchange in the following scenarios: Single forest The simplest and most traditional design for Exchange is one where Exchange is installed within the same forest used for user accounts. This design also has the least amount of complexity and synchronization concerns to worry about. Resource forest The Resource Forest model in Exchange Server 2007 involves the deployment of a dedicated forest exclusively used for Exchange itself, and the only user accounts within it are those that serve as a placeholder for a mailbox. These user accounts are not logged on to by the end users, but rather the end users are given access to them across cross-forest trusts from their particular user forest to the Exchange forest. Multiple forests Different Multiple Forest models for Exchange are presently available, but they do require a greater degree of administration and synchronization. In these models, different Exchange organizations live in different forests across an organization. These different Exchange organizations are periodically synchronized to maintain a common Global Address List (GAL). It is important to determine which design model will be chosen before proceeding with an Exchange deployment because it is complex and expensive to change the AD structure of Exchange after it has been deployed. William of Occam stressed the concept of simple solutions to complex problems with his famous ‘‘razor.’’ The same principle applies to AD design. You should start with the idea that all that is needed is a simple forest and domain in your environment. However, simplicity is not always possible, and there will be certain cases where you must consider needing more than one AD forest in an organization, among the reasons for this are: ◆ Corporate politics. Some organizations have specific political reasons that force the creation of multiple AD forests. ◆ Security concerns. Highly security-conscious organizations will implement separate AD forests to enhance internal security. ◆ Application functionality. Individual branches of an organization may require that certain applications, which need extensions to the schema, must be installed. This might not be possible or might conflict with the schema requirements of other branches. In those cases, you will likely need an additional separate forest. ◆ In some cases, it might be necessary to install Exchange Server 2007 in a separate forest, to enable Exchange to reside in a separate schema and forest instance. An

93

94

CHAPTER 4 APPLYING PLANNING PRINCIPLES TO EXCHANGE SERVER 2007

example of this type of setup is an organization with two existing AD forests that creates a third forest specifically for Exchange and uses cross-forest trusts to assign mailbox permissions. In any case, always, I repeat always, design AD with simplicity in mind. A Single Forest, Single Domain model will meet the needs of many organizations. If Exchange itself is all that is required of AD, this type of deployment is the best practice to consider. Let KISS (keep it simple stupid) be your byword.

AD Domain Structure Design Once you’ve planned the AD forest structure, you need to lay out the domain structure. Here again, simple is the best policy, and you should strive to establish a Single Domain model for the Exchange 2007 directory. When deploying Exchange is the only consideration, this is often the best choice. There is one major exception to the Single Domain model: the Placeholder Domain model. The Placeholder Domain model has an isolated domain serving as the root domain in the forest. The user domain, which contains all production user accounts, would be located in a separate domain in the forest, as illustrated in Figure 4.1.

Figure 4.1

Forest

A typical placeholder domain configuration

Company main domain

Placeholder

The value of a placeholder domain structure is that it increases security in the forest by isolating high-level schema-access accounts into a completely separate domain from the regular user domain, thus enhancing security. The negative side is that the additional domain will require additional domain controllers, thus increasing the infrastructure costs. You’ll find that in smaller organizations the tradeoff between cost and security is not worth it. Larger organizations can consider the increased security provided by this model, however.

AD Site and Replication Topology Exchange 2007 no longer uses a separate replication mechanism (routing groups) from Active Directory, and Exchange replication takes place within the context of Active Directory sites. This makes proper AD site topology creation a critical component of an Exchange deployment.

UNDERSTANDING ACTIVE DIRECTORY (AD) REQUIREMENTS

Active Directory sites should mirror existing network topology. Where there are pools of highly connected AD domain controllers, for example, Active Directory sites should be created to optimize replication. Smaller organizations have the luxury of a simplified AD site design. In general, the number of sites is small — or, in most cases, a single physical location. Midsize and larger organizations might require the creation of multiple Active Directory sites to mirror the wide area network (WAN) connectivity of the organization.

Domain Name System (DNS) Since both AD and Exchange Server 2007 are completely dependent on the DNS for lookups and overall functionality, DNS is an extremely important design element. Typically, DNS is installed on the domain controller(s), which enables the creation of Active Directory–integrated DNS zones. AD–integrated zones enable DNS data to be stored in AD with multiple read/write copies of the zone available for redundancy purposes. Although using other non-Microsoft DNS for AD is supported, it is not recommended. The main decision regarding DNS layout is what namespace should be used within the organization. The DNS namespace is the same as the AD domain information, and it is difficult to change later. The two options in this case are to configure DNS to use either a published, external namespace that is easy to understand, such as Corp123.com, or an internal, secure namespace that is difficult to hack in to, such as Corp123.internal. In general, the more security conscious an organization, the more often the internal namespace will be chosen. For the sake of simplicity Corporation123 could have chosen corp123.com as its AD namespace. This allows for an environment where the AD logon user principal name (UPN) and the email address can be the same. For example, the user Kim Wimpsett is [email protected] for logging on and [email protected] for email. This the preferred model for many organizations because the need for user simplicity often outweighs the benefits of higher security.

Hardware Considerations In some cases with very small organizations, the number of users is small enough to warrant the installation of all AD and Exchange Server 2007 components on a single server. This scenario is possible, as long as all necessary components — DNS, a global catalog domain controller, and Exchange Server 2007 — are installed on the same hardware. In general, however, it is best to separate AD and Exchange on separate hardware wherever possible.

Locating Global Catalog Servers The global catalog is an index of the AD database that contains a partial copy of its contents. All objects within the AD tree are referenced within the global catalog, which enables users to search for objects located in other domains. Every attribute of each object is not replicated to the global catalogs, only those attributes that are commonly used in search operations, such as first name and last name. Exchange Server 2007 uses the global catalog for the email-based lookups of names, email addresses, and other mail-related attributes. As a result, it is critical that the essential AD global catalog information be available to each Exchange Server 2007 server in the organization. When planning for small offices with a single site, this simply means that it is important to have a full global catalog server available in the main site. Another key consideration, within large organizations in particular, is to design a site structure that reflects available WAN link capacity. This is because full global catalog replication can consume more bandwidth than standard domain controller replication. Only if a sufficient amount of

95

96

CHAPTER 4 APPLYING PLANNING PRINCIPLES TO EXCHANGE SERVER 2007

capacity is available will you be able to place a full global catalog server to be deployed at a site. If not, and capacity is restricted, plan to enable universal group membership caching to reduce the bandwidth load.

Planning for Compliance Analysts estimate that as much as 75 percent of corporate documentation is created and communicated via email. No doubt, a significant amount of your organization’s intellectual property lives on its messaging servers. In business today, email is often both the most common and most preferred method of communication. As a corporate asset, email must be protected and in some instances regulated. Governments and corporate policy makers are defining regulations that affect email and the data it contains. The enforcement of these policies and regulations is known as compliance. As mentioned in Chapter 2, organizations can no longer afford to simply ignore the whole aspect of compliance with legal, regulatory, and corporate requirements regarding the production, handling, transmission, and retention of electronic messages. Each day a demand for evidence for litigation or to provide documentation to regulatory agencies to prove they are complying with their regulations is delivered. Many organizations in the financial services, insurance, and health-care industries must maintain records of communication that occurs when employees perform daily business tasks. Organizations that consider compliance when they plan their information technology infrastructures, including their email infrastructures, can supply the required documentation on demand with less effort. They can also comply with other regulatory requirements more easily. Organizations that don’t consider compliance up front may find themselves sorting through millions of email messages manually, wasting time and money. Organizations can also be held legally responsible for not complying with laws or regulatory requirements. Although an organization may have never been subject to litigation or may not be required to follow regulatory requirements, there’s a good chance that you handle private and confidential information that may be regulated by laws or regulations in your country or region. It’s important that you understand the laws and regulations that apply to your organization and take proactive steps to make sure that you comply with them.

Selected Laws Governing Electronic Records in Effect as of 2007 This list is by no means exhaustive and estimates are that actual laws that have some impact of electronic records, including international, federal, state, and local number in the thousands. ◆

Sarbanes-Oxley Act of 2002 (SOX): A U.S. federal law that requires the preservation of records by certain exchange members, brokers, and dealers.

◆

Security Exchange Commission Rule 17a-4 (SEC Rule 17 A-4): A U.S. Security and Exchange Rule that provides rules regarding the retention of electronic correspondence and records.

◆

National Association of Securities Dealers 3010 & 3110 (NASD 3010 & 3110): The NASD requires that member firms establish and maintain a system to ‘‘supervise’’ the activities of each registered representative, including transactions and correspondence with the public.

PLANNING FOR COMPLIANCE

Also, NASD 3110 requires that member firms implement a retention program for all correspondence that involves registered representatives. These regulations affect primarily broker-dealers, registered representatives, and individuals who trade securities or act as brokers for traders who are subject to the regulations. ◆

Gramm-Leach-Bliley Act (Financial Modernization Act): A U.S. federal law that protects consumers’ personal financial information held by financial institutions.

◆

Financial Institution Privacy Protection Act of 2001: This law amends the Gramm-Leach Bliley Act to provide enhanced protection of nonpublic personal information.

◆

Health Insurance Portability and Accountability Act of 1996 (HIPAA): A U.S. federal law that provides rights and protections for participants and beneficiaries in group health plans.

◆

Uniting and Strengthening America by Providing Appropriate Tools Required to Intercept and Obstruct Terrorism Act of 2001 (PATRIOT Act): A U.S. federal law that expands the authority of U.S. law enforcement for the stated purpose of fighting terrorist acts in the United States and abroad.

In addition to these U.S. laws and regulations, the following regulations also specify requirements that may rely on journaling technology: ◆

European Union Data Protection Directive (EUDPD): This directive standardizes the protection of data privacy for citizens throughout the European Union (EU) by providing baseline requirements that all member states must achieve through national implementing legislation.

◆

Japan’s Personal Information Protection Act: This act regulates the collection, use, and transfer of personal information in and out from Japan. The Personal Information Protection Act applies to government or private entities that collect, handle, or use personal information of 5,000 or more individuals.

Exchange Server 2007 has been designed to help organizations to meet compliance requirements and contains several features that help you capture email messages in a user mailbox and as they flow in, through, and out of the organization. There are generally three broad areas of compliance requirements: information retention, access control, and data integrity. The following list provides several examples of the areas where compliance expectations are increasing and should be planned for based on what you determined in your initial analysis: Data retention policies Many organizations are required to keep data for a specific time and then remove that data to protect privacy. Privacy and confidentiality requirements Organizations have to protect the privacy of individuals and the confidentiality of communications. Ethical walls Organizations that work with securities and other financial information are frequently required to prohibit communication between specific groups in their own organization. Discovery requests Organizations are sometimes subject to litigation. As part of this process, litigants can request information from each other. This information frequently comes in the form of email messages.

97

98

CHAPTER 4 APPLYING PLANNING PRINCIPLES TO EXCHANGE SERVER 2007

The following compliance features provide the tools to help you seamlessly manage messages in your organization: ◆ Messaging records management ◆ Transport rules ◆ Managed folders ◆ Journaling ◆ Disclaimers What you will find yourself doing during this stage of your planning and designing process is working with key personnel to determine what policies currently exist, what policies and practices need to be employed and how, and who will be defining the rules using one or all of these methods to ensure that you meet compliance.

Messaging Records Management (MRM) The purpose of message management policies is to help organizations comply with legal requirements and conserve information technology resources. MRM functionality in Exchange Server 2007 meets the twin goals of messaging management and policy through three principles: ◆ Users classify their own messages. ◆ Obsolete messages are removed. ◆ Required messages are retained. Within your organization, you most likely have rules, limits, and policies that define how large a mailbox can grow, how long email is retained after it is deleted, and perhaps age limits on certain folders. These policies are put in place to manage email within your organization. Messaging Records Management defines the life cycle of an email message within your organization, based on the policies and rules you have in place. After an email message is created and the user clicks ‘‘Send,’’ several things may happen to the message. Obviously, the message is delivered to its recipient(s). Beyond that, several actions may be taken with the email, including: Sent items By default, a copy of each sent message is placed in the Sent items folder. Deleted items Most messages are deleted out of the Inbox. By default, deleted messages are moved to the Deleted items folder. Deleted items retention After a user deletes a message from the deleted items folder, the message may be stored for a period of time defined by the deleted items retention policy configured on the Exchange server. (The default is now 14 days.) After the retention period expires, the message is finally deleted from the user’s mailbox. Journaling during transport During transport, messages that meet defined criteria can be sent to any message archive that accepts SMTP email. An archive contains copies of messages along with message metadata. Journaling managed folder messages Messages in a managed folder (described later in more detail) can be sent to any message archive that accepts SMTP email, such as SharePoint Server 2007.

PLANNING FOR COMPLIANCE

Backups Messages are also copied during each backup. Backups are typically used for disaster recovery but can also be used to retrieve messages that have otherwise been deleted or lost. The life cycle of an email message begins when the message is created, and ends when all copies of the message are deleted. You can manage what happens to the message between these points, as defined by your organization or by government regulations. A simple life cycle is where a message is simply sent and received. With Exchange Server 2007, you can define your email life cycle for messages that touch your organization so that legal discovery and compliance policies are satisfied. As you design your plan, you will need to have a clear idea of what is organizationally required and apply these needs.

Transport Rules Exchange Server 2007 allows you to define and create transport rules that conform to corporate email policy. During message transfer, if the message meets the transport rule criteria, an action will be taken that may affect that message. Rule criteria are based on message sender, recipient, or metadata — such as a word or phrase within the message, or the message classification. Message classification can be applied by a user or rule, such as confidential or personal. When you plan for the deployment and configuration of transport features, you must clearly identify the organization’s business needs and the message-processing practices that best fulfill those needs. To make sure that you have all the information and resources that are required to correctly deploy and configure these features, you should ask the following questions: ◆ Are there corporate or regulatory mandates with which your organization must comply? ◆ Should messages be identified for long-term document retention? ◆ Does your organization transmit confidential messages? ◆ Does your organization have to journal communications between individuals and groups? ◆ Should certain types of messages be scheduled or prioritized? ◆ Do you have to add disclaimers to the body of particular messages? ◆ Should messages be restricted by attachment size or type? ◆ Should certain connections be rejected by content or attachment name? When you determine the business needs of your organization, you can determine the transport features that should be deployed. After you have made these decisions, you will know which features to configure, which agents to enable, and which storage and security resources to make available. In terms of compliance, however, the only important agent is the one that runs on Hub Transport servers. This agent helps you apply policy-based compliance rules to messages flowing through your Exchange organization. (The Edge Transport Server Rules agent, on the other hand, helps you protect your organization against spam and viruses, and is discussed further in Chapter 5.) Some of the common regulatory and compliance requirements that you will need to consider include the following: ◆ Limiting interaction between different groups of senders and recipients (‘‘ethical walls’’) ◆ Preventing inappropriate content from entering or leaving the company

99

100

CHAPTER 4 APPLYING PLANNING PRINCIPLES TO EXCHANGE SERVER 2007

◆ Filtering confidential information ◆ Tracking or archiving messages that are sent to and received from specific users and groups ◆ Redirecting inbound and outbound messages for inspection before delivery ◆ Applying disclaimers Among the common uses of transport rules are ethical walls between users within the same organization whose communication must be managed. You can define a rule where an action is taken when messages are sent between users or groups of users. Several actions can be taken: drop the message, return a nondelivery report, strip attachments, modify the message, journal the message, send a copy of the message to a compliance officer, and so on. For example, Market Analysts and Brokers within an organization — two groups whose communication should be monitored or not allowed — can be managed with a transport rule. In this example, the transport rule restricts messages being exchanged between these two groups of users. Rules can also be defined that take action based on message classification. Users can chose from several types of message classifications within Exchange Server 2007, in addition to classifications that can be assigned by the transport rule itself. For example, all messages sent to the corporate counsel can be classified as confidential. Confidential messages can be archived differently than normal messages, or avoided during discovery searches. You can apply the Transport Rules agent in Exchange Server 2007 to meet any requirements governing messages, the senders, and the recipients. Obviously, in designing your plan and statement of work, you will need to take these into consideration. In addition to compliance, as you will see in Chapter 5, you can plan for and design transport rules to deal with spam and viruses. Transport rules on Hub Transport servers evaluate all meeting requests, regular messages, encrypted messages, and rights-protected messages that are sent between authenticated users, as shown in Figure 4.2. All email messages that are sent anonymously are evaluated, regardless of message type, sender, and recipient. Each transport rule consists of the following components: conditions, exceptions, and actions. Conditions are used to indicate which message attributes — such as headers, recipients, or senders — are used in the message identification process. Once a message meets all of the conditions for a particular rule, actions are applied unless the message matches a configured exception. Exceptions are optional. If configured, an exception will stop any messages that meet any one of the exception criteria from being processed by the transport rule. Actions, which are a required component for each transport rule, specify how a message should be processed. Transport rules are available with both the Exchange Enterprise CAL and the Exchange Standard CAL.

Managed Folders After a message reaches your inbox, it is outside the reach of transport rules, so policy and compliance responsibility is shifted to folder rules. Exchange Server 2007 introduces managed folders, useful for meeting compliance and also for general message organization. Managed folders are created by an Exchange administrator and appear in the mailbox folder list of a user’s mailbox. They can have specific rules and age limits applied to them, but they are not shared across users like public folders. A compliance scenario provides a good example of how a managed folder might be used. Some messages within your organization may need to be retained for seven years for compliance purposes. You can create a managed folder that stores and archives messages for seven years. As

PLANNING FOR COMPLIANCE

users receive messages that require that level of compliance, they move them into the managed folder.

Figure 4.2 Hub Transport server mail flow

Forest SITE A Unified Messaging Server

SITE B Mailbox Server 1

Hub Transport Server 1

Mailbox Server 3

Mailbox Server 2

Hub Transport Server 2

Firewall Third-Party Application or Messaging Server Edge Transport Server Firewall

Internet

Data retention (or records management) is a critical part of your compliance framework. Exchange Server 2007 has taken a big leap forward in how it allows administrators to manage data. In Exchange Server 2007, records management is based on three principles: obsolete messages are removed, required messages are retained, and users are responsible for classifying their own messages. A key part of your plan should be to determine how messages should be classified. Managed folders and the corresponding content settings provide a powerful mechanism for managing the retention and compliance process. Not only does it allow users to sort relevant email and store data in folders that are managed centrally, but it also allows for journaling of these items to ensure that in the event of a discovery request or preservation order, you can easily comply with the court’s request.

Journaling Planning for journaling and designing it into your statement of work will be partly driven by corporate and regulatory demands that you must be aware of and familiar with.

101

102

CHAPTER 4 APPLYING PLANNING PRINCIPLES TO EXCHANGE SERVER 2007

Journaling is the ability to record all communications, including email communications, in an organization for use in the organization’s email retention or archival strategy. Archiving refers to reducing the strain of storing data by backing up the data, removing it from its native environment, and storing it elsewhere. Journaling allows for the auditing of all mail sent to and received by a group of users as required by several different regulations and serves as a key tool in the email retention or archival strategy you are designing. It is also a good tool for ensuring compliance even if not specifically required by a specific regulation since terms and requirements of the regulation may force you to use journaling as a way to comply. Journaling is also a useful tool to organizations for conducting internal policies or audits. Messages journaled by Exchange Server 2007 can be stored in an Exchange database, SharePoint site, or can be sent to any external SMTP address used by third-party journaling companies. In previous versions of Exchange, entire mailbox stores had to be journaled. In Exchange Server 2007, a scope determines what messages are journaled. The scope can be as granular as a single mailbox, a distribution list, a database, or the entire organization. Voice mail messages and missed call notifications can be excluded from the journal. Also, a detailed report on what is journaled includes information such as To:, From:, Cc:, Bcc:, and expanded distribution list information as well as other metadata from each journaled message. The value of this is obvious if you find that your plan needs to include the ability to respond to an ongoing need to place a hold on the email messages of certain individuals, because, for example, of an internal investigation or a court case. Exchange Server 2007 allows the administrators to add and remove users to an established group that is already being journaled. This provides a quick and easy way to provision ad hoc journaling. Figure 4.3 provides a good overview of how Exchange Server 2007 journaling operates.

Figure 4.3 Exchange Server 2007 journaling

From: To: Cc: * Bcc: * Subject: Original Message

JOURNAL AGENT Is there a journal rule that matches this message?

Recording Message

Journal Report Normal Delivery

Hub Transport Role

Create a Journal Report

Journal Mailbox

Sender: Message ID: Subject: Original Message

From: To: Cc: * Bcc: * Subject: Original Message

To: Cc: * Bcc: *

*Ps: The fields CC: and BCC: are optional

PLANNING FOR COMPLIANCE

You will have to determine which of the two versions of journaling should be implemented, premium or standard.

Leveraging Journaling Technology By US federal law corporate officers at Wimpsett Financial Services are responsible for the claims made by their employees to their customers. In order to verify that this is the case and the data provided is accurate, a corporate officer sets up a system whereby managers review some part of employee-to-client communications regularly. Every quarter the managers verify compliance and approve their employees’ conduct. After all managers report approval to the corporate officer, the corporate officer reports compliance, on behalf of the company, to the regulating body. In this scenario, email messages are one of the employee-to-client communications that managers must review, so all email messages that are sent by client-facing employees are journaled. Other client communication mechanisms may include faxes and telephone conversations, which must also be recorded. Hence with Exchange Server 2007’s ability to journal all classes of data in an enterprise, Wimpsett Financial Services not only can meet internal audit requirements but also document them and be able to act resolutely and confidently in the event that employees are not meeting the standards.

Premium Journaling Premium journaling, new to Exchange Server 2007, allows the targeting of journaling rules by specifying Simple Mail Transfer Protocol (SMTP) addresses that belong to mailboxes, contacts, or distribution lists that you want to journal in your organization. When you specify a target recipient or sender on a journal rule, you target specific recipients or senders for journaling. These recipients or senders may be subject to the regulatory requirements that were described earlier in this topic. Alternatively, they may be involved in legal proceedings where email messages or other communications are collected as evidence. If you target specific recipients, senders, or groups of recipients or senders, you can easily configure a journaling environment that matches your organization’s processes and regulatory and legal requirements. Premium journaling requires Exchange Server 2007 Enterprise Edition CALs.

Standard Journaling Standard journaling is basically the same as journaling in Exchange Server 2003. It enables journaling on a per-mailbox store basis. When a mailbox database has standard journaling enabled, all the messages that are sent to or from mailboxes in a mailbox database are sent to the specified journaling mailbox. If you have only Exchange Standard CALs for the mailboxes that you want to journal, you must use standard journaling.

Licensing and Compliance Features The availability of compliance features depends on whether you have purchased Exchange Enterprise CALs or Exchange Standard CALs. As you can see in Table 4.6, all the compliance features listed earlier are available to you if you have purchased Exchange Enterprise CALs. If you have purchased Exchange Standard CALs, you can use only the compliance features that are part of the Exchange Standard CAL.

103

104

CHAPTER 4 APPLYING PLANNING PRINCIPLES TO EXCHANGE SERVER 2007

Table 4.6:

Compliance Features Available for Each Type of CAL

Compliance feature

Exchange Standard CAL

Exchange Enterprise CAL

Messaging records management

No

Yes

Hub Transport rules

Yes

Yes

Standard journaling

Yes

Yes

Premium journaling

No

Yes

If you want to use the advanced compliance features available with an Exchange Enterprise CAL, purchase the number of Exchange Enterprise CALs equal to the number of users who will be using the advanced compliance features. For example, if you have 1,000 mailboxes and plan to enable MRM on only 100 of those mailboxes, you only have to purchase 100 Exchange Enterprise CALs. The 900 remaining licenses can be Exchange Standard CALs. If you want to apply premium journaling to some of the same 100 mailboxes that were previously covered by the Exchange Enterprise CALs, you don’t have to purchase additional licenses. However, if you want to apply MRM or premium journaling to more than the original 100 mailboxes, you must upgrade the appropriate number of Exchange Standard CALs to Exchange Enterprise CALs. You can use either Exchange Enterprise CALs or Exchange Standard CALs with both Microsoft Exchange Server Enterprise Edition and Microsoft Exchange Server Standard Edition. For example, you can put mailboxes that require premium journaling, such as Exchange Enterprise CALs, on a computer that is running Exchange Standard Edition. Other features of Exchange 2007 may require Exchange Enterprise CALs. You must purchase Exchange Enterprise CALs for each mailbox that uses an Exchange Enterprise CAL feature. As discussed at the beginning of the chapter, you are going to have to spend time carefully assessing your licensing needs.

Exchange Hosted Services Some compliance features are enhanced by or are also available as a service from Microsoft Exchange Hosted Services. Exchange Hosted Services is a set of four distinct hosted services: ◆ Hosted Filtering, which helps organizations protect themselves from email-borne malware ◆ Hosted Archive, which helps them satisfy retention requirements for compliance ◆ Hosted Encryption, which helps them encrypt data to preserve confidentiality ◆ Hosted Continuity, which helps them preserve access to email during and after emergency situations These services integrate with any on-premise Exchange servers that are managed in-house or Hosted Exchange email services that are offered through service providers. Exchange Hosted Services will be discussed in greater detail as part of Chapter 5’s assessment on whether to keep your Exchange Server in-house or to outsource some or all of it.

PLANNING FOR COMPLIANCE

Message Classifications Message classifications is a Microsoft Exchange Server 2007 and Microsoft Office Outlook 2007 feature that is intended to help organizations comply with their email policies and regulatory responsibilities. By default, there are four message classifications when Exchange Server 2007 is deployed and which are available in OWA. Below, the four default message classifications are explained: Company Confidential confidentially.

This contains proprietary information and should be handled

Company Internal This contains sensitive information that should only be delivered to internal recipients. A/C Privileged This kind of message is either a request for legal advice from an attorney or a response by an attorney about legal advice. It’s also called ‘‘Attorney/Client Privileged.’’ Attachment Removed The attachment was removed from the email. Technically speaking there is a fifth default classification, ‘‘No Restriction,’’ which is merely a traditional message without any added metadata. When a message is ‘‘classified,’’ the message contains specific metadata that describes the intended use or audience of the message. Outlook 2007 or Microsoft Office Outlook Web Access may act on this metadata by displaying a user-friendly description of the classification to senders and receivers of a classified message. In Exchange Server 2007, the Exchange Transport service may act on the metadata if there is a transport rule that meets specific criteria that are configured by the Exchange administrator. The following list provides a brief description of some of the message classification fields that can be set by the Exchange administrator: ◆ Display name ◆ Sender description ◆ Recipient description ◆ Locale It is important to remember that in the initial installation of Exchange Server 2007 all message classifications are informational only. They don’t do anything because they are not associated with rules. Default message classifications are simply a way for senders to communicate additional information about a message to the message recipients. Your plan can consider and call for creating a global transport rule that enforces some or all of the message classification based on your business needs. For example, if the client organization is a law firm or a company with a legal division, you can group the attorneys into organizational unit that is called ‘‘Legal.’’ You can then configure a transport rule that returns messages that are classified as A/C Privileged to the sender if the sender or at least one recipient on the To or Cc line is not in the Legal group. Message classifications can be logically separated into two classes based on how they are attached to a given message: ◆ A message classification can be manually added by the sender of a message. ◆ A message classification can be added as the result of a rule.

105

106

CHAPTER 4 APPLYING PLANNING PRINCIPLES TO EXCHANGE SERVER 2007

You can create more than one message classification instance for each language in your organization. If you have multiple, localized versions of a given message classification, Outlook and Outlook Web Access will display the correct version based on the language settings on the user mailbox. In some scenarios, your business needs may dictate following different regulations for different regions or locales where your business operates. In these cases, it may not make sense to display all message classifications to all users. For example, health care–related companies that operate in the United States and in Europe may have to comply with Health Insurance Portability and Accountability Act (HIPAA) regulations in the United States but not in Europe. Therefore, the display of message classifications that are HIPAA-specific should only be enabled for employees operating in the United States. You can set read permissions on classifications so that only appropriate users can view specific message classifications.

Overview of Disclaimers After several high-profile lawsuits with multi-million dollar penalties concerning the contents of corporate emails, companies are increasingly aware that simply by using email they are exposing themselves to legal threats. Email disclaimers can also be used for marketing purposes or to provide warnings about unknown or unverified email senders or for any other reasons determined by an organization. Exchange Server 2007 includes the ability to add text disclaimers to email messages that are processed on a computer that has the Hub Transport server role installed. Disclaimers are typically used to provide legal information and warnings about unknown or unverified email senders, or for various other reasons as determined by an organization. There are several legal threats that disclaimers can help protect against: Breach of confidentiality By including a disclaimer that warns that the content of the email is confidential, you can protect your company against the exposure of confidential information. If the receiver breaches this confidentiality, they could be liable. Accidental breach of confidentiality If an employee were to receive a confidential mail from someone and by accident forward it to the wrong person, the employee, and therefore the company, could be liable. This can easily happen. For instance a wrongly addressed email can be forwarded to a postmaster, who might not be authorized to read the mail. Furthermore, email can easily be intercepted. If you include a statement at the end of your mail that the message is only intended for the addressee, and that if anyone receives the email by mistake they are bound to confidentiality, this could protect you. Transmission of viruses If an employee sends or forwards an email that contains a virus, your company can be sued for this. Apart from implementing a good virus checker that blocks viruses entering and leaving the company via email, you can also warn in your disclaimer that the email can possibly contain viruses and that the receiver is responsible for checking and deleting viruses. Entering into contracts Written communication, including email, can be used to form binding legal contracts if the individuals have actual or apparent authority to do so. If you do not wish certain employees to be able to form binding contracts by email, you could include a statement that any form of contract needs to be confirmed by the person’s manager. Negligent misstatement By law, a person is obliged to take care when giving advice that a third party relies on. If an employee were to give professional advice in an email, the

PLANNING FOR COMPLIANCE

company will be liable for the effect of the advice that the recipient or even third party, reasonably relies upon. A suitable disclaimer could protect your company from this kind of liability.

Disclaimers Are Not a Panacea There is no certainty that if a company is sued for the contents of an email, that an email disclaimer will protect it from liability in a court of law. However, it will certainly help and in some situations might exempt the company from liability because it can show it has acted responsibly. Although a company is ultimately responsible for the actions of its employees, including the content of any emails they send, a disclaimer can decrease liability. If a company can show that it has correctly instructed its employees not to send libelous, inappropriate, or defamatory statements this could help in disclaiming responsibility if an employee breaches these rules. A company can demonstrate this by including an email disclaimer to that effect, and by implementing an email policy that clearly warns employees against misuse of email. There is no disclaimer that can protect against actual libelous or defamatory content. The most a disclaimer can accomplish in this respect is to reduce the responsibility of the company, since it can prove that the company has acted reasonably to stop employees from committing these offenses.

Apart from legal uses, disclaimers can be used to add a footnote or to add a signature for marketing purposes. A ‘‘disclaimer’’ can also be used to add a company address, URL, and/or slogan if wished. In some countries companies are required to state the company’s particulars on any written communication. Since email is also written, it is probably best to include this in emails as well. Another benefit of using disclaimer is that they help an enterprise convey a professional, trustworthy image.

Disclaimer Examples Disclaimers can serve a variety of purposes, not only legal but also marketing and customer service support and information ones. The following examples, taken from my own email, show you the uses to which this technology can be put. You encourage management to think of various proactive ways to use disclaimers to promote their business and not just for defensive antilawsuit purposes.

Amazon.com We hope you found this message to be useful. However, if you’d rather not receive future emails of this sort from Amazon.com, please visit the opt-out link here: http://www.amazon.com/ gp/gss/o/1U4V7f41B4j.GH5WzGigvvY4BFb47iy-8AQqoA9w43HM Please note that product prices and availability are subject to change. Prices and availability were accurate at the time this newsletter was sent; however, they may differ from those you see when you visit Amazon.com.

107

108

CHAPTER 4 APPLYING PLANNING PRINCIPLES TO EXCHANGE SERVER 2007

(c) 2007 Amazon.com, Inc. or its affilates. All rights reserved. Amazon, Amazon.com and the Amazon.com logo are registered trademarks of Amazon.com, Inc. or its affilates. Amazon.com, 1200 12th Ave. S., Suite 1200, Seattle, WA 98144-2734.

GFI DISCLAIMER The information contained in this electronic mail may be confidential or legally privileged. It is for the intended recipient(s) only. Should you receive this message in error, please notify the sender by replying to this mail. Unless expressly stated, opinions in this message are those of the individual sender and not of GFI. Unauthorized use of the contents is strictly prohibited. While all care has been taken, GFI is not responsible for the integrity of the contents of this electronic mail and any attachments included within. This mail was checked for viruses by GFI MailSecurity. GFI also develops antispam software (GFI MailEssentials), a fax server (GFI FAXmaker), and network security and management software (GFI LANguard) - www.gfi.com

Against The Odds Magazine Against the Odds Magazine has won three Charles S. Roberts Awards for Best Wargaming Magazine. Visit us at www.atomagazine.com and see why! Andy Nunez, besides editing Against the Odds is also the author of Treasures of the Eastern Shore, Mysteries of the Eastern Shore, Crimson Need, and the upcoming Ghosts of the Eastern Shore, all available from www.cambridgebooks.us.

Law offices of Hilary B. Miller This message, together with any attachments, is intended only for the use of the individual or entity to which it is addressed and may contain information that is legally privileged, confidential and exempt from disclosure. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this message, or any attachment, is strictly prohibited. If you have received this message in error, please notify the original sender immediately by telephone (203-399-1320) or by return email and delete the message, along with any attachments, from your computer. IRS Circular 230 disclosure: Any tax advice contained in this communication (including any attachments) was not intended or written to be used, and cannot be used, for the purpose of (i) avoiding tax-related penalties under the Internal Revenue Code or (ii) promoting, marketing or recommending to another party any matters addressed herein. Thank you.

British Airways IF YOU HAVE RECEIVED THIS EMAIL IN ERROR This is a confidential email intended only for the British Airways customer appearing as the addressee. If you are not the intended recipient please delete this email and inform the sender as soon as possible. Please note that any copying, distribution or other action taken or omitted to be taken in reliance upon it is prohibited and may be unlawful.

PLANNING MAIL ARCHIVING

Jumeirah Emirates Towers Disclaimer Jumeirah is a trade name of Jumeirah International LLC, a limited liability company incorporated in Dubai. Commercial Registration Number 57869. Share Capital Dhs. 300,000 fully paid up. The information in this email is private & confidential. It is intended only for the use of the person(s) named. If you are not the intended recipient, you are notified that any dissemination or copying of this communication is prohibited and kindly requested to notify the sender and to then delete this message. Jumeirah International LLC gives no representation or guarantee with respect to the integrity of any emails or attached files and the recipient should check the integrity of and scan this email and any attached files for viruses prior to opening.

Unique Disclaimers The following conditions are examples of business conditions that might require that you use unique disclaimers: ◆ Legal requirements that may be different in various countries or regions ◆ Different languages ◆ Business or regulatory requirements that may be different in multiple regions ◆ Potentially unsafe email messages that are sent to internal users

Disclaimers for Messages That Can’t Be Modified Some messages, such as encrypted messages, prevent Exchange from modifying the content of the original message. Exchange enables you to control how your organization handles these messages. When you create a new disclaimer, you can decide whether to wrap a message that can’t be modified in a message envelope that contains the disclaimer, reject the message if a disclaimer can’t be added, or let the message continue without a disclaimer.

Planning Mail Archiving Since Chapter 2 we have been discussing the need to comply with certain requirements and the fact that such requirements must be factored into your planning. In Chapter 4, we discussed the role of journaling and other compliance meeting actions and tasks that you needed to take into consideration. All these touch on the concept of mail archiving in one way or another. Your plan for your Exchange Server 2007–based messaging system must include provisions for archiving email, whether or not you intend to use Exchange Server 2007 exclusively, use it in conjunction with third-party products, or use third party products exclusively. As you should be aware, email has become a primary channel of business communication. As email has evolved into electronic substitutes for legal business documentation, the information in the email now constitutes a legal record. Hence, as with all records, these emails must now be retained for a minimum period of time, often established by statutes. As mentioned previously, there is considerable legislation and regulatory requirements describing what to retain, how to

109

110

CHAPTER 4 APPLYING PLANNING PRINCIPLES TO EXCHANGE SERVER 2007

retain it, and how accessible it must be. Simply stated, retaining these records is critical and must be planned for. You should also understand the real difference between a true email archive and an email backup that is sometimes erroneously described as archival. An email archive is a repository of correspondence, usually held in a nonproduction environment that provides a secure preservation of email for compliance and operational purposes. A ‘‘true’’ email archiving system automatically extracts message contents and attachments from incoming/outgoing emails, and after indexing, it stores them in read-only format. This ensures that archived records are maintained in their original state. Because it’s active, archiving ensures that an organization has a centralized and accessible copy of all its email. This provides additional protection against accidental or intentional deletion of emails by end users. Email archiving also eliminates the need to search for personal archives on each and every local machine whenever litigation support is requested. Record authenticity (i.e., preservation of a record in its original state) is one of the key requirements in many of the content regulations imposed by the laws. This is completely different from email backup. Backups are intended to save current data against the event of failure or disaster. That’s all. The data is not ‘‘archived,’’ merely stored. By contrast email archiving systems preserve data in a manner that allows it to be accessed when needed by using advanced search and retrieval functions. These systems allow users to track down email messages in a timely and cost effective manner. Email archiving also allow for the creation of access restrictions to secure and protect intellectual property rights as well as ensure data integrity and confidentiality in compliance to the statutes. Email archiving solutions offers businesses tremendous capabilities — from optimizing their email environment to providing archive, search, and retrieval options for compliance and discovery mandates. Often the benefits these solutions provide go beyond the scope of an organization’s initial requirements. Prior to planning and implementing an email archive solution, you should carefully examine the drivers that determine the solution. You should also carefully research the companies that offer email archive solutions, as this is a relatively new market and some technology vendors don’t have the track record that others do.

The Cost of Discovery The cost of finding the electronic records for a discovery process can be astronomical, requiring months of IT manpower to wade through backup tapes. Failing to find the records or losing them can lead to a series of fines and directed judgments. Your email archiving design should prevent these sort of occurrences: ◆

In Murphy Oil USA v. Flour Daniel, the defendant was ordered to restore and print the emails contained in 93 tape backups and to absorb the total costs involved to perform this operation which amounted to $6.2 million.

◆

In March 2004, Bank of America was fined $10 million by the Securities and Exchange Commission (SEC) for failing to retain email records for the time stipulated by the regulation and for failing to submit the information requested by SEC in a timely manner.

PLANNING MAIL ARCHIVING

◆

Investment firms Deutsche Bank Securities Inc., Goldman Sachs & Co., Morgan Stanley, Solomon Smith Barney Inc. and U.S. Bancorp Piper Jaffray Inc. were all fined $1.65 million each for not complying with SEC Rule 17a-4 and for failing to produce emails requested during the course of an investigation.

◆

The cost for restoring 77 tape backups in the case Zubulake vs. Warbung (USB Bank) amounted to $165,954, and the relative review costs totaled to $107,694.

◆

Philip Morris International, one of the largest tobacco companies in the world, was fined $2.75 million dollars for destroying emails in violation of a 1999 order.

Why Archive Email? There are four key reasons for an organization to archive its email. These are compliance, judicial discovery, storage management, and knowledge control.

Compliance The new regulatory environment is one of the major drivers behind the increase in demand for email archiving solutions. Although the data subject to regulatory statutes varies by industry, all records that pertain to the organization’s business activity are subject to compliance regulations. These include employee and client records, correspondence between organizations, and financial documentation. Other legislation defines requirements for specific regulated industries. Some legislation relates to the amount of time records must be held, while other legislation relates to what can be held. While it is not always clear-cut what these laws require, and there is some degree of subjectivity in interpreting the laws, several common themes emerge: ◆ Electronic business records (including email communications) are now placed under the same scrutiny as their paper-based counterparts. Failure to manage these records properly and failure to reproduce certain email data upon request could be deemed an obstruction of justice. ◆ Organizations are being required to archive email data systematically as a standard course of business and, in some cases, on a inalterable storage medium to bolster the evidentiary value of this data. ◆ Organizations are being required to document their data management practices and requirements related to email and to communicate this information to employees so that all stakeholders are on notice as to the liabilities associated with email messages. ◆ Metadata or descriptive information about the email data itself is viewed as a key consideration when evaluating the evidentiary value of archived email messages. Although many regulations exist and each seems to have its own requirements, email archiving compliance is based on three main concepts: ◆ Archived data must be retained in its original state without being altered or deleted. ◆ Archived information that is retained must be safeguarded against all security threats, which include access by unauthorized persons as well as anything that could physically damage or endanger the availability of the information.

111

112

CHAPTER 4 APPLYING PLANNING PRINCIPLES TO EXCHANGE SERVER 2007

◆ Archived information should be easily accessible in a timely manner by authorized personnel whenever required. Any archiving plan and product should ensure that these exist.

Judicial Discovery Sooner or later every company, large or small, is going to become involved in a lawsuit, either as a defendant or a plaintiff. Every lawsuit inevitably involves the process of judicial discovery. Discovery is the process in which parties involved in a lawsuit are requested by the court to submit information that is relevant to the case. The company that receives the discovery request must search its records and submit all the relevant/requested information in a timely manner. Recent court rulings have acknowledged that the company providing the information must endure the discovery cost, without reimbursement. As you can imagine, as is shown in our real-world examples, the cost of producing the information for litigation can be colossal and can often outweigh the damages sought in the suit, especially if the organization does not have an adequate email archiving solution in place. An issue with discovery requests is that there is no specific time limit that defines on how far back a company must search. Organizations are required to provide all copies of email relevant to the request, regardless how far back this may be. The completeness and availability of all the requested records and the time required to extract this information depends very much on the organization’s email storage management and employee behavior. Other issues that need to be considered are that litigation support information must be accurate, complete, and possibly in its original state. An organization that fails to submit the information requested in a legal discovery can be found guilty of ‘‘spoliation.’’ This is legal term describes the improper destruction of evidence. If a court feels that there is a basis to believe spoliation has occurred, it can do a number of things, almost all of them bad for the party found involved in spoliation. The court can order a verdict for the other party, or the court can assume that the lost information was harmful to the party that failed to produce it and instruct a jury to act accordingly. Finally, there can be hefty fines.

Storage Management It has been estimated that one in every four organizations experiences a storage management growth rate in excess of 25 percent per year. It is also estimated that nearly 50 percent of organizations are providing more than 150 MB of storage per user. A study by Osterman Research affirms that email stores are growing at 37 percent annually. Consequently, keeping email in a ‘‘live’’ (online) storage format will necessitate more physical storage space as well as increasingly powerful hardware to handle these loads. Compliance regulations have further contributed to the increased demand for storage by obliging organizations to preserve old email for predefined periods. Email archiving solutions can be used to provide a more versatile way of storage management by doing the following: ◆ Centralizing the organization’s email records. ◆ Storing emails in a compressed format. ◆ Automatically archiving emails as they pass through the message store. ◆ Allowing authorized users to view emails from a central repository can encourage them to eliminate bulky PST files stored locally.

PLANNING MAIL ARCHIVING

Knowledge Control An organization’s email system is also a vast and comprehensive corporate knowledge repository. It can contain vast quantities of useful email information that are often vital to a business, and allowing access to this corporate asset can make users more productive. An email archiving system can provide appropriate knowledge management tools (for example, email record sorting, advanced searching, and retrieval functions) that enable IT and end users to better manage the knowledge base contained in the company’s email archive.

Performance Archiving can enhance performance. By decreasing the size of the primary email database, the performance of the email servers is enhanced and there is a subsequent reduction in the amount of high-performance storage required for email. Backup and recovery operations will be improved as well. Because persistent (that is, static) data is archived, the amount of unchanged data that is backed up again and again is reduced.

Email Archiving Planning Considerations Based on the above, any email archiving solution should include the following features: ◆ Emails should be archived automatically and with the minimal human intervention possible. ◆ Archived emails should be indexed, especially the text content, so that search facilities will enable the quick extraction of records to support regulatory audit requests and legal discovery. ◆ The email archiving plan system must include configuration features through which the company can define its archiving criteria. These features should at least allow archiving of specific mailboxes and messages from specific domains or email addresses. ◆ The email archiving system must be able to ensure that records are secure from loss, damage, or misuse. The solution must include access restriction features. ◆ Journaling must be used for organizations that are using the email archive solution for governance (i.e., a system of record), since it ensures that each email is captured and saved. ◆ The solution should enable a company to use its email archive as a central knowledge repository from where authorized users can extract information required. Depending on how the system is configured, the retrieval can essentially be transparent to the end user. ◆ The archiving system should support all major messaging platforms to ensure standards compatibility.

Deploying and Managing Email Archive Solutions There are two main methods for deploying and managing email archive solutions: ◆ A completely in-house solution ◆ A hosted solution in which the archive is maintained at a third party’s data center

113

114

CHAPTER 4 APPLYING PLANNING PRINCIPLES TO EXCHANGE SERVER 2007

An in-house email archiving solution involves having your email repository on a server within the corporate building. The main advantage of in-house archiving is that the organization’s sensitive information is stored behind the corporate firewall and is handled by its own internal staff. This ensures better control over data integrity and confidentiality. The organization relies entirely and independently on its own resources and can therefore assess its compliance status at any time. The main disadvantage is the upfront costs involved and the sudden impact that the system might have on the company’s IT department. In order to deploy an internal email archive, the company must purchase an adequate email archiving program as well as the hardware (server) that will host the archive. Hosted solutions require lower upfront cost than in-house solutions. Customers can get up and running fairly quickly without the investment in hardware and IT staff. Running costs are also low since new capabilities and software/hardware upgrades are generally implemented by the provider. In hosted solutions, a software application located on the corporate email server captures email and migrates it offsite via the Internet to a third-party data warehouse for archiving. Authorized users can subsequently access the data stored offsite using a web browser or compatible email client. However, it is likely that many, if not most organizations will prefer a message archiving solution that is operated completely in-house. This perception is primarily attributed to the fact that organizations feel more confident when storing sensitive corporate data in-house rather than on third-party servers outside the company (i.e., hosted archiving). In addition companies that manage their own email systems have the final say on when things get done whereas with a hosted system the company’s priorities compete with those of the service provider. Such a limitation may actually place an organization at higher risk because archival records might be incomplete and/or may not be able to be retrieved in the time required by a request. Organizations must also consider the possibility of a provider going out of business or failing to provide a service compliant to the statutes. In such an event, the company will be forced to change service supplier or must switch to an in-house archiving solution. In either case, the archiving service will be disrupted and extra money must be spent. Some organizations perceive hosted archiving solutions as a way to shift liability to the outsourcing vendor but this is a misconception, as the liability continues to fall with the data owner (that is, the organization employing the outsourced resources).

In-House vs. Outsourced Services Now that you’ve determined what needs to be planned for and how it should be implemented, one final consideration is where and how you want to provide these services. In the past, the answer was relatively simple; most companies and enterprises would purchase the needed hardware and software, and hire the necessary support staff. However as Exchange, and the whole area of messaging systems, has become more complex that simple option has started to lose its allure and practicality. Exchange 2007 is the first major update since Exchange 2003, and it is the first version of the software that runs only on 64 bit servers. Previously, Exchange ran on 32 bit servers, so customers will not be able to just switch out their current version of Exchange to a new one. They will be required to update the hardware. The introduction of server ‘‘roles’’ in Exchange Server 2007, while a boon in one regard, also means that the software can no longer be set up for high availability on two servers — one for the roles and one for failover. Now, to run all of the three primary Exchange 2007 roles (mailbox server, hub transport, and client access) with high availability, you will typically need up to four servers, which is twice as many as you needed in Exchange 2003. If your design adds the Unified Message and Edge Transport roles, you need six servers. Of course, if you don’t want high

IN-HOUSE VS. OUTSOURCED SERVICES

availability, you can run all the roles of Exchange Server 2007 on one server, except for the Edge Transport server. The question of course is whether or not an enterprise is willing to forego high availability for their messaging system. Most won’t take that risk. New hardware requirements, incompatibilities with other Microsoft software, and the complexity of the product’s new architecture are just a few of the issues that can make a move to Exchange 2007 from Exchange 2003 or earlier versions costly for a company and difficult for IT administrators. There are 6,000 pages of documentation for an IT administrator to review and understand in order to deploy Exchange Server 2007. Another concern is the need for added functionality that most organizations will have for email archiving, storage management, and continuity service messaging, which is not fully met with standard features. For example, Exchange 2007 lacks capabilities for the following: ◆ The ability to set, secure, or easily manage granular message retention and deletion rules ◆ The ability to place legal holds on selected mailboxes to prevent the destruction of messages ◆ Storage management capabilities to reduce data store sizes or improve backup, recovery, and maintenance window times ◆ The ability to execute finely tuned searches for messages, and/or attachments across multiple mailboxes ◆ End user search and recovery of deleted or lost messages and attachments ◆ Continuity services that protect against site outages, infrastructure problems, database corruption, Exchange & Active Directory problems, and configuration errors ◆ Email recovery services that protect against message loss in the event of database corruption ◆ Wireless device continuity services that protect against BlackBerry downtime during Exchange, Active Directory, and infrastructure outages Nearly all companies, especially U.S. companies regulated under Sarbanes-Oxley or with active litigation subject to the Federal Rules of Civil Procedure, consider these archive, compliance, and disaster recovery capabilities to be essential email requirements. As a result, most companies will probably deploy Exchange 2007 with a complementary mail archiving solutions as discussed in the next section. With part of the solution already being outsourced, there will likely be some pressure to outsource the entire messaging system solution. For many small and medium businesses (SMB) the entire cost, both financial administrative and resource intensive of an in-house Exchange Server 2007–based messaging system may simply be too much. Upfront costs can exceed $10,000, plus staff time to maintain the server. These considerations may necessitate SMBs considering different strategies. Large enterprises will likely be less inclined to make a move to a hosted Exchange system, but increasing complexity and resource consumption will start to drive organizations to study their options in that regard.

Pros and Cons of Outsourcing Outsourcing has a number of substantial benefits. When done correctly, it can provide SMBs with direct positive outcomes: ◆ Low cost-of-ownership and cost predictability ◆ Rapid deployment ◆ Scalability

115

116

CHAPTER 4 APPLYING PLANNING PRINCIPLES TO EXCHANGE SERVER 2007

◆ Anytime, anywhere access to information ◆ Business-class messaging and collaboration ◆ Malware management Outsourcing reduces or eliminates the following: ◆ Purchasing hardware and software, reducing startup costs ◆ Maintenance expenses ◆ Administrative staff needs ◆ Maintaining hardware and software updates In addition, it makes sense to utilize off-site solutions that have no dependency on your organization’s internal infrastructure. Similarly using an outsourced service eliminates spam and viruses at the perimeter before they utilize your organization’s bandwidth and server capacity. Finally, for archiving, it is often important to have a third-party custodian who can certify the integrity of the message archive in the event of a lawsuit or compliance investigation. Outsourcing email is usually a harder decision for a large enterprise IT to make. This is because there is already significant investment in resources and expertise, which acts as an anchor to keep email servers and administration in-house. Also outsourcing from a large enterprise requires careful strategic planning because of the integration between email and other applications that may already exist. There may also be custom integration with other enterprise systems, such as order-taking systems that get their input from email.

Service-Level Agreements Before finalizing an outsourcing arrangement, you should have a service-level agreement (SLA) with the vendor. Simply described an SLA is a formal negotiated agreement between customers and their service provider, or between service providers. A typical SLA records the common understandings about services, priorities, responsibilities, guarantees, and the like, with the main purpose being to agree on the level of service. For example, it may specify the levels of availability, serviceability, performance, operation, or other attributes of the service such as billing, and even penalties in the case of violation of the SLA. There are two major parts to an SLA — the governing document and the process: ◆ The SLA document is usually legally binding between a company and an outsourcing vendor(s). The document describes the exact services and service levels, with details about all agreements. ◆ The SLA process represents the methods that the outsourcing vendor will use to support the SLA document. The methods of supporting the SLA document are usually left to the outsourcing vendor to identify. These processes should be discussed and possibly identified during SLA contract negotiation. It is important that both parties understand the processes and methods of support as well as the management and reporting tools. The SLA process represents a third of the total solution. It is up to the outsourcing vendor and your company to ultimately choose the correct people to manage the systems and the best technology for implementation. The people involved in managing the process must also manage the technologies and understand the importance of reporting on and monitoring the entire system.

IN-HOUSE VS. OUTSOURCED SERVICES

System management and service desk automation technology can provide a supporting environment for tracking, escalation, and management of service metrics. End-user satisfaction surveys can also provide input that will help target appropriate service levels and cost controls.

Proper Elements of an SLA Let’s take a look at what needs to be considered in creating an SLA document for the fictional company Maeder Enterprises: Statement of objectives The primary objective of an SLA document is to correctly identify the support requirements for Maeder Enterprises in regard to supporting the messaging system needs. Usually this will be negotiated between the Maeder Enterprises and the vendor. Contacts and role assignment First, name the key contact for the service-level agreement and delegate SLA management tasks to others. You may need to include other contacts such as management, technical personnel, and the like. Reporting The frequency and detail of reports must be identified as well. Finances Payment terms and contract length are negotiated with the outsourcing vendor. Contract termination procedures Specifies how the contract is terminated. Specifies penalties, if any. Specifies whether technology transfer must occur. Review process There should be a formal review to evaluate the performance and customer service levels as well as staff reviews. A quarterly review is sometimes formalized in order to include discussions on SLA fulfillment, staffing, and future projects that may affect the SLA. Change management Specifies how amendments and changes can be made to the existing SLA. Several things could require a change or addendum to the existing SLA: ◆

A change in the process workflow

◆

Additional services

◆

Missed performance or customer service thresholds

◆

Additional third-party applications

Usually these changes are detailed by contract riders appended to the SLA until such time that the SLA is rewritten to incorporate the addendums. The SLA can only be written during a renewal cycle, with both parties present. Financial incentive plan Specifies penalties and bonuses for meeting or exceeding SLA performance guidelines. This can be used as a carrot/stick approach to ensure SLA compliance. Performance-level guidelines These should be specified and metrics applied. In the case of an SLA for Exchange outsourcing, typical metrics might include: ◆

Intersite message transfers

◆

Intrasite message transfers

117

118

CHAPTER 4 APPLYING PLANNING PRINCIPLES TO EXCHANGE SERVER 2007

◆

Remote synchronization performance

◆

Offline address book refreshes

◆

Mailbox replication/size

◆

Directory update frequency

◆

Administrative task time limits (e.g., one business day to add a mailbox)

Uptime requirements System availability can be an expensive requirement. It is important to identify the specific requirements from a resource access standpoint and not necessarily on a server-by-server basis. The specifics dictate the availability of the services: ◆

Network and remote access

◆

Mailbox access

◆

Public folder access

◆

Intersite directory

◆

Intrasite directory

◆

Server availability

Equipment support requirements For access and security, you should require that named contacts be permitted physical access to the equipment at any given time. Moreover, overall access to the equipment must be secured and restricted. Access to the equipment must be available 24 hours a day, 7 days per week for the vendor’s support personnel. For backups, many companies require that the clients be able to request a ‘‘recovery of deleted items’’ for up to 30 days of deleted items. Moreover, backup tapes for the system should be placed in a 30 day rotation, then erased or destroyed. There should be no tapes that contain data over 30 days old. For monitoring, specify any required monitoring or where appropriate the type of monitoring technologies to be used. Staffing Certification and experience levels of supporting staff. Exclusive/nonexclusive use of resources. Equipment Brand/vendor of equipment to be used. Any additional equipment for testing or recovery.

Comfort Level The final decision will be up to the enterprise’s management, but your recommendation on this point will carry considerable weight. Before recommending outsourcing to a particular vendor, you should be comfortable with your answers to the following points: ◆ Is the organization comfortable with someone else handing their data? If you’re the CIA, you may not want to have others in possession of your email. ◆ Do you feel secure that your outsourcing solution will be there for you when you need them for a restore or just general support? You should always check the track record and reliability rating of any vendor.

SUMMARY

◆ Do they have the technical expertise to do everything you need? ◆ What is the plan in the event their hardware fails? ◆ If the vendor turns out to be a mistake or incapable of meeting your needs, what is your backout strategy? Can you migrate to your own server, or another third-party’s servers, if you need to reverse your outsourcing decision?

Summary As you have seen, Exchange Server 2007 offers a broad range of functionality to messaging that you need to assess so that you can properly plan for it. With proper thought and attention to the major design topics, you can put a robust and reliable Exchange email solution into place that will perfectly complement the needs of any organization. The following are some of the best practices and key points you will want to keep in mind while planning for Exchange Server 2007: ◆ Use site consolidation strategies to reduce the number of Exchange servers to deploy. ◆ Install Exchange Server 2007 on Windows Server 2003 R2 Edition when possible. ◆ Select the appropriate license, version, and edition based not only on the current environment but also on what is anticipated for the next 3 to 5 years. ◆ Select the processor and memory based not only on the current environment but also on what is anticipated for the next 3 to 5 years. ◆ Keep the AD design simple, with a single forest and single domain, unless a specific need exists to create more complexity. ◆ Implement DNS in the environment on the AD domain controllers. ◆ Keep a local copy of the global catalog close to any Exchange servers. ◆ Identify the client access methods that will be supported, and match them with the appropriate Exchange Server 2007 technology. ◆ Make sure that you understand and plan for the correct number and type of server roles. ◆ Determine in advance who will set transport rules, journaling, and disclaimer policies. ◆ Establish sufficient flexibility in compliance policies to meet inevitable new demands and changes. ◆ Use disclaimer and other technologies proactively, not just in a ‘‘hunker-down’’ protective position.

119

Chapter 5

Planning Server Roles ‘‘A good plan today is better than a perfect plan tomorrow.’’ — General George S. Patton ‘‘Good fortune is what happens when opportunity meets with planning.’’ — Thomas A. Edison In the previous chapter, we reviewed some general planning considerations that apply to Exchange Server 2007. In this chapter, we’ll be discussing in some detail a new wrinkle in Exchange Server 2007 — server roles, and how to plan for them. Exchange Server was originally planned, and still functions, as a complete messaging system that can run on a single server, with all Exchange services residing on that single server. With the passage of time and the growing complexity of messaging systems and Exchange, Microsoft realized that there were significant benefits to deployment, management, and security with a flexible modular system that could be installed across more than one machine. This concept was first introduced in Exchange 2000 Server, where a front-end server could be configured to proxy inbound Internet client protocols to the appropriate mailbox server. Front-end servers are optional and can reduce the load on mailbox servers and simplify Microsoft Office Outlook Web Access (OWA) and Exchange ActiveSync (EAS) user access. Having front-end servers in medium-sized and large organizations made Exchange more scalable by concentrating particular tasks on a limited number of servers. In reality, this server functionality was loosely termed and not always clearly defined, nor was there a set terminology that was used for Exchange server roles. Exchange Server 2007 introduces distinctly defined and specific roles that a server can hold. You decide what server roles will be placed on a system during the setup process, as shown in Figure 5.1. Multiple roles can reside on a single server, or multiple servers can have the same role. The standardization of these roles makes planning much easier, and you can use this to designate specific roles for servers in specific locations. These roles allow organizations to control mail flow, increase security, and distribute services. Most of these roles can be installed on a single server or on multiple servers. For smaller organizations, a single server holding the three basic Exchange roles may be sufficient. For larger organizations, a more complex configuration might be required. In your planning documents you will not need to discuss possible considerations for assessing the Client Access server, Edge Transport server, Hub Transport server and Mailbox server. You simply need them, and it’s not necessary to make a business case for having them. You will, of course, have to examine the justification (if any) for Unified Messaging server and determine the role of the Edge Transport versus third-party solutions.

122

CHAPTER 5 PLANNING SERVER ROLES

Figure 5.1 You select the Server role during Exchange Server 2007 setup

You should, of course, be familiar with the function of each server role. As part of your plan and statement of work, you will need to assess what server roles are required, how many are needed, and where they should be located. I’m going to spend a lot of time looking at two of the more advanced server roles, Edge Transport and Unified Messaging, as they are both very complex and can have a serious impact on your planning and design. The Edge Transport server is intended to be the guardian and sentinel on the borders of the Exchange environment; it’s a crucial bit of planning and thinking. This server can, when properly configured and supported, be your greatest ally. On the contrary, an improperly planned and deployed Edge Transport server has all the value of a Confederate dollar. The Unified Messaging (UM) server role is perhaps one of the most complex to configure and implement, yet ironically it may be one of the simplest to plan. Basically planning simply consists of deciding what features and support you need. Sounds simple right? It is, and it isn’t. Planning a Unified Messaging deployment may seem cut and dried, but the devil is in the details. Understanding them, and how they interact, is also critical. Let’s look at some of your planning and design considerations for each server role in Exchange Server 2007.

Client Access Server (CAS) Role The Client Access server role performs the functions that used to be provided by a front-end server and can be load balanced for redundancy purposes. These include mailbox access to clients accessing Exchange using Outlook Web Access (OWA), Exchange ActiveSync, Post Office Protocol 3 (POP3), and Internet Message Access Protocol (IMAP), all of which require CAS to be present.

CLIENT ACCESS SERVER (CAS) ROLE

In addition to providing a connection point for client applications, the Client Access server role provides support for the following: ◆ Autodiscover service ◆ Exchange Web Services You must have the Client Access server role installed in every Active Directory site within your organization that contains an Exchange 2007 Mailbox server. If your organization has only one Active Directory site, the Client Access server role must be installed on at least one computer within your Exchange organization. You can install the Client Access server role on an Exchange 2007 computer that is running any other server roles except for the Edge Transport server role. You cannot install the Client Access server role on a computer that is installed in a cluster. Installation of a Client Access server in a perimeter network is not supported. Figure 5.2 shows how the Client Access server role interacts with the Exchange Server environment.

Figure 5.2

Forest

How the Client Access server role interacts with the Exchange Server environment

Site A

Active Directory

SMTP

ActiveSync

Internet CAS

Outlook Web Access

HTS

Outlook

MBS

SMTP

Outlook

RPC/HITTPS LDAP MAPI/RPC encrypted

Exchange ActiveSync Considerations Exchange ActiveSync is based on HTTP and XML that enables mobile device users to access their email, calendar, contacts, and tasks, and to continue to be able to access this information while they are working offline. When you’re planning for whether to include Exchange ActiveSync, consider the following issues: ◆ Will the organization be utilizing Exchange ActiveSync devices such as Windows Mobile powered devices? ◆ Can the organization support Direct Push? Direct Push keeps messaging data synchronized with mobile devices over cellular connections. If your users’ data plans charge by

123

124

CHAPTER 5 PLANNING SERVER ROLES

the minute or the megabyte, the monthly cost can quickly escalate. For Direct Push with Exchange ActiveSync to be optimally used end users should have an unlimited data plan with their cellular carrier. ◆ What will be the Exchange ActiveSync security plan (including mailbox policies)?

Outlook Web Access Considerations Outlook Web Access uses an Internet browser to provide access to Exchange information. Outlook Web Access has a powerful, intuitive interface that resembles Outlook 2007 without the need to install Outlook 2007 on the computer. By default, when you install the Client Access server role on an Exchange 2007 server, four Outlook Web Access virtual directories are created in the default Internet Information Services (IIS) website on the Exchange server. You may want to limit the features that are available to users through Outlook Web Access, depending on your organization’s security and information management needs. Outlook Web Access for Exchange 2007 offers several enhancements in security. You can configure SSL on the Outlook Web Access virtual directory in addition to standard and forms-based authentication. You can configure the following authentication methods for Outlook Web Access by using the Exchange Management Console or the Exchange Management Shell: ◆ Standard authentication methods ◆ Forms-based authentication Note that while the original four default directories have SSL enabled by default, if you want to use SSL to help secure additional Outlook Web Access virtual directories or websites, you must set this up manually. To configure a site to use SSL, you must obtain a certificate and configure the website or virtual directory to require SSL by using that certificate.

Outlook Anywhere Considerations Outlook Anywhere enables users who are running Outlook 2007 or Outlook 2003 to connect to your Microsoft Exchange messaging infrastructure from the Internet by using the Outlook Anywhere networking technology. Microsoft recommends enabling at least one Client Access server for Outlook Anywhere access in each site that you manage.

POP3 and IMAP4 Considerations Exchange 2007 provides support for clients that use the POP3 and IMAP4 protocols. However, by default, the POP3 and IMAP4 services are not started in Exchange 2007. To use these protocols, you must first start the POP3 and IMAP4 services on the Client Access server. When you deploy Client Access servers to support POP3 and IMAP4 clients, there are physical limitations and security limitations if you use earlier versions of Microsoft Exchange, such as Exchange Server 2003. The main physical limitation in deploying POP3 and IMAP4 is that cross-site communication between Client Access servers and Mailbox servers in separate Active Directory sites is not supported. You must make sure that clients can connect to the Client Access server that is located in the same site as the Mailbox server that contains their mailbox.

Exchange 2007 Web Services Considerations As mentioned earlier, a CAS supports two Web services: Exchange Web Services and the Autodiscover service.

EDGE TRANSPORT SERVER ROLE

Exchange Web Services provides access to the following: ◆ Free/busy information, meeting suggestions, and Out of Office functionality ◆ Calendar, email, contacts, folders, and task items in a user’s mailbox ◆ Notifications about events that occur in a user’s mailbox ◆ Synchronization features to synchronize clients with the associated mailbox ◆ Ambiguous name resolution ◆ Distribution list expansion The Autodiscover service enables clients such as Outlook, custom applications, and some mobile devices to obtain settings for a variety of services such as the Availability service, Unified Messaging, and the offline address book (OAB).

CAS Security Planning As you would expect, there are many factors to consider when you plan a secure messaging environment. Microsoft recommends, and the plan should call for, SSL encryption for all Client Access features, including Outlook Web Access and Outlook Anywhere. You should not use Basic authentication since it transmits user names and passwords in clear text. Your planning can be more flexible since you can also customize each Client Access feature to use different security mechanisms. Another method to enhance messaging environment security is to deploy an advanced firewall server solution such as Microsoft Internet Security and Acceleration (ISA) Server 2006.

Edge Transport Server Role Placing a typical Exchange 2000/2003 server, or any other domain member server, in your perimeter network (demilitarized zone, or DMZ) has not been recommended because of the communication necessary with production network resources such as DNS and Active Directory. At the same time, the perimeter network is the ideal place to analyze incoming messages and filter out unwanted or virus-infected email. To reconcile this dilemma, Exchange Server 2007 introduces the Edge Transport role, an Exchange server that is not a traditional member of the Active Directory or the Exchange organization, as you can see in Figure 5.3. The Edge Transport server role consists of a standalone server that typically resides in the DMZ of a firewall. It provides SMTP message transport between the Exchange organization and the Internet, and provides antispam and antivirus processing using transport agents, then forwards it to internal Hub Transport servers. Edge Transport servers keep a local AD Application Mode (ADAM) instance that is synchronized with the internal AD structure via a mechanism called EdgeSync. This helps to reduce the surface attack area of Exchange. Information sent from the Hub Transport server to the Edge Transport server includes recipient lists used to verify that recipients exist before passing the inbound message along. Other information pushed out to the Edge Transport server includes user safe sender lists. A Microsoft Office Outlook or OWA user can add SMTP addresses to a safe sender list. This list makes its way from the Hub Transport server to the Edge Transport server so that messages to that Outlook user from users on the safe sender list are not blocked by Exchange antispam components.

125

126

CHAPTER 5 PLANNING SERVER ROLES

Figure 5.3 Edge Transport server role

Forest Site A UMS

AD

HTS

Site B

AD

HTS

SMTP

ActiveSync

Outlook Web Access Outlook

Internet

ETS

CAS

MBS

CAS

MBS

Outlook

A key advantage is that you can standardize a single technology for both your organizational and perimeter network servers. The result is easier and simplified administration and easy integration of perimeter servers. Keep in mind that while you can combine other roles on a single system, the ET role must reside alone. Considerations in designing and planning the Edge Transport role will be discussed more fully in Chapter 5. As mentioned in the previous chapter, the Edge Transport Server Role is new to Microsoft Exchange Server 2007. In the past, placing an Exchange 2000/2003 server, or any other domain member server, in your perimeter network (DMZ) was not recommended because the communication necessary with production network resources such as DNS and Active Directory, placed the network at risk in the event of a penetration. On the other hand, the perimeter network is also the ideal place to analyze incoming messages and filter out unwanted or virus-infected email. To reconcile this dilemma, Exchange Server 2007 introduced the Edge Transport server role. The Edge Transport server role is installed on the edge of the network on a standalone server that is not a member of the Active Directory domain. Because the server is not a member of the Active Directory domain, ADAM is used to sync AD with the Edge Transport server. ADAM and a component called EdgeSync are used to perform scheduled one-way synchronization of the configuration and recipient information from Active Directory. Exchange 2007 Service Pack 1 (SP1) is required if you want to deploy server roles on a Windows Server 2008 computer. If the Edge Transport server is installed on Windows Server 2008, ADAM is replaced by Active Directory Lightweight Directory Services (AD LDS). Windows Server 2008 includes several features that have been enhanced or renamed. For information about the feature changes between Windows Server 2003 and Windows Server 2008, vist the Microsoft website at http://www.microsoft.com/windowsserver2008/evaluation/overview.mspx The Edge Transport role performs a number of functions, including antispam and antivirus (AV) protection. The Edge Transport uses connection filtering, content filtering, recipient filtering, SenderID, sender, and IP reputation to reduce the amount of spam delivered to the end users’ inboxes. Mail tagged as spam will sit in a spam quarantine from which administrators can delete or allow messages tagged as spam either manually or through an a previously configured adminstrator defined action. One of the top features is the ability for Outlook 2003 and 2007 clients to merge their spam settings (like white and black lists) to the Edge Transport server to increase the efficiency and accuracy of the filters. The built-in Virus Scanning Application Program Interface

EDGE TRANSPORT SERVER ROLE

VSAPI has been improved and the introduction of transport agents will allow third-party AV applications to provide stronger AV filtering. Edge Transport Rules are used to protect the Exchange organization by applying rules, and based on whether the message passes or fails, appropriate action is taken. Unlike the antivirus and antispam processing, Edge Transport rules are based on SMTP and MIME addresses, words in the subject or message body, and SCL rating. The Edge Transport role also handles address rewriting; in Exchange 2007, an administrator can modify the SMTP address on in or outbound mail. The Edge Transport server is also responsible for all mail entering or leaving the Exchange organization. Mail travels inbound through the Edge Transport and once the Edge Transport Rules have been applied the message is passed on to the Hub Transport server. Because the Edge Transport is responsible for all inbound and outbound mail, you can plan for multiple Edge Transport servers for redundancy and load balancing. Information sent from the Hub Transport server to the Edge Transport server includes recipient lists used to verify that recipients exist before passing the inbound message along. Other information pushed out to the Edge Transport server includes user safe sender lists. A Microsoft Office Outlook or OWA user can add SMTP addresses to a safe sender list. This list makes its way from the Hub Transport server to the Edge Transport server so that messages to that Outlook user from users on the safe sender list are not blocked by Exchange antispam components. A key advantage is that you can standardize on a single technology for both your organizational and perimeter network servers. The result is easier and simplified administration and easy integration of perimeter servers. The Edge Transport Server role also permits: ◆ Configuration of which Internet SMTP domains email will be accepted from ◆ Sender ID checking ◆ Which internal or external domains are supported for SMTP relay ◆ Whether SMTP addresses are to be rewritten on inbound and outbound messages You can configure the Edge Transport Server role to either use DNS to lookup external SMTP domains, or to forward them all on to a smart host. Finally, the Edge Server role includes the Edge Rules Agent, which helps manage antivirus issues. You can also add the Edge Transport Server role to an existing Exchange Server 2003 network, and we discuss this later in this section. As should be obvious, establishing the correct use of the Edge Transport Server role thus requires considerable planning and assessment of a variety of considerations. What should you consider when you plan your deployment? As you’ve seen, the Edge Transport server does not have access to Active Directory for storage of configuration and recipient information as do the other Exchange 2007 server roles. Instead, it uses the Active Directory Application Mode (ADAM) directory service to store configuration and recipient information. This is a special case you need to take into account. When you plan to deploy the Edge Transport server role, you should consider all the following topics.

Topology Considerations Begin by planning where you will put your Edge Transport server in the Exchange physical topology. Install the Edge Transport server on a computer that is in your organization’s DMZ. Don’t put it completely outside the firewall, and don’t place it on the inside of the network.

127

128

CHAPTER 5 PLANNING SERVER ROLES

You should not install the Edge Transport server on a computer that is a member of your Active Directory organization. In this way, the Edge Transport server can be considered expendable when it comes to the possibility of facing an attack from the outside. When you have determined where the Edge Transport server will be located in the network relative to your other Exchange servers, you can plan for the connectors that you will require and for how they should be configured.

Server Capacity Considerations Planning for server capacity includes planning to conduct performance monitoring of the Edge Transport server. Performance monitoring will help you understand how hard the server is working, and also help you determine the capacity of your current hardware configuration. In large organizations, redundancy can be built into Edge Transport services through simple round-robin DNS or with the use of a third-party load-balancing service between requests sent to the servers.

Transport Features When you plan for the deployment and configuration of transport features, you must clearly identify the organization’s business needs and the message-processing practices that best fulfill those needs. To make sure that you have all the information and resources that are required to correctly deploy and configure these features, you should have answers to the following questions: ◆ Are there corporate or regulatory rules that your organization has to comply with? ◆ Do any messages have to be identified for long-term document retention? Which ones? ◆ Are you implementing an in-house antispam solution? ◆ Are you implementing in-house antivirus protection? ◆ Is journaling of communications between individuals and groups required? ◆ Do certain types of messages have to be scheduled or prioritized? ◆ Do you have to add disclaimers to the body of particular messages? ◆ Do you have to restrict messages based on attachment size or type? ◆ Should certain connections be rejected based on content or attachment name? ◆ Do you have to rewrite internal Simple Mail Transfer Protocol (SMTP) addresses in order to masquerade internal subdomains? ◆ Does your organization transmit confidential messages? When you determine the business needs of your organization, you can determine the transport features that should be deployed. After you have made these decisions, you will know which features to configure, which agents to enable, and which storage and security resources to make available.

Edge Subscription Considerations You use an Edge Subscription to subscribe the Edge Transport server to the Exchange organization. When you create an Edge Subscription, recipient and configuration data is replicated from Active Directory to ADAM. You subscribe an Edge Transport server to an Active Directory site. The Exchange EdgeSync service running on the Hub Transport servers in that site synchronize

EDGE TRANSPORT SERVER ROLE

ADAM with data from Active Directory. The Edge Subscription process automatically provisions the Send connectors that are required to enable mail flow from the Exchange organization to the Internet through an Edge Transport server. You should consider the following information when determining whether or not and how to use Edge Subscriptions: ◆ You must create an Edge Subscription if you plan to use the antispam features, recipient lookup or safelist aggregation, or the Domain Security feature on the Edge Transport server. ◆ Each Edge Transport server requires an individual Edge Subscription. The credentials that are written to the Edge Subscription file are specific to the server from which the file is exported. ◆ An Edge Transport server can only be subscribed to a single Active Directory site. If you want to change the site association for a subscribed Edge Transport server, you must remove the Edge Subscription from the Hub Transport server and then create a new Edge Subscription. ◆ When an Edge Transport server is subscribed to an Active Directory site, all the Hub Transport servers that are installed in that Active Directory site at that time can participate in the EdgeSync process. If new Hub Transport servers are installed in the Active Directory site, they will not participate in the EdgeSync process. To enable those Hub Transport servers to participate in the EdgeSync process, you must resubscribe the Edge Transport server.

Security The Edge Transport server role is designed to have a minimal attack surface. Therefore, it important to correctly secure and manage both the physical access and network access to the server. Planning for security will help you make sure that IP connections are only enabled from authorized servers and from authorized users. Since the Edge Transport server resides on the perimeter network, you still need to make some adjustments so that the server can send and receive email and receive recipient and configuration data updates from the Exchange EdgeSync service. Hence you must allow communication through the ports that are listed in Table 5.1.

Address Rewriting Address rewriting enables you to modify the addresses of senders and recipients on messages that enter and leave your Exchange Server 2007–based messaging system. Address rewriting is a useful tool if it is important that your organization present a consistent appearance to external recipients of messages from your messaging system. It is also helpful for organizations that use third-party vendors to provide email support and services, since customers, clients and other recipients expect email messages to come from the organization, not a third party. Another instance is after a merger or acquisition, In those cases, the organization will usually want all email messages to appear to come from the single new organization. The address rewriting feature frees organizations to structure their businesses by business requirements instead of by technical requirements or limitations. You can also use address rewriting to enable appropriate routing of inbound messages from outside your Exchange 2007 organization to internal recipients. Address rewriting enables replies to messages that were rewritten to be correctly routed to the original sender of the rewritten message.

129

130

CHAPTER 5 PLANNING SERVER ROLES

Table 5.1:

Communication Port Settings for Edge Transport Servers*

Network interface

Open port Protocol

Note

Inbound from and outbound to the Internet

25/TCP

SMTP

This port must be open for mail flow to and from the Internet.

Inbound from and outbound to the internal network

25/TCP

SMTP

This port must be open for mail flow to and from the Exchange organization.

Local only

50389/TCP

LDAP

This port is used to make a local connection to ADAM.

Inbound from the internal network

50636/TCP

Secure LDAP This port must be open for EdgeSync synchronization.

Inbound from the internal network

3389/TCP

RDP

Opening this port is optional. It provides more flexibility in managing the Edge Transport servers from inside the internal network by letting you use a remote desktop connection to manage the Edge Transport server.

*The Edge Transport server role uses nonstandard LDAP ports. The ports that are specified in this topic are the LDAP communication ports that are configured when the Edge Transport server role is installed.

You configure Address Rewriting agents on the Receive connector and Send connector on a computer that has the Edge Transport server role installed. One important caveat is that for inbound email to be appropriately mapped and routed, you must make sure that the user name part of the address is unique across all email organizations that may be affected by address rewriting. This may necessitate plans for how to convert existing email addresses that might overlap. For example, if you have [email protected] and [email protected], and Wiley buys Sybex, and the address is rewritten, all of the former [email protected]’s emails will be sent to [email protected]. It may be necessary, in your planning, to redesign the way that mail is currently addressed for the organization to allow for future changes. Hence when implementing your new Exchange Server 2007–based messaged system, this might be an opportunity to move from the older, albeit friendlier [email protected] to the longer, but less likely to be duplicated in the same organization [email protected].

Address Rewriting Scenarios The following scenarios are examples of how address rewriting can benefit organizations:

Group Consolidation Some organizations segment their internal businesses into separate domains that are based on business or technical requirements. However, this configuration can cause email messages to appear as if

EDGE TRANSPORT SERVER ROLE

they come from separate groups or even separate organizations. This appearance might not be desirable to the organization. The following example shows how an organization, Maeder Enterprises, could hide its subdomains: Outbound messages from the sales.maeder.com, customerservice.maeder.com, and marketing .maeder.com domains are rewritten to appear as if they all originate from a single maeder.com domain. All messages are rewritten as they pass through Edge Transport servers that provide SMTP connectivity between the whole organization and the Internet. Inbound messages to the maeder.com domain are passed from the Edge Transport server to the Hub Transport server role, which then determines the correct recipient. For example, messages to [email protected] are sent to an internal Hub Transport server, which then determines the correct mailbox to send the message to by using the proxy address that is configured on the recipient’s email account.

Mergers and Acquisitions When organizations merge or are acquired, their technology infrastructure must be modified to match new business and technical requirements. An acquired company may continue to run as a separate business unit, but the email administrator can use address rewriting to make the two organizations appear as if they are one integrated organization. The following example shows how Maeder Enterprises could hide the email domain of the newly acquired company, Auggie CatFood: Maeder Enterprises wants all outbound messages from Auggie Catfood’s Exchange organization to appear as if they originate from maeder.com. All messages from both organizations are sent through the Edge Transport servers at Maeder Enterprises, where email messages are rewritten from [email protected] to [email protected]. Inbound messages to [email protected] are rewritten and routed to her linda@auggiecatfood .com email account. Incoming messages that use her old [email protected] domain are also accepted, because the domain still exists. Inbound replies to email messages that were rewritten are handled by the Edge Transport servers at Maeder Enterprises, where the Address Rewriting agent rewrites the recipient address so that replies are correctly routed to the appropriate auggiecatfood.com email address. Replies to email messages that were sent before the merger to auggiecatfood.com email addresses are routed directly to Auggie Cat Food’s email servers.

Partners Many organizations use external partners to provide services for their customers, other partners, or the organization itself. To avoid confusion, the organization might replace the email domain of the partner organization with its own email domain. For example, this is how Mullen Technologies Enterprises could hide a partner’s email domain: Mullen Technologies provides support for the larger ANHA organization. ANHA wants a unified experience for its customers and requires all messages that originate from support personnel at Mullen Technologies to appear as if they were sent from ANHA. All outbound messages that relate to ANHA

131

132

CHAPTER 5 PLANNING SERVER ROLES

are sent through their Edge Transport servers, and all mullen.com addresses are rewritten to appear as anha.com addresses. Inbound messages for [email protected] are accepted by ANHA’s Edge Transport servers, are rewritten, and then are routed to the [email protected] email address. There are two ways you can use address rewriting. The first is to rewrite outwardbound addresses, and the second is bidirectional address rewriting.

Outbound-Only Address Rewriting Outbound-only address rewriting involves modification of the sender SMTP address. The Address Rewriting agent is configured only on the Send connector on the Edge Transport server. The following list shows the conditions that are required to configure an outbound-only Address Rewriting agent: ◆ The resulting addresses must be unique across the organization. ◆ A proxy address must be configured on each mailbox that matches the rewritten email address. ◆ When you use wildcard characters, there must be a period between the wildcard character and the domain name. ◆ You can use wildcard characters only in the internal domain. ◆ No characters can be in front of the wildcard character. ◆ Outbound-only address rewriting cannot affect the user name or display name part of the address. ◆ Only literal strings are supported.

Considerations for Bidirectional Address Rewriting Bidirectional address rewriting modifies the sender SMTP address on email messages that are leaving the Exchange organization and the recipient SMTP address on email messages that are entering the Exchange organization. To do this, you configure the Address Rewriting agent on both the Send connector and Receive connector on the Edge Transport server. The following conditions are required to create a bidirectional Address Rewriting agent: ◆ No wildcard characters are allowed. ◆ Full SMTP addresses must be used to configure a bidirectional address rewriting rule. For example, the internal address is [email protected], and the external address is [email protected]. ◆ Only literal strings are supported. ◆ The address must be unique across the organization.

Planning for Antispam and Antivirus Features Exchange 2007 includes a variety of antispam and antivirus features that are designed to work cumulatively to reduce the spam that enters your organization. Exchange 2007 also includes improved infrastructure for antivirus applications. The following sections provide brief descriptions of each default antispam and antivirus feature.

EDGE TRANSPORT SERVER ROLE

Antispam and Antivirus Filters The antispam and antivirus filters are applied in the following order. ◆ Connection filtering ◆ Sender filtering ◆ Recipient filtering ◆ Sender ID ◆ Content filtering ◆ Spam quarantine ◆ Sender reputation ◆ Attachment filtering ◆ Microsoft Forefront Security for Exchange Server (add-on) ◆ Outlook Junk Email filtering

Note Forefront Security for Exchange Server is an antivirus software package that is tightly integrated with Exchange 2007 and offers antivirus protection for the Exchange environment. The antivirus protection that is provided by Forefront Security for Exchange Server is language independent. However, the setup, administration of the product, and end-user notifications are available in 11 server languages.

Antispam Stamps Antispam stamps help you diagnose spam-related problems by applying diagnostic metadata, or ‘‘stamps,’’ such as sender-specific information, puzzle validation results, and content-filtering results, to messages as they pass through the antispam features that filter inbound messages from the Internet. These stamps are visible to the end-user mail client and encode sender-specific information, the version of the spam filter definition file, Outlook puzzle validation results, and content-filtering results.

Using IPv6 Receive Connectors If Exchange Server 2007 Service Pack 1 (SP1) is deployed on a computer running Windows Server 2008, you can enter IP addresses and IP address ranges in the Internet Protocol Version 4 (IPv4) format, Internet Protocol Version 6 (IPv6) format, or both formats. A default installation of Windows Server 2008 enables support for IPv4 and IPv6. You should not configure Receive connectors to accept anonymous connections from unknown IPv6 addresses. Doing that will probably increase the amount of spam that enters your organization. The matter is more complex because there is as yet no broadly accepted industry standard protocol for looking up IPv6 addresses. Furthermore, most IP Block List providers do not support IPv6 addresses.

Spam Quarantine Spam quarantine is a feature of the Content Filter agent that reduces the risk of losing legitimate messages by providing a temporary storage location for messages that are identified as spam and that should not be delivered to a user mailbox inside the organization.

133

134

CHAPTER 5 PLANNING SERVER ROLES

Messages delivered to the spam quarantine mailbox can be reviewed and appropriate actions taken. They can be deleted or identified as false positives in antispam filtering and be routed to their intended recipients. The spam quarantine mailbox can be set to automatically delete messages after a designated time period. Planning for your deployment and implementation must include an assessment of how you will set the Spam Confidence Level (SCL) and how it will apply to incoming messages. If the SCL rating is greater than or equal to the SCL quarantine threshold but less than either the SCL delete threshold or SCL reject threshold, the message goes to the spam quarantine mailbox. If the SCL rating is lower than the spam quarantine threshold, it is delivered to the recipient’s Inbox. You should include planning for review of the antispam stamps, and adjustments to the SCL settings if: ◆ Too many false positives are filtered into the spam quarantine mailbox. ◆ Not enough spam is being rejected or deleted.

Safelist Aggregation Safelist aggregation refers to a set of antispam functionality that is shared by Outlook and Exchange. Basically what safelist aggregation does is collect data from the antispam safe recipients lists or safe senders lists and contact data that Outlook users configure. It then makes this data available to the antispam agents on the computer that has the Edge Transport server role installed. Safelist aggregation is likely the most effective way to reduce false positives. Outlook 2003 and Outlook 2007 let users create safe senders lists, which specify a list of domain names and email addresses from which the Outlook user wants to receive messages. By default, email addresses in Outlook Contacts and in the Exchange Server global address list are included in this list. Outlook also adds all external contacts to which the user sends mail to the safe senders list.

Deployment Requirements Edge transport servers are standalone, workgroup members that are meant to reside in the DMZ of a firewall. They do not normally require access to any internal resources except to the Hub servers via port 25, and they must be able to resolve the names via DNS or a host file, and perform a one-way synchronization of specific configuration information from Active Directory via a process called EdgeSync.

Note When performing EdgeSync two additional ports, 50389 and 50636, are used. Port 50636 is used for synchronization, while 50389 is the port that the Edge Transport Server uses to talk to itself for ADAM services. If you do not use EdgeSync, you will only need port 25.

The Edge Transport server has some unique requirements and recommendations. ◆ The Edge Transport server role can’t coexist with any other Exchange 2007 server roles. It must be installed on its own hardware.

EDGE TRANSPORT SERVER ROLE

◆ The Edge Transport server must have a primary DNS suffix before the role can be installed. This isn’t an issue for machines that are members of your domain, but on standalone machines, it is a step that is sometimes forgotten. ◆ You must install Active Directory Application Mode (ADAM) on the Edge Transport server before you install the new role. During the ADAM installation, accept all of the defaults. The Edge Transport server installation process will handle the ADAM configuration. ◆ The computer on which you install the Edge Transport server role has the same software requirements as a normal Exchange 2007 server. Make sure that the .NET Framework 2.0, the Microsoft Management Console 3.0, and PowerShell 1.0 are installed before you proceed. ◆ You must change your external DNS MX record to point to the Edge Transport server. ◆ The IP address for the Edge Transport server must be in your DNS and accessible by the Hub Transport server. ◆ Once you complete the installation of the Edge Transport server, you must either manually create SMTP Send and Receive connectors between the Edge Transport and Hub Transport servers or subscribe the Edge Transport server to the Exchange organization.

Securing Exchange 2007 Edge Transport Servers The Edge Transport Server is the most vulnerable of all server roles due to its location on the edge of the network. This means that you are required to do a little more work to secure the server itself. The Security Configuration Wizard in Windows Server 2003 SP1 is an ideal tool to use to reduce the attack surface of your Edge Transport server(s). The Security Configuration Wizard (SCW) is a new feature in Windows Server 2003 that is part of Service Pack 1. It is easy to use and allows you to quickly create security templates and apply them to servers.

135

136

CHAPTER 5 PLANNING SERVER ROLES

Adding an Edge Transport Server to an Existing Exchange 2003 Organization You can add an Edge Transport server to an existing Exchange 2003 organization without upgrading the internal Exchange servers. You don’t have to perform any Active Directory preparation steps when you install the Edge Transport server since it doesn’t have access to Active Directory for storage of configuration information. As you saw earlier, the Edge Transport server uses the ADAM directory service for storage of configuration information. The ADAM schema contains all the object classes and attributes that are required to perform configuration of the Edge Transport server. The antispam features, recipient lookup and safelist aggregation, and the Domain Security feature require that the Edge Transport server be subscribed to the Exchange organization by using the Edge Subscription process and EdgeSync synchronization. If you don’t create an Edge Subscription, you can’t use those features. To create an Edge Subscription, you must deploy at least one computer that is running an Exchange 2007 Hub Transport server in the Exchange organization, and you must configure Exchange server coexistence.

Edge Transport Server Messaging Services The Edge Transport server can provide the following messaging services to the Exchange 2000/2003 organization: ◆ Smart host server for the organization ◆ SMTP relay server for the organization ◆ Antispam and antivirus tasks prior to sending mail to the internal Exchange servers ◆ Address rewriting ◆ Apply transport rules

Planning to Deploy the Edge Transport Server Before you deploy the Edge Transport server, you must answer the following planning questions: ◆ How will you position the Edge Transport server within the perimeter network? ◆ How will you administer the Edge Transport server? ◆ How will you configure mail flow? ◆ How will you configure the transport agent settings? When you add the Edge Transport server to the perimeter network, you must consider how the Edge Transport server will interact with other servers in the perimeter network. The following are some topology considerations: ◆ Have you deployed Microsoft Internet Acceleration and Security (IAS) Server 2006 in the perimeter network to handle Internet network traffic? In this scenario, ISA doesn’t proxy or modify the SMTP protocol. ISA can be configured to redirect, or tunnel, the SMTP protocol to the Edge Transport server. ◆ Do you have an existing smart host or SMTP relay in the perimeter network? After the Edge Transport server is deployed, you can load balance traffic between the Edge transport

MAILBOX SERVER ROLE

server and the existing server during a test period. Or you can just decommission the existing smart host or SMTP relay. ◆ Do you have an existing antispam gateway product deployed in the perimeter network? After the Edge Transport server is deployed, you can decommission the existing gateway product. If you want to maintain both systems for a while, you can configure a Send connector on the Edge Transport server so that it will relay email to the existing system before the email is delivered to the Exchange organization. To provide smart host and SMTP relay services, you must allow for access through TCP port 25 on both the internal and external firewalls, to and from the Edge Transport server.

Hub Transport Server Role This role provides SMTP and MAPI message transport services for the Exchange organization. Every message that is sent or received by the users in your organization is processed by a Hub Transport server, which acts as a mail bridgehead for mail sent between servers in one AD site and mail sent to other AD sites. There always needs to be at least one Hub Transport server within an AD that contains a Mailbox server. Multiple Hub Transport servers can be used for load balancing and redundancy.

Note The load balancing and redundancy feature will be lost if you install a Hub Server on a Mailbox server since the Mailbox server will always use the local Hub server.

One key advantage for your planning is that the mandatory passthrough of the Hub Transport server assures that no message can bypass the server-based rules or journaling policies in the transport pipeline. When installed in an environment with an Edge Transport server, the Hub Transport server will work with it hand in hand. Messages coming in through the Edge Transport server will be passed to the Hub Transport and vice versa. You can configure the Hub Transport role to perform most of the same features as the ET server. If you don’t need the added protection of an Edge Transport server, install the Hub Transport on a member server connected to your domain, so it doesn’t require ADAM and can still send/receive mail from the Internet. Part of your planning should include deciding whether or not you want an Edge Transport server and how you’ll configure your Hub Transport server.

Mailbox Server Role The Mailbox Server role serves as the storehouse for mail data in users’ mailboxes and down-level public folders if required, as you can see in Figure 5.4. Exchange Server 2007 can support up to 50 stores per server. These stores can be deployed as 50 individual storage groups, or you can create up to 50 stores in a single storage group. Note that the Mailbox server role is the only one that can be deployed as a cluster, so if you will be using clustering, you will need to install the Mailbox server on dedicated hardware. The Mailbox Server role directly interacts only with Outlook MAPI traffic. All other access methods are proxied through the CAS servers.

137

138

CHAPTER 5 PLANNING SERVER ROLES

Figure 5.4

Forest

Mailbox server role

Site A

Active Directory

SMTP RTS

ActiveSync

Internet

Outlook Web Access

CAS

MBS

Outlook SMTP RPC/HITTPS

Outlook

LDAP MAPI/RPC encrypted

Public Folders Exchange Server 2007 public folders, which are deployed as part of the Mailbox Server role, are intended to serve as a repository for information that is shared among many users. You should use public folders when your business requires data replication to multiple servers. Access to public folders is integrated with regular mailbox access through the MAPI protocol. You must use public folders if your Exchange Server 2007 organization meets the following criteria: ◆ You have Outlook 2003 clients in your organization. ◆ Your Exchange server will interoperate with Lotus Notes. In addition to evaluating the features and functionality of Exchange public folders, you should evaluate the features and functionality that are provided by Microsoft Windows SharePoint products and technologies for data repositories and collaboration tools.

Standby Continuous Replication Standby continuous replication (SCR) is a new feature being introduced in Service Pack 1 for Microsoft Exchange Server 2007. As its name implies, SCR is designed for scenarios that use standby recovery servers. SCR extends the existing continuous replication features and enables new data availability scenarios for Mailbox servers. SCR uses the same log shipping and replay technology as local continuous replication (LCR) and cluster continuous replication (CCR) to provide added deployment options and configurations. SCR is very similar to LCR and CCR but has unique characteristics: ◆ SCR supports multiple targets per storage group. LCR and CCR support only one replication target per storage group (the passive copy). ◆ SCR includes a built-in delay for replay activity, and allows an administrator to specify an additional delay.

MAILBOX SERVER ROLE

◆ In Exchange Server 2007 before Service Pack 1, rules are enforced so that in a continuous replication environment a log file is not deleted unless and until it has been backed up and replayed into the copy of the database. SCR (which introduces the concept of multiple database copies) allows log files to be truncated at the SCR source as soon as they are inspected by all SCR target machines. Log truncation at the SCR source server does not wait til all logs have been replayed into all SCR targets because SCR target copies can be configured with large log replay lag times. ◆ Unlike CCR and LCR, you cannot back up an SCR copy. When using SCR, the database headers for SCR copies are updated, and the log files are truncated, when supported backups are made against the source storage group (or, in the case of LCR and CCR, when backups are made against either the active or passive copies of the source storage group). As with LCR and CCR, SCR uses the concept of active and passive copies of a storage group, and like CCR, SCR requires that the database and log files paths be the same on the source and the target. Because SCR extends the scenarios supported by LCR and CCR, SCR also introduces the concepts of sources and targets. The starting point for SCR is called the source, which is any storage group, except a recovery storage group, on any of the following: ◆ A standalone mailbox server (with or without LCR enabled) ◆ A clustered mailbox server in a single copy cluster ◆ A clustered mailbox server in a CCR environment As with LCR and CCR, SCR-enabled storage groups cannot contain more than one database; you cannot enable SCR for a storage group that contains more than one database, and you cannot add a second or subsequent database to an SCR-enabled storage group. The endpoint for SCR is called the target, and the target can be either: ◆ A standalone mailbox server (without LCR enabled for any storage groups) ◆ A node in a failover cluster where the Mailbox role is installed but no clustered mailbox server has been configured in the cluster A source can have multiple targets. There is no limit to the number of targets you can have for each source; however, Microsoft recommends using no more than four targets per source. Other limitations for targets include: ◆ Target machines must be in the same Active Directory domain. ◆ Each target can have multiple source servers. Both the source and the target system must be running Service Pack 1 for Exchange 2007. ◆ The operating system can be any operating system supported by Service Pack 1 for Exchange 2007. ◆ The database and log file paths on the source and all of its targets must match for each storage group being replicated with SCR. If both paths, including drive letter(s), do not match, you will not be able to enable SCR. When a node or a server is configured as an SCR target these capabilities are blocked: ◆ If you’re using a standalone Mailbox server, LCR cannot be enabled for any storage groups. ◆ If the target is a passive node, it must be a member of a cluster that does not have any clustered Mailbox servers.

139

140

CHAPTER 5 PLANNING SERVER ROLES

Unified Messaging Server Role The Unified Messaging server role is new in Exchange 2007 and allows a user’s Inbox to be used for voice messaging and fax capabilities. This enables users to access their voice mail, fax, and email from one location, using multiple access interfaces (phone, email, or web browser). It integrates with your IP/VoIP gateway or IP-PBX to provide telephone access to messages and calendar items, and it lets you transcribe a reply as well as perform other tasks, as shown in Figure 5.5. This role is not able to interoperate with any previous versions of Exchange.

Figure 5.5

Forest

Unified Messaging server role

Site A

Active Directory

UMS

SMTP

HTS

ActiveSync

Internet

Outlook Web Access

CAS

MBS

Outlook SMTP RPC/HITTPS

Outlook

LDAP MAPI/RPC encrypted VoIP

The Unified Messaging server role enables Unified Messaging for an Exchange 2007 organization. Unified Messaging lets users access their Exchange 2007 mailbox over any telephone for email, voice mail, fax messages, and calendaring and contact information. Microsoft Exchange Server 2007 Unified Messaging (UM) combines voice messaging, fax, and email messaging into a single messaging infrastructure. Unified Messaging puts all email, voice, and fax messages into one Exchange 2007 mailbox that can be accessed from a variety of devices. After Unified Messaging servers have been deployed on the network, users can access their messages by using Outlook Voice Access, from any telephone, from a mobile device, or from the computer of a user who is running Microsoft Windows XP or Vista Migrating to Exchange 2007 Unified Messaging from your current voice mail solution or implementing a new voice mail system by using Exchange 2007 Unified Messaging can be a complex process. Planning and deployment requires the coordination of telephony, IT, and Exchange administrators. Microsoft strongly recommends that customers who planning to deploy Unified Messaging obtain the help of a Unified Messaging specialist. This will help ensure a smooth transition from a legacy voice mail system. Rolling out a new UM deployment or performing an upgrade of an existing legacy voice mail system requires significant knowledge of PBXs and Exchange 2007 Unified Messaging. You can obtain information about who to contact by visiting http://go.microsoft .com/fwlink/?LinkID=72005.

UNIFIED MESSAGING SERVER ROLE

Assessing the Benefits of Unified Messaging Unified Messaging is an extremely complex topic, and in planning for it you may find yourself limited to a simple item heading ‘‘bring in UM expert,’’ as Microsoft suggests. Whether you intend to introduce the UM Server role using local personnel and resources or to bring in an outside expert is, of course, a local and purely situational decision. Given the ultimate cost, you should assess the UM implementation against the hoped-for benefits.

Benefits to the Organization Microsoft and other industry professionals cite the following as potential corporate benefits to an enterprise that implements and Exchange Server 2007–based messaging system with UM deployed. You should determine if these benefits warrant the implementation of the UM server role and if they actually apply to your organization. Reduced costs Exchange Server 2007 UM eliminates the need for expensive voice cards, or expensive traditional voice mail system upgrades. It allows you to deploy gateways at regional sites as needed and limits the need for dispersed UM servers. Site and server consolidation The Exchange Server 2007 UM role relies on VoIP gateways or direct Session Initiation Protocol (SIP) interoperability with IP PBX systems to receive information from the PBX. This capability also allows users to expand services easily to new sites by deploying VoIP gateways at local sites and configuring shared UM servers in major data centers. User self-service By combining self-service features such as personal identification number (PIN) reset with a single mailbox for multiple message types, Exchange UM puts users in control, reducing helpdesk calls and support costs. Additionally, users can access email and voice mail through a variety of methods, including the full Office Outlook client, Microsoft Office Outlook Web Access, a mobile device, or a standard telephone. Active Directory integration Whereas the third-party UM systems use a separate user database, Exchange Server 2007 UM natively integrates with Active Directory. UM objects, such as dial plans, VoIP gateways, and hunt groups, have a logical representation as Active Directory objects for easier administration because all the data is stored in Active Directory. Additionally, Exchange Server 2007 UM uses the Active Directory user database for a single repository of user data. Next generation networking (NGN) Unified messaging and VoIP represent a general trend toward convergence of messaging systems into a single network type: the packet-switched IP network. This network transports services and data for voice, data, video, and other media by encapsulating the streams into data packets. NGN requires essential building blocks, such as an IP network, site connectivity, and existing routing topologies for the various traffic types. Administration, operation, and training With one user database (Active Directory), one message store (Exchange Server), and one messaging infrastructure to maintain for additions, moves, changes, and backups, organizations should be able to realize savings in administering and maintaining the voice mail, fax, and email messaging systems. Using one system consistently across the enterprise network also reduces the time spent training users and administrators. Employee productivity The features that Exchange UM provides to access voice mail, fax, and email messages from one mailbox, coupled with the ability to access the mailbox by phone, mobile device, or computer, creates great flexibility for employees. Outlook Voice Access

141

142

CHAPTER 5 PLANNING SERVER ROLES

makes it possible to adjust calendar items, check and write messages, and retrieve directory information while away from the office.

User Benefits When you deploy Exchange 2007 Unified Messaging, your users will have access to their email, voice mail, and fax messages from either Microsoft Office Outlook 2007 or the version of Outlook Web Access that is included with Exchange 2007. Additionally, users will be able to use the following features: ◆ Access to Exchange information. UM-enabled users can access a full set of voice mail features from Windows Mobile powered devices, Outlook 2007, and Outlook Web Access. ◆ Play on Phone. The Play on Phone feature lets UM-enabled users play voice messages over a telephone, which allows increased privacy of messages. ◆ Voice mail form. The Outlook 2007 voice mail form gives users an interface for performing actions such as playing, stopping, or pausing voice messages, playing voice messages on a telephone, and adding and editing notes. ◆ Fax receiving ◆ Call answering ◆ Outlook Voice Access ◆ Subscriber access. The subscriber access feature enables dial-in access for the organization’s users. By using a telephone, a subscriber or user can: ◆

Access voice mail

◆

Listen, forward, or reply to email messages

◆

Listen to calendar information

◆

Access or dial contacts who are stored in the global address list or a personal contact list

◆

Accept or cancel meeting requests

◆

Set a voice mail Out-of-Office message

◆

Set user security preferences and personal options

◆ Auto attendant gives the administrator the ability to: ◆

Create a customized menu for external users.

◆

Define informational greetings, business hours greetings, and non-business-hours greetings

◆

Define holiday schedules

◆

Describe how to search the organization’s directory

◆

Describe how to connect to a user’s extension so external callers can call a user by specifying their extension

UNIFIED MESSAGING SERVER ROLE

◆

Describe how to search the organization’s directory so external callers can search the organization’s directory and call a specific user

◆

Enable external users to call the operator

Planning Unified Messaging When you plan your Exchange 2007 Unified Messaging deployment, you must consider design and other issues that may affect your ability to reach your organizational goals when you deploy Exchange 2007 Unified Messaging. This means of course that you fully understand user and business requirements. Keeping needs in mind is key for a successful UM design and deployment. As explained in Chapter 2, your analysis should have identified what UM features are critical. This allows you to choose proper hardware to support projected use. It is also important that you have considered and analyzed the risks, dependencies, technical requirements, and trends for proper provisioning, hardware sizing, and workflow for UM in your organization. Generally, the simpler the Unified Messaging topology, the easier Unified Messaging is to deploy and maintain. Install as few Unified Messaging servers and create as few Unified Messaging objects in the Active Directory service as you need to support your business and organizational goals. Large enterprises with complex network and telephony environments, multiple business units, or other complexities will require more planning than smaller organizations with relatively straightforward Unified Messaging needs. There are many areas that you must consider or evaluate to be able to successfully deploy Unified Messaging. You must understand the different aspects of Exchange 2007 Unified Messaging and each component and feature so that you can plan your Unified Messaging infrastructure and deployment appropriately. Allocating time to plan and work through these issues will help prevent problems when you deploy Unified Messaging in your organization. The following are some of the areas that you should consider and evaluate when planning for Exchange 2007 in your organization: ◆ Your business needs for Unified Messaging ◆ Your telephony network and your current voice mail system ◆ Your current data network design ◆ Your current Active Directory environment ◆ The number of users that you will have to support ◆ The number of Unified Messaging servers you will need ◆ The storage requirements for users ◆ The placement of IP/VoIP gateways, telephony equipment, and Unified Messaging servers In addition to the above you should be sure to create and maintain documentation for configuration settings, design considerations, technical notes, and similar details. A good technique is to prepare and maintain a master reference document that includes all server, gateway, dial plan, port, and access number information for each site. The reference document should include support contact information for relevant people at each site.

143

144

CHAPTER 5 PLANNING SERVER ROLES

Another valuable inclusion in your plan is the provision for the creation of custom help. This may include communications for users that include links to intranet help sites with reference material, feature how-tos, setup instructions, and configuration instructions. You might want to plan customized email messages that UM servers send when a user is enabled for UM services or for PIN reset requests, with intranet site links for more help.

Availability and Scalability To provide a highly scalable and available solution in Exchange 2007 Unified Messaging, you must understand how the Unified Messaging components can be scaled to support your users. You must also understand how to implement a solution that will make your Unified Messaging servers highly available. Scalability is defined as the capability to increase resources to increase the capacity of a given service. There are two types of scalability that can be used to increase the capacity of Unified Messaging servers in your organization: horizontal and vertical. In Exchange 2007 Unified Messaging, when you scale vertically, you add hardware resources to a single Unified Messaging server or multiple Unified Messaging servers, such as the following: ◆ Adding more hard disk space for message storage ◆ Increasing the speed or number of processors ◆ Increasing the amount or speed of RAM ◆ Increasing the number of network adapters or increasing the number of local area network (LAN) ports in a single network adapter In Unified Messaging, when you scale horizontally, you install the Unified Messaging server role on new Unified Messaging servers and add more Unified Messaging servers to a dial plan to increase the number of incoming concurrent calls that the system can accept. To scale your Unified Messaging environment horizontally, you can also increase the number of IP gateways. This increases the number of ports that are available to be used for incoming calls.

Integrating Unified Messaging and Office Communications 2007 Server Exchange Server 2007 Service Pack 1 allows Unified Messaging servers to use the Microsoft Office Communications Server 2007 platform to combine voice messaging, instant messaging (IM), enhanced presence, audio-video conferencing, and email. Advantages of the integration include: ◆ Enhanced presence notifications across a variety of applications that keep users informed of the availability of contacts. ◆ Integration of IM, voice messaging, conferencing, email, and other communication modes that enable users to select the mode that is most appropriate for the task. Users can also switch from one mode to another as needed. ◆ Availability of communications alternatives from any location where an Internet connection is available. ◆ A smart client (Microsoft Office Communicator 2007) for telephony, IM, and conferencing. ◆ Continuity of user experience across multiple devices.

UNIFIED MESSAGING SERVER ROLE .

Warning Microsoft Exchange Server 2007 Service Pack 1 (SP1) must be installed on the computers that have the Unified Messaging server role installed to allow for the integration discussed here.

Enterprise Voice All Office Communications Server 2007 topologies support Enterprise Voice. Enterprise Voice is an implementation of IP telephony that uses Session Initiation Protocol (SIP) for signaling and Realtime Transport Protocol (RTP) for voice messaging. SIP is an industry standard, application layer signaling protocol for starting, controlling, and ending communication sessions in an IP-based network. In Office Communications Server 2007, SIP is used for IM, conferencing, presence subscriptions, video, and voice messaging. SIP enables Enterprise Voice clients to provide a common user experience across all these communication modes. Enterprise Voice uses RTP for media. For Enterprise Voice users, Unified Messaging (UM) combines voice messages and email messages into a single store that can be accessed from a telephone or a computer. Unified Messaging and Office Communications Server 2007 work together to provide voice mail, subscriber access, and auto-attendant services to Enterprise Voice deployments, including the following: ◆ Voice mail ◆ Subscriber access, which enables Enterprise Voice users to access voice mail, calendar, and contacts from a telephony interface. A subscriber access number is configured by the Exchange 2007 administrator on a Unified Messaging dial plan. ◆ Auto attendant. This transfers callers to the extension of a user or department without the intervention of a receptionist or an operator. In many auto-attendant systems, a receptionist or operator can be reached by pressing or saying zero. The automated attendant is a feature in most modern PBXs and Unified Messaging solutions.

Integration Scenarios There are four user scenarios in which Office Communications Server 2007 and Exchange 2007 Unified Messaging can be used together. These are: Providing call notification Tom calls Harry. Harry does not answer the call. Tom hangs up. Harry receives an email message in his Exchange 2007 mailbox that Tom called. Call notifications are also sent when an inbound call is forwarded. Harry sets call forwarding to Karl. Tom calls Harry. The call is forwarded to Karl, and Harry receives a call notification that the call was forwarded. Leaving a voice mail message Kim calls Dave. Dave does not answer the call. Because Dave has not configured call forwarding to another telephone number, the call from Kim is diverted to the voice mail for Dave. Kim is invited to leave a voice message for Dave. The voice mail greeting that was previously recorded by Dave is played, inviting Kim to leave a voice message for Dave. Dave receives a voice mail message recorded by Kim. Providing subscriber access Denise dials in to a subscriber access number and accesses the Exchange 2007 mailbox to check for voice messages. Denise can listen to the email or voice mail

145

146

CHAPTER 5 PLANNING SERVER ROLES

messages or access the calendar. After listening to the voice message from Chatwin, Denise decides to return the call from Chatwin. Denise accesses the options menu and uses the callback option to place a call to Chatwin. Auto-attendant Linda does not know the extension number for Sarah. Linda dials in to a telephone number that is configured on a UM auto-attendant. The welcome greeting and prompts that are configured on the auto-attendant are played to Linda. Linda uses the directory search feature to locate Sarah in the directory and places a call to the extension number for Sarah.

Note Both subscriber access and those auto-attendant services offered by Exchange 2007 Unified Messaging require users to dial specific telephone numbers. These numbers must be routable by Enterprise Voice. This means that each number must be mapped to a SIP address. Office Communications Server 2007 can route the SIP address to an address that is configured on the server that has the Exchange 2007 Unified Messaging server role installed.

Unified Messaging Active Directory Objects Exchange Unified Messaging Active Directory objects enable Exchange 2007 Unified Messaging to be integrated with the Office Communications Server 2007 Enterprise Voice infrastructure. To successfully deploy Exchange 2007 Unified Messaging in your organization, you must fully understand the relationship between each of following UM Active Directory objects and their counterparts in Enterprise Voice: Unified Messaging Dial Plan object A UM Dial Plan object is the basic unit of configuration in Exchange Unified Messaging. A UM dial plan can be of the following types: Telephone Extension, SIP URI, or E.164. When Exchange Unified Messaging is deployed with Office Communications Server 2007, the dial plan type is always SIP URI. Users in a UM dial plan reach all other users in the plan by using SIP URIs or SIP addresses. Each SIP address must be unique within a given SIP URI dial plan. Each dial plan must correspond to an Enterprise Voice location profile. The name of each location profile must match the forest fully qualified domain name (FQDN) of the SIP URI dial plan. Unified Messaging IP Gateway object A Unified Messaging IP Gateway object is a logical representation of a physical IP gateway or SIP-enabled IP PBX. The UM IP gateway object logically represents each Office Communications Server 2007 pool and front-end server as if it were a physical IP gateway. Each UM IP Gateway object encapsulates configuration elements that are related to the corresponding pool or server. After a UM IP Gateway object is created, it is associated with one or more UM hunt groups. Unified Messaging Hunt Group object The UM Hunt Group object associates a UM IP gateway with a UM dial plan. By creating multiple UM Hunt Group objects, you can associate a single UM IP gateway with multiple UM dial plans and, therefore, with multiple Enterprise Voice location profiles.

Deployment Exchange 2007 Unified Messaging provides an efficient and simple deployment model that is highly scalable without increasing the complexity of the deployment. There are many deployment

SELECTING THE APPROPRIATE PROCESSOR

models for Unified Messaging in your organization. But the recommended deployment model for Unified Messaging is to centralize your Unified Messaging servers. All the available deployment options for Unified Messaging have several steps in common that are required to create a scalable system to support large numbers of Unified Messaging users. These steps are:

1. Provision PBX lines: The first step in building a highly scalable UM solution is to provision PBX lines.

2. Organize channels: After you have provisioned PBX-based voice channels, you can organize the channels as hunt groups.

3. Deploy IP gateways: After you have organized your voice channels as hunt groups, you end these channels at IP gateways. IP gateways are used with a legacy PBX to convert the circuit-switched protocols found on a telephony network to IP-based packet-switched protocols.

4. Add more Unified Messaging servers to a dial plan: If you have to increase the number of calls that can be handled by Unified Messaging, you can install and configure additional Unified Messaging servers and add them to a dial plan. In most cases, IP gateways will use DNS to perform load balancing between the existing Unified Messaging servers and the additional Unified Messaging servers that have been installed.

Network Traffic Before you deploy Unified Messaging, you should perform an analysis of the network traffic to determine current usage patterns and identify any potential issues. On most networks, bandwidth demand is not evenly distributed throughout business hours. Because all the IP-based calls are routed directly to your Unified Messaging servers from the IP gateways on your network and this IP-based network traffic consumes some available bandwidth, you should follow these recommendations and guidelines: ◆ Place your PBXs physically close to your IP gateways. ◆ Place your IP gateways and your Unified Messaging servers on the same well-connected network or within the same physical site. ◆ Place your Unified Messaging servers on the same well-connected network or within the same physical site as other computers that have Exchange 2007 server roles installed, including Mailbox, Hub Transport, and Client Access servers. ◆ Terminate your wide area network (WAN) connections close to where your telephony equipment is located. ◆ In branch office scenarios or over WAN connections, use the G.723.1 codec instead of the G.711u or G.711A codec to minimize the network traffic that is passed between your IP gateways and your Unified Messaging servers.

Selecting the Appropriate Processor To use Exchange Server 2007 in a production environment, you must choose a processor that will work with the x64-based version of Windows Server 2003. These include Intel processors that support Intel Extended Memory 64 Technology or AMD processors that support AMD64. Exchange Server 2007 will not run on Itanium-based systems.

147

148

CHAPTER 5 PLANNING SERVER ROLES

Multicore processors are an attractive option for Exchange 2007 based on price and performance. Exchange Server 2007 benefits significantly when using multicore processor technology, with the derived benefit dependent on the specific processor used. The type of processor to use (as well as specific memory configurations) is dependent on the various roles that an Exchange Server 2007 machine is expected to play.

Recommended Processor Configurations Table 5.2 can be used for a quick-and-dirty assessment of what processor hardware you will need to purchase to supplement existing hardware inventories for your Exchange Server 2007 plan. This table provides minimum requirements, recommended requirements, and recommended maximum configurations. Note that this table assumes an average concurrency profile. Concurrency is defined as the percentage of the total number of users on a server that are connected and using the server at a specific peak period of time. For a fully utilized server, concurrency is generally in the 75 to 80 percent range.

Table 5.2:

Processor Configurations for Exchange 2007 Server Roles

Exchange 2007 server role

Minimum∗

Recommended∗∗

Maximum∗∗∗

Client Access

1 x processor core

4 x processor cores

4 x processor cores

Edge Transport

1 x processor core

2 x processor cores

4 x processor cores

Hub Transport

1 x processor core

4 x processor cores

8 x processor cores

Mailbox

1 x processor core

4 x processor cores

8 x processor cores

Unified Messaging

1 x processor core

4 x processor cores

4 x processor cores

Multiple server roles (combinations of Hub Transport, Client Access, Unified Messaging, and Mailbox server roles)

1 x processor core

4 x processor cores

4 x processor cores

*Minimum is the minimum processor and memory configuration suitable for specific server roles. The minimum hardware requirements must be met to receive support from Microsoft Support Services. **Recommended is defined as the best configuration based on price and performance. The recommended configuration also provides a balance between processor and memory capacity. ***Maximum is defined as ‘‘the upper bound of viable processor and memory configurations based on price and performance.’’ The recommended maximum configuration is a guideline; it is not a support criterion, and it does not take into account the resource requirements of third-party applications that might access or be installed on the server.

Client Access Server Sizing In each Active Directory service site in which you deploy Mailbox servers, you deploy at least one Client Access server processor core for every four Mailbox server processor cores that you deploy. For example, if you deploy eight Mailbox servers in an Active Directory site, and each Mailbox server contains four processor cores (for a total of 32 Mailbox server processor cores), you should deploy at least eight Client Access server processor cores, which could be deployed as two Client Access servers with four processor cores each, or four Client Access servers, with two processor cores each.

SELECTING THE APPROPRIATE MEMORY CONFIGURATION

Mailbox Server Sizing While there are multiple considerations to take into account that will change this ‘‘rule of thumb’’ a good starting calculation is to assume 1 processor core per each Mailbox server for every 1,000 mailboxes. You will, of course, need to adjust this part of the plan if there is a specific unusual value in the number of messages, size of messages or mailbox size.

Processor Recommendations for LCR In a local continuous replication (LCR) environment, both the active copy and passive copy of LCR-enabled storage group are on the same server. In this environment, there is additional processing overhead generated from the Replication service copying and replaying in logs to the passive copy of the database. This additional processing overhead is approximately 20 percent and should be factored in when sizing Mailbox servers that have one or more storage groups enabled for LCR.

Multiple Server Roles Planning for multiple server roles on a single machine is similar to the Mailbox server role. To accommodate the Client Access and Hub Transport server roles on the same server as the Mailbox server role, you should reduce the 1,000 mailboxes per core calculation based on the average client profile by 20 percent (800 mailboxes per core) when performing sizing. Neither cluster continuous replication (CCR) nor single copy clusters (SCC) support hosting the Hub Transport or Client Access server roles in a failover cluster, so the multiple-role server is nonclustered. It is a good idea to cluster Mailbox servers that host thousands of mailboxes to make sure that server maintenance or failures do not have a significant impact on uptime or availability. For this reason, the recommended maximum processor core configuration for the multiple-role server is listed at four. Although this configuration can use up to eight processor cores, Microsoft does not recommend this configuration based on availability concerns.

Selecting the Appropriate Memory Configuration As a result of moving to a 64 bit architecture, Exchange 2007 enables much better memory utilization than previous versions of Exchange Server. For example, because of the virtual address space limitations of a 32 bit platform, Exchange Server 2003 is limited to using 4 gigabytes (GB) or less of physical memory. In contrast, Exchange 2007 can use 32 GB of memory and beyond. When selecting hardware for Exchange Server 2007, you should consider the server maximum memory configuration. Different server architectures have different memory limits, hence you should check the following technical specifications of the server to determine the most cost-efficient maximum memory configuration for your servers: Memory speed Some server architectures require slower memory to scale the memory to dozens of gigabytes in a specific server. (For example, maximum server memory is limited to 16 GB with PC3200 or 32 GB using PC2700.) You should check with the manufacturer to ensure that the memory configuration target for Exchange Server 2007 is compatible in terms of speed. Memory module size Consider the largest memory module size that the server will support. Generally, the larger the memory module, the more expensive. For example, two 1 GB DDR SDRAM memory modules generally cost much less than one 2 GB DDR SDRAM memory module. Make sure that the maximum memory module size allows you to meet your target memory requirements for Exchange Server 2007. It may make sense to spend more money and purchase denser memory modules.

149

150

CHAPTER 5 PLANNING SERVER ROLES

Total number of memory slots Consider how many memory modules that a specific server will support. The total number of slots multiplied by the maximum memory module size provides the maximum memory configuration for the server. Keep in mind that memory modules must sometimes be installed in pairs. One caveat with this planning method is that some servers experience a performance improvement when more memory slots are filled, while others experience a reduction in performance. Check with your hardware vendor to understand this effect for your server architecture.

Recommended Memory Configurations Table 5.3 can be used for a quick-and-dirty assessment of what memory requirements you will need to have in your existing hardware inventories, or to purchase, for your Exchange Server 2007 plan.

Table 5.3:

Memory Configurations for Exchange Server 2007 Roles

Exchange 2007 Server Role

Minimum per Server

Client Access

2 GB

1 GB per core (2 GB minimum)

8 GB

Edge Transport

2 GB

1 GB per core (2 GB minimum)

16 GB

Hub Transport

2 GB

1 GB per core (2 GB minimum)

16 GB

Mailbox

2 GB; also depends on number of storage groups

2 GB plus from 2 MB through 5 MB per mailbox. This is variable based on user profile.

32 GB

Unified Messaging

2 GB

1 GB per core (2 GB minimum)

4 GB

Multiple roles (combinations of Hub Transport, Client Access, Unified Messaging, and Mailbox server roles)

2 GB; also depends on number of storage groups

4 GB plus from 2 MB through 5 MB per mailbox. This is variable based on user profile.

8 GB

Recommended

Maximum per Server

Mailbox Server Role Memory Considerations The memory configuration process for the Mailbox server role is more complex than the other roles because the optimal memory configuration depends upon the mailbox count and the client profile. Memory sizing for the Mailbox server role is critical to reducing disk I/O on the server. The more memory you add to the Mailbox server, the less disk I/O that will be generated by Exchange. There is, however, a point of diminishing return at which adding memory to the server may not be justifiable based on price and performance. In general, anything beyond 32GB RAM for

SERVER ROLE RATIOS

a Mailbox server is not recommended by Microsoft because cost, the impact of nontransactional disk I/O, and cold state operations produce a point of diminishing returns.

Memory Recommendations for Local Continuous Replication In a local continuous replication (LCR) environment, both the active copy and passive copy of LCR-enabled storage group are on the same server. To ensure that the ESE database cache maintains optimal efficiency in an LCR environment, Microsoft recommends that you install an additional 1 GB of RAM on Mailbox and multiple-role servers above and beyond the suggested memory listed above.

Memory Recommendations for Multiple Server Roles Multiple server role configurations should accommodate the needs of the Client Access and Hub Transport server roles on the same server as the Mailbox server role, hence the recommended base memory configuration is 4 GB (2 GB + 1 GB + 1 GB). The recommended maximum amount of memory is 8 GB. Neither CCR nor SCC supports hosting the Hub Transport or Client Access server roles in a failover cluster; thus, a multiple-role server is nonclustered by definition. It is a good idea to cluster Mailbox servers that host thousands of mailboxes to ensure that server maintenance or failures do not have a significant impact on uptime or availability.

Server Role Ratios After you have determined your optimal processor and memory configurations, you should determine how many server roles of each type are required for your planned deployment. Every environment is different, so consider these recommendations as starting points that can be tailored to your environment.

CAS, Mailbox and Hub Transport Count Table 5.4 shows recommended server role ratios that are based on the processor core recommendations since it is common for roles to have vastly different processor core counts. Also, the Mailbox server role is the basis for the processor core ratios. Hub Transport and Client Access roles relate to the Mailbox role with regard to the recommendation.

Table 5.4:

Recommended Server Role Ratios Based on Processor Core

Role ratio Mailbox:Hub

Recommended processor core ratio 7:1 (no antivirus scanning on Hub) 5:1 (with antivirus scanning on Hub)

Mailbox:Client Access

4:1

When considering these recommendations, be aware of the following: ◆ The ratios listed in Table 5.4 are ‘‘rule of thumb,’’ and they may not be valid for every topology.

151

152

CHAPTER 5 PLANNING SERVER ROLES

◆ Ratios can change dramatically based on user profiles. A user that creates a larger than expected load against the Mailbox role than the Hub role will increase the Mailbox:Hub ratio, and vice versa. ◆ For these recommendations, the processors used on Mailbox, Hub Transport, and Client Access roles were the same type and speed. ◆ A minimum of two Hub Transport and two Client Access servers should be deployed for redundancy and to ensure uninterrupted service in case of planned or unplanned server downtime.

Unified Messaging Server Count It is not possible to provide a ratio for the Unified Messaging server role because its utilization is not directly tied to the Mailbox server role.

Edge Server Count To determine how many Edge Transport servers are required, you must measure or estimate the following metrics during peak periods: ◆ Connections/sec ◆ Messages/sec ◆ Avg. Message Size Sizing is based on the number of connections and messages processed, with average message size being a secondary factor. Because every SMTP connection does not translate into an SMTP message, and because every accepted message will not survive antivirus and antispam scanning, it is very difficult to provide a simple sizing methodology based on message rate. Edge Transport server utilization depends on several factors that are unique to each organization. Complicating matters further, a significant percentage of the server processing can be associated with the overhead of analyzing connections and scanning accepted messages. Consequently, no one has been able to devise a sizing metric based solely on the number of messages sent and received per second because antivirus and antispam are significant processor utilization functions of the Edge Transport server role. Hence your best approach is to design by best guess and allow sufficient flexibility in your planning to adapt to changing circumstances.

Tools You Can Use You can use the Exchange 2007 Management Pack for Microsoft Operations Manager 2005 SP1 and the Performance Troubleshooter in the Toolbox node of the Exchange Management Console to determine if and when a given deployment requires additional server roles based on performance. These tools can also be used to fine-tune server role ratios for a specific deployment. These tools, and how to use them, will be discussed in further detail in Chapter 11.

Summary In this chapter, we’ve examined a few of the factors you will need to take into consideration when choosing server roles and what you will need to keep in mind to configure them. We established that three of the roles, Hub, Mailbox, and Client Access, are mandatory in all circumstances. In 99 percent of most installations, you will also need the Edge Transport server role. The Unified

SUMMARY

Messaging server role is optional, but rest assured with the changes in technology and pricing that have been seen over the past year, it is likely to become an extremely important factor in future deployments. You’ve seen how to use your proposed configuration to determine detailed aspects of hardware requirements such as CPU, memory, and disk space required. You’ve learned about critical aspects of the Edge Transport server role. Its unique position as the sentinel of the messaging system means that its configuration and the planning required to deploy it properly will be a major challenge and opportunity for you. With the material we have covered so far, you should have a reasonably accurate statement of work that follows through on the scope statement and requirements discussed earlier. This statement of work fleshes out the skeletal framework of the earlier document and starts you on the process of asking hard questions and analyzing tradeoffs. Some of the items in the statement of work, such as 64 bit servers and obtaining licenses for Exchange Server 2007 are simply not optional. In others, you may be able to see where the choices you make have a long-term effect and reduce (or expand) the costs and the schedule. Your statement of work, of course, is an excellent document. I am sure that you remember the lessons from earlier in the book, and as you have developed it, you have been in regular communication with the executive sponsor and the rest of the key stakeholders. Their informal and formal input has helped guide the statement of work and helped you over any rough spots. They’ve also helped you puzzle through the various tradeoffs that you may have already detected and helped you in reaching decisions. Despite this you can’t simply take the statement of work and immediately start developing an implementation plan. The plan still needs to be approved and its implementation be authorized and funded. Don’t think that approval and funding is automatic, no matter how optimistic everyone, including the executive sponsor, is. A wise project manager at a company I once worked for once said, ‘‘Many good ideas have shriveled in the harsh light of the senior vice presidents’ committee and their review.’’ In the next chapter, you’ll learn how to make a business case, and escape the harsh light with nothing more than an approved statement of work — and perhaps a golden tan.

153

Chapter 6

Building the Business Case ‘‘Let the facts be submitted to a candid world’’ — Declaration of Independence (before listing the reasons for declaring American independence) For the past four chapters, we’ve been going through the long but necessary process of developing and creating a plan for your organization to use in implementing an Exchange Server 2007–based messaging system. All of this has been leading up to the preparation of documents to present to the decision makers in order to move your plan from the theoretical to the actual. In order to do that, you need to have your plan approved and funded. This means that you need to build the business case. I heard some of you shudder and a number of you groan. I suspect some of you may have closed this book. It’s not really surprising: there are a number of IT managers who, given the choice between preparing the business case for their project or having root canal, would make their way to their local dentist. There is a reason for this. Many IT managers and potential managers don’t like preparing a business case for project approval, because most have never studied basic accounting, so learning to create a solid business case is often a matter of trial and error. Technically trained people often don’t have well-developed sales skills, so they find the entire ‘‘making a case’’ process awkward. There is also a general attitude that users are lacking in intelligence — the vast collections of stories about ‘‘dumb’’ users attest to that leitmotif that permeates some IT cultures. Finally, IT personnel and corporate personnel have a natural communications gulf on subject matter and different levels and types of expertise, and the effort it takes to bridge that gap is sometimes seen as a waste of time and energy. Why bother to convince the other of what seems to be self-evident, they reason. The end result is that for many IT personnel, building a business case is a necessary evil to be shunned as much as possible. Like it or not, though, preparing and presenting business cases is very much a part of any IT manager’s daily life. Regardless of your personal approach or feeling about business cases, it is now more important than ever to have a business case that is carefully planned, written, and presented, especially when you consider that corporate investments are being subjected to increased scrutiny. In the past, IT expenditures were frequently rubber stamped, especially as rapid improvements made hardware and software obsolete almost on an annual basis. I remember having my office computer replaced 4 times in 18 months from a P133 to a P2 400 to a P3 600 to a P3 800. By contrast, it has been 5 years since my P4 2.6 was installed. The same is applied to software. Corporations also noticed that much of the hype from vendors about the various products fell short of promise. The combination of a maturing user base, mature hardware and software, and rising prices has led most companies to regard IT expenditures much more warily than in the past and to subject major changes of software and hardware to the same review process and analysis as other expenditures. IT is definitely in a ‘‘prove the need’’ stage rather than ‘‘tell us what we need’’

156

CHAPTER 6 BUILDING THE BUSINESS CASE

position. Writing a good business case will help you justify resource allocation to key decision makers and secure funding for your project. In this chapter, I will review how to take the information you have been putting together in the past four chapters and use it to write and present a business case to persuade key decision makers in your organization that your proposal is a winning initiative. You should come away from this chapter versed in the principles for preparing an effective business case. The material in this chapter will help guide you through the writing process and explain how to concisely present your business case to connect with your audience and key decision makers.

Overview of the Business Case Concept A business case is the presentation of an argument for a particular course of action to be taken by an enterprise. The sole consideration is how the proposed plan of action, in this case adopting your statement of work for an Exchange Server 2007–based messaging system, will impact the success of the enterprise. In the private sector, this will almost invariably involve ascertaining the implications for costs and/or revenues; in the public sector, it will probably be costs and/or service levels. A business case argument is usually designed to show why a particular course of action is better than the present situation, when considered against the ‘‘do nothing’’ status quo or other alternatives. There may, however, be other impacts that the business case should consider. A well-argued business case can help convince senior management, finance officers, and elected members of the need for change and the consequences of inaction. You’ll present the business case to the decision makers in an organization. For a corporation, this is usually executive management at some level, depending on the organization’s rules and the amount of money involved. In small businesses, the public sector, or other institutions, this may involve a single individual or small group that may in turn make recommendations to a larger body that adopts or rejects the plan formally based on their input. It may be necessary to present the case more than once with slightly different emphasis. For example, publishing this book required review and approval first by an editorial board at John Wiley & Sons that assessed the book’s potential market. A second presentation a week later dealt with the revenue issues involving the book. Both bodies needed to approve the plan for a contract to be issued. There are a few caveats that you should keep foremost in your mind, especially if you’re new to business case development. At the end of the day, regardless of the technical merit, the groundbreaking technology involved, or the ‘‘wow factor’’ of your Exchange Server 2007–based messaging system, the overriding concern to the decision makers is whether this investment will justify the expense in terms of money, manpower, and other resources. If you don’t focus on that point, you will almost surely fail. Building a business case will require supply metrics to support both the business need and the positive impact of your plan. This might necessitate benchmarking, measurement, and justification of resources, in both financial and human capital terms.

How to Make a Business Case Although there is no one way to write and present a business case, there are some general points that you should keep in mind. Later in this chapter, I’ll present a simple procedure for writing a business case that you can use as is or, more likely, modify for your own situation. In some instances, the company or organization you are presenting the business case to may already have an existing template you are required to follow. No matter how you actually prepare the case, it will contain some common elements that all business cases contain.

OVERVIEW OF THE BUSINESS CASE CONCEPT

A business case should always set out the cost of making changes, in this case adopting the proposed Exchange Server 2007–based messaging system, against the cost of doing nothing. The business case development process includes the following: Align the objectives of your proposal with the business objectives and vision. This is an important and a politically sound idea. Management wants to know how this will help the company or organization achieve its stated goals and how the objectives of your proposal will match up with their goals. One example is: if an organizational goal were to increase sales by 20 percent, then you could point to how the implementation of your proposal for the Exchange Server 2007–based messaging system would help improve sales by allowing communication between sales personnel and the main office. It may seem to someone with an exclusively IT background that this alignment is simply window dressing. It is not. Corporate goals and vision statements are typically the result of a long and tortuous development process that seems to increase exponentially with the size of an organization. Management takes these goals and statements very seriously, even if you don’t. Decide what to examine to allow the business case being presented to be more easily understood. Although you want to be complete, you don’t want to bury the decision makers in details that might simply distract them. It’s enough to say ‘‘The plan calls for the purchase of eight 64 bit servers with 8 GB RAM each at $5,000 per server.’’ You don’t need to have it read ‘‘The plan calls for the purchase of eight 64 bit servers in black cases that will be purchased from Caruso Electronics.’’ Decide on scenarios to present. These should include, at least, the recommended change and a ‘‘do nothing’’ scenario. Since this book presupposes that a decision has already been made to use an Exchange Server 2007–based messaging system, your principal concerns in the presentation will be how it is implemented and what is done if it is not. Another thing to keep in mind is that many large companies will frequently require IT managers to frame a project case against all the other IT projects up for consideration by the corporate financiers. Decide what business assumptions to use. You should already have an idea of these. It is always a good idea to make sure that the finance officers of the enterprise approve these assumptions before you use them. If you don’t, or if you use unrealistic assumptions, these same finance officers could become your worst nightmare and derail your entire business case by pointing out that your assumptions about the business are completely out of line with the business’s assumptions about itself. The assumptions will need to be applied consistently across scenarios and over time. Examine how the different scenarios ‘‘play out.’’ This should be done whenever possible. It may not always be feasible, but you could, in this instance, show how a similar implementation has worked in another organization or how a similar plan worked in another department of the same company. Summarize the costs and the benefits. You want to present a clear idea of what this project will cost the company both in present terms and ongoing costs. You also want to present what they get for this expenditure. Typically, unless the company is in dire financial straits, it will readily spend money if it sees a good (and reasonably quick) return on investment or sees that the expenditure will strengthen its business position. The company will almost never spend money if the benefits are spotty or not necessarily desirable. Once again, you should

157

158

CHAPTER 6 BUILDING THE BUSINESS CASE

try to demonstrate how these benefits align with the company’s or organization’s missions and goals. Run a limited number of sensitivity analyses to understand how results change in response to changes in assumptions. For example, your mail archiving and compliance plan is subject to the actions (whimsical or not) of corporate and regulatory agencies. Summarize any risks that are involved. Every change to a corporate infrastructure item, such as a messaging system, has certain risks. You need to clarify what these might be. For example, is there a possible loss of the existing mail database? Prepare contingencies in case things don’t go the way you envision them after the plan is accepted. A very smart person I know, one of the senior vice presidents of a large oil company, said that most decisions are often self-evident. All it takes is a little common sense. The key to success, he said, isn’t always making the right decision; the key is knowing what to do if you make a wrong decision and how to recover from it.

Tips and Hints In presenting business cases, you should try to do the following: Keep it simple. When it comes to preparing a business case for an IT project, the best approach is to present the information that is needed to make a decision and leave out any unnecessary detail. In general, the single most important questions are how does this help the organization and what is the return on the investment? Make sure that your analysis and business case cover the basics of clearly identifying the problem and the solution, costs, returns, benefits, the time frame, and the cost of not doing the project. Tell a story. Telling the story well is very important. A business case answers two fundamental questions: ‘‘Why does the organization need the project?’’ and ‘‘What is the most effective manner in which to accomplish the business goals and objectives?’’ If the need is not funded, what is the consequence? What are the various ways the need can be resolved, and what will happen to the organization in each instance? And based on all of that, what is the conclusion you want the audience to draw and the action you recommend taking? Walk the reader through all these steps by ‘‘telling a story,’’ where each section is part of the overall flow. Writing well and writing in a way that flows evenly and logically will improve the odds of having your proposal accepted. It may seem that this saying nothing more than ‘‘write a well-written cohesive case,’’ but it much more than that. By telling the proposal as part of the overall story of the company, you make it relevant, and it’s much more understandable to the audience. Involve the stakeholders. Consult widely with your stakeholders and sponsors so that you agree on what kind of business case you need to make. If you do not need a full cost-benefit justification, then you can save some resources and focus just on assessing the likely cost of the solution for budget-planning purposes. Nontechnical organizational barriers can easily pose obstacles to a proposal. It’s important to identify what teams and individuals will be affected by the business case, both as workers and as benefactors. In the business case, try to address and identify those individuals and departments within the organization that will be directly and indirectly affected by the solution. Make an effort to identify the appropriate stakeholders, and be prepared to ease their concerns.

OVERVIEW OF THE BUSINESS CASE CONCEPT

Use multiple vendors for costs. Do not go to just one supplier to obtain solution costs. Suppliers tend to underestimate total costs when asked and then will suddenly remember additional costs elements they did not mention before. Ask existing users of these solutions or seek advice from an independent consultant who can confirm or adjust your estimates for you. Be honest. Acknowledge in your project documentation that this is not a final set of figures. Make certain that you acknowledge there are some elements that can be calculated only once a decision has been made or that are subject to market forces beyond your control or that may still be in a state of flux. Add the caveat that at this stage the business case is based on assumptions and informal quotations. The cost part of the case may have to be revisited at the time of procurement when you receive the supplier quotations as part of their tender. Ensure that the benefits are attainable and measurable. Human nature tends toward the optimistic view of possible outcomes. Nowhere is that more clear than in defining the benefits associated with a business case. There is an enormous tendency to take every possible benefit and put it in the business case in order to make it look desirable. Benefits should be included only if they can be measured and if they can be attained. It is almost better to understate the benefits. Benefits that are not realized on one project because of an overinflated business case will be remembered when it comes time for your next business case to be presented. Watch your assumptions. Always define all your assumptions carefully and present the benefits and costs in a spreadsheet so that if certain elements of the costs or benefits need to be changed, this can be easily accomplished and the case recalculated. Make sure that you explain how the assumptions were arrived at, who was consulted, and what has been excluded. For example, your plan may call for 10 servers based on a projected increase in company manpower from the current situation. You need to explain that the projection came from corporate planning and finance. That way, if there is a challenge to the assumption, it will be up to the sources to support or reject it. Know what measurements play a role in the decision-making process. There are a host of measurements, some concrete and some fuzzy, that have been used in one business case or another. For some, it is solely a bottom-line profit-loss statement. In other cultures, it might be the relative impact on market position. For a third group, the key measure might be how long it will take to implement the change. Some are going to make sense to the business case audience, and some are not. Keep in mind that the audience needs to know how cost and benefit values are measured and attainable. Know what the audience is looking for, what criteria are relevant to them, and how they expect them to be presented.

The Case of the Well-Told Story Karyn Chiarello was waiting for approval of an email upgrade project that she had proposed when something fortuitous happened. The system crashed for a day. ‘‘Suddenly everyone could see the immediate value of upgrading,’’ said Chiarello, IT manager at Equinox Enterprise, a commercial real estate company with 50 employees based in the Isle of Man. ‘‘Everyone was saying, ‘Why hasn’t this been replaced?’ ’’

159

160

CHAPTER 6 BUILDING THE BUSINESS CASE

Chiarello had presented her case for upgrading Equinox’s email system to her boss several weeks earlier but hadn’t yet received a green light for the six-figure project. When the system crashed, management could immediately see firsthand the productivity impact of the system crashing and the cost of not doing the upgrade. ‘‘The story this told them was priceless,’’ said Chiarello. The project was approved the next day. Chiarello had done an excellent job writing and presenting her proposal. But she had failed to convey in real, understandable terms the story of why the upgrade was necessary. The crash did the job for her.

Writing the Business Case As I’ve mentioned, there is no single way to write a business case, although all business cases will have similar elements. The following sections are based on the sample template that is outlined in the ‘‘Business Case Template’’ sidebar. This template was adapted from a number of templates used in governmental and corporate organizations and is provided as an example both for its completeness and its ease of use. There is a strong likelihood that the enterprise or organization that you will be preparing your written case for will have an existing template that you will be required to follow. Regardless of which template you use, or what the various headings are called, you will almost certainly find that the content will be the same. A rose by any other name is still a business case proposal.

Tip Appendix B includes a completed sample business case proposal for your reference.

Business Case Template Executive Summary

A. Introduction ◆

A.1. Background

◆

A.2. Assumptions

◆

A.3. Proposed Action

◆

A.4. Business Objectives

◆

A.5. Business Case Purpose

B. Business Case Methods ◆

B.1. Business Case Scope and Boundaries

◆

B.2. Rationale for Benefits

◆

B.3. Success Criteria

◆

B.4. Business Objectives

WRITING THE BUSINESS CASE

C. Cost Projections ◆

C.1. Financial Model

◆

C.2. Cost Analysis

D. Benefits ◆

D.1. Tangible Benefits

◆

D.2 Intangible Benefits

E. E. Cost-Benefit Analysis ◆

E.1. Financial Projections

◆

E.2. Cost-Savings Examples

F. F. Sensitivities, Risks, and Contingencies ◆

F.1. Sensitivity

◆

F.2. Risks

◆

F.3. Contingencies

G. Conclusions and Recommendations ◆

G.1. Conclusions

◆

G.2. Recommendations

Executive Summary An executive summary is a narrative telling the reader what the business case is and what it intends to accomplish. It is a brief summation (no longer than two or three pages) of the issue(s), the limitations, the problems to be solved, and how they will be solved. You should view the executive summary as a proposal, which the rest of the business case then supports, elaborates, or proves. As a result, approach the executive summary with careful preparation and attention to how it is written and presented. If the organization has a template, follow it exactly. It is possible that some of the intended audience will only focus on the executive summary; in fact, they may form their opinion from the executive summary alone. Others may read or misread some or all of the business case and not fully understand it. As a result, you should utilize the executive summary to its fullest extent to ‘‘present a good picture’’ and make the elements precise and clear to the audience. Make sure to remember the Who, What, Where, When, Why, and How.

Tip Even though it appears at the start of the document, the executive summary is almost always the last part written.

161

162

CHAPTER 6 BUILDING THE BUSINESS CASE

A. Introduction The introduction opens the topic of the business case and begins the process of ‘‘making the case’’ for your proposed statement of work and plan for the Exchange Server 2007–based messaging system. It should cover the following: ◆ Background ◆ Assumptions ◆ Proposed action ◆ Objectives ◆ Purpose

A.1. Background The background sets the stage for the business case, giving historical and situational information for the readers about where the organization has been, where it is now, and the problems to be solved. Current market situations and connections to other projects/products or programs can also give relevancy to the business case and place it in context. Hence, this section should include material that accomplishes the following: ◆ Provides a baseline, important historical or situational information, from which you will argue your business case and proposal ◆ Describes current conditions, limitations, and problems to be solved ◆ Includes the market situation and connections to other projects/products or programs In the case of a proposal for an Exchange Server 2007–based messaging system, you might want to describe the current messaging system, its age, and its limitations. You might also mention how changes to the market and regulatory environment make a new system necessary.

A.2. Assumptions Assumptions are events that a business case assumes will happen. For example, a business case might assume approval from a regulatory agency. Critical assumptions must occur for a project to succeed. In this section, you should describe the assumptions of the business case. Business assumptions of any kind, no matter how necessary, obvious, or appropriate they may be, need to be explicitly recorded in the business case. The author cannot take for granted that the evaluation group will make the same assumptions. Make sure to state the business assumptions clearly and precisely, as well as their sources.

A.3. Proposed Action The starting point for identifying the business case subject is usually a proposed or planned action. The proposed action is the subject of the business case, that is, what the business case is about. The subject of the business case should ultimately be defined in terms of objectives. If multiple options are being considered in the business case, remember that each option should be reasonable and a viable alternative. Use the proposed action to state the recommended actions(s) and prioritize them if there are several actions. In this case, your proposed action will be the creation and deployment of an Exchange Server 2007–based messaging system in the manner described in your statement of work.

WRITING THE BUSINESS CASE

A.4. Business Objectives Business objectives answer the question ‘‘What is the case about?’’ and address the needs and/or problems to be solved. Good subject statements are built around objectives — business objectives, financial objectives, functional objectives, or operational objectives. In brief, when a proposed action supports an objective, the appropriate subject for the business case is the full range of resources and actions required to reach the objective. For example, you might explain how the proposed messaging system will support the corporate objective of increasing sales or protecting itself against litigation or ensuring more efficient and timely communication with key officials.

A.5. Business Case Purpose In this section, state specifically what the business case plan will be used for, how it will be used, and who will use it. Business cases can be built for many different purposes. Some are built for decision support purposes; others are built for business-planning purposes. The audience needs to understand clearly the business case’s purpose in order to decide later, when they see the results, whether or not the business case successfully meets the needs of those who must use the results. What will it take for the business case to accomplish its purpose? The reader audience will want to know the answer before reading the full set of financial results. If the business case supports decision making, readers will also want to know early just how these measures will be used.

Nonfinancial Business Case Purposes Here are two examples of nonfinancial business cases: ◆

A charity presents a business case to its funders showing the costs of delivering better services to clients and the benefits in terms of client satisfaction.

◆

A local authority presents a business case to a government department showing the implications of a proposed policy to change the traffic system. The effect is to increase the acceptance by other authorities of the need to undertake other changes in its traffic management.

B. Business Case Methods This section deals with the methodology used to create the business case. In general, you speak in the language of corporate management, laying out what your project will do and how it will do it. At the same time, you also answer most of the basic questions as to why this new system is a good idea.

B.1. Scope and Boundaries Stating the assumptions, subject, objectives, and purpose does not state the scope and boundaries of the business case. Scope is the features, functions, final deliverables of the proposal — the fulfillment of the requirements; boundaries define the scope precisely, providing rules for deciding which data belongs in the business case and which does not. Scope and boundary statements determine where the cost/benefits items are measured. Scope and boundary statements tell business case readers which costs and benefits are included and where the financial impacts come from.

163

164

CHAPTER 6 BUILDING THE BUSINESS CASE

Boundary statements are always necessary, but especially so when costs of a proposed action are borne primarily by one organization or site, but where benefits may be realized much more broadly. Those who read the report or see the analysis also need to know how cost and benefit values are measured or where they come from. For this, you should describe data sources and the methods used to assign cost and benefit values. It is wise to include the data source descriptions when you cannot assume that another analyst or reader would know how the data was developed. Summarizing, this section of the business case does the following: ◆ Gives the scope and boundary statements. ◆ States the features, functions and final deliverables of the proposal; for example, that the messaging system will provide certain features. Also explains what features aren’t being included and why. ◆ Defines the boundary and provides boundary rules for deciding which data belongs in the business case (and which does not). ◆ Determines where the cost/benefits items are measured. ◆ Tells which costs and benefits are included and where the financial impacts come from. ◆ Identifies when costs of a proposed action are borne primarily by one organization or site but where benefits may be realized much more broadly. ◆ Describes sources of data and their validity. ◆ Describes time frames. ◆ Describes the geography/locations affected. ◆ Describes organizations involved. ◆ Describes the hardware or software is affected.

B.2. Rationale for Benefits There is more to business than costs and cost savings. Businesses and other organizations usually exist in order to meet certain objectives. Yet that simple and obvious fact often gets lost in business case building, when people do not know how to bring other business impacts into the business case — especially different kinds of benefits. Business cases may be built to determine how one or another proposed action contributes to business objectives, and the business case benefits rationale provides a basis for bringing these contributions into the business case. The cost model and benefits rationale identify and organize cost/benefit line items. When a proposed action contributes to the objectives, the impact may be recognized and measured immediately in financial terms (increased sales), or it may be recognized and measured in some other terms (tangible evidence of improved customer satisfaction, for instance might appear as fewer complaints or in the results of customer surveys). To bring any such impacts into the business case as benefits, the business case author develops a benefits rationale that establishes the validity of the benefits and the basis for assigning financial value to them. When building a business case, remember that it is important to establish and agree on the benefits rationale with the business case audience or readers as early as possible — well before

WRITING THE BUSINESS CASE

the final case report is delivered. This is the best possible way to avoid later disagreements about so-called intangible benefits. In sum, this section does the following: ◆ States mission/business results objectives ◆ States financial/business performance objectives ◆ States operational/functional objectives ◆ States product/service objectives ◆ States image/reputation objectives (from a customer perspective) ◆ States internal/external objectives ◆ Identifies other business objectives

Example of Benefit Rationale The rationale for a benefits such as ‘‘Improved customer satisfaction’’ can be built simply and directly by answering questions like these: ◆

Is improved customer satisfaction recognized as an important business objective for this organization? If ‘‘yes,’’ then . . . ◆

Does improving customer satisfaction have value?

◆

By what measure do we know that customer satisfaction improves?

◆

What is the target level for improvement?

◆

What is the overall value to the organization of achieving the target?

◆

Will the proposed action impact the measure of customer satisfaction? If ‘‘yes,’’ by how much?

◆

What is the value of that contribution (this may be 100 percent of the value in the last bullet or, if many other factors also contribute to reaching the target, the benefit value may be some smaller percentage of that figure).

B.3. Success Criteria Define the critical success factors for the project — what will constitute success? For example, customers will want to use the new service in preference to the previous way of delivering it. Also determine how success will be measured, such as the percentage of take-up of a new service over x years, with milestones for each annual improvement in take-up. In the case of the messaging system, success might be initially measurable by a successful deployment. Or, 100 percent of all senior management and sales staff will be equipped and trained in the use of Anywhere Access technology. Success should be judged in relation to the objective and measurable criteria established at or soon after the project’s inception. The management of the project and equally that of stakeholder expectations will form the foundation of the project’s success. It should be an expression in measurable terms of what must be done for the project to be acceptable to the client, stakeholders, and affected end users.

165

166

CHAPTER 6 BUILDING THE BUSINESS CASE

When defining success criteria, you should be able to answer ‘‘yes’’ to each of the following tests: ◆ Are all criteria measurable? ◆ Is each criterion individually realistic? ◆ Are the criteria as a group realistic? For example, high quality, early delivery and low cost may have conflicting goals. ◆ Do the success criteria form a complete list of criteria to define what will constitute an outcome that is acceptable to the customer? Although there is no single set of rules, suggested content in the success criteria discussion should include all or some of the following: ◆ Target dates ◆ Major functions ◆ Appearance ◆ Personnel level required to use/operate a deliverable ◆ Performance levels ◆ Capacity ◆ Accuracy ◆ Availability ◆ Reliability ◆ Development cost ◆ Running costs ◆ Security ◆ Ease of use ◆ Timings

C. Costs To be relevant, a business case must reflect what the anticipated costs associated with the decision are over that period. This means not just the cost of doing the project but also the costs of supporting the project throughout its life cycle, which may include internal technology costs, licensing costs, and staffing costs. What this means is the overall cost in the business case is not the same as the project budget — it reflects the full cost to the business of making a specific decision. This section summarizes the costs of the proposal the business case is being written to support.

C.1. Financial Model In this section, you should do the following: ◆ Present the financial model, such as bottom-line costs and annual and life cycle costs. ◆ Identify one-time costs such as procurement.

WRITING THE BUSINESS CASE

◆ Identify ongoing costs, such as maintenance, operational, equipment, and human resources. ◆ Predict cost increases over the lifetime of the project. It’s also useful to include cost increases that are anticipated if the project is delayed. You will find that the centerpiece of the financial aspect of the business case will be your financial model, certainly insofar as your corporate audience is concerned. It can also be a useful tool, since it is easier to examine the behavior of a model than it is to examine the thing it represents. The financial model’s first job is to simply help identify cost items that belong in the business case, as well as which items to exclude. The financial model includes every cost impact item that follows the proposal scenarios, as well as the costs expected under business as usual. All costs need to be fully defined and understood if objective and meaningful decisions are to be made. The overall cost in the business case is not the same as just the project budget. The financial model reflects the full costs to the agency of making a specific decision.

C.2. Cost Analysis The cost analysis section provides additional date regarding the above and summarizes the finding of the material discussed in the financial model section. Your best approach to cost analysis is to design it as a response to a series of questions: ◆ How much will it cost to get the system up and running? ◆ How many developer/project manager hours are required? ◆ What other projects will be affected by the new grid project? ◆ How many developer/project manager hours are required? ◆ How does the messaging system change process for the business? ◆ Will the end users need training? ◆ Is there manpower adequate to support the ongoing growth of the messaging system? ◆ Will the messaging system be revised regularly? ◆ What are the hardware costs? ◆ What are the space costs, if applicable? ◆ What are the software costs, if applicable? ◆ What are the system administration costs? ◆ What are the human capital costs? ◆ What are the project management (internal and consultancy) costs? ◆ What are the information gathering and analysis (internal and consultancy) costs? ◆ What are the records management tool development (internal and consultancy) costs? ◆ What are the records management strategy implementation (internal and consultancy) costs? ◆ What are the specialized hardware costs? ◆ What are the standard software costs?

167

168

CHAPTER 6 BUILDING THE BUSINESS CASE

◆ What are the infrastructure upgrade costs? ◆ What are the contingency costs? The costs should be quantified and divided into one-time capital costs and ongoing revenue costs. The one-time costs go into the model as the initial system costs. The ongoing costs are balanced against the ongoing system savings to arrive at an overall figure for ongoing system savings. Project management costs include the costs of third-party consultancy support plus the internal project team costs. Software costs are sometimes hard to define, as different suppliers have different pricing policies. Look at server costs, per-user costs, and concurrent user costs. Training costs can be significant for a large number of users. Options here include paying the supplier to train the administrators, operators, and a small number of users who are given the task of then training the other users. This approach is referred to as ‘‘training the trainers.’’

C.3. Alternative Solutions It’s always good to consider options. The obvious concern of management is whether there is another, less expensive way to accomplish the same task. It is easy to provide one good option and several irrelevant ones, with the obvious decision being to proceed with the choice that was originally intended. However a good business case presents multiple options that are reasonable and viable alternatives to accomplish the objectives of a project. Sometimes options will be variations on a theme, where one option is to implement a new system, change the business process, and change the roles and responsibilities within the organization. Another option might evaluate just the impacts of the new system and what the process changes would be, or the impact of changing the process and roles without implementing a new system. Most important, step back and identify viable options that reflect the most relevant means of accomplishing the business objectives.

D. Benefits Obviously, the entire point of the proposed solution is to bring benefits to the organization. These benefits should be described and discussed. Every benefit associated with the business case should be attainable and measurable in some way. Be pragmatic about the possible results, making sure that the outcomes can be measured. The attainment of the outcomes can be directly attributed to the project. These may include contributions to an agency’s image, customer satisfaction, or better delivery of service. Identify both financial and nonfinancial benefits. Nonfinancial results will not enter the financial model or total cost of operations, or other financial metrics, yet they deserve consideration in the business case. If the nonfinancial benefit clearly impacts any objective, then it is should be examined within the business case. For each benefit, you should do the following: ◆ Describe the benefit. ◆ Specify any dependencies (on projects, risks, other, benefits and programs, and so on). ◆ When is the benefit expected to occur and over what period of time realization will take place? ◆ The measure for the realization of the benefit. ◆ Specify any key performance indicators in the business operations that will be affected by the benefit.

WRITING THE BUSINESS CASE

There are two classes of benefits: tangible and intangible benefits (sometimes called tactical and strategic or hard and soft benefits).

D.1. Tangible Benefits Tactical benefits can be best be summarized as benefits that produce efficiencies and/or areas of improvement. Sometimes called hard benefits, they can be presented a number of ways, including the following: ◆ Productivity improvements ◆

Improved staff productivity

◆

Reduction in manpower requirements

◆ Competitive gains ◆

Improved uptime

◆

Streamlined processes

Sometimes IT managers shy away from accounting for productivity improvements in their business cases, preferring to stick to hard benefits that they can prove. This can be a mistake, and you shouldn’t consider the need to prove productivity to be an enemy. In addition, as most IT (or other infrastructure) managers know, the hardest projects to cost-justify are infrastructure projects like email where there is no demonstrable hard-dollar return. Sometimes the best way to do it is to assess the impact if you took the technology away. How much would costs go up or productivity go down?

D.2. Intangible Benefits In addition to the hard financial benefits the implementation of your solution will also deliver intangible (soft) benefits. These are more difficult to quantify but can, in many cases, prove even more significant. Indeed in many cases the strategic benefits are vital and hence outweigh any tactical considerations. Examples of intangible benefits include the following: ◆ Improved customer service ◆ Improved visibility and image ◆ Ability to meet e-business and electronic service delivery targets ◆ Ability to deliver improved quality levels to agreed-on financial targets ◆ Reduced delivery cycles for new products ◆ Regulatory record keeping compliance ◆ Improved knowledge management ◆ Support move to process-oriented/team working ◆ Full disaster recovery Traditionally, such vital strategic benefits are regarded as soft, and many accountants will not attach a cost figure to them. However, if your analysis of business activity establishes that these

169

170

CHAPTER 6 BUILDING THE BUSINESS CASE

strategic benefits are vital and you have senior management’s backing to achieve them, you are in a much stronger position. For example, if your information gathering and analysis indicates that you are not currently meeting your record keeping obligations and requirements, and are not complying with legislative requirements, meaning that you cannot provide up-to-date, accurate sets of the records required by law, then you need to quantify the risks you run. It may also be that one of your key strategic benefits is the survival of the organization.

Measuring Intangible Benefits Intangible benefits are just as real as, and often have a much greater impact than, hard returns. The problem with intangible benefits is they are difficult to measure. This means that if they are going to have any impact whatsoever, you must try to identify them and attempt to quantify them, if possible. Although this is a less straightforward process than some of the other aspects of building a business case, it is no less essential. Here’s one way to translate intangible benefits into tangible returns: Quantify the amount of time you expect employees to save as a result of the new application or system. For example, if the new unified communications tool will save 10 hours a year each for 100 salespeople, that’s a potential savings of 1,000 hours. Because time saved doesn’t translate directly to additional time worked, multiply the time saved by a correction factor to account for an inefficient transfer of time. The correction factor is less than 1 and greater than 0. For example, salespeople on commission are highly motivated to work, so they might have a correction factor of .7 or .8. Marketing staff might not use their time saved as effectively, so their correction factor might be .5 or less. In this example, multiplying the total hours saved (1,000) by the correction factor for the salespeople (.8), means the real time saved would be 800 hours. Next multiply that result (800 hours) by the average salesperson’s hourly salary to quantify the benefit to the company in dollars.

E. Cost-Benefit Analysis In this section, you compare costs against benefits to show that there is valid methodology to your proposal that results in some benefit to the company that outweighs the investment placed in the project.

E.1. Financial Projection The heart of the financial model and the heart of the business case will be a financial projection that clearly indicates that the expenditures are needed, affordable, doable, and measurable, while creating efficiencies and cooperation between government entries. The stability of the funding source is relevant to the successful life cycle of the business case. An explanation of what exactly the expenditures will buy, where the funding will come from, and its frequency will allow the audience to decide if the proposal is worth the invested expenditures.

WRITING THE BUSINESS CASE

What the funding will not buy is an important piece of information that the audience will also need to know in order to fully evaluate all the impacts. If there are any nonfinancial impacts that will affect the success of the proposal, these should be explored. Hence, this section does the following: ◆ Describes what the funding will cover ◆ Describes nonfinancial impacts

E.2. Cost-Savings Examples The cost analysis should examine and discover the cost savings for doing the proposal. Cost savings can be recognized in a wide range of areas (in other words, reduction in staff time, maintenance expenditures are eliminated due to a no-cost warranty period). Evaluation of how future expenditures can be avoided will lend importance to why the proposal should move forward. Even if the impact is not valued immediately in financial terms, describe its effects in ways that make the impact tangible, which can be observed and verified. Intangible impacts, savings, and benefits are sometime difficult to identify. However, these intangible savings, and benefits must be identified and made quantifiable, measurable, and realistic. This part of the business case: ◆ Predicts cost avoidances and savings ◆ Identifies tangible/intangible savings

Calculating a Return on Investment Equinox wants to purchase five new PDAs with an estimated life cycle of three years. Based on the estimated life cycle, we will use a three-year timeline with four dates: year 0 (start of project), year 1, year 2, and year 3. The product costs $3,000 each. The cost of the annual maintenance contract is $500 each item. The new product will replace other equipment that costs $3,000 a year to lease, and it will save five hours a week of administrative time. The total cost per hour (including overhead) for an administrative assistant at Equinox Company is $30. At $30 per hour, the new product will save $7,800 per year (5 hrs./week × $30/hr. × 52 weeks/year). Equinox plans to purchase and install the new product when the next payment for the leased equipment is due. The following table shows the cash flow statement for our proposed project (if the project is implemented on July 1, 2008).

171

172

CHAPTER 6 BUILDING THE BUSINESS CASE

Cash Flow Statement (three years) Year 0

Year 1

Year 2

Year 3

7-1-08

7-1-09

7-1-10

7-1-11

Purchase

15000

0

0

0

Maint Fee

2500

2500

2500

0

Cost

15500

2500

2500

0

Leased

3000

3000

3000

0

7800

7800

7800

3000

10800

10800

7800

(4500)

8300

8300

7800

Labor Savings Cash Flow

When the project starts (year 0), $15,500 will flow out of ABC Company. The project will bring in $8,300 during year 1, $8,300 during year 2, and $7,800 during year 3. At the end of year 3, the new product should be replaced. For that reason, year 3 does not include the savings from not leasing equipment. A project’s return on investment (ROI) is its savings (quantified benefits) over a specified period divided by its costs over the same period. Multiply the result by 100 to obtain the ROI percentage. ROI = (Savings/Costs) × 100 Here is an example of a simple ROI calculation for Equinox’s project. Immediate (year 0): savings: $3,000; costs: $15,500. Year 1: savings: $10,800; costs: $2,500. Through end of first year: savings: $13,800; costs: $18,000. To calculate the ROI after one year, divide $13,800 (savings) by $18,000 (costs). The result is 0.77. Multiply by 100. The ROI is 77%. A project that breaks even has an ROI of 100%. There is no return on investment after one year. Year 2: savings: $10,800; costs: $2,500. Through end of second year: savings: $24,600; costs: $20,500. To calculate the ROI after two years, divide $24,600 by $20,500. Multiply by 100. The result is 120%. The project returns 120% of its investment after two years. Year 3: savings: $7,800; costs: $0. Through end of third year: savings: $32,400; costs: $20,500. The ROI after three years is 158%.

WRITING THE BUSINESS CASE

F. Sensitivities, Risks, and Contingencies Every business plan, no matter how carefully crafted, is going to run into problems. Something is going change. A vendor may be late on delivery. A regulatory agency may change the rules on you. A cheaper (or more expensive) version of software may be required. You need, therefore, to discuss pertinent sensitivities, risks, and contingencies as part of your business case.

F.1. Sensitivities In the sensitivity analysis you will want to ask ‘‘What happens if the assumptions change?’’ Remember that the financial model and its benefits are the product of hard (relatively certain) data, but also assumptions about values and trends during the analysis period. What happens to the business case results if the values assumed for the business case are wrong? What are the consequences? Will the overall impact statements for business, financial, functional, and operational objectives change much? Such questions need to be answered on an assumption-by-assumption basis, because changes in some assumptions may impact results profoundly, while other assumptions and changes will have little effect on results. Assumptions and impact analysis statements need to be managed carefully, because changes in the assumption can bring about large changes in the relevancy of the investment. This part of the business case does the following: ◆ Highlights any regulation changes which will have an impact ◆ Predicts changes in assumptions which will have an impact ◆ Explains the consequences if values assumed in the business case are wrong ◆ Anticipates changes in impact statements for business, financial, functional, and operational objectives ◆ Elaborates on changes which will impact the relevancy of the analysis ◆ Outlines the main stakeholder groups and their contribution to the project; notes any potential conflicts between different stakeholder groups and their demands.

F.2. Risks Describe the risk assessment and its findings, including business, management, technology, and execution risks. The best method to address ‘‘risk’’ in the business case is to keep individual risks in view. There is a tendency to lump risks together. Address each individual risk element’s probability of occurring and the impact on the proposal under consideration if it does. Overall results can be developed when the individual risk factors are known, and you can then analyze their collective effect. In the case of your Exchange Server 2007–based messaging system, there is the potential that if improperly designed, the mail archiving system may fail to meet regulatory requirements. Another risk is that if it is designed too rigidly, there may be a lack of flexibility that prevents it adapting to a changing regulatory environment. Depending on the type of risk and the impact it may have on the investment, it may be necessary to develop risk mitigation provisions. In order to safeguard the overall investment from the ‘‘what ifs,’’ it is recommended that a contingency plan be developed. What are the alternatives, and why are other considerations not feasible?

173

174

CHAPTER 6 BUILDING THE BUSINESS CASE

This section does the following: ◆ Addresses project future, if project goes away ◆ Specifies each risk individually

F.3. Contingencies Identify all scenarios, including those that are most likely, pessimistic, and optimistic. This section does the following: ◆ Provides risk mitigation and backout strategy ◆ Includes pessimistic and optimistic scenarios ◆ Gives alternatives considered and reason why they were rejected ◆ Summarizes outline arrangements for contingency management such as fallback plans if service implementation is delayed.

G. Conclusions and Recommendations Now that you’ve reached the end, here comes another key point in the business case, the conclusions and recommendations. After all, this effort has been leading toward this moment when you ask your readers to buy into your conclusions and accept your recommendations.

G.1. Conclusions Your conclusion will almost certainly be that a change is indicated. You should then specify the reasons for the change. I strongly recommend that you also take this opportunity to identify and discuss any items that might be misinterpreted. Conclusions are generally organized around the business objectives addressed by business case. The conclusion focuses on the expected contribution to these objectives in terms of the results and analyses developed in the business case. You should present all the important decision criteria necessary for the business case to achieve its purpose in the conclusion section.

G.2. Recommendations A very straightforward recommendation should come at the end of the business case. The recommendation needs to be based on the preceding conclusions, which are based on the preceding analyses. A strong, clear and well-written recommendation section brings closure to the business case.

Double-Checking the Business Case Think you’re done with the written plan? Not quite. I usually recommend that you leave your plan on your desk for a day or two before doing anything else with it. Then pick it up and look at it again. Before you submit your business plan, it’s a good idea to make sure that you’ve covered the essentials. So, ask yourself the following questions, and check the answers against the plan: ◆ Does this document identify a benefit for the organization to implementing this proposal? ◆ Does the proposal lower costs or increase profitable revenue?

PRESENTING THE BUSINESS CASE

◆ Does it have intangible benefits that are valued by key stakeholders (such as shareholders and customers)? ◆ Does it support the longer-term strategic direction of the organization? ◆ Is there a good reason to change from our current way of operating? What is driving the necessity for change? ◆ What options have been considered, including the following: ◆

Doing nothing and maintaining the status quo.

◆

Stopping the activity.

◆

Options such as partnerships and outsourcing.

◆

A more limited scope for the project. Where do we get the maximum return for our effort? It is worth considering Pareto’s law (sometimes called the 80:20 rule), whereby 80 percent of the benefit might come from 20 percent of the investment?

◆ Have we examined the full range of costs and benefits — both tangible and intangible? ◆ Have we factored in to the financial case the commercial terms, such as contractual restraints, time delays for third parties to be contracted, and availability of investment funding, costs, and benefits through the whole life of the project? ◆ Who are the stakeholders and how will their interests be affected by this proposal? ◆ Is this project feasible given the constraints of time and budget? ◆ Have we identified the assumptions on which the case is based and shown why they are valid? ◆ Finally, if it were your organization, would you accept this proposal?

Creating Supplemental Documentation After completing preparation of the written business case, you should also have the following documents available as supplemental material. While you don’t need to submit them with the business plan, they will be very useful if detailed questions are raised. ◆

A documented set of tangible benefits that will result from implementing the preferred solution

◆

A documented set of intangible benefits that will result from implementing the solution

◆

A documented set of costs for implementing the preferred solution

◆

A documented cost/benefit analysis for implementing the preferred solution

Presenting the Business Case In addition to a written business case, you will almost certainly be called upon to make an oral presentation to decision makers regarding your plan for the Exchange Server 2007–based messaging system you have developed. If you’re like the vast majority of people, public speaking may be

175

176

CHAPTER 6 BUILDING THE BUSINESS CASE

one of your hidden fears. In fact, most people say that public speaking is their number-one fear, with death ranking number two. This has led at least one wag to say that apparently most people would rather die than deliver their eulogy.

PowerPoint Presentations Do’s and Don’ts Typically, a business presentation these days involves authoring it in Microsoft PowerPoint. PowerPoint is both a very useful and much abused tool. In a business case situation when presenting your information properly to the decision makers, the last thing you want is to leave them with the idea that you’ve wasted their time. You should have only one priority when making a presentation to an audience. That is ‘‘Has the audience come away from this with information that was in line with the original point of the presentation?’’ If people leave your PowerPoint presentation armed with confusion and wonder, your presentation has failed. Lack of information is rarely a failing of most presentations. Most of the time there is too much. The biggest issue is the way you deliver your PowerPoint presentation. Start with the most basic rule you need to remember: You, not PowerPoint, are the presenter. Here are some tips to creating and presenting effective PowerPoint presentations that speak of professionalism, not scattered brains: ◆ Establish whether your organization has a required PowerPoint template that you are required to use. Most companies do. Using it says, ‘‘We’re part of the same team.’’ If there is no required template, use an appropriately conservative business one. Flash and glitter are appropriate for your birthday pictures, not your business case. ◆ You have a finite amount of time — use it wisely. You have x amount of minutes, decided by someone else. Adjust accordingly, choose the most important pieces from everything you know, and make the presentation flow for the time you have. ◆ Create a logical flow to your presentation. Better yet, tell a story. You don’t want your presentation to be a random assortment of bulleted lists, which is unfortunately what frequently happens when PowerPoint is involved. There must be a flow. Tell the audience what you are going to tell them, tell them, and then tell them what you told them. If people understand where you are going to take them, they can relax and enjoy the ride. If they don’t, they will be distracted and frustrated. ◆ Avoid using generic graphics. It sends the message ‘‘Hi, more of the same old same old.’’ ◆ Don’t overdo the visuals, transitions, effects, or animations. You want people focused on the point, not the effects. ◆ To emphasize a main point, put it on the screen by itself, and let people read it. A good rule for effective PowerPoint presentations is to put up only your main points and use the screen as a reference. If you have a slide with more than five points, start a new slide. ◆ If only the main points are on the screen, the audience will realize their importance. Don’t overwhelm your audience with techno-fluff. Your goal is to make sure they leave the room with the right information. ◆ Instead of placing the bulk of your content on the slides, leave it for your presentation, and use the slides merely as reminders. Slides are most effective when used to present graphical information, not to convey passion and enthusiasm for your subject.

PRESENTING THE BUSINESS CASE

◆ Give the slides out as handouts. Let your audience know at the beginning of your PowerPoint presentation that you will give out copies of the slides. This also keeps people from getting frustrated when they can’t write down what is on every slide. You don’t want the audience to get distracted and tune you out. A handout helps them stay focused on you. You want your listener making notes about what you are saying, not merely writing down what’s on the slide. ◆ Don’t just read the points on your slides. The people who are the decision makers have all graduated from elementary school and should be capable of reading simple sentences. The slides are an aid; they are not the case. What you argue and how you explain the points is the case. As much as people like to think the opposite, we can only do one thing at a time. If someone is reading the screen, they are not listening to you, and vice versa.

Tips for Presentation Day To advance and succeed in your career, you need more than just technical skills. You also need to be able to present your ideas clearly and persuasively. Why so many people mess this part up is puzzling. Presenting a business case in front of an audience does not need to be a torturous or frightening experience. In fact, when done properly, it can have an amazingly positive impact on the future of your proposal and your career. The odds are that every decision maker in the room wants you to convince them that your proposal is a good idea. If the champion has done his job and your business case has been circulated, much of what is going to happen that day is primarily answering questions and addressing concerns or clarifying points. However, you can also completely blow it and find both you and your proposal in the limbo of organizational irrelevancy. It takes some effort to do things that badly. Here are some tips on how to avoid it: Dress appropriately. You may be used to coming to work every day and slipping into the bowels of the IT department wearing ripped jeans, a pair of pink flip-flops, and a T-shirt expressing something outrageous or obscene. That’s fine for life in your 6 by 6 cubicle. However, now you are making a presentation to professionals who come to work dressed to do business and make far-reaching decisions. They don’t have a lot of time for someone who can’t even make a simple effort to look presentable, and many see it as sign of disrespect. Wear business clothing. If you’re not sure what is expected, jackets and ties or a suit are never out of place. You can always change back into your preferred attire later if you need to. The last thing you want is the decision makers focused on your clothing and the statement it makes instead of on you and your project plan. Be early. Arriving late is disrespectful and irresponsible. The message it sends is ‘‘I can’t be bothered.’’ Practice, practice, practice. Before you make your presentation, you should know it so well you can literally give it in your sleep. Most people can’t read off a sheet of paper very well, and the tendency is to fall into a monotone, which quickly bores the listeners. By contrast, if you know the material well, you can present it conversationally, which engages the listeners. An admirer once commented to Winston Churchill’s son how moved they had been his father’s impromptu remarks and off-the-cuff speeches. Churchill’s son is reputed to have replied ‘‘I’m glad, because we heard him practice those remarks for hours at home.’’

177

178

CHAPTER 6 BUILDING THE BUSINESS CASE

Don’t fret your nervousness. Everyone gets nervous, and surprisingly no one else usually notices it unless it takes control and paralyzes you. Don’t let that happen. Remember that you know more about the subject than anyone else in the room. Also remember that almost everyone there does want to hear what you have to say and is more likely inclined to agree than disagree. Organize the material.

A good presentation has an opening, a body, and a conclusion.

The effectiveness of your opening can determine the success of your presentation. You want to capture your audience’s attention and draw them into your presentation. In the body of your presentation, make sure that you cover the points you allude to in your opening. Finally, conclude your presentation with a summary of what you said. Make sure that your material makes logical sense and that it flows smoothly from one topic to the next. Engage the audience. Eye contact is effective. Smiles, when appropriate, are effective. If you avoid eye contact, your talk will fail to connect, and your audience will feel excluded. Properly handle questions from the audience. If you take a question from the audience, first repeat it so that everyone can hear. Then, thank the questioner and answer the question. Finally, follow up to make sure you answered the question. Repeating the question first helps put your answer into context. Thanking the questioner allows you to gracefully ‘‘cut away’’ from him or her so that you’re talking to the whole audience. Use humor effectively. Humor, when used correctly, can break tension for both you and the audience and can help them connect with you. Be prepared with the details. Have all the technical documentation you might need in case you have to dive into the details. Anticipate questions, and prepare responses. Try to imagine every possible question an attendee might ask, and always be ready with an answer. Prove productivity gains. Be sure to prove how the new project will boost productivity and reduce the Total Cost of Ownership (TCO). Don’t neglect to quantify indirect returns. Show and tell.

Be prepared to demonstrate the value of the new technology.

Mitigate risks, and manage expectations. Present a worst-case and most-likely-case scenario to help with risk mitigation and managing expectations. Watch the factors that affect critical numbers when preparing these scenarios.

Summary To summarize, a business case is a logical, fact-based explanation of the reasons for approving a project or decision. A business case is developed to: ◆ Gain approval to proceed with one or more projects ◆ Obtain resources for a project or projects through internal departmental processes or the budget committee process ◆ Document — where resources are already available — what the project can accomplish for the funding

SUMMARY

The business case enables those approving the resources to analyze the rationale for the project, assess the economics of the project (financial and strategic), analyze the impact of the project, and compare these against other factors, such as the major risks and the prevailing political environment. Throughout this chapter, I walked you through the different sections of writing a business case and offered some tips for creating it. By following along with the business case available in Appendix A, you will now be ready to present your business case to the decision makers. Be confident and remember that this is your chance to shine!

179

Chapter 7

Developing a Change Management Program ‘‘The only person that likes change is a wet baby.’’ — Anonymous ‘‘It is not necessary to change. Survival is not mandatory.’’ — W. Edwards Deming ‘‘If you want to make enemies, try to change something.’’ — Woodrow Wilson President Woodrow Wilson, the author of the last quote, wasn’t that far from the mark. In the wake of the devastation of World War I, optimistically called ‘‘the war to end all wars,’’ he proposed a world assembly, the League of Nations, to serve as a sounding board for disputes. Wilson’s proposal, which would have meant a sea change in American foreign policy, was utterly rejected by the Senate and most of the American people. Vilified and attacked for the proposed change and its introduction of ‘‘entangling alliance,’’ Wilson suffered a stroke that effectively ended his presidency, and his party was ousted from power in the next election. Debate over American membership in the League of Nations was drowned out by the blitzkrieg and the din of tank treads that was World War II. This chapter is about change and how you can manage it in your organization. Even if your proposed Exchange Server 2007–based messaging system doesn’t seem like it is going to be bringing change to the organization in which you are introducing it, it is. For the new system to be successful, you are going to have manage the change process. As you’ll see later in the chapter, this is going to a complex and tricky task because of the way people respond to change. Some will see change as beneficial and promote a positive atmosphere by suggesting that there will be good results. Others will fear and resist the change. That’s why managing change is going to be critical to the successful implementation of your Exchange Server 2007–based messaging system. In this chapter, we’re going to examine what you need to do to be an effective agent of change and to ensure that your new messaging system is accepted and successful. That’s a process called change management. In the next chapter, we’ll examine a key factor in change management, user expectations and how to manage them as part of the change process. That’s not all — in Chapter 11 I’ll also cover how to manage ongoing change after you’ve deployed Exchange Server 2007.

182

CHAPTER 7 DEVELOPING A CHANGE MANAGEMENT PROGRAM

Understanding Change Management Change management is a systematic approach to dealing with change, both from the perspective of an organization and on the individual level. The term is used in a number of ways and can be both ambiguous and vague, and there is a great deal of confusion among some people about what is meant by it. Change management has at least three different facets, including adapting to change, controlling change, and effecting change. A proactive approach to dealing with change is at the core of all three. For an organization, change management means defining and implementing procedures and/or technologies to deal with changes in the business environment, in this case the introduction of the new Exchange Server 2007–based messaging system. Change management is important because successful adaptation to change is critical to an organization. Although it is unlikely that a failure to adapt to the new Exchange Server 2007–based messaging system will bankrupt the company or wreck its future, a failure to adopt and adapt to the changes it has created can significantly reduce productivity, lead to noncompliance, and hurt the organization in many small ways that can cumulatively lead to disaster. The refusal to accept and use the system fully by a significant number of users can create the sense, illusory or not, that the new system is a failure. It may not be true, but in a wider sense if people won’t use and adopt it, you have failed to achieve a key goal — full implementation of the system — and that reflects poorly on both you and your efforts. The more effectively you deal with change, the more likely you and the new system are to thrive.

Change Management Defined As mentioned, change management can be a nebulous term, and it is often used in a number of ways. In general, there are at least four basic definitions that people mean when they talk about change management: ◆ The task of managing change ◆ An area of professional practice ◆ A body of knowledge ◆ A control mechanism

The Task of Managing Change The first and most obvious definition of change management is that it means managing (and promoting) change. Unfortunately, that’s still fairly ambiguous and unclear. Managing change is a term that has at least two meanings. One meaning of managing change is to make changes in a planned or systematic fashion. This allows more effective implementation of new methods and systems in an ongoing organization. The changes to be managed lie within and are controlled by the organization. (Perhaps the most familiar instance of this kind of change is the ‘‘change control’’ aspect of information systems development projects.). However, these internal changes might have been triggered by events originating outside the organization, in what is usually termed the environment. Therefore, the other meaning of managing change is the response to changes over which the organization exercises little or no control for example, legislation, social and political upheaval, competitors, economic forces, and so on). Change management in this context doesn’t mean a knee-jerk or reactive response but a proactive response, usually one that anticipates the need for change and tries to promote its acceptance throughout the organization. This is what I mean when I talk about change management in this chapter.

UNDERSTANDING CHANGE MANAGEMENT

An Area of Professional Practice There are hundreds, if not thousands, of independent consultants who will quickly and proudly proclaim that they are engaged in planned change, that they are change agents, that they manage change for their clients, and that their practices are change management practices. There are numerous small consulting firms whose principals make these same statements about their firms. And, of course, most of the major management consulting firms have a change management practice area. Some of these change management experts claim to help clients manage the changes happening to them. Others help clients make changes. Still others offer to help by taking on the task of managing changes that must be made. In almost all cases, the process of change is treated separately from the specifics of the situation. It is expertise in the task of managing the general process of change that these personnel claim to have.

A Body of Knowledge The third definition of change management refers to the content or subject matter of change management. What is meant here are the models, methods and techniques, tools, skills, and other forms of knowledge that go into making up any practice. The content or subject matter of change management is drawn from psychology, sociology, business administration, economics, industrial engineering, systems engineering, and the study of human and organizational behavior. It is to this large, reasonably cohesive albeit somewhat eclectic body of knowledge that the term change management can refer.

A Control Mechanism For many years now, information system organizations have tried to rein in and otherwise ride herd on changes to systems and the applications that run on them. For the most part, this is referred to as version control, and most people in the workplace are familiar with it. In recent years, systems people have begun to refer to this control mechanism as change management and configuration management. Moreover, similar control mechanisms exist in other areas. Chemical processing plants, for example, are required by Occupational Safety and Health Administration (OSHA) to satisfy some exacting requirements in the course of making changes. These fall under the moniker of management of change (MOC). This type of change management is referred to as the change process in this book and will be covered in detail in Chapter 9. To summarize, there are at least four basic definitions of change management: ◆ The task of managing change (from a reactive or a proactive posture) ◆ An area of professional practice (with considerable variation in competency and skill levels among practitioners) ◆ A body of knowledge (consisting of models, methods, techniques, and other tools) ◆ A control mechanism (consisting of requirements, standards, processes, and procedures) The one we’ll be talking about in this chapter is the task of managing change and how you can fulfill your role as an agent of change.

Principles of Change Before we get into the whole question of how you can be an effective change agent, we need to examine what change means and what you can expect in response. There are five key principles you need to keep in mind, covered in the following sections:

183

CHAPTER 7 DEVELOPING A CHANGE MANAGEMENT PROGRAM

◆ Different people react differently to change ◆ Everyone has fundamental needs that have to be met ◆ Change often involves a loss ◆ Expectations need to be managed realistically ◆ Fears have to be dealt with Before we go any further, there is one thing I want to emphasize to you about change and people’s reactions to it. You can’t prevent the reaction; people are going to have these no matter what you do. What you can do is shorten the reaction time. Your change management activities are intended to get people through the process of adopting and accepting as quickly and as painlessly as possible. Figure 7.1 shows what you can realistically expect to do.

Figure 7.1 The classic change curve +

Performance

184

High expectations

THE CLASSIC CHANGE CURVE

Realization of effort and complexity x

−

Much better than before

Light at the end of the tunnel Time

Despair

Typical program Effective program

Different People React Differently to Change Figure 7.2 shows a simple but illustrative continuum ranging from stability to change. As you can imagine, just as with most human endeavors and states, everyone has his or her own preference for where they would like to be on this continuum. Some crave stability and cluster at that end of spectrum. They like things they way they always have been. Change is not attractive to them. You’ve probably run into the more extreme versions — those who would much prefer a return to typewriters and carbon paper. Other people like to be at the Change end of the spectrum — they are always looking for something different and new.

Figure 7.2

Stability

Change

The change continuum

Psychologists and sociologists tell us that problems inevitably arise when an individual’s preferences differ from the situation they find themselves in. Examples of this would be having a stability-oriented person in circumstances that are changing constantly, or a change-oriented person where everything is the same and there is nothing new. In these situations, the individuals involved can experience an entire range of reactions: ◆ Strong dissatisfaction ◆ Stress

UNDERSTANDING CHANGE MANAGEMENT

◆ Negative attitudes toward individuals with preferences at the other end of the spectrum (such as a distrust or dislike of them) ◆ Resistance (to change or to the status quo) ◆ Intense emotions ◆ Loss of rational judgment What this means is that people will resist change the closer they are to the stability end of the spectrum, while change-oriented persons will likely be more willing to accept your new system.

Everyone Has Fundamental Needs That Have to Be Met The psychologist Will Schutz identified three basic needs that people have in interpersonal relations. These basic needs are also of fundamental importance in people’s reaction to change in their lives and in their livelihood: ◆ The need for control ◆ The need for inclusion ◆ The need for openness Although different people have different levels of these needs, in any change process there is always some degree of need for control over one’s environment/destiny, some degree of need to be included in the process of forming the change that is taking place, and some degree of need for managers/leaders to be open with their information. If a change program fails to meet the control, inclusion, and openness needs of the individuals affected by it, then that program is likely to encounter a range of negative reactions, ranging from ambivalence through resistance to outright opposition. In the case of implementing an Exchange Server 2007–based messaging system, this could mean that they don’t get on board with the many changes and benefits that it can bring to the system.

Change Often Involves a Loss In the graphic shown here, you can see the classic ‘‘loss curve’’ that describes the stages we go through when there is a change in our lives. I am sure you have noticed that it is very similar to the change curve you saw in Figure 7.1 The relevance of how it impacts on change acceptance depends on the nature and extent of the loss. If someone is promoted to a more senior position, the ‘‘loss’’ of the former position is rarely an issue because it has been replaced by something better. But if someone is laid off with little prospect of getting a new job, there are many losses (income, security, working relationships) that can have a devastating effect. Although that is a bit extreme for the system you are introducing, there will likely be displacement, and some people affected (or who think they will be affected) will go through the process. There are many variations of the loss curve. One is known as SARAH — that is, the individual experiences (in this order): ◆ Shock ◆ Anger ◆ Rejection ◆ Acceptance ◆ Healing

185

CHAPTER 7 DEVELOPING A CHANGE MANAGEMENT PROGRAM

Shock Healing

Performance or Self-Esteem

186

Acceptance Anger

Rejection

Time

All loss curves have some common factors. First, there can be an initial period where the change does not sink in. For example, feelings may be kept high by the individual convincing him- or herself that the change is not going to happen. People used to a system may find a dozen different reasons to think that the new system won’t really happen. Second, when the loss is finally realized, the individual may hit a deep low. The depth of this ‘‘low’’ is deepened if the loss is sudden or unexpected. For users this may be nothing more than the sense of frustration at having to learn a new way of doing things. For IT personnel responsible for running the previous Exchange Server, it may be that they think their previous skillset is now useless — and they may transfer that feeling from ‘‘What I know is valueless’’ to ‘‘I am valueless.’’ Finally, the period of adjustment to the new situation can be very uncomfortable and take a long time. In the case of the loss of a loved one, the period of adjustment can be as long as two years. Studies have shown that new computer systems can take about the same amount of time to be accepted based on the amount of change. I am personally convinced that many older systems are still maintained from the point of view of comfort then fiscal reasons.

Expectations Need to Be Managed Realistically The relationship between expectations and reality is very important. You can see this in customer relations — if a supplier fails to meet expectations, then the customer is unhappy; if the supplier exceeds expectations, then the customer is happy. If you promise your users the sky and give then dirt, you’re in for a rebellion. Because this is an extremely important part of the change process, Chapter 8 is going to address this topic. To some extent the same principle applies to staff and change. If their expectations are not met, they are unhappy. If their expectations are exceeded, they are happy. Sometimes, enforced change inevitably involves the failure to meet expectations: for example, there was an expectation of system stability, which has now been taken away. What you have to do, however, is make sure they that don’t pour gasoline on the fire by making promises that cannot or will not be kept. Expectations have to be set at a realistic level, and then exceeded (e.g., in terms of the degree of outplacement support that will be provided).

Fears Have to Be Dealt With As you’ve probably noticed, whenever there is a significant change, rational thought goes out of the window. This can mean people enter a euphoric state expecting the sky to rain gold. More

UNDERSTANDING CHANGE MANAGEMENT

commonly it means that people often fear the worst — in fact, they fear far more than the worst, because their subconscious minds suddenly become illogical and see irrational consequences. Former U.S. President Lyndon B. Johnson once said that when someone was laid off from his job it was devastating to productivity. His argument was that the real problem was not the lost worker, but the six people who were now worried they were going to be laid off next. Let’s a take a quick look at the thought process of a person whose company has taken steps, such as the introduction of a new messaging system, that is widely perceived as likely to produce a reduction in staff in various departments. (You may be wondering how someone can come to that conclusion. They arrived there because fear drives reason out.) So they might be having this type of though process as word reaches them about the change you will be implementing: ◆ The company is going to be able to reduce staff with this new system, which means . . . ◆ They will start laying people off, which means . . . ◆ I’ll be the first to go, and . . . ◆ I’ll have no hope of getting another job, which means . . . ◆ I won’t be able to pay the mortgage, so . . . ◆ I’ll lose the house, which means . . . ◆ My family won’t have anywhere to live, and . . . ◆ My spouse won’t be able to cope, so . . . ◆ My spouse will leave me, and . . . ◆ I’ll be so disgraced that the children won’t speak to me ever again. ◆ I’ll end up killing myself in shame. ◆ I’m going to make sure this doesn’t happen! Any and all fears need to be addressed. For example, if the new messaging system is going to result in the reduction of staff generally or perhaps only among those using the old system, you might want to help people recognize that most people who are laid off find a better job with better pay and have a good-sized lump sum in their pocket! Or you can explain how the reductions in staff numbers are going to be achieved (by natural attrition or voluntary lay off).

Obstacles to Change At the start of this chapter I made reference the famous aphorism that ‘‘no one likes change but a wet baby.’’ The truth is that people, including you and me, don’t really like change that much. The status quo is comfortable and easy to deal with. In any organization, there are a number of sources of resistance to change. Parochialism and cultural resistance These can play a critical role in hindering any change effort. Many current operating practices have a long, entrenched history that has developed over time in order to accommodate the needs of different organizations and special interests. The more deeply rooted these systems and attitudes are, the more difficult change will be. Unclear goals and performance measures If there aren’t clear goals or performance measures in the organization, people are going to look at change warily. If they don’t see how it benefits them or the organization, they would probably prefer business as usual.

187

188

CHAPTER 7 DEVELOPING A CHANGE MANAGEMENT PROGRAM

Lack of incentives for change For many organizations, performance is measured by the amount of money spent, people employed, or tasks completed on time or not. The bottom line in these organizations is that if they cannot see a way for the proposed change to directly meet these targets, they are less likely to embrace and almost certain to reject it.

Resistance to Change History shows that workers have resisted some of the best-laid plans. A few may openly fight it. Many more may ignore or try to sabotage a change. In the corporate world, most people, most of the time, resist change. Why? These people believe that change has very little upside for them — in other words, that change is rarely for the better.

Ho-Hum One kind of resistance involves employees who have been with a company for a few years and have seen flavor-of-the-month change programs come and go: Management launches some kind of change effort to great fanfare. Managers talk up the benefits and explain why this program will be good for both the company and its employees. They make promises, but at the end of the day, they fail to deliver. Nothing really happens, and the whole effort seems like a waste of time. Well, it makes sense to resist things that are a pure waste of time. These kinds of dismal scenarios give employees the impression that change is not good. And employees have no reason to believe that it’s going to be better in the future. The reason why that is not the case here is that, as you’ve already seen, your Exchange Server 2007– based messaging system is a fabulous thing, and we’ve already talked about all the fabulous reasons why we’re implementing it in Chapter 2. But you do need to make sure that you have communicated that to all those who will be affected. If you don’t, they will sabotage you.

Preserving the status quo seems to be a natural inborn state. You can usually measure the depth of resistance to change a person has, and that depth usually falls into one of three broad categories: Superficial This one may be overcome fairly easily by simple, basic processes. It’s vulnerable because the resistance isn’t deep seated and more pro forma. Moderate This is the most common form which is often based on emotional issues and fear of loss. Occasionally it may ‘‘go underground’’ and be mistakenly interpreted as superficial. Strong

The entrenched adversarial resistance. These are the ‘‘opponents’’ to the system.

How does someone resist change? As you already know from your personal life, resistance to change doesn’t always manifest itself in obvious ways. Change management specialist Rick Maurer has identified eight forms of resistance: Confusion There is a fog present that makes it hard for people to hear that change is going to happen. You might find that the existing messaging system staff claim to have never heard about the new system or ‘‘weren’t in the loop’’ when in reality they were. This is one of the most common initial resistance ploys: ‘‘No one told me about it.’’ Immediate criticism Before people hear the details they are against it. These are the folks — users and IT staff — that already have the idea that any change is bad, so they can’t wait to criticize. I think their most distinguishing characteristic is ‘‘Well you know all those new Microsoft programs are full of bugs!’’

UNDERSTANDING CHANGE MANAGEMENT

Denial People refuse to see or accept that things are different and that they need to adapt. Although I am not in favor of change for change’s sake, I’ve often encountered people who are still using older software versions and foregoing the needed features an upgrade provides because they simply refuse to recognize the need to change the system or that things have changed. They may, for example, simply maintain Exchange 5.5 and consider VoIP a passing fad. Malicious compliance They smile and seem to go along, but you discover later that they haven’t made a single move toward change. Sabotage Actions taken to inhibit or kill the change. This can take a lot of forms. One common way is to start burying you under ‘‘policies’’ that need to be adhered to. I was on a simple project once where the opponent attempted to keep us busy by filling out impact statements. The goal is often to discredit the project by making it miss deadlines or forcing it out of scope through creative application of bureaucratic ‘‘creep.’’ Another favored sabotage technique is to find an opponent in corporate management and feed him enough information to counter the executive sponsor. Easy agreement People agree without much resistance but may not realize what they are agreeing to, then attempt to back away form their agreement. Deflection Better known as ‘‘If I change the subject and maybe it’ll go away.’’ The hallmark of this resistance is that while you may be explaining the benefits of the new messaging system, they want to talk about some other problem or issue that is completely unrelated. Silence input.

This is the hardest resistance to deal with from your perspective because there is no

Reacting to Change: The Wrong Way What are our typical and human reactions to resistance? ◆ Use power to overcome it. This almost inevitably ensures an increase in resistance. ◆ Manipulate those who oppose. But trickery doesn’t work for long. ◆ Apply force of reason. Sadly this common response can quickly deteriorate into one of the others, especially if those you’re trying to convince don’t seem to get your reasoning ◆ Ignore resistance. The problem is that it still doesn’t go away. ◆ Use your personal relationships. The problem is that even friends may back away if they don’t like the cost or tradeoffs. ◆ Make deals or offer bribes (for example, this change will get you a new computer). This works if the resistance is superficial and the deal is a good one — sometimes. ◆ Kill the messenger (many executive use this one — just get rid of the opposition — or banish them to Siberia). ◆ Give in too soon (and have a half-baked or mediocre success if any). The most important thing you should remember when you meet the inevitable resistance to change is that resistance is normal. The second point to remember is that when you react too strongly to resistance (like trying to ’’overcome’’ it), this only causes it to stiffen and increases the likelihood of problems with the change.

189

190

CHAPTER 7 DEVELOPING A CHANGE MANAGEMENT PROGRAM

As you’ll see later in this chapter, it is important to understand the reasons behind the resistance. If you respect those who resist and consider the merits of their position, you can gain considerable knowledge. This knowledge can enable you to ‘‘embrace’’ the positions of those resisting, and in doing so gain far greater insights into how to enlist their help in removing resistance positively. Perseverance is also important. Being able to see the other side of the issues and embrace some part of that position without compromising the whole change effort will pay dividends and improve the chances of success.

Basic Principles of Change So far we’ve looked at what change management is and what sort of obstacles you can expect along the way. Now it’s time to start examining how to actually make change happen and to ensure that the process and the outcome are pleasant and positive for everyone. This is going to be different than anything you have done before. You may have been managing change your entire life, but that was on a personal level. Now you are going to have to manage change for other people — the people in the company where you are introducing the new Exchange Server 2007–based messaging system. To be an effective change agent, you need to have a familiarity with the basics of change management theory. Kurt Lewin, a noted psychologist, characterized change having three basic stages: unfreezing, changing, and refreezing. Figure 7.3 illustrates this concept.

Figure 7.3 Lewin’s ‘‘unfreezechange-refreeze’’ model

Change

Unfreeze

Refreeze

The unfreezing step involves making people aware of the need for change and identifying the forces supporting and resisting change. Because most people and organizations prefer stability and the perpetuation of the status quo, a successful change process must overcome the status quo by unfreezing old behaviors, processes, or structure. You can use a variety of communication methods, such as one-on-one discussions, presentations to groups, memos, reports, company newsletters, training programs, websites and so forth to educate employees about an imminent change and help them see and accept the logic of the decision. Deficiencies in the current situation are identified, and the benefits of the replacement are stressed. The changing step focuses on learning new behaviors. Change results from individuals being uncomfortable with the identified negative behaviors and being presented with new behaviors,

ADOPTING CHANGE

role models, and support. In this phase, something new takes place in a system, and change is actually implemented. This is the point at which managers initiate change in such organizational targets as tasks, people, culture, technology, and structure. When managers implement change, people must be ready. Refreezing centers on reinforcing new behaviors, usually by positive results, feelings of accomplishment, or rewards. After management has implemented changes in organizational goals, products, processes, structures, or people, they cannot sit back and expect the change to be maintained over time. Behaviors that are positively reinforced tend to be repeated. In designing change, attention must be paid to how the new behaviors will be reinforced and rewarded. This model applies to your messaging system implementation project. The company and its user are currently frozen in the sense that they have a messaging system in place that they are already familiar with and comfortable with. In order to unfreeze them you have to identify the forces that are causing (or can cause) resistance to change and nullify them. For example, they may simply be at the stability end of the personality spectrum and don’t want to learn anything new. You can do things to unfreeze this position by showing the simplicity and benefits of the new system over the old one. Once users are unfrozen, it is easy to lead them to an acceptance of the new system. Once you have the new system and the changes it brings are in place, you can start the process of ‘‘refreezing’’ the users. Be careful about how you think of refreezing. You do not want to recreate an irrevocable belief that the new system is carved in stone. A good ‘‘refreezing strategy’’ leads the users and the organization to embrace the new system, and adopt and reinforce any new behaviors (for example, using devices), while at the same time keeping open the idea that feedback and future changes are both welcome and desirable. With the new messaging system, this means getting the users to use the new system regularly and that you communicate with them frequently about how to update and improve the system.

Adopting Change Up until now, it seems like we’ve concentrated on how difficult change is. In fact, you might be wondering if change is even possible and whether or not it can be done. I’m happy to tell you that it can. In the following sections, let’s look at how change is actually adopted. Understanding how change happens will help you be an effective change agent.

How People Change As you have almost certainly surmised by now, change is not simply an event. An announcement by management that a new messaging system is being implemented and should be used is not enough to make it happen and produce the desired change. Instead change is a process, a transformation. All change requires individuals to develop and put into practice new skills, behaviors, and working relationships. Each potential user must individually go through a process of accepting and then learning to use the innovation. Failure to understand the change process leads to actions that are not relevant to user needs — and produces an increased risk of failure. As we’ve seen earlier, before individuals can decide that that they want to use the innovation, all of their personal concerns must be uncovered and addressed. Even the concerns that are not voiced like ‘‘Can I really succeed under the new system?’’ If you force people to use the innovation before their concerns are addressed, you will create reluctant users, always looking for an opportunity to prove that their concerns are justified and that the innovation won’t work.

191

192

CHAPTER 7 DEVELOPING A CHANGE MANAGEMENT PROGRAM

At any point, individuals can become discouraged or decide that the benefits are not worth the effort. Implementation slows down, costs escalate, and planned improvements in profit and competitive advantage evaporate. Fortunately, there are common stages people go through as they adopt an innovation. By understanding how people change, you can develop specific interventions to improve implementation success.

Concerns-Based Adoption Model The Concerns-Based Adoption Model (CBAM) described in Table 7.1 provides a road map for understanding change. People undergoing change move stepwise through stages. So, if you know the model and know someone’s current stage, you can predict the information that they need now and the next set of issues that will concern them.

Table 7.1:

How People Change

Levels of Use

Stages of Concern

Exchange Example

Orientation: User is acquiring information about the innovation and is exploring its value and the demands that it will make.

Informational: General awareness and interest in learning more about the innovation. The individual is unconcerned about himself/herself in relation to the innovation.

User reads about Exchange Server 2007 in magazines or trade journals.

Preparation: User has decided to use the innovation and is preparing for first use.

Personal: The individual is concerned about the demands of the innovation and how it will impact decision making, compensation, rewards, and status.

Exchange user wonders how this is going to impact them.

Mechanical use: User is occupied with mastering the tasks required to use the innovation, often resulting in disjointed and superficial use.

Management: Attention is focused on using the innovation. Primary issues relate to organizing, managing, and the time needed to use the innovation.

Personnel have received some training but don’t have mastery. IT staff still feeling wary; users still uncertain.

Routine or refinement: The user has mastered the mechanics of using the innovation and is using the innovation to produce results.

Consequence: Attention focuses on the outcomes of using the innovation. Does the new SFA process help improve sales performance?

Exchange users starting to feel comfortable with new features.

Integration: User is combining his/her efforts to use the innovation with the related activities of others to achieve a collective impact.

Collaboration: The focus is on coordination and cooperation with others regarding use of the innovation.

The best evidence that this stage is here is when you see users, technical and nontechnical, sharing ‘‘tips’’ on how to make things work better.

ADOPTING CHANGE

Practical Results As you can see, there are a number of practical lessons from this model that you can immediately apply in your change management strategy: ◆ High levels of positive interest in the beginning of a change process does not mean there will be low user resistance as the process moves forward. It simply means that users are at the informational stage of concern where they want to learn about general characteristics and requirements for using the innovation. ◆ As users move to the personal stage of concern, you can expect them to have lots of very detailed concerns about how the new process will work and how it will impact individuals: ‘‘What must I do different?’’ ‘‘What’s in it for me?’’ ‘‘Is the change really necessary or is it simply another fad?’’ ◆ At the management stage of concern, users greatly benefit from easy access to help on how to use the innovation. Many small support efforts from a help line or from successful users works much better that a few long training efforts. If support is not provided during this time, many users will become discouraged and stop using a complex innovation. ◆ Users at the routine level of use are successfully using the innovation and are producing results. Now is the time to provide information about how to use the SFA system to meet more complex strategic goals. Providing advanced user information at an earlier stage can actually slow implementation.

How People Adopt Change As you can surmise from our simple illustration of the spectrum of change at the beginning of this chapter, individuals do not adopt a change at the same rate, rather they will adopt it at different times. Noted social psychologist Everett M. Rogers used a classification system to identify the different types of adopters of innovation (which is really just a different word for change) The adoption of a change will usually follow a normal bell-shaped curve. There are five different adopter categories, as shown in Figure 7.4: ◆ Innovators ◆ Early adopters ◆ Early majority ◆ Late majority ◆ Laggards

Note A small warning — these five are ideal types and therefore abstractions. Another caveat is that the division into type is not always smooth — there are no pronounced breaks in the continuum. These means that people, particularly those on the border between types, may show more than one characteristic.

193

194

CHAPTER 7 DEVELOPING A CHANGE MANAGEMENT PROGRAM

Figure 7.4 Rogers’ adoption curve

50

40

30

20

10 Innovators 2.5%

0

Early Adopters 13.5%

Early Majortiy 34%

Late Majority 34%

Laggards 16%

Time

Innovators Innovators live on the edge, pushing the barriers of the change. They like change and can cope with a high uncertainty about the change at the time they adopt it, which is literally moments after they become aware of it. They also have personalities that can accept the occasional setback that inevitably happens without losing either their enthusiasm for the idea or their faith in themselves. These are the users and IT staff that think Exchange Server 2007 is going to be great for the organization before they even see the demo, and will often leave your presentations singing its praises. Innovators are not always the best people to look to for help in promoting change throughout the system. One of the potential problems is that if they are not monitored carefully they can accidentally give rise to unrealistic expectations. Because they are perceived as interested in change for change’s sake, and without regard for the consequences, they are normally not very well respected by other persons in the organization. Except for other innovators, no one looks to them for evidence that the new change is good or beneficial. The polite word most people will use to describe an innovator is adventuresome, but most people in an organization think of them as weird.

Early Adopters This group is better integrated into the rest of the organization and as a result has both the highest level of respect and the greatest degree of opinion leadership. Other persons thinking of adopting the change will look to early adopters for advice and information about your new messaging system. They are ‘‘the person to check with’’ before using the new system. Another characteristic is that early adopters also serve as role models for people who want to adopt the innovation. Early adopters are respected as the embodiment of the successful use of new ideas and changes. Consequently, simply by adopting the new system, they decrease uncertainty about it. As a change agent, you will find that early adopters, as opposed to innovators, make excellent missionaries for speeding the diffusion process of your new messaging system.

Early Majority Adopters These persons adopt the new system just before the average member of the organization. They tend to communicate frequently with their peers but are not opinion leaders or influencers.

YOU, THE CHANGE AGENT

However, they are still an important link in the diffusion process since they form the bridge between the early adopters and late majority, thus linking together almost 85 percent of the personnel in the organization. Typically, they will deliberate and ‘‘think about it’’ for some time before completely adopting the new change. They tend to have a relatively longer waiting period than both the innovator and the early adopter, and their motto could easily be ‘‘Be not the first by which the new is tried, nor the last to lay the old aside.’’

Late Majority Adopters Like the early majority, they make up a third of the members of an organization. They tend to adopt a change because of economic necessity (for example, to keep their job) or peer pressure from others. They tend to greet change with skepticism and caution. Winning them over is usually a longer process. Typically, the best strategies to get them to adopt involve the overwhelming weight of system norms and peer pressure. They will only adopt the change after most of the uncertainty about a new idea is removed.

Laggards The point of reference for this group is the past. They make decisions only in terms of what has been done previously. They interact usually only with other like themselves who cling to the traditional ways of doing business. These are the people who will still argue that computers are wrong and that email communication is just a fad. Some of them will make little if any effort to adopt new systems.

You, the Change Agent Several times we’ve referred to your role as a change agent for the introduction of the new Exchange Server 2007–based messaging system without defining exactly what a change agent is. As you’ve no doubt surmised, a change agent is ‘‘an agent for change, promoting it.’’ But it is much more than that. A change agent is a person who has the clout, the conviction, and charisma to make things happen and to keep people engaged. Change agents employ a number of skills — they must do the following: ◆ Understand, but not participate in, an organization’s politics ◆ Be able to ‘‘deconstruct’’ an organization or process and put it back together in original, innovative ways ◆ Be keen analyzers who can clearly and persuasively defend their analyses to the organization ◆ Speak many organizational languages — marketing, finance, systems management ◆ Understand the financial impacts of change, whether brought on by radical overhaul or incremental continuous improvements In other words you, as a change agent, are responsible for bringing order out of chaos. Managing the kinds of changes encountered by and instituted within organizations requires an unusually broad and finely honed set of skills, roughly grouped as follows:

195

196

CHAPTER 7 DEVELOPING A CHANGE MANAGEMENT PROGRAM

◆ Political skills ◆ Analytical skills ◆ People skills ◆ System skills ◆ Business skills

Political Skills Organizations are first and foremost social systems. Without people, there can be no organization. Lose sight of this fact and any would-be change agent will likely lose his or her head. Organizations are hotly and intensely political. And, as one wag pointed out, the lower the stakes, the more intense the politics. Knowing how to deal with organizational politics is an essential skill. One of the things you need to learn early, as we mentioned in Chapters 2 and 3, is to learn and understand who wields what power. You also need to distinguish between formal and informal power. Formal power comes from the position or office a person occupies. It may be legal (for example, corporate officers can legally do things that an employee can’t). Typically it is hierarchical and higher a person is in an organization chart the more power they wield. For example the chief technology officer wields more authority than the supervisor of the help desk. While formal power is real, it can often mask informal power. You get informal power by earning it. In our discussion of adopters earlier in the chapter, for example, we mentioned the role of early adopters as trendsetters and influential persons in the acceptance of the new system. Persons who are considered ‘‘experts’’ may wield considerable power, albeit over a limited area. Consider for example a parliamentarian who can define how and what debate styles and times can be used, therefore effectively controlling people who far outrank him. More than one humorist has observed that the person who paints the lines for parking spaces also wields considerable organizational power. As the change agent, you will be given some level of ‘‘formal power,’’ though expect it to be limited. Change agents may be necessary but management is loath to give you a lot of real power. Hence you will have to earn, for yourself, informal power if you want to successfully control and manage change. You want people to consider you an expert on the new system and a competent manager, and you want them to perceive you as a source of valuable information and in some ways a mentor for understanding the new system. There are no quick paths to informal power, but there are a few things you can do to enhance your informal power: ◆ Listen. ◆ Help people with problems as often as you can. ◆ Tell the truth. ◆ Reward successes and accomplishments. ◆ Praise people. ◆ Don’t be arrogant about getting your hands dirty. Superior smugness undoes all benefit (see George W. Bush).

YOU, THE CHANGE AGENT

◆ Attend all meetings you are expected to. Be on time. ◆ Don’t be afraid to admit you don’t know something. Finally and most importantly, while you should understand the organization’s internal politics do not, repeat do not, under any circumstances join in this game. This is one area where you must make your own judgments and keep your own counsel; no one can do it for you.

Analytical Skills You might be able to be weak in all the other skillsets and still accomplish an effective if not brilliant job as a change agent. But the one area you cannot afford to be less than brilliant is analysis. Guessing won’t work. Insight is nice, even useful, and sometimes shines with brilliance, but it is difficult to sell and almost impossible to defend. A lucid, rational, well-argued analysis can be ignored and even suppressed, but not successfully contested and, in most cases, will carry the day. If not, then the political issues haven’t been adequately addressed. Two particular sets of skills are very important here: (1) workflow operations or systems analysis, and (2) financial analysis. Change agents must learn to take apart and reassemble operations and systems in novel ways, and then determine the financial and political impacts of what they have done. Conversely, they must be able to start with some financial measure or indicator or goal, and make their way quickly to those operations and systems that, if reconfigured in a certain way, would have the desired financial impact. Of course, you’ve no doubt caught on to the fact that there isn’t a list of all the problems that could possibly arise, so there are no ready-made solutions you can simply pull out of a box. Analytical skills are going to be your tools. You must be able to define the problem, assess its importance, understand its dependencies and develop a solution. And probably have little time to do it. There is no hard and fast way to define a problem. But there is a series of essential questions you should ask: ◆ What is the problem (that is, fully describe it)? ◆ Is it my problem? ◆ Can I solve it? Is it worth solving? ◆ Is this the real problem, or merely a symptom of a larger one? ◆ If this is an old problem, what was wrong with the previous solution? ◆ Does it need an immediate solution, or can it wait? ◆ Is it likely to go away by itself? ◆ Can I risk ignoring it? ◆ Does the problem have ethical or political dimensions? ◆ What conditions must the solution satisfy? ◆ Will the solution affect something that must remain unchanged?

People Skills As stated earlier, people are the sine qua non of organization. Moreover, they come characterized by all manner of sizes, shapes, colors, intelligence and ability levels, gender, sexual preferences, national origins, first and second languages, religious beliefs, attitudes toward life and work,

197

198

CHAPTER 7 DEVELOPING A CHANGE MANAGEMENT PROGRAM

personalities, and priorities — and these are just a few of the dimensions along which people vary. You have to deal with them all. The skills most needed in this area are those that typically fall under the heading of communication or interpersonal skills. To be effective, we must be able to listen and listen actively, to restate, to reflect, to clarify without interrogating, to draw out the speaker, to lead or channel a discussion, to plant ideas, and to develop them. All these and more are needed. Not all of us will have to learn Russian, French, or Spanish, but most of us will have to learn to speak systems, marketing, manufacturing, finance, personnel, legal, and a host of other organizational dialects. More important, we have to learn to see things through the eyes of these other inhabitants of the organizational world. A situation viewed from a marketing frame of reference is an entirely different situation when seen through the eyes of a systems person. Part of the job of a change agent is to reconcile and resolve the conflict between and among disparate (and sometimes desperate) points of view. Another task, relationship building, especially with stakeholders and management is a major success factor. Don’t leave relationships to chance; give this activity the same importance as other tasks, and add them to your ‘‘to do’’ and ‘‘action item’’ lists. Too often, change agents make the mistake of believing that others understand the issues, feel the need to change, and see the new direction as clearly as they do. The best change programs reinforce core messages through regular, timely advice that is both inspirational and practicable. Communications flow in from the bottom and out from the top, and are targeted to provide employees with the right information at the right time and to solicit their input and feedback. Often this will require overcommunication through multiple, redundant channels.

Changing the Image of the IRS In the late 1990s, the commissioner of the Internal Revenue Service, Charles O. Rossotti, had a vision: The IRS could treat taxpayers as customers and turn a feared bureaucracy into a world-class service organization. Getting more than 100,000 employees to think and act differently required more than just systems redesign and process change. IRS leadership designed and executed an ambitious communications program, including daily voice mails from the commissioner and his top staff, training sessions, videotapes, newsletters, and town hall meetings that continued through the transformation. Timely, constant, practical communication was at the heart of the program, which brought the IRS’s customer ratings from the lowest in various surveys to its current ranking above the likes of McDonald’s and most airlines. It is important to remember that the users and coworkers you are dealing with are people, not machinery. You might find it necessary to show empathy, provide support and understanding, and address individual concerns. Charm is great if you have it, but courtesy and respect are even better. A well-paid compliment can buy gratitude. People tend to thrive on positive recognition and acknowledgment and wither from criticism; do not belittle people if they are struggling with the new system or not moving along as fast as you think they should. A sincere ‘‘thank you’’ can earn respect. Some other quick tips you should employ that will enhance your social and people relationships include: ◆ Don’t eat at your desk, thus isolating yourself; have lunch with team members, employees, or coworkers. ◆ Avoid sarcasm.

BASIC CHANGE MANAGEMENT STRATEGIES

◆ Learn to reduce your stress level. ◆ Smile. ◆ Be honest. ◆ Don’t pretend to know things you don’t.

System Skills This doesn’t refer to the Exchange and other computer system skills you will need to master as part of the project. System skills in this context are much more than learning about computers. A system is an arrangement of resources and routines intended to produce specified results. To organize is to arrange. A system reflects organization and, by the same token, an organization is a system, known as General Systems Theory. When a user employs the Exchange Server 2007–based messaging program or device, the two form a system. What you need to be aware of and fully understand is how the users are going to work with the Exchange Server 2007–based messaging system. That’s because the new dynamic is going to create new properties that don’t exist for the user or the system separately.

Business Skills As change agent, another essential skill is knowing and understanding how the business works. This includes knowing how it is managed, is financed, is organized, and plans. You’ll also have to understand what other factors effect the business, such as regulatory requirements, laws, market forces, future plans, and so on. We covered this material in detail in Chapter 2, so we won’t spend much time restating it here. However, understand that you should now be able to manage change from a business perspective. First, make sure that you fully understand what the reason for implementing the system is in the first place. Make sure that you have thoroughly mapped this out. It is also imperative that you continue to communicate with management and key stakeholders throughout the life cycle of this project. One of the most critical errors you can make is letting them stop talking to you (or you stop talking to them). Second, make sure that you are familiar with the current business model, organizational structure, geographic scope, and other key business aspects. The odds are good that you will find yourself needing to manage change at every level of the organization.

Basic Change Management Strategies There are currently four basic change management strategies, the first of which was described back in 1969 when Warren Bennis, Kenneth Benne, and Robert Chin authored a book on change management strategy, The Planning of Change (Holt Rinehart Winston, 1969). Each of these strategies is an attempt to explain the underlying assumptions, challenges and methods by which change is regarded, digested, and eventually created by individuals and organizations. Table 7.2 contains a summary of these four strategies.

Empirical-Rational This strategy starts from the belief that people are rational and act in their own self-interest. Change will be accepted if it acts in their self-interest or in helping them attain something that is in their interest.

199

200

CHAPTER 7 DEVELOPING A CHANGE MANAGEMENT PROGRAM

Table 7.2:

Change Management Strategies

Strategy

Description

Empirical-Rational

People are rational and will follow their self-interest — once it is revealed to them. Change is based on the communication of information and the proffering of incentives.

Normative-Reeducative

People are social beings and will adhere to cultural norms and values. Change is based on redefining and reinterpreting existing norms and values, and developing commitments to new ones.

Power-Coercive

People are basically compliant and will generally do what they are told or can be made to do. Change is based on the exercise of authority and the imposition of sanctions.

Environmental-Adaptive

People oppose loss and disruption but they adapt readily to new circumstances. Change is based on building a new organization and gradually transferring people from the old one to the new one.

To apply this strategy you, the change agent, suggest or propose a change that is in the user’s best interest; for example, an Exchange Server 2007–based messaging system. This strategy is difficult to use when the incentives available are modest. Why risk what we have for an uncertain future that promises to be no more than modestly better than the present? This is especially true when people currently like the existing system. The proposal for the change, as well as the arguments for embracing and adopting the change are made from a rational point of view. Your case is built on pointing out how the change and the user’s best interests are connected. The expectation is that the users will agree with the logic of your arguments and therefore adopt the change because it is in their best interests. The story you tell has to convince them, not you. The way to make this strategy work is through information and communication in great abundance. There probably isn’t such a thing as overcommunication or too much information. The way the information is provided and organized should be logical, empirical as well as being understandable. In this strategy users will look around and through a cognitive process adapt and adopt the new system. A by-product of this strategy consists of converts, that is, people who buy the story. Some will see the light and want to sign on. These people can be very helpful. However, depending on their stature in the organization, you might not want them. Another stratagem here is to systematically target converts, especially early adopters who, if they buy the story and buy into helping make the change, will influence others.

Normative-Reeducative Here the underlying premise is that it is not rational thought that leads to adoption of change. Instead adoption is dependent on feelings and the user’s value systems. The first step in this strategy is getting the user to feel that the current situation as unsatisfactory. The second step is getting him to feel the proposed change is the correct method for fixing this dissatisfaction.

BASIC CHANGE MANAGEMENT STRATEGIES

Of course, this strategy goes beyond personal feelings — it extends to organizational values. The change is going to be adopted only if ‘‘feels right’’ for the corporate culture. It’s important to remember that, in this change management strategy, the assumption is no matter how rational your arguments are, users will adopt changes that are seen to align with either their personal values or the organization’s value. Your change strategy thus has to focus squarely on culture — what people believe about their world, their work, and themselves and the ways in which people behave so as to be consistent with these beliefs. Since culture doesn’t change quickly and certainly not overnight, this is not the strategy of choice in a turnaround situation on short deadlines. Another problem is that an organization’s culture is as much in the grip of the informal organization as it is the formal organization. For this reason, this strategy works only when the relationships between the formal and informal organizations are at least cordial, and preferably harmonious. If they are at odds with one another, this change strategy is not an option. There are, of course, other values to this strategy. Almost all change efforts have both long-term and short-term goals. To some extent, any long-term change strategy will have to incorporate some normative-reeducative actions. Enlisting and involving the informal leaders of the organization and keeping them involved is one such avenue. This is particularly true since the people who lead or influence large or important constituencies and who also hold powerful positions often overlap in formal and informal organizations.

Power-Coercive In this strategy, change is achieved by the application of economic, political, and moral power and institutions to make people accept the new change and move away from the previous version. The underlying assumption is that people are basically compliant and will generally do what they are told or can be made to do. Successful change is based on the exercise of authority and the imposition of sanctions. This can range from the iron hand in the velvet glove to downright brutality — ‘‘My way or the highway.’’ The basic aim here is to decrease people’s options, not increase them. Surprisingly, in many situations, people actually want and will readily accept this approach, particularly when all feel threatened and few know what to do. This is the ‘‘stick’’ side of carrot-and-stick management. Management, for example, may withhold rewards or administer punishments to reach the change goal. This may include coercion or threats to livelihood or pay raises. It may come down to a simple option to either accept and adopt the change or seek employment elsewhere. Whether this is an acceptable strategy depends on time and the seriousness of the threat that not changing means to the organization and if there are no feasible alternatives to produce the change other than forcing the users to submit, or if the costs of allowing users not to accept the change is too high. The problem, of course, is that using coercion can, and most likely will, stiffen resistance to the change.

Environmental-Adaptive The assumption behind this strategy is that while people oppose loss and disruption, they can readily adapt readily to new circumstances. Change is based on building a new organization and gradually transferring people from the old one to the new one. This strategy seeks to shift the burden of change from management and the organization to the rest of the workforce. It exploits their natural adaptive nature and avoids the many complications associated with trying to change people or their culture.

201

202

CHAPTER 7 DEVELOPING A CHANGE MANAGEMENT PROGRAM

Essentially, this is a strategy of self-cannibalization, that is, you set out to eat your own lunch — before someone else does. Also known as ‘‘the die-on-the-vine’’ strategy, this hinges on the commonplace observation that, although people are often quick to oppose change they view as undesirable, they are even quicker to adapt to new environments. Consequently, instead of trying to transform existing organizations, it is often quicker and easier to create a new one and gradually move people from the old one to the new one. Once there, instead of being able to oppose change, they are faced with the prospect of adapting to new circumstances, a feat they manage with great facility. The old organization, then, is left to die on the vine. The major consideration here is the extent of the change. This strategy is best suited for situations where radical, transformative change is called for. For gradual or incremental change, this is not the strategy of choice. Time frames are not a factor. This strategy can work under short time frames or longer ones. However, under short time frames, a key issue will be that of managing what could be explosive growth in the new organization and, if it is not adequately seeded with new folks, the rapid influx of people from the old culture can infuse the new organization with the old culture. Another factor to consider is the availability of suitable people to ‘‘seed’’ the new organization and jump-start its culture. Some can come from other organizations but some can come from the old organization, too. In the old culture can be found rebels, misfits and other nonconformists who are precisely what is needed in the new culture. They must be chosen with care, however, because of politics and the possibility that some will bear grudges against some members of the old culture. Another consideration here is perhaps best termed as ‘‘bad apples’’ (in other words, people from the old organization who simply cannot be allowed into the new one).

London’s Printing Presses: The Environmental-Adaptive Strategy in Action In 1986, Australian tycoon Rupert Murdoch surveyed his London titles — the Sun, Times, and Sunday Times — and didn’t like what he saw. He declared that Fleet Street had ‘‘three times the number of jobs at five times the level of wages’’ as other countries. He also knew that the new Atex typesetting technology could remove typesetters at a stroke, and neuter their powerful unions. Murdoch also knew he would get support from the British government of Margaret Thatcher. A longtime opponent of labor unions, the prime minister could be counted on to support any blow against union power in Britain. He bought a site in Wapping (cheap at the time), telling people it was to be used to produce a new paper, The London Post. In reality, he quietly set about building an entirely new operation. Negotiations on new working practices began, focusing on the Post. The unions were never going to accept the closed shop, flexible working conditions, and no-strike demands that Murdoch made, and he knew it. They took the bait and went out on strike on January 16, 1986. Almost immediately Murdoch informed the employees in the old operation that he had some bad news and some good news. The bad news was that the existing operation was being shut down. Everyone was being fired. The good news was that the new operation had jobs for all of them — but on very different terms. That there are also elements of the Empirical-Rational and Power-Coercive strategies at play here serves to make the point that successful change efforts inevitably involve some mix of these basic change strategies.

SUMMARY

Selecting a Change Management Strategy Despite our nice neat tables and descriptions, there is no such thing as a single change strategy, no such thing as a ‘‘pure’’ strategy, no such thing as a right or wrong strategy. For any given initiative, you are best off using a mix of strategies. Which of the preceding strategies you use in your mix of strategies is a decision affected by a number of factors. Some of the more important ones follow. Degree of change Radical change or transformation argues for an environmental-adaptive strategy (in other words, ‘‘wall off’’ the existing organization, and build a new one instead of trying to transform the old one). Less radical changes argue against this strategy. Degree of resistance Strong resistance argues for a coupling of Power-Coercive and Environmental-Adaptive strategies. Weak resistance or concurrence argues for a combination of Empirical-Rational and Normative-Reeducative strategies. Target population Large populations argue for a mix of all four strategies, something for everyone so to speak. The stakes High stakes argue for a mix of all four strategies. When the stakes are high, nothing can be left to chance. The time frame Short time frames argue for a Power-Coercive strategy. Longer time frames argue for a mix of Empirical-Rational, Normative-Reeducative, and Environmental-Adaptive strategies. Expertise Having available adequate expertise at making change argues for some mix of the strategies outlined above. Not having it available argues for reliance on the Power-Coercive strategy. Dependency This is a classic double-edged sword. If the organization is dependent on its people, management’s ability to command or demand is limited. Conversely, if people are dependent upon the organization, their ability to oppose or resist is limited. (Mutual dependency almost always signals a requirement for some level of negotiation.)

Summary As you’ve seen in this chapter, you manage change pretty much the same way you’d manage anything else of a turbulent, messy, chaotic nature; that is, you don’t really manage it, you grapple with it. It’s more a matter of leadership ability than management skill. So let’s look at what you should be doing. First, accept the fact that no matter what you think, not everyone is going to welcome change and that you’re going to have to be the primary change agent. You want the project to succeed, and you want your users to welcome and make full use of your Exchange Server 2007–based messaging system. Otherwise, why bother? The second thing to do is jump in. You can’t do anything about it from the outside, and as the change agent you can’t simply ignore that the organization, and the users in it will need to be guided through this process. Make sure that your sponsorship is visible. Have the CEO, the management champion, and everyone else in the hierarchy make it clear that failure to change is not an option. As you saw in Chapter 2, your project needs a sponsor — someone with the authority to say ‘‘This is important.’’ If no one in charge says ‘‘Here’s where we’re going,’’ then as the change agent you can’t develop the momentum you need to get your project going and overcome resistance. After all, they reason,

203

204

CHAPTER 7 DEVELOPING A CHANGE MANAGEMENT PROGRAM

the change seems optional. Those who want to get on board do; others wait on the sidelines to see how events unfold. Look for allies and supporter among the users. ‘‘Lone wolves’’ have their uses, but managing change isn’t one of them, and if that’s your normal style you’re going to have to adapt. Look for missionaries among the early adopters. Ask for volunteers. You’ll be surprised at who shows up. You’ll be pleasantly surprised by what they can do. Increase the sense of urgency. Start planning for change implementation by assessing your group’s perceived urgency to break away from the status quo. A high comfort level with current practices doesn’t bode well for a change. Use feedback to keep the change on track. During the transition phase — when new routines are not completely established and the old way still beckons — feedback and acknowledgment can make a critical difference. People want to know whether their actions are making a difference, especially if they are being pushed out of their comfort zone. Credible information and feedback helps keep a change on track. In planning for the new messaging system, you asked the question ‘‘How will we know whether this change is achieving the goal we want?’’ Use feedback and input to answer those questions. Understand the corporate culture. Successful change programs pick up speed and intensity as they cascade down, making it critically important that leaders understand and account for culture and behaviors at each level of the organization. Make sure that you have determined the organization’s and the users’ readiness to change at every level. Identify the core values, beliefs, behaviors, and perceptions of the organization and how they will need to be considered. Sound like a lot to do and manage. It is, and it isn’t. A lot of what we’ve reviewed in this chapter is common sense. It is manageable and more importantly it must be done. There is good news though. Change management is not rocket science; it is a learned skill. Make sure that you understand the theories and underlying psychology that lie behind change. Make sure that you master the skills you need to manage change on both the individual and organizational level. Finally, make sure that you have at least a rudimentary strategy in mind and be ready to adapt it. Finally, be ready to toss out the rule book. Change is messy, and you may have to improvise. In the next chapter, we’ll address one of the most important issues you have to face in a change environment — managing user expectations.

Chapter 8

Managing User Expectations ‘‘Manage other people’s expectations very carefully. If you can’t deliver on all your promises, immediately contact the person who has an expectation of you and level with them.’’ — Mitch Thrower, The Attention Deficit Workplace ‘‘Anger always comes from frustrated expectations.’’ — Elliott Larson ‘‘Disappointment proves that expectations were mistaken.’’ — Mason Cooley In the previous chapter we discussed change management. As mentioned control of the project has now shifted from you the planner and manager to others. The simple, and often overlooked, fact is that your users are now going to control the success of this project. Satisfied users can help support a project over the rough spots. Dissatisfied users can sink your project as surely as a torpedo amidships brought down the USS Indianapolis. As the Exchange Server 2007–based messaging system project manager, you have two things you will need to manage: the development of the system and the perception of the system. In this chapter, I’ll cover one of the most important aspects of perceptions and the level of user satisfaction or dissatisfaction: managing user expectations.

The Power of Expectations Remember the last time you went to see the latest Hollywood blockbuster? Or picked up a new computer? Or went on a first date? Or drove off in a new car? Or took a vacation to a place you’d always wanted to go? Or had root canal? The odds are that before you did any of them there was a good deal of excitement and anticipation on your part. You may have gone over and over in your mind what it was going to be like. You probably thought about how you’d feel. Other people might have told you about similar experiences they’d had that fueled your feelings one way or the other. By the time the day of the event arrived, you were probably pretty excited — or dreading it in the case of the root canal. These emotions were taking hold because you’d developed expectations. The same thing is going on with the users in your organization. From the first day you began work on the Exchange Server 2007–based messaging system, everyone involved — directly or peripherally — has developed expectations. Users in upper management have their expectations. By now, most users throughout the organization, some of whom have only heard that something is going to happen, have begun developing expectations.

206

CHAPTER 8 MANAGING USER EXPECTATIONS

The expectations about the Exchange Server 2007–based messaging system that your users develop are extremely powerful forces. Your users may have low expectations. They approach the whole project with a dismissive wave of the hand and a roll of the eyes that says ‘‘here we go again.’’ If they do and can’t be budged from that position, your project is sunk. No matter what happens, you’ll be in a no-win situation. On the other hand, high expectations are good. People are positive and upbeat and eagerly anticipating what you’re doing — unless of course the expectations are too high, meaning they expect more than the system can deliver. In which case, they will not be happy with the new system, because it does not meet their expectations. They don’t care whether the new system wasn’t designed to allow Voice over IP (VoIP) to the International Space Station, if that was what they were allowed to expect and it isn’t there, the only thing that is important to them is your failure to deliver. A wise person once said the cause of all anger is unmet expectations. If you’re able to meet or exceed your users’ expectations, you’re golden; otherwise, you’re just a yellowish rock. Obviously, if you can manage a user’s expectations so that they are realistically high and consistent with the expected outcome, then not only will the project be a success, you will have earned many valuable allies.

What Are User Expectations? The phrase user expectations is an easily used term that is difficult to define in any meaningful fashion and just as slippery in trying to nail down. Ask a dozen people what ‘‘user expectations’’ means, and you’ll get back 15 different answers. Despite their vague nature, user expectations tend to center around their interpretation of where the project falls relative to criteria or drivers that are important to them: Satisfaction How do the users feel about the project? There are many users who will be involved in and impacted by the project. No matter how it is done, not all users are going to be satisfied with either their relationship with the project or the impact of the project on them and their work. For example, the changes being implemented by the project may lead to a substantial de-skilling, loss of control, or other negatives related to the jobs of some people. It would be na¨ıve to expect these people to be satisfied with the results of the project. It is critical for the you to determine which users must be satisfied at the end of the project and to identify those who will be likely be unsatisfied at the end. Both these groups of users must be communicated with, and different strategies are used for each group. Objectives and requirements What do the users want from the project? Here again the Exchange Server 2007–based messaging system will meet some objectives and requirement and fail to meet others. You will need to clearly define which is which and to assure users know which side their needs will fall. Resource consumption How much are the users prepared to pay in terms of resources (typically time to become familiar with the Exchange Server 2007–based messaging system for most)? This includes people, equipment, accommodation, and overhead costs. Users tend to have expectations based on the amount of resources they are expected to devote to a project. Deadlines When do the users want it? Users will have a clear set of expectations when something will be ready. Failure to meet deadlines or time frames has been used consistently in the past to fairly or unfairly condemn projects as failures.

THE POWER OF EXPECTATIONS

Added-value criteria What does this do for me? This is probably the most important component of expectations. Cost-benefit analysis is only one component. Users expect to see evidence that the change will benefit them in both tangible and intangible ways. Quality criteria How well does the project have to be built? Users will have expectations about the quality in a product. Just as the driver of new Mercedes does not expect to hear a rattle under the hood, while it might be acceptable to the driver of 20-year-old Lancer, quality expectations will have a major role in the overall outlook.

Sources of Expectations You may be wondering where users are getting their expectations from about your Exchange Server 2007–based messaging system project. It’s also important that you know where they will get other expectations during the implementation and life cycle of the Exchange Server 2007–based messaging system. There are many sources of expectations. As the project was being developed and you were gathering business requirements, as described in Chapter 2, you would have had many opportunities to describe the Exchange Server 2007–based messaging system project to small group of users and key stakeholders. During these meetings you would have described the project in a positive light and touched on some of its features and advantages. This would have been once source of expectation. These individuals would, in turn, have fueled expectations in other users who were not familiar with the project. Most of them probably would have been positive, but almost certainly there would have been the occasional doom-and-gloomer. This information, and the implicit expectations it carried, would have continued to cycle through the corporate grapevine. You ignore this sort of informal backchannel means of communication at your peril. Although nothing can exceed the speed of light, news over the grapevine comes close. The project sponsor will discuss the planned Exchange Server 2007–based messaging system with the staff and subordinates, and this information, and its implications for the user expectations will be circulating as well. Experience has shown that members of upper management are also keen to discuss new projects, often before their formal release and their perceptions and information become part of the body of user expectations. Users may have been through a similar implementation before. It may have turned out well. It may have turned out badly. In either case, these previous experiences define and shape present expectations. Where the experience is not direct, users may already have been exposed to prejudices for and against the project based on other people’s experiences.

Effect of Unmet Expectations As mentioned earlier, the overall impact of user expectations can make or break your project. Many studies have shown that there is a cause-and-effect relationship between user expectations and project failure. This is not to say that a poorly designed system can’t fail to meet expectations and hence fail all on its own. But often, when users have been able to develop unrealistic expectations without regard for constraints of budget, time, manpower, and so on, the best system that developers could produce will go unused and disliked. Why? The best system doesn’t meet the user’s high expectations. Therefore, the user subjectively considers the system a failure and makes an objective decision not to use it. In this sort of case, the user’s expectations were actually the cause of the failure, not the other way around.

207

208

CHAPTER 8 MANAGING USER EXPECTATIONS

Awareness of this fact has been growing over the past decade. A 2001 article in the Cutter IT Journal by consultant Jeff Gainer stated ‘‘Expectations management is the key to successful projects. . . The difference is the focus on managing the customer, rather than the product or development team.’’ Remember, there is a lot more at stake here than simply stilling the rumbling of a few (or not so few) malcontents who don’t recognize the brilliance and benefits of your new system. During the Industrial Revolution, engineers in France introduced power looms into the textile industry of Paris. The new machines were a vast improvement over the previous system of creating fabric, but the engineers and project developers never considered the role or expectations of the laborers who were the ones using the new system. Resentment grew, and the workers soon realized that the looms could be damaged by an angry or disgruntled worker tossing a wooden shoe or clog into the machinery, effectively clogging the looms. The French word for wooden shoe was sabot, which in turn led to the word sabotage and the phrase ‘‘clogging the machinery.’’ Your goal then is for there to be an alignment between what the user expects your new Exchange Server 2007–based messaging system to do and what it is capable of doing. You want the user’s expectations to be high enough to sustain support, but not so high as to be unrealistic. You want to avoid low expectations since these usually ensure that no matter what the final outcomes, those users will invariably be disappointed. It’s a balancing act, and Figure 8.1 shows where you’d ultimately like to have every one on the expectation balance beam.

Figure 8.1 User Expectations

User expectations balance beam Low

High

How do you get there? The expectations belong to the user, so the only way you can really shape them is to get to know the user, understand the user, and most importantly, communicate with user as a colleague, mentor, and friend.

Understanding Users Before we start this section, let me state that if you have the opinion that users are some sort of necessary evil that should be condescended to, you don’t need to read any further. That attitude alone will do more than anything to ensure that your project meets maximum resistance, plummeting morale, intended or unintended sabotage, and just about anything else necessary to make your project fail. Remember, no matter what you think, believe, or feel, in the ultimate analysis it is the users, not you, who are going to determine the success or failure of your project. If users aren’t satisfied with the finished product, then the project isn’t really a success. The rumbling of discontent will drown out the sweet purr of your Exchange Server 2007–based messaging system even if it runs flawlessly, is more secure than Fort Knox, and is an IT work of art. They simply won’t use it, and if forced to they won’t use it to its full potential, thus undoing all of your efforts. It’s not what you want to have happen, is it? The first thing you need to do is to think of your users as distinct individuals, people who are neither computers nor merely computer users. For you, of course, IT and its tools are part of your daily life and its center. For users, the tendency is to look at computer technology as a tool, not an end in itself. This means that you have to take into account their thoughts, ideas, emotions, and all the other things that make them, and you, human.

UNDERSTANDING USERS

There is a big difference between where the user is coming from and where you are coming from. The key to guiding and shaping user expectations is to understand the user’s perspective; in other words, put yourself in their shoes. First, users have a different focus. They are concerned with what they see and use, and are not particularly interested in what happens behind the scenes. They are not really impressed by the fact that your data stores are elegantly configured and tweaked to perfection. On the other hand, they can have strong feelings about the exact shade of blue you use for the message frame. Next, users can sometimes be too easy to please. This is not to make light of their expectations, but rather to point out that because their focus is on the interface, relatively minor cosmetic changes can enhance their faith in the project. They might thus miss a major point that you will need to direct them to. In addition, users will often say, ‘‘But I saw this other program and it does this, that and the other. . . ’’ Closely tied to this problem is the comment that ‘‘If my 13 year old son can do/create the same, how come you take so long and charge so much?’’ There is no real solution to this frustration, beyond explaining as simply as possible why a mailbox that uses Hotmail is not the same as a fully functional Exchange Server 2007–based messaging system. Sometimes much patience is required.

Communicating with Users As we’ve already seen, managing user expectations is a key part of making the project run as smoothly as possible. Properly conceived, communications can be used to orchestrate the relationship between you, the user and the Exchange Server 2007–based messaging system. As with any relationship, it will not work without good communication. Good communication needn’t be a mystery or even that difficult. The purpose of all your communications is to sweep away the mystery and uncertainty among users through open, honest, and frequent communication. Because their number is large and their points of departure nearly infinite, you will never be able to totally control users’ experience with your system. So, the best user management weapon is information. Give users enough information to manage their experience. This information will help them make their own judgments. It will also help them help you through feedback and testing. Don’t make the mistake of trying to manipulate your users into a particular point of view or position. Far too often, the more you try to manipulate users, the harder they will rally against you. The harder you try to twist their perception, the more they will make negative comments. The power of control rests with the users, not you and your project. Remember, at the end of the day, even the powerful oak can be felled by the unseen wind. The bottom line of course is simple. You need to communicate with your users, management, staff, and colleagues. Communication can take many forms including: ◆ One-on-one communications ◆ Email ◆ Phone calls ◆ Group meetings ◆ Newsletters ◆ Presentations

209

210

CHAPTER 8 MANAGING USER EXPECTATIONS

How to Communicate Obviously, if you’ve gone this far into your Exchange Server 2007–based messaging system planning and haven’t communicated with the users in general, you’ve already created a huge information void within your organization. If considerable time has gone by without a peep about the project, people will start making assumptions — mostly negative (‘‘they don’t know what they’re doing’’ or ‘‘this project will never get off the ground’’) to fill the void. Even if rumors don’t start flying, you’ve missed a good opportunity to keep people focused on and excited about the Exchange Server 2007–based messaging system project. Remember, a large portion of project success is defined by the perception of success by the people involved. Perception is greatly influenced by communication, so one of the first things you should do is to communicate frequently even if you don’t know all the details. Don’t fall into the trap of not communicating because there are still too many unknowns or open variables. Lots of people don’t like saying ‘‘I don’t know,’’ and techies may be some of the most reluctant. It’s a dangerous trap to fall into. The objection is ‘‘If I don’t know what’s going on yet, what should I communicate?’’ It’s not as difficult as many people make it, and there are plenty of ways of saying ‘‘I don’t know’’ that don’t sound quite so clueless. A simple email letting people know that you’re in the planning stages of the Exchange Server 2007–based messaging system project and that you expect to have more detailed announcements in the coming weeks might be all it takes. For instance, you could say ‘‘We are in the planning stages of the Exchange Server 2007–based messaging system project. We expect to have a detailed plan available for review by next Friday. In the meantime, you may be hearing from some of our project team members as they gather additional data to nail down the details of this project. Thanks for your cooperation, and we’ll keep you posted as things move forward.’’ What have you really said? Basically that you don’t know enough to tell anybody anything, but you will by next Friday. That’s a long way around ‘‘I don’t know,’’ but it provides project visibility and lets people know you are moving forward. There’s a saying in project management that ‘‘no news is no news’’ (as opposed to the saying ‘‘no news is good news’’). No news means that you have no information and when you’re working on a project that’s in the planning stages, it also means that your project visibility slowly (or sometimes quickly) fades into the background. This might mean that you have difficulty securing promised resources because managers have forgotten about your project. It might mean that the expenditures are going to be delayed because purchasing forgot to take the necessary steps to procure needed resources. There are many more reasons to keep your project visible, so communicate regularly during the definition and planning stages because project work is not yet visible to the rest of the organization. From this point forward, you should have your communication plans in place for your various stakeholders and the users, and you should begin implementing those plans. From the planning phase through project completion, you should communicate regularly, at appropriate intervals for each audience. This is one area that many IT project managers fail in, and it’s a huge opportunity to influence the perception of the project. With a bit of planning and practice, you can improve your project communication skills, and the payoff is almost always far greater than the investment. Your communications plans and activities should include the following audiences: ◆ Project sponsor ◆ Project team ◆ Stakeholders ◆ Users ◆ Management

UNDERSTANDING USERS

There are various checkpoints you may want to use for your project communications. Sometimes project phases are good checkpoints, other times you might want to use project milestones. Whatever checkpoints you use, make sure that you identify them and use them. If you have someone on your IT project team who is a good communicator, you may delegate project communications planning and implementation to this team member. Together decide on your communication checkpoints and have a team member own that schedule. That means updating the schedule as the project schedule changes and communicating some of those changes to project stakeholders as well. If you feel like you’re overcommunicating, that’s probably good since most IT project managers undercommunicate outside of their immediate IT environment. An email everyday is probably overkill but an email every week or two may be quite appropriate. Table 8.1 outlines one method of managing communications; you may choose to use other methods suitable to your project and organization. As with any task, if the task doesn’t have an owner, it probably won’t get done, so make sure that you ask for a volunteer or assign these tasks to someone on the IT project team and ensure that person takes ownership of these crucial tasks.

Table 8.1:

Sample Communication Plan Overview

Target Audience

Frequency

Method

Owner

Project team

Daily

Email updates

Project team, as needed

Project sponsor

Weekly

Email updates (submit progress report as part of project processes)

Project Manager

Unit Directors

Biweekly overview, monthly detail

Biweekly overview via email, monthly presentation at director’s meeting

Project Manager

Project Deployment Team

Monthly overview until 60 days from project completion, then weekly

Email updates, then weekly meetings

Project Communication Lead (person from IT project team to fill this role)

Users, Stakeholders, or Company-wide

Every two months until project completion

Update in company newsletter, targeted email to user groups

Project Communication Lead

This may seem like overkill, but keeping users updated regarding the status of the project means that they will rest easier, they will not be surprised by outcomes, and they will be more convinced that the project is being well managed; as a result, users’ attitudes toward the project will be better.

What Should Be Communicated? What should you communicate? In general, reports and updates should list accomplishments, issues, and metrics. Accomplishments can be mundane but essential such as getting the team email access. Issues are potential obstacles to the project; this is where you warn users that

211

212

CHAPTER 8 MANAGING USER EXPECTATIONS

something bad might happen. The metrics section is perhaps the most crucial section of the report. It is important to have objective measures for evaluating the progress of the project. Making goals objectively measurable goes along with the idea of documenting to manage expectations. If users know what concrete outcomes to expect, their expectations will be more realistic. When they see concrete results, they will be more satisfied. Measurements should address business issues, not merely technical ones. Like educating users (discussed in the next section), communicating with users should be done whenever possible. The only real caution is not to take up excessive amounts of users’ time. Communications should be brief and may simply feature bullet-point lists. Such a document is take it or leave it for the user; that is, they can decide how much time to devote to reading the documents. Meeting weekly for an hour to tell users how things are going might be excessive. Likewise, when gathering information, use the most efficient means possible. One last very important aspect of your communications with user is to be honest and forthright. Whenever you fail, and whenever you fall short of user expectations, tell users the truth. It is rare that telling the truth will harm you. Sincerity and integrity carry a lot of weight.

Effective Communication Tips I have found though that there are ways of helping yourself when it comes to sending a message that will also have to dissuade people from expectations and positions they have developed. Following these guidelines will help make it less of a painful process for you and the user you are trying to convince to adopt another set of expectations. Be comfortable speaking in front of a group and managing a meeting. Some folks just lack confidence when addressing more than a handful of people. While they may be brilliant one on one, for whatever reasons, working in front of a group makes them nervous. The remedy is knowledge and experience: knowledge, regarding how to manage a meeting, read people, and communicate effectively; and experience, because the process has become more familiar the more times you’ve been through it. This is definitely a case where practice can help to make perfect. Know the facts. The more knowledge you have regarding the issue, the better prepared you are to defend the facts of the project and cut through the BS. Believe in yourself. If you doubt yourself, you are less likely to show a certainty and conviction in your expectations before someone else’s. Don’t be surprised to be pressed in public, particularly if the facts you are presenting run counter to existing expectations. Don’t take it personally. Try to remain as emotionally detached as you can. It is highly unlikely that anyone challenging your position woke up that morning with the intention making you uncomfortable or calling you an idiot. Remain resolute and passionate about your position. Remember that the minute you react emotionally you diminish your effectiveness and lower your confidence, as well as impair your ability to think rationally. Understand your position relative to others. Realize that who you are is almost as important as what you are saying. You are the project manager (or his designee), and the weight of your statement is dependent on your relative position of authority/power and your persuasiveness. You can be in a position of power and your statement will have the weight of authority, or you can have little authority but be very persuasive and have an equally weighty one. Conversely, you can have the authority but never exercise it; thus, your statement becomes insignificant. You can also have little authority — and act like it — and never be heard.

EDUCATING USERS

Educating Users In addition to communicating regularly with users you are also going to have to take time to educate them. You are implementing a new Exchange Server 2007–based messaging system, a fact that has been announced. Expectations started to form the moment users heard about your new project. This is normal, but as we’ve already seen the sources of that information originally come from sources that are flawed — either the user’s past experience or information derived second hand from those in the know or those who know someone who knows someone. One of the key things you have to do therefore is to educate (or reeducate) your users so that they will base their expectation not on the flawed information but on actual fact. When do you start educating users? Immediately, if not sooner. You want to start the education process before your users have to time to develop and become set in their expectations. The communications vehicles described above are the perfect tools. What should you educate users about? What they can expect to happen during and after the project? How will the Exchange Server 2007–based messaging system work? What new features there will be? One way to accomplish this is by creating prototypes.

Prototyping Prototyping means building a working model of the system. A prototype doesn’t do everything the final system will do. Rather, it simulates some of the essential features. For example, the user might be able to see how the interface will look with regards to screen layout, menus, buttons, and so on. Maybe all of the buttons don’t work. But the essence of the system is represented. The prototype can be a great tool for zeroing in on users’ needs. Prototyping has many benefits. It accommodates the communication style of the user instead of the developer. The prototype gives the user and the developer something concrete to talk about, greatly alleviating communication problems and misunderstanding. A prototype is much easier for a user to evaluate than a requirements definition because it is closer to their everyday experience: Instead of users being disappointed at the end of a project when the system doesn’t do what it should, they are excited at being involved with developing something new. In fact it is often the case that users can’t wait to see a prototype. With regard to cost, while it may seem, on the face of it, to be inefficient and expensive, prototyping can help guard against something much more expensive — a system that the users will not use. Research has shown that prototyping leads to better designs, better matches with user needs, and improved maintainability. The benefits of prototyping are clear, but it is not necessarily a silver bullet. Protoyping works best when the system is not batch processing in nature and helps most with developing a good user/machine interface. Operational support and record management systems are good candidates, while heavily algorithmic systems and those for decision support and ad hoc retrieval and analysis are not; in other words, good candidates ‘‘are the business’’ not ‘‘about the business.’’ Because of the time and resources necessary, prototyping is not recommended for ‘‘crash’’ projects. The characteristics of the users are important when deciding whether to use prototyping. Although satisfying, prototyping requires users to devote substantial resources to refining the model, a commitment they need to be willing to make on their own. Finally, the users must be willing and able to make decisions.

Training Traditional training classes are probably the most effective means for training users about the new Exchange Server 2007–based messaging system. However, as you’ll quickly discover there

213

214

CHAPTER 8 MANAGING USER EXPECTATIONS

probably isn’t a ready made class for your situation and even if there was you’d be better off customizing a training. If your new Exchange Server 2007–based messaging system is an upgrade of an existing Exchange 2003 or earlier system then you can assume safely that users are familiar with the basics of operating the system. If this is a new implementation, then you will need to establish who is responsible for software training. If you are responsible for developing an education plan for the users (something that is spelled out in the scope of work), you will need to have the answer to each of these two questions for each user: ◆ What does the user know now? ◆ What does the user need to know to optimally use the system? Knowing what the user needs to know to optimally use the Exchange Server 2007–based messaging system will help you determine the best classes and instruction for the user. Being aware of their current level of education and training keeps you from wasting their time by sending them to classes where they won’t learn anything (therefore adding to frustration and negative perceptions about the project) and wasting their time and the project’s money. It’s not that difficult to determine what the users need to know to optimally use the system. If the Exchange Server 2007–based messaging system allows users at different levels to use different technologies you may have to customize that for different employees or groups of employees. In some cases, you may be able to use existing classes at a local training facility. In other instances, the best option might be to create a customized class. Determining whether to use standard or custom training is going to be a purely ad hoc decision based on a number of local factors. Establishing what the user knows can be accomplished easily through the use of a selfassessment or prerequisite testing system. An assessment test consists typically of 20–50 questions that users complete, typically online. If you decide to create a customized training class, you will need to create custom courseware to match. Currently, there is an increasingly large number of sophisticated software to assist you in this task. The caveat, of course, is that developing customized software is a lengthy and time-consuming process. Typically, you will need to include the following: ◆ Timed modules ◆ Assessment questions with answers ◆ A student edition of the courseware ◆ A teacher edition of the courseware ◆ Hands-on labs and other material ◆ Evaluation forms ◆ User guides You may opt to use a commercial firm rather than in-house training for development of custom courseware if you do not have the resources to do so internally. Of course, this option would have been included in your project plan! You also want to make sure that the students are getting what you and they want to get out the training. Students should be given a postassessment test to allow them to demonstrate that they have mastered the material. Obviously, the test should cover the main topics in the class. Analysis of the tests will also help you identify any weak spots in either training or coverage.

EDUCATING USERS

Another popular tool is the student completed satisfaction survey. This is a generic survey that asks basic questions about the instructor, facilities, material, and so forth. Analysis of these surveys will help you make necessary improvement to the classroom, personnel, materials, and so on. Finally, when developing user guides, it’s always a good idea to develop documents that can assist users in showing them how to do old tasks with the new system. There are too many features to cover them all, however, a survey can provide a list of the most common tasks.

VAK Learning Styles The visual-audio-kisthethetic (VAK) learning style is a neurolinguistic programming (NLP) model that analyzes how the human mind processes information and learns. The argument is that all information is processed through our senses, and that three are used primarily for learning: vision, auditory, and kinesthetic (movement). Learners use all three to receive information. However, one or more of these receiving styles is normally dominant. This dominant style defines the best way for a person to learn new information by filtering what is to be learned. This style may not always to be the same for different tasks. The learner may prefer one style of learning for one task and a combination of others for another task. Classically, our learning style is forced upon us through life like this: In grades kindergarten to third, new information is presented to us kinesthetically; grades 4 to 8 are visually presented; while from grades 9 to college and on into the business learning environment, information is presented to us in an auditory way via lectures. Trainers should present information using all three styles. This engages all learners, no matter what the preferred style is. It also allows a learner to be presented with the other two methods. Remember that a preference for one style does not negate the other two. On the contrary they support the learning process by reinforcing the material. Here are some hints for recognizing and implementing the three styles. ◆

◆

Auditory learners often talk to themselves. They also may move their lips and read out loud. They may have difficulty with reading and writing tasks. They often do better talking to a colleague or a tape recorder and hearing what was said. To integrate this style into the learning environment, begin new material with a brief explanation of what is coming. Conclude with a summary of what has been covered. This is the old adage of ‘‘tell them what they are going to lean, teach them, and tell them what they have learned.’’ ◆

Use the Socratic method of lecturing by questioning learners to draw as much information from them as possible, and then fill in the gaps with your own expertise.

◆

Include auditory activities, such as brainstorming, buzz groups, or Jeopardy.

◆

Leave plenty of time to debrief activities. This allows them to make connections of what they leaned and how it applies to their situation.

◆

Have the learners verbalize the questions.

◆

Develop an internal dialogue between yourself and the learners.

Visual learners have two subchannels, linguistic and spatial. Learners who are visual-linguistic like to learn through written language, such as reading and writing tasks. They remember what has been written down, even if they do not read it more than once. They like to write down directions and pay better attention to lectures if they watch them. Learners who are

215

216

CHAPTER 8 MANAGING USER EXPECTATIONS

visual-spatial usually have difficulty with written language and do better with charts, demonstrations, videos, and other visual materials. They easily visualize faces and places by using their imagination and seldom get lost in new surroundings. To integrate this style into the learning environment, do the following:

◆

◆

Use graphs, charts, illustrations, or other visual aids.

◆

Include outlines, agendas, handouts, and so on for reading and taking notes.

◆

Include plenty of content in handouts to reread after the learning session.

◆

Leave white space in handouts for note taking.

◆

Invite questions to help them stay alert in auditory environments.

◆

Post flip charts to show what will come and what has been presented.

◆

Emphasize key points to cue when to takes notes.

◆

Eliminate potential distractions.

◆

Supplement textual information with illustrations whenever possible.

◆

Have them draw pictures in the margins.

◆

Show diagrams and then explain them.

◆

Have the learners envision the topic or have them act out the subject matter.

Kinesthetic learners do best while touching and moving. This type of learning also has two subchannels: kinesthetic (movement) and tactile (touch). Learners tend to lose concentration if there is little or no external stimulation or movement. When listening to lectures they may want to take notes. When reading, they like to scan the material first and then focus in on the details (get the big picture first). They typically use color highlighters and take notes by drawing pictures, diagrams, or doodling. To integrate this style into the learning environment: ◆

Use activities that get the learners up and moving.

◆

Play music, when appropriate, during activities.

◆

Use colored markers to emphasize key points on flip charts or white boards.

◆

Give frequent stretch breaks (brain breaks).

◆

Provide toys such as Koosh balls and Play-Dough to give them something to do with their hands.

◆

To highlight a point, provide gum, candy, scents, and so on, which provides a cross-link of scent (aroma) to the topic at hand (scent can be a powerful cue).

◆

Provide highlighters, colored pens, and/or pencils.

◆

Guide learners through a visualization of complex tasks.

◆

Have them transfer information from the text to another medium such as a keyboard or a tablet.

EDUCATING USERS

Service-Level Agreements As discussed in Chapter 2, a service-level agreement (SLA) is a formal negotiated agreement between two parties. Traditionally, it is used to create a contract customers and their service provider, or in this case between the user and the project on behalf of the IT department. This can be a useful tool to ensure that users trust the system, and that the system responds to the user’s problems. It also has the added benefit of helping manage user expectations by defining the limits of the system, making both user and system accountable to one another. The typical SLA defines the common understanding about services, priorities, responsibilities, guarantees, and so on, with the main purpose being to agree on the level of service. An SLA may specify the levels of availability, serviceability, performance, operation, or other attributes of the service such as billing, and even penalties in the case of violation of the SLA. As you can see, the SLA effectively sets user expectations. Say, for example, that your SLA specifies that Unified Messaging (UM) server downtime will not exceed 30 minutes in a 24-hour period. Users then know that they can assume that any disruption in services is temporary and will be resolved within an hour. You have deftly moved from having them assume that an ideal ‘‘never down’’ state will exist to an expectation that is both reasonable and measurable. Another advantage of the SLA is that it provides a way for users and your project team to open a dialogue and communicate better. Users will have to turn to you when there is a problem and be assured of an answer and a response. It also helps you resolve problems, minimize friction, and keep discontent from brewing. When users, annoyed that he UM server was down for 15 minutes when they needed it on a priority basis, start complaining that the system does not perform as reliably as promised, you can review it with them to see whether or not the system is meeting the agreed to availability target. The problem with this approach, of course, is that it can be overly legalistic and also ends up creating unexpected friction between users and IT personnel. The approach can come across something like this. We in IT need to make sure we document what we’re doing. Then we need to get the user to agree with what we wrote down. That way we’re covered if the user complains. This vaguely antagonistic approach seems extreme when the IT department and the users work for the same organization. In fact, protecting the IT department from any claim of negligence on an official level, while ignoring the attitudes of the users, is inherently antagonistic. You need to make sure that you avoid anything that equates managing user expectations with keeping users quiet. One pitfall of an SLA, or rather the way its applied, is that when used as a club, users quickly develop negative judgments about IT precisely because they think that the IT is treating them as adversaries. Another serious problem with SLAs is that users don’t always understand them. Sometimes the users will not even sign off one because they don’t care for the way it has been used as a bludgeon. Obviously, if the SLA is not helping the users, if it is seen as tool for the IT department to shield itself from complaints, if there is no signoff is obtained, then it serves no real purpose. The best way to think of the SLA and how to use it is not as a bludgeon or a means of stifling complaints. Think of it as both a communications tool to encourage dialogue, meaningful dialogue, between IT and the users; and as a conflict resolution tool. Otherwise, it does not serve the purpose of managing user expectations.

Quick Guide to Managing Expectations Much of what I’ve been discussing in this chapter, and throughout this book, is tied directly or indirectly to managing expectations. Let’s take a quick look at the key steps to managing expectations. You can follow along using Figure 8.2.

217

218

CHAPTER 8 MANAGING USER EXPECTATIONS

Figure 8.2 Steps for managing expectations

Involve customers / stakeholders in defining needs and wants Celebrate met expectations (interim successes)

Understand the values of customers/stakeholder groups through communications

Communicate changes Assess risks and address them accordingly

Realign or change expectations

Establish approach to “market” the project

Measure performance

Set realistic expectations on budget, scope, and benchmarks

Assure that processes are credible and open

Communicate realistic expectations and do not create false hopes

Follow through on commitments

1. As you saw in Chapter 2, your first step is to involve customers, stakeholders, and other affected individuals in defining the needs and wants they require your messaging system to address.

2. Use the communication process not only to discuss the new system but also to help you understand and appreciate the values of the groups.

3. Assess risks and address them accordingly. 4. Determine how you’re going to market the project both to management and to the users. 5. Set realistic expectations. 6. Communicate realistic expectations. Never ever play the lowering expectations game, and most assuredly never promise anything you’re not going to deliver. Once your credibility is questioned you’re finished.

7. Make sure that you keep your commitments. If you promised to do something, you must keep that promise.

8. Make sure to keep your processes open. 9. Assess whether or not the new messaging system is delivering on its promise. Determine and evaluate whether people feel that the expectations you presented are being met.

10. If they aren’t, you’re going to have to realign or change expectations.

SUMMARY

11. If you make changes to the expectations (sometimes euphemistically called realignment) communicate them.

12. As expectations are met — take time to celebrate!

Summary Are there any ‘‘right’’ or ‘‘better’’ strategies for managing user expectations? By now, it should be clear that some strategies are more appropriate for certain situations, although most projects will call for some of each of these strategies. Documenting requirements is always a part of the system development process but use the documents as contracts only when there is a genuine contractual relationship between parties; even then, the contract should not be the only method for managing expectations. Educate users on the systems development process, the constraints under which the IT department operates, and especially on the impact of changes on the budget and schedule. Strive to communicate well with users continually throughout the development process, but do not let the process of education or communication take up too much of the users’ time (or your own). Utilize prototyping where appropriate. A careful mix of these strategies will ensure users know exactly what to expect from their information systems.

219

Chapter 9

Setting Up a Change Request Process Let all things be done decently and in order. — I Corinthians 14:40 It’s not the strongest species that survive, nor the most intelligent, but the most responsive to change. — Charles Darwin In the previous chapter, I talked about change management as the tools and techniques you use to convince an organization and the personnel in it to accept, adapt, and adopt the proposed changes that your project will be bringing about. However, it’s not time to rest on your laurels just yet. There are changes you are going to have deal with that are more than just attitudinal. When you completed planning the Exchange Server 2007–based messaging system and had it approved by the stakeholders and corporate management, you may have had a momentary sense of completion. Of course, you probably quickly realized that this wasn’t true — the plan wasn’t really done yet. Within seconds, users and management started requesting changes and revisions to your planned project. It’s easy to look at these change requests as a distraction, a nuisance, or just a detriment to your system, but they are actually a part of a project’s normal development. When handled properly, they can either help perfect the product vision or reinforce what you were already planning to do. In this chapter, you’ll learn about revision management and how to use it to create a process or methodology that ensures all changes are appropriate, are timely, and are made with the highest levels of certainty to achieve good results. There is one major caveat that I want to bring to your attention. Because of the nature of writing books, I’ve had to compartmentalize a number of processes, including gathering requirements, planning, and change management, into separate chapters that are in linear order. This is not the way the real world operates. As you have realized, most of these activities usually run in parallel, almost simultaneously, impacting each other as they happen and interact. Now you will have to add designing and using a revision management process as well. You should aim to have a completed revision management system (which we’ll call the change request process) as soon as you are ready to discuss the initial design and begin prototyping. Why? Typically, as soon as you show management or other interested parties what you think would be a good idea for a new messaging system, someone will suggest a change. Requests for changes will continue throughout the planning phase and long after the initial implementation. In fact, change requests will be part of the system’s environment as long as the system lasts. In this chapter, I’ll talk about how to manage those changes effectively so they benefit the project rather than hamper it.

222

CHAPTER 9 SETTING UP A CHANGE REQUEST PROCESS

Note Change request processing is often referred to as change management. I am using the former term here to distinguish it from change management as it was used in the previous chapter. In reality, the two terms are commonly, if confusingly, used interchangeably, with their meanings dependent on the context.

What Is the Change Request Process? Managing change, as you will see, requires a very deliberate and disciplined effort. As you’ve probably seen in most things, you simply can’t change something without forethought. For example, suppose that you are in the process of building a house and your spouse wants you to add a pool in the backyard. No matter how much you want to please your significant other, you simply can’t tell the contractor to make a pool magically appear in the backyard. Like all changes, you need to take a series of rigorous steps before you can start digging holes and ordering a new bathing suit. There needs to be a full investigation of the proposed change, and you need to do the following: ◆ Verify that the change is necessary and beneficial to the house project. ◆ Confirm that the change is allowed; for example, your neighborhood may have rules that ban pools. ◆ Identify other changes that might result. For example, you will need a fence around the pool. There are ongoing pool care expenses. The yard will be smaller. ◆ Evaluate its impact on the budget for the house. Do you have the money? If not, will you need to make changes to other plans? ◆ Evaluate its impact on the project schedule. Will adding the pool change the completion date? Will this affect your deadline to move out of your other dwelling? ◆ Will the change impact on the quality of the project? Does adding this pool make sense, and is it consistent with the quality elsewhere in the house overall? Then, and only after ensuring that you and your spouse are in agreement on not only the change, but all of the other aspects of making the change, should you make it. The change request process is the series of steps that guarantee every change requested is handled and assessed properly. This includes effective planning, implementation, and post-event analysis of changes to a system.

Building a Change Request Process Change requests can come from anywhere — team members, users, potential users, stakeholders, management, and vendors. They can also be mandated by sudden changes in regulatory or business requirements. Change requests usually have to do with a discrepancy in what is planned for the product of the project or things that might have been overlooked. Once the system is deployed, changes will most commonly arise from the identification of the need for a fix or an enhancement to the Exchange Server 2007–based messaging system. Requested changes or revisions can range from simple to complex, so your process will need to accommodate both types. It should make it easy for simple, quick changes to be made (for

WHAT IS THE CHANGE REQUEST PROCESS?

example, adding a mailbox for a new employee). On the other hand, it must also be powerful enough to properly capture and manage complex changes. This balance can be difficult to achieve, but it is necessary. If the process is too complex, people, including both the project and the post-project support teams, will find ways to make simple changes that circumvent the revision management process. The result is a loss of control, communication, and a portion of your audit trail. On the other hand, if there is not enough rigor to the change request process, you might end up with a system where changes are not properly controlled, but instead bypass critical reviews, thus causing widespread deleterious effects across the system. To avoid this, you want to create a change request process that does the following: ◆ Requires the logging of all changes made to the environment ◆ Ensures changes are properly controlled by an authorization process ◆ Ensures all changes can be traced to the person who initiated the change request and the person or persons who made the change ◆ Establishes a method for review (usually in an escalating manner) by management and priorities established based on business or technical needs ◆ Ensures testing and verification of the requested change before it is fully implemented ◆ Provides a uniform system to ensure that all change requests are evaluated properly against the same set of criteria ◆ Ensures that change requests and change implementations are properly documented ◆ Ensures that changes have a backout plan in case their implementation proves to be in error One key aspect you shouldn’t overlook is making certain that the change request process is widely advertised and understood. You must make sure that everyone — management, your project team, IT, and users are aware of the process and how to use it to request change. Most importantly, you must be prepared to insist upon a rigorous adherence to the process and be prepared to deal harshly with those who circumvent it.

Determinants of the Change Request Process Before we turn to examining the change request process itself, let’s look at what factors you’ll be using to determine what to do about a change request in general. Traditionally, the three most important considerations in project management, especially during a project’s development phase, are the ‘‘triple constraints’’ of time, cost, and scope — sometimes described as time, budget, and desired outcome, as shown in Figure 9.1. The change request process is primarily a control system that makes sure that the scope of a project, its schedule, and its budget all stay within the agreed-to confines of the project plan as authorized by management. Any change request that materially impacts these should require a rigorous review and analysis. The change request process does not rule out alterations that have an impact on these three, but it does dictate a strict process is adhered to. Obviously, if a change doesn’t have an impact on the triple constraints, that doesn’t mean the change is automatically approved or that it doesn’t require a review. It still must be assessed and analyzed, though the decision whether to implement the change might be made at a relatively lower level.

223

224

CHAPTER 9 SETTING UP A CHANGE REQUEST PROCESS

Figure 9.1 The triple constraints

Target

Scope goal

Cost goal

Time goal

Who’s in Charge? You may be wondering who is in charge of the change request process. That depends primarily on the size of your project and the nature of your organization. Usually as project manager, you will have little authority to make major changes to the approved project. You may have a formal structure that includes a separate change control board comprising the corporate sponsor as well as key stakeholders, as shown in Figure 9.2. As a project manger in this type of setting, you will have a set of guidelines on which changes — mostly those impacting one or more of the triple constraints — need to be referred to the board. You may be authorized to decide whether to follow through on certain change requests without referring them to the board. Because this sort of structure usually exists in large projects, you will also have a project team to assist with processing and managing change requests, as well as carrying out the actual project.

Figure 9.2 Executive Sponsor and Chairman of CCB

A complex change control hierarchy

Project Manager

Chief Financial Officer

Director of Training

Chief Operating Officer

Chief Information Officer

BUILDING A CHANGE REQUEST PROCESS

In small or medium enterprises, or with small projects, there may be less formality. Decisions regarding change requests may be made by the corporate sponsor, there may or may not be a board, and you may have considerable leeway as project manager. In either event, it is unlikely that you will be authorized to make any changes that impact the triple constraints without management review.

Note Once the messaging system is in place and the deployment and implementation phase is completed, you will also need to set up a system and structure for change requests made throughout the life of the project.

Whichever type of organization you have is irrelevant to the idea that change requests must be dealt with and managed in a structured, organized fashion.

Building a Change Request Process How change requests are handled need not be terribly complex, but it must be structured. If there were no control processes in place, then change would be handled haphazardly. This could lead to the project becoming bogged down with trivial changes or critically needed changes never being brought to the attention of the project team. In this section, I’ll talk about the process of making, assessing, and finally figuring out what to do with the change. The steps involved in change request are fairly straightforward:

1. Receive the change request. 2. Evaluate the request. 3. Accumulate the required work. 4. Determine the impact on project plan and project requirements. 5. Determine whether there is an impact on the triple constraints. 6. Make a decision. 7. Notify others and follow up.

Receiving the Change Request As mentioned earlier, a change request can typically come from anywhere, including from management, users, vendors, or even project team members. Once received, all change requests should be logged. The input log should contain, at a minimum, the following: ◆ Date of request ◆ Name of requestor ◆ Description of request You should assemble your project team and review the change request together. At this point, your sole goal is to make sure that everyone actually knows what the request is about and that

225

226

CHAPTER 9 SETTING UP A CHANGE REQUEST PROCESS

everyone understands its intent. In some instances, particularly complex requests, it might be advisable to invite the requestor to the meeting so he or she can answer questions.

Evaluating the Request Once everyone is clear on the intent of the change request, the next step is evaluating the request. You need to determine what needs to be done to make the request happen. To do that, you will need to send team members back to their individual work areas to answer the following key questions as they relate to their portion of the project: ◆ How long will it take to make the change? ◆ How much work is required to do the change request? ◆ What resources are needed? ◆ What steps need to be taken? Are there other dependencies involved? ◆ What are the potential risks to the project?

Summing Up the Required Work Once the individual team members have completed their analysis and reported back to you, you need to build the total picture of what the change request means from the pieces given you by your personnel. Once you have summarized their findings into a cumulative document, you and your team will know the following: ◆ The total time to do the change ◆ The total effort, which determines the total cost ◆ All the resources ◆ All the risks It’s not a bad idea to sketch out the sequence of steps that need to be taken to effect the change and where they will fit into the current plan and timeline of the project.

Determining the Impact Now that you have the cumulative work that the change request requires, you will need to conduct your own analysis. Your key questions center around what would happen if the change request were approved. These are the four most important questions: ◆ If approved, will the requested change affect the schedule? ◆ If approved, will the requested change affect the overall costs? ◆ If approved, will the requested change affect the affect the quality guidelines? ◆ Does the requested change invalidate any of the requirements for this product? You may recognize the first three as questions regarding the triple constraints. The last question is really an analysis of whether the requested change has an impact on the project requirements. You want to be assured that a proposed change, if implemented, doesn’t invalidate one of the requirements for the project or make it impossible to meet all the requirements. For example,

BUILDING A CHANGE REQUEST PROCESS

suppose that your messaging system plan called for utilizing a third-party solution for storage and mail archiving since that was required by a federal regulation. A change request is proposed that calls for an in-house storage solution because it will save the corporation money. Implementing the change, however, will mean not meeting a project requirement.

Determining the Impact on the Triple Constraints You have spent a lot of time gathering information and analyzing it. You have asked a lot of questions abut the ramifications of the requested change. You should have a clear idea if the requested change would have a negative impact on the schedule, budget, defined quality, or the project requirements. If none of them are impacted, it is probably acceptable to make the change. We’ll discuss the concerns you still need to take into consideration shortly. If even one of the triple constraints is impacted, you must get approval from the next higher level. As mentioned at the start of this section, that is typically the change control board (or equivalent) in large projects. If you don’t have a control board, at a bare minimum you will need to refer the requested change to the project sponsor for approval. Regardless of the source of the approval, you will perform the same basic activities.

Making a Decision The decision of whether to accept the change will be made either by you, if the change is relatively trivial in its impact, or by the change control board (or its equivalent), if it impacts at least one of the triple constraints. Therefore, it has the potential to push the project off the tracks, derailing the plan by requiring a longer schedule, exceeding the current budget, or compromising the quality of the project. It is important to know that a change request that might alter one or more of these elements is not necessarily a bad thing. The change might address an overlooked or new facet of the project. However, all changes, no matter how beneficial, that have the potential to affect your messaging system project need to be reviewed and accepted by the corporate designated authority.

Decision by the Change Control Board (or Equivalent) Once you decide that the decision needs to be referred to the change control board or its equivalent, you’ll want to refer the change to the board as soon as possible. Depending on the system you have in place, the board may meet on a regular (preferably weekly basis) for a large project with lots of change requests requiring action, or you may need to convene an ad hoc meeting of the board to address it. Even if the project is small and your ‘‘board meeting’’ consists of no one other than you and the executive sponsor meeting and reviewing the requested change, the procedures you follow should be the same:

1. First, prepare and distribute an agenda beforehand. The agenda should list the proposed changes that are going to be discussed.

2. Provide each board member, in advance, with a summary of the request and an analysis of its impact. Make sure to specify any impacts on time, money, quality and requirements. State how much time will be needed to implement the plan. State how much money will be needed. Specify what the changes will mean to the final appearance of the project.

3. Make sure that you know the answers to these questions and can provide answers to questions about them in a clear and concise fashion. Be prepared to discuss any alternatives you might have developed in lieu of the change request that might achieve the goal.

227

228

CHAPTER 9 SETTING UP A CHANGE REQUEST PROCESS

4. Finally, make sure that everyone is clear on the guidelines of how the decision about change request is going to be made by the board. There should already be rules in this place. For example, is the decision by majority vote or does it require unanimity or does the sponsor have the final vote? If these basic rules haven’t been set beforehand, make sure to have them agreed to before the board makes its first decision. If these parameters aren’t in place when it comes time to decide, you run the risk of having the board drift off into a fog of indecision where nothing is finally decided and the course of the project turns in circles on a becalmed sea. I’m now going to let you in on a little secret. Review board meetings involving major decisions are usually nothing more than formalities. The decisions are almost always made before the meeting takes place. Since the decision of the board will have a direct impact on your project, you don’t want to leave anything to chance. Also, since you, along with your team, if you have one, have already analyzed the request, you are in a better position to know whether the proposed change makes sense in the context of the project. Consequently, it is important you make a point to meet with key members of the change control board before the meeting. During these meetings provide your input dispassionately, explain why the change is right, or wrong, for the project. Lay out the facts of your analysis on the triple constraints. Explain your reasoning for favoring or opposing the requested change. When you think the change request is politically motivated (or has political ramifications), explain the politics of the situation. You want the board members to have enough information so that they make the decision that is right for the project. When you go into the change control board meeting, which will usually be chaired by the corporate sponsor, you should know where every member stands on the change. You should be confident that the decision they will make is the right one for the project and the one that assures your Exchange Server 2007–based messaging system is the appropriate one for the organization.

Decision by the Project Manager Most of what I have discussed up until now has been about major changes that impact the project’s triple constraints. What about change requests that don’t affect them, the kind that are small enough that you don’t need to get anyone else involved? If there are impacts on budget or schedule, they are minor and can be managed with reserves that you built into the project. How do you decide whether to approve a minor change? Basically, you assess it against the twin considerations of the following questions: Will the change improve the outcome of the project? Will the change enhance the way the project is organized or implemented? Other items you should consider are scope, need, and politics. You should assess the requested change against the scope document. If it’s out of scope, you can reject it for that reason. Another consideration is whether this change is actually needed or is simply a case of gilding the lily, that is, doing something to make it better than it needs to be. Another noncritical reason for requesting a change is what I’ve taken to calling ‘‘male cat syndrome’’ — some people want to make a change so they can say they left their mark on your project. Typically, if you can’t find any way the requested change actually improves the project, don’t approve it. Having said that, you should be mindful of the political considerations associated with a change request — and it is axiomatic that the smaller the change, the more politically intense it becomes. Assess who is asking for the change. If the change is denied, will that person become an enemy capable or determined enough to hurt the project? If the project is approved or denied, will it impact negatively on the team? Another consideration is the impact the decision will have on the sponsor.

BUILDING A CHANGE REQUEST PROCESS

Another useful ‘‘trick’’ you can employ to help with the political ramifications, as well as send out the message, is to discuss an unwarranted change request with the initiator. In the discussion you should lay out the business reasons against the change and try to get the initiator to withdraw the change request voluntarily.

Notifying Others and Following Up Once the decision is made, you will have to do one of three things: ◆ If the change is rejected, notify the initiator and the team. ◆ If the change is approved and affects the triple constraints, you will have to rewrite the portions of the plan that are affected. You will also need to notify the initiator and the team. ◆ If the change is approved and doesn’t affect the triple constraints, then make such adjustments as need to be done to the plan. You will also need to notify the initiator and the team. Regardless of what happens you will also have to do the following: ◆ Document the decision. If this was a board action, there will be minutes of the meeting and you should still record them on the change request, and enter it in the change request log. ◆ Disseminate the decision to the team. You can do this any number of ways, such as by sending an email, posting to a project website, announce it at team meetings, whatever it takes. Your biggest goal is to make sure no rejected changes work their way into the project simply because someone didn’t get the word.

Change Rejected This is the easiest decision to follow up on. Simply document the decision and advise the initiator and your team that the change has been denied. How you inform the initiator can be a matter of some delicacy depending on his or her place in the company and the politics it might engender. I have found that it is usually better to tell someone in person or by telephone of the outcome of the decision, rather than send an email. You can use the human connection to reduce the disappointment and to explain the rationale. If properly handled, the initiator can be turned from a potential enemy to a supporter. If you are seriously concerned about political ramifications or think that either the initiator is way above your pay scale or the project would benefit from high-level schmoozing, discuss this with the project sponsor and see whether he or she is willing to play a role in the communication process.

Approved with Impact on the Triple Constraints Your principal task is to redesign the plan to integrate the approved change. Your second principal task is to reset the aspects of the plan that the change impacts. This means you may have to reset the schedule, budget or scope, and requirements depending on what has been impacted. You will have to significantly rewrite the scope, statement of work, and plan. The simple reality is that when there is a major change, your original plan is basically defunct. From this point forward you have to write a new plan. This can actually be a positive thing, as you can use this opportunity to nudge the plan back on course if it has started to drift and also use it to reemphasize the objectives and goals of the new system.

229

230

CHAPTER 9 SETTING UP A CHANGE REQUEST PROCESS

Approved with No Impact on the Triple Constraints If you make the decision to approve the change request because it is the right thing for the project for either business or political reasons, there are few things you have to do:

1. Update the project schedule/sequence to integrate the change. 2. Modify the scope document and statement of work to integrate these relatively minor changes.

3. Notify the initiator and the team. When you notify the team, it’s important that they understand how the approval decision was made. You’re not really explaining yourself or justifying your actions in a defensive way when you do that. Instead, you are making sure that the team understands that approvals (and denials) are not simply acts of caprice. Notifying the team of the decision also requires that they fully understand the following: ◆ How the change fits into the existing project schedule ◆ How the change modifies the scope, statement of work, and plan ◆ How the change benefits the project.

Global Thermonuclear War? At 8:50 a.m. on November 9, 1979, duty officers at four command centers — North American Aerospace Defense Headquarters (NORAD), Strategic Air Command (SAC), the National Military Command Center, and the Alternate National Military Command Center — all saw on their displays a pattern showing a large number of Soviet missiles in a full-scale attack on the United States. During the next six minutes emergency preparations for retaliation were made. A number of Air Force planes were launched, including the President’s National Emergency Airborne Command Post. With understandable haste, NORAD contacted PAVE Phased Array Warning System (PAWS) early warning radar to confirm the attack. They learned that no missiles had been reported. In addition NORAD satellites had detected no missiles. After six nerve-wracking minutes, the threat assessment conference, which was discussing the launch of a retaliatory strike, was terminated. The reason for the false alarm and the near start of a global war was an exercise tape simulating a missile launch from Cuba that was running on the NORAD computer system. A technician had simply started to run the test tape without telling anyone or switching the computer to test mode. The moral of this story is to have a methodology in place that makes sure that everyone knows what is happening to the system. The planet you save may be your own.

Other Considerations So far we have discussed the key aspects of the change request process and how you should design and handle yours. In addition, there are other considerations related to the change request that you should be aware of, and prepare for. These include the following: ◆ Limiting the disruptive nature of change requests ◆ Scheduling

OTHER CONSIDERATIONS

◆ Documentation ◆ Enforcing the system ◆ Stopping change

Limiting the Disruptive Nature of Change Requests When your Exchange Server 2007–based messaging system was first approved, everything probably hummed along smoothly at the beginning. Everyone was focused, the direction was clear, and the work was on, if not a bit ahead of schedule. However, that didn’t last long and a key reason for this was because of change requests. Every time a change request came along, the people working on the messaging system needed to stop and do the analysis. These were probably the key members of the team as well since you would want your analysis to be done by the people who knew the system best, and the same people who would have to implement the change. They then returned to the project, while waiting for the decision. Human nature being what it is, some would fret about the project. If the requested change would impact what they were working in they might slow it down. They talk to each other about the change request, the politics of it, repeat rumors and any number of things, none of which were relevant to the project, but all of which consumed valuable time. You might discover that 10 hours of work were done on the project, 5 hours on the change request analysis, and the rest vaporized into nothingness. Pretty soon the messaging system is slipping behind schedule. Here are some techniques you can use to limit this disruption: ◆ Prescreen the change requests. ◆ Delegate the change management tasks to others. ◆ Analyze the cause of the change requests.

Prescreening Change Requests As project manager, you should be the first person to review a change request and determine whether it should go forward to the team for analysis. The criteria you use to filter through the change requests initially are very much the same as you those you will use if you are required to make the decision to approve or reject a fully analyzed change request. If the request is out of scope, not needed, or a mere case of gilding the lily, you can probably kill it at this stage. For political reasons, you will want to discuss the request with the initiator and ideally get them to withdraw it. It’s also a good idea to discuss the change request with the sponsor. He or she may be able to get the request withdrawn, or they may ask that you let the request go forward for a variety of reasons. When you do meet with the initiator, I suggest it be a closed door one-on-one meeting. You ask the initiator about the reasons for the request. Make sure you listen and don’t merely assume that your opinion is automatically correct. If your position hasn’t changed, then it’s a process of negotiating with the initiator. Depending on the request, you may be proposing its withdrawal or deferring it to a later time, such as after the completion of the project or during a future budget cycle. This procedure might help eliminate some requests before they can disrupt your team.

Delegating the Change Management Tasks to Others If you find that your key team members are too valuable to the project to take away from the actual work, you might want to delegate change management to other team members.

231

232

CHAPTER 9 SETTING UP A CHANGE REQUEST PROCESS

They will then be responsible for analyzing the change and submitting the results to you, but the key team members will still be involved in the final review. Giving this job to junior members can be advantageous and provide them with valuable experience. On the other hand, if a junior team member errs badly in the analysis of a change request, the ramifications can be devastating.

Analyzing the Cause of the Change Requests After a while you may begin to notice that there is a pattern to some of the change requests and that some things don’t quite make sense. Some clues that you might have a problem include one or more of the following: Many change requests get only halfway though the review process before being rejected. Sometimes this manifests itself as requests for changes that are already planned, or that try to exempt or exclude someone or some unit from the project’s outcomes. This many indicate a communications problem. Persons in the organization don’t really realize what the project is about or what they and it have been committed to and for. The best solution is to revisit your communications plan and make the necessary adjustments so that everyone understands what is happening. Many change requests are targeted at changing fundamental goals of the project. You may be getting these because there is a flaw in the design of the plan that you overlooked. It may occur because the scope wasn’t defined well. I think it’s important and highly advisable when you start seeing these sorts of request in large numbers to take the time to reevaluate what you’ve planned and scoped, and if necessary review it with the sponsor. It may be that it will be necessary to redesign the whole system. Many change requests are frivolous. Look to see where these requests are coming from. Is there a pattern? Are they coming from one person? Are they politically motivated? Are they an attempt to bog down the project by wasting its time? Your analysis will decide your best course of action. You may need to talk to an individual or organization to discover the basis for their concerns. It’s worth making a few attempts to get the initiators to understand the new system so that they send only valid and sensible change requests. Many requests are coming from your team as the project draws to a conclusion. This phenomenon usually only occurs during the predeployment phase. Some project managers call it the 95 percent syndrome. It’s not uncommon that project team members don’t want the project, or more correctly their involvement in it, to come to an end. They might not know what is going to happen to them next. They aren’t sure if they are going back to their old job, being assigned a new project, or going to be laid off. In this case, the best solution is to do what you did for the organization as a whole when we talked about change management in the previous chapter. You need to calm their fears about the future or else your project is not going to be completed.

Note The key thing to remember when faced with possible change request–based disruptions to your project is that you need to take action. You cannot afford to ignore them. When change requests threaten the project, you need to evaluate, isolate, and do something about the causes.

OTHER CONSIDERATIONS

Creating Documentation It is important that you make sure that you have a process in place that documents all change requests. You should create a form similar to the one in Appendix C. The form requires some information about each change request from the requestor and from other players in the process. Usually this form will have the following information: ◆ Project name ◆ Change request number ◆ Date ◆ Initiator ◆ Description of the change request ◆ Reason for the request ◆ Risk if not implemented ◆ Project manager ◆ Work effort required ◆ Amount of time required ◆ Nonmonetary resources required ◆ Dependencies ◆ Costs required ◆ Risks if implemented ◆ What triple constraints are impacted? ◆ External impacts (for example, contracts and vendors) ◆ Project manager recommendation ◆ Change control board recommendation ◆ Decision ◆ Date implemented There should be also places for signatures of the project manager, as well as the executive sponsor if the matter is reviewed by the change control board. Figure 9.3 provides an example of the complete change management process.

Enforcing the System Former U.S. President Lyndon Johnson once said, ‘‘A method of cheating was developed by the first student about five minutes before the first teacher gave the first test.’’ The same can be said for a change request process. Within a few minutes of putting your system in place, you’ll probably find that someone on your project team is circumventing it.

233

234

CHAPTER 9 SETTING UP A CHANGE REQUEST PROCESS

Figure 9.3

Someone decides they want to make a change to the project

Complete change management process

Requestor completes a change request form

Team reviews the request

Project manager receives request and logs it

Determine the amount of work required to make change YES

Project manager reviews the request

No Cancel request

Is the request appropriate?

Sum the required work

Determine the impact to the plan

Notify the team and the requestor No

Impact triple constraints?

Approve the change

Change Control Board reviews request

No

OK to change triple constraints?

Yes

Yes Update the plan and reset as necessary

Notify the team and the requestor

Reset any triple constraint modified

Usually these sorts of circumventions are not malicious, and most start innocently enough. A team member has a good relationship with a client. The client asks for a feature change and the team member does it. The client then simply goes to the team member every time they want ‘‘minor’’ changes done, the team members then slips it in so the client doesn’t have to deal with any of that ‘‘silly change management paperwork.’’ Usually what happens is the team member starts falling behind on their actual work, since they are doing the other stuff and the project schedule starts to fall behind. This is a common pattern in projects. Some people just don’t like to follow the rules; others don’t want to deal with the paperwork, and others still are usually acting from the best and noblest of intentions. If you’re totally honest with yourself, you may have to admit to yourself that you have done something similar in the past. Of course, it’s wrong and can badly impact your project, causing a number of problems: ◆ No one else knows about the change or the new feature. So it’s not tested and no one notices it isn’t working until after the implementation of the system. ◆ It takes time from the approved portions of the project and results in the project falling behind schedule. ◆ Documentation and training don’t match the system.

OTHER CONSIDERATIONS

◆ Other persons in the organization are encouraged to bypass the change management system. ◆ Chaos reigns. What do you do to maintain order and keep people from circumventing the system? There are two key things you must do: ◆ Set up a team policy that states no unauthorized changes can be made. ◆ Monitor policy compliance at every meeting. Make it very clear you are serious. The first time a change is done correctly point this out and publicly praise the persons who did it correctly. This helps reinforce the idea in everyone’s mind, and nothing gets people to perform better than being acknowledged — or seeing others acknowledged for what they can do. The first time you find an unauthorized change, stop it, and if completed, take steps to undo it. Identify the team member who has violated the policy and pull them aside privately. Explain that they have violated the policy and that is unacceptable. I suggest advising them that a second instance will result in their removal from the team. I also suggest making them responsible for removing the change. At the next team meeting reiterate the policy. Never under any circumstances should you publicly humiliate the perpetrator in front of his peers. I also recommend one last step if you feel that it is warranted. You may need to identify the person who has asked your team member to circumvent the process and speak to their boss. This is probably not necessary and can lead to some unexpected fallout. It is also almost certain that your team member will have let the other person know the amount of trouble they caused your team member, even if inadvertently. You will still need to monitor the situation, however, and guard against repeat attempts by the non-team member and if the problem becomes chronic, go to his or her superiors.

A Tale of Two Olympics IBM built and operated the computer infrastructure to support the 1996 Summer Olympics in Atlanta and the 1998 Winter Olympic Games in Nagano. For the 1996 Atlanta Games, there was no change request process in place, and many ‘‘minor’’ changes were made by programmers completely oblivious that their changes might impact the rest of the system. Some systems were completed at the last minute, and there was no time for testing. Some were still being developed after the games had started. There were many problems, all heavily reported by the press, much to IBM’s embarrassment. The problems and associated outages prevented the press from getting information about the athletic events and left them with nothing else to write — except that IBM’s highly touted computer system wasn’t working. A root cause analysis was conducted after the event, and it was determined that a better change request process was needed. IBM established change control boards (which it referred to as change management boards). These boards had up to 10 representatives from different areas of the project for the Nagano Games to review change proposal. Using this mechanism several ‘‘small’’ changes were prevented from being implemented, and all the necessary hardware and software was completed and fully tested before the event, with many problems discovered and fixed in advance. The final result was that the information system for the 1998 Winter Olympics ran smoothly when the events started.

235

236

CHAPTER 9 SETTING UP A CHANGE REQUEST PROCESS

Stopping Change This usually applies only when in the planning and implementation phase of your Exchange Server 2007–based messaging system, or any project for that matter. There must be some established point after which no more change requests will be accepted. The reason for this is obvious. You need to complete the project. The date you choose is dependent on the answer to a simple question: ‘‘How much time will my team need to complete the project if they don’t have any distractions?’’ From there it’s a simple process of subtracting that date from the projected end date and setting the ‘‘no changes date.’’ Once that date is set make sure that it is widely disseminated throughout the enterprise. When the date comes along, stick to it. You will continue to receive change requests after the date. They should still be logged in, and as the project manager you will still need to review them. However, these change requests will become part of the next, postdeployment phase of your messaging system. Indeed they may form the crux of the next project for the messaging system after it is implemented. One caveat: if you do receive a change request that is completely warranted and really needs to be done, even at this late date, for the project to be done correctly you must take it through the entire change request process and to the change control board and implement it.

Case Study: Setting Up a Change Request Process Up to this point everything in this chapter has been theoretical. Now I’m going to change gears a bit and walk you through a case study that illustrates the lessons in this chapter. You can follow these steps in Figure 9.4, which is based on the method I described in Figure 9.3. Numbers in the text correspond to numbered steps in the flow chart. Oakland Playground Equipment is a large company located in California that manufactures and sells equipment for children’s playgrounds, such as slides, swing sets, jungle gyms, and so on. Kim has been named project manager for the implementation of an Exchange Server 2007–based messaging system. Kim has already completed all the steps up to presenting the business case and getting its approval, having successfully gathered business requirements, author scope, and statement of work documents and prepared an implementation plan. All the particulars of the plan have been approved by and are enthusiastically supported by the executive sponsor, Neil. It is estimated that it will take six months for the plan to be completely implemented and the Exchange Server 2007–based messaging system to be fully operational. One element of the plan calls for the 25 members of senior management to be provided with anywhere availability. The limitation was set because of the cost of equipment and required server and disk capacity. One month into the plan, Kim is satisfied with the project and the progress her team is making. A 50 percent drop in the cost of handheld communication devices, along with moderate pressure from her personnel (Step 1) prompts the senior vice president of sales to fill out a change request form (Step 2). The change request asks for anywhere availability for her sales force of 50 people. The business rationale is that the new lower price of devices allows for the purchase of additional devices without stretching the budget. Equipping the sales force with this capability, she states, is necessary to assure that the sales force can exploit opportunities and provide better customer service. If this step is not taken, she argues, then Oakland Playground Equipment will likely lose its competitive edge. The completed form is submitted to Kim who logs it and assigns it a change request number (Step 3).

CASE STUDY: SETTING UP A CHANGE REQUEST PROCESS

Figure 9.4 The change request process for Oakland Playground Equipment.

1. Sr VP -Sales decides she wants change

2. Sr VP completes change request

6. Team reviews the request

3. Kim receives request and logs it

7. Determine the amount of work required to make change

YES 4. Kim reviews change request

5. Determines request is appropriate

8. Kim sums the work required

9. Determines the impact to the plan

13. Notify the team and the requestor No

10. Impacts triple constraints

11. Change Control Board Reviews request

12. OK to change triple constraints?

As project manager Kim reviews the request (Step 4). She has several misgivings about it, and had the request form been from someone else she might have been inclined to reject it as out of scope. However, the request initiator is a senior vice president. She contacts the sponsor. After a few minutes of deliberation, the sponsor instructs Kim to continue processing the change request (Step 5). Kim is of the opinion that this continuation is being done for political purposes, and although she is unhappy about the waste of time, she appreciates the potential impact on the project that a rejection at this point might have. Kim schedules a meeting of the key team members to review the change request (Step 6). Team members are asked whether they think the requested change will affect their areas of the project. Those answering in the affirmative (for example, hardware acquisition) are asked to prepare an analysis and report back to Kim the next day (Step 7). Kim gathers up the report and collates the information the reports contain (Step 8). The requested change will have the following impacts (Step 9): ◆ Require the addition of an Exchange Server set up in the UM role ◆ Require additional disk space and bandwidth ◆ Require additional training time for the sales personnel ◆ Add $75,000 in direct costs and approximately an additional $35,000 in indirect costs

237

238

CHAPTER 9 SETTING UP A CHANGE REQUEST PROCESS

◆ Implementation of the requested change would take approximately one additional month for hardware delivery, training, and extra time required to deploy additional server and disks ◆ The change is outside the initial scope and statement of work and will require rescheduling of numerous other dependent tasks Kim and her team prepare contingency diagrams, outlining what they will now need to do if the change is required. Because the proposed change clearly impacts all three of the triple constraints (schedule, budget, and scope) (Step 10), the matter is referred to the change control board. Kim gathers together her documentation and recommends that the change not be made at this time because of its overall impact on the timeline. She cautions in her report that if a decision is made to approve the change request, then it will necessitate approving a longer schedule and arranging an increase in funding. After a brief discussion with Kim, the sponsor adds the change request to the agenda of the change control board scheduled for three days hence. Kim visits key members of the board explaining her recommendation and the reasons behind it. Board members listen to her attentively, although some, including the sponsor, have cited the political problems inherent in rejecting a change to the project sought after by one of the enterprise’s senior officers. At her suggestion, Kim and Neil meet with the senior vice president of sales. After about an hour of discussion, two points become clear. The senior vice president wants the feature available for all her sales staff, a point she considers nonnegotiable. At the same time she admits that the full ramifications of the request clearly exceed her initial assessment of them, namely, simply buying additional devices and some rudimentary training. She, therefore, does not want to delay the project or cause it to run over budget. Consequently, she is willing to accept Kim’s suggestion to defer the requested change until after the Exchange Server 2007–based messaging system is in place. At the change control board meeting (Step 11), the executive sponsor summarizes Kim’s reasons for not recommending the change and encourages the board to accept her recommendation to deny the change. The change is denied and the reason summarized in the minutes (Step 12). The board makes it clear that the change request is only being rejected at this time and leaves the door open for a future resubmission after the project has been completed and the messaging system implemented. After the meeting Kim visits the senior vice president and informs her of the change control board’s decision and recommendation. She then informs her team of the fact that the change has been rejected for the current project (Step 13) and documents the result on the form accordingly.

After the Deployment Much of what we’ve reviewed up to this point is primarily aimed at what to do about change requests that come in before your Exchange Server 2007–based messaging system is deployed. But as I discussed already, change doesn’t end at deployment; in fact, it’s just the beginning of a process that will last for the life of your system. Most of the techniques you applied before the system was deployed to handle changes will still continue to be needed. Given the robust nature of Exchange Server 2007 and its likely life cycle in your organization, you will constantly need to make changes. Some will be simple hardware and software changes, such as the applying of security patches, or replacing servers or upgrading other components. Some will be complex and have major impact

SUMMARY

across the system, such as applying service packs or changes to your domain structure and active directory. You will need to have a change request process in place for these sorts of changes. The change request process for these types of changes will need to take into account the different categories of systems that are changed, the types of changes that are made, and the specific procedures for each combination. Categories of changes may include such things as creating a mailbox, or installing a new service or upgrades or patches. Successful change management of this type requires communications. Everyone in the system, especially users and administrators, needs to know what is happening and when. Changes should be scheduled to be implemented when they run the least risk of causing damage or outages. None should ever be undertaken without a rollback strategy in place. As a general rule of thumb, any change that will impact more than a single desktop should be coordinated through a change request process nearly identical to the one I’ve already described. Hence, you should ensure that you have provided a plan for how the change request process for these sorts of change will be processed. Another category of postdeployment change requests are really a continuation of the original project and in one sense are mini-projects. A good example is the planned change request for available anywhere technology for her sales force that the senior vice president agreed to defer until after deployment. To handle this sort of request, you will need to continue the project’s change request process and maintain a method for handling major change requests of this type. As a practical issue it will be easier, and perhaps more effective, to treat major requests of this type as a separate project.

Summary In this chapter, you learned how change requests are part of your Exchange Server 2007–based messaging system’s natural life cycle. You also learned that having a process to handle change requests that is structured, consistent, and well thought out is necessary to successfully complete your system on time, on budget, and with high quality. You’ve seen an example of how a good, effective change request process system can help in navigating the political and financial shoals that can sink your project. This chapter has also showed you basic tips and tricks for managing change requests in a way that enhances your project, boosts your credibility, and improves your chances of a successful completion.

239

Chapter 10

Deploying Exchange Server 2007 ‘‘Make it so.’’ — Captain Jean Luc-Picard, USS Enterprise, NCC 1701-D Congratulations! You have now come to the moment when the system you have lovingly and carefully raised from the time it was a sketch on a piece of paper, walked it through the gauntlet of corporate and managerial inquisition, and seen it grow into a truly worthy implementation plan is about to be launched. Take a moment and pat yourself on the back, because you certainly deserve it. The time for paper analyses, testing, and sandboxes is over. Your Exchange Server 2007–based messaging system is about to be deployed out into the enterprise. In this chapter, you’ll review the terminology and supported paths to your Exchange Server 2007–based messaging system. You’ll take the final steps to prepare for deployment, such as selecting your organizational model, conducting readiness checks, and preparing for migrations. In this chapter, you’ll walk through a typical installation, learn about other installation options, and become familiar with the setup command. Finally, you’ll learn about the many postinstallation tasks and the intricacies of mailbox moving from your old messaging system to your new one. Sound like fun? Good! Let’s start with mastering the jargon.

The Tao of Upgrading I remember, and maybe I shouldn’t tell you this because it will date me, when I had to make my very first computer upgrade. I inserted my 360 KB floppy with DOS 3.3 on it and upgraded my system from DOS 2.1. I think it took 15 minutes (it was a 16 MHz machine). When I said I had upgraded my computer, everyone knew what I meant — even the cat who promptly chewed on the diskette. As you already know, there is no such thing as a straight upgrade to Exchange Server 2007. As a result, Microsoft, never known for its hesitancy to create new terms, has come up with three terms to describe the scenarios by which an Exchange Server 2007–based messaging system is created. Unfortunately, what Microsoft chose to do was to redefine a term we had all been using differently and introduce a new term that doesn’t match its definition. Sigh. The three terms are as follows: ◆ New installation ◆ Transition ◆ Migration

242

CHAPTER 10 DEPLOYING EXCHANGE SERVER 2007

The first scenario is a new installation. This is ideal for a new enterprise or one that never had an email system before. The second scenario is called transition. In a transition, you upgrade an existing Exchange organization, which of course must be Exchange Server 2000/2003 Exchange Server 2007. Performing the transition requires that you move data from the existing Exchange servers to new Exchange Server 2007 servers. For example, when upgrading from an Exchange Server 2003 or Exchange 2000 Server organization to an Exchange Server 2007 organization, you perform a transition. The transition process happens in several phases. In each phase, you introduce individual Exchange Server 2007 server roles and transport features. At the conclusion of each phase, the organization will have coexistence of Exchange Server 2007 with Exchange Server 2000/2003 and will be running in a supported coexistence mode. The end-to-end process is designed to maintain messaging functionality and stability throughout the transition process. You can only transition to Exchange Server 2007 from the following existing messaging systems: ◆ Exchange Server 2003 messaging system ◆ Exchange Server 2000 messaging system ◆ Combined Exchange Server 2003 and Exchange 2000 messaging system Migration is the scenario in which you upgrade to Exchange Server 2007 by migrating data from a non-Exchange messaging system to Exchange Server 2007. An example of this is changing your messaging system from Lotus Notes to Exchange Server 2007. In that situation you must move mailboxes and data to the new Exchange Server 2007 organization, without retaining any of the data from the Lotus Notes organization. Migration also applies to scenarios when you move from an existing Exchange organization to a completely new Exchange organization, without retaining any of the Exchange configuration data in the first organization. For example, when merging with another company, you can perform a migration. In this scenario, you move mailboxes and data to the other company’s Exchange organization, without retaining any of the configuration data from your existing Exchange organization. The migration process includes installing a completely new Exchange Server 2007 organization and then migrating mailboxes from the old messaging system to the new Exchange Server 2007 messaging system, using various tools for migration. One thing of course that you should keep in mind is that if you are moving an Exchange Server 2003 or Exchange 2000 organization to Exchange Server 2007, you can choose to either transition the organization, or migrate to a new organization. In most cases, you will want to retain the Exchange data from the existing organization, so you should choose to transition to Exchange Server 2007. Table 10.1 shows the supported conversion paths to Exchange Server 2007. Deployment consists of preparation, installation, and postinstallation tasks.

Note SP1 can be installed on computers running the RTM version of Exchange Server 2007 to perform an in-place upgrade. For new installations, you do not need to install Exchange Server 2007 RTM and then install SP1. Because SP1 is a completely updated set of installation files, it can be used to perform a fresh installation of Exchange Server 2007 SP1.

FINAL PREPARATIONS FOR DEPLOYMENT

Table 10.1:

Supported Migrations and Transitions

Existing Messaging System

In-Place Server Upgrade to Exchange Server 2007

Transition to an Exchange Server 2007 Organization

Migrate to Exchange Server 2007

Exchange Server 5.5

Not supported

Not supported

Supported, by migrating first to Exchange Server 2003 or Exchange 2000, and then transitioning Exchange Server 2003 or Exchange 2000 to Exchange Server 2007

Exchange Server 2003

Not supported

Supported

Supported

Exchange 2000

Not supported

Supported

Supported

Mixed Exchange Server 2003 and Exchange 2000 organization

Not supported

Supported

Supported

Lotus Notes

Not supported

Not supported

Supported, using interoperability and migration tools

Final Preparations for Deployment By now you should have already made sure that key predeployment tasks have already been done by you, or in the case of large projects, members of your team. This means of course that before you proceed any further, you should take a few moments and make sure that you’re ready for the deployment.

Double-Checking the Basics In every sports movie or TV show, from Hoosiers to Remember the Titans to Coach Carter, there’s a scene where the coach meets with the players. Inevitably he quells their doubts, suppresses their skepticism, and inspires them to greatness by telling them that it’s time to get back to the fundamentals. Inevitably the team wins, and the players go on to greatness and multimillion-dollar contracts. What’s true in sports is also true in most aspects of life, including Exchange Server 2007. The last thing you should do is reconfirm that you have taken care of all the fundamentals. Double-checking these basic items will save you problems, not to mention embarrassment.

Check the Scope Statement Before you deploy your Exchange Server 2007–based messaging system throughout your enterprise, you want to make sure that it will meet the agreed-on requirements as spelled out in the scope statement. Double-check this. I also suggest that you make one last call to the sponsor and

243

244

CHAPTER 10 DEPLOYING EXCHANGE SERVER 2007

the legal department to ensure that there are no last-minute business, legal, or regulatory requirements that have been added. Also ensure that all change requests have been filled. One of the reasons you set a no change date was so that there would be no outstanding changes pending. If there is a reason why the planned deployment cannot meet some of the requirements spelled out in the scope statement and that have not been previously dealt with, resolve these, or discuss them with the sponsor and management. For example, your deployment may call for all 50 members of senior management to have Outlook Anywhere capabilities, but only 20 required handheld devices have arrived. The sponsor and management should be consulted on whether the deployment should proceed as planned or be delayed pending the vendor’s delivery. Obviously, you should explain any impact on the deployment schedule the delay will have.

To Deploy or Not to Deploy In 1944, General Dwight D. Eisenhower was faced with a deployment question of his own. The scope statement for ‘‘Operation Overlord’’ called for the successful invasion of France with sufficient force to establish a sustainable beachhead in Normandy. Everything needed was ready, material assembled and training completed, and even rollback plans were in place in case his plans failed. Eisenhower had one other deployment requirement: a full moon was required both for light for the aircraft pilots and for the spring tide, effectively limiting the window of opportunity for mounting the invasion to only a few days in each month. The best tide and moon conditions gave the military three options for the invasion: Late May, June 5 or 6, or June 17 and 18. Given those dates, the forecasters had to predict the best conditions for the invasion. Postponement past June effectively meant that the invasion would have to be put off until 1945, because several months of good campaigning weather were essential for the subsequent operations on the Continent. Eisenhower had originally selected June 5 as the date for the assault, since he was told that a late May invasion would not be possible. While most of May had fine weather, this deteriorated in early June. On June 4, conditions were clearly unsuitable for a landing; wind and high seas would make it impossible to launch landing craft, and low clouds would prevent aircraft finding their targets. The Allied troop convoys already at sea were forced to take shelter in bays and inlets on the south coast of Britain. If the weather continued to be bad, it seemed possible that everything would have to be canceled, and the troops returned to their camps (a vast undertaking, because the enormous movement of follow-up formations was already proceeding) and the invasion postponed two weeks, if not longer. On the gloomy stormy morning of June 5, Eisenhower met with his top subordinates and chief meteorologist Group Captain J. M. Stagg. Stagg forecast a brief improvement for June 6. On the strength of Stagg’s forecast, Eisenhower ordered the invasion to proceed, with the now famous decision, ‘‘All right boys, we’ll go.’’ Eisenhower also prepared two speeches; one announcing the success of the landings, the other their utter failure. Eisenhower’s decision, made with a full appreciation of its consequences, turned out to be the right one. The Germans seeing the poor weather conditions believed no invasion would be possible for several days. Some troops stood down, and many senior officers were absent. Field Marshal Erwin Rommel, the commander of the forces intended to repel the invasion, decided to take a few days’ leave with his wife and family. Dozens of division, regimental, and battalion commanders were away from their posts at war games or on holiday.

FINAL PREPARATIONS FOR DEPLOYMENT

The invasion succeeded, albeit at a high price. As it turns out, Eisenhower’s decision to go ahead was also inspired, or lucky. On what would have been the next deployment date, June 18, the worst storm in 60 years swept through the English Channel. That storm destroyed one artificial harbor and severely damaged another, as well as wreaking havoc on ships and materiel. Had Eisenhower waited, D-Day would have been a disaster, as all three Allied meteorology teams had failed to forecast the storm. ‘‘I thank the gods of war we went when we did,’’ Eisenhower wrote to the military’s chief meteorologist. The moral of this story is that you must fully understand the consequences of delaying a scheduled deployment as well as going ahead with one if the situation limits the possibility of success.

Confirm Hardware and Software Requirements Confirm that all of the hardware and operating systems on the target machines meet, and preferably exceed, the system requirements. Since you will be installing Exchange Server 2007 Service Pack 1, be certain to have Service Pack 2 installed on all Windows Server 2003 machines that you will install Exchange 2007 SP1 on and that the domain controllers and machines running Windows Server 2008 are stable. If you plan to deploy server roles on different physical servers, you need to ensure fast network links between them. For example, you need at least 100 Mbit links between Client Access and Mailbox servers — 1Gbit is better. If you plan to integrate with software products such as Outlook 2007 and Office Communications Server 2007, make sure that they have already been deployed or will be deployed in conjunction with the deployment of Exchange Server 2007.

Confirm Active Directory Preparation Confirm that the Active Directory has been properly prepared. If you haven’t don’t worry, if you run the Exchange Server 2007 Setup Wizard with an account that has the permissions required to prepare Active Directory and the domain, the wizard will automatically prepare Active Directory and the domain; however, you will then need to allow domain controller replication to take place. Convert all mixed modes to native mode.

Confirm Correct Permissions on Legacy Exchange Systems Double-check that permissions on the legacy exchange systems are correct. If you have any computers in your organization running Exchange Server 2003 or Exchange 2000 Server, open a command prompt window, and then run one of the following commands. To prepare legacy Exchange permissions in every domain in the forest that contains the Exchange Enterprise Servers and Exchange Domain Servers groups, run the following command: setup /PrepareLegacyExchangePermissions.or setup /pl

To prepare legacy Exchange permissions in a specific domain, run the following command: setup /PrepareLegacyExchangePermissions: < FQDN of domain you want to prepare > or setup /pl:

245

246

CHAPTER 10 DEPLOYING EXCHANGE SERVER 2007

Apply Preinstallation Security Steps Before installing Exchange 2007, perform the following procedures:

1. Run Microsoft Update. 2. Run the Microsoft Malicious Software Removal Tool. 3. Run the Microsoft Baseline Security Analyzer. Review DNS Settings Make sure that you correctly register host records for servers that run Exchange Server 2007 in the Domain Name System (DNS) server for the Active Directory forest. By default, the Exchange 2007 server uses the DNS server that is configured in the IP properties of the network adapter to locate domain controllers and global catalog servers, other Exchange servers, and remote domains. You should verify that static IP addresses have been applied to the server and that the DNS server settings are configured correctly on the IP properties of the local area connection of the servers and that the A resource records and PTR resource records are accurately registered in DNS. Remember from Chapter 5 that the Edge Transport server role is deployed outside the Exchange organization as a standalone server in the perimeter network or as a member of a perimeter network Active Directory domain. As a result make sure that you have manually configured the correct DNS suffix for the Edge Transport server role before you continue with installation of Exchange 2007. If a DNS suffix is not configured, setup will fail.

Confirm Training While you probably weren’t responsible for the actual training of users in the use of the new product, you would have had considerable input into what subjects were covered. You may have also been responsible for providing training versions of the planned deployment so that users were familiar with the changes the deployment of Exchange Server 2007 was going to bring to their work environment. You should confirm that all required training has been completed and on the correct versions of the relevant software and hardware.

Give Proper Notifications It seems like such a simple thing, but it’s often overlooked. Make sure that all relevant personnel know that your deployment is about to start and when they can expect to see its impact. Among the key people you should notify personally are the executive sponsor, corporate management, and other relevant IT personnel if your deployment is one of many projects. I strongly encourage you notify the help desk personnel as well, since they will be receiving any initial notifications of problems. Users should be given advance notice of when your deployment activities will begin to impact them. For example if you are using a deployment strategy that calls for coexistence of the existing system with the new Exchange Server 2007–based messaging system for a period of time, your deployment of server roles will likely be transparent until you begin moving user accounts and mailboxes to the new organization. In that case, you might be able to delay notification until the actual impact is seen. In addition to the previous, you should also do the following preparatory steps:

1. Select an organization model. 2. Understand the process for deploying a new organization.

FINAL PREPARATIONS FOR DEPLOYMENT

3. Understand the process for transitioning an Exchange organization. 4. Under the process of migrating from Lotus Notes. I’ll go over each of these in detail in the following sections.

Selecting the Exchange Organization Model Before deploying an Exchange Server 2007 organization, you must first identify the organization model that best describes your existing Exchange organization and/or which of these you want your organization to be after you deploy Exchange Server 2007.

Note An organization is a logical container that groups Exchange resources together. Exchange resources within an organization are tightly integrated and share a common security context. There can be only one Exchange organization per forest. If you are transitioning you should scan your existing organization before you deploy Exchange Server 2007, by using the Microsoft Exchange Best Practices Analyzer Tool (ExBPA). You can do this by launching ExBPA from the Toolbox Work Center in the Exchange Management Console or downloading the tool from the Microsoft site at www.microsoft.com/downloads/ details.aspx?familyid = DBAB201F-4BEE-4943-AC22-E2DDBD258DF3&displaylang = en.

In addition to providing errors, warnings, best practices, and other information that you may want to resolve before installing Exchange Server 2007, the Exchange Best Practices Analyzer will also alert you as to which of the four organization types you have. There are four supported Exchange organization models: Simple Exchange Organization The Simple Exchange Organization contains either a single Exchange server that provides all Exchange services and stores all Exchange data for the entire

247

248

CHAPTER 10 DEPLOYING EXCHANGE SERVER 2007

organization, or multiple Exchange servers in a topology that includes redundant directory servers and an Edge Transport server in a perimeter network. Standard Exchange Organization The Standard Exchange Organization builds upon the Simple Exchange Organization by deploying multiple computers running Exchange. Large Exchange Organization The Large Exchange Organization is the largest organization model that can be deployed in a single Active Directory directory service forest. Complex Exchange Organization The Complex Exchange Organization is the only model that includes multiple Active Directory forests or the use of synchronization technology. Each organizational model has its own characteristics.

Simple Exchange Organization Model The Exchange Server Analyzer categorizes the Exchange organization as a simple Exchange organization if the following conditions are true: ◆ The total number of mailboxes in the organization is less than 1,000. ◆ Exchange servers are installed only in one Active Directory site. ◆ There are fewer than three computers running either Exchange 2000 or Exchange Server 2003. ◆ There are no clustered Exchange servers deployed. Of the four defined organization models for Microsoft Exchange Server 2007, the simple Exchange organization represents the most basic topology into which Exchange Server 2007 can be deployed. The simple Exchange organization contains either: ◆ A single Exchange server that provides all Exchange services and stores all Exchange data for the entire organization. ◆ Multiple Exchange servers in a topology that includes redundant directory servers and an Edge Transport server in a perimeter network. If you are transitioning from an existing Exchange Server 2003 or Exchange Server 2000 organization to an Exchange Server 2007 organization, be aware that you cannot perform an in-place upgrade on a single server. You must add an Exchange Server 2007 server to your existing organization, move mailboxes and other data to the Exchange Server 2007 server, and then remove the Exchange Server 2003 or Exchange 2000 server from the organization. In a simple Exchange organization, it is not expected that you will keep the Exchange Server 2003 or Exchange 2000 server in the organization coexisting with the Exchange Server 2007 server. The transition will happen quickly, so you do not need to plan for coexistence between Exchange Server 2007 and previous Exchange versions. If you do plan to keep an Exchange Server 2003 or Exchange 2000 server in your organization, your organization is considered a standard Exchange organization instead of a simple Exchange organization.

Warning If the Client Access server and Mailbox server roles are going to be on the same server, exprox.dll has a problem with redirection and will use the internal server name causing Outlook Web Access

FINAL PREPARATIONS FOR DEPLOYMENT

(OWA) to fail if they are going through the Client Access server to a Exchange Server 2003 mailbox, which is common in a simple setup. For more details, see http://technet.microsoft .com/en-us/library/bb885041.aspx.

Standard Organization Model Of the four defined organizational models for Exchange Server 2007, the standard Exchange organization represents the most common topology into which Exchange Server 2007 is deployed. As a messaging service needs grow beyond the resource limits of a single computer, separation of Exchange Server 2007 services onto multiple computers becomes the next topological division: the standard Exchange organization. The standard Exchange organization builds upon the simple Exchange organization by deploying multiple computers running Exchange. Unlike the simple Exchange organization, in which all Exchange server roles and services (except for the Edge Transport server role) are installed on a single computer, the distinguishing characteristic of the standard Exchange organization is that Exchange services are installed on multiple computers. In this topology, Exchange Server is not installed on a directory server, and it may be installed on multiple member servers. In this case, adequate directory service resources must be available to meet the needs of the messaging system. Other distinguishing characteristics of the standard Exchange organization include: ◆ The Service Delivery Location (SDL) and Client Service Location (CSL) reside on the same local area network (LAN). ◆ There are more than 1,000 mailboxes in the organization. ◆ There are fewer than five routing groups, and between one and five Active Directory service sites. Multiple locations and Active Directory sites introduce the multi-site routing protocol and role discovery algorithms, as well as a requirement to use IP site links.

Note Multiple routing groups will only exist in a standard Exchange organization that includes Exchange Server 2007 and either Exchange Server 2003 or Exchange 2000 Server, or both Exchange Server 2003 and Exchange 2000. In a pure Exchange Server 2007 environment, all servers belong to a single routing group. ◆ There is a single Active Directory forest. It is recommended the single-forest Exchange design because it offers the richest set of mail system features and has the most streamlined administrative model. Because all resources are contained in a single forest, a single global address list (GAL) contains all users across the forest. The main disadvantage associated with this option is that administrators must determine how to share or divide responsibilities for managing Active Directory and Exchange objects. The introduction of a second or subsequent forest automatically redefines the topology as a complex Exchange organization.

Large Organization Model Of the four defined organization models for Exchange Server 2007, the large Exchange organization is the largest organization model that can be deployed in a single Active Directory

249

250

CHAPTER 10 DEPLOYING EXCHANGE SERVER 2007

service forest environment. The distinguishing characteristics of the large Exchange organization include: ◆ Five or more routing groups, or five or more Active Directory sites that have at least one Exchange server deployed. Multiple locations and Active Directory sites introduce the multi-site routing protocol and role discovery algorithms, as well as a requirement to use IP site links. ◆ A single Active Directory forest. The introduction of a second or subsequent forest, or the introduction of directory synchronization tools, such as Microsoft Identity Integration Server (MIIS), automatically redefines the topology as a complex Exchange organization. ◆ The Service Delivery Location (SDL) and Client Service Location (CSL) reside in multiple physical locations, and there is often greater separation between them than in the standard Exchange organization. ◆ Although in this topology, the Exchange organization includes multiple points of presence, the external messaging and client protocol-specific namespaces are common across most or all locations.

Note Multiple routing groups will exist only in a large Exchange organization that includes Exchange Server 2007 and either Exchange Server 2003 or Exchange 2000 Server, or both Exchange Server 2003 and Exchange 2000. In a pure Exchange Server 2007 environment, all servers belong to a single routing group.

Complex Organization As its name implies, a complex Exchange organization represents the most intricate topology into which Exchange Server 2007 is deployed. Of the four defined organization models for Exchange Server 2007, the complex Exchange organization is the only model that includes multiple Active Directory service forests or the use of synchronization technology. The deployment of multiple Active Directory forests that host Exchange servers and mailboxenabled accounts is becoming a common scenario. A major driver of these deployments is the need to segregate administration of user environments and trusted security contexts. Because the forest represents the security boundary of Active Directory in deployments where security and controlling access to resources is the primary concern, it is common to find multiple Active Directory forests deployed in parallel. This also allows disjointed organizations to centralize services to unify communication and collaboration.

Deploying a New Organization Microsoft recommends that you deploy a new, single-server Simple Exchange Organization only when you are using Microsoft Windows Small Business Server 2003. They also recommend that you deploy a new, multiple-server Simple Exchange Organization only when using Centro.

FINAL PREPARATIONS FOR DEPLOYMENT

When deploying a new Standard, Large, or Complex Exchange Organization, you should use the following process:

1. Verify that Active Directory is configured correctly for an Exchange Organization. The requirements that must be met are: ◆ The domain controller that is the schema master has Microsoft Windows Server 2003 Service Pack 1 (SP1) or above installed. ◆ At least one domain controller in each Active Directory site that will contain Exchange Server 2007 Service Pack 1 must be running Windows Server 2003 SP1 or above. ◆ The Active Directory domain functional level must be Windows 2000 Server-native or higher for all domains in the Active Directory forest where you will install Exchange Server 2007 Service Pack 1.

2. Verify that your network and its name resolution services are configured correctly for an Exchange organization. The requirements that must be met are: ◆ Domain Name System (DNS) is configured correctly in your Active Directory forest, using a single, unified namespace. ◆ Connection points between distributed sites that will contain Exchange Server 2007 have at least 64 kilobits per second (Kbps) of bandwidth available.

3. Verify that Active Directory sites are configured correctly to accommodate message routing. 4. Prepare the Active Directory forest and domains for Exchange Server 2007. The Active Directory schema needs to be extended to support Exchange Server 2007.

5. Deploy and configure Client Access servers. The first Exchange Server 2007 server role that should be introduced into the organization is the Client Access server. The Client Access server provides access to clients using Post Office Protocol version 3 (POP3), Internet Message Access Protocol version 4 (IMAP4), Microsoft Outlook Anywhere, and ActiveSync. The Client Access server role also provides Web Services, including the Availability service and Autodiscover service for clients such as Microsoft Office Outlook 2007. You must deploy the Client Access server role in each Active Directory site that will contain a Mailbox server.

6. Deploy and configure Edge Transport servers. The Edge Transport server is deployed outside the Exchange organization in a perimeter network. You can deploy this server role during any phase of the upgrade process. The Edge Transport server does not depend on any particular messaging or directory configuration. You can add an Edge Transport server to an existing Exchange organization without upgrading any Exchange servers. You do not have to make any organizational changes to use an Edge Transport server. The Edge Transport server uses Active Directory Application Mode (ADAM) for storage of configuration and recipient information. The ADAM schema contains all the object classes and attributes that are required to perform configuration of the Edge Transport server.

7. Deploy and configure Hub Transport servers. The Mailbox server and Unified Messaging server require a Hub Transport server. You must install and configure a Hub Transport server before mail flow can be established.

251

252

CHAPTER 10 DEPLOYING EXCHANGE SERVER 2007

8. Deploy and configure Mailbox servers. 9. Deploy and configure Unified Messaging servers. You cannot install and configure a Unified Messaging server until after you have deployed and configured a Hub Transport server and Mailbox server. This is required because messages generated by a Unified Messaging server can only be submitted to a Hub Transport server, and because only recipients who have mailboxes on Exchange Server 2007 servers can use Unified Messaging. After you install a Unified Messaging server, there are other deployment tasks that you must complete to successfully deploy Unified Messaging in your organization.

10. Perform postinstallation tasks. After the deployment of server roles is complete, there are several postinstallation tasks that you should perform, including verifying that your installations were successful, and finalizing your deployment.

Transitioning an Exchange Organization As mentioned already, Microsoft Exchange Server 2007 does not support an in-place upgrade from any earlier version of Exchange. The Exchange organization must be operating in native mode before you can start introducing any Exchange Server 2007 servers into the environment. This means that only Exchange Server 2003 and Exchange 2000 Server servers can exist in the organization. If your organization includes Exchange Server version 5.5, you must perform an upgrade to Exchange Server 2003 or Exchange Server 2000 before moving to Exchange Server 2007. To move messaging services and data from Exchange Server 2003 or Exchange 2000 Server to Exchange Server 2007, you must use the move mailbox functionality in Exchange Server 2007. The transition process varies from organization to organization depending on the complexity of the current deployment. The transition process occurs in several phases. Each phase introduces individual Exchange Server 2007 server roles and features. At the conclusion of each phase, your organization will be running in a supported transition mode. The end-to-end process is designed to maintain messaging functionality and stability throughout the transition process. The following steps are recommended.

Conducting a Readiness Check As mentioned earlier, the easiest way to capture most of the information about your Exchange organization, Active Directory, and other settings and configuration information is to scan the organization using the Microsoft Exchange Server Best Practices Analyzer Tool (ExBPA). After the Exchange Server 2007 Readiness Check scan is complete, a report is generated. After the report is complete, navigate to the All Issues tab and look for an entry called Transition documentation. Select this item to display the organization model for the scanned Exchange organization, as shown in Figure 10.1.

Documenting the Environment In addition to using ExBPA to collect Exchange Server organization information and perform an Exchange Server 2007 Readiness Check, you should document some information about your environment. The collected information can be used to roll back to an previous environment or configuration, and it is useful as reference material for comparing the existing environment to the environment to which you transition. You should document the following Exchange organization settings: ◆ Mixed or native mode ◆ Processors, memory, disk storage, and network throughput

FINAL PREPARATIONS FOR DEPLOYMENT

◆ Exchange Server version and service pack level ◆ Server roles, such as front-end servers, dedicated bridgehead servers, Mailbox servers, and public folder servers ◆ Administrative group names and permissions assigned to Exchange administrators ◆ Exchange administrators and any permissions delegation that has been performed ◆ Database and log file locations, and any policies that are applied ◆ Backup and restore plan ◆ Routing group master, names and locations of servers, connectors and their properties ◆ Recipient policies, server policies, store policies, and any exemptions that have been applied at the user level ◆ The Simple Mail Transfer Protocol (SMTP) namespace for all domains for which the Exchange organization is authoritative ◆ Recipient filters, sender filters, address filters, message size limits, and message formats ◆ Virtual server configuration, authentication and encryption settings, and secure relationships with other domains ◆ Antivirus software installation locations and settings ◆ Intelligent Mail Filter spam confidence levels, IP Block List and IP Allow List settings, and attachment blocking settings ◆ Complete configuration information that includes IP addresses, authoritative domains, and real-time block list (RBL) subscriptions

Figure 10.1 Reporting the type of existing organization model

Exchange Server 2007, Exchange Server 2003, and Exchange 2000 Server store the following information in Active Directory: data about how the Exchange organization is configured; schema objects and attributes that are used in Exchange and recipient information. Exchange Server 2007 also uses Active Directory sites for routing.

253

254

CHAPTER 10 DEPLOYING EXCHANGE SERVER 2007

You should document the following Exchange Active Directory settings: ◆ Active Directory site names, directory servers in each site, and IP subnets that are associated with each site ◆ Sites included in each IP site link and costs that are assigned to each link ◆ Forest and domain functional levels ◆ Expansion Servers that expand distribution list membership and that use one or more global catalog servers to resolve the membership ◆ Security groups and security group membership for any groups that have been delegated administrative responsibility for the Exchange organization ◆ Document accounts that are members of Schema Admins and Enterprise Admins universal security groups ◆ The location (organizational unit) of each server within the directory You should also document your existing physical network, firewalls, and name resolution servers. Documenting these settings allows you to identify which locations are best suited for connectivity. You should document the following network settings: ◆ Network backbone, autonomous system connections, and available bandwidth ◆ DNS servers and Mail Exchanger (MX) records for your organization ◆ Firewall configuration with regard to port availability to external and internal systems ◆ Identify any servers that are located in a perimeter network or screened subnet, and the network services that they provide, especially any servers that provide SMTP-relay functionality Finally, identify any Exchange aware products, such as antivirus software, antispam software, backup software, and others, that will need to be upgraded to or replaced with newer versions of the software that are compatible with Exchange Server 2007. With this information, you’re ready to move on to the actual transition process: deploying new Exchange Server 2007 servers and then moving the existing messaging services and data to those servers. After all Exchange Server 2003 and Exchange 2000 Server servers are no longer providing any messaging services to the organization, they can be decommissioned.

Transition Task List: A Quick Guide The following is a short version of the steps required to transition an existing Exchange organization:

1. Conduct a Readiness Check. 2. Document the existing infrastructure. 3. Deploy and configure Client Access servers. 4. Deploy and configure Hub Transport servers. 5. Deploy and configure Mailbox servers. 6. Deploy and configure Edge Transport servers.

FINAL PREPARATIONS FOR DEPLOYMENT

7. Move resources from Exchange Server 2003 and Exchange 2000 Server servers to Exchange Server 2007 servers.

8. Uninstall Exchange Server 2003 and Exchange 2000 Server. 9. Remove connectors between routing groups and the routing groups. 10. Deploy and configure Unified Messaging servers. 11. Perform postinstallation tasks. Remaining Tasks Once you have established readiness (Step 1) and documented the existing organization (Step 2), you’re ready to work on the final phases:

1. Deploy and configure Client Access servers. The first Exchange Server 2007 server role that should be introduced into the organization is the Client Access server. You must deploy the Client Access server role in each Active Directory site that contains or will contain a Exchange 2007 Mailbox server(s). This does not mean that every site must contain a Client Access server before you can deploy Mailbox servers. Rather, it means that as each site is deployed, the first role to be deployed is the Client Access server.

2. Deploy and configure Edge Transport servers. 3. Transition all servers in a routing group to Exchange Server 2007 at the same time, in the following order:

a. Deploy and configure Hub Transport servers. b. Deploy and configure Mailbox servers. c. Move a test set of users to the Mailbox server to validate functionality. d. When Mailbox servers have been deployed, you can move mailboxes from Exchange Server 2003 and Exchange 2000 Server to Exchange Server 2007.

e. Move resources from Exchange Server 2003 and Exchange 2000 Server servers to Exchange Server 2007 servers, including all public folders and system folders.

f. Uninstall Exchange Server 2003 and Exchange 2000 Server. The uninstall process decommissions the servers and removes them from the Exchange organization.

g. Remove connectors between routing groups, and then remove the routing groups. 4. Deploy and configure Unified Messaging servers. The Unified Messaging server is new in Exchange Server 2007. The Unified Messaging server does not interoperate with earlier versions of Exchange Server. Remember that you cannot install and configure a Unified Messaging server until after you have deployed and configured a Hub Transport server and Mailbox server.

5. Perform postinstallation tasks Don’t Toss that Earlier Exchange Version Just Yet Not all features found in Exchange Server 2000 or Exchange Server 2003 are supported in Exchange Server 2007 Service Pack 1. If you plan on using them you will need to keep at least one Exchange Server 2000 or Exchange Server 2003 server in your organization depending on which features you need supported.

255

256

CHAPTER 10 DEPLOYING EXCHANGE SERVER 2007

The following Exchange 2000 Server features are not supported in Exchange Server 2007: ◆

Microsoft Mobile Information Server

◆

Instant Messaging service

◆

Exchange Chat Service

◆

Exchange 2000 Conferencing Server

◆

Key Management Service

◆

cc:Mail connector

◆

MS Mail connector

The following Exchange Server 2003 features are not supported in Exchange Server 2007: ◆

GroupWise connector

◆

X.400 connector

◆

Connector for Lotus Notes

Migrating from Lotus Notes to an Exchange Organization The process of moving from a Lotus Notes directory and messaging system to Active Directory service and Microsoft Exchange Server 2007 occurs in three distinct phases: ◆ Plan and prepare ◆ Interoperate ◆ Migrate

Planning and Preparing The first phase, plan and prepare, involves the following: ◆ Collecting information about the current mail environment. ◆ Learning about Microsoft and third-party integration and migration tools and their capabilities. ◆ Planning for Active Directory and Exchange Server 2007. ◆ Determine whether the current network design, topology, and bandwidth are adequate for the new messaging environment. ◆ Determine where to place the Microsoft Exchange Server 2007 servers, and which Microsoft Exchange and Lotus Domino servers will be connected for directory synchronization and mail routing during a coexistence period. You should also define an overall plan and schedule. Ideally, the plan should be tested in a lab environment that simulates the production environment as closely as possible.

Interoperating Once you have migrated some users to Exchange Server 2007, you then face the question of how to ensure communication between them and the other users still using Lotus Notes. Both

FINAL PREPARATIONS FOR DEPLOYMENT

environments use the interoperability tools available from Microsoft to synchronize directory information and to perform free/busy lookups. Mail is routed between the Lotus Domino 6.x and 7.x servers and Exchange Server 2007 servers via Simple Mail Transfer Protocol (SMTP). Issues that you should consider when planning for interoperability include: ◆ Preserving message paths to maintain uninterrupted message transfer to the correct destinations regardless of the recipient’s mail platform ◆ Maintaining user and distribution lists and groups in both directories during the interoperating phase ◆ Synchronizing calendar information to provide all users with current free/busy information

Migrating Users are next moved from the Lotus Domino messaging platform to Exchange Server 2007. Migrating users in batches allows you to modify and update the migration and training methodologies based on experience. This approach also limits the number of users migrated to a new platform and thus reduces the number of calls to the helpdesk by new users. Users should be batched based on their workgroups and locations, so that users and their assistants are able to continue to work together with minimal interference.

Note It’s always a good idea to perform a pilot run with a subset of users to work out the pain points. While users are being migrated in batches, they require the ability to send mail and check free/busy information for users on both systems. Once all users have been migrated to Exchange, the interoperate and migrate phases are completed.

Migrating from Exchange Server 5.5 As you should know by now this is impossible. You cannot migrate, upgrade, or transition an existing Microsoft Exchange Server 5.5 organization directly to Exchange Server 2007. You must first migrate from the Exchange Server 5.5 organization to an Exchange Server 2003 or an Exchange 2000 Server organization. Then you can transition the Exchange Server 2003 or Exchange 2000 Server organization to Exchange Server 2007.

Deployment Tips ◆

It’s always a good idea to perform a pilot run with a subset of users to work out the pain points.

◆

Exchange Server 2007 only ships on DVD — make sure the servers have DVD drives. Otherwise be prepared to copy the installation media before you start the install. The Exchange installer doesn’t always work on network drives.

◆

You can’t do in-place upgrades of previous Exchange versions, so you’ll need to move mailboxes to the new Exchange Server 2007 machines. Do this when users are offline.

◆

Prepare legacy exchange permission on the domains that contain Exchange Server 2003 machines.

257

258

CHAPTER 10 DEPLOYING EXCHANGE SERVER 2007

◆

Since only Mailbox servers can be clustered, if you’re deploying CCR or SCC, you’ll need additional servers to provide redundancy for Hub Transport, Client Access and Unified Messaging roles.

◆

Exchange Edge and ISA can’t run on the same server.

◆

LCR and CCR can only protect one database per storage group. Your storage group design must provide enough headroom.

◆

Office Communicator and Entourage need the system free/busy public folder. If using them make sure you say ‘‘yes’’ when asked if you’re supporting pre-Outlook 2007 clients.

◆

The setup utility needs Internet access to check for hotfix and patch prerequisites.

◆

Use the Exchange 2007 management tools to move mailboxes to an Exchange Server 2007 machine. The new tools are faster and have better error checking than past versions.

◆

For load balancing, cluster Mailbox servers.

◆

Availability of the Client Access, Hub Transport and Unified Messaging roles can be improved by deploying multiple nodes and using network load balancing.

◆

If the Client Access server and Mailbox server roles are going to be on the same server, exprox.dll has a problem with redirection and will use the internal server name causing Outlook Web Access (OWA) to fail if they are going through the Client Access server to a Exchange Server 2003 mailbox, which is common in a simple setup. For more details, see http://technet.microsoft.com/en-us/library/bb885041.aspx.

Installing Exchange Server 2007 with Service Pack 1 Once you have determined that you have the necessary prerequisites and system requirements, and understand how you want to deploy your server roles and to which computers, you are ready to perform the actual installation, which is quite simple. You can install Exchange Server 2007 server roles on a computer in two ways: ◆ Use the Exchange Server 2007 Setup Wizard. ◆ Use the Setup command at a command prompt if you want to create a script to perform the installation. The suggested deployment order for the most common server roles is Client Access server, Mailbox server, and Hub Transport server. If you deploy server roles on different physical servers, you need to ensure fast network links between them. For example, you need at least 100 Mbit links between Client Access and Mailbox servers — 1 Gbit is better. Let’s walk through a typical installation.

Installing Using the Setup Wizard Exchange Server 2007 Setup Wizard gives you the option of choosing either a typical or custom setup. To perform the following procedure, the account you use must be delegated membership in the Schema Administrators group if you have not previously prepared the Active Directory schema. If you are installing the first Exchange Server 2007 server in the organization, the account you use must have membership in the Enterprise Administrators group. If you have already prepared

INSTALLING EXCHANGE SERVER 2007 WITH SERVICE PACK 1

the schema and are not installing the first Exchange Server 2007 server in the organization, the account you use must be delegated the Exchange Organization Administrator role. Note also that an Exchange Server Administrator can install a server unless it’s the first of its role.

Exchange Server Administrators This role is a fundamental change over Exchange 2000 and Exchange 2003, since members of this role have permissions to administer one or more servers but do not have any permissions over global configuration options. This gets around the problem of delegating access at administrative group level and the situation where an administrator may have access to servers that he or she should not have. Also, Exchange Server Administrators cannot uninstall an Exchange server; they can add and remove server roles, but they cannot remove the last server role and thus ultimately remove the Exchange server. To install using the Setup Wizard, do the following:

1. Log on to the server on which you want to install Exchange Server 2007. 2. Insert the Exchange Server 2007 DVD into the DVD drive. If Setup.exe does not start automatically, navigate to the DVD drive and double-click Setup.exe. The welcome screen appears.

3. The setup program starts. On the Start page, complete Steps 1 through 3 if they need to be done. If you already have Microsoft .NET Framework 2.0, Microsoft Management Console (MMC) 3.0, and Microsoft Windows PowerShell installed, these steps will be grayed out.

259

260

CHAPTER 10 DEPLOYING EXCHANGE SERVER 2007

4. On the Start page, click Step 4: Install Microsoft Exchange. Setup copies the setup files locally to the computer on which you are installing Exchange Server 2007.

5. In the Exchange Server 2007 Setup Wizard, on the Introduction page, click Next. 6. On the License Agreement page, select I accept the terms in the license agreement, and then click Next.

INSTALLING EXCHANGE SERVER 2007 WITH SERVICE PACK 1

7. On the Customer Feedback page, choose the appropriate selection, and then click Next.

8. On the Installation Type page, you can choose between Typical Exchange Server Installation or Custom Exchange Server Installation.

If you chose the Typical Exchange Server Installation option, Client Access, Hub Transport, and Mailbox Server will automatically be selected. You will not be able to install the Unified Messaging server role, Edge Transport server role, or clustered Mailbox servers during

261

262

CHAPTER 10 DEPLOYING EXCHANGE SERVER 2007

this installation. You can add additional server roles later if you choose not to install them during this installation. Selecting Custom Server Installation allows you to add these roles and options at this time. If you selected Custom Exchange Server Installation you will be taken to the Server Role Selection page. There you can do any or all of the following: ◆ Decide which of the Exchange Server 2007 server roles you want to install. ◆ Install a clustered Mailbox server. ◆ Install only the Exchange management tools (which include the Exchange Management Console, the Exchange Management Shell, the Exchange Help file, the Microsoft Exchange Best Practices Analyzer Tool, and the Exchange Troubleshooting Assistant Tool). If you want to change the path for the Exchange Server 2007 installation, click Browse, locate the appropriate folder in the folder tree, and then click OK. Click Next.

Note If you were installing Exchange Server 2007 in a forest that has an existing Exchange Server 2003 or Exchange 2000 Server organization, on the Mail Flow Settings page, you would select a bridgehead server in the existing organization that is a member of the Exchange Server 2003 or Exchange 2000

INSTALLING EXCHANGE SERVER 2007 WITH SERVICE PACK 1

routing group to which you want to create a routing group connector. As mentioned earlier, Exchange Server 2007 does not use routing groups, but a routing group connector is required to allow mail flow between the Exchange Server 2007 routing group and the routing group in the Exchange Server 2003 or Exchange 2000 organization.

9. If this is the first Exchange Server 2007 server in your organization, on the Exchange Organization page, type a name for your Exchange organization. The name can only contain alphanumeric characters, spaces, hyphens and dashes and must be less than 64 characters in length.

10. If this is the first Exchange Server 2007 server in your organization, on the Client Settings page, click the option that describes the client computers in your organization that are running Microsoft Outlook. If you have client computers that are running Outlook 2003 or earlier and you select Yes, Exchange Server 2007 will create a public folder database on the Mailbox server. If all of your client computers are running Office Outlook 2007, public folders are optional in Exchange Server 2007. If you select No, Exchange Server 2007 will not create a public folder database on the Mailbox server. If you need to, you can add a public folder database later.

11. On the Readiness Checks page, the installation program will check if the organization and server role prerequisite checks were completed successfully. If not, it will stop the installation from continuing further until the failing is corrected. If they have completed successfully, click Install to install Exchange Server 2007. The installation process then starts.

263

264

CHAPTER 10 DEPLOYING EXCHANGE SERVER 2007

12. Once it is done, you are shown the Completion page. You can then click Finish. After you install Exchange Server 2007, you should verify the installation, a task covered in ‘‘Postinstallation Tasks’’ later in this chapter.

Note After you install any Exchange Server 2007 server roles on a computer, you cannot use the Setup wizard to add any additional server roles to this computer. If you want to add more server roles to a computer, you must either use Add or Remove Programs from Control Panel or use Setup.com from a command prompt window.

Note Prior to Exchange 2000 Server7 Service Pack 1, if you had any domain controllers that were running Windows 2000 Server and were installing the release to manufacturing (RTM) version of Exchange Server 2007, you had to run Setup.com from a command prompt window, and use the /DomainController parameter to specify a domain controller that is running Windows Server 2003 SP1. That is no longer required.

INSTALLING EXCHANGE SERVER 2007 WITH SERVICE PACK 1

Installing Exchange Server 2007 Using the Setup Command Exchange Server 2007 supports command-line installations, which can be very useful if you want to use unattended installations.

1. Log on to the target server. 2. Insert the Exchange Server 2007 DVD into the DVD drive, and then, at the command prompt, navigate to the DVD drive, or navigate to the network location of the Exchange Server 2007 installation files.

3. At the command prompt, execute setup, passing the options you want to use for installation. For example, the following: Setup.com /mode:install /Roles:C, H, M /On:CrystalPalace /dc:quark.majestic12.net /EnableLegacyOultook /LegacyRoutingServer:Sauron2003 /DisableErrorReporting

This tells the installation procedure to do the following: ◆ Install the Client Access, Hub Transport, and Mailbox roles in the CrystalPalace Organization. ◆ Use quark.majestic12.net as the domain controller. ◆ Enable support for legacy Outlook clients. ◆ Create a routing group connector to legacy Exchange servers with Sauron2003 as bridgehead on the legacy side of the connector. ◆ Disable the option to report errors back to Microsoft.

Note For a full list and explanation of all switches, visit the Microsoft website at http://technet .microsoft.com/en-us/library/aa997281.aspx.

4. The Setup program copies the setup files locally to the computer on which you are installing Exchange Server 2007.

5. The Setup program checks the prerequisites, including all prerequisites specific to the server roles that you are installing. If you have not met all of the prerequisites, Setup fails and returns an error message that explains the reason for the failure. If you have met all of the prerequisites, Setup installs Exchange Server 2007.

6. Verify that the installation was completed successfully. New Command-Line Parameters in Service Pack 1 The following command-line parameters have been added for Exchange Server 2007 Service Pack 1. This command upgrades an Exchange Server 2007 server to Exchange Server 2007 SP1: Setup.com /mode:Upgrade

265

266

CHAPTER 10 DEPLOYING EXCHANGE SERVER 2007

This command installs a CMS using cluster continuous replication (CCR) in an environment that has both IPv4 and IPv6 networks: Setup.com /mode:install /role:Mailbox /NewCms /CmsName:ExchCMS01 /CmsIPv4Networks:”Cluster Network 1”,”Cluster Network 2” /CmsIPv6Networks:”Cluster Network 1”,”Cluster Network 2”

Exchange Server 2007 also has the ability for an administrator to assign the responsibility for completing the installation of a server to another user with the /NewProvisionedServer command switch. In this scenario, an enterprise administrator executes the heavily permissioned parts of the installation procedure to create the server object and add the delegated account to the local administrators group on the target server. The delegated user account is also added to the Exchange View Only administrators group. Effectively, the enterprise administrator delegates enough authority to allow the designated user to run Setup to complete the actual creation of the physical server (such as moving files to the right location on the disk, etc.). The other user only has the necessary permission to be able to complete the installation of the designated server and can take no other action.

Postinstallation Tasks A few moments ago a screen popped up and told you installation was completed and you had the warm self-satisfied feeling that comes from clicking the ‘‘Finish’’ button. I hate to tell you this, but the screen lied. You’re not really finished yet. While the bulk of the work is done, there are still some housekeeping chores and last minute items to attend to. These postinstallation tasks will help you verify the installation. You will also have to take a few moments to configure the components that you have just installed. The topics in this section provide information about these postinstallation tasks. Because each server role offers several features that you can configure for your organization, make sure that you complete the postinstallation tasks for each server role that you install on a computer.

Verifying the Installation To verify that Exchange Server 2007 installed successfully, run the Get-ExchangeServer cmdlet in the Exchange Management Shell. As you can see in Figure 10.2 a list is displayed of all Exchange Server 2007 server roles that are installed on the specified server when this cmdlet is run.

Figure 10.2 Confirming that the installation is complete

POSTINSTALLATION TASKS

During installation, Exchange setup logs events in the Application log of Event Viewer on computers that are running Microsoft Windows 2000 Server or above. Examine the Application log and confirm that there are no warning or error messages related to Exchange server setup. During the setup process, information about the progress of setup is logged in the Exchange setup log file at C:\ExchangeSetupLogs\ExchangeSetup.log. These log files contain a history of actions that the system takes during setup and any errors that have occurred. By default, the logging method is set to verbose. It is certainly possible to review the setup log, but the level of detail that it captures is more than verbose, it’s garrulous and wading through the file line by line can be tedious and time consuming. You can filter the application event log for events written by MSExchangeSetup and check for events 1000 (starting to install a server role) and 1001 (successfully installed a server role). I also suggest that you review these logs by using a search for the string ‘‘error.’’ If you come across an entry like that you can read the text around it to determine the cause of the error. Alternately, you can use a PowerShell script called Get-SetupLog.ps14 to parse the contents of the setup log and report the entries found there.

Verifying the Default Configuration of the Hub Transport Server Agents Once you’ve installed Exchange Server 2007, you must enable and configure the agents that provide the messaging features that you want to deploy. An agent is a managed software component that performs a task in response to an Exchange Server 2007 event. Transport agents in Exchange Server 2007 perform tasks that support messaging policy and compliance and the Built-in Protection features that support antispam and antivirus prevention and management. By default, all the transport agents listed in Table 10.2 are installed on the Hub Transport server role. An agent must be installed and enabled for you to use the associated transport feature. Only the agents that provide the messaging features that are designed to be deployed inside the organization are installed by default. Agents that are not installed are designed for use in the boundary network on a computer that has the Edge Transport server role installed. To view the agent configuration, run the Get-TransportAgent command in the Exchange Management Shell.

Table 10.2:

Default Configuration for Agents on the Hub Transport Server Role

Agent

Default State

Transport Feature Group

Journaling agent

Installed, Enabled

Messaging policy and compliance

Transport Rule agent

Installed, Enabled

Messaging policy and compliance

Note You can install the antispam agents on the Hub Transport server role by using the provided InstallAntiSpamAgents.ps1 script. The script is located in the %programfiles%\Microsoft\ ExchangeServer\Scripts folder. After you run this script, all of the antispam agents are installed and enabled, and the Anti-spam tab is available in the Exchange Management Console.

267

268

CHAPTER 10 DEPLOYING EXCHANGE SERVER 2007

Verifying the Default Configuration of the Edge Transport Server Agents All the transport agents listed in Table 10.3 are available on the Edge Transport server role. An agent must be installed and enabled for you to use the associated transport feature. Only the agents that provide the messaging features that are designed to be deployed in the perimeter network are installed by default. The agents that are not installed are designed for use inside the organization on a computer that has the Hub Transport server role installed. Table 10.3 shows the default configuration for agents on the Edge Transport server role.

Table 10.3:

Default Configuration for Agents on the Edge Transport Server Role

Agent

Default state

Transport feature group

Address Rewriting Inbound agent

Installed, Enabled

Messaging policy and compliance

Address Rewriting Outbound agent

Installed, Enabled

Messaging policy and compliance

Attachment Filter agent

Installed, Enabled

Anti-spam and antivirus

Connection Filter agent

Installed, Enabled

Anti-spam and antivirus

Content Filter agent

Installed, Enabled

Anti-spam and antivirus

Edge Rule agent

Installed, Enabled

Messaging policy and compliance

Protocol Analysis agent

Installed, Enabled

Anti-spam and antivirus

Recipient Filter agent

Installed, Enabled

Anti-spam and antivirus

Sender Filter agent

Installed, Enabled

Anti-spam and antivirus

Sender ID agent

Installed, Enabled

Anti-spam and antivirus

Configuring Authoritative Domains for the Exchange Organization An authoritative domain is created when you create an accepted domain and set the accepted domain type as authoritative. Accepted domains are any Simple Mail Transfer Protocol (SMTP) namespace for which an Exchange organization sends and receives email. Accepted domains include those domains for which the Exchange organization is authoritative. An Exchange organization is authoritative when it handles mail delivery for recipients in the accepted domain. Accepted domains also include domains for which the Exchange organization receives mail and then relays it to an email server that is outside the Exchange organization for delivery to the recipient. You must configure an accepted domain before that SMTP namespace can be used in an email address policy. The accepted domain name is automatically populated to the email address policy editor. Each domain or subdomain that you want to use in an email address policy must have an explicit accepted domain entry. The email address policy determines the email address for the users who have mailboxes in the Exchange organization. Configure the SMTP domain that you want to use for these email addresses as an authoritative domain.

POSTINSTALLATION TASKS

By default, one accepted domain exists and is configured as authoritative for the Exchange organization during installation. The default authoritative domain is the fully qualified domain name (FQDN) of your Active Directory directory service forest root domain. In many organizations the internal domain name differs from the external domain name. For example, your internal domain name may be farscape.local, and your external domain name may be farscape.net The public domain name system (DNS) MX resource record for your organization will reference farscape.net. To send and receive email across the Internet, you will have to assign farscape .net as the SMTP email address for the users in your organization. There are two methods to create an authoritative domain, using the Exchange Management Console and the Exchange Management Shell.

Using Exchange Management Console to Create an Authoritative Domain Using Exchange Management Console to create an authoritative domain, follow these steps:

1. Open the Exchange Management Console. 2. In the console tree, click Organization Configuration, and then click Hub Transport. 3. In the work pane, click the Accepted Domains tab. 4. In the action pane, click New Accepted Domain. The New Accepted Domain Wizard appears.

5. On the New Accepted Domain page, complete the name — which is the title the user sees — and Accepted Domain, which identifies the SMTP namespace for which the Exchange organization will accept messages.

6. Make sure that the radio button next to Authoritative Domain. Email is delivered to a recipient in this Exchange organization is selected.

7. Click New. 8. On the Completion page, click Finish.

269

270

CHAPTER 10 DEPLOYING EXCHANGE SERVER 2007

Using the Exchange Management Shell to Create an Authoritative Domain To use the Exchange Management Shell to create an authoritative domain, run the following command: New-AcceptedDomain -Name ”SCAPE” -DomainName majestic12.net -DomainType Authoritative

Configuring Authoritative Domains on the Edge Transport Server Role As with an Exchange organization, accepted domains are any Simple Mail Transfer Protocol (SMTP) namespace for which the Edge Transport server sends and receives email. An Edge Transport server may send and receive email for more than one SMTP domain. Accepted domains also include domains for which the Exchange organization receives mail and then relays it to an email server that is outside the Exchange organization for delivery to the recipient. The Edge Transport servers should always accept email that is addressed to any of the organization’s authoritative domains.

Note Do not perform this procedure on an Edge Transport server that has been subscribed to the Exchange organization by using the Microsoft Exchange EdgeSync service. Instead, you should create the accepted domain on the Hub Transport server. It will be replicated to the Edge Transport server when synchronization next occurs. If you try to create or modify an accepted domain entry on an Edge Transport server that is subscribed to the Exchange organization, an error will occur.

Using the Exchange Management Console to Create an Authoritative Domain on an Edge Transport Server To use the Exchange Management Console to create an authoritative domain on an Edge Transport server, follow these steps:

1. Open the Exchange Management Console. 2. In the work pane, click the Accepted Domains tab. 3. In the action pane, click New Accepted Domain. The New Accepted Domain Wizard appears.

4. On the New Accepted Domain page, complete the Name and Accepted Domain fields. Ensure that the radio button next to Authoritative Domain. Email is delivered to a recipient in this Exchange organization.

5. Click New. 6. On the Completion page, click Finish. Using the Exchange Management Shell to Create an Authoritative Domain on an Edge Transport Server To use the Exchange Management Shell to create an authoritative domain on an Edge Transport server, run the following command: New-AcceptedDomain -Name ”SCAPE” -DomainName majestic12.net -DomainType Authoritative

POSTINSTALLATION TASKS

Using the Security Configuration Wizard The Security Configuration Wizard (SCW) is an often overlooked tool introduced with Microsoft Windows Server 2003 Service Pack 1. The SCW can be used to minimize the attack surface for servers by disabling Windows functionality that is not required for Microsoft Exchange Server 2007 server roles. The SCW automates the security best practice of reducing attack surface for a server. The SCW uses a role-based metaphor to solicit services that are required for the applications on a server. This tool reduces the susceptibility of Windows environments to exploitation of security vulnerabilities. Before you begin using SCW, you need to register the SCW extensions for the server roles. You can do this with these commands. The first command registers the extensions for any role except the Edge server; the second registers the extension for the Edge server. Scwcmd register /kbname:”SCAPE-Edge” /kbfile:”%programfiles%\ Microsoft\Exchange Server\scripts\Exchange2007.xml” Scwcmd register /kbname:”SCAPE-Edge” / kbfile:”%programfiles%\Microsoft\Exchange Server\scripts\ Exchange2007Edge.xml”

Exchange Server 2007 provides an SCW template for each of the Exchange Server 2007 server roles. By using this template with the SCW, you can configure the Windows operating system to lock down services and ports that are not needed for each Exchange server role. When you run the SCW, you create a custom security policy for your environment. You can apply the custom policy to all Exchange servers in your organization. You can configure the following functionality by using the SCW: Server role The SCW uses the server role information to enable services and open ports in the local firewall. Client features Servers also act as clients to other servers. Select only the client features that are required for your environment. Administration options Select the options that are required for your environment, such as backup and error reporting. Services Select the services that are required for the server, and set the startup mode for services that are not specified by the policy. Unspecified services are not installed on the selected server and are not listed in the security configuration database. The security policy that you configure might be applied to servers that are running different services than the server where the policy is created. You can select the policy setting that determines the action to perform when an unspecified service is found on a server that this policy is applied to. The action can be set to not change the startup mode of the service or to disable the service. Network security Select the ports to open for each network interface. Access to ports can be restricted based on the local network interface or based on remote IP addresses and subnets. Registry settings Use the registry settings to configure protocols that are used to communicate with other computers. Audit policy The audit policy determines which success and failure events are logged and the file system objects that are audited.

271

272

CHAPTER 10 DEPLOYING EXCHANGE SERVER 2007

Performing Exchange Management Console Postinstallation Tasks When you select the Microsoft Exchange node in the Exchange Management Console, the result pane displays two tabs: Finalize Deployment and End-to-End Scenario. Each task on these tabs includes a link to more information or specific instructions that will help you navigate the Exchange Management Console to configure the selected task. Figure 10.3 shows a typical listing.

Figure 10.3 Finalize Deployment Tasks as shown in Exchange Management Console

Finalize Deployment Tasks Finalize Deployment tab tasks are required to complete the deployment of your Exchange Server 2007 organization. The tasks, some of which are shown in Figure 10.4, apply to features that are enabled by default but require additional configuration: Enter the Product Key. To enter the product key, click Server Configuration in the Exchange Management Console, select an Exchange Server 2007 server, and then click Enter Product Key in the action pane. You can also enter the product key by using the Set-ExchangeServer cmdlet. The Enter Product Key Wizard is available only if you installed the 64 bit version of Exchange Server 2007. Run the Exchange Server Best Practices Analyzer. To complete your verification of a successful installation, it is a best practice to run the Exchange Server Best Practices Analyzer. The

POSTINSTALLATION TASKS

Exchange Server Best Practices Analyzer automatically examines an Exchange Server deployment and determines whether the configuration is set according to Microsoft best practices. After you install or upgrade Exchange, or after you make configuration changes, you should run the Exchange Server Best Practices Analyzer. You can run the Exchange Server Best Practices Analyzer from the Toolbox in the Exchange Management Console. Figure 10.4 shows a typical health report.

Figure 10.4 Best Practices Analyzer Health Status report of an Exchange 2007 Server

Install Microsoft Forefront Security for Exchange. Forefront Security is a Microsoft product that integrates multiple scan engines from industry-leading security firms in a single solution to help protect your Microsoft Exchange Server 2007 messaging environments from viruses, worms, spam, and inappropriate content. Despite its inclusion in the Finalize Deployment list it is not a mandatory purchase. You should, of course, employ all possible means to protect your Exchange Server 2007–based messaging system. Mailbox Server Role Tasks Configure offline address book (OAB) distribution for Outlook 2007 clients so they can take advantage of new Web-based distribution method. Configure OAB public folder distribution for Office Outlook 2003 and earlier clients to ensure coexistence. Configure mailbox limits. Configure managed folder policies. Client Access Server Role server.

Configure Secure Sockets Layer (SSL) for your Client Access

Configure Exchange ActiveSync. By default, when you install the Client Access server role on a computer that is running Exchange Server 2007, Exchange ActiveSync is enabled. However,

273

274

CHAPTER 10 DEPLOYING EXCHANGE SERVER 2007

I recommend that you configure security, authentication, and policy settings if you plan to use ActiveSync in your environment. Configure Autodiscover. Configure remote access methods OWA, IMAP, POP, Outlook Anywhere. Configure external URLs for OAB, Active sync OWA. Hub Transport Server Role Tasks messages.

Configure domains for which you will accept email

Subscribe the Edge Transport server for one-way replication of recipient and configuration information. Configure Internet mail flow. By default, a Hub Transport server is not configured for Internet mail flow. If you do not subscribe an Edge Transport server to your Exchange organization, you must use either deploy an Edge Transport server and manually configure the Send connectors and Receive connectors that are required for Internet mail flow, or manually configure Internet mail flow between your Exchange Server 2007 organization and Microsoft Exchange Hosted Services or other external SMTP gateway servers. Configure an external postmaster recipient to receive email messages. Unified Messaging Server Role Tasks

Create a New Unified Messaging Dial Plan.

Create a New Unified Messaging IP Gateway. These first two tasks are required to configure the first UM server in your organization, or the first UM server in a new dial plan. To configure an additional UM server for an existing dial plan, you only need to add it to an existing dial plan. Add to a Dial Plan. Enable a User for Unified Messaging. Configure Unified Messaging and Office Communication Server integration. Edge Transport Server Role Tasks

Subscribe the Edge Transport server.

Use the Security Configuration Wizard. Configure an external postmaster recipient to receive mail. Configure Domain Name System (DNS). The Edge Transport server must be configured for internal DNS lookups within the Exchange organization and external DNS lookups for external recipients. Public DNS records must also be configured for this server to send or receive mail from the Internet.

End-to-End Scenario Tasks The tasks on the End-to-End Scenario tab are optional for configuring features. The recommended tasks are: ◆ Configure monitoring for Exchange Server 2007. Monitoring tools will be discussed in Chapter 11. ◆ Mailbox Server role tasks include the following: ◆

Implementing Best Practices for Disaster Recovery

POSTINSTALLATION TASKS

◆

Configuring the Spam Confidence Level for User’s Junk E-mail Folder Threshold

◆

Configuring Messaging Records Management

◆ Client Access server role tasks are: ◆

Enable Outlook Anywhere (this is discussed below)

◆

Verify that Microsoft Office Outlook 2007 Autodiscover is enabled and configured correctly.

◆ Hub server roles to be considered include: ◆

Replicate Safelist Aggregation Data.

◆

Configure Spam quarantine.

◆ Unified Messaging tasks: ◆

Enable outdialing to allow calls to be transferred to users outside a UM dial plan.

◆

Enable mutual-TLS between IP gateways or IP PBXs and an Exchange Unified Messaging (UM) server.

◆

Create and configure a UM auto-attendant. The auto-attendant is a set of voice prompts (in .wav format) that are played to callers in place of a real person when they call into a business or other enterprise with Unified Messaging.

◆ Edge Transport server role–related configuration tasks: ◆

Create an alias and mailbox for quarantine message delivery.

◆

Enable the Microsoft Exchange Anti-spam Update Service.

◆

Configure the list of internal Simple Mail Transfer Protocol (SMTP) servers.

◆

Replicate Safelist Aggregation Data.

Deploying Outlook Anywhere The Outlook Anywhere feature for Microsoft Exchange Server 2007 lets users connect to their Microsoft Exchange information from any location by using the Internet. This feature eliminates the need to use a virtual private network (VPN) to access computers that are running Exchange Server 2007 or Microsoft Exchange Server 2003 from outside an organization’s network. By default, when you install the Client Access server role on a computer that is running Exchange Server 2007, Outlook Anywhere is not enabled. Additionally, based on your topology, there are several postinstallation tasks that you might have to perform after you enable Outlook Anywhere. To enable Outlook Anywhere, you must follow these steps in order:

1. Install a valid Secure Sockets Layer (SSL) certificate from a certification authority (CA) that is trusted by Outlook clients.

2. Install the Windows RPC over HTTP proxy component. 3. Enable Outlook Anywhere on an Exchange Server 2007 Client Access server by using the Enable Outlook Anywhere Wizard.

4. Configure Exchange services, such as the Availability service, for external access.

275

276

CHAPTER 10 DEPLOYING EXCHANGE SERVER 2007

Note Be careful as you configure Exchange services for external access. This is among the most common sources of problems during deployment of Exchange Server 2007. An excellent explanation and discussion can be found at http://exchange-genie.blogspot.com/2007/07/autodiscoverad-attribute.html.

Note When you install Exchange Server 2007, you can install a default SSL certificate that is created by Exchange Setup. However, this certificate is not a trusted SSL certificate and will not work for Outlook Anywhere.

Deployment Options for Outlook Anywhere When you deploy Outlook Anywhere, you have several deployment options. The option you choose depends on your current messaging environment. Generally, when you deploy Exchange Server 2007, it is recommended that you start by deploying Client Access servers. Client Access servers provide Outlook Anywhere access to clients that are running Outlook 2007 or RPC over HTTP access to clients that are running Outlook 2003. Access is provided to Exchange Server 2007 servers that have the Mailbox server role installed or to Exchange Server 2003 back-end servers that have been enabled for RPC over HTTP. Note also that the number of connections that a server can handle for Outlook requests is determined primarily by the hardware that you are using. If your organization requires many concurrent Outlook Anywhere users, use hardware that will support these connections. It is recommended that you use 64 bit servers to support many Outlook Anywhere users. Table 10.4 describes the Client Access server deployment options that you can choose from. It shows which clients you can use with the various versions of Microsoft Exchange.

Table 10.4:

Outlook Anywhere Deployment Options

Mailbox Location

Deployment Details

Exchange Server 2007 Client Access servers can provide Outlook Anywhere access for Outlook 2007 servers with the Mailbox and Outlook 2003 to Exchange Server 2007 servers that have the Mailbox server role installed server role installed. However, Outlook 2003 clients cannot use the Autodiscover service. Exchange Server 2003 back-end servers that are running Exchange Server 2003 Service Pack 1 (SP1) or later

Client Access servers can provide access to Exchange Server 2003 back-end servers that are running SP1 or a later version for Outlook 2007 and Outlook 2003. After you enable the Client Access server for Outlook Anywhere, you can enable any new Exchange Server 2003 back-end servers for RPC over HTTP access by using Exchange System Manager in Exchange Server 2003. Existing servers that are enabled for RPC over HTTP will not require additional changes.

POSTINSTALLATION TASKS

Table 10.4:

Outlook Anywhere Deployment Options (CONTINUED)

Mailbox Location

Deployment Details

Exchange Server 2003 back-end servers

Client Access servers can provide access to Exchange Server 2003 back-end servers that are not running SP1 or a later version. However, you must manually manage your servers. This means that you must manually edit the registry to provide access to Outlook 2007 and Outlook 2003 clients.

Exchange Server 2007 To use Outlook Anywhere in this deployment scenario, you must restart the with Client Access server server after you see the event that reads ‘‘MSExchange RPC over HTTP an Mailbox server roles Autoconfig Event ID: 3002.’’ on a single machine (Single Server Deployment)

Deploying Exchange ActiveSync By default, when you install the Client Access server role on a computer that is running Exchange Server 2007, Exchange ActiveSync is enabled. However, there are several postinstallation deployment tasks that you can perform to enhance the security and performance of Exchange ActiveSync. Configure Direct Push to Work with Your Firewall Direct Push is the mechanism by which Exchange ActiveSync keeps your mobile devices up to date with your Exchange mailbox. A long-standing HTTPS request is created by the mobile device and sent to the Exchange server. Direct Push requires port 443 to be open on your firewall. Configure Policies for Exchange ActiveSync Exchange ActiveSync mailbox policies let you apply a common set of policy or security settings to a user or group of users. Some of the settings that you can configure include the following: ◆ Password requirements and settings ◆ Device encryption ◆ Access to Windows file shares and SharePoint Services files ◆ Attachment settings

Note A number of the new policies require Windows Mobile Server 6 or newer to use all features. Configure Mobile Devices to Synchronize with Exchange Server After the Client Access server role is installed, users can configure devices to synchronize with the Exchange server. Configure Security Settings for Exchange ActiveSync When the Client Access server role is installed, the Exchange ActiveSync virtual directory is configured for Basic authentication. Basic authentication sends information in clear text. By default, Secure Sockets Layer (SSL) is enabled. You can configure an additional authentication method on your Exchange ActiveSync

277

278

CHAPTER 10 DEPLOYING EXCHANGE SERVER 2007

virtual directory. You can use Basic authentication, Integrated Windows authentication, certificate-based authentication, or RSA SecurID. Configure the Autodiscover Service for Exchange ActiveSync The Autodiscover service provisions a user’s device when the user’s email address and password are supplied. The Autodiscover service returns the address to a computer that is running Exchange Server 2007 that has the Client Access server role installed. If you have multiple Client Access servers in your organization, you can configure the Autodiscover service to return the URL of the Client Access server that you want the users to use for synchronization. The ability to use the Autodiscover service depends on the mobile device operating system that you are using. Not all mobile device operating systems that support synchronization with Exchange Server 2007 support processing information from the Autodiscover service.

Moving Mailboxes As you’ve already determined way back in the beginning of this book, changing a corporate mail system is potentially one of the most disruptive and risky ventures any organization can undertake. It’s one thing to have a server go down or go bad; it’s entirely another when your activities contain in them the prospect of jeopardizing the organization’s basic communications fabric, as well as its service delivery capabilities and profit-making ability. At this point, one of the key challenges is how to transfer all the data most organizations have (including public folders, email messages, tasks, and calendars) from the previous messaging system to the new one. As you can imagine, this is going to be one of your key installation tasks when transitioning or migrating. If not done properly, not only may critical data be unavailable to users, but corporate activities will come to a screeching halt.

Strategies There are a number of traditional strategies when it comes to transferring mailboxes to Exchange Server 2007, each with its own associated benefits and risks. These include: An in-place upgrade involves converting the old Exchange Server to the new one on the same server. This involves upgrading to Windows Server 2003 Enterprise x64 Edition, removing Exchange Server 2003, renaming databases and directories, and converting databases. It is a labor-intensive process and subject to operator error. The benefits of this approach are that the number of additional servers required is less than the other options and you can complete the transfer process in the shortest time. In a Move Mailbox migration, mailboxes and users are moved to an already commissioned new Exchange Server 2007 server. This strategy gives you the luxury of initially having a new Windows Server x64 and Exchange Server 2007 environment to do lots of testing in — without impacting users or risking the corporate email service. The downside to this approach is the additional cost and the fact that you have to move mailboxes, which can involve considerable time and risk. A phased, or swing, migration, where the old Exchange Servers and new Exchange Server 2007 servers effectively run in parallel, and mailboxes and users are migrated gradually, appeals to larger organizations that have restricted budgets and many users to migrate. The theory is that maintaining the old Exchange Server 2003 service and the new Exchange Server 2007 service in parallel will make it possible to move users at a more leisurely pace, individually or department by department. With the phased migration approach, only a few new servers need be purchased because existing ones can be redeployed during the migration process.

MOVING MAILBOXES

In practice, however, many sites that have chosen this path have experienced great difficulty in maintaining both environments side by side. For example, Site Replication Services (SRS) with Exchange Server 2003 cannot be installed or doesn’t work in an Exchange Server cluster. So to support SRS it is necessary to deploy an additional Exchange Server 2007 server and make it the bridgehead between the two environments. This complicates the configuration and adds to the expense. No matter which strategy you employ, you are, sooner or later, going to have start the process of moving mailboxes and their contents.

Caveats and Tools To move mailboxes from Exchange 2003 or Exchange 2000 directly to Exchange 2007, you can use the Move Mailbox Wizard or the Move-Mailbox cmdlet. You cannot use the Exchange System Manager or Active Directory Users and Computers to move mailboxes from Exchange 2003 or Exchange 2000 to Exchange 2007. As you might expect, you cannot move mailboxes directly from Microsoft Exchange Server version 5.5 to Exchange 2007. To move mailboxes from Exchange Server 5.5 to Exchange 2007, you must first move the mailboxes to either Exchange 2003 or Exchange 2000 servers, and then move the mailboxes to Exchange 2007. If you move a mailbox from Exchange 2003 or Exchange 2000 to Exchange 2007, and the mailbox is part of an email address policy, the email addresses for that mailbox will be automatically updated based on the configuration of the email address policy. If the mailbox had a primary Simple Mail Transfer Protocol (SMTP) address that differs from the email address enforced by the email address policy, that SMTP address will become a secondary SMTP address and the email address generated by the email address policy will become the primary SMTP address. This behavior is different from Exchange 2003 and Exchange 2000. In Exchange 2003 or Exchange 2000, the email address policy is not applied to a mailbox when it is moved. To prevent accidentally changing the primary SMTP address of a mailbox in an Exchange 2007 environment, you must configure the mailbox so that is does not automatically update email addresses based on email address policy. To configure Exchange 2003 or Exchange 2000 mailboxes, in Active Directory Users and Computers, right-click the recipient, and then select Properties. On the E-mail Addresses tab, clear the Automatically update email addresses based on email address policy check box.

Note You cannot use the Move-Mailbox cmdlet to move mailboxes to an Exchange 2007 forest from a forest with a previous version of Exchange that contains only Windows 2000 Server domain controllers. The Move-Mailbox cmdlet can communicate with only Windows Server 2003 domain controllers.

Shared Mailboxes and Resource Mailboxes In addition to the default user mailboxes, you can create shared mailboxes and resource mailboxes in Exchange 2007. A shared mailbox is a mailbox to which multiple users can log on. A resource mailbox is a mailbox that represents a type of resource, such as a conference room or video equipment. Resource mailboxes have additional properties in Active Directory that user mailboxes and shared mailboxes do not have, such as capacity. Exchange 2003 and Exchange 2000 do not have resource mailboxes. Instead, you must use shared mailboxes to represent resources. If you move a shared mailbox from Exchange 2003

279

280

CHAPTER 10 DEPLOYING EXCHANGE SERVER 2007

or Exchange 2000 to Exchange 2007, the Move-Mailbox cmdlet creates the mailbox as a shared Exchange 2007 mailbox. After you move the mailbox to Exchange 2007, you can convert it to a resource mailbox.

Note You can access full instructions for conversion by visiting http://technet.microsoft .com/en-us/library/bb201749.aspx.

Moving a Mailbox within a Single Forest To perform the following procedures, the account you use must be delegated the Exchange Server Administrator role and local Administrators group for both the source server and the target server as well as the Exchange Recipient Administrator role for both the source organization and the target organization. Also note that you cannot use the Move Mailbox Wizard to move mailboxes across forests, but must use the Move-Mailbox cmdlet. You can run only one instance of the Move Mailbox Wizard from the Exchange Management Console at a time. However, if you want to run multiple Move Mailbox Wizards at the same time, you can open multiple Exchange Management Consoles and run one instance of the Move Mailbox Wizard from each console.

Using Exchange Management Console To use Exchange Management Console, follow these steps:

1. Start the Exchange Management Console. 2. In the console tree, expand Recipient Configuration, and then click Mailbox. 3. In the result pane, click the mailbox or mailboxes that you want to move. 4. In the action pane, click Move Mailbox. 5. In the Move Mailbox Wizard, on the Introduction page, click Browse to select the mailbox database to where you want to move the mailbox, and then click Next.

6. On the Move Options page, perform the following steps: a. Select an option for handling corrupted messages in a mailbox. b. (Optional) Specify a global catalog in the target forest to use for search operations. c. (Optional) Specify a domain controller in the target forest to use to write to the Active Directory service.

d. (Optional) If you are moving the mailbox to a database on an Exchange 2003 or Exchange 2000 server, specify whether you want to move rules.

7. Click Next. 8. On the Move Schedule page, specify when the move should occur, and then click Next. 9. On the Move Mailbox page, review the summary to confirm the mailbox moves, and then click Move.

10. On the Completion page, click Finish.

MOVING MAILBOXES

Using Exchange Management Shell To use Exchange Management Shell, follow these steps:

1. To move a mailbox to a destination in the same forest, run the following command. Note that if the value of any parameter, such as the database name, contains a space, you must enclose it in quotation marks. Move-Mailbox quark\dave -TargetDatabase ”First Storage Group\Mailbox Database”

Note For detailed syntax and parameter information, see http://technet.microsoft.com/en-us/ library/aa997599.aspx.

Moving a Mailbox across Forests As mentioned above, you cannot use the Exchange Management Console to move mailboxes across forests but are required to use the Exchange Management Shell for the task. The procedures outlined in this section can be used when you need to do the following: ◆ Move a mailbox from one Exchange Server 2007 forest to another Exchange Server 2007. ◆ Move a mailbox from an Exchange 2007 server in one forest to an Exchange 2003 server in another forest. ◆ Move a mailbox from a server running Exchange Server 2003 in one forest to an Exchange 2007 server in another forest. ◆ Move a mailbox from an Exchange 2000 server in one forest to an Exchange 2007 server in another forest.

Note When you want to move mailboxes from one forest to another without interrupting the user’s access to the mailbox, you should use the Move-Mailbox cmdlet with the AllowMerge parameter, as described in the next section.

To perform the following procedures, you need to make sure of the following: The account you use to run the command must be delegated the Exchange Server Administrator role on the server where you run the command. The account you use for the source forest must be delegated the following: ◆ Exchange Recipient Administrator role for the source Exchange organization ◆ Exchange Server Administrator role and local Administrators group for the source server You specify this account by using the -SourceForestCredential parameter.

281

282

CHAPTER 10 DEPLOYING EXCHANGE SERVER 2007

The account you use for the target forest must be delegated the following: ◆ Exchange Recipient Administrator role for the target Exchange organization ◆ Exchange Server Administrator role and local Administrators group for the target server You specify this account by using the -TargetForestCredential parameter. In addition to the permission consideration, you should make sure that you are aware of the following: ◆ The procedure only moves the mailbox, not the user account. You need to move the account to the target forest using a tool like the Active Directory Migration Tool version 3.0 (ADMT v3). ◆ When a mailbox is moved across forests dumpster items are lost except when you are merging mailboxes using the AllowMerge parameter. ◆ You need to use a tool such as Active Directory Migration Tool version 3.0 (ADMT v3) to move contacts or distribution groups from one forest to another. ◆ You cannot use the Move-Mailbox cmdlet to move mailboxes to an Exchange 2007 forest from a forest with a previous version of Exchange that contains only Windows 2000 Server domain controllers. The Move-Mailbox cmdlet can communicate with only Windows Server 2003 domain controllers. ◆ Unless you are in a resource forest scenario, you must move both the mailbox and the user account.

Using the Exchange Management Shell To use the Exchange Management Shell, follow these steps:

1. Move the user account to the target forest by using ADMT v3. 2. On the Exchange 2007 server where you will run the Move-Mailbox cmdlet, in the Exchange Management Shell, run the following command to create a credential object: $SourceCredential = Get-Credential

You will be prompted for credentials. Specify an account that has permissions to move the mailboxes in the source forest.

3. On the Exchange 2007 server where you will run the Move-Mailbox cmdlet, in the Exchange Management Shell, run the following command to create a credential object: $TargetCredential = Get-Credential

You will be prompted for credentials. Specify an account that has permissions to move the mailboxes in the target forest.

4. On the Exchange 2007 server, in the Exchange Management Shell, run the Move-Mailbox command to move the mailbox. For example: Move-Mailbox -TargetDatabase ”Target Server\ First Storage Group\Mailbox Database” -Identity dave -GlobalCatalog GC01.majestic12.net -SourceForestGlobalCatalog

MOVING MAILBOXES

GC02.majestic12.net -NTAccountOU ”OU=OrgUnit01,DC=samso,DC=com” -SourceForestCredential $SourceCredential -TargetForestCredential $TargetCredential

In this example, the command is run on a Mailbox server in the target forest. Majestic12 domain is in the source forest and the samso domain is in the target forest The GlobalCatalog and SourceForestGlobalCatalog parameters are used to locate the mailbox in the target and source forests. If you do not specify a source forest global catalog or a target forest global catalog, the forest for the local computer on which you are running the Move-Mailbox command will be used to determine a global catalog server to use. For mailbox moves across different forests, you must specify at least one of these two parameters. The DomainController parameter is used to identify a specific domain controller in the target forest for the mailbox move. If you do not specify a target forest domain controller, the local forest on which you are running the Move-Mailbox command will be used to determine a domain controller to use. The NTAccountOU parameter is used to specify the organizational unit in the target forest where the user account for the mailbox will be created. You cannot use the NTAccountOU parameter if you use the AllowMerge parameter. The AllowMerge parameter specifies that you want to merge the mailbox with a mailbox that already exists in the target forest.

Note For detailed syntax and parameter information, see http://technet.microsoft.com/en-us/ library/aa997599.aspx.

5. Check the command’s output to verify that the move completed successfully. 6. If the user whose mailbox was moved uses Microsoft Office Outlook 2003 or a previous version of Outlook, you must modify the Outlook profile of that user so that it accesses email messages from the target Exchange server.

7. Verify that the user can access email messages from an email client computer.

Merging Mailboxes Merging mailboxes can be a useful strategy when you want to move mailboxes from one forest to the other without interrupting a user’s access to the mailbox. When you move a mailbox from one forest to another, unless you are in a resource forest scenario, you must move both the mailbox and the user account. You must perform these two steps separately. To move the mailbox, you must use the Move-Mailbox cmdlet. To move the Active Directory directory service user account, you must use the Active Directory Migration Tool version 3.0 or something similar. If you are moving a large number of mailboxes across forests, users could be without access to their mailboxes for a significant amount of time. However, you can reduce the amount of time that users cannot access their mailboxes. First, run Move-Mailbox to move the mailbox from the source forest to the target forest, but do not delete the source mailbox or source user account. At this point, the user still has access to that source mailbox. Next, move the user account with ADMT v3, and then disable access to the source mailbox. Now the user cannot access the source mailbox but can access the target mailbox. Finally, run Move-Mailbox again using the AllowMerge parameter to move email messages contained in the source mailbox that were sent or received during the transition and were not moved to the target mailbox during the initial move.

283

284

CHAPTER 10 DEPLOYING EXCHANGE SERVER 2007

Note To perform the following procedures, the account you use must be delegated the Exchange Server Administrator role and local Administrators group for both the source server and the target server as well as the Exchange Recipient Administrator role for both the source organization and the target organization.

1. Move the user account to the target forest by using ADMT v3. 2. On the Exchange 2007 server where you will run the Move-Mailbox cmdlet, in the Exchange Management Shell, run the following command: Move-Mailbox -Identity dave -TargetDatabase ”Mailbox Database” -AllowMerge $true

Note If you use the AllowMerge parameter, you cannot use the SourceMailboxCleanupOptions parameter. If you want to delete the source mailbox after you merge mailboxes, you must do this manually after you run the Move-Mailbox command.

Taking Extreme Measures Sometimes deployment doesn’t quite work the way you planned, though it’s probably not your fault. If you have problems with a server, need to redeploy it, or simply need to mothball an existing system, there will come a time when you might need to modify or remove it. It’s not the first choice, but sometimes you have no choice but to terminate the server with extreme prejudice.

Modifying and Removing Servers To modify or remove an existing Exchange 2007 server, you can use either the Windows Control Panel (to add/remove software) or the ExSetup program, which you’ll find in the LaserProgram FilesLaserMicrosoftLaserExchange ServerLaserBin directory. This program has several modes: ◆ /Install: Add a new role to an existing Exchange 2007 server. ◆ /Uninstall: Remove a role or a complete Exchange 2007 server. For example, to remove the client access role from a server, use the following command: ExSetup /Mode:Uninstall /Roles:CA. You can also use the following switches: ◆ /Upgrade: Upgrade to a new release. ◆ /Recover Server: Recover a server using the information about it stored in the Active Directory. ◆ /Clustered: Designate an active role in a cluster.

TAKING EXTREME MEASURES

Modifying an Exchange Installation You can modify an Exchange 2007 installation in the following ways: ◆ Add an Exchange 2007 server role to an existing Exchange 2007 server. ◆ In a clustered scenario, designate the active node in the cluster. ◆ Remove Exchange 2007 server roles or remove Exchange from an Exchange 2007 server. To remove server roles or to remove Exchange, you must use the Control Panel in Windows Server or Setup.com from a command prompt window.

Note You cannot add an Exchange 2007 Service Pack 1 (SP1) server role to a computer that is running the release to manufacturing (RTM) version of Exchange 2007. To add an Exchange 2007 SP1 server role, you must first upgrade the server to Exchange 2007 SP1.

Note If you have Exchange 2007 SP1 installed on Windows Server 2003, you must use Exchange 2007 SP1 Setup.com or Add or Remove Programs from the Control Panel to add server roles. If you have Exchange 2007 SP1 installed on Windows Server 2008, you must use Exchange 2007 SP1 Setup.com or Programs and Features from the Control Panel to add server roles.

Using Setup.com to Modify an Exchange Installation To modify an Exchange installation with Setup.com, follow these steps:

1. Log on to the Exchange server you want modify. 2. Open a command prompt window and navigate to the directory where you installed Exchange. By default, this is %programfiles%\Microsoft\Exchange Server.

3. Navigate to the \bin directory. You have several options based on what you want to do: ◆ If you are adding a server role to or removing a server role from an existing Exchange 2007 server, at a command prompt, use the following code: Setup.com /mode:< setup mode > /roles:< server roles to install > [-OrganizationName:< name for the new Exchange organization >] [/TargetDir:< target directory >] [/SourceDir: ] [/UpdatesDir:< directory from which to install updates >] [/DomainController:< domain controller >] [/AnswerFile:< filename >] [/DoNotStartTransport] [/EnableLegacyOutlook] [/LegacyRoutingServer]

285

286

CHAPTER 10 DEPLOYING EXCHANGE SERVER 2007

[/EnableErrorReporting] [/NoSelfSignedCertificates] [/AdamLdapPort] [/AdamSslPort] [.AddUmLanguagePack:] [/?]

◆ If you are designating the active node of a clustered Mailbox server, use the following syntax for Setup.com: Setup.com [/NewCms] [/CMSName:< name >] [/CMSIPAddress:< IP address >] [/CMSSharedStorage] [/CMSDataPath:< CMS data path >] [/DomainController:< name of domain controller >]

Note You can find full details regarding the various parameters and options in the Exchange 2007 documentation.

Using the Control Panel to Modify an Exchange Installation Follow these steps to use the Control Panel to modify an Exchange installation:

1. In Control Panel, perform one of the following steps: ◆ If you are running Windows Server 2003, double-click Add or Remove Programs. ◆ If you are running Windows Server 2008, double-click Programs and Features.

2. In Add or Remove Programs or Programs and Features, select Microsoft Exchange Server 2007.

3. To remove server roles or remove Exchange, perform one of the following steps: ◆ If you are running Windows Server 2003, click Remove. ◆ If you are running Windows Server 2008, click Uninstall. ◆ To add server roles or to designate the active node in a cluster, click Change.

4. In the Exchange Server 2007 Setup Wizard, on the Exchange Maintenance Mode page, click Next.

5. On the Server Role Selection page, if you are removing server roles, clear the server roles that you want to remove, and then click Next. If you are adding server roles or adding a Clustered Mailbox server role, click the server role that you want to add, and then click Next.

TAKING EXTREME MEASURES

6. If you are adding the Hub Transport Role, and if you are installing Exchange 2007 in a forest that has an existing Exchange Server 2003 or Exchange 2000 Server organization, on the Mail Flow Settings page, select a bridgehead server in the existing organization that is a member of the Exchange 2003 or Exchange 2000 routing group to which you want to create a routing group connector.

7. On the Readiness Checks page, view the status to determine whether the organization and server role prerequisite checks completed successfully. If they completed successfully, click Uninstall to uninstall Exchange 2007 server roles or click Install to install Exchange 2007 server roles.

8. On the Completion page, click Finish.

Removing Exchange Server Roles from Windows 2003 and Windows 2008 Server If you need to remove an Exchange Server 2007 server role, the procedure you follow will differ depending on which platform you’ve deployed to originally. You can use either the Setup Wizard or Setup.com to accomplish these tasks.

287

288

CHAPTER 10 DEPLOYING EXCHANGE SERVER 2007

Using Setup Wizard to Remove a Server Role from Windows Server 2003

1. Log on to the server from which you want to remove Exchange 2007 server roles. 2. Open Control Panel and then double-click Add or Remove Programs. 3. On the Change or Remove Programs page, select Microsoft Exchange Server, and then click Remove.

Note Change allows you to add but not remove server roles. Why doesn’t it say ‘‘Add’’? Your guess is as good as mine.

4. In the Exchange Server 2007 Setup Wizard, on the Exchange Maintenance Mode page, click Next.

5. On the Server Role Selection page, clear the check boxes for the server roles that you want to remove, and then click Next.

Note Having already confused you about the meaning of ‘‘Change,’’ the program has it so that by default, all server roles are selected. This indicates that no server roles will be removed. To remove a server role, you must clear the appropriate check box.

6. On the Readiness Checks page, after the check is completed, click Uninstall. 7. On the Completion page, click Finish.

Note If you are removing the Mailbox server role from a computer, remove the Exchange database files (*.edb) and storage group log files (*.log) from the server. This step will be necessary if you attempt to reinstall the Mailbox server role at some future date.

Using Setup Wizard to Remove a Server Role from Windows Server 2008 Follow these steps:

1. Log on to the server from which you want to remove Exchange 2007 server roles. 2. Open Control Panel, and then double-click Programs and Features. 3. In Programs and Features, select Microsoft Exchange Server 2007, and then click Uninstall.

TAKING EXTREME MEASURES

Note If you click Change instead of Uninstall, you can add server roles, but you cannot remove server roles. Obviously, they didn’t correct that little bit of confusion.

4. In the Exchange Server 2007 SP1 Setup Wizard, on the Exchange Maintenance Mode page, click Next.

5. On the Server Role Selection page, clear the check boxes for the server roles that you want to remove, and then click Next.

Note Having already confused you about the meaning of ‘‘Change,’’ the program has it so that by default, all server roles are selected. This indicates that no server roles will be removed. To remove a server role, you must clear the appropriate check box.

6. On the Readiness Checks page, after the check completes, click Uninstall. 7. On the Completion page, click Finish.

Note If you are removing the Mailbox server role from a computer, remove the Exchange database files (*.edb) and storage group log files (*.log) from the server. This step will be necessary if you attempt to reinstall the Mailbox server role at some future date.

Using Setup.com to Remove a Server Role This method applies regardless of which operating system or version of Exchange Server 2007 is deployed on the server.

1. Log on to the server on which you want to remove one or more Exchange 2007 server roles.

2. Open a command prompt window and navigate to the directory where you installed the Exchange Server 2007 files. By default, this directory is %programfiles%\ Microsoft\Exchange Server.

3. Navigate to the \bin directory. 4. Use the following syntax for Setup.com: Setup.com /mode:uninstall /role:

Note If you want to uninstall all roles, skip the /role switch.

289

290

CHAPTER 10 DEPLOYING EXCHANGE SERVER 2007

Completely Removing Exchange Server 2007 Completely removing Exchange 2007 from a server includes removing all server roles, all installation files, and the Exchange server object and all its child objects from the Active Directory directory service. If the server from which you are removing Exchange has the Mailbox server role installed, make sure you have either deleted, disabled, or moved all mailboxes, public folders, and public folder replicas to another Mailbox server. If you remove the public folder database, make sure that you complete all the steps to move the data and remove the database. Depending on the size of the database, this could take a significant amount of time.

Using Setup Wizard to Remove Exchange Server 2007 SP1 from Windows Server 2003 Follow these steps:

1. Log on to the server from which you want to remove Exchange 2007. 2. Open Control Panel, and then click Add or Remove Programs. 3. On the Change or Remove Programs page, select Microsoft Exchange Server, and then click Remove.

4. In the Exchange Server 2007 Setup Wizard, on the Exchange Maintenance Mode page, click Next.

5. On the Server Role Selection page, clear all the server role check boxes, clear the Management Tools check box, and then click Next.

6. On the Readiness Checks page, after the check completes, click Uninstall. 7. On the Completion page, click Finish. If you are removing the Mailbox server role from a computer, remove the Exchange database files (*.edb) and storage group log files (*.log) from the server. This step will be necessary if you attempt to reinstall the Mailbox server role at some future date You should also do the following optional steps: ◆ Remove the setup log files that are located at %systemdrive%\ExchangeSetupLogs. ◆ Remove the following virtual servers that are created for Exchange 2007 under the Default Web Site in Internet Information Services (IIS): ◆

Microsoft-Server-ActiveSync

◆

OAB

◆

OWA

Using Setup Wizard to Remove Exchange Server 2007 from Windows Server 2008 Follow these steps:

1. Log on to the server from which you want to remove Exchange 2007. 2. Open Control Panel, and then double-click Programs and Features. 3. In Programs and Features, select Microsoft Exchange Server 2007, and then click Uninstall.

TAKING EXTREME MEASURES

4. In the Exchange Server 2007 SP1 Setup Wizard, on the Exchange Maintenance Mode page, click Next.

5. On the Server Role Selection page, clear all the server role check boxes, clear the Management Tools check box, and then click Next.

6. On the Readiness Checks page, after the check completes, click Uninstall. 7. On the Completion page, click Finish.

Note If you are removing the Mailbox server role from a computer, remove the Exchange database files (*.edb) and storage group log files (*.log) from the server. This step will be necessary if you attempt to reinstall the Mailbox server role at some future date.

You should also do the following optional steps as necessary: ◆ Remove the setup log files that are located at %systemdrive%\ExchangeSetupLogs. ◆ Remove the following virtual servers that are created for Exchange 2007 under the Default Web Site in Internet Information Services (IIS): ◆

Microsoft-Server-ActiveSync

◆

OAB

◆

OWA

Using Setup.com to Remove Exchange 2007 This method applies regardless of which operating system or version of Exchange Server 2007 is deployed on the server.

1. Log on to the server from which you want to remove Exchange 2007. 2. Open a command prompt window and navigate to the directory where you installed the Exchange Server 2007 files. By default, this directory is %programfiles%\Microsoft \Exchange Server.

3. Navigate to the \bin directory. 4. Use the following syntax for Setup.com: Setup.com /mode:uninstall

Note If you are removing the Mailbox server role from a computer, remove the Exchange database files (*.edb) and storage group log files (*.log) from the server. This step will be necessary if you attempt to reinstall the Mailbox server role at some future date.

291

292

CHAPTER 10 DEPLOYING EXCHANGE SERVER 2007

You should also do the following optional steps: ◆ Remove the setup log files that are located at %systemdrive%\ExchangeSetupLogs. ◆ Remove the following virtual servers that are created for Exchange 2007 under the Default Web Site in Internet Information Services (IIS): ◆

Microsoft-Server-ActiveSync

◆

OAB

◆

OWA

Removing the Last Legacy Exchange Server If you are removing the last Exchange 2003 server, confirm that you do not plan to use any of the Exchange 2003 features that have been removed in Exchange 2007. The following features are not supported in Exchange 2007: ◆ Novell GroupWise connector ◆ Network News Transfer Protocol (NNTP) If you are removing the last Exchange 2000 server, confirm that you do not plan to use any of the Exchange 2000 features that have been removed and are not supported in Exchange 2007. ◆ Microsoft Mobile Information Server ◆ Instant Messaging service ◆ Exchange Chat Service ◆ Exchange 2000 Conferencing Server ◆ Key Management Service ◆ cc:Mail connector ◆ MS Mail connector

Preparing the Exchange Organization There are a number of pre-steps you have to take before removing the server, assuming that you want to retain any of the data or connectivity that existed previously. In order to prepare your Exchange Server 2007 organization for removal of the last Exchange 2003 or Exchange 2000 server, do the following:

1. Move all mailboxes to an Exchange 2007 server in the organization. 2. Move all content/system folders from the public folder database on the legacy server to a public folder database on an Exchange 2007 server in the organization.

3. On an Exchange 2007 server, for each offline address book (OAB), move the generation process to an Exchange 2007 server.

REMOVING THE LAST LEGACY EXCHANGE SERVER

4. To remove the public folder mailbox and stores on the Exchange 2003 or Exchange 2000 server, use the Exchange System Manager to perform the following steps:

a. Expand the server, expand the storage group that contains the public folder store, right-click the public folder store, and then click Delete.

b. In the dialog box that notifies you that the public folder store is the default store for one or more mailbox stores or users, click OK to select a new public folder store. In the Select Public Store dialog box, select a public folder store on an Exchange 2007 server, and then click OK.

5. Verify that Internet mail flow is configured to route through your Exchange 2007 transport servers. By default, Exchange 2007 does not enable Internet mail flow. Use one of the following methods to configure Internet mail flow: ◆ Deploy an Edge Transport server and subscribe it to the Exchange organization. ◆ Deploy an Edge Transport server and manually configure the required Send and Receive connectors for Internet mail flow. ◆ Relay internet email through Microsoft Exchange Hosted Services or other thirdparty SMTP gateway servers. ◆ Configure the Hub Transport server to send and receive Internet mail directly. ◆ Verify that you have created Exchange 2007 Send connectors to replace all outbound SMTP connectors that may exist on that Exchange 2003 or Exchange 2000 server. ◆ Verify that you have made any required changes to your Domain Name System (DNS) MX resource records so that SMTP traffic from the Internet is routed to the Internetfacing mail server you configured in this step.

6. Verify that all inbound protocol services (ActiveSync, Microsoft Office Outlook Web Access, Outlook Anywhere, POP3, IMAP4, Autodiscover service, and any other Exchange Web service) point to an Exchange 2007 Client Access server by:

a. Making sure that the Internet hostnames and IP addresses are appropriately configured in DNS for access to Exchange 2007 Client Access servers.

b. Confirming that your clients are configured correctly. 7. Delete the routing group connectors that connect the Exchange 2003 or Exchange 2000 routing groups and the Exchange 2007 routing group.

8. If you have Exchange 2003 or Exchange 2000 recipient policies that are only Mailbox Manager policies and do not define email addresses (they do not have an E-mail Addresses (Policy) tab), perform the following steps to delete the policies:

a. In Exchange System Manager, expand Recipients, and then select Recipient Policies. b. To verify that a policy is only a Mailbox Manager policy, right-click the policy, and then select Properties. The Properties page must not have an E-Mail Addresses (Policy) tab.

c. To delete the policy, right-click the policy, and then select Delete. Click OK and then click Yes.

293

294

CHAPTER 10 DEPLOYING EXCHANGE SERVER 2007

9. If you have Exchange 2003 or Exchange 2000 policies that are both E-mail Addresses and Mailbox Manager policies (they have both the Mailbox Manager Settings (Policy) tab and the E-mail Addresses (Policy) tab), perform the following steps to remove the mailbox manager portion of the policy:

a. In Exchange System Manager, expand Recipients, and then select Recipient Policies. b. Right-click the policy, and then select Change property pages. c. Clear the Mailbox Manager Settings check box, and then click OK.

Note Do not delete any email address recipient policies that have email addresses that you still want defined in your organization. Exchange 2007 will use those policies when provisioning new recipients.

Removing the Last Exchange 2000 or 2003 Server On your Exchange 2003 or Exchange 2000 server, perform the following steps to move the public folder hierarchy from the Exchange 2003 or Exchange 2000 administrative group to the Exchange 2007 administrative group. If you do not complete this step, the Exchange 2007 public folder database could fail to mount if you delete the Exchange 2003 or Exchange 2000 administrative group:

1. In Exchange System Manager, expand Administrative Groups, right-click Exchange Administrative Group (FYDIBOHF23SPDLT), select New, and then select Public Folders Container.

2. Expand the Exchange 2003 or Exchange 2000 administrative group that contains the public folder tree, expand Folders, and then drag Public Folders to Folders under the Exchange 2007 administrative group. Perform the following steps to delete the domain Recipient Update Services:

1. In Exchange 2003 or Exchange 2000 System Manager, expand Recipients, and then select Recipient Update Services.

2. Right-click each domain Recipient Update Service, and then select Delete. 3. Click Yes. The last step is to Uninstall Exchange 2003 or Exchange 2000 by using Add or Remove Programs from Control Panel.

Implementing Ongoing Change Management Now that you have implemented your Exchange Server 2007–based messaging system and gotten everyone to accept that the change has come, your work is still not done. Now you have to implement a process for manage ongoing changes that will need to be made to the system. This is different from the Change Management topic that we reviewed in Chapter 8. There we were talking about changes in the organizational culture, and changes to the scope statement and statement of work. Now we’re talking about managing changes to a working system.

IMPLEMENTING ONGOING CHANGE MANAGEMENT

This is important because if you do not have a change management system in place, your well-tuned system could be brought to a sudden, screeching, and expensive halt because of a flawed update or a tweak whose ripple effects were not considered. Suppose for example that you need to do something simple like change the name of a storage group to adhere to new naming conventions. If you do not have a change management system in place and the storage group name is changed without warning or discussions, other systems may feel a ripple effect and suddenly your messaging system is not working for some people. What’s worse, if the name change wasn’t known to anyone, it might take hours to ascertain the change. The change management system you implement for ongoing changes can be as simple as form that needs to be filled out and approved to something as complex as a change review board. No matter what you opt to do and what is most appropriate for your organization and deployment, and regardless of how you document change requests, you should always have the following information about a change to the system: ◆ The date of the proposed change ◆ The system(s) effected by the change as well as any dependencies ◆ A detailed description of the proposed change ◆ A detailed rollout plan ◆ A detailed description of what constitutes a successful rollout ◆ A rollback plan ◆ Who will be notified BEFORE the change takes place to monitor it? For changes that might have a system-wide impact, such as the application of a major service pack, I strongly suggest you insist on testing in a nonproduction environment and that a copy of the test results be attached to the user notification list.

Enforcing Change Management Consistency is required, and there can be no exceptions to requiring that those who can change the system follow this procedure. Some people will argue that minor changes, like adding a mailbox, should be exempt from this process, but I strongly disagree. Exemptions and exceptions have a tendency to expand in inversely proportional to the administrators’ enthusiasm for paperwork. You must make sure that all changes made to the Exchange Server 2007–based messaging infrastructure are known in advance. This includes not only the software, but changes affecting managing: servers, routers, network devices, databases, and so forth. Each detected change must either map to authorized work, or it must be flagged for investigation. Critical questions that need to be answered about all changes are: ◆ Who made the change? ◆ What did they change? ◆ Should it be rolled back? If so, then how? ◆ How do we prevent it from happening again in the future? The key to creating a successful culture of change management is accountability. If the change process is repeatedly bypassed, management must be willing to take appropriate disciplinary action.

295

296

CHAPTER 10 DEPLOYING EXCHANGE SERVER 2007

Dos and Don’ts You should make sure that your post-deployment change management system does the following: ◆ Requires post-implementation reviews to determine whether the change succeeded or not. ◆ Tracks the change success rate and uses it to learn and avoid making historically risky changes. ◆ Make sure everyone attends change meetings that affect them or their systems; otherwise, auditors have a good case that this is a nonfunctioning control. ◆ Categorize the disposition of all changes. In other words, all outcomes must be documented once a change is approved. Three potential outcomes are: ◆

Change request withdrawn.

◆

Change failed. Require documentation of what went wrong.

◆

Change completed successfully, that is, the change was implemented and everything is functioning nominally.

The things you should never do are: ◆ Authorize changes without rollback plans that everybody reviews. ◆ Allow the rubber stamp approval of changes. ◆ Fail to investigate every detected change; someone made them, so understand who did them and why. ◆ Send mixed messages. Bear in mind that the first time the process is circumvented, incredible damage can be done to the process. ‘‘Well heck, we did it last time’’ or the boss said, ‘‘just do it’’ — both send the wrong messages.

The Case of the HIV Letter When I worked for the health department of a western state back in the 1980s, AIDS was just starting to be a problem and drew the concern of many people. It was decided that the state health department would send an HIV/AIDS awareness booklet to every person in the state. The aim was to quell concerns about HIV, dispel rumors, and create an informed public. One of the key points to the letter was to identify hemophiliacs, IV drug users, and homosexual males as persons at the highest risk. The booklet was to be accompanied by a letter signed by the governor. As is the usual case a series of people prepared the draft, which was then reviewed by a number of people before being signed by the governor. Each of the five reviewers was supposed to have read the letter and double-checked its contents to ensure that there were no grammatical, spelling, or other errors. When the letter arrived for copying to be included with the booklets, it was read one last time by the clerk whose job it was to ensure that sufficient copies were made. She broke into immediate uproarious laughter. ‘‘Did anyone actually read this?’’ she asked, pointing to the third paragraph. ‘‘Persons at highest risk for HIV infection include hemophiliacs, IV drug users, and men who have sex with me.’’

LESSONS LEARNED

The sentence was obviously supposed to have read ‘‘Persons at highest risk for HIV infection include hemophiliacs, IV drug users, and men who have sex with men.’’ It wasn’t detected because none of the reviewers actually read the letter, relying instead on the previous reviewer and a misguided faith in the spellchecker. The moral to the story is never allow approvals to be routine or rubber stamped. You never know when you might embarrass the wrong person — including yourself.

Gauging Success Don’t become discouraged if the change management system has some bumps along the way. You’re not simply putting a logical and beneficial system in place, you’re also changing people, processes, and technology. If you’ve introduced a change management process to an environment that never had one before, it will take a while for it to be accepted and for people to realize that it will be enforced. Managing change is an evolutionary process. The following examples illustrate the various levels of change management awareness you can expect: ◆ Oblivious of change. Did something just happen with Exchange? ◆ Aware of change. Hey, who just changed Exchange? ◆ Announcing the change. I’m applying this patch. Let me know if it causes a problem. ◆ Authorizing change — I need to apply to this patch, who do I have to ask? ◆ Scheduling change. When is the next maintenance window? I’d like to apply this patch then. ◆ Verifying change — Looking at the logs, I can see that the patch was applied as scheduled. ◆ Managing change — Let’s schedule the patch for week 14 so we can apply that and the Windows Server service pack at the same time. Always remember that the goal of the process is to reduce the amount of time spent on unplanned down time by reducing the number of self-inflicted problems and modifying how problems are solved so that change is ruled out early in the repair cycle. By increasing the change success rate, you will not only decrease the amount of unplanned work but also increase the number of changes that can be successfully implemented by the organization.

Lessons Learned Nearly every person I have ever worked with agrees that the last step before a project can be considered ‘‘complete’’ is do a lessons learned analysis. Hardly anybody ever does. ‘‘No time right now,’’ they say. ‘‘Too busy.’’ ‘‘We’ll get to it later.’’ And they don’t. And guess what? They go out and make the same mistakes on the next project. Why? Consider that one definition of insanity dating back to 1879 is ‘‘doing the same thing over and over again and expecting a different result.’’ To avoid doing the same things wrong, and to get a good handle on what you did right, a lessons learned session — a postmortem — is a key element of the project. It also helps make sure you do better projects in the future; the point to lessons learned is to make sure that you keep doing the right things, to figure out what the wrong things were, and to stop doing them.

297

298

CHAPTER 10 DEPLOYING EXCHANGE SERVER 2007

There are some caveats to this, and in some instances a lessons learned process may be the last thing you want to put an organization through. The corporate culture needs to be one of openness, honesty, and truth telling. The individuals need to be comfortably self-critical and feel safe and trusted enough in the organization that they fully believe that they can tell the truth about the project. This means several things. First, try to set the stage and nudge as many persons as you can — especially the executive sponsor — to support open and nondefensive communications. Getting an organization to fearlessly tell the truth is useful for all its projects and will definitely help it in the long run. Second, if the organization is not fully self-aware and truthfully open, a professional facilitator should be used. This is a simple facilitation; however, the facilitator should have project experience so that he or she can intervene if the discussion becomes self-serving or if lessons are suggested that are inconsistent with project reality. Third, if a ’’blame’’ hunt is in progress, don’t even try a lessons learned meeting. People trying to duck blame will obfuscate reality and twist circumstances in such creative ways that no one could sort out the truth. Others will try to use the process to score political points and take it as an opportunity to attack others.

Lessons Learned Meeting Who should be involved in the lessons learned meeting? This depends of course on the project. At bare minimum it should be you, as project manager, and the executive sponsor, or sole proprietor. If you have a team or a large project, you may have to break it down. You may, for example, have to conduct a lessons learned session with the people working on the hardware aspects of the project or those who were managing the change requests and so on. But you should hold lessons learned meetings. A sample agenda for a Lessons Learned meeting is included in Appendix E. The goal of the meeting is to carefully consider what went wrong and why, and to make sure that there is a way to transfer related recommendations forward. The meeting can also help the team help others repeat their successes only if they can express concretely what went well, and why. The specific lessons and recommendations generated in this kind of meeting will yield concrete actions for the participants and other teams. For a large project, you may find that using a neutral facilitator for the lessons learned meeting is the best way to keep everything on track. This particularly true if there were serious problems, internal divisions, or other concerns that put people on the defensive. You should open the meeting by stating the ground rules for the discussion. Something like ‘‘We’re here to examine what went right with Project X and what we can learn to improve our results. We’re not here to criticize people or find fault. We’re here to learn from each other and strengthen the process we used.’’ This helps keep everyone in the right frame of mind, and hopefully minimizes the chances for friction. Next, review the project scope and the desired final result. Identify the parts that went well, then look for areas for potential improvements. If the project is large or complex, break discussions into manageable points dealing with such items as cost, schedule, quality, customer satisfaction, and so on.

Do It for Yourself Even if you think the corporate environment isn’t ready for a lesson learned session, or you can’t generate any interest in the topic, you should still do one for yourself. Whether this is your first project or your thousandth, you should assess your performance. The assessment should be

SUMMARY

self critical, but not overly harsh. It should be realistic. If you are convinced that you did everything right, that nothing went wrong, and that you were perfect, you really shouldn’t be a project manager. You can’t learn because the first step to learning is to admit that you don’t know something. That attitude will inevitably result in disaster. If, on the other hand, you’re willing to review the project, your implementation plans, and how you did each part, and then draw up a reasonable list of accomplishments and disappointments, the reward will be that you will be a better manager. The next time you are called upon to build an Exchange Server 2007–based messaging system, or any project, you will be armed with new knowledge, heightened awareness, and a quiet, casual efficiency that ensures success.

Summary I started this chapter off by congratulating you, and I will end it the same way. Your messaging system is now deployed. Congratulations! As you now realize, the actual installation of an Exchange Server 2007–based messaging system is, mechanically, not that difficult. In fact the engineers at Microsoft made it about as foolproof as they could. What was difficult, and where you spent most of your time, was in preparing for the deployment. As you saw in this chapter, had there not been a well-thought-out statement of work and a clearly defined scope statement to use as a starting point for your design and implementation plans, the deployment would have been more difficult than it needed to be. We ended the chapter by examining some nontechnical processes that you will have to do to ensure the successful conclusion of the project. First, we reviewed how to go about implementing a change management process for modifications to Exchange Server 2007. The last and final step was conducting a lessons learned analysis and review so that you can use the current project to get ready for the next one. Those lessons will also serve as the core set of attributes that will be used when it comes time for the Exchange Server 2007–based messaging system to be replaced. It’s the circle of life, at least for an Exchange deployment. So be proud and share the achievement. Treat yourself and your team to something special to mark the occasion. At this point in the development of your Exchange Server 2007–based messaging system, you have successfully negotiated through most of the hurdles. You now have a functioning messaging system and assuming your plans were correct and well thought through, and that your deployment was solid, you have met the goals you set for yourself in the scope statement and statement of work. Since I’m sure that you’ve done everything correctly, you’re probably in line for a bonus or a promotion; or if you’re a freelance consultant, prompt payment and a glowing recommendation. Before we close up shop though, we’re going to spend the next chapter on what is truly your last — and longest — step. Monitoring, maintaining, and supporting your messaging infrastructure so that it hums along nicely for and, believe it or not, getting ready for the day you will want to replace it.

299

Chapter 11

Tweaking the Infrastructure ‘‘It ain’t over till it’s over.’’ — Yogi Berra In the previous chapter, we went through the processes and steps you need to take to prepare for the deployment of your Exchange Server 2007–based messaging system. We ended the chapter with the successful installation of Exchange Server 2007 and some basic postinstallation tasks. It doesn’t end there. In fact, the care, feeding, and tweaking of the new messaging system is a never ending process. In this chapter, we’ll examine the procedures you should perform immediately after deployment. Some of them are performed almost simultaneously with the deployment to harden the infrastructure, and to ensure that all the remaining requirements are implemented. Most of these are technical, and some are conceptual. Let’s start with the tools you can use to keep your messaging system in perfect order after you’ve deployed it.

Tools, Tools, and More Tools Microsoft has been generous when it comes to tools, or maybe it’s the nature of technical people to love these ‘‘toys.’’ In addition to all the tools that come with Windows 2003 or Windows 2008, Exchange Server 2007 comes with a veritable cornucopia of tools, wizards, and assistants that are designed to help you monitor every aspect of the application. Learning about them and when and how to use them to your benefit can be one of your best investments of time and energy. The right tool, in the right place, can save you hours of effort and reduce your stress level when things don’t go according to plan. I’ve already introduced you to a few of these, such as the Best Practice Analyzer. Now that you have Exchange Server 2007 up and running and deployed, let’s take a good look at all the nifty gadgets we have to keep it running in good form.

Note For information about the tools that come with the operating system (such as System Monitor or Task Manager), please refer to the Windows Server 2003 or Windows Server 2008 documentation. You can access many of the tools through the Exchange Management Console’s Toolbox node. The Toolbox is a collection of tools that are installed with Exchange Server 2007. The Toolbox provides a central location for diagnostic, troubleshooting, and recovery activities using various Exchange tools.

302

CHAPTER 11 TWEAKING THE INFRASTRUCTURE

Note Independent tools, such as the Microsoft Exchange Server Best Practices Analyzer Tool, are not integrated with the Exchange Management Console. They function as separate executable files when run from the Toolbox. These tools have their own Help file content. For more information about how to use the tools, refer to the individual tool’s Help file.

When you click the Toolbox node, the following tools are displayed in the result pane. You can open the tool by double-clicking the tool name or by clicking Open Tool from the action pane or from the right-click menu. The resulting window, as you can see in Figure 11.1, shows the following: ◆ Configuration Tools ◆

Best Practices Analyzer

◆

Details Templates Editor

◆

Public Folder Management Console

◆ Disaster Recovery Tools ◆

Database Recovery Management

◆

Database Troubleshooter

◆ Mail Flow Tools ◆

Mail Flow Troubleshooter

◆

Message Tracking

◆

Queue Viewer

◆

Routing Log Viewer

◆ Performance Tools ◆

Performance Monitor

◆

Performance Troubleshooter

There are others as well, but let’s start by discussing these first.

Configuration Tools There are three configuration tools. The most valuable for tweaking the infrastructure is the Best Practices Analyzer.

Best Practices Analyzer The Exchange Server Best Practices Analyzer automatically examines an Exchange Server deployment and determines whether the configuration is in line with Microsoft best practices. You should always run this tool after you install a new Exchange server, upgrade an existing Exchange server, or make configuration changes.

TOOLS, TOOLS, AND MORE TOOLS

Figure 11.1 Toolbox in the Exchange Management Console

As you can see in Figure 11.2, there are five different types of scans, four of which are relevant to a functioning Exchange Server 2007 organization. The fifth scan, the Exchange Server 2007 Readiness scan, is not germane to this chapter now that you have your system in place.

Figure 11.2 Scans available in the Best Practices Analyzer

303

304

CHAPTER 11 TWEAKING THE INFRASTRUCTURE

The Health Check scan performs a full scan of Exchange Server. It checks for errors, warnings, nondefault configurations, recent changes, and other configuration information. You should run a Health Check scan if you want to check the health of your Exchange Server organization, or if you want to troubleshoot a particular problem. The Permission Check scan checks permissions. You should run this scan if you suspect a problem with permission access. The Connectivity Test scan tests network connections on each Exchange Server that is specified in the scope. You should run a Connectivity Test scan if you have firewalls in the topology. The Connectivity Test scan runs very quickly. The Exchange Server Best Practices Analyzer queries one registry parameter and two Microsoft Windows Management Instrumentation (WMI) classes. The first WMI query validates WMI repository access. The second WMI query queries the Active Directory directory service servers that are used by Exchange Server. After scanning all Exchange Servers that are specified in the scope, the Exchange Server Best Practices Analyzer tries to validate network connectivity and permissions on Active Directory servers that are used by Exchange Server. The Baseline scan checks for deviations from the baseline values that you set and performs the following tasks:

1. It selects properties. 2. It sets baseline values for those properties. 3. It then selects servers on which to compare those properties. The Baseline scan report identifies as baseline mismatches all properties on the selected servers whose values are different from the source values of the selected properties.

Details Templates Editor The Details Templates Editor allows you to control the appearance of object properties that are accessed by using address lists in MAPI 32-bit client applications, such as Microsoft Outlook. For example, when a user opens an address list in Outlook, the properties of the recipients in that address list are presented as defined by the details template that exists in your Exchange organization. It is of little value to you as a monitoring or troubleshooting tool, but if you’re inclined to create your own templates, it is a simple but powerful tool.

Public Folder Management Console The Public Folder Management Console is a Microsoft Management Console (MMC) 3.0–based interface that provides Exchange administrators with a graphical user interface (GUI) in which they can create, configure, and maintain public folders.

Disaster Recovery Tools Two disaster recovery tools are accessible directly from the Toolbox, and two are command-line tools. I’ll cover disaster recovery in depth in the ‘‘Performing Disaster Recovery’’ section of this chapter.

Database Recovery Management The Database Recovery Management tool, shown in Figure 11.3, allows you to perform the following tasks to help resolve database-related issues:

TOOLS, TOOLS, AND MORE TOOLS

◆ Verify the restored database files to make sure that all necessary database, streaming, and transaction log files are available to perform a restore. ◆ Examine dismounted databases, checkpoint files, and log files for each storage group to determine log drive space issues. ◆ Move all transaction log files for a storage group to a temporary location, and restart the log generation number. This action is required when a storage group runs out of transaction log file names. ◆ Repair corrupted databases. ◆ Examine database-related event log entries during a specified time range. ◆ Create a recovery storage group for a storage group that needs to be restored. ◆ Mount or dismount the databases in the recovery storage group. ◆ Remove the existing recovery storage group when it is no longer needed. ◆ Merge or copy mailbox content from the databases in the recovery storage group to production mailboxes. ◆ Set the Database Can Be Overwritten by Restore option if you need to restore the database files.

Figure 11.3 You can perform a variety of tasks using the Database Recovery Management tool.

Database Troubleshooter The Database Troubleshooter tool analyzes Exchange Server databases and available transaction log files for issues that affect database recoverability. This tool reports missing or corrupted

305

306

CHAPTER 11 TWEAKING THE INFRASTRUCTURE

log files and recommends steps that you can take to bring the database to a clean, mountable state. You can use the Database Troubleshooter tool to repair and analyze the following Exchange database issues: ◆ The database will not mount. ◆ Log files are inconsistent. ◆ Log file generation has run out of numbers to name the log files. ◆ Out of drive space.

Eseutil.exe The Exchange Server Database Utilities (Eseutil.exe) is a command-line tool that works with the Extensible Storage Engine (ESE), database files, and log files associated with a Microsoft Exchange database. You can use Eseutil.exe to verify, modify, and repair an Exchange database file. When a database is corrupt or damaged, you can restore data from backup or repair it using Eseutil.exe.

Note Eseutil.exe is located in the Exchange default install folder, which is :\Program Files\Microsoft\Exchange Server\Bin.

One difference for Eseutil.exe in Exchange Server 2007 is that it can now be used against any ESE database. In previous versions of Exchange, it could be used only with mailbox and public folder ESE databases, but this ability has been extended to include Edge Transport and Hub Transport server roles as well.

Note Streaming (.stm) files are not supported by Eseutil.exe in Exchange Server 2007 databases. However, Eseutil.exe supports .stm files in older Exchange databases. If you are working with databases in versions of Exchange that precede Exchange Server 2007, use the Eseutil.exe tool that is associated with that version of the Exchange database.

Eseutil.exe can be run on one database at a time from the command prompt to perform a range of database tasks including repair, offline defragmentation, and integrity checks. Table 11.1 lists the most common Eseutil.exe switches.

Isinteg.exe The Information Store Integrity Checker (Isinteg.exe) is not included in the Toolbox but is accessible from the command line. Isinteg.exe finds and eliminates errors from the public folder and mailbox databases at the application level. Isinteg.exe is not intended for use as a part of routine information store maintenance; it is provided to assist in disaster recovery situations. The Isinteg.exe tool can recover data that the

TOOLS, TOOLS, AND MORE TOOLS

Exchange Server Database Utilities (Eseutil.exe) tool cannot recover. This is because data that is valid for the Isinteg.exe tool at the physical schema level can be semantically invalid at the logical schema level.

Table 11.1:

Common Eseutil.exe Switches

Switch

Eseutil.exe mode

Description

/D

Defragmentation

Defragments the database offline but leaves the new, defragmented database in the temporary location with or without overwriting the original database.

/P

Repair

Repairs a corrupt offline database by discarding any pages that cannot be fixed. In repair mode, the Eseutil tool fixes individual tables but does not maintain the relationships between tables.

/C

Restore

Displays restore log file (Restore.env file) and controls hard recovery after restoration from legacy online backups.

/R

Recovery

Replays transaction log files or rolls them forward to restore a database to internal consistency or to bring an older copy of a database up to date.

/G

Integrity

Verifies the page level and ESE level logical integrity of the database. Does not verify integrity at the application level. Application-level logical integrity can be verified with Isinteg for mailbox and public folder databases.

/M

File Dump

Displays headers of database files, transaction log files, and checkpoint files. Also displays database page header information, and database space allocation and metadata.

/K

Checksum

Verifies checksums on all pages in the database, log files, and checkpoint files.

/Y

Copy File

Performs a fast copy of very large files.

Isinteg.exe is most often used after running the Eseutil.exe repair operation. The Isinteg.exe tool performs three main tasks: ◆ Patches the information store after a restore from an offline backup. ◆ Tests and optionally fixes errors in the information store. ◆ Repairs information and relationships between mailboxes, folders, items, and attachments at the application level.

Mail Flow Tools The only real purpose for an Exchange deployment is to allow communication, primarily email, among clients. If the mail isn’t flowing as intended, then you have a serious problem. These four tools will help keep your ‘‘core mission’’ intact and help diagnose and fix it for you if it stops functioning.

307

308

CHAPTER 11 TWEAKING THE INFRASTRUCTURE

What’s It All About? Military personnel are understandably proud of their specialties. It takes months to learn them and years to be proficient at them. A tank has three major components: the drive train, which allows it to be mobile; the communications/navigation system, which allows it to receive orders and determine where it is; and the cannon, which is used in combat. Each requires a separate maintenance specialty. One day three maintenance sergeants were talking about their respective specialties. Inevitably the discussion turned to which part was the most important. The sergeant who oversaw the drive train argued that his was, since without the ability to move the tank was little more than an ugly artillery piece. The communications sergeant posited that without the radio and navigation equipment the tank crew had no idea what to do or where to go. They both looked at the weapons sergeant for his comment. ‘‘Gentlemen,’’ he said, ‘‘the way I see it, without the cannon working, what you have is the world’s largest and heaviest portable radio.’’ In your Exchange Server 2007–based messaging system, the most important requirement is to keep the mail flowing. Everything else is secondary.

Mail Flow Troubleshooter The Exchange Mail Flow Troubleshooter tool, shown in Figure 11.4, helps provide easy access to various data sources that are required to troubleshoot problems with mail flow, such as nondelivery reports, queue backups, and slow deliveries. The tool will then automatically diagnose the retrieved data and present an analysis of the possible root causes, and suggest corrective actions.

Figure 11.4 Mail Flow Troubleshooter

TOOLS, TOOLS, AND MORE TOOLS

Message Tracking The Message Tracking tool allows you to follow specific messages as they are routed through the Exchange environment. Message tracking is a detailed log of all message activity as messages are transferred to and from an Exchange Server 2007 server that has the Hub Transport server role, the Mailbox server role, or the Edge Transport server role installed. Exchange servers that have the Client Access server role or Unified Messaging server role do not have message tracking logs. Message tracking logs can be used for message forensics, mail flow analysis, reporting, and troubleshooting.

Tip The GUI shows messages only for the server you are on; you must use the command line to show all servers.

Queue Viewer Microsoft Exchange uses queues to hold messages as they are being processed for routing and delivery. The Queue Viewer allows an administrator to monitor mail flow and inspect an organization’s messaging queues and identify mail flow issues. It can also be used to perform intrusive actions against the queuing databases, such as suspending or resuming a queue, or removing messages. The Queue Viewer is available on all Exchange Server 2007 servers with the Hub Transport or Edge server role installed. You must develop a queue baseline so that you can identify the difference between normal behavior and abnormal behavior for your organization. Typically, on-demand use of the Queue Viewer is the result of a support call indicating that email delivery is slow or that a message has not been delivered. You can use the Queue Viewer to check for the following: ◆ Messages that are queued for extended periods of time. Except under an extremely heavy load of email, Exchange server won’t have queued messages for any extended duration. If you start to see extended periods of queuing then that’s a good indication that your attention is required. In that case, you should review performance counters to see whether some other performance issues are causing email messages to queue. If not, look for connectors or servers that are not functioning. SMTP protocol logging might also help you discover the problem. ◆ Peaks in queued messages. Spikes in queued messages can occur when someone sends: ◆

A message to a large distribution list

◆

An extremely large message to a large number of people

◆

A message whose destination is across a slow network link

These conditions are not cause for immediate alarm. However, you must review the security of your Exchange organization if either of the following conditions exists: ◆ A large volume of messages is queued to one recipient or email address. This can be a symptom of a spam attack on an email loop or a denial-of-service (DoS) attack. ◆ A large volume of messages is queued to a specific server or domain. This indicates that a server is down, a service is stopped, a domain is unreachable, or a network disruption is preventing the system from establishing a connection.

309

310

CHAPTER 11 TWEAKING THE INFRASTRUCTURE

Note To use Queue Viewer on a computer that has the Edge Transport server role installed, you must use an account that is a member of the Local Administrators group on that computer. To use Queue Viewer on a computer that has the Hub Transport server role installed, the account you use must also be a domain account that has the permissions assigned to the Exchange View-Only Administrators group.

Routing Log Viewer Exchange Routing Log Viewer enables administrators to open a routing log file that contains information about what the routing topology looks like to the server. The administrator can also open a second routing log and compare it to the first log opened. The tool consists of a parser and a public user interface. To use the Routing Log Viewer to view logs of routing table configuration changes, you must connect to an Exchange Server 2007 server that has the Hub Transport or the Edge Transport server role installed. The account that you use must be delegated as Exchange View-Only Administrator.

Performance Tools The following are the tools you can use to monitor the performance of your system.

Performance Monitor Performance Monitor can be configured to collect information about the performance of your messaging system. Specifically, you can use it to monitor, create graphs, and log performance metrics for core system functions. You can also use Performance Monitor to monitor Exchangespecific parameters, such as the number of inbound or outbound messages per hour or the number of directory lookups performed by Exchange. Performance Monitor is commonly used to view key parameters while troubleshooting performance problems. It is also used to gather baseline performance data to perform historical trend analysis and measure the effect of changes to your Exchange environment. When you open the tool, it automatically displays a live graph of the key performance indicators for the computer on which the tool is running, as shown in Figure 11.5.

Performance Troubleshooter Performance Troubleshooter helps you locate and identify performance-related issues that could affect an Exchange server by identifying possible bottlenecks. . Based on the symptoms you select, the tool walks you through the correct troubleshooting path.

JetStress This utility tests the ability of storage subsystems to handle the I/O load generated by Exchange servers. I/O capacity is a critical success factor for any medium to large Exchange server, and JetStress allows administrators to generate different I/O loads and then to measure how the storage subsystem copes with the workload. Microsoft operates a program called ESRP (Exchange Solution Reviewed Program) that allows selected partners to document the results of testing storage solutions with JetStress according to guidelines set by Microsoft. The documents published through ESRP provide useful information about how storage vendors test their solutions with Exchange and the performance data that they obtain.

TOOLS, TOOLS, AND MORE TOOLS

Figure 11.5 Performance Monitor

Load Generator This utility replaces the LoadSim program that Microsoft first released in 1997 to allow administrators to test the performance of early Exchange servers by generating a load from simulated MAPI users. Over time, the complexity of Exchange servers has grown enormously through different client types, different workloads, and different types of servers. The Exchange Load Generator is a modern performance simulation tool that allows administrators to model workloads and to see how hardware configurations deal with the workloads that you specify. This utility focuses on MAPI client workload and supports the kind of operations generated by Outlook 2003 and 2007 clients, including when these clients work in cached Exchange mode.

Troubleshooting Tools In addition to the previous tools, a number of others are available, some in conjunction with Exchange Server 2007 Toolbox and others separately. All of them are used to help you assess and analyze problems you might be having with your messaging system

Exchange Troubleshooting Assistant Exchange Troubleshooting Assistant (ExTrA) is as a standalone program that can be installed on a workstation or other server. This makes it particularly useful if you are unable to log on directly to the Exchange server. Exchange Troubleshooting Assistant provides access to the following functionalities, all of which can also be accessed through the Toolbox node: ◆ Exchange Performance Troubleshooter ◆ Exchange Database Troubleshooter ◆ Exchange Database Recovery Management

311

312

CHAPTER 11 TWEAKING THE INFRASTRUCTURE

◆ Exchange Mail Flow Troubleshooter ◆ There is also a fifth function that analyzes failure events on a remote computer running Exchange Server 2007. The first screen, as shown in Figure 11.6, has two sections: ◆ A set of symptom-driven selections ◆ A set of related functionality selections

Figure 11.6 Exchange Troubleshooter Assistant. It comes bundled with Exchange Management Console or as a standalone tool.

The symptom-driven section is for troubleshooting performance issues, mail flow issues, or database issues, such as storage mounting problems. The related functions include items like trace control, message tracking search, and database recovery management. Some items might be available for Exchange Server 2007 servers only.

Note The Exchange Troubleshooting Assistant must be installed on a workstation or server that is running a U.S. English version of the Microsoft Windows operating system. It cannot be installed on a computer running Exchange Server 2007 Service Pack 1.

Note The Microsoft Exchange Analyzers web page at http://go.microsoft.com/fwlink/?linkid= 34707 contains downloads for the current versions of Exchange Best Practice Analyzer and Exchange Troubleshooting Assistant. In addition, the page contains information about system requirements, and a link to a newsgroup for discussion about the analyzers.

TOOLS, TOOLS, AND MORE TOOLS

Exchange Server User Monitor The Exchange Server User Monitor (ExMon) is a separate tool that enables administrators to view and evaluate individual users’ usage and experience with Exchange Server 2007. You can view and analyze how individual users affect the health and performance of an Exchange server, including CPU usage and network traffic. You can also gauge how the individual user’s experience is affected by the server. You can then use this information to better understand current client usage patterns and plan for future use. ExMon allows you to view the following: ◆ IP addresses used by clients ◆ Outlook versions and mode, such as Cached Exchange Mode and classic online mode ◆ Outlook client-side monitoring data ◆ Resource use, such as the following: ◆

CPU usage

◆

Server-side processor latency

Note ExMon measures only MAPI traffic and load on an Exchange server. It does not include or display data about other protocols, such as Simple Mail Transfer Protocol (SMTP), Distributed Authoring and Versioning (DAV), Outlook Web Access, Post Office Protocol version 3 (POP3), or Internet Message Access Protocol version 4rev1 (IMAP4).

Note that ExMon does not report all information about server health or user experience. For example, ExMon does not report on the following factors that can affect Exchange Server 2007 performance: ◆ Incoming unsolicited commercial email (SPAM) from the Internet ◆ Incoming SMTP mail flow from the Internet or from other sites in your organization ◆ Use of non-MAPI protocols for account access, such as POP3 and IMAP4 ◆ Use of mobile devices, although some Exchange ActiveSync client traffic is included ExMon provides an overview of individual users’ behavior only. Use it with other procedures and tools that are recommended by Microsoft.

Exchange Server Stress and Performance Tool Exchange Server Stress and Performance (ESP) is a highly scalable stress and performance tool that you can use to stress-test Exchange Server. ESP is not part of the Toolbox and must be installed separately. ESP includes multiple modules and can simulate many client sessions while accessing one or more Exchange servers at the same time. You can use ESP to test several workload scenarios. You can run an unlimited number of ESP modules from a single computer to more realistically simulate physically separate client computers. Alternatively, you can run ESP modules from separate computers at the same time. Therefore, the load you can apply to your test environment

313

314

CHAPTER 11 TWEAKING THE INFRASTRUCTURE

is limited only by the available hardware. Depending on the hardware and workload imposed by each script, you can simulate 5,000 or more users on a single host computer. ESP is modular and extensible. Currently modules are provided that enable you to test stress that is applied for most Internet protocols.

Note Download this tool from the Tools for Exchange Server 2007 website at http://go.microsoft. com/fwlink/?linkid=81741. To install the Exchange Server Stress and Performance tool, follow these steps:

1. In the Setup folder on the ESP download package, run ESP.MSI. 2. In ESP Setup, under Destination Folder, note the default location to which ESP will be installed. To change the location, click Browse, and then move to the location that you want.

3. To start the setup process, in ESP Setup, click Install. 4. In ESP Service Account, type a password for the ESP service account that will be created during ESP Setup, and then click Continue.

5. In ESP Setup, click OK to the message that states that ESP components have been installed on your computer. To set up a realistic test, you have to create users and populate mailboxes with email messages. Exchange Server Stress and Performance cannot simulate users. Therefore, you have to use it in conjunction with tools that have this capability, such as Exchange Load Generator, to create users and populate mailboxes. For example, if you are using Exchange Load Generator with ESP, you can export a list of users created with Exchange Load Generator from Active Directory. To export a list from Active Directory, follow these steps:

1. Start Active Directory Users and Computers. 2. Expand the Active Directory Users and Computers console tree to display the Active Directory containers that include the usernames that you want to export.

3. Right-click a container for which you want to export usernames, click Export, and then save the usernames to a file.

4. Open the file where you exported usernames. 5. In that file, delete all data other than the usernames. The correct syntax is that only one username should be listed per line.

6. Repeat Steps 3 through 5 for each Active Directory container for which you want to export the list of users.

Performing Disaster Recovery Not having a reliable, carefully thought out disaster plan is an open invitation to disaster and borders on inexcusable criminal negligence. It’s as if you decided to jump out of an airplane without

PERFORMING DISASTER RECOVERY

a parachute, expecting the trees below to catch you. It might work, but it’s not a viable plan. Disaster recovery planning is a complex process that relies on many decisions you make regarding the planning for Exchange Server 2007. In this section, we’ll examine how to make sure that you have a viable data recovery strategy for your messaging system, including viable backup and restore strategies. For many organizations, messaging services are mission critical or business critical. If the messaging system is not available, productivity drops, and business and revenue opportunities can be lost. Even if email is neither mission critical nor business critical to your organization, chances are that the loss of messaging services would create a substantial disruption to your organization. A few general points before we begin: although I will primarily focus on best practices, one task you should get in the habit of doing is to establish and apply general principles when planning and using data recovery techniques across your infrastructure rather than try to design a different plan for each server. Establishing and using general principles can save you both time and money. For example, let’s assume that you decided to design an individualized recovery strategy for each Exchange Server 2007 server in your system. Doing so would result in having procedures that might vary from server to server. The subsequent plan is unnecessarily complex. Avoiding this is a simple matter of generalizing the principles involved and taking into account the requirements of all your databases and applications. Armed with these principles you can easily design a strategy that can apply to the entire infrastructure.

A Stitch in Time The first rule of disaster recovery and planning should be to make sure that before it happens you have done everything to minimize it happening. For example most people would agree that it is better to maintain a passenger plane properly than to have procedures if the engine fails. The same logic applies to data protection. Here are some simple things you should do: ◆ Make sure that you have any required hardware and software ready. The last thing you want to be doing is sending people out to the store looking for required material, or to have to scour the Internet for the latest patch. This includes the following: ◆

Software and firmware updates.

◆

All Exchange Server 2007 software disks and updates.

◆

Spare hardware.

◆

Copies of all software needed for your server.

◆ Document your configuration by keeping records of hardware and software configurations. ◆ Make sure you know what you are going to do by having already done the following: ◆

Documented and tested your recovery procedures.

◆

Trained staff on disaster recovery procedures.

◆

Performed disaster recovery simulation drills.

◆ Consider using local continuous replication (LCR), cluster continuous replication (CCR), Standby continuous replication (SCR) or single copy clusters (SCC) to protect your mailbox data.

315

316

CHAPTER 11 TWEAKING THE INFRASTRUCTURE

◆ Consider implementing server-side deleted item retention to protect mailboxes from accidental item deletion through the clients by saving deleted items before purging them from a mailbox. ◆ Consider implementing recovery storage groups. This technology mounts a second copy of an Exchange mailbox database on the same server as the original database or on any other server that is running Exchange in the same Exchange administrative group. ◆ Implement fault tolerance in your organization at the hardware or software level. When appropriate use methods such as RAID, multi-path hardware solutions, clustering, load balancing, or data replication with LCR/CCR/SCR. ◆ Make sure you have sufficient hard disk capacity for your Exchange Server 2007 servers. You should have sufficient space on your hard disk to restore both the database and the log files of your largest database. ◆ Put your transaction log files and database files on separate physical drives. ◆ Implement practices to minimize Exchange database backup and restore times. ◆ Create schedules for archiving your backup media. ◆ Archive the backup media in a secure location, for example, a fireproof safe or at another location (offsite storage). ◆ Have a plan to monitor servers proactively. ◆ Monitor the health of the Exchange store. For example, monitor the event log for the occurrence of 1221 events to determine the amount of white space available in a database. If the available white space equals 30 percent of the size of the database, you might want to consider offline defragmentation of Exchange databases. Monitor your Event log for 1018 events, which indicate when your disks might be starting to fail. ◆ Distribute your users across multiple mailbox stores. ◆ Configure deleted item retention for your users. ◆ Configure deleted mailbox retention at the mailbox level. ◆ Verify the integrity of your backups; make sure that they occur without error by performing test restores and conducting recovery fire drills. ◆ Make sure that your insurance policy is sufficient to cover damages from loss of data.

How Can I Lose Thee? Let Me Count the Ways A number of things can happen to cause you to lose all or parts of your Exchange Server 2007– based messaging system. The longer you think about it, the more scenarios you can come up with. Scary, isn’t it? You can divide disasters into three categories based on the cause. Some disasters are physical hardware problems. A hard disk dies, a connection fails, or software simply become corrupted and starts malfunctioning. Some disasters are man-made. A user deletes a message or a folder or a mailbox by accident. A discontented employee or coworker acts maliciously and wipes out a store or inserts a virus that does the same. Your antivirus software isn’t patched in time and malware strikes. Or things that are catastrophic just happen. Your server is destroyed in a fire. The building collapses, a water main breaks, there’s gas leak, the air conditioning fails, or terrorists

PERFORMING DISASTER RECOVERY

fly passenger jets into your office building. Regardless of the cause, there are enough ways for something to go wrong that you know sooner or later something will. What should you do? How should you plan? Start from the premise that you can’t restore something if you don’t have it to restore. Make redundancy your favorite noun, and consider using ‘‘backup, backup, backup’’ as your mantra at yoga class and during all those meditative moments you work into your life. Do that, have a good disaster recovery plan, and a little luck, and you’ll ensure that you have the ability to repair or restore one, some or all of your messaging system components.

What Should You Protect? The only way you can recover from a disaster is to make sure that you’re protecting the items that need protecting. In order to do that, you need to have an idea of what it is that you need to be able to recover from. You should have a strategy in place to recover from the following situations: ◆ Lost mail item (permanently deleted mail) ◆ Lost mailbox ◆ Lost database or storage group ◆ Lost server that is running Exchange Server 2007 (Exchange databases and transaction log files intact) ◆ Lost server that is running Exchange Server 2007 (Exchange database and transaction log files also lost) ◆ Lost computer in an Exchange Server 2007 Network Load Balancing cluster ◆ Lost computer in an Exchange Server 2007 back-end Microsoft Windows Server failover cluster ◆ Lost database or storage group for a Windows failover cluster ◆ Lost entire Exchange Server 2007 back-end Windows Server failover cluster ◆ Lost external services (including domain controller services, global catalog services, certificate services, DNS, and so on) ◆ Lost site (including all Exchange servers and all servers that provide external services) And that’s just the start of possible combinations. To write the necessary strategy, you will need to identify the following: ◆ Components that can be restored by replicating data from other sources (for example, data that is stored in Active Directory) ◆ Components must be restored from backups (such as Exchange databases and transaction log files) ◆ What data can be re-created (such as connector and server configuration) The data that you can need to protect includes the following: ◆ Microsoft Windows Server operating system data ◆ Domain controller data

317

318

CHAPTER 11 TWEAKING THE INFRASTRUCTURE

◆ Exchange Server 2007 databases and transaction logs ◆ Edge server configuration data ◆ Hub server configuration data ◆ Client Access server configuration data ◆ Certification authority (for servers running certification services) ◆ Cluster configuration data (if you are using back-end clustering) ◆ Individual mailboxes ◆ Unique dynamic data ◆ Any other data stored on your servers that is specific to your organization and that would be difficult to re-create or restore. For example, custom scripts or web forms for Internet Information Services (IIS).

Backup! Backup! Backup! All the redundancy, security, and fault tolerance in the world cannot help you when it comes to a damaged, corrupt, or lost database. Backing up the critical data in your Exchange Server 2007 organization is a necessary operational task for all organizations. Performing backups of your servers is your first line of defense in planning for a disaster. You must have a well-planned and well-rehearsed disaster recovery plan for your Exchange organization. What to back up can be a difficult decision as you need to weigh the tradeoff between the amount you back up and how long it takes. If you take time to back up everything in your Exchange Server 2007 organization, you will most likely be able to restore completely all critical data and configuration settings. However, when you back up everything, the backup and restore processes are much complex, more time-consuming, and they require more disk space than if you did not back up all the data. Your disaster recovery plan should include backing up Exchange data and Active Directory directory service data daily. You must back up all critical data from many sources, including server configuration, the Active Directory database, and the Exchange Information Store service. You should also back up all logged event and performance data. Make sure that you back up records such as Active Directory data, application software, Exchange Server 2007 message tracking log files, and databases and log files. Regardless of what else you include in your backup, the most important priority for securing and protecting the data must be Active Directory data and Exchange databases, which include both Exchange database files and transaction log files. If you protect both of those sets of data, you will have additional options for recovering your Exchange data. Focus your resources on making sure that you protect those two items. Everything else is secondary. If an enterprise does not back up enough data on the servers in their messaging organization, it does not really have a backup strategy. For example, if your organization experiences a disaster, such as a lost mailbox server (including its Exchange databases and transaction log files) and has backups only of the Exchange databases and transaction log file basic server elements, you may be able to recover the Exchange Server 2007 database files and some Exchange configuration data. With such limited backups you may not be able to recover all the data and information that existed on the original server. Data and information on the original server could include cluster

PERFORMING DISASTER RECOVERY

configuration information, management scripts, or system management software that resided on the server before it was lost.

Note Some servers can be lost with no impact. For example, a Client Access server in a Network Load Balancing (NLB) configuration can be rebuilt and not require a backup since there is no important data stored on the server. You should also be able to answer the following ‘‘housekeeping’’ questions about your backups: ◆ After you perform backups, who will move the media to a secure location? ◆ Is the secure location somewhere local or remote? ◆ When will you use the tapes or other media for backup purposes again? ◆ Can you recover the backup media quickly if a disaster occurs?

Tip You should record all configuration settings and changes you make to a server starting as soon as its installation is completed. This allows you to manually redo them in the event of a disaster.

Backup Operations As you should already know, there are four backup types: Full Backup A full backup is a complete backup that archives every selected database and all necessary log files. Log files older than the checkpoint at the time the backup was started are deleted after the backup completes. It is the simplest backup and restore method because it gives you a single backup set to restore. Copy Backup A copy backup is a complete backup and is the same as a full backup except that log files are not deleted at the completion of the backup. A copy backup is useful if you want to save a copy of your Exchange databases at a specific point in time. The copy backup does not remove the log files. Log files must be removed or the log file drive will eventually fill up, and your Exchange database will be taken offline until the log files are purged. Incremental An incremental backup is a change-only backup that only archives the transaction log files since the last full or incremental backup. Log files older than the checkpoint are deleted after the backup is complete. You cannot perform an incremental backup when circular logging is enabled. To restore data from an incremental backup, you must have the most recent full backup and each subsequent incremental backup set available. After the restore process is complete, the transaction logs are applied to the Exchange database that you restored with the full backup. Differential Backup A differential backup is a change-only backup that archives only the transaction log files since the last full or incremental backup. The transaction logs are not deleted. You cannot perform a differential backup when circular logging is enabled. To restore

319

320

CHAPTER 11 TWEAKING THE INFRASTRUCTURE

data from a differential backup, you must have the most recent full and differential backups available.

Note You should perform daily full backups unless your databases are replicated continuously. For storage groups enabled for LCR, CCR, or SCR, weekly full backups are recommended. If you’re doing weekly full, you should be doing incremental between depending on the terms of the service level agreement (SLA).

Supported Backup and Restore Methods Exchange Server 2007 supports the following methods of backing up and restoring to the active copy of the database or recovery storage group: Legacy streaming backup All four types of Exchange backups (full, copy, incremental, and differential) are supported on the active copy of the database. Backups can be selected at the database level, but there can be only one backup job running against a specific storage group. Separate storage groups can be backed up at the same time. Legacy streaming restore All four types of Exchange backups can be restored to the active copy of the database or to the recovery storage group. VSS backup All four types of backups can be taken from the active copy. All four types can be taken from the replicated database. Backups can be selected at the storage group level. There can be only one backup job running against a specific storage group. (If a backup of a storage group is taken from a replica, you cannot initiate a backup from the active storage group until the first backup finishes.) Separate storage groups can be backed up in parallel. VSS restore All four types of backups can be restored to the active copy. VSS (Volume Shadow Copy Service) backups can be restored to the same storage group, to an alternate storage group on the same or a different server, or to a non-Exchange location as supported by the Exchange Server 2007 Store Writer. VSS backups cannot be restored to a storage group copy location using Exchange VSS components, but they can be restored as a file-level restore from VSS backups.

Note Streaming and VSS backup technologies cannot be combined either during backups or restores. Legacy incremental backups cannot be taken after VSS full backups. You cannot combine a VSS differential backup with a legacy full backup at restore time. What’s the best way to achieve the proper balance and know exactly what you have to do successfully recover from a disaster? I recommend you practice disaster recovery procedures in a test environment before you implement a backup strategy on your production servers. Once you’ve implemented a backup and recovery strategy, you should conduct test restore operations regularly to make sure that you will be able to recover from various disasters that may occur.

Restoring the Data Far too often, disaster recovery planning focuses on data backup and planning how to do it, where to store it and how to protect it. The second step, restoring the data, is sometimes overlooked.

PERFORMING DISASTER RECOVERY

Restores are equally as important as backups, but usually all the attention goes on backup procedures and backup products. Administrators shouldn’t wait to examine the detail of restores until a disaster happens. That is exactly the wrong time to begin thinking about restoring the data. It’s easy to overlook or be unaware of how long a restore operation is likely to take. You can count on the fact that unless you have tested it, you will likely underestimate the time it takes to do a backup and or restore. Inasmuch as databases have the capacity, and tendency, to expand quickly, backup times will grow in proportion. After a server has been in production for a number of months, you might find that it is time to consider looking for faster or higher-capacity media to help reduce backup times. You might for example switch to backing up to disk instead of tape, while still using tape for archival storage at predetermined message age. Remember, it is not just the Exchange databases that you have to back up to ensure that you can recover a system. You’re going to have to be dependent on recovery of the Active Directory database, other Windows data, the IIS metabase, Exchange binaries, user data, and other application data. All contribute to the amount of data and length of backup operations. If you followed best practice, most of your Exchange servers are not domain controllers or global catalogs, so you may not have to restore the Active Directory after a failure on an Exchange server. Make sure you apply the correct levels of service packs to Windows and Exchange on the recovery server before commencing any restore operation. The internal database schema has changed a number of times in Exchange’s history and so you usually cannot restore a database from a backup taken with a higher software revision level. This rule does not hold true for all combinations of service packs and versions, but there is enough truth in it to make a strong recommendation that you should maintain servers at the same software levels in order to ensure that you can always restore backups. You must account for all of the factors discussed here in the operational procedures you employ at your installation. Make sure you can answer the following questions: ◆ How long will it take to restore one gigabyte of data from your backup media using the backup software you employ? ◆ How long will it take to restore 3 GB, or maybe 10 GB, or how about a full-blown 100 GB mailbox store? ◆ How long will it take to restore a public store? ◆ What are the procedures in place to restore Active Directory? As you should know, even assuming that you can instantly move to replacement hardware, the answer to how long it takes to restore a server is counted in hours. After the restore is complete, you may have other work to do before Exchange is available for use again. For instance, the store must replay transaction logs to roll forward messages and other items that are not fully committed to the database. The store does this automatically, but applying masses of transactions at one time delays the startup operation (depending on processor speed and other load, a set of 100 logs might take between 20 and 30 minutes to process on a slow server). Of course, while this is going on, users will likely be on the phone or arriving personally demanding that you get the system back online as quickly as possible. The increased stress levels don’t help and that alone is justification enough to have a written procedure you can follow to restore essential data. Face it — do you want to be explaining to the CIO or executive management why the messaging system was unavailable for one or two days while staff fumbled their way through the recovery like the Keystone Kops?

321

322

CHAPTER 11 TWEAKING THE INFRASTRUCTURE

Recovery Strategies Choose a strategy for recovering from different service or server failures, such as the following: ◆ How to recover from an entire mailbox server failure ◆ A single or multiple database failures ◆ A single mailbox or individual item

Recovering from an Entire Mailbox Server Failure If your Exchange Server 2007 organization encounters a problem that requires the recovery of a server that is running Exchange Server 2007 (for example, if a fire destroys one of your servers), you can select from four recovery options: ◆ Conduct a full server recovery. In this instance, you restore the server from a full computer backup set and then restore your Exchange databases. A full backup set includes a backup of system state data, the Exchange binary files, and most of the data on your hard disks. ◆ You can rebuild the server completely. This option involves performing a new installation of Windows Server running Exchange Server 2007 in Disaster Recovery mode, and then restoring your Exchange databases. This option assumes that Active Directory service is still available in Exchange Server 2007 in Disaster Recovery mode. ◆ You can use a standby recovery server as part of the rebuild the server strategy. This option involves keeping recovery servers available with the operating system and other software installed. Having standby recovery servers available reduces the time it takes to rebuild a damaged server. ◆ Database Portability to restore the database to an existing server and bring the users online. A full server recovery is needed when a disaster damages one of your servers to a point where you must take steps to, at a minimum, rebuild or restore the operating system and Exchange installation. Additionally, you may have to restore other information such as Exchange databases. You can categorize full server recovery strategies as either a full computer backup and restore, or a clean operating system install and Exchange disaster recovery. A full computer backup strategy must include the Exchange binaries. Restores require a System State restore, which should be performed using similar hardware. The clean operating system installation recovery method includes recovering Microsoft Windows by running Windows Setup, restoring a Windows backup set, and then running Exchange Server 2007 in Disaster Recovery mode to retain your Exchange configuration. You must also be prepared to re-create configuration data manually if it becomes necessary. Although running Setup /mode:RecoverServer can help you bring up a functional server, it may not preserve every custom setting or leave connectors functional. Therefore, you should be prepared to re-create any Exchange configuration settings in the event that you cannot recover those settings stored in Active Directory. Creating Powershell scripts for server configuration can speed up this process and makes sure that a configuration is not missed. If you can manually reconfigure the server, you have additional recovery options if a disaster occurs. Reconfiguring the server involves such tasks as reconfiguring your connectors, making metabase modifications, and making registry modifications. Another method you can use to recover a lost server is to use a backup of the system state and critical Exchange files. The System State Backup recovery method requires that the same hardware

PERFORMING DISASTER RECOVERY

is used for server restoration. At a minimum, your backup must include both the system state data and the Exchange files installed by Exchange. You will need the Exchange installed files because you will not be able to run Setup options to recover your Exchange configuration if Exchange Setup detects the partial Exchange Server 2007 existence on the server. In the event of a Client Access, Hub Transport, or Edge Transport server failure, you may simply be able to move to the failover server while you perform the previous recovery or rebuild operations.

Recovering from Single or Multiple Database Failures Recovery methods include recovering from the following: Using Exchange Streaming Backups Sets Individual databases in a storage group may be restored while all other databases remain online. This method is the preferred means of replacing a single failed database. When the database is remounted, pertinent transactions are automatically played back from the storage group’s log files to bring the restored database back to the time of the disaster. When you use Backup to restore Exchange databases, API calls are made to the Exchange Extensible Storage Engine (ESE) to restore Exchange database files and their associated log files. You can use Exchange database backups to restore one or more damaged mailbox stores or public folder stores. You can also use Exchange database backups to restore every mailbox and public folder on the server. In a disaster recovery scenario that involves rebuilding a server, use Backup to restore your Exchange databases after you run Exchange Setup and any Exchange service packs in Recover Server mode (assuming that Active Directory is still available). Using Hardware-Based Snapshot Backup Sets Exchange Server 2007 supports hardwarebased snapshots using the Volume Shadow Copy Service (VSS) implemented in Windows Server 2003. Generally, it takes much less time to restore a backup that was taken using a hardware-based snapshot. Therefore, depending on the hardware and software that was used in the solution, restoring Exchange data from these types of backups may make it easier to meet the elements of your service level agreement (SLA) requirements that relate to the time that it takes to restore Exchange databases. Additionally, because larger databases can be restored more quickly, hardware-based snapshot restores can help you support larger database sizes and still let you meet your SLAs for restoring Exchange data. Use Dial Tone Portability Dial tone portability was introduced in Exchange Server 2007. Dial tone portability allows a user’s mailbox to be moved without having access to any of the mailbox content. This allows an alternative server to house the mailboxes of users who were previously on a server that is no longer available. With the Outlook 2007 and Exchange Server 2007 Autodiscover service, clients are redirected to the new server when they try to connect, removing the past requirement that the Outlook profile be modified to redirect a user to a new server. Users are then moved to this new server and quickly regain the ability to send and receive email messages. In this event, another alternative would be for a new mailbox database to be created on an existing mailbox server. Users can then be moved to the existing server. Dial tone portability is a useful, albeit limited, business continuity solution that can help you keep business operations functioning during the recovery process of a single database. After the recovered database is brought back online, it provides the ability to merge the dial tone and recovered databases into a single up-to-date mailbox database.

323

324

CHAPTER 11 TWEAKING THE INFRASTRUCTURE

Recovering Mailboxes and Individual Items Exchange Server 2007 provides additional flexibility with regard to how you can back up and recover mailboxes. This flexibility included the recovery storage group on the server side and the Cached Exchange Mode feature of Microsoft Office Outlook 2007 on the client side. The latter is outside the range of this book. Consider implementing one or more of the following strategies to help you be prepared to recover individual mailboxes or individual items: Server-side deleted item retention In this method, you help protect mailboxes from accidental item deletion through the clients by saving deleted items before purging them from a mailbox. You can customize the deleted item retention period for your users. Server-side reconnect of a deleted or orphaned mailbox You can reconnect deleted or orphaned mailboxes to a user account by using the Exchange Management Console or by using the Exchange Management Shell. You can customize the time that deleted or orphaned mailboxes can be retained on the server. Restoration of backups performed at the mailbox level In the case of a damaged mailbox, you can restore a user’s individual mailbox from backup.

Note If your users are using client-side caching of mailbox data such as Cached Exchange mode, they should have a local copy of their mailbox data on their computer.

Recovery storage group With the recovery storage group feature in Exchange Server 2007, you can mount a second copy of an Exchange mailbox database on the same server as the original database or on any other server that is running Exchange in the same Exchange administrative group. This action can be performed while the original database is still running and serving clients. With this capability, you can recover data from an older backup copy of the database without disturbing user access to current data. The recovery storage group can also be useful in various disaster recovery scenarios, most notably the messaging dial tone scenario. Third-party brick-level backups Some third-party backup tools let you back up and restore Exchange at the level of individual mailboxes. Alternate server method This method requires that you restore an entire database to a server outside of your production environment and that you extract the mailbox data that you want. Although this method is still valid, whenever possible, you should use the recovery storage group method.

Recovery Storage Group Exchange Server 2007 provides a feature called the recovery storage group. The recovery storage group is a specialized storage group that can exist alongside the regular storage groups in Exchange, even if the server already has the maximum number of regular storage groups. You can restore Exchange Server 2007 mailbox stores from any storage group in the Exchange organization. You can only have one recovery storage group per Exchange server. After you restore a mailbox store to the recovery storage group, move the recovered mailbox data from the recovery storage group to the regular storage group. With this method, you can recover an entire mailbox store, which contains all the database information, including the log

PERFORMING DISASTER RECOVERY

data, or just a single mailbox. Mailboxes in the recovery storage group are disconnected and are not accessible to users who have mail clients.

Note You can use the recovery storage group to recover only mailbox stores, not to recover public folder stores. The recovery storage group also makes it possible to offer dial tone service quickly after a failure. This capability means that users can create and receive mail while their existing data is being restored. Frequently, this approach is the fastest way to restore mail service to users. Because the volume of data generated by the users is likely to be less than the amount of data in the existing database, merging the dial tone mail data into the original store after it is recovered is faster than moving the original database contents to a new store. When correctly used, the recovery storage group can be a powerful tool for reducing outage times.

Continuous Replication In addition to traditional backup methodologies, Exchange Server 2007 includes continuous replication (asynchronous log shipping), which can be used to create and maintain a copy of a production storage group on another set of disks or on another server. As you saw earlier, there are three types in Exchange Server 2007 Service Pack 1: ◆ Local continuous replication (LCR) ◆ Cluster continuous replication (CCR) ◆ Standby continuous replication I’ll talk about their role in high availability in the next section of this chapter, but for now let’s briefly examine how ECR can help you in your disaster recovery.

Note When I speak of the three types of continuous replication collectively, I’ll refer to them as Exchange continuous replication (ECR). In addition to allowing almost immediate restoration abilities when properly configured, ECR provides a type of backup service. In fact, Microsoft almost argues that you can skip daily backups using ECR and back up on a weekly basis. Their logic is that full daily backups are taken to provide a known good starting point for restore operations should a problem occur. If you deploy ECR, then that new starting point already exists in the form of the copy of the database; hence, full daily backups aren’t required.

Warning If a database is corrupted, the corruption could be replicated to the second copy. Deletions can also be replicated. Although there is a certain truth to that, it ignores the fact that full daily backups also provide copies of data that can be taken offsite to media vaults to be used for restore operations in the

325

326

CHAPTER 11 TWEAKING THE INFRASTRUCTURE

case of catastrophic failure or to satisfy audit requirements. These needs still exist, so I wouldn’t recommend you cease taking full daily backups.

Achieving High Availability In the past, when you had the crash of a mail system, you could expect two things. It would take only a couple of hours to get the mailbox data back online, and users were reasonably tolerant of that length of delay. Your time usually wasn’t that long, even if you had to make hardware or software repairs as well for the simple reason that the Exchange databases were usually less than 10 GB, so the restore didn’t take too long, even using slow tapes. Things have definitely changed, and as email has become a critical business tool, that tolerance has vanished. Exchange Server 2007 is the first release to include the ability for the store to replicate its data — something that Lotus Notes has had much longer. With Exchange Server 2007, you can duplicate transaction logs on a local server basis (LCR) or to the other server in a two-node cluster (CCR) or to another datacenter in a two-node cluster (standby continuous replication). The premise behind ECR is that data outages are expensive to recover from and the time frame unacceptably long because restoring from backup takes is a lengthy process. If transaction log files are missing, corrupted, or cannot be replayed into the recovered database, you have data loss. The logical solution to this is to keep a copy of critical data that is up to date and available to be switched to take the place of production data if a problem occurs. There are two ways to do this. You can keep a copy of the data on the same computer or keep the copy on a different computer, and that is what ECR does by using the principle of log shipping to enable loose synchronization of mailbox data through continuous replication.

Note Log shipping is the same technique that is used by SQL Server and Lotus Notes to provide continuous replication. Copying the transaction logs and applying them against a copy of the live database ensures that you will not lose data following a failure. Instead, you simply switch to an up-to-date copy of the failed database and restore service without having to deal with the complexities involved in restoring the database from a backup. Once you have a second working system, you just reinitiate the replication method so the replica is created. Another advantage of ECR is that administrators don’t have to worry about the interaction and potential dependencies between third party storage add-ons and the base product, especially after Microsoft updates Exchange or Windows with hot fixes or service packs.

Types of ECR As mentioned earlier there are three type of ECR: local (LCR), continuous (CCR), and standby (SCR). All three provide quick recovery, high availability, and site resilience for Mailbox servers.

Local Continuous Replication (LCR) CLR is the single-server version. As you can see in Figure 11.7, all of the processing done by LCR is on a local server, which is its real difference from CCR and SCR. LCR uses built-in asynchronous log shipping technology to create and maintain a copy of a storage group on a second set of disks that are connected to the same server as the production storage group. LCR provides log shipping,

ACHIEVING HIGH AVAILABILITY

log replay, and a quick manual switch to a secondary copy of the data. This can generate increased CPU and disk utilization on your server, so plan accordingly.

Figure 11.7 How local continuous replication works

Cluster Continuous Replication (CCR) CCR operates similarly to LCR, the principal difference being that Exchange copies the logs to a remote server for processing when you use CCR as you can see in Figure 11.8. CCR is designed to be either a one or two data center solution, providing both high availability and site resilience. CCR nodes must be in the same AD site and same IP subnet. Only Windows 2008 will allow the servers to be on different IP subnets.

Figure 11.8 How cluster continuous replication works

Standby Continuous Replication Exchange Server 2007 SP1 introduced this variation on the CCR theme. The difference is that while CCR uses two nodes in a Majority Node Set (MNS) cluster, this does not have to be the setup; SCR

327

328

CHAPTER 11 TWEAKING THE INFRASTRUCTURE

could be in the same location or a different location, as shown in Figure 11.9. An SCR model allows Exchange to survive even a catastrophic datacenter outage by allowing a standby node in a different/local datacenter to take on the load of the active node if an outage stops the active node working. It’s important to note that SCR will not automatically come online; there are a number of manual steps that must be taken to bring the replica online.

Figure 11.9 How standby continuous replication works

Single

SCR

SCR depends on the same basic principle as CCR in that the standby node has to copy (or pull) transaction logs from the active node on an asynchronous basis and apply them to its copy of the database. As with CCR, you have to ensure that a reliable link exists between the two servers to allow the passive node to copy logs in a timely manner. If the network between the two servers suffers from high latency or low throughput, then the passive node may not be able to copy logs quickly enough to ensure that it can replay sufficient logs to stay within the lost log resilience threshold in the event of a failover. As I write this it is far too early to be able to make a reasoned assessment of how well SCR will function in production environments and the necessary hardware and network prerequisites that you will have to put in place to use SCR successfully. However, it is clearly an option that you should consider employing depending on the needs of your Exchange Server 2007–based messaging system.

Setting Up Local Continuous Replication Setting up an LCR-enabled mailbox database, storage group or public folder is fairly straightforward. Using LCR begins with enabling a storage group for LCR. You can accomplish this task by using the Exchange Management Console or the Exchange Management Shell.

Enabling a Storage Group To use the Exchange Management Console to create a new LCR-enabled storage group, follow these steps:

1. Open the Exchange Management Console. 2. Expand Microsoft Exchange, expand Server Configuration, and then select Mailbox. 3. In the result pane, right-click the server on which you want to create the new storage group and select New storage group. The New Storage Group Wizard appears.

4. On the New Storage Group page, type the name for the new storage group in the Storage Group Name box.

ACHIEVING HIGH AVAILABILITY

5. Use the Browse buttons to specify the locations for the storage group’s log files and system files.

6. Select the Enable local continuous replication for this storage group check box. 7. Use the Browse buttons to specify the locations for the passive copy of the log files and system files, and then click New.

8. After the new storage group has been created and enabled for LCR, click Finish. To use the Exchange Management Shell to create a new LCR-enabled storage group, run the following command: New-StorageGroup -Server -Name LogFolderPath -SystemFolderPath -HasLocalCopy:$true CopyLogFolderPath CopySystemFolderPath

Note The procedure is similar if you are using an existing storage group, except you select an existing storage group rather than create a new one. After LCR has been enabled for a storage group, it will initially report a status of Initializing. The storage group will change from a status of Initializing to a status of Healthy after one transaction log file has been generated.

329

330

CHAPTER 11 TWEAKING THE INFRASTRUCTURE

Enabling a Mailbox Database or Public Folder for LCR The next step is to enable the mailbox database or public folder for LCR. The same procedures are followed, with slight variations, depending on whether you are enabling a mailbox database or public folder, and whether or not you are using an existing one or creating a new one. To use the Exchange Management Console to create a new LCR-enabled mailbox database, follow these steps:

1. Open the Exchange Management Console. 2. In the console tree, expand Server Configuration, and then click Mailbox. 3. In the result pane, select the server on which you want to create the new mailbox database. 4. In the work pane, select the storage group to host the new database. The storage group must not contain any databases.

5. In the action pane, click New Mailbox Database. The New Mailbox Database Wizard appears.

6. In the Mailbox database name box, type the name for the new database.

7. Select the database file location by clicking Browse and navigating to the desired location. Databases cannot be placed at the root of a volume.

8. Leave the Mount this database box selected, and click New to create the database. 9. Click Finish to complete the wizard.

ACHIEVING HIGH AVAILABILITY

To use the Exchange Management Shell to create a new LCR-enabled mailbox database, run the following command: New-MailboxDatabase -Name StorageGroup: -HasLocalCopy:$true EdbFilePath: CopyEdbFilePath:

Note LCR continuously checks and accesses the copy unless replication and replay are halted for the copy. If you need to manipulate the disk volumes, you must first halt replication.

Tuning the Default Configuration of the Transport Dumpster The transport dumpster is a feature of the Hub Transport server role that submits recently delivered mail after an unscheduled outage. The Hub Transport server maintains a queue of mail that was recently delivered to a mailbox: ◆ In a clustered mailbox server in a CCR environment ◆ In a storage group that is enabled for LCR The transport dumpster should always be turned on when using CCR or LCR. The transport dumpster is enabled organization-wide by setting the amount of storage available per storage group and setting the time to retain mail in the transport dumpster. The transport dumpster is AD-site-specific. You can use the Set-TransportConfig cmdlet to change the default configuration settings for the transport dumpster, which are applied at the storage group level. You should configure the MaxDumpsterSizePerStorageGroup parameter, to set the maximum size of the transport dumpster queue for each storage group, to a size that is 1.5 times the size of the maximum message that can be sent. For example, if the maximum size for messages is 10 MB, you should configure the MaxDumpsterSizePerStorageGroup parameter with a value of 15 MB. You should configure the MaxDumpsterTime parameter, which specifies how long an email message should remain in the transport dumpster queue, to a value of 7.00:00:00, or seven days. Messages will be removed from the transport dumpster when the size specified by MaxDumpsterSizePerStorageGroup is reached. Otherwise, they will be removed from the transport dumpster when the time specified by the MaxDumpsterTime parameter has elapsed. This should be sufficient time to allow for an extended outage to occur without loss of email messages. When using the transport dumpster feature, additional disk space will be needed on the Hub Transport server to host the transport dumpster queues. The amount of storage space required is approximately equal to the value of MaxDumpsterSizePerStorageGroup multiplied by the number of storage groups on all clustered mailbox servers in a CCR environment and all LCR-enabled storage groups in the Active Directory site containing the Hub Transport server.

Note In a CCR environment, request for redelivery from the transport dumpster on all Hub Transport servers in the site is performed automatically. In an LCR environment, the request for redelivery from all Hub Transport servers in the site occurs as part of the Restore-StorageGroupCopy task.

331

332

CHAPTER 11 TWEAKING THE INFRASTRUCTURE

To use the Exchange Management Console to view and configure the transport dumpster settings, follow these steps:

1. Open the Exchange Management Console. 2. Expand Organization Configuration, and then select Hub Transport. 3. In the Results pane, select the Global Settings tab. 4. Double-click Transport Settings. 5. In the Transport Dumpster area, enter the appropriate values for the Maximum size per storage group (MB) and Maximum retention time (days) fields.

6. Click OK to save the changes. You can use Exchange Management Shell to determine the current settings of the transport dumpster with the command Get-TransportConfig To configure the transport dumpster, you should run the following command: Set-TransportConfig - MaxDumpsterSizePerStorageGroup 30MB -MaxDumpsterTime 07.00:00:00

Note You should familiarize yourself with the remaining various procedures for managing LCR available in the Exchange Server 2007 SP1 documentation. These include seeding, activating passive clusters, halting LCR, and so on.

ACHIEVING HIGH AVAILABILITY

Managing Cluster Continuous Replication You can create a new Windows Server 2003 cluster for an Exchange Server 2007 clustered mailbox server (CMS) in a cluster continuous replication (CCR) environment by using the New Server Cluster Wizard or by using the command-line tool Cluster.exe.

Using the New Server Cluster Wizard to Create a New Failover Cluster To create a new failover cluster, follow these steps:

1. Open a command prompt window, and run the following command: Cluster /create /wizard

2. The New Server Cluster Wizard appears. Verify that you have the necessary information to continue with the configuration, and then click Next.

3. In the Domain field, select the name of the domain in which the cluster will be created. In the Cluster name field, enter a unique name for the cluster that is 15 characters or fewer in length, and the click Next.

4. On the Select Computer page, verify or type the name of the computer that you plan to use. Click Advanced, and select Advanced (minimum) configuration, and then click OK. Click Next.

5. On the Analyzing Configuration page, the wizard analyzes the domain and the node for possible issues that can cause installation problems. Review any warnings or error messages that appear. Click Details to obtain more information about each warning or error message.

333

334

CHAPTER 11 TWEAKING THE INFRASTRUCTURE

6. After all checks complete successfully, click Next. Resolve any errors before continuing with the installation.

7. On the IP Address page, type the unique, valid cluster IP address, and then click Next. The wizard automatically associates the cluster IP address with the public network by using the subnet mask to select the correct network. The cluster IP address should be used for administrative purposes only and not for client connections.

8. On the Cluster Service Account page, type the username and password for the Cluster service account. In the Domain field, select the domain name, and then click Next. The wizard verifies the user account and password.

9. On the Proposed Cluster Configuration page, click Quorum. Select Majority Node Set from the drop-down box. Click OK, and then click Next.

10. On the Creating the Cluster page, review any warnings or error messages that appear while the cluster is being created. For more information about warnings or errors, click to expand each warning or error message. To continue, click Next.

11. Click Finish to complete the cluster formation.

Using the Server Cluster Wizard to Add a Second Node to the Failover Cluster To add a second node to the failover cluster, follow these steps:

1. Open a command prompt window, and then run the following command: Cluster /add /wizard

2. After the Add Nodes Wizard appears, click Next.

ACHIEVING HIGH AVAILABILITY

3. In the Domain list, click the domain where the server cluster is located, verify the cluster name in the Cluster name box, and then click Next.

4. In the Computer name field, type the name of the node that you want to add to the cluster, click Add, and then click Next.

5. After the wizard has analyzed the cluster configuration successfully, click Next. 6. In the Password field on the Cluster Service Account page, type the password for the Cluster service account. Make sure that the correct domain for this account appears in the Domain list, and then click Next.

7. On the Proposed Cluster Configuration page, view the configuration details to verify that the server cluster IP address, networking, service account, and quorum information are correct, and then click Next.

8. After the second node is successfully added to the cluster, click Next, and then click Finish to return to the command prompt.

Note You can use Cluster.exe from the command line to create a new failover cluster. Now that the second node has been added to the cluster, you need to do the following steps using the procedures outlined in the Exchange Server 2007 SP1 documentation:

1. Configure the Majority Node Set quorum to use the file share witness. 2. Configure the cluster networking components and priority. 3. Configure tolerance settings for missed cluster heartbeats. 4. Verify that the failover cluster is functional. 5. Create a clustered mailbox server (CMS) on the active node in a cluster continuous replication (CCR) for a new or existing Mailbox server.

6. Install the passive node. 7. Configure the transport dumpster. 8. Tune the failover and mount attribute settings. SP1 introduced a way to do the latter using the Exchange Management Console:

1. Open the Exchange Management Console. 2. Expand Server Configuration, and then select Mailbox. 3. In the result pane, right-click the clustered mailbox server (CMS) and select Properties. 4. Select the Clustered Mailbox Server tab. 5. Use the Auto database mount dial drop-down box to configure the desired failover availability settings.

6. Click OK to save the change.

335

336

CHAPTER 11 TWEAKING THE INFRASTRUCTURE

Note Because the drop-down box only sets the value for AutoDatabaseMountDial, you need to use the Exchange Management shell to set the ForcedDatabaseMountAfter parameter using the following command Set-MailboxServer -ForcedDatabaseMountAfter:.

Managing Standby Continuous Replication SCR is enabled and managed only by using the Exchange Management Shell using the commands described in Table 11.2. The Exchange Management Console cannot be used to enable or disable SCR, view SCR status, or manage any aspects of SCR.

Table 11.2:

SCR Commands

To Do This...

Run This Command

Enable SCR for a new storage group

New-StorageGroup -Server -Name

-LogFolderPath SystemFolderPath StandbyMachine

Enable SCR for an existing storage group

Enable-StorageGroupCopy -Identity -StandbyMachine -ReplayLagTime 0.1:0:0

Disable SCR for storage group

Disable-StorageGroupCopy -Identity -StandbyMachine

Move the location for storage group files for an SCR-enabled storage group

First, you must suspend SCR: Suspend-StorageGroupCopy -Identity -StandbyMachine

Then you can move the location: Move-StorageGroupPath -Identity -LogFolderPath -SystemFolderPath -ConfigurationOnly Then you need to resume SCR: Resume-StorageGroupCopy -Identity -StandbyMachine

Move a database

First, you must suspend SCR: Suspend-StorageGroupCopy -Identity -StandbyMachine

ACHIEVING HIGH AVAILABILITY

Table 11.2:

SCR Commands (CONTINUED)

To Do This...

Run This Command Then you can move: Move-DatabasePath -Identity EdbFilePath ConfigurationOnly Then you need to resume SCR: Resume-StorageGroupCopy -Identity -StandbyMachine

Review status (quick and dirty)

Get-StorageGroupCopyStatus -Identity \ -StandbyMachine

View the ReplayLagTime and TruncationLagTime settings for an SCR-enabled storage group

$a=Get-StorageGroup

$a.StandbyMachines $a.StandbyMachines[0].ReplayLagtime $a.StandbyMachines[0].TruncationLagtime

Verify database and transaction log for an SCR-enabled storage group

First, you must suspend SCR: Suspend-StorageGroupCopy -Identity -StandbyMachine

Verify: Vssadmin create shadow /for= Then you need to resume SCR: Resume-StorageGroupCopy -Identity -StandbyMachine

How to seed an SCR-enabled storage group

First, you must suspend SCR: Suspend-StorageGroupCopy -Identity -StandbyMachine

To seed: Update-StorageGroupCopy -Identity -StandbyMachine

Then you need to resume SCR: Resume-StorageGroupCopy -Identity -StandbyMachine

337

338

CHAPTER 11 TWEAKING THE INFRASTRUCTURE

Single Copy Clusters Exchange Server 2007 clusters create logical servers that are referred to as clustered mailbox servers by using the Microsoft Windows Server Cluster service. Exchange Server 2007 only supports active/passive single copy cluster (SCC) configurations; they are no longer Active/Active supported. An SCC cluster can contain up to 8 nodes with Windows 2003 and 16 nodes with Windows 2008. SCC is a clustered solution that uses a single copy of a storage group on storage that is shared between the nodes in the cluster. This model has been supported in slightly variant versions since Exchange 5.5. SCC involves servers and storage collocated in the same physical place, so a catastrophic disaster can wipe everything out. Figure 11.10 shows the major components of an SCC. All of the Exchange mailbox data — databases, transaction logs, SMTP folders, content indexing, and so on — goes on shared storage that the cluster can move between the nodes in the cluster. The simplest SCC has two nodes, one active and one passive. Exchange runs as a virtual server (now called a CMS, or clustered mailbox server) that can move between the nodes just like a physical resource such as storage.

Figure 11.10 Single Copy Cluster

EX07Server01

EX07Server02

Active

Passive

NodeA

NodeB

Shared Storage

Database and Log Files

Managing and Maintaining the Messaging System Now that your system is up and running, you want it to stay that way. As you know from your own experience the degradation process starts from the moment you start the deployment. This manifestation of the law of entropy is reflected in a variety of ways, including the degradation of hardware and software, file corruption, and the normal changes you can expect in a large organization, or even a small one for that matter. This accumulation of errors will eventually render your messaging system nonfunctional. The simplest way to avoid this is through ‘‘operations management,’’ which is IT jargon for monitoring and proactively performing maintenance of the messaging system you’ve created. In the case of your Exchange Server 2007–based messaging system, this means that you will have to actively monitor the physical platform, the operating system, and all of the important Exchange

MANAGING AND MAINTAINING THE MESSAGING SYSTEM

Server 2007 services. Preventive maintenance helps you identify potential errors before any one of these errors cause problems with the operation of your Exchange organization. Preventive maintenance combined with disaster recovery planning and regular backups will minimize any problems that occur. Operations management also includes the day-to-day administrative tasks, both planned and on-demand, that are required to ensure smooth operations of the messaging system. Normally, these tasks are laid out in written procedures. These procedures provide all support staff with the same standard tools and methods. Having written procedures makes it much easier for everyone to know what is expected and to ensure consistency. It also makes it much easier for new staff to quickly learn the tasks before them. Of course, writing the procedures out is never enjoyable but doing so will save you countless man-hours, if not days, of frustration and exasperation. In a Exchange Server 2007–based messaging system environment, typical system administration tasks include creating mailboxes, backing up and archiving mailbox and public folder data, monitoring logs, maintaining and recovering mailboxes, and updating antivirus scanners. The tasks that need to be performed can generally be separated into daily tasks, weekly tasks, monthly tasks, and as needed (or ad hoc) tasks.

Note Checklists are useful to help make sure that the required tasks are performed at the appropriate time. A collection of sample checklists is available in Appendix D.

Daily Tasks Every day you do certain tasks — brush your teeth, check your email, kiss your partner, pay your bills, make your bed, put away the clean dishes, and so forth. Probably if you were like me at some point your parents (and then you) called them your daily ‘‘chores.’’ You even probably had a checklist or three. When I was a child, my parents taped it the refrigerator and put a gold star next to each one as it was completed; now I carry it around on my PDA and make an electronic checkmark. It’s not quite as satisfying, but the point is the same. To maintain our lifestyle and health, we do some chores everyday. Keeping up an Exchange Server 2007–based messaging system means checking for problems with connections, services, server resources, and system resources. The daily tasks outlined below help you keep the system up and running and make sure that you’re doing the following: ◆ Meeting the performance requirements of your service level agreements (SLAs) ◆ Successfully completing specific administrative tasks, such as daily backup operations, and checking server health ◆ Detecting and addressing issues such as bottlenecks in the server performance or need for additional resources before they affect productivity Another advantage is that you can use daily maintenance tasks to determine what’s normal for your organization, define normal, and use it to detect any abnormal activity. Implement daily maintenance tasks so that you can capture and maintain data about your Exchange organization, such as usage levels, possible performance bottlenecks, and administrative changes. What should you be checking on a daily basis?

339

340

CHAPTER 11 TWEAKING THE INFRASTRUCTURE

Physical Environment Check the physical environment on a daily basis: ◆ Confirm that physical security protection such as locks, doors, and restricted-access rooms are working. Check for any unauthorized and forced entries and signs of equipment damage. ◆ Check the temperature and humidity to help make sure that the environmental systems such as heating and air conditioning are maintaining acceptable conditions and function within the hardware manufacturer’s specifications. ◆ Check to make sure that routers, switches, hubs, physical cables, and connectors are operational.

Monitor Backups Make sure that the previous night’s backup jobs have run, and then investigate any errors or warnings. Make sure that you have a procedure for media rotation, labeling, and storage, according to the backup strategy being used and that it is being followed. If applicable (based on the type of the backup that was run), determine whether the transaction logs have been removed from the disk as part of the backup process. Proactively monitoring the successful completion of your Exchange backups is critical to success of your disaster recovery plan. As explained earlier in the chapter, you should regularly test the disaster recovery plan for your Exchange infrastructure in a laboratory environment that mimics your production environment.

Check Disk Space Hard disks drives are a critical component of your Exchange organization. Without sufficient free disk volume, neither the operating system nor the Exchange databases can function correctly. Exchange Server 2007 needs hard disk space to store its databases and transaction logs. To accommodate troubleshooting and disaster recovery situations, it is recommended that available free volume space be equal or greater than 110 percent of the size of database. Hence you must check the Exchange store statistics daily and be prepared to add storage resources as required.

Note When the Exchange Information Store service runs out of hard drive space, it logs Event ID 1113 in the Application event log to indicate the problem. You can check free disk space by using the following methods: ◆ Windows Explorer can be used to physically check each volume. ◆ Run a script that will send you an alert message if the hard disk space falls below 100 MB. A sample script for monitoring disk space can be found at www.microsoft.com/technet/ scriptcenter/scripts/default.mspx?mfr=true. ◆ Microsoft Operations Manager (MOM) can be used to alert administrators when volume space is running low. ◆ System Center Operations Manager 2007 (formerly MOM).

MANAGING AND MAINTAINING THE MESSAGING SYSTEM

Check the Event Viewer Every day you should review the logs (shown in Figure 11.11) maintained by Event Viewer. These logs will contain information about service failures, Active Directory replication errors, and warnings about system resources such as virtual memory and disk space reported by both the operating system and Exchange Server 2007. Event Viewer can be used to view and manage event logs; obtain information about hardware, software, and system problems that must be resolved; and identify trends that require future action.

Figure 11.11 The Application Event Log can be used to identify the sources of some problems.

You should periodically archive the logs or use automatic rollover to avoid running out of space. Because log files can occupy a finite amount of space, increase the log size (for example, to 50 MB) and set it to overwrite, so that Exchange Server can continue to write new events.

Note For information about using Event Viewer as a troubleshooting tool, see Microsoft Knowledge Base article 302542 (http://go.microsoft.com/fwlink/?linkid=3052&kbid=302542).

You can automate event log administration by using tools and technologies such as the following: ◆ The Event Comb tool lets you gathers specific events from the event logs of several computers to one central location. It also lets you report on only the event IDs or event sources you specify. ◆ This command-line tool Eventtriggers.exe allows you to create event triggers that will run programs when specific events occur. ◆ You can use Microsoft Operations Manager (MOM) to monitor the health and use of Exchange servers. Exchange Server 2007 Management Pack extends Microsoft Operations Manager by providing specialized monitoring for servers that are running Exchange Server 2007. This management pack includes a definition of health for an Exchange Server 2007 server and will raise an alert message to the administrator if it detects a state that requires intervention.

341

342

CHAPTER 11 TWEAKING THE INFRASTRUCTURE

Monitoring Server Performance Obviously, if your server is not functioning optimally, Exchange Server 2007 will also run sluggishly. Monitoring server performance helps you to make sure that your servers are functioning correctly and helps you identify bottlenecks in the system. You can use the performance monitoring data described in the next section to identify problems and apply corrective action. You can also use the monitoring data to enhance the performance of your servers by identifying areas that need additional resources.

Monitoring the Operating System If your organization is small, or if you rely on one server for most of your Exchange Server 2007 operations, you may need to monitor only one server. If you have a larger organization, or if you want to monitor the performance of all servers and components in Exchange Server 2007, such as the Exchange Information Store service, you can use any of the following tools: System Monitor System Monitor helps you define, collect, and view a lot of data about the usage of hardware resources and the activity of system services on computers that you administer. You can specify the type of data you want to monitor and the source of the data, and establish sampling parameters, such as manual or automatic, within a time interval on real-time data. You can even change the appearance of your System Monitor to use graph, histogram, or report views. Performance Logs and Alerts Performance Logs and Alerts allows you to collect performance data automatically from local or remote computers. You can view logged counter data using System Monitor or import the data into spreadsheet programs or databases for analysis and report generation. You can set an alert on a counter, thereby defining that a message be sent, a program be run, an entry made to the application event log, or a log be started when the selected counter’s value exceeds or falls under a specified setting.

Note Alerts can only be sent if the Windows Server 2003 Messenger Service and the Windows Server 2003 Alerter Service are enabled and the recipient account is registered in the Windows Internet Name Service (WINS). The Messenger and Alerter services are disabled by default. Task Manager You can use Task Manager to monitor key indicators of your computer’s performance. You can see the status of the programs that are running and end programs that have stopped responding. You can also assess the activity of running processes using up to 15 parameters, and see graphs and data on CPU and memory usage. In addition, you can view the network status and see how your network adapter is functioning. If you have more than one user logged on to your computer, you can see who is connected, what they are working on, and you can send them a message.

Monitoring Network Performance You can monitor your network by using the following tools: Network Monitor Network Monitor collects, displays, and analyzes resource usage on a server and measure network traffic. By using this data with performance logs, you can determine your network usage, identify network problems, and forecast your network needs for the future.

MANAGING AND MAINTAINING THE MESSAGING SYSTEM

Windows Management Instrumentation Windows Management Instrumentation (WMI) lets you monitor, track, and control system events that are related to software applications, hardware components, and networks. Exchange Server 2007 provides many WMI classes that you can use to monitor and analyze Exchange servers, track messages, and check mail flow status. Simple Network Management Protocol Simple Network Management Protocol (SNMP) lets you capture configuration and status information about your network and send the information to a designated computer for event monitoring.

Weekly Tasks As a best practice, perform the following tasks and procedures weekly: ◆ Archive Event Logs. This is especially important for security logs, which may be required when investigating attempted security breaches. ◆ Check for Security Updates (you should use WSUS or SMS to automate patch deployment). ◆ Review SLA performance figures. Check the key performance data for the previous week. Review performance against the requirements of the SLA. Identify trends and items that have not met their targets. ◆ Check that public folder replication is up to date. ◆ Archive data to CD, DVD, tape, or similar media.

Monthly Tasks As a best practice, perform the following tasks and procedures monthly: ◆ Security checks: Depending on the level of security that your organization requires, you might need to do regular audits of security, including firewall rules, user rights, group membership, delegate rights, and so on. ◆ Capacity planning: Review capacity figures for the previous month, and produce a plan for any upgrades that may be required in the coming months to keep the system operating within limits specified by the organization’s service level agreements (SLAs). ◆ Disaster recovery test: Perform a system recovery for a single server to test your organization’s documented recovery process. You should simulate a complete hardware failure for one server, and make sure that the resources, plans, and data are available for recovery. Ideally you should rotate the testing to test the failure and recovery of a different server or other piece of equipment every time. ◆ Test restores: Perform test restores from disk/tape to validate backups and document restore times.

Tasks to Do ‘‘As Needed’’ Perform the following tasks as necessary: ◆ Perform mailbox housekeeping for new and departing users, such as show in Figure 11.12. New users will need a user account, a mailbox, certain rights, and group memberships.

343

344

CHAPTER 11 TWEAKING THE INFRASTRUCTURE

I suggest also ensuring that they receive an email copy of the organization’s IT and security procedures, and so on. Departing users should have access to their mailbox and other systems revoked (often urgently). You will need a policy to define what should be done with email destined for the user (for example, should it be rerouted or rejected). You will also need a procedure to explain what happens to a user’s Exchange data after they leave the organization.

Figure 11.12 Creating a new mailbox

◆ Create public folders. A procedure should define who can make requests and what permissions should be applied to different levels of public folders. ◆ Recover mailboxes. Sooner or later someone is going to need their mailbox recovered from the deleted mailbox retention dumpster or from a database backup by using a recovery storage group. Make sure that you have a mailbox recovery procedure in place and documented. ◆ You should perform a full security audit regularly or in response to an upgrade or redesign of the messaging system, or in response to an attempted (or successful) security breach. The procedure may involve port scans on servers and firewalls, audits of security fixes, and third-party penetration tests. ◆ Update performance baselines after an upgrade or configuration change. You can use baselines to measure performance changes and to detect problems that affect system performance.

MANAGING AND MAINTAINING THE MESSAGING SYSTEM

◆ Exchange databases should be brought offline on a quarterly or, at most, semiannually for offline maintenance. Eseutil.exe can be used to defragment Exchange databases. You can resolve inconsistencies in Exchange databases by verifying the integrity of and repairing the database with the Information Store Integrity Checker (Isinteg.exe), as discussed earlier in this chapter. ◆ Monitor the mail queue to determine whether there is a problem with email delivery. You normally initiate this procedure in response to a call from a user.

Monitoring Continuous Replication Exchange Server 2007 Service Pack 1 (SP1) introduces new and improved capabilities for monitoring continuous replication environments to the Get-StorageGroupCopyStatus cmdlet, added the new cmdlet, Test-ReplicationHealth, and provides greater visibility into the loss window covered by the transport dumpster. In addition to using these cmdlets to monitor the health of continuous replication, you can also use several performance counters that are published by the Microsoft Exchange Replication service. The new Test-ReplicationHealth cmdlet is designed to run locally on a Mailbox server to check the status of replication in a local continuous replication (LCR), cluster continuous replication (CCR), and standby continuous replication (SCR) environment. The Test-ReplicationHealth cmdlet is also designed to be tightly integrated with the Microsoft Operations Manager (MOM) Management Pack to provide simple, accurate information detailing the health of continuous replication for the Mailbox server. The checks, described in Table 11.3, are done in order of seriousness; more critical tests are checked first. If one of these checks fails, it is assumed that the less critical tests would fail as well or are not relevant.

Table 11.3:

Tests Performed by the Test-ReplicationHealth Cmdlet

Test

Description

Passive node status (PassiveNodeUp)

Verifies that the passive node has a status of Up when used in a CCR environment.

Cluster network status (ClusterNetwork)

Verifies that all cluster-managed networks found on the local node are running.

Quorum group state (QuorumGroup)

Verifies that the cluster group containing the quorum resource is healthy.

File share quorum state (FileShareQuorum)

Verifies that the value of the FileSharePath used by the Majority Node Set quorum with file share witness is reachable.

Clustered mailbox server group state (CmsGroup)

Verifies that the clustered mailbox server is healthy by confirming that all resources in the group are online.

Node state (NodePaused)

Verifies that neither of the nodes in the cluster is in a paused state.

DNS registration status (DnsRegistrationStatus)

Verifies that all cluster-managed network interfaces that have Require DNS registration to succeed set have passed Domain Name System (DNS) registration.

(CONTINUED)

345

346

CHAPTER 11 TWEAKING THE INFRASTRUCTURE

Table 11.3:

Tests Performed by the Test-ReplicationHealth Cmdlet (CONTINUED)

Test

Description

Replication service status (ReplayService)

Verifies that the Microsoft Exchange Replication service on the local node is healthy.

Databases mounted after failover (DBMountedFailover)

Checks to see whether any databases are dismounted or failed after a failover has occurred. This test only checks for databases that have failed as a result of a failover.

Storage group copy suspended (SGCopySuspended)

Checks to see whether continuous replication has been suspended for any storage groups on the clustered mailbox server.

Storage group copy failed (SGCopyFailed)

Checks to see whether any storage group copies exist that are in a Failed state.

Storage group initializing (SGInitializing)

Checks to see whether any storage groups are in the Initializing state.

Storage group copy queue length (SGCopyQueueLength)

Checks to see whether any storage group has a replication copy queue length greater than best practice thresholds. Currently, these thresholds are: Warning Queue length, 3–5 log files. Failure Queue length, 6 or more log files.

Storage group replay queue length (SGReplayQueueLength)

Checks to see whether any storage group has a replication replay queue length greater than best practice thresholds. Currently, these thresholds are: Warning Queue length, 30–59 log files. Failure Queue length, 60 or more log files.

I’ll discuss the various performance measures performance counters published by the Microsoft Exchange Replication Service later in the Performance Section of this chapter.

Note A set of checklists for these and other tasks can be found in Appendix D.

Improving Performance As you should already know, most performance related problems will likely arise with problems relating to the computer on which you have installed Exchange Server 2007. Windows performance alerting provides a fully automated method for monitoring server performance and reporting when certain performance thresholds are reached. You can use performance alerting to track the following: ◆ Memory usage ◆ CPU utilization ◆ Disk usage ◆ Messaging components

IMPROVING PERFORMANCE

Tracking Memory Usage Physical and virtual memory is critical to normal system operation. When a server runs low on memory, system performance can suffer, and message processing can grind to a halt. To counter this problem, you should configure performance alerting to watch memory usage. You can then increase the amount of virtual memory available on the server or add additional RAM as needed. You configure a memory alert by completing the following steps:

1. In Exchange Management Console, click the Toolbox node, and then double-click Performance Monitor. This opens the Exchange Server System Monitor.

2. Expand the Performance Logs and Alerts node, and then select Alerts. You should see a list of current alerts (if any) in the right pane. A green alert symbol next to the alert name indicates alerting is active. A red alert symbol indicates alerting is stopped.

3. Right-click Alerts in the left pane, and then choose New Alert Settings. 4. In the New Alert Settings dialog box, type a name for the alert, such as Memory Usage Alert. Then click OK to display a Properties dialog box for your new alert.

5. On the General tab, type an optional description of the alert. Then click Add to display the Add Counters dialog box.

6. Use the Select Counters From Computer list to select the Exchange server for which you are configuring alerting.

7. Because you are configuring memory alerts, select Memory from the Performance Object list. Select Available Mbytes, and then click Add.

347

348

CHAPTER 11 TWEAKING THE INFRASTRUCTURE

8. Select Paging File from the Performance Object list. Click %Usage, and then click Add. 9. Click Close. In the Properties dialog box, select Available Mbytes. Set the Alert When Value Is list to Under, and then enter a Limit value that is approximately 5 percent of the total physical memory (RAM) on the server for which you are configuring alerting. For example, if the server has 2 GB of RAM, you would set the value to 100 MB to alert you when the server is running low on available memory.

10. In the Counters list, select %Usage. Set the Alert When Value Is list to Over, and then type 98 as the Limit value. This ensures that you are alerted when more than 98 percent of the paging file is being used.

11. In the Sample Data Every field, type a sample interval, and select a time unit in seconds, minutes, hours, or days. The sample interval specifies when new data is collected. Don’t sample too frequently, however; you’ll use system resources and might cause the server to seem unresponsive. A good value may be once every 10 minutes.

12. In the Run As field, type the name of the account under which the counter log will run, and then click Set Password. After you type the password for the account and then confirm it, click OK to close the Set Password dialog box. To run alert logging under the default system account, type .

13. On the Action tab, you can now specify any of the following actions to occur when an alert is triggered: ◆

Log An Entry In The Application Event Log: Creates log entries for alerts

◆

Send A Network Message To: Sends a network message to the computer specified

◆

Start Performance Data Log: Sets a counter log to start when an alert occurs

◆

Run This Program: Sets the complete file path of a program or batch file script to run when the alert occurs

14. When you click OK, alerting will start immediately. To manage an alert, right-click its entry in the right pane, and then select one of the following options: ◆ Delete deletes the alert. ◆ Properties displays the alert Properties dialog box. ◆ Start activates alerting. ◆ Stop halts alerting.

Tracking CPU Utilization You can use a CPU utilization alert to track the usage of a server’s CPUs. When CPU utilization is too high, Exchange Server can’t effectively process messages or manage other critical functions. As a result, performance can suffer greatly. CPU utilization at 100 percent for an extended period of time can be an indicator of serious problems on a server. Typically, you’ll need to reboot a server when the CPU utilization is stuck at maximum utilization (100 percent).

IMPROVING PERFORMANCE

You’ll also want to closely track process threads that are waiting to execute. A relatively high number of waiting threads can be an indicator that a server’s processors need to be upgraded. You configure a CPU utilization alert by completing the following steps:

1. Right-click Alerts in the left pane of the Performance console, and then choose New Alert Settings.

2. In the New Alert Settings dialog box, type a name for the alert, such as CPU Utilization Alert. Then click OK to display a Properties dialog box.

3. On the General tab, type an optional description of the alert. Then click Add to display the Add Counters dialog box.

4. Use the Select Counters From Computer list to select the Exchange server for which you are configuring alerting.

5. Because you are configuring CPU alerts, select Processor from the Performance Object list. Select %Processor Time, and then click Add.

6. Select System from the Performance Object list. Click Processor Queue Length, and then click Add.

7. Click Close. In the Properties dialog box, select %Processor Time. Set the Alert When Value Is list to Over, and then type 98 as the limit value. This ensures that you are alerted when processor utilization is more than 98 percent.

8. In the Counters list, select Processor Queue Length. Set the Alert When Value Is list to Over, and then type 10 as the limit value. This ensures that you are alerted when more than 10 process threads are waiting to execute, which can be an indicator that a server’s processors need to be upgraded.

9. Follow steps 11–14 under ‘‘Tracking Memory Usage.’’

Tracking Disk Usage When hard disks run out of space, the Exchange server malfunctions and data gets lost. To prevent serious problems, you should monitor free disk space closely on all drives used by Exchange Server. You’ll also want to track closely the number of system requests that are waiting for disk access. A relatively high value for a particular disk can affect server performance and is also a good indicator that a disk is being over utilized. To resolve this problem, you will want to try to shift part of the disk’s workload to other disks. You configure disk usage alerting by completing the following steps:

1. Right-click Alerts in the left pane of the Performance console, and then choose New Alert Settings.

2. In the New Alert Settings dialog box, type a name for the alert, such as Disk Usage Alert. Then click OK to display a Properties dialog box.

3. On the General tab, type an optional description of the alert. Then click Add to display the Add Counters dialog box.

349

350

CHAPTER 11 TWEAKING THE INFRASTRUCTURE

4. Use the Select Counters From Computer list to select the Exchange server for which you are configuring alerting.

5. Select LogicalDisk from the Performance Object list. Select %Free Space. Under Select Instances From List, select all individual logical disk instances except Total, and then click Add.

6. Select PhysicalDisk from the Performance Object list. Select Current Disk Queue Length. Under Select Instances From List, select all individual physical disk instances except Total, and then click Add.

7. Click Close. 8. In the Properties dialog box, select %Free Space for the first logical disk instance. Set the Alert When Value Is list to Under, and then type 5 as the Limit value. This ensures that you are alerted when available free space is less than 5 percent. Repeat this procedure for each logical disk.

9. In the Counters list, select Current Disk Queue Length for the first physical disk instance. Set the Alert When Value Is list to Over, and then type 2 as the Limit value. This ensures that you are alerted when more than two system requests are waiting for disk access.

10. Follow steps 11–14 under ‘‘Tracking Memory Usage.’’ Tracking Exchange Components You can use a similar procedure to set up tracking and alerts for any of the 1400+ Exchange Server 2007 specific counters that you have an interest in. Which ones you select depend on your needs and particular problems.

Troubleshooting Methodology What’s troubleshooting all about? Put simply, it’s identifying that there is a problem and fixing that problem. In other words ‘‘shooting the trouble’’ out of the system. You probably do troubleshooting all day and never realize it. For instance, let’s say you sit down in the evening to read a book. You reach up, turn the switch and get no light. What do you do? Give up reading? Call the electric company? If you’re like most people, you’ll at least give some thought to what might be causing the trouble before you do anything. That’s troubleshooting. Knowing what to do when faced with a problem and effectively resolve it requires a combination of planning, strategy, and knowledge. Without a clear strategy, defined methodology and plan your troubleshooting efforts will cost you countless hours of work, frustration and lost productivity. While Exchange Server 2007 provides a comprehensive set of troubleshooting tools for diagnosing and resolving hardware and software problems, using these tools effectively requires an understanding of basic troubleshooting concepts and strategies. It also requires some learning. To know why something isn’t working, you must understand how it works when everything is functioning as it should. The rest of this book will be devoted to providing you that information and will be trying to explain, at a basic level at least, how most things work inside Exchange Server 2007. That knowledge, combined with the skills you probably already have for identifying the problem and its symptoms, should be enough to give you a starting point for guessing the causes of a problem.

TROUBLESHOOTING METHODOLOGY

When a problem occurs while running Exchange Server 2007, and you can be sure that it will, you can use the general troubleshooting methods and tools provided with the operating system to isolate and fix it; they cover a wide range of problems. You will also have a better understanding of how to approach a problem when confronted by a frantic client whose computer doesn’t work. By approaching the problem methodically, you can both calm the user down and show that you recognize that their concerns and their data are as important to you as it is to them.

Developing a Troubleshooting Methodology Anytime a computer is disabled someone has lost productivity, either in their private or professional lives. The job of desktop support personnel is to keep the downtime to a minimum and to get the system back to the client. One of the best ways to get a computer system running quickly is to have a troubleshooting strategy to assess the situation and make the necessary adjustments or repairs. Whether an issue stems from a physical, hardware or a software problem, you need a reliable troubleshooting plan. Guesswork and random solutions are unreliable and often unsuccessful. As discussed above, an effective troubleshooting plan starts with gathering information, observing symptoms, and doing research based on the user’s input, but then what? Figure 11.13 shows the Microsoft-developed six-step troubleshooting model, called the ‘‘detect model’’ that should regularly be employed when approaching any system or application problem.

Figure 11.13 Troubleshooting model

Discover the Problem

Evaluate System Configuration Track Possible Solutions

Execute a Plan No

Yes

Check Results Does it work?

Take a Proactive Approach

Based on research in problem solving, these are the six steps of this troubleshooting model:

1. Discover the problem. Identify and document problem symptoms, and search technical information resources to determine whether the problem is a known condition.

2. Evaluate system configuration. Review your system’s history to determine what configuration changes occurred since the computer last worked correctly. Did you install new hardware or software? Did you verify that the hardware or software is fully compatible with Exchange Server 2007?

351

352

CHAPTER 11 TWEAKING THE INFRASTRUCTURE

3. Track possible solutions. Instead of using the trial-and-error approach, review Microsoft Knowledge Base articles. You can simplify troubleshooting by temporarily removing hardware and software that is not needed for starting Exchange Server 2007. Consider enabling logging options to better evaluate your troubleshooting efforts.

4. Execute a plan. Test potential solutions and have a contingency plan if these solutions do not work or have a negative impact on the computer. Be sure to back up critical system or application files.

5. Check results. Determine whether your plan was successful. Have another plan in place to address unresolved issues.

6. Take a proactive approach. Document changes that you make along the way while troubleshooting the problem. After resolving the problem, organize your notes and evaluate your experience. Think about ways to avoid or reduce the impact of the problem in the future.

Discover the Problem The immediate goal of any troubleshooting session is to restore service as quickly as possible. However, the larger goal is to determine the cause of the problem. Root-cause analysis is the practice of searching for the source of problems to prevent them from recurring. The most effective way to solve a problem is to gather information before acting, and then isolate and eliminate variables. Let me repeat that. The best way to start troubleshooting is by gathering information. Typically, the user doesn’t really have the knowledge to adequately describe the problem or may only be telling you only part of the problem. ‘‘It doesn’t work.’’ ‘‘It’s blinking at me.’’ Typically, the client is more concerned with the data they have lost then a description of the nature of the problem. Also, many users do not understand mail flow so any message that cannot be delivered will be deemed a system problem. The first step should be to develop a clear understanding of the symptoms and collect pertinent system information to understand the environment in which they occur. What was the user expecting to occur? Precisely what is not working correctly? Under what conditions does the problem occur? Is the problem specific to an application, or is it specific to a system (for example, networks, video, and so on). This is important, because once you have a good idea what the problem is you can begin the process of solving it. Typically, when you start troubleshooting a malfunctioning system, the first thing you should consider is PHO. ‘‘P’’ stands for physical, ‘‘H’’ for hardware and ‘‘O’’ for operating system — the initial troubleshooting hierarchy. PHO simply means that you should check all of the physical issues first, the hardware issues second, and the operating system issues last. The biggest reason to use this strategy is that it also follows the most generic to the most complex troubleshooting strategy recommended by most professionals in the information technology field.

Identify Problem Symptoms As has already been said, it all starts with observing and identifying symptoms of the problem. You cannot begin to solve the problem until you have learned as much as you can about the circumstances in which problems occur and become familiar with system behavior when issues arise. Here are some questions that you can use to help identify symptoms: Do error messages appear? If so, record the error numbers, the exact message text, and a brief description of the activity. This information is useful when researching the cause of the

TROUBLESHOOTING METHODOLOGY

problem or when consulting with technical support. In your description, include events that precede or follow a problem and the time and date of the error. Did you check Event Viewer logs? Entries in the Event Viewer application, security, and system logs might contain information helpful for determining the cause of the problem. Look for symptoms or signs of problems that occur at frequent or regular intervals. Did you check log files on the computer? Error messages sometimes direct you to view a log file on your computer. The operating system or an application typically saves log files in text format. By using Notepad or an equivalent text editor, you can view the contents of a text log file to determine whether it contains information useful for troubleshooting your problem. Exchange Server 2007 has a number of logs files on various servers; that is, protocol logs, SMTP send/receive logs, IIS Logs and message tracking logs. Message tracking can be your friend to prove a message is leaving the mail system or provide delivery information. In fact, I heavily depend on these logs. Does the problem coincide with an application or activity? If the problem occurs when an application is running or during activities such as network printing or Internet browsing, you can reproduce the error to observe details and gather information for troubleshooting purposes. Be sure to record what applications and features are being used when the problem occurs. Do previous records exist? Check to see whether there are records that describe changes, such as the software installed or hardware upgraded. If records are not available, you might query users or other support technicians. Pay special attention to recent changes such as service packs applied, device drivers installed, and motherboard or peripheral firmware versions. Is baseline information available? Baseline information is system configuration and performance data taken at various times to mark hardware and software changes. If possible, compare current baselines with previous ones to determine the effects of recent changes on system performance. If previous baselines are not available, you can generate a baseline to evaluate recent efforts to troubleshoot your current system configuration. Does the problem seem related to user profiles? Do other users who log on to the same computer have similar problems? Are all users who do not experience problems using Administrator accounts or do they share other common attributes? For example, check if the problem occurs when using a newly created user account. Does the problem seem network-related? Determine whether the same error occurs on more than one computer on a network. See whether the error happens when you log on locally or use a domain account. Utilities such as DCDiag and NetDiag are useful tools to diagnose network-related problems. Is incompatible or untested software installed? Are you using unsigned or beta drivers? Installing software not fully tested for compatibility with the operating system or application or using unsigned drivers can cause erratic behavior or instability. Do you have backups to examine? If you can establish a time frame for the problem, try to locate earlier system backups. Examining the differences between current and previous configurations can help you identify system components or settings that have changed. In addition to examining backups, you can use the System Restore tool to save or restore system states. By comparing the current state to past states, you might be able to determine when the changes occurred and identify the components or settings affected.

353

354

CHAPTER 11 TWEAKING THE INFRASTRUCTURE

Once you have identified the problem and adequately described it you should search technical information resources, such as the Microsoft Knowledge Base articles, to determine whether the problem is a known condition.

Review Your System’s History Review the history of your computer to know about recent changes, including all hardware and software installed. If baseline or change records exist, look for information about new devices, new applications, updated drivers, and change dates — as well as descriptions of the work done. If records are not available, you can query users and internal support personnel or use tools such as Device Manager and System Information (MSInfo32). Here are a few points to consider when reviewing the history of your computer: ◆ Did problems occur shortly after the installation of a particular application? ◆ Was a ‘‘hot fix’’ applied? Microsoft technical support might provide a hot fix for an urgent or critical issue. Hot fixes address a specific issue and might not be fully tested for compatibility. For example, a hot fix that works for one computer might cause unwanted results in another. Carefully read and follow the instructions before applying a hot fix. ◆ Did the problem occur soon after new hardware was installed? ◆ Why were hardware or software updates made? Are the motherboard and peripheral firmware current? Can you establish a relationship between the problem and the recent change? ◆ When was the last virus check performed? Does the virus-scanning software incorporate the latest virus signature updates? For more information about virus signature versions and updates, see the documentation provided with your antivirus software. ◆ If a service pack is installed, is it the latest version? Compare System Settings and Configuration With Baselines If similar computers in your organization are problem free when you are troubleshooting a problem, the properly functioning system can provide valuable baseline data. By comparing the following elements, you can speed up the process of identifying contributing causes. ◆ Installed services and applications ◆ Software revisions ◆ System logs ◆ Hardware revisions Check Firmware Versions When you turn on or cycle power to a computer, the central processing unit (CPU) begins to carry out programming instructions, or code, contained in the motherboard system firmware. Firmware contains operating system independent code necessary for the operating system to perform low-level functions such as startup self-tests and the initialization of devices required to start Windows. If instability or setup problems affect only a few Windows 2003/2008–based computers in your organization, check the motherboard and peripheral firmware. ◆ Motherboard firmware revisions: Compare the BIOS or Extensible Firmware Interface (EFI) versions on the problem and problem-free systems. If the versions differ, check the

TROUBLESHOOTING METHODOLOGY

computer manufacturer’s website for the latest firmware revisions. For example, if your firmware revision A was stable, but upgrading to firmware revision B causes problems, you might find firmware revision C on the website. If no revision C exists, temporarily downgrade to revision A until an update becomes available. ◆ Peripheral firmware revisions: It might be necessary to check peripheral firmware revisions and upgrade firmware for individual peripherals, such as small computer system interface (SCSI) adapters, CD and DVD-ROM drives, hard disks, video cards, and audio devices. ◆ Original equipment manufacturers (OEMs) periodically incorporate updated firmware into existing products to address customers’ issues or to add new features. Sometimes similar computers using the same hardware components have different motherboard and peripheral firmware versions. Upgrading firmware on older devices might require you to replace components (such as electronic chips) or exchange the part for a newer version. To avoid firmware problems, be sure to check the firmware (BIOS or EFI) revision your computer uses.

Tracking Possible Solutions After you observe symptoms, check technical information sources, and review your system’s history, you might be ready to test a possible solution based on the information that you have gathered. If you are unable to locate information that applies to your problem or find more than one solution that applies, try to further isolate your problem by grouping observations into different categories such as software-related symptoms (due to a service or application), hardware-related symptoms (by hardware types), and error messages. Prioritize your list by frequency of occurrence and eliminate symptoms that you can attribute to user error. This enables you to methodically plan the diagnostic steps to take, or to select the next solution to try. This material will be dealt with in detail throughout the book, but the below provides a useful summary. Isolate and resolve hardware problems. When troubleshooting hardware, start with and work toward the simplest configuration possible by disabling or removing devices. Then incrementally increase or decrease complexity until you isolate the problem device. In safe mode, Windows 2003 starts with only essential drivers and is useful for diagnosing problems. If your diagnostic efforts point to a hardware problem, you can run diagnostic software available from the manufacturer. These programs run self-tests that confirm if a piece of hardware has malfunctioned or failed and needs replacing. You can also install the device on different computers to verify that the problem is not due to system-specific configuration issues. If diagnostic software shows that the hardware is working, consider upgrading or rolling back device drivers. Isolate and resolve software issues. If you suspect that a software problem or a recent change to system settings is preventing applications or services from functioning properly, use safe mode to help diagnose the problem. You can also use the Last Known Good Configuration startup option or System Restore to undo changes made by a recently installed application, driver, or service.

Executing a Plan and Checking Results Ideally you should test potential solutions and have a contingency plan if these solutions do not work or have a negative impact on the computer. Before implementing a solution it is worth taking a deep breath and reviewing your course of action. You can complicate a problem or troubleshooting process unnecessarily by acting too quickly. Avoid the following common pitfalls that can hinder your efforts:

355

356

CHAPTER 11 TWEAKING THE INFRASTRUCTURE

Not describing the problem adequately If you fail to make essential observations about a problem before responding to it, you can miss important information in the critical moments when symptoms first appear. Here are some typical scenarios: ◆ Failing to record information before acting ◆ Restarting the computer too soon ◆ Failing to check for scheduled maintenance events or known service outages ◆ Assuming that past solutions always work ◆ Neglecting to check the basics Other common pitfalls

These are some other common pitfalls:

◆ Not observing the effects of diagnostic changes ◆ Not documenting changes while troubleshooting ◆ Not adequately backing-up or preparing a return point ◆ Not restoring a previous settings before trying something else ◆ Troubleshooting several problems at one time ◆ Using incompatible or untested hardware ◆ Failing to adequately test new and replacement parts ◆ Using incompatible software Even if you are 100 percent confident that you know the cause of the problem you need to take steps to safeguard the data and the applications. One of the key things you should do, before doing anything that has the potential to harm the computer or the files on it, is to back up critical system or application files. Another way of protecting the data is to create a System Restore Point using the System Restore tool. A Restore Point, ideally, is a point at which your computer starts and runs without any errors or problems. Now — implement the solution and check the results. If everything works then congratulations on successfully troubleshooting the problem your supported user has encountered in Exchange Server 2007. If it did not solve the problem, or made things worse, don’t despair. Implement your contingency plan, restore the system to its previous state if necessary and reevaluate it. If you already have another plan in place to address unresolved issues, implement it.

Taking a Proactive Approach After you have gone through all the time and effort to effectively troubleshoot a problem, you will no doubt feel an understandable and deserved sense of pride. Success can be addicting. What you also want to do as well is to make sure that all of that effort does not go to waste or have to be redone. After you have successfully finished troubleshooting a new problem, the first thing you should to do is a ‘‘debriefing’’ of what you did.

TROUBLESHOOTING METHODOLOGY

Always make sure that you have documented the problem itself as well as the changes and the steps that you took along the way while troubleshooting the problem. After resolving the problem, organize your notes and evaluate your experience. What lessons have you learned and are there ways to avoid or reduce the impact of the problem in the future?

Document and Evaluate the Results You can increase the value of information collected during troubleshooting by keeping accurate and thorough records of all work done. You can use your records to reduce redundant effort and to avoid future problems by taking preventive action. Create a configuration management database to record the history of changes, such as installed software and hardware, updated drivers, replaced hardware, and altered system settings. Periodically verify, update, and back up this data to prevent permanent loss. To maximize use of your database, note details such as: ◆ Changes made ◆ Times and dates of changes ◆ Reasons for the changes ◆ Users who made the changes ◆ Positive and negative effects the changes had on system stability or performance ◆ Information provided by technical support Update baseline information after installing new hardware or software to compare past and current behavior or performance levels. Baselines combined with records kept over time enable you to organize experience gained, evaluate maintenance efforts, and judge troubleshooting effectiveness. Analysis of this data can form the basis of a troubleshooting manual or lead to changes in control policy for your organization. A post-troubleshooting review, or postmortem, can help you pinpoint troubleshooting areas that need improvement. Some questions you might consider during this self-evaluation period include: ◆ What changes improved the situation? ◆ What changes made the problem worse? ◆ Was system performance restored to expected levels? ◆ What work was redundant or unnecessary? ◆ How effectively were technical support resources used? ◆ What other tools or information not used might have helped? ◆ What unresolved issues require further root-cause analysis?

Write an Action Plan An action plan is a set of relevant troubleshooting objectives and strategies that fits within your organization’s configuration and management strategies. After you identify the problem and find a potential solution or workaround that you have tested on one or more computers, you might

357

358

CHAPTER 11 TWEAKING THE INFRASTRUCTURE

need an action plan if the solution is to be deployed across your organization, possibly involving hundreds or thousands of computers. Coordinate your plan with supervisors and staff members in the affected areas to keep them informed well in advance and to verify that the schedule does not conflict with important activity. Include provisions for troubleshooting during nonpeak work hours or dividing work into stages over a period of several days. Evaluate your plan, and as you uncover weaknesses, update it to increase its effectiveness and efficiency.

Take Proactive Measures You can combine information gathered while troubleshooting major and chronic problems to create a proactive plan to prevent or minimize problems for the long term. When planning a maintenance or upgrade process for your organization, consider the following goals: ◆ Improving the computing environment ◆ Monitoring system and application logs ◆ Documenting hardware and software changes ◆ Anticipating hardware and software updates Improve the computing environment. Some basic precautions include labeling connecting cables, periodically testing uninterruptible power supply (UPS) batteries, and placing computers far from high-traffic areas where they might be bumped or damaged. Check environmental factors such as room temperature, humidity, and air circulation to prevent failures due to excessive heat or dust. Install surge suppressors, dedicated power sources, and backup power devices to protect equipment from electrical current fluctuations, surges, and spikes that can cause data loss or damage equipment. Perform regular file and system state backups to prevent data loss. Use virus-scanning software and regularly download the latest virus signature updates. Monitor system and application logs. Monitor your system to detect problems early and avoid having software or hardware failure be your first or only warning of a problem. When using a monitoring tool to evaluate changes that might affect performance, compare baseline information to current performance to isolate and assess bottlenecks. You can also use the data to justify acquiring additional CPUs, more RAM, and increased storage space. Event Viewer can help you to identify chronic problems and detect potential failures. Document changes to hardware and software. Record not only computer-specific changes but also other factors that can impact computer operation such as Group Policy and network infrastructure changes. Plan for hardware and software upgrades. Regardless of how advanced your system hardware or software is, all computer technologies have a limited lifespan. Develop a maintenance plan that takes into account: ◆ Increased demand for computing resources ◆ Discontinued support for a device or software ◆ Upgrading operating systems or installing application patches, hot fixes, and operating system service packs ◆ Scheduling training time to stay current with new developments and product updates

SUMMARY

Summary Whew! We’ve reached the end, both of the chapter and of the project you started working on back in Chapter 1. In this chapter, you’ve read about some of the technical, Exchange Server 2007–specific tasks that you need to perform simultaneously or shortly after your deployment. You’ve learned about the many support tools provided for Exchange Server 2007 and when and where to use them. You’ve seen best practices for disaster recovery and learned about configuring your messaging system for high availability using continuous replication. In this chapter, we’ve also covered the basics of monitoring and performance — topics that could warrant their own book this size. You also learned about effective troubleshooting methodologies. Exchange Server 2007 is complex, and you need to be have a solid understanding of how to approach problems and their resolution In the next and final chapter, we’ll talk about how you can leverage the skills and techniques you’ve learned to take on consulting positions. It really doesn’t make a difference if that consulting is done as a freelance self-employed ‘‘expert’’ or as your organization’s ‘‘go-to guy.’’ The skills you’ve obtained and demonstrated can ensure you a valuable role in future projects.

359

Chapter 12

So, You Want to Be a Consultant? A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects. — Robert A. Heinlein A number of the techniques and skills you have applied in developing the Exchange Server 2007–based messaging system described in this book are not limited to Exchange Server alone. You can apply many of them, such as assessing business needs, writing plans, and making a business proposal, to any of a number of other software projects. E-communication systems are going to be a growth market for a number of years to come as the technology and users mature. You’ve also developed considerable project management skills that will serve you in good stead. So, what should you do with these new skills? What are your options? A lot depends on your circumstances and personal preferences. For some people being put in charge of a project like this is simply part of their day-to-day duties in a large organization. The successful deployment of the project may lead to a pay raise or bonus and perhaps a promotion. However, your new skills are moth-balled. If you work for a particularly visionary company, you may be assigned to another project that calls upon some of those skills. It is even possible that you may head up a team (or work solo initially) to get ready for the next iteration of Exchange Server, be it another version or a simply a major service pack such as Exchange Server 2007 Service Pack 1. You may be satisfied with this. Or if you are the restless sort or simply like to look at other opportunities, you may not like the idea of not going any further. One answer to the question ‘‘What are my options?’’ is to become a consultant. After more than three decades of IT experience, I have discovered that for some people being a consultant is the ‘‘holy grail’’ for which they went into an IT career; for others, it’s the most frightening idea imaginable. Given your skillset — whether newly acquired or not — a career as a consultant is something to consider. So, in this chapter, I’ll discuss some of the realities of being a consultant and help you decide whether this is the life for you. If you’re already working as a consultant, much of this chapter may seem ‘‘old hat’’ to you. However, even ‘‘old hands’’ know that there is always something to learn.

Understanding Consulting A consultant is someone who provides unique assistance or advice to someone else. In the IT world, a consultant is usually someone hired on an ad hoc basis to set up or establish a particular activity. Because of the increasing complexity of IT systems, consultants are usually valued

362

CHAPTER 12 SO, YOU WANT TO BE A CONSULTANT?

for their specialized skillsets and knowledge of the system of interest. Right now you are almost certainly your organization’s leading expert on setting up an Exchange Server 2007–based messaging system. This expertise makes you an excellent consultant for another organization trying to set up an Exchange Server 2007–based messaging system.

What Does a Consultant Do? A consultant’s work is typically defined by three factors: expertise, structure, and process. Expertise is what the consultant knows and has experience with. Expertise can run the gamut from pig farmer to SAP R/3 to garnet miner. William Solo, in his 1997 book, provided a list of 296 specialty consulting fields. Rest assured that Exchange Server 2007 was not on that list and that the list has grown considerably. Structure refers to the way a consultant works. A consultant can function as the following: ◆ Employee of a large consulting firm ◆ Employee of a small or medium consulting firm ◆ Partnership ◆ Virtual organization ◆ Subcontractor to the above ◆ Internal/staff consultant ◆ Freelance, independent consultant This list is by no means exhaustive, and a consultant may actually work in different structures at different times. The final aspect of what consultants do is what part of the process they’re involved in. The principal role of consultants is to assist in one or more of the steps of problem solving: ◆ Identify the problem. Why isn’t our messaging system effective? ◆ Identify the cause. What is causing limited business? Why are our salespeople always out of contact? ◆ Identify the solution. What’s the best messaging system for our business? ◆ Implement the solution. How do we set up an Exchange Server 2007–based messaging system? How do we migrate from earlier versions?

Why Become a Consultant? There is no single answer to this question. People become consultants for reasons as varied as you can imagine. In the final analysis, though, good consultants became consultants and were successful for the following reasons: ◆ They liked what they did so that the long hours and uncertainty didn’t bother them. ◆ They wanted more control over what they did for a living. ◆ They saw an opportunity. ◆ Their personality demanded it.

UNDERSTANDING CONSULTING

I think the latter one is the real key to success to being a consultant or to being good at any endeavor. If there is something you like to do and it is suited to your personality, it is compelling and your personality simply demands that you do it and often won’t let you rest till you do. For example, I have been writing professionally for 20 years and academically for several additional years before that. As a writer I found that I simply could not ‘‘stop’’ the urge. The more I wrote, the better I became at it. It was fun, so I did it more and more. At times, I simply hated the mechanics of it, but I couldn’t stop. Dorothy Parker summed it up best for writers (and any other profession) when she said ‘‘I hate to write, but I love having written.’’ If there is something you love or are excited about doing, showing others how to do, or doing for others, then you have found something you’d be a natural consultant for.

What Is the Consultant Personality? Consulting takes a certain aptitude and attitude, that is, the natural talents and personal qualities we possess and that make us who we are. It might be the ability solve a problem methodically or the ability to see a problem as a solution, or to find a solution where no one has ever looked before. The following attributes make up some of the aptitude, natural talents, and personal qualities it takes to be a consultant. Ask yourself how many of these describe you: ◆ Hard worker ◆ Risk taker ◆ Good health ◆ Thick-skinned ◆ Persistence ◆ Detail oriented ◆ ‘‘Big picture’’ oriented ◆ Aware of limitations ◆ Self-starter ◆ Self-promoter ◆ Can say ‘‘no’’ ◆ Self-disciplined ◆ Analytical ◆ Confident ◆ Articulate ◆ Flexible/adaptable ◆ Complete what you start ◆ Trustworthy ◆ Willing to do a good job even you don’t want to do it ◆ Willing to work long hours

363

364

CHAPTER 12 SO, YOU WANT TO BE A CONSULTANT?

◆ Sense of humor ◆ Good self-esteem ◆ Fearless ◆ Active listening skills ◆ Ability to translate abstract ideas and concepts into the concrete ◆ Rapid responsiveness, that is, the ability to act on something quickly, not put it off I’ll add one more item to this list, and that’s intellect. There is probably nothing in your consulting arsenal as powerful as this. The more you are able to quickly use examples, paraphrase, cite historical analogies, recognize weakness in an argument, ask penetrating questions, and so on, the better. These will help you be seen as a peer and an invaluable asset to the client’s business. It’s a win-win situation by the way. Clients with powerful capabilities — in intellect and competency — tend to hire people who they perceive as having the same capabilities — often defined as ability to think. Their businesses tend to be more together and more effective, so they are the types of clients you want. Weak people tend to be afraid of ‘‘powerful’’ people, and as a result they either won’t hire them or, if they do, will inevitably do everything to sabotage their efforts. Consulting is a business, so you want to market yourself to the people who will hire you and let you do your job, as opposed to those who won’t hire you or, if they do, will interfere. There is one other point I’d like to make on this topic. If you have focused only on developing technical expertise and ignored the rest of the universe, it’s time to change that. You must continually broaden your intellectual breadth. You cannot even focus solely on business skills, consulting methodology, and marketing, as well as IT technologies. Consulting is, like most of life, a relationship business; the more skilled you are in a variety of areas, the better your chances of building those relationships.

Calculus and the Kansas City Royals In 1981, a few years before his untimely death at 51, former New York Yankees manager Dick Howser was one of several candidates for the job of managing the Kansas City Royals baseball team. Howser was well respected, but other candidates included such managerial heavyweights as Dick Williams, so he was not considered the favorite, especially because his team had just lost the playoffs to the Royals the year before. To many observers’ surprise Howser was selected by the Royals organization. Not only because of his considerable skill as a manager but also because Royal owner Ewing Kauffman said he was impressed with the fact that Howser had taken calculus in college. The moral of the story is simple — knowing something is never a waste of time.

Understanding IT Consulting If you’re satisfied that you have the right combination of aptitudes, skills, and attitudes, then let’s examine how this translates into the skillsets necessary to be an effective IT consultant.

UNDERSTANDING IT CONSULTING

As a consultant, you are basically selling the services and skills that you possess to someone else. The more you are paid for your time, the more successful you are, financially and professionally. You must remember that the client sees you in a different light. It isn’t all about what you know. They aren’t experts in your field. They really can’t judge you, except by the results — the quality of advice they are receiving from you. They assume, based on the letters after your name and your background and skills, that you presumably know what you’re talking about. Despite this technical background limitation, the client can clearly assess and judge other attributes that you bring to the relationship. Because they lack expertise in the technical aspects, these attributes assume much more weight in their evaluation of you. The first key quality that a client is typically looking for beyond technical skill is the ability to communicate effectively. A consultant who cannot ask the right questions, listen effectively to the response, interpret what is said and develop a dialog based on trust is severely limited in his ability to diagnose the situation and prescribe solutions. The second key aspect is whether or not you have the breadth of knowledge and ability to see the entire gestalt to be of any value. A consultant who doesn’t look at the whole picture — but focuses on the technological issues without considering the business context is in danger of offering a solution that simply won’t work or be accepted. So just as there are certain character traits that make an effective consultant, there are skills and methods that are critical to success. Thankfully, they can be learned, assuming that you want to do so. There are various ways to group these skills, but they inevitably break down into four broad classifications: ◆ Advisory ◆ Technical ◆ Business ◆ Communication Let’s take a brief look at each these skillsets.

Advisory Skills What are you really providing as a consultant? Your technical expertise of course, but that doesn’t really stand alone, and it doesn’t operate in vacuum. When you go to a lawyer and talk to him about a will, you go not just because he can cite the law relating to will creation; you seek his advice on the best way to legally carry out your final wishes and to help you avoid any pitfalls. When a doctor diagnoses you with a disease, you don’t just want to be told its name and treatment, you want advice on what it means and how best to manage it. As an IT consultant, you are also master of a highly specialized body of knowledge. You will, therefore, spend a significant part of your working life explaining complex technical subject matter to clients. These clients will rely on the advice you give them to achieve success in their careers or businesses. Obviously you also have a responsibility to provide complete and correct advice.

Being an Advisor How do you become a good advisor? And is it important? Think back to your own experiences. First you should be well aware from your own experiences with mechanics, dentists, tax advisors,

365

366

CHAPTER 12 SO, YOU WANT TO BE A CONSULTANT?

doctors, lawyers, and other IT consultants that technical expertise alone doesn’t make one a good and trusted advisor — there are good and bad ones. I’m sure you know this scene. You’re sitting in a hospital room in one of those silly gowns that opens in the back, freezing and more than a little nervous. The door swings open, and in walks a doctor staring at a clipboard. She never looks up as she asks you a couple of questions in a bored monotone and checks off some items. Only then does she bother to glance up to see who the subject of her interview is. You’re left wondering if she cared whether you were a man, a woman, or a cow. Then there is the doctor who took the time to get to know you, your preferences and personality, and the way you felt about your medical condition, and the prescribed therapies. Both physicians were competent, so why do you prefer one over the other? Almost certainly the reason was that the ability to give personalized advice influenced your perception of the experience and the ultimate success of the relationship.

Bedside Manner and Malpractice If you think that personal skills as an advisor aren’t important consider this. Studies conducted by the medical profession since the 1990 have consistently showed a correlation between bedside manner and malpractice suits. The evidence is compelling that physicians who have strong relationships with their patients are less likely to get sued, and may be more likely to move up the professional ranks. Physicians who communicate well are less likely to be sued for malpractice than poor communicators, says Dr. Greg Schneider, assistant professor of family practice and community medicine at University of Texas Southwestern Medical School at Dallas. ‘‘There is a clear association between rapport with patients and incidence of lawsuits,’’ Schneider says. In addition, Schneider has observed situations where intuitive physicians who have the ability to connect with patients thrive in a group medical practice, while less personable physicians flounder. How true is it? Consider that beginning with the class of 2005, however, all medical school students — about 16,000 U.S. students per year — are required to take a test of bedside manner as part of the U.S. Medical Licensing Exam. Each student in the country’s 126 medical schools must travel to Chicago, Houston, Los Angeles, Atlanta, or Philadelphia to take the exam in addition to paying the $975 testing fee. As a consultant, you must use some process of interviewing, documenting, analyzing, recommending, and communicating to be an effective advisor. Many professionals have learned this process through trial and error, as it is not typically a subject covered in depth as part of their training and certification. For the skilled practitioner, advising becomes an ingrained and instinctual skill that is rarely thought of as a separate process. For the less skilled, it is a hit-or-miss process that often leaves crucial factors undiscovered, or critical decision criteria poorly understood by the client. Probably one of the most disconcerting sights to see is other ‘‘consulting’’ work that is little more than a collection of unstructured, inconsistent, uncoordinated activities. When that happens both the IT professionals and their clients are often left wondering how a simple technical project could get so fouled up. Everyone understood the technology, but nobody managed the relationship or the delivery process. To help you avoid that ignominious fate, I want to spend some time looking at what it means to be an advisor and not merely a technician. Once you understand and integrate these into

UNDERSTANDING IT CONSULTING

your work they can readily translate into the specific practices that constitute an IT consulting framework. There are five basic concepts, or ‘‘fundamentals,’’ that underpin the IT advisory process: Nurture the relationship. Identify who the client is. Learn about the motivations, culture, history, fears, and goals of both the human being and the organization he or she represents. Success at this task can have more bearing on the success or failure of what you are doing than the technical discipline involved. Clearly define everything, including your role. Make sure that the client knows exactly what you are there to accomplish, what tasks you are making a commitment to perform, what tasks you expect the client to perform, and where the boundaries of the relationship lie. Then do it. Define the criteria for success. Part of your central role is to help the client draw a mental picture of the desired result. Not doing so leads to scope creep, in which nothing concludes because the expectations keep changing. Defining success creates a common goal that all participants can agree upon and strive for together. It becomes an unambiguous and motivational target that clarifies the effort and helps clear away extraneous issues and barriers. Advise, don’t decide. One of the most difficult tasks for a consultant is to cast aside emotional attachment to her own advice and the belief that it was carved in stone on Mount Sinai. Some consultants fall in love with their favored particular solution or technology and then lose interest in, or respect for, the client if he decides to take another approach. Always remember that the client understands the complexities of his own environment much better than you do. Also keep in mind that the client will be living with the outcome of his or decision after you move on to the next job. Be result oriented. Your job is to help your client achieve a goal. While some relationships are strictly informational, most clients don’t rely on you to just recommend solutions; they want you to help implement them. You should consider implementation issues throughout the engagement, such as corporate culture, readiness to change, training requirements, and corporate communication channels, and how you can achieve the desired results.

Nurturing the Relationship Being a consultant doesn’t mean dropping by the client’s facility, peering into corners like a detective, making some profound (and often obvious) pronouncements, and then sending a bill. That’s not consultancy, that’s arrogant pontificating and won’t work more than once or twice. Your success as a consultant will be based on your ability to apply your technical specialty to the client’s unique situation. Without focusing on the human relationship, and developing the trust and confidence that enable the client to reveal his or her problem, this won’t happen If you are wise enough to listen carefully, the client will tell you how to successfully advise him. The client knows his own environment and corporate culture. He knows the history and the personalities that have gotten the organization to the state it’s in, and he probably has an idea of where he wants to end up. He knows his priorities: is it schedule, cost, performance, ease of implementation, lack of disruption, data safety, or personal prestige? Get to know your client, because there will be many points where you’ll need to make a judgment about what your client will prefer, how he will react, and how to present him with problems or alternatives. You also need to be adaptable about what method you use so that it fits the client. Some clients may prefer a blunt, take-no-prisoners approach to the consulting relationship. Others may be extremely sensitive to their team’s reaction to your advice. Some clients or stakeholders may be threatened or distracted by the consulting process. You may need to spend a significant amount

367

368

CHAPTER 12 SO, YOU WANT TO BE A CONSULTANT?

of time educating the client in the consulting process, to set expectations, and to build in the assurance factors. Some clients may be ready to engage fully in the process, prepared to give trust freely and to disclose fully the information required. In those cases, all you might have to do is provide a periodic progress report to ensure that you are on track. For other clients frequent assurances that you are remaining ‘‘on task’’ and producing the expected deliverables may be required. Weekly progress meetings and complete status reports may be necessary to continually reassure these clients that they are getting value for their money. You must be mature enough to understand your clients’ differing needs for assurance and not to interpret their attitude as ‘‘the client breathing down my neck’’ or ‘‘they don’t really give a damn.’’ Spending time nurturing the relationship aspect of advising will help clarify one of the most troublesome aspects of consulting, namely, ‘‘Who is actually my client?’’ IT consultants are frequently engaged by managers to create systems for the departments they lead. Who is the client in these cases — the manager who hired you or the ultimate user of the system? In most cases, the answer is both are your client. The manager’s requirements for schedule, budget, and reporting are driving factors that must be accounted for in the result, yet the user’s need for functionality and convenience must be considered or the system will end up unused. You need to understand who the client is, who determines whether or not the engagement was a success, and who will pay the bill. This means that you will have to keep multiple, and often conflicting, success criteria in mind. Of course, you need to understand who the person is as an individual. Everyone is different. Some are naturally quiet; others will talk your ears off. Some are slow to trust and reticent to reveal. Others will tell you more than you ever wanted to know. Some will act as if you’re an intruder in their private domain, while others will treat you like a long-lost friend. Human diversity is what makes the relationship aspect of consulting so challenging, and ultimately so rewarding. You should work to develop strategies for dealing with both the reluctant and the cooperative client.

Defining Your Role Understanding the role of the client and the consultant is extremely important and avoids confusion and wasted effort. For example, a client may have decided that since you are a paid advisor you are going to be on 24 hour call for any emergencies in your area of expertise. If you’ve been hired to work on a new Exchange Server 2007–based messaging system, does this mean that you’re expected to answer the phone in the middle of the night if someone has a design question? If that is not the expectation, client and consultant had better define that up front. If it is part of the consultant’s role, you need to ensure that the client can get in touch with you when required — and that you’ve negotiated a proper pay scale for that 3:00 A.M. call. Disconnects between what you think you’re supposed to deliver and what the client thinks you’re supposed to do can rapidly sour any relationship. Make sure that you have made everything clear. If the agreement to consult on the selection of new computer equipment means assistance in procuring that gear, make sure that everyone knows what is going to be done. Does it include installation? Is ongoing support included? Many clients assume that recommendation means implementation. ‘‘Why would I want you to recommend something if you’re not going to install it?’’ Implied and unspoken expectations can poison an otherwise healthy relationship. What is the appropriate expectation? That varies between what you’re willing to do and what the client is willing to pay for. It’s the consultant’s role to define that in conjunction with the client. It’s all just not one way. You need to determine the client’s availability to work on the project. It’s obviously going to be very difficult to make recommendations if the client and his

UNDERSTANDING IT CONSULTING

representatives are unavailable for work sessions to define their goals and objectives. Clients will often state in the negotiation phase that their internal team will take on a multitude of tasks to save money. Then, when the project is underway, these staffers are unavailable, and the assumption is that you will take on their commitments. As a consultant you will need to carefully consider and document any assumptions about client participation and get them to sign-off on it. It may be clear to you, as a practicing consultant, what the roles and responsibilities of client and consultant are. The client, however, may be a novice to the consulting process, or may have had advisory relationships with very different ground rules. The negotiation of roles, availability, access, and disclosure should be conducted with the same diligence as contracts and fees.

Defining Success Criteria Determining what the success criteria are and how you are going to define a successful conclusion serves a number of useful purposes. First, it helps both you and the client visualize the final product. Visualization is a useful technique used by athletes and others to help see the end at the beginning. This technique is valuable for more than the confidence it inspires that there will be a successful outcome. It also can be a method for controlling expectations and managing the scope of the project. In any project, the possibility of scope creep should concern the consultant. Anyone who has attended a project management seminar has seen the statistics regarding the number of projects that fail to deliver their expected result. The blame for these failures is often placed on creeping specifications, the ‘‘moving target’’ of client expectations. Working with clients to define success is an excellent way to manage scope and expectations. Creating a clear idea of what the client will have when the project is done allows you to focus the client’s mind on the critical success factors. A definition of success is also critical for communication. Most consulting work requires the participation of many representatives of the client organization, and perhaps other consultants or subcontractors. The clear and simple visualization of success creates a process of mutual agreement on a clearly stated endpoint, so that all can agree when the job has been done.

Being the Advisor, not the Decider The last thing you do when you walk into someone else’s home is start moving the furniture around. Why? Not only is it impolite, it’s not your home; there may be a perfectly good reason why the furniture is where it is and no one asked you to touch it. It’s really difficult for some consultants (and I have succumbed occasionally) to realize that it’s not up to you to decide what the client wants. All you can do is offer your best advice and suggestions. Another danger you need to guard against is ‘‘technology bigotry.’’ Typically, we tend to recommend the sort of solutions and technologies that we are most familiar and comfortable with. Client-focused consulting requires vendor and solution neutrality. All problems do not have the same solution, for which we should be glad, because if they did, IT consultants would not be needed. Apart from the natural tendency to recommend a solution with which we have experience, there is also the entanglement of emotion to complicate the issue. Many consultants feel slighted if the recommendation they make is discounted or ignored. The ability to look beyond our own emotional need for status and validation, and to focus on the cultural, political, and prestige needs of the client, differentiates the professional consultantfrom the rank amateur.

369

370

CHAPTER 12 SO, YOU WANT TO BE A CONSULTANT?

Being Result Oriented There are some consulting situations where all the customer wants to buy is advice or research. I’ve been engaged from time to time to write a ‘‘white paper’’ report that outlines various options and the pros and cons of each. When I delivered that paper, my task was done. I had no role in the ultimate decision or the implementation of the system, and often had no idea if my work was utilized or run through the shredder. Those type of consultancies are relatively rare. Most of the time the reason you’re called on isn’t just to give advice; it’s to provide a specific result. Being result oriented means making that result happen by doing the things necessary to achieve it. There are some things you should do to ensure that at the end of the consultancy, you’ve provided a result that the client wants: Insist (diplomatically) that the goals of the project be communicated to the user community. When users are sold on the benefits of the new technology, when they understand how it affects their duties, when they are involved in scheduling the rollout, the odds for success are enhanced tremendously. Design training, support, and maintenance into your solutions from the beginning. Advising the client to consider these issues adds value far above the purely technical. It helps clients create an environment that is primed for success. It also demonstrates that you can participate at a strategic level and serve as a business advisor.

Technical Skills Successful consultants have to be strong in the technical discipline of their specialties. These skills are the focus of all the training, certifications, and diplomas. The most important thing you must keep in mind is that technical expertise is a process, not an event. What this means is you’re never done developing your skills. IT technology changes so quickly that those who master a current skillset and stop there are doomed to obsolescence. Technical training in IT must be looked at as a lifetime learning experience. Hopefully, curiosity and the joy of learning will motivate you to stay current, if not you’re in the wrong profession. Don’t underestimate your clients either. They are becoming more sophisticated and knowledgeable all the time. They also expect their highly paid consultants to be at least one step ahead of them. Fifteen years ago, knowing how to install a PC and a printer was enough to generate IT consulting contracts. A lot of my early consulting work was teaching clients how to set up their new IBM PCs. Now I frequently walk into clients’ offices and find people there who could probably build a Web 3.0 on during their lunch break. One thing I always tell people is don’t take the attitude that ‘‘I don’t need to know all about the subject; I just need to know more than the client.’’ It’s self-defeating, and I think it displays something about your character that you may want to think long and hard about. You owe any client much more. The real value-adding consultant strives to do more, to gain depth as well as breadth in the technologies that drive competitive advantage for clients around the world. I don’t want a doctor performing surgery on my body who knows ‘‘a little more’’ than I do about the procedure. I certainly don’t want someone tinkering with my business or livelihood with the same attitude about their skillset. Most professions these days require continuing education as a baseline requirement that is the sine qua non of working in and staying in the field, be it law, medicine or engineering. The same applies to consulting in the IT field. You have to be prepared to make the investment in continuous education and development. I encourage you to read IT trade magazines, roam bookstores, search the Internet, attend vendor presentations and user-group meetings, and network with colleagues and do everything possible to learn more.

UNDERSTANDING IT CONSULTING

The market is the ultimate determiner of your value. If you find that your technical skillset is not bringing in the volume of business opportunities that you expect, perhaps you need to broaden your technical scope. Learning new skills and technologies will always increase your value in the marketplace and to your client. Learning new material can also be the right cure for the ‘‘booooooooring’’ syndrome that often sets in when highly intelligent people, such as consultants, have worked it out. I don’t know anyone who really likes to do the same thing over and over again exactly the same way.

Business Skills As I stated in Chapter 1, an IT professional who can navigate the waters of both the technical and business seas is worth his or her weight in gold. One of the common themes in the current business press is the shortage of IT professionals in the labor market. Articles in PC Week and ComputerWorld, and studies by the Commerce Department’s Office of Technology Policy bemoan the fact that hundreds of thousands of IT jobs go begging every year for the lack of qualified technical candidates. How much rarer still is the technical candidate who also has an understanding of business issues. The clich´e of the computer nerd, who must be kept in the back room with a screwdriver in his hand, is, like most clich´es, based on a nugget of truth. Many talented IT practitioners have never mastered basic business skills, and many managers did not consider these skills relevant to the IT function. If you want to be a consultant, it’s time to scrap that sort of silo thinking, and fast. Even if you don’t want to be a consultant, the paradigm in your professional life that will maximize your value, income, and ability to work is to firmly place one foot in each area of expertise and get good at both. ‘‘Specialization,’’ wrote Robert Heinlein, ‘‘is for insects.’’ Many technical professional don’t seem to have many opportunities for exposure to business functions or information. If you want to be a consultant, take some time to do the following: Read general business magazines. Subscribe to Business Week, Forbes, Fortune, or The Wall Street Journal. If you aspire to specialize in a particular industry, or are an in-house consultant, read the trade journals that cover that industry. If you know other consultants, try getting together with them to discuss articles and the like. Watch the business news on TV. CNN’s Moneyweek, PBS’s Nightly Business Report and Wall Street Week, CNBC, and Bloomberg News offer a valuable background in current business conditions. They provide an education on the factors that drive markets, on the state of the economy, and on business sectors that are doing well (or not so well). Use the library. A good library and a competent reference librarian can work with you to put together a reading program that will help you develop into a formidable consulting asset. Learning to use the reference material, such as Business Periodicals Index, Gale’s Encyclopedia of Associations, the U.S. Manufacturers Directory, the Thomas Register, and reference works, can give you research skills that set you apart from the multitude of technically focused consultants with whom you will compete. Read the business classics. There are some classics, such as Management by Peter Drucker or W. Edward Deming’s Out of the Crisis that are necessary to understand. Not being familiar with them is like being an English major whose never read Shakespeare. A program of reading in management, sales, finance, marketing, and business strategy is an obvious place to begin discovering the inner mechanisms of business.

371

372

CHAPTER 12 SO, YOU WANT TO BE A CONSULTANT?

Use the Internet. The amount of information online can boggle your mind. There is everything from online courses offered by prestigious institutions such as Harvard to Dun & Bradstreet directories to company and vendor websites. The Internet brings a worldwide reference library to your desktop. The simple act of reviewing a prospective client’s website or annual report can make a difference in whether or not you want to go after their business and understand what they need. These suggestions are focused on general business understanding. If you’re talking about a prospective or impending client, then knowledge about the specific company, industry, and project issues of the client company are critical to success. You must develop strong research habits, especially when it comes to new clients. Nothing develops client confidence and assurance more potently than a bit of pre-project homework. Consultants who walk in the door with some knowledge of the client’s industry, company history, stock price, and competitive position create the image of experienced and competent professionals from the beginning of the relationship.

Communication Skills Consulting is communication. I’ll repeat this: it’s all about communications. Communications is the key to consulting. Got it? If you can’t establish clear, open, and effective communication between yourself and a client, you can’t be a consultant. The ability to help the customer articulate his or her needs, understand the capabilities and constraints of technology, and create a clear and compelling project vision, are the central tasks of the advisory process. But what is the cultural view of the IT professional? Just look at Dilbert. The IT staffer needs to be kept in the back room. He talks to everyone in such obtuse and obscure jargon that it puts everyone to sleep, or worse yet he’s going to compare the client’s business plans and strategies to a scenario in World of Warcraft. Well that’s not really the truth is it? Most IT professionals are intelligent individuals who have mastered a difficult and demanding craft that has required diligent study and training. The idea that they cannot communicate well is nonsense. People develop those skills for which they are mentored, compensated, and judged. Superior communication skills have not, until recently, been a requirement of the IT profession. In the mainframe days, IT teams worked in the infamous ‘‘glass room,’’ talking mostly amongst themselves, usually with a manager from the finance department to act as their interpreter. As computing moved to the desktop, however, and the ability to provide support and service to users in a language they could understand became a valuable skill, communication came to the forefront. Those technicians who could avoid jargon and communicate clearly with the secretary, clerk, salesperson, and manager became valuable commodities. In short, the desktop PC revolution forced IT to become more consultative. The IT consultant, in a typical day, will need to interview a client to understand his requirements, to examine a candidate and assess her suitability for a spot on a project team, and to report on project activities to a manager or project sponsor. In between these oral communication tasks, the consultant will probably be sitting at a desk preparing a status report, a scope of work document, a proposal, or some operational documentation. Now, is it clear that the central skill for all of these tasks is the ability to communicate? If you’re not already a good communicator or feel that you could use improvement, there are a number of options. If you’re part of a team or large firm, you can work with colleagues. If you’re a solo practitioner, you’re not out of luck. You can join local user groups and technical associations and get in the habit of sharing ideas. Regardless of the method, the ability to communicate

BECOMING A CONSULTANT

must be developed. Communication is the central skill of consulting. Without a mastery of it, IT professionals will have great difficulty excelling as consultants.

Becoming a Consultant Does this idea still appeal to you? Do you think you have more than just the technical skills? Do you want to be a consultant? If the answer is yes, then I’m going to spend the rest of this chapter reviewing the things that you need to do and keep in mind from a practical viewpoint. Please note that it is well outside the scope of this book to provide you with a comprehensive introduction to consulting. I strongly urge you to pick up a few books, either from a library or a local bookstore, and review them in detail. One classic is Alan Weiss’s Getting Started in Consulting (Wiley, 2003) — a good if somewhat dated guide (Weiss, for example, doesn’t see the need for cell phones and doesn’t mention blogs). Another pair of good books is Rick Freedman’s Building the IT Consulting Practice (Wiley, 2002) or his The IT Consultant (Pfeiffer, 2000).

Getting ‘‘Free’’ Experience There are a number of ways you can obtain consulting experience before you leave the safety and financial stability of your full-time job. These methods also provide a relatively accurate way for you to see if your temperament fits the roles of a consultant. You can also use these opportunities to get necessary experience. Some of the things you can do to get experience include: ◆ Facilitate a weekend retreat for a local volunteer group. ◆ Conduct a team-building session for a civic organization such as the Rotary Club or Lions Club. ◆ Offer your services on a pro bono basis to a charitable organization. ◆ Design new software or databases for the local school system. ◆ Teach a class in your area of expertise. All of these tasks — and I’m sure you can come up with others — have several things in common with a consulting job. They require good organizational, communication, and interpersonal skills. And the clients for them may turn out to be some of your best supporters when you launch your career.

Getting Started While the rest of this chapter is primarily going to focus on you starting your own consulting business, there are other ways to enter the field that you may wish to consider. You may opt to go one of these ways because you don’t have the necessary startup money or you’re simply not ready to leave your job: As an employee This can be as a member of a firm, from a small one in your neighborhood to a national powerhouse. There are advantages and disadvantages to both, but they provide a certain degree of stability and a launching pad to start from. As a subcontractor This is similar to being an employee, the difference being you are not employed. This is a less secure position but has much more flexibility while allowing you to gain experience.

373

374

CHAPTER 12 SO, YOU WANT TO BE A CONSULTANT?

As a part-timer In this model you keep your current job, while using your vacation time and weekends to conduct small consulting projects. Depending on what you do as your regular job, you may need to keep your employer informed of this activity to avoid conflicts or interest or the implication of unethical behavior. As a partner In this instance, you team up with one or more consultants to start your own firm. The advantage is sharing expenses; the disadvantage is the conflicts that might arise over unbalanced workloads, personal styles, and so on. The final option, what the rest of this chapter is going to be about, is to be a self-employed consultant. This entails the greatest risk of all the options and also has the highest potential payoff.

Managing Your Finances As a self-employed consultant, you are going to have expenses. And the worst thing you can do is to underestimate them. In fact, the primary reason that most people who decide to become consultants fail is not lack of talent, competition, or methodology — it’s undercapitalization. While it’s not going to cost you a fortune to start a consulting business, there are expenses such as letterhead, phone, and postage, not to mention food, clothing, and shelter for yourself and your family. When you start working as a consultant, you don’t stop living as an individual. Conventional wisdom states that you should start to generate business in six months from your actual startup. This guesstimate is based on a number of intangibles and other variables dependent on your focus, market factors, and so forth. The stream of business won’t be strong until the end of the first or second year. Consequently, you need to have necessary capitalization to keep you and the business going till your business starts generating income.

Reducing Monthly Expenses The first step is to reduce your optional monthly expenses. Dine out less; maybe forego this year’s vacation; do all of the things you need to do to create the lowest monthly expenditure you (and your family) can reasonably commit to. Once this commitment is made, you must do what you can to stick to it.

Establishing a Fund for the Year Find enough actual money (not future business or projections) to fund your monthly expenditures for 12 months. If you don’t develop any business in the course of a year, you can at least say that you gave it a shot, but the profession just isn’t for you. Where do you get the money if you don’t have a fat bank account? Nonretirement savings Cash in stocks, bonds, certificates of deposit. The problem with this is you may be paying a considerable amount in capital gains taxes. In the other hand if you cash in stocks and bonds that have taken a loss, you get a tax deduction. However, very few long-term-held stocks have lost money over the past decade. Home equity loan If you have your own home, this is an excellent source of funds. The interest is fully deductible as well, and a home equity loan is usually readily obtainable. Retirement savings This is actually my least favorite option, since usually you have to pay penalties and you are risking something that you’re going to need. You also lose the benefit of tax-free interest appreciation. I personally don’t advise this route for anyone over 40. Lines of credit

These are quick and fast but carry incredibly high interest rates.

BECOMING A CONSULTANT

Investors This may sound like a good idea, but it can be a trap. Don’t offer investors an equity ownership position in your business. Family Some families will happily loan you money in a warm and friendly supportive atmosphere. Others won’t. No matter which route you take (and there are some alternatives I haven’t mentioned such as selling property or having a spouse work), the key is to set aside a full year’s living expenses. You can’t enter the consulting profession full time with only a few months’ reserves.

Considering Startup Expenses Now that you’ve gotten food, clothing, and shelter out of the way, the next item is to create a startup budget. Identify everything you will need to start your consulting business. Think in terms of furniture, equipment, supplies, and setup expenses. What do you need?

Office Space Some consultants are able to turn part of their home into an office and workspace. If you choose to go that route, it is very important that you clearly delineate your workspace as workspace. The last thing you need is your two-year-old answering the phone when the CEO of a company is calling, or to have your dogs barking in the background. A home office should have the following: ◆ A private area with a door. ◆ Enough space for all equipment and supplies. ◆ Your biggest challenge will be to educate family members that when you are in your office you are at work, and not to be disturbed. This is important because you need to have the mindset that you are running a business in order to have one, and it’s difficult when that isn’t respected. Other alternatives include sharing office space or renting a formal office. Both are expenses you might not want to take on.

Equipment You obviously need office equipment. At the start you minimally need the following: ◆ Two-line phone ◆ Voice mail ◆ Copier ◆ Computer and peripherals such as printer, scanner, and the like ◆ Postage meter ◆ Cell phone ◆ Laptop computer ◆ High-speed Internet connection

375

376

CHAPTER 12 SO, YOU WANT TO BE A CONSULTANT?

It would also be useful to have television set and a video recorder to keep track of news and review any training or promotional material. A radio is important, and you’ll find a voice recorder useful as well. A last bit of advice, while being careful how you spend money is good, buying cheap junk is counterproductive economy. Don’t try to get by with poor equipment or without essentials. You’ll land up spending more time on busywork than you do on consulting, and you’ll tarnish you image as well.

Getting Professional Help Sorry, I couldn’t resist using that heading. No, I’m not suggesting anyone considering a consulting career should have their head examined. One key fact of being a consultant and running your own business is that you’re not going to be able to do it on your own. There are a considerable number of tasks that need to be performed — from tax accounting to payroll activities to legal incorporation — that require specialized knowledge. To get that sort of help and advice, you’ll need to hire and retain some specialists. The following is a quick summary of these professionals and what they can do for you: Accountant This person will help you set up your books and navigate tax issues and other fiduciary requirements. Lawyer A good lawyer can help you determine the structure for your business (e.g., should you incorporate, set up an LLC, etc.) as well as guide you through pertinent legal requirements. Banker You should cultivate a relationship with a banker who is familiar with your business, provides personalized assistance, and can expedite matters for you. You should also make sure that you maintain a separate account for your business and personal finances. Designer This is the person who will help develop logos, letterhead, media kit, and the like. Whatever you do don’t use computer-generated stationery or stuff you buy off the shelf. People may say ‘‘image isn’t important,’’ but they’re lying. The more professional your business cards and presentation look, the more you’ll be treated as a professional. Insurance agent You’re going to need insurance, and whether you use one agent for all your needs or a variety of them, they should be professional. You’re going to need the following types of insurance for your business: ◆ Disability ◆ Liability ◆ Life ◆ Malpractice (sometimes called Errors and Omissions) ◆ Medical ◆ Property Payroll services This is to handle the payment of checks and determination of the appropriate tax deduction. This is becoming more and more of a necessity, especially as the government has made electronic filings mandatory. Web designer You can’t run an IT consulting business without a web site. You have to show you know how to use technology and a web site shows that you’re conversant with

BECOMING A CONSULTANT

mainstream technology. It tells clients a great deal about and is as important as a corporate brochure, and may be even more important. Bookkeeper You may not need a bookkeeper at the start, but once you start moving into six figures you will.

Marketing Yourself Consultants don’t go on sales calls. Clients must be attracted to you, and they should contact you. I first learned that lesson from Rob Lebow, a former director of marketing and corporate communications at Microsoft and now CEO of Lebow Company and the developer of the Shared Values Process. Why? The buying psychology is 180 degrees different when you are sought out, rather than the seeker trying to ingratiate himself or herself to a buyer. When the buyer comes to you, the relationship between you is more likely to be on a peer level, collaborative basis, rather than supplicant to grantor. You do this through the process of marketing, which is the act of creating and enhancing the sense of need among potential buyers for your services. The creation is important, because not all clients realize that they need your help, or that what they want may not be what they need. There are some tried-and-true basic marketing techniques that you should be familiar with; these consist of the following: ◆ Media kit ◆ Image products ◆ Networking ◆ ‘‘Free’’ work ◆ Passive marketing Let’s take a closer look:

Media Kit A media kit is your primary physical marketing tool. It is flexible, required, and the mark of a professional organization. It’s going to be the most ubiquitous of all your physical marketing tools. It will be sent to prospects, used as a leave behind, used to answer media inquiries and requests for interviews, used for proposals and confirmations, and used for any number of other purposes. What should you put in your media kit? Results a client should expect if they hire you Clients want to know what benefits hiring you will bring to their business, so make sure that you list expected client outcomes right at the start. Testimonials If potential clients see that you’ve been well received before, they will be more comfortable approaching you. If you’re just starting out, one recommended technique is to obtain character testimonials about your honesty, work ethic, quality, intellect, and so on. Biographical sketch This is about yourself and is designed to explain who you are and what qualifications or background you bring to the job. This is not a resume, so keep it short, less than one page. Keep it simple, honest, and relevant. Don’t be afraid to use humor. Position/white papers These can be powerful marketing tools. A white paper is simply your position on an issue in area about which you consult. Typically, these are two to six pages.

377

378

CHAPTER 12 SO, YOU WANT TO BE A CONSULTANT?

They enable you to establish credibility and value for the prospective client. I strongly suggest that you create at least one paper a month until you have a couple dozen.

Tip Through an interesting twist of psychology the more references your provide, the less likely a prospect is to call any of them. References This is a list of people who are willing to vouch for you or the work you have done (or both).

Image Products There’s an old saying ‘‘you can’t judge a book by its cover.’’ Sounds good, but it’s not true. Whether it’s the cover of a book, a potential mate, or simply a business organization, the first thing we use to judge any thing or anyone is the outward appearance. It can speak volumes. It may not be the final criteria we use for determining whether this is someone we can do business with, but it does tell us whether we want to give someone our attention.

Print Materials Normally, the first image your clients will see is your printed material, that is why a good designer is very important and a smart investment at the outset. They can help you prepare the following professional-looking materials: ◆ Letterhead ◆ Business cards ◆ Envelopes ◆ Labels

Tip Keep your business card simple, but personalize it for the other party. It’s a nice gesture to write your home phone number on the back or a book title you’re recommending or even the name of another consultant for another project. The person will have useful information and know whom to thank.

Website The key aspects of an effective website for consultants are: ◆ Easy navigation ◆ Lack of clutter ◆ Informational material such as free articles for downloading, techniques and tips and links ◆ A clear explanation of how the client benefits from your services ◆ An easy way to contact you You can have people sign up for your newsletter, join your discussion groups, or sign a guest log. The aim is to keep track of interested visitors who might someday become clients.

BECOMING A CONSULTANT

Networking This one of the most commonly used and abused buzz words of the last 50 years. Networking isn’t merely talking to people, handing out business cards, and acting like a politician running for office. Networking isn’t asking for something for yourself. It’s an interactive process whereby you develop reciprocal and mutually beneficial relationships through interpersonal, telephone, electronic, and written means. What differentiates effective networking from glad-handing is that an effective networker’s relationships with others combines providing value that others will want to reciprocate with creating the impression that you’re the sort of person that they will happily direct third parties to who might want your services either now or in the future. Why does this work when it’s actually implemented? Why did you go to the last movie you saw? Odds are that someone who saw it, and whose opinion you trust, recommended it to you. If faced with the choice between trusting media hype and a friend’s recommendation, which way do you go? There are hundreds of books and articles about effective networking, but in the end it always boils down to whether or not you can establish a mutually beneficial relationship with another person. Noting makes you more memorable to another person than when you provide powerful value to him or her. My strongest recommendation is that you develop good networking skills and never be afraid to give to get.

‘‘Free’’ Work Free, or pro bono, work is work you deliberately do without charging. Typically, this is performed for nonprofit organizations or other groups that can’t afford to pay for your services anyway. Some consulting advisors recommend that you should always have one pro bono project going on at all times. Never do pro bono work for a profit-making organization. It makes you look desperate and will present problem if you ever want to bid on a project for that organization in the future. Why do pro bono work? There are several good reasons: ◆ You are contributing to a worthy cause. ◆ You are developing and fine-tuning your skills in an appreciative environment. ◆ Potential clients will see you in the best possible light — as a caring, giving communityspirited person.

Serendipity Typically, you will want to find pro bono opportunities that involve you with potential customers. If you can’t, still do it — it is amazing where people end up and who you might encounter. I was once working on a small pro bono project for a veteran’s group in the Middle East where I was living at the time. There was a young blonde woman whom I barely knew but who thought highly of the work I was doing and commented appreciatively to me. She said she would be quite happy to contact her former employer and tell them about me., which she did. Who was her former employer? Until six months earlier she had been the public relations director for Halliburton, Dick Cheney’s old firm. Needless to say her recommendation opened a number of doors.

379

380

CHAPTER 12 SO, YOU WANT TO BE A CONSULTANT?

One of the nice things about doing pro bono work is that no organization soliciting free help is going to question your experience, credentials, or motives. So these are, as we mentioned earlier, ideal opportunities to gain experience and recognition when you are starting out. Despite the temptation to do the opposite, make sure that you bring the same level of work ethic, enthusiasm, and skill to the pro bono work that you do to paying clients. Doing otherwise is not only unethical but also self-defeating. People can usually tell when you’re not giving it your all, especially in a nonprofit where the motivation is genuine enthusiasm and commitment and not greed.

Passive Marketing By passive marketing I’m referring to ads, listings, and other places where you can advertise your services. The key locations where you should always list your business are: ◆ Buyers guides ◆ Directories ◆ Yellow pages — pay for at least a bold listing and a small display ad Pay as close attention to appearance here as you did with your stationery, business cards, and other printed matter.

Writing and Publishing Nothing establishes credibility as quickly as having written something and had it published. A book or an article that is published by an independent source creates credibility, and the publisher’s reputation will burnish your own as well. If one piece lends credibility — a body of work provides much more and defines a clearer idea of your intellect, and the validity and the integrity of your business. How do you go about getting published? Its both simple and difficult, but here are some basics. First, find out what people tend to read. Ask your clients and colleagues what they think are valuable resources: what books they read and what journals and magazines they consider authoritative or invaluable. Once you have the list, the next step is to actually pick up several issues of the magazines or journals (libraries can help you with back issues) and review the following: ◆ Does the publication accept freelance offerings? ◆ What’s the tone or voice the publications use? How are the articles formatted? ◆ Where do they get their articles? World experts or people with well written ideas? ◆ Get the name of the editor. Once you’ve established the magazine you’d like to write for, the next step is to propose an idea. Write a query letter to the editor that describes the article you’d like to submit, why it would be of interest to the readers, and your credentials for writing it. In the past it was unheard of to submit a query letter by email, but now that is the common method. However, you should double-check the publication’s guidelines for what they expect and how they expect it — and then follow the guidelines precisely. Submit the letter and wait. Never call or follow up. If the editor is interested, he or she will contact you. If you don’t succeed the first time, don’t be discouraged, just keep plugging away. The key is to find a publication that is interested in your idea. It’s also important that you send

BECOMING A CONSULTANT

your proposal to a magazine that is interested in the topic. Sending an article on ‘‘Ten Pitfalls to Avoid in Configuring Exchange Server 2007’’ might work well in Redmond Magazine but isn’t going to be a viable topic for PC Gamer.

Public Speaking Speaking can be an effective (and independently lucrative) marketing tactic. Initially, as you develop your practice, you can usually get speaking engagements in front of local groups without much difficulty. Service organizations like the Rotary and Kiwanis clubs, chambers of commerce, and the like are always interested in luncheon or dinner speakers. They don’t pay, but the appearances are effective ways of: ◆ Gaining practice at public speaking ◆ Exposing you to local buyers and potential clients ◆ Gathering testimonials ◆ Gathering references ◆ Learning what the local hot topics and issues really are You can include the appearance in your media kit. It might also be possible for to write an article for the organization’s newsletter or be interviewed for it by them. Once you’ve established yourself as an effective speaker, you can start looking outside the local area. The most important groups to reach out to in terms of marketing are trade and professional organizations. These groups specialize in membership education. Additionally, the conference participants are usually the recommenders or actual buyers of consulting services. You can speak at any one of a number of concurrent sessions. Eventually, if your practice and ideas are sufficiently compelling, you might get to be a keynote speaker.

Newsletters Newsletters, like articles, are a good way to gain credibility early in your career and provide you an ongoing point of contact with clients, colleagues, and prospects. The one thing I encourage you to do is not to create a newsletter that sings your praises. No one is going to waste their time to read about how wonderful you are, who your clients are, and all that other stuff. They are going to read your newsletter for information of interest to them. Meeting that need will provide more effective marketing and ‘‘promotion’’ because readers will come to depend on your advice and respect your expertise. So how do you create a professional newsletter as a marketing tool? Keep these items in mind: ◆ Make it free. ◆ Keep it short. Two to four pages is sufficient. ◆ Keep to a schedule. Never miss an issue. Monthly is best; quarterly works but barely. I think more than once a month is too much. ◆ Make the format professional. ◆ Writing short pieces with bullet points is better than creating long narratives. ◆ Always include references to other material. Make clear attributions to work you’ve taken form other sources.

381

382

CHAPTER 12 SO, YOU WANT TO BE A CONSULTANT?

◆ I have found that swapping mentions of each other’s newsletter with colleagues will increase your subscription base. ◆ Encourage readers to write letters and comments, and include pertinent ones in future issues. ◆ Archive back issues on your website.

Blogs As we ease into the latter part of the first decade of the twenty-first century, one thing that stands out above all else is the change the Web is making in how business is done and how people interact. I don’t think that anyone has the definitive handle on this yet, but you can’t ignore the Web. Blogging is currently being viewed as an effective marketing tool for everything, including consulting business. David Meerman Scott in his book The New Rules of Marketing and PR (Wiley, 2007) calls a blog your ‘‘front door.’’ The place where a blogger/consultant can post his or her ideas, both big and small. He calls his blog, ‘‘the most important marketing and PR tool I have.’’ He’s not alone in that assessment. Robert Scoble and Shel Israel in Naked Conversations (Wiley, 2007) emphatically state that blogs are changing the way that businesses talk with customers. What this means is that, just as you have to have a computer and a website and email to survive as a consultant today, you’re going to need to utilize blogging as a marketing tool for your consulting business, sooner rather than later. Blogs allow you do to the following: ◆ Monitor what millions of people are saying about you, the market you work in, your organization, and its products ◆ Participate in those conversations ◆ Begin and shape those conversations by creating and writing your own blog How do you use a blog to successfully market your consulting firm? ◆ Start with the idea the a blog is a personal web log that people visit because they want to hear what you and other have to say. They aren’t interested in a sales pitch, but they do want you to communicate with them about ideas and get to know you. ◆ Post often and be interesting. This can be a struggle and time-consuming, but once you’re good at it, it won’t be. You do want to generate traffic and have people come to see what you’re thinking and saying. Posting often also helps with search engine ratings. ◆ Write on issues you know or care about. If you’re a consultant for developing messaging systems, write about that. A good blog is passionate and shows authority. While it’s not a good idea to turn a blog into a sales device (people will simply not visit), showing what you know and care about is perfectly acceptable. ◆ A good blog can save you money by reducing or eliminating the need for advertising and other media support items. It can, however, be time-consuming. Being a good blogger takes time. You need to be part of the conversation by reading other blogs, linking to them, and writing comments on them.

PROFESSIONAL CONDUCT

◆ The more you listen the smarter you get. I don’t care how smart you are, your readers are collectively smarter than you are, and even negative comments can tell you a great deal about whether what you’re doing is on the right path or not. ◆ A good blog can help you build a reputation as a leader in your field. Blogging is a way to personal prominence without the ‘‘look at me, look at me’’ behavior that is so grating. At this point in their development blogs are not really the ideal venue for the sales of services. The readers aren’t there to buy, but to learn. That makes a blog an ideal forum to establish expertise, show engagement and interest, and build a reputation. This, in the final analysis, is what you’re marketing — yourself.

Professional Conduct There shouldn’t be a reason to write this section, but the sad truth of the matter is that there are now almost as many consultant jokes as there are lawyer jokes, and most of them are a little too close to the mark and have a little too much justification. The following is a simple list of the two key things owe to your clients at all times: ◆ Integrity ◆ Application of all your skills and expertise to their benefit What’s integrity? This is a lengthy topic that can go on for pages and fill books. It needn’t though. Integrity is doing the correct, moral thing even when you don’t want to or it’s not in your best interest. It means telling the truth about your own background and experience. It means reporting to stakeholders, customers, or others any actions or circumstances that could be construed as a conflict of interest. You will very likely come across confidential information or intellectual property during your consulting experiences. Respect the use of this information and always verify who may have permission to access the information and when disclosures are required. Integrity is why you finish a project early when you can even though its going to mean you’re paid less rather than ‘‘drag it out’’ another week. Integrity is why you don’t divulge company secrets to another competitor. Integrity is why you answer the phone at 3 A.M. The thing about integrity is that it can’t be faked for long. If you don’t act as honest broker, you will be found out and the damage to your professional and personal reputation will be irrecoverable. You also owe your clients your skills and your professional judgment, fully and totally. So use your best judgment. Use all your skills and energy to help them achieve the goal they’ve set for themselves through you. Unlike lawyers and doctors, there is not yet a single code of ethics for consultants, but that doesn’t let you off the hook. Many consulting associations have ethical codes that they require their members to follow. And if you don’t already have your own set of personal ethics that would let you write your own, then you really are considering the wrong profession. The Society of Telecommunication Consultants (STC) is an international organization of independent telecommunications and IT consultants who serve clients in business and government. The organization’s code of ethic is:

383

384

CHAPTER 12 SO, YOU WANT TO BE A CONSULTANT?

STC Code of Ethics Members of the STC are required to be independent and are restricted under the STC Code Of Ethics from selling any product or service other than independent services. Every consultant member must sign annually renewing and reinforcing their independence and ethics by signing the Code Of Ethics as follows: ◆

Every member has the professional responsibility of fair dealing towards the member’s clients, past and present, fellow members, and the general public.

◆

Every member has the professional responsibility of adhering to generally accepted standards of accuracy, truth and good taste at all times.

◆

No member shall represent conflicting or competing interests, nor shall be placed in a position where the member’s interest is, or may be in conflict with duty to the client.

◆

Each member shall safeguard the confidences of both present and former clients, and shall not accept retainers which may involve the disclosure or use of these confidences to the disadvantage or prejudice of such clients.

◆

No member shall intentionally disseminate false or misleading information, and each member is obligated to use as much care as is humanly possible to avoid dissemination of false or misleading information.

◆

No member shall intentionally injure the professional reputation or practice of another member. However, if a member has evidence that another member has been guilty of unethical, illegal or unfair practices, including practices in violation of this Code, the member is obligated to present the information to the proper authorities of the Society for action in accordance with the procedure set forth in the bylaws.

◆

No member shall accept fees, commissions, or any other valuable consideration in connection with those services from anyone other than the member’s client.

◆

Each member shall, prior to the commencement of the services to be performed, make the client fully aware of the fee structure, and all associated costs.

◆

It is imperative that no member should be in conflict by retaining an ownership or partnership interest in, or be an employee of, any company selling or leasing telecommunications products or transmission services.

◆

A member shall, as soon as possible, sever the relationship with any organization when the member knows or should know that continuing the relationship would require the member to conduct himself contrary to the good conduct principles of this Code.

Summary Ready to become a consultant? If you do you’re in for one of the most exciting and potentially rewarding experiences you’ll ever have. But it’s not all fun and games. It means long hours, separation from family, high financial, risk, and numerous potential pitfalls. It’s not for everyone.

LAST WORD

Whether that’s the path you choose to take or not really doesn’t make a difference in your value and the knowledge you bring to any job based on the skills we’ve reviewed throughout this book. If you choose the consultant path, there are some key things to remember. First, you need to hone your advisory, technical, business, and communication skills. Consultancy is all about building relationships, and these are key elements to an building effective relationship. Transitioning to being a consultant isn’t easy, but it obviously isn’t impossible either. Make sure that you’re properly capitalized and have the right tools for the job to get you through the first year. Don’t be afraid to spend money for value. Being economical about the wrong things is as bad as overspending. How successful you are is going to depend not merely on your technical skills, no matter how considerable and profound they are. It’s also going to depend on your marketing skills. Seek out professional help if you don’t know how to handle the marketing, and use every opportunity you can find to present yourself and your ideas. Use websites, newsletters, and blogs to present your expertise and build your reputation. Finally and most obviously, adhere to a rigid ethical standard in both your professional and personal life.

Last Word With this final chapter I also want to say thanks to you for joining me on this journey. This book has been about approaching technology, in this case an Exchange Server 2007–based messaging system, from a business-oriented viewpoint. It hasn’t been my intention to make you an expert on Exchange Server 2007. There are other books from Sybex and Wiley that can guide you through the technical aspects. However, if you follow the guidelines in this book, you’ll be a able to do something mere technical knowledge alone won’t allow you to do. You’ll be able to create an Exchange Server 2007–based messaging system that brings value to your organization and helps your business reach its goals. And that, you will discover, makes you a very valuable member of any organization and ensures you a bright and promising future. Good luck!

385

Appendix A

Measuring Team Effectiveness Whether you are new to heading up a project team or have been doing it for years, one of your responsibilities is to make sure that your team is performing optimally. You can score yourself on the following four questionnaires, based on research by consultant Kevin Lohan, or you can distribute them to all team members to gather a collective team score, in order to measure four aspects of team effectiveness: goals, roles, procedures, and interpersonal relationships. Each response is rated from 0 to 5 points. The total maximum score for each of the four team aspects is 50 points. Once the sheets have been completed, their interpretation is up to you. To start with, there is no ‘‘good’’ or ‘‘bad’’ score. Your interpretation of what each statement means and the variables that exist in a numerical rating system make that sort of diagnosis relatively worthless. What the assessments allow you to do is to identify strengths and weaknesses on the team, as well as your leadership. A meaningful diagnosis is achieved by comparing score for each aspect against the other three. You can then determine which area has the greater need for development. At the same time, you can look at each of these four aspects to identify issues that need urgent attention by comparing the scores for each of the 10 items with others in the quiz.

1: GOAL SETTING

1: Goal Setting Directions: The 10 items that follow are associated with establishing and maintaining goals for your team. Consider the two statements in each item and then circle a number between the two options to indicate how closely your team fits one or the other description.

I never discuss objectives with others on the team.

0

1

2

3

4

5

I always discuss objectives thoroughly with others on the team.

Our goal review sessions are more than a month apart.

0

1

2

3

4

5

Sessions to update our goals are held at least every 2 weeks

Goals and milestones are not distributed evenly

0

1

2

3

4

5

Goals and milestones are at appropriate intervals.

We rarely clarify how we will measure our success.

0

1

2

3

4

5

We have defined success criteria.

We rarely meet to discuss performance.

0

1

2

3

4

5

Performance is either part of our regular agenda or discussed often.

Once set, our goals rarely change 0 as circumstances change.

1

2

3

4

5

When unexpected situations arise, our goals are open to renegotiation.

Only staff (and not the manager) have clear accountabilities.

0

1

2

3

4

5

Everyone has clear accountabilities.

Unachievable targets are often set for the team.

0

1

2

3

4

5

Targets are always achievable.

Nothing is done to ensure that people share information about their goals.

0

1

2

3

4

5

We ensure that people share information about their goals.

We rarely check the organizational relevance of our goals.

0

1

2

3

4

5

Total of 10 circled numbers:

Goals are checked to ensure they are relevant to the organization’s goals.

389

390

APPENDIX A

MEASURING TEAM EFFECTIVENESS

2: Roles Directions: The 10 items that follow are associated with establishing and maintaining goals for your team. Consider the two statements in each item and then circle a number between the two options to indicate how closely your team fits one or the other description.

There are no clear, written job descriptions for each role.

0

1

2

3

4

5

Written job descriptions exist for each role.

Lines of responsibility are unclear and people often question their parts of a task.

0

1

2

3

4

5

People know their responsibilities very well and rarely question them.

0

1

2

3

4

5

Assigning work is easy. Team members know their roles and accept them.

When one person is absent, other people are uncertain about 0 how to fill in.

1

2

3

4

5

When one person is absent, important things still get done.

No one is being groomed to learn a new role.

0

1

2

3

4

5

People are always being groomed for the next position.

There is no program for addressing staff weaknesses.

0

1

2

3

4

5

Staff development is addressed continuously.

We do not openly discuss our roles.

0

1

2

3

4

5

We openly discuss our roles.

There is very little respect for each other’s part in the process.

0

1

2

3

4

5

Everyone respects the part played by every other team member.

Informal roles are often adopted that take over from formal roles.

0

1

2

3

4

5

The formal roles are followed by everyone and attempts to adopt informal roles are not made.

Leadership of the team is unclear.

0

1

2

3

4

5

Team leadership is clear.

It is difficult to assign work without making waves.

Total of 10 circled numbers:

3: PROCEDURES

3: Procedures Directions: The 10 items that follow are associated with establishing and maintaining goals for your team. Consider the two statements in each item and then circle a number between the two options to indicate how closely your team fits one or the other description.

There are few, if any, clearly communicated policies and procedures.

0

1

2

3

4

5

Clearly written policies and procedures are readily available for our use.

We have trouble agreeing on tough team decisions.

0

1

2

3

4

5

We have agreed-on procedures for reaching tough team decisions.

There isn’t a procedure for resolving conflict.

0

1

2

3

4

5

There is an agreed-on procedure for resolving conflict when it arises.

0

1

2

3

4

5

Communication is appropriate, and we know how and from whom we get information.

0

1

2

3

4

5

Formal rules are almost always complied with.

Our organization does not welcome ideas for change.

0

1

2

3

4

5

Our organization encourages innovation.

Our operating procedures are out of date.

0

1

2

3

4

5

Our operating procedures are regularly updated to reflect current methods and technology.

Our meetings are usually a waste of time.

0

1

2

3

4

5

Our meetings are productive and well run.

Policies favor labor-intensive, time-consuming procedures that 0 cover all the bases.

1

2

3

4

5

Policies favor getting things done rather than guarding against error.

1

2

3

4

5

Policies are the same for everyone, with a few necessary exceptions.

Communication is confused and comes and goes in many directions. Formal rules are rarely followed.

Policies appear inconsistent. 0

Total of 10 circled numbers:

391

392

APPENDIX A

MEASURING TEAM EFFECTIVENESS

4: Interpersonal Relationships Directions: The 10 items that follow are associated with establishing and maintaining goals for your team. Consider the two statements in each item and then circle a number between the two options to indicate how closely your team fits one or the other description.

Some people on the team treat others as inferiors.

0

1

2

3

4

5

Everyone treats others as equals, and there is clear evidence of empathy.

People on the team do not trust each other.

0

1

2

3

4

5

People on the team trust each other.

If people have problems, they keep them to themselves.

0

1

2

3

4

5

If people have problems, they discuss them with each other.

There is no feedback among the team about each other’s work.

0

1

2

3

4

5

Everyone accepts feedback willingly and gives it appropriately.

I do not find out about problems I have created until it is too late.

0

1

2

3

4

5

Problems I create are promptly brought to my attention so that corrective action can be taken.

Anger and frustration are displayed as violent outbursts.

0

1

2

3

4

5

Anger and frustration are resolved rationally.

I do not treat others on the team as friends but as coworkers.

0

1

2

3

4

5

Friendships among the team are common and do not cause problems.

In a conflict one person usually wins at the expense of others.

0

1

2

3

4

5

Conflicts are resolved to the satisfaction of everyone concerned.

0

1

2

3

4

5

Participation in decision making and at meetings is equally shared.

1

2

3

4

5

Participation in decision making and at meetings is unequal, and some people dominate.

Perceptions held by team members about our relationships 0 are not the same as those of people outside the team. Total of 10 circled numbers:

Our perceptions about the way we get along are the same as the perceptions of those outside the team.

Appendix B

Sample Business Case Proposal This appendix is composed of a sample business case for the Exchange Server 2007–based messaging system discussed in this book. The sample is greatly simplified in order to help you understand how to prepare one. Figures and time frames are intentionally ‘‘fanciful.’’ An actual business case will require additional details and depth. You should always use the template provided you by the enterprise for whom the business case is prepared.

394

APPENDIX B

SAMPLE BUSINESS CASE PROPOSAL

Business Case for Exchange Server 2007–Based Messaging System for Oakland Playground Equipment, Inc. Date: January 14, 20xx

Executive Summary This business case recommends implementing an Exchange Server 2007–based messaging system. The implementation will result in enhanced business communications that will save or generate revenue of $832,500 over three years. Process and data improvements will increase productivity throughout the Oakland Playground Equipment Company. For example, the productivity of the sales staff may increase by up to 40 hours per sales person per year. The Exchange Server 2007–based messaging system will cost $270,000 over three years. It will replace the existing messaging system. The return on investment over three years is 308.30%.

A. Introduction A.1. Background The current Exchange Server 2000 messaging system was implemented in 2002 and is now two generations behind current technology. In the intervening six years significant changes in regulatory and business requirements have occurred which this system is unable to address. Similarly, our lessening ability to leverage improvement in business communication technology, such as unified communications, is threatening our competitive ability. Furthermore, analysis of current work has determined that one IT employee and two non-IT employees have tasks compensating for insufficiencies in the current Exchange Server 2000–based messaging system as their sole work.

A.2. Assumptions The volume of business communications will stay the same or increase over the next three years. The company intends: ◆ To maintain or improve its market share ◆ Leverage improvements in business communication technology ◆ Mitigate liability by adherence to relevant message archiving and journaling requirements There will be no significant changes in existing regulatory or business requirements that exceed the capabilities of the proposed solution. Implementation and ongoing support will not require any addition in existing personnel levels but will allow for elimination of three positions in the company. Inflation and cost increases will be a modest 5% over the next three years.

A.3. Proposed Action To develop and deploy an Exchange Server 2007–based messaging system as detailed in the attached statement of work.

A.4. Business Objectives The proposed messaging system will support the following corporate objectives: ◆ Increase sales and market

BUSINESS CASE FOR EXCHANGE SERVER 2007

◆ Provide protection against noncompliance litigation ◆ Leverage technology ◆ Reduce or re-deploy manpower ◆ Ensure more efficient and timely communication with key officials

A.5. Business Case Purpose The purpose of this business case is to assist key stakeholders at Oakland Playground Equipment as follows: ◆ Provide support for decision-making regarding the proposed statement of work ◆ Provide information relating to the goals of the proposed statement of work ◆ Specify the benefits of the planned implementation

B. Business Case Methods B.1. Business Case Scope and Boundaries This business case will result in: ◆ Replace current Exchange Server 2000–based messaging system with an Exchange Server 2007–based messaging system by October 1, 2008 ◆ Integrate with and provide anywhere communication capabilities for 25 senior members of management ◆ Provide 24/7 availability of messaging capabilities ◆ Provide auto-archiving ◆ Provide each employee with email capability while preserving all existing mail stores ◆ Antivirus and antispam capabilities that meet or exceed industry best practices Costs and projections are based on data supplied by the Finance, Human Resources, and the Sales department, and all assumptions therein are based on historical trends or estimates.

B.2. Rationale for Benefits This project will assist Oakland Playground Equipment meet the following company objectives: ◆ Improve customer satisfaction by enhancing communications ◆ Improve sales goals by allowing for improved sales staff–home office communication ◆ Achieve operating efficiencies ◆ Leverage technology to corporate benefit ◆ Prepare the workforce for the future

395

396

APPENDIX B

SAMPLE BUSINESS CASE PROPOSAL

B.3. Success Criteria The criteria for success for this project will be as follows: ◆ Deployment by July 1, 2008 of an Exchange Server 2007–based messaging system ◆ Implementation cost not to exceed $180,000 ◆ Said system to provide 24/7 availability with a maximum of 2 hours of downtime ◆ Archiving and retention policies and methods will match or exceed regulatory requirements ◆ Message and system security to match or exceed industry standards ◆ Annual operating costs not to exceed $30,000 per year exclusive of manpower ◆ No increase in current IT personnel required ◆ Reduction in three FTEs currently used to support workarounds

C. Cost Projections C.1. Financial Model The bottom line costs for this project are $270,000 over three years, exclusive of personnel. The startup cost will be $180,000 with recurring annual costs of $30,000 per annum. Revenue flow will be reflected in increased sales and improved customer satisfaction. The finance and sales department have predicted a 10% increase in sales per year. The new system will allow for the elimination of one IT position and two non IT positions (one in customer service and one in orders, who are currently employed to overcome/workaround shortcomings due to the current messaging system’s shortcomings). This will generate an annual savings of one FTE reduction in the first year ($100,000) and the elimination or change to part-time status of the other two positions the following year (total = $120,000). This will result in personnel cost savings of $540,000 over three years.

C.2. Cost Analysis Project Implementation Costs ◆ One time costs include: ◆

Hardware: $60,000

◆

Software Licenses: $60,000

◆

Contract labor for development & implementation: $40,000

◆

Training costs: $20,000

◆ Ongoing costs include ◆

Annual maintenance fees: $15,000

◆

Spare parts per annum: $5,000

◆

Training of new hires (non-IT): $2,000

BUSINESS CASE FOR EXCHANGE SERVER 2007

◆

IT Staff education: $3,000

◆

Annual offsite storage: $5,000

Note: Above figures include adjustment for projected 5% annual inflation rate. Two IT staff and two nontechnical staff will be assigned full time to the project team for a period of six months. This represents a commitment of 3,260 man hours. No additional new IT projects can be started during this time frame because of the small size of the existing IT staff.

C.3 Alternative Solutions The only valid alternatives are to continue as is, which is clearly unacceptable since the company wishes to address the problems stated above. An additional valid alternative is to examine the components of the statement of work defined deployment and opt to delete or defer their deployment. This is unfortunately a short term, rather than long-term solution, and the business needs for the components identified in the solution have already been established. Alternate solutions would require a full appreciation of the tradeoffs involved.

D. Benefits D.1. Tangible Benefits The tactical (tangible) benefits of this business case are: ◆ Improvement in business communication resulting in improved staff productivity ◆ Reduction in manpower requirements (3 FTEs) currently employed to provide workarounds to insufficiencies of the existing Exchange Server 2000–based messaging system ◆ Improved availability of messaging system, particularly email ◆ Better security and antivirus and antispam protection ◆ Replacement of antiquated and near obsolete hardware ◆ Streamlined ordering and communication of orders

D.2 Intangible Benefits The following intangible benefits will be reduced form this deployment: ◆ Improved customer service ◆ Improved leveraging of technology ◆ Preparing the workforce for the future ◆ Improved compliance with regulatory requirements and flexibility to meet future requirements ◆ Full disaster recovery of messaging data ◆ Positioning of communication systems towards a unified communication model

397

398

APPENDIX B

SAMPLE BUSINESS CASE PROPOSAL

E. Cost-Benefit Analysis E.1. Financial Projections The $270,000 in funding for this product will purchase: ◆ Four next generation 64 bit hardware with an estimated life cycle of three to five years ◆ Exchange Server 2007 Enterprise Edition (Service Pack 1 or later) ◆ Twenty-five PDAs capable of interacting with new messaging system ◆ Ad hoc contract labor ◆ Training for employees ◆ Ongoing maintenance for three years ◆ Three years of spare parts ◆ Certification training for IT staff ◆ Offsite storage for three years Nonfinancial impacts of this project consist of: ◆ Improved compliance ◆ Improved communication ◆ Improved system availability ◆ Reduction in liabilities

BUSINESS CASE FOR EXCHANGE SERVER 2007

E.2. Cost-Savings Examples Cash Flow Statement (three years) (in thousands of dollars) Year 0

Year 1

Year 2

Year 3

10-1-08

10-1-09

10-1-10

10-1-11

Hardware Purchase

60

Software Purchase

60

Contractor

40

Training

20

Maintenance

15

15

15

Spare Parts

5

5

5

Training of New Hires

2

2

2

Staff Education

3

3

3

Offsite Storage

5

5

5

210

30

30

71.5

79

87

100

220

220

65

171.5

299

307

(145000)

141500

269000

307000

Cost

Increased Sales

65

Labor Reduction Revenue/Savings

Cash Flow

F. Sensitivities, Risks, and Contingencies F.1. Sensitivity To realize $540,000 in labor savings over three years, the company must eliminate one IT position and two nontechnical positions (from orders and customer service). Revenue figures are based on projections prepared by the Sales Department and are subject to market forces.

F.2. Risks Specific risks involved in this project include: ◆ Inability to procure adequately skilled contractor labor adversely impacting schedule. ◆ Unforeseen changes in regulatory requirements that will have an adverse impact on the ability of the planned system to comply without additional expenditure for archiving, offsite storage or compliance-related software.

399

400

APPENDIX B

SAMPLE BUSINESS CASE PROPOSAL

F.3. Contingencies In the event that it is determined that the messaging solution is delayed beyond the scheduled implementation date, adequate trained personnel remain who can maintain the current Exchange Server 2000–based messaging system. In the event of a deployment failure, a copy of the then existent message store will be retained and able to provide a rollback to the previous system.

G. Conclusions and Recommendations G.1. Conclusions The only cost-effective solution to the many message system and business communication problems currently facing Oakland Playground Equipment is to adopt a robust implementation of an Exchange Server 2007–based messaging system. The first step is the deployment of Exchange Server 2007.

G.2. Recommendations This business case recommends deployment of an Exchange Server 2007–based messaging system. Purchase of necessary hardware, software, and identification of contractor personnel to begin immediately. Deployment of the new system is to take place no later than October 1, 2008.

Appendix C

Change Request Form This appendix is a template that you can use for a change request form in your organization.

CHANGE REQUEST FORM

Put company logo here

Organization name here

Change Request Form Project Name: Requestor: Date (MM/DD/YYYY): Control No. (from CR Log): 1. Requestor Information Fill in with appropriate information or place an “X” next to those that apply: Area of Change: Scope [ ]

Schedule [ ]

Budget [ ]

Quality [ ]

Proposed Change Description and References:

Other [ ]

Provide information below concerning the requested change. Create links to any supporting documentation.

Description: Justification: Hyperlinks:

Link_To_Supporting_Document

Impact of Not Implementing Proposed Change: Alternatives: 2. Initial Review Results of the Change Request (Project Manager Completes) Initial Assigned to: Review Date: (MM/DD/YYYY) Action Approve for Impact Analysis Reject Defer Until (MM/DD/YYYY) Express Approval

Comments [ ] [ ] [ ] [ ]

403

404

APPENDIX C

CHANGE REQUEST FORM

3. Impact Analysis (Project Manager Completes) Baselines Affected: Configuration Items Affected (e.g. product specifications): Cost / Schedule Impact Analysis Required? (check one)

Yes [ ]

No [ ]

Specific Requirements Definition: Additional Resource Requirements (insert rows as needed):

Work Days

Cost

Totals Impact on Cost: Impact on Schedule: Impact on Resources: Risk associated with implementing the change: Triple Constraints Impacted: Project Manager Recommendation: Signed:

Date: (MM/DD/YYYY)

4. Final Recommendation (Executive Sponsor/CCB completes) CCB Recommendation: Signed: (by Executive Sponsor CCB Chairman)

Date: (MM/DD/YYYY)

5. Disposition (Project Manager completes) Disposition: Approved [ ] Denied [ ] Requestor Notified by Included in Version/Date:

Date: (MM/DD/YYYY)

Appendix D

Operations Checklists Operations management involves the administration of an organization’s infrastructure components and includes the day-to-day administrative tasks, both planned and on-demand, that are required to keep an IT system operating smoothly. Typically, operations management tasks are covered by written procedures. These procedures provide all support staff with the same standard tools and methods. Several resources can help you define what standard procedures are required in your organization and how to perform them. Because each organization is unique, you will have to customize and adapt these resources to suit your requirements. Routine tasks that need to be performed can generally be separated into the following categories: ◆ Daily Tasks ◆ Weekly Tasks ◆ Monthly Tasks A fourth category, ‘‘As Needed Tasks,’’ is ad hoc. Checklists are useful to help make sure that the required tasks are performed at the appropriate time. Three of these are presented here, along with a summary checklist of the main headings. All should be adapted to meet your particular environment Each checklist and item should include the name of the person completing the task, the date, and where relevant, the time.

406

APPENDIX D OPERATIONS CHECKLISTS

Daily Operations Checklist Use these checklists to record daily operations. You can modify these checklists based on your organization’s requirements.

Physical Environmental Checks Use this checklist to ensure that physical environment checks are completed. Completed Task Verify that environmental conditions are tracked and maintained. Check temperature and humidity to ensure that environmental systems such as heating and air conditioning settings are within acceptable conditions and that they function within the hardware manufacturer’s specifications. Verify that physical security measures such as locks, dongles, and access codes have not been breached and that they function correctly. Ensure that your physical network and related hardware such as routers, switches, hubs, physical cables, and connectors are operational.

Check Backups Complete this checklist to check backups. Completed Task Make sure that the recommended minimum backup strategy of a daily online backup is completed. Verify that the previous backup operation completed. Analyze and respond to errors and warnings during the backup operation. Follow the established procedure for tape rotation, labeling, and storage. Verify that the transaction logs were successfully purged (if your backup type is purging logs). Make sure that backups complete under service level agreements (SLAs).

Check CPU and Memory Use Use this checklist to record the sampling time of each counter. Completed Task Examine % Processor Time performance counter. Examine Available MBs performance counter. Examine % Committed Bytes in Use performance counter. Check against a performance baseline to determine the health of a server.

DAILY OPERATIONS CHECKLIST

Counter

Measured value

Time when recorded

% Processor Time Available MBs % Committed Bytes in Use

Check Disk Use Follow the checklist and record the drive letter, designation, and available disk space. Completed Task Create a list of all drives and label them in three categories: drives with transaction logs, drives with queues, and other drives. Check disks with transaction log files. Check disks with SMTP queues. Check other disks. Use server monitors to check free disk space. Check performance on disks. Drive Letter

Designation (drives with transaction logs, drives with queues, and other drives)

Available space Available % MB free

Your data here Your data here Your data here

Check Event Logs Check event logs using the following checklist. Completed Task Filter application and system logs on the Exchange server to see all errors. Filter application and system logs on the Exchange server to see all warnings. Note repetitive warning and error logs. Respond to discovered failures and problems.

407

408

APPENDIX D OPERATIONS CHECKLISTS

Check IIS Logs and Performance Complete this checklist to check IIS logs and performance, as well as the status of services such as POP3 and IMAP. Completed Task Examine event log and filter. IIS logs give you information about your changes. (Note: if the organization is medium-sized, do this weekly rather than daily.) Examine System Monitor for IIS performance to examine the output of performance counters. Examine Web Service counters to monitor the World Wide Web Publishing Service (WWW service). Examine Web Service Cache counters to monitor the WWW service cache. Examine FTP Service counters to monitor the File Transfer Protocol (FTP) service. Examine Active Server Pages counters to monitor applications that run as Active Server Pages (ASPs).

Exchange Database Use this checklist for to verify health of your Exchange database. Completed Task Check the number of transaction logs generated since the last check. Is the number increasing at the ‘‘usual’’ rate? Verify that databases are mounted. Make sure that public folder replication is up to date. If full-text indexing is enabled, verify that indexes are up to date. With test mailbox, verify the logon of each database and the send/receive capabilities.

MAPI Client Performance Complete the checklist to verify MAPI client performance and server availability. Completed Task Examine System Monitor counters. Examine Event Viewer logs. Verify that a test account can log on to the Exchange server and has send/receive capabilities. Verify your Perfmon RPC counters against a baseline — RPC average latency/RPC requests/RPC operations.

DAILY OPERATIONS CHECKLIST

Check Queue Viewer Follow the checklist and record the size of each queue. Completed

Task Check queues for each server in each administrative group using the Queue Viewer tool in the Exchange Management Console. Record queue size.

Queue type

Queue size

Your data here Your data here Your data here

Message Paths and Mail Flow Use this checklist to examine the message paths and mail flow in your organization. Completed

Task Send messages between internal servers using test accounts. Check and verify that messages deliver successfully. Send outgoing messages to nonlocal accounts. Check and verify that outgoing messages are delivered successfully. With the test account on the external host, verify that mail comes in. Send messages across any connectors to Exchange 5.5 organizations, Lotus Notes, and Novell GroupWise recipients. Verify successful message transfer across connectors and routes.

Checklist: Security Logs To effectively correct known and discovered security issues, complete the following checklist. Completed

Task View the security event log on Event Viewer and match security changes to known, authorized configuration changes. Investigate unauthorized security changes discovered in security event log. Check security news for latest virus, worm, and vulnerabilities. Update and fix discovered security problems and vulnerabilities. Verify that SMTP does not relay anonymously, or lock down to specific servers that require functionality. Verify that the Message Tracking Log does not have the Everyone group listed in the ACL permission. You can also do this task weekly. Verify that SSL is functioning for configured secure channels. Update virus signatures daily.

409

410

APPENDIX D OPERATIONS CHECKLISTS

Weekly Operations Checklist Use these checklists to record weekly operations. You can modify these checklists based on your organization’s requirements.

Create Reports Use this checklist to create status reports to help with capacity planning, service level agreement (SLAs) reviews, and performance analysis. Completed

Task Use daily data from event log and System Monitor to create reports. Report on disk usage. Create reports on memory and CPU usage. Generate uptime and availability reports. Generate database and mailbox sizes. Create capacity reports from messages sent and client logons. Create reports on queue use, size, and growth.

Incident Reports Use this checklist to create incident reports. Completed

Task List the top generated, resolved, and pending incidents. Create solutions for unresolved incidents. Update reports to include new trouble tickets. Create a document depository for troubleshooting guides and postmortems about outages.

Antivirus Defense Use this checklist to perform your antivirus defense. Completed

Task Perform a virus scan on each computer; however, exclude drives that are specifically for Exchange (SMTP/Exchange Databases/Logs, and so on).

Status Meeting Use this checklist to conduct weekly status meetings during which the tasks are reviewed. Completed

Task Server and network status for the overall organization and segments. Organizational performance and availability. Overview reports and incidents. Risk analysis and evaluation, including upcoming changes. Capacity, availability, and performance reviews. Service level agreement (SLA) performance, and review items that have not met target objectives.

MONTHLY OPERATIONS CHECKLIST

Monthly Operations Checklist Use these checklists to record monthly operations. You can modify these checklists based on your organization’s requirements.

Capacity Planning Use this checklist for capacity planning. Completed Task Check capacity and performance against service level agreement (SLA) requirements. Review SLA requirements and capacity figures from previous month. Produce and implement upgrade path based on projected growth from previous growth data.

Hot fixes, Service Packs, Update Rollups, and Security Updates Use this checklist to update your systems with hot fixes, service packs, update rollups, and security updates in your organization. Completed Task Maintain a list of applied hot fixes, service packs, update rollups, and security updates. See if there are new hot fixes for Microsoft Windows Server. See if there are service packs for Windows Server. See if there are updates to complementary services such as Internet Information Services (IIS), Active Directory directory service, and the DNS server. Apply updates uniformly across servers and workstations in the organization. Perform critical security updates as soon as possible, based on company policy.

411

412

APPENDIX D OPERATIONS CHECKLISTS

Summary Checklist This checklist provides you with a summary of Exchange Server 2007 operations tasks on a daily, weekly, and monthly basis. You should modify these checklists based on your organization’s requirements. Completed Daily Tasks Check of physical environment. Check backups. Check CPU/memory use. Check disk use. Examine message queues. Examine event logs. Check backups. Check Internet Information Service (IIS) performance. Check Exchange Server database health. Check MAPI client performance. Check Queue Viewer. Check message paths and mail flow. Check non–Exchange Server connectors. Check security logs. Update virus definitions and scan for viruses. Verify that Exchange Server and required Microsoft Windows services have started correctly. Completed Weekly Create reports. Complete incident reports. Meet to discuss status. Check IIS logs. Completed Monthly Do capacity planning. Perform hot fixes, service packs, update rollups, and security updates. Perform disaster recovery test; test one backup a month by restoring it.

Appendix E

Lessons Learned Meeting Agenda The only way to avoid problems happening yet again in the future is to carefully consider what went wrong and why, and make sure that there is a way to transfer related recommendations forward. Likewise, teams can help others repeat their successes only if they somehow can express concretely what went well, and why. The specific lessons and recommendations generated in this kind of meeting will yield concrete actions for other teams. This agenda is also useful for interim lessons learned meetings. Some teams have such meetings at the end of each major project phase to capture lessons before the team moves on and forgets the lessons learned so far.

How to Use This Example 1. Edit the example agenda subjects to reflect any specific areas that your meeting should cover.

2. Adjust the timeslots for a longer or shorter meeting, depending on your project and how much discussion you think will be needed.

3. Adjust the attendee list to include specific names and their departments/functional groups, to help ensure that you’re inviting everyone that should be there.

4. Allow enough time ahead of the meeting to allow the project manager and others to gather or compile information for reference. For example, during the first part of the meeting, the team reviews the original planned major milestone dates vs. the dates those milestones were actually achieved. That information should be brought to the meeting rather than creating it from memory on the spot.

5. Send out the agenda, with appropriate statements about the importance of attendance by all invitees and expectations about ‘‘tone’’ and spirit of the meeting. (Specifically, lessons learned meetings must be objective and professional — no ‘‘blame games’’ allowed.)

414

APPENDIX E LESSONS LEARNED MEETING AGENDA

Example Agenda for a Lessons Learned Meeting Oakland Playground Equipment Exchange Server 2007–based Messaging System Project Lessons Learned Meeting 1:30 p.m. to 4:00 p.m. November 21, 2008

Attendees ◆ Project manager and project team members ◆ Executive sponsor ◆ Other key players and those specifically invited by the project manager or executive sponsor

Meeting Objectives

1. Understand how this project performed against its original goals (time, resources/costs, scope) 2. Identify ‘‘lessons learned’’ and recommendations for future projects 3. Take steps to ensure these lessons learned are considered for future projects Deliverables from Meeting ◆ Full report including: ◆

Review and analysis of plan vs. actual milestone achievement; what was delivered vs. the original scope and requirements

◆

List of successes and problems

◆

List of recommendations for achieving the successes while avoiding problems during future projects

◆ Templates and checklists for use during future projects. Agenda Item

Facilitator(s) Time

Introduction, agenda review, ground rules

Kim W.

15 min

Successes and Problems. Project review: Review the planned vs. actual results at major milestones and final release. Brainstorming: Each participant will take turns providing a success or problem until no one else has items to add. Major project issues: Which problems contributed most to milestone and vision shortfalls? Which successes contributed most to what the project accomplished?

Karen L.

60 min

Break

10 min

Create lessons learned recommendations. Successes: what do other projects need to do to achieve these wins? Challenges: how should future projects avoid each issue we identified?

Kim W.

15 hr

Next steps. Discuss how lessons learned recommendations will be used for future projects. Review action items and finalize assignments.

Neil E.

20 min

Index Note to the Reader: Throughout this index boldfaced page numbers indicate primary discussions of a topic. Italicized page numbers indicate illustrations.

A A/C privileged message classification, 105 Accepted Domains tab, 269–270 accidental breach of confidentiality disclaimers, 106 accountant services for consulting businesses, 376 Achievable characteristic in SMART, 54 action plans for troubleshooting,

357–358

Action tab, 348 actionable items from high-level goals,

37–38

Active Directory (AD), 90–91 backups, 318 in deployment, 245 DNS, 95 domains authoritative, 268–270, 269 design, 94, 94 new organizations, 251 forests design, 93–94 Large Organization model deployment, 250 mailbox moves across,

281–283

mailbox moves within,

280–281

new organizations, 251 Standard Organization model deployment, 249 hardware requirements, 95–96 schema preparation, 92 site and replication topology,

94–95

transitioning settings, 254 with Unified Messaging servers 141, 146 uses, 91–92 ActiveSync Client Access server considerations, 123–124 deployment, 277–278 postinstallation tasks, 273 activities in planning, 62 Add Counters dialog box, 347–349,

347

Add Nodes Wizard, 334–335 added-value criteria, 207 address rewriting, 129–132

AdminDisplayVersion property, 85 administration Security Configuration Wizard options, 271 Unified Messaging servers for, 141 advisory skills for consulting,

365–370

agreement as change resistance tactic, 189 alerts, 347–349 aligning IT with business values, 4–5 objectives, 157 AllowMerge parameter, 282–284 alternate server recovery method, 324 alternative solutions in business cases,

168

analyses in business cases, 167–168, 170–172, 399–400 organizational structures, 27–34,

28–31

analytical skills for change management, 197 Analyzing Configuration page, 333 antispam features Edge Transport servers, 126,

132–134

Hub Transport serves, 267 antivirus (AV) features checking, 410 Edge Transport servers, 126,

132–134

application logs Event Viewer, 341, 341 in installation, 267 monitoring, 358 appreciation, expressing, 17, 65 archiving. See mail archiving ‘‘as-is’’ analysis, 47 ‘‘as needed’’ messaging system tasks, 343–345, 344 assumptions in business cases, 157, 159, 162 in scope statements, 57, 69–70 ‘‘attachment removed’’ message classifications, 105 attorney/client privileged message classification, 105 audience issues for presentations, 178 audit policies, 271 auditory learners, 215

Authoritative Domain. Email is delivered to a recipient option, 269 authoritative domains, 268–270, 269 auto-attendant, 146 autocratic management style, 32 Autodiscover service, 278 availability, 326 CCR, 327, 327, 333–336,

333–334

LCR, 326–332, 327, 329,

331–332

SCR, 327–328, 328, 336–338, 338 Unified Messaging servers, 144

B

background in business cases, 162 backups, 318–319 checking, 406 messaging records management, 99 methods, 320 monitoring, 340 operations, 319–320 restoring, 321–322 third-party, 324 in troubleshooting, 353 balancing needs in scope determinations, 56, 56 Bank of America, 110 bank robber case, 61–62 banker services for consulting businesses, 376 Basel II, 44 baselines ExBPA scans, 304 implementation schedules, 74 performance, 344 in troubleshooting, 353–354 basic deployment checks, 243–247 Bay of Pigs invasion, 11–12 bedside manner, 366 benchmarks. See objectives benefits in business case proposals, 157–158, 168–170, 398 Benne, Kenneth, 199 Bennis, Warren, 199 Berra, Yogi, 301 bidirectional address rewriting, 132 biographical sketches, 377 blogs for marketing, 382–383 body of knowledge for change management, 183

416

BOOKKEEPER SERVICES

•

COMFORT LEVELS FOR OUTSOURCED SERVICES

bookkeeper services, 377 boundaries in business case, 163–164 Branch Office business model, 27 breach of confidentiality disclaimers, 106 brick-level backups, 324 ‘‘bring me a rock’’ school of leadership, 18–19 budgets, 8 in planning, 62 in statements of work, 70 Building the IT Consulting Practice (Freedman), 373 builds, 85–86 Bush, George W., arrogance of, 196 business cases, 155–156 benefits, 157–158, 168–170, 398 conclusions and recommendations, 174, 400 contingencies, 158, 174, 400 cost-benefit analyses, 170–172,

399–400

costs, 157–158, 166–168,

397–398

double-checking, 174–175 executive summaries, 161, 395 introduction, 162–163, 395–396 making, 156–158 methods, 163–166, 396–397 nonfinancial purposes, 163 overview, 156 presenting, 175–178 return on investment, 171–172 risks, 158, 173–174, 400 sensitivities, 158, 173, 400 summary, 178–179 supplemental documentation, 175 template, 160–161 tips and hints, 158–159 business-oriented approach, 1 business value, 3–7 development, 2–3 nontechnical managers, 7–9 project team management. See project teams summary, 19 business requirements, 21–22 actionable items, 37–38 analyzing, 22–23 confirming, 39–40 current business model, 23 company model and geographic scope, 27 organizational structures, 27–34, 28–31 processes, 23–26 data flow diagrams, 42, 43 dependencies identification,

40–42

determining, 33 gap analysis, 47–48 growth forecasting and planning,

45–46

information sources, 35–36 messaging, 44–45 personnel and training assessment, 42–43 priorities, 36 regulatory, 43–44 risk management, 39 stakeholder interviews, 37 summary, 48 system features, 34–35, 35 business skills change management, 199 consulting, 371–372 business value, 3–7

C call notification, 145 CALs (client access licenses), 85,

103–104

capacity disk, 87–88 Edge Transport servers, 128 planning, 343, 411 Carr, Nicholas, 3 case study for change management process, 236–238, 237 Castro, Fidel, 11 CBAM (Concerns-Based Adoption Model), 192–193 CCR (cluster continuous replication), 138–139, 325, 327, 327, 333 failover clusters, 333–336,

333–334

multiple server roles, 149 change control boards, 227–228 change curve, 184, 184 change management, 181 analytical skills, 197 business skills, 199 change agent overview, 195–196 changes in adopting, 191–195, 194 obstacles, 187–190 principles, 183–187, 184, 186, 190–191, 190 stopping, 236 defined, 182–183 empirical-rational strategy,

199–200

environmental-adaptive strategy,

201–202

guidelines, 296 implementation, 294–295 normative-reeducative strategy,

200–201

overview, 182 people skills, 197–199 political skills, 196–197 power-coercive strategy, 201 in SLAs, 117 strategy selection, 203 success indicators, 297

summary, 203–204 system skills, 199 in troubleshooting, 353 Change or Remove Programs page Exchange Server removal, 290 server roles, 288 change request processes, 221 authority for, 224–225, 224 building, 222–223 case study, 236–238, 237 cause analysis, 232 change request form template,

401–403

decisions, 227–229 delegating tasks, 231–232 after deployment, 238–239 determinants, 223, 224 disruptions, 231–232 documentation, 233, 234 enforcing, 233–235, 295 evaluating requests, 226 impact determination, 226–227 notifications and follow-up,

229–230

overview, 222 receiving requests, 225–226 summary, 239 summing required work, 226 triple constraints, 223, 224, 227,

229–230

channels in Unified Messaging servers, 147 Chin, Robert, 199 classifications for messages, 105–106 client access licenses (CALs), 85,

103–104

Client Access servers (CAS), 122–125,

123

new organizations, 251 postinstallation tasks, 273–275 ratios, 151–152 setup, 261, 265 sizing, 148 transitioning, 255 client features, SCW for, 271 Client Service Location (CSL) Large Organization model deployment, 250 Standard Organization model deployment, 249 Client Settings page, 263, 263 clothing for presentations, 177 cluster continuous replication (CCR), 325, 327, 327, 333 failover clusters, 333–336,

333–334

multiple server roles, 149 Cluster Service Account page, 334–335 clustered mailbox servers, 338 clusters, failover, 333–336, 333–334 comfort levels for outsourced services,

118–119

COMMUNICATION

communication, 9 business processes, 25 consulting skills, 372–373 nontechnical managers, 7–8 project team management, 14–15 system features, 34–35, 35 tips, 212 for user expectations, 209–212 communication ports in Edge Transport servers, 129–130 company confidential message classification, 105 company internal message classification, 105 company models analyzing, 27 selecting, 247–250, 247 company politics, 33–34 Completion page authoritative domains, 269–270 Exchange Server removal, 290 mailbox moves, 280 server roles, 288–289 Setup Wizard, 264 Complex organization model deployment, 250 compliance, 96 disclaimers, 106–109 Exchange Hosted Services, 104 journaling, 101–103, 102 laws, 96–97 licensing, 103–104 mail archiving, 111–112 managed folders, 100–101 message classifications, 105–106 messaging records management,

98–99

regulatory requirements, 43–44 transport rules, 99–100, 101 computing environment improvements, 358 Concerns-Based Adoption Model (CBAM), 192–193 conclusions in business cases, 174,

400

confidentiality breaches disclaimers, 106 confidentiality requirements, 97 configuration management, 183 configuration tools, 302–304, 303 conformity in group think, 11 confusion as change resistance tactic, 188 Connectivity Test scans, 304 consolidation address rewriting for, 130–131 Unified Messaging servers for, 141 constraints change request processes, 223, 224, 227, 229–230 scope statements, 55, 57 consulting, 361 advisory skills, 365–370

•

DEPARTMENT OF JUSTICE ORGANIZATION CHART

business skills, 371–372 communication skills, 372–373 finances, 374–377 free experience, 373 functions, 362 marketing, 377–383 overview, 361–362 personality for, 363–364 professional conduct, 383–384 starting, 373–374 success factors, 362–363 summary, 384–385 technical skills, 370–371 contacts in SLAs, 117 Content Filter agent, 133–134 contingencies in business cases, 158, 174, 400 contingency time in implementation schedules, 74 continuous replication, 138–139,

325–326

CCR, 325, 327, 327, 333 failover clusters, 333–336,

333–334

multiple server roles, 149 LCR, 325–326, 328 memory recommendations, 151 processor recommendations, 149 storage groups, 328–329,

329

transport dumpster configuration, 331–332,

332

monitoring, 345–346 new feature, 79 SCR, 325, 327–328, 328 Mailbox servers, 138–139 managing, 336–337 new feature, 79 contract termination procedures in SLAs, 117 control change management, 183 need for, 185 and ownership, 32 Control Panel, 284–288, 287 Cooley, Mason, 205 copy backups, 319 copying transaction logs, 326 cost reductions, Unified Messaging servers for, 141 cost-savings examples in business cases, 171 costs in business cases, 157–158, 166–168, 170–172, 397–400 discovery, 110–111 CPU utilization tracking, 348–349, 406–407 Creating the Cluster page, 334 critical success factors, 36

criticism in change resistance, 188 CSL (Client Service Location) Large Organization model deployment, 250 Standard Organization model deployment, 249 Cuban missile crisis, 12 cultural resistance to change, 187 Custom Server Installation option, 262 Customer Feedback page, 261, 261 customer relationships, 33

D

daily messaging system tasks, 339 backups monitoring, 340 checklist, 406–409 disk space checks, 340 Event Viewer checks, 341, 341 network performance monitoring,

342–343

operating system monitoring, 342 physical environment, 340 server performance monitoring,

342

Darwin, Charles, 221 data flow diagrams (DFDs), 42, 43 data processing centers, 2 data protection, 315–316 data retention. See compliance Database Portability option, 322 Database Recovery Management tool, 304–305, 305 Database Troubleshooter tool,

305–306

databases backups, 318 checking, 408 LCRs, 330–331, 330 recovering, 304–306, 305, 323 deadlines, user expectations for, 206 decentralized business unit organizational structure, 30, 30 decisions business processes, 26 change request processes,

227–229

deflection as change resistance tactic, 189 degree of change factor, 203 delayed fan-out, 91 delays, procurement, 68 delegating change management tasks,

231–232

Deleted items folder, 98 Deming, W. Edwards Out of the Crisis, 371 quoted, 181 denial as change resistance tactic, 189 denial-of-service (DoS) attacks, 309 Department of Justice organization chart, 28, 28

417

418

DEPENDENCIES

•

EVENTTRIGGERS.EXE TOOL

dependencies in change management, 203 identifying, 40–42 implementation schedules, 74 deployment, 241 basic checks, 243–247 change management implementation, 294–297 Edge Transport servers, 134–135,

135

Exchange Server removal,

290–292

installation modifying, 285–287, 287 with Service Pack 1, 258–266, 259–264 verification, 266–268, 266 last Exchange Server removal,

292–294

lessons learned, 297–299 mail archiving, 113–114 mailbox moves. See moving mailboxes migration, 256–257 new organizations, 250–252 organization model selection, 247–250, 247 postinstallation tasks. See postinstallation tasks server modification and removal,

284

server roles removal, 287–289 summary, 299 tips, 257–258 transitioning, 252–256, 253 Unified Messaging servers,

146–147

upgrading, 241–243 deployment team communication, 211 design documents, 70–71 design decisions, 71 disaster recovery options, 71–72 structure, 72–73 designer services for consulting businesses, 376 details business case presentations, 178 requirements, 22 Details Templates Editor, 304 detect model, 351–352, 351 plan execution, 355–356 problem discovery, 352 problem symptoms, 352–354 solution testing, 355 system history review, 354–355 Deutsche Bank Securities Inc., 111 Device Manager, 354 dial tone portability, 323 die-on-the-vine strategy, 202 differential backups, 319–320 diplomacy in team management,

14–15

Direct Push mechanism with firewalls, 277 direction in team management, 18–19 Disable-StorageGroupCopy cmdlet, 336 disaster recovery, 314–315 backups, 318–320 continuous replication, 325–326 data protection, 315–318 design documents options, 71–72 mailbox server failures, 322–323 mailboxes and individual items,

deployment requirements, 134–135, 135 Edge Subscription considerations,

restores, 320–321 scenarios, 316–317 single and multiple database failures, 323 storage group recovery, 324–325 testing, 343 tools, 304–307, 305 discipline in team management,

setup, 261, 265 topology considerations,

324

12–13

disclaimers, 106–109 discovery costs, 110–111 judicial, 111–112 requests, 97 disk storage requirements, 87–90 usage tracking, 340, 349–350, 407 disruptions in change request processes, 231–232 documentation change management processes, 233, 234, 358 troubleshooting, 357–358 Domain Name System (DNS), 95 authoritative domains, 269 in deployment, 246 new organizations, 251 domains, Active Directory authoritative, 268–270, 269 design, 94, 94 new organizations, 251 DoS (denial-of-service) attacks, 309 Drucker, Peter, Management, 371

E E-mail Addresses tab, 279 E-mail Addresses (Policy) tab, 294 early adopters of change, 194 early majority adopters of change,

194–195

easy agreement as change resistance tactic, 189 Edge Subscriptions, 128–129 Edge Transport servers, 125–127, 126 address rewriting, 129–132 agents, 268 antispam and antivirus features,

132–134

authoritative domain configuration, 270

128–129 existing Exchange 2003 organizations, 136–137 new organizations, 251 postinstallation tasks, 274–275 ratios, 152 security, 129–130, 135, 135 server capacity considerations,

128 127–128 transitioning, 255 transport features, 128 version mismatches, 85–86 Edison, Thomas A., 121 edition considerations, 84 education for user expectations,

213–219 Eisenhower, Dwight D., 244–245 email archiving. See mail archiving email loops, 309 empirical-rational change strategy,

199–200 employee, starting consulting as, 373 employee productivity, 141–142 Enable-StorageGroupCopy cmdlet, 336 End-to-End Scenario tab, 274–275 enforcing change management processes, 233–235, 295 Enter Product Key Wizard, 272 entering into contracts, disclaimers for, 106 Enterprise Voice, 145 environment settings in transitioning, 252–254, 253 environmental-adaptive change strategy, 201–202 environmental checks, 240, 406 equipment consulting, 375–376 in SLAs, 118 error messages in troubleshooting, 352–353 ESRP (Exchange Solution Reviewed Program), 310 ethical walls, 97 ethics, 383–384 European Union Data Protection Directive (EUDPD), 97 Event Comb tool, 341 Event Viewer checking, 341, 341, 407 in installation, 267 in troubleshooting, 353 Eventtriggers.exe tool, 341

EXCHANGE 2000 FEATURES REMOVED AND NOT SUPPORTED

Exchange 2000 features removed and not supported, 292 Exchange ActiveSync Client Access server considerations, 123–124 deployment, 277–278 postinstallation tasks, 273 Exchange continuous replication (ECR). See continuous replication Exchange database checking, 408 Exchange Enterprise CALs, 104 Exchange Hosted Services, 104 Exchange Load Generator, 90 Exchange Maintenance Mode page Exchange Server removal, 290–291 server roles, 286, 288–289 Exchange Management Console authoritative domains, 269–270,

269 LCR, 328–332

mailbox moves, 280 postinstallation tasks, 272–275,

272–273

storage groups, 329 Exchange Management Shell authoritative domains, 270 mailbox moves, 281–283 storage groups, 329 Exchange Organization page, 263 Exchange Server 2007 Setup Wizard, 258–264, 259–264 Exchange Server Best Practices Analyzer (ExBPA) tool organizational analysis, 247 overview, 302–304, 303 postinstallation tasks, 272–273,

273

transitioning readiness checks, 252 Exchange Server Database Utilities (Eseutil.exe) tool, 306–307 Exchange Server Stress and Performance (ESP) tool, 90,

313–314

Exchange Server System Monitor, 347 Exchange Server User Monitor (ExMon), 313 Exchange Standard CALs, 104 Exchange Troubleshooting Assistant (ExTrA), 311–312, 312 Exchange View Only administrators group, 266 ExchangeSetup.log file, 267 ExchangeVersion property, 86 executive summaries in business cases, 161, 395 expectations business case presentations, 178 change management, 186 user. See user expectations expenses, consulting, 374 expertise factor in change management, 203 exposure factor in risk, 70

ExSetup program, 284 Extensible Storage Engine (ESE), 306, 323 external dependencies, 40–42

•

HIGH AVAILABILITY

functional organizational structure, 29,

29

fund sources, 374–375

G

F

failed felon case, 61–62 failover clusters, 333–336, 333–334 families as revenue source, 375 fan-out, delayed, 91 fear issues in change management,

186–187

features removed and not supported, 292 in trade-off triangle, 56, 56 filters, antispam and antivirus,

132–133

Finalize Deployment tab, 272–274,

272–273

finances consulting businesses, 374–377 in SLAs, 117 Financial Institution Privacy Protection Act, 97 financial models in business case,

166–167

Financial Modernization Act, 97 financial projections in business cases,

170–171

firewalls, Direct Push with, 277 firmware revisions, 354–355 fiscal responsibility, 5–6 focus groups, 38 folders deleted items, 98 managed, 100–101 public. See public folders follow-up in change request processes,

229–230

Forefront Security product, 273 forests, Active Directory design, 93–94 Large Organization model deployment, 250 mailbox moves across, 281–283 mailbox moves within, 280–281 new organizations, 251 Standard Organization model deployment, 249 formal power, 196 FQDNs (fully qualified domain names), 269 Franklin, Aretha, 16 Franklin, Benjamin, 49 free work, 379–380 Freedman, Rick, Building the IT Consulting Practice, 373 Friedman, Milton, 1 frivolous change requests, 232 full backups, 319 full server recovery, 322 fully qualified domain names (FQDNs), 269

Gainer, Jeff, 208 Gantt, Henry Laurence, 68 Gantt Charts, 68, 73–74 gathering information in troubleshooting, 352 General System Theory, 199 General tab for alerts, 347, 349 geographic organizational structure, 30, 30 geographic scope analysis, 27 geographical factors in scope statements, 55 Get-ExchangeServer cmdlet, 86, 266 Get-SetupLog.ps14 script, 267 Get-StorageGroupCopyStatus cmdlet, 337 Get-TransportConfig cmdlet, 332 Getting Started in Consulting (Weiss), 373 global catalog (GC) server placement,

95–96

Global Settings tab, 332 global thermonuclear war case, 230 goals actionable items from, 37–38 in change management, 187 in planning, 62–65 priorities, 36 project team, 16, 389 in scope statements, 55, 67 Goldman Sachs & Co., 111 Gramm-Leach-Bliley Act, 44, 97 group consolidation, address rewriting for, 130–131 group think, 11–12 growth, forecasting and planning,

45–46

H hard benefits in business case, 169 hardware Active Directory, 95–96 deployment, 245 problems, 316, 355 procurement delays, 68 requirements, 81–82 storage technology, 88–89 hardware-based snapshot backup sets,

323

Health Check scans, 304 Health Insurance Portability and Accountability Act (HIPAA), 44, 97 Heinlein, Robert A., 361, 371 helicopters case, 41–42 high availability, 326 CCR, 327, 327, 333–336,

333–334

419

420

HIGH AVAILABILITY

•

MAGAZINES FOR BUSINESS INFORMATION

LCR, 326–332, 327, 329,

331–332 SCR, 327–328, 328, 336–338, 338 Unified Messaging servers, 144

HIV letter, 296–297 Hoare, Charles Anthony Richard, 77 home equity loans as revenue source, 374 honesty business cases, 159 communication, 212 hosted solutions for mail archiving,

114

hot fixes, checking, 411 Howser, Dick, 364 Hub Transport servers, 137 Active Directory for, 91 agents, 267 mail flow, 100, 101 new organizations, 251–252 postinstallation tasks, 274–275 ratios, 151–152 setup, 261, 265 transport dumpster, 331–332,

332

humor in presentations, 178 Hunt Group objects, 146

I

IBM Olympic game systems, 235 IIS log and performance checking, 407–408 image products, 378 IMAP4 considerations, 124 immediate criticism in change resistance, 188 impact determination change request processes,

226–227

risk, 70 implementation documents, 73 plans, 74–75 schedules, 73–74 implementation plans, 50 in-house services archiving, 114 vs. outsourced, 114–115 in-place upgrades, 81, 242–243, 248, 252, 257, 278 incentives for change, 188 incident reports, 410 inclusion, need for, 185 incompatible software, 353 incremental backups, 319 individual mailbox recovery, 324 Industrial Revolution, 208 ineffective organizational structures,

31

informal power, 196–197 information flow in business processes, 24–25 information source identification,

35–36

Information Store Integrity Checker (Isinteg.exe), 306–307, 345 infrastructure requirements, 21, 82–83 innovators and change, 194 inputs in planning process, 60 InstallAntiSpamAgents.ps1 script, 267 installation deployment. See deployment modifying, 285–287, 287 with Service Pack 1, 258–266,

259–264 verifying, 266–268, 266

installation paths, 80 Installation Type page, 261, 261 insurance agent services for consulting businesses, 376 intangible benefits in business cases,

169–170

integrity in consulting, 383 interim objectives in planning, 65 internal dependencies, 40–42 Internal Revenue Service (IRS) image, 198 International business model, 27 Internet for business information, 372 Internet mail flow in Exchange Server removal, 293 interoperability in Lotus Notes migration, 256–257 interpersonal relationships in team effectiveness, 392 Introduction page mailbox moves, 280 Setup Wizard, 260 introduction sections in business cases, 162–163, 395–396 investors as revenue source, 375 IP Address page, 334 IP Gateway objects, 146–147 IPv6 receive connectors, 133 IRS (Internal Revenue Service) image, 198 isolating problems, 355 Israel, Shel, Naked Conversations, 382

J Jaikumar, Jai, 3 Janis, Irving L., 11–12 jargon, 8 Jetstress tool, 90, 310 Johnson, Lyndon B., 187, 233 journaling, 98, 101–103, 102 judicial discovery, 111–112

K Kauffman, Ewing, 364 Kennedy, John F., 11–12 Kennedy, Robert, 12 kinesthetic learners, 216 knowledge control, archiving for, 113 Krekeler, John, 7

L laggards in change adoption, 195 Lambert-St. Louis International Airport runway, 6–7 Land Rover case, 39–40 Large Organization model deployment, 249–250 Larson, Elliott, 205 last legacy Exchange Server removal,

292–294

late majority adopters of change, 195 lawyer services for consulting businesses, 376 LCR. See local continuous replication (LCR) League of Nations, 181 learning styles, 215–216 Lebow, Rob, 377 legacy streaming backups and restores, 320 legal issues. See compliance lessons learned deployment, 297–299 meeting agenda, 413 Lewin, Kurt, 190 libraries for business information, 371 License Agreement page, 260, 260 licensing compliance features, 103–104 considerations, 84–85 in installation, 260, 260 lifetimes in business processes, 25–26 lines of credit, 374 listening skills for team management, 17 Load Generator utility, 311 loans, home equity, 374 local continuous replication (LCR), 138–139, 325–328 databases and public folders, 330–331, 330 memory recommendations, 151 new feature, 79 processor recommendations, 149 storage groups, 328–329, 329 transport dumpster configuration, 331–332, 332 logical unit numbers (LUNs), 87 logs checking, 407–409 Event Viewer, 341, 341 installation, 267 monitoring, 342, 347, 358 transaction, 326 in troubleshooting, 353 London Post, 202 loss curve for changes, 185–186, 186 Lotus Notes, migration from, 256–257 lowest-cost routes, 91–92

M magazines for business information, 371

MAIL ARCHIVING

mail archiving, 102, 109–110 for compliance, 111–112 deploying, 113–114 for discovery process, 110–112 for knowledge control, 113 for performance, 113 planning considerations, 113 storage management, 112 mail flow checking, 409 tools, 307–310, 308 Mail Flow Troubleshooter tool, 308,

308

Mailbox Manager Settings (Policy) tab, 294 Mailbox servers, 137–139, 138 failure recovery, 322–323 memory considerations, 150–151 new organizations, 251–252 postinstallation tasks, 273–275 ratios, 151–152 setup, 261, 265 sizing, 149 mailboxes databases for LCR, 330–331, 330 housekeeping tasks, 343, 344 merging, 283–284 moving. See moving mailboxes recovering, 324 size calculations, 88 Majority Node Set quorum, 335 malicious compliance as change resistance, 189 malpractice suits, 366 man-made disasters, 316 managed folders, 100–101 Management (Drucker), 371 management information systems (MISs), 2 management models, 32 management of change (MOC). See change request processes MAPI Client performance checking, 408 marketing for consulting, 377 blogs, 382–383 free work, 379–380 image products, 378 media kits, 377–378 networking, 379 newsletters, 381–382 passive, 380 public speaking, 381 writing and publishing, 380–381 Masefield, John, 65 matrix organizational structure, 29,

29

Maurer, Rick, 188 MaxDumpsterSizePerStorageGroup parameter, 331 MaxDumpsterTime parameter, 331 Measurable characteristic in SMART, 54

measurements in business cases, 159 team effectiveness, 387–392 media kits, 377–378 meetings lessons learned, 298, 413 project team management, 13–14 scope statement validation, 58–59 status, 210 memory server roles, 149–151 usage tracking, 347–348, 347, 406–407 mergers and acquisitions, address rewriting for, 131 merging mailboxes, 283–284 Message Tracking tool, 309 messages classifications, 105–106 path checking, 409 messaging records management (MRM), 98–99 messaging requirements, 44–45 messaging system management,

338–339

‘‘as needed’’ tasks, 343–345, 344 continuous replication monitoring, 345–346 daily tasks, 339–343, 341 monthly tasks, 343 weekly tasks, 343 methods in business case, 163–166,

396–397

Microsoft Exchange Server Best Practices Analyzer Tool (ExBPA) organizational analysis, 247 overview, 302–304, 303 postinstallation tasks, 272–273,

273

transitioning readiness checks, 252 Microsoft Identity Integration Server (MIIS), 250 Microsoft Operations Manager (MOM), 340–341 migration, 242–243 from Exchange Server 5.5, 257 from Lotus Notes, 256–257 mailbox moves, 278 milestones. See objectives mindguards in group think, 11 MISs (management information systems), 2 missile attack case, 230 missile crisis, 12 misstatements, disclaimers for, 106–107 mobile devices, 277 MOC (management of change). See change request processes moderate resistance to change, 188 modifying installation, 285–287, 287 servers, 284

•

NETWORKS

module size for server role memory, 149 MOM (Microsoft Operations Manager), 340–341 monitoring backups, 340 continuous replication, 345–346 logs, 342, 347, 358 network performance, 342–343 operating system, 342 server performance, 342 monthly consulting expenses, 374 monthly operations checklist, 411 messaging system tasks, 343 morality in group think, 11 Morgan Stanley, 111 Move-DatabasePath cmdlet, 337 Move-Mailbox cmdlet, 279–284 Move Mailbox page, 280 Move Mailbox Wizard, 279–280 Move Options page, 280 Move Schedule page, 280 Move-StorageGroupPath cmdlet, 336 moving mailboxes, 278 across forests, 281–283 merging, 283–284 shared and resource, 279–280 within single forests, 280–281 strategies, 278–279 tools, 279 MRM (messaging records management), 98–99 MSExchangeSetup, 267 multiple database failure recovery,

323

multiple forests, 93 multiple server roles memory recommendations, 151 processor recommendations, 149 Murdoch, Rupert, 202 Murphy Oil USA v. Flour Daniel, 110

N Naked Conversations (Scoble and Israel), 382 National Association of Securities Dealers, 96–97 National business model, 27 needs issues change management, 185 scope determinations, 56, 56 negligent misstatements, disclaimers for, 106 nervousness issues in presentations, 178 Network Monitor, 342 networking in marketing, 379 networks infrastructure requirements,

82–83

new organizations, 251

421

422

NETWORKS

•

POSTINSTALLATION TASKS

performance monitoring,

342–343

security, 271 transitioning settings, 254 troubleshooting, 353 Unified Messaging servers on, 147 neurolinguistic programming (NLP) model, 215 New Accepted Domain page, 270 New Accepted Domain Wizard, 269–270, 269 New-AcceptedDomain cmdlet, 270 New Alert Settings dialog box, 347, 349 new features, 78–80 New-Mailbox cmdlet, 331 New Mailbox Database Wizard, 330–331, 330 new organization deployment,

250–252

New Rules of Marketing and PR, The (Scott), 382 New Server Cluster Wizard, 333–334,

333–334

New Storage Group page, 328 New Storage Group Wizard, 328, 329 New-StorageGroup cmdlet, 329, 336 news, business, 371 newsletters, 381–382 next generation networking (NGN), 141 95 percent syndrome, 232 NLP (neurolinguistic programming) model, 215 no restriction message classification, 105 nonfinancial business cases, 163 nonretirement savings as revenue source, 374 nontechnical managers, 7–9 normative-reeducative strategy in change management, 200–201 notifications change request processes,

229–230

deployment, 246–247 nurturing relationships, 367–368

O objectives aligning, 157 business case, 163 implementation schedules, 74 planning, 62, 65 in SLAs, 117 in statements of work, 68–69 user expectations, 206 obstacles to change, 187–190 Occam’s razor, 93 Office Communications 2007 Server features, 80 Unified Messaging server integration, 144–146

offices for consulting, 375 Olympic games, 235 openness, need for, 185 operating system (OS) monitoring, 342 requirements, 82–83 Operation Overload, 244–245 operations checklists, 405 daily tasks, 406–409 monthly tasks, 411 summary, 412 weekly tasks, 410 operations management, 339 organization models and structures analyzing, 27–34, 28–31 selecting, 247–250, 247 organizational communication in scope statements, 55 organizing presentation materials, 178 orphaned mailboxes, 324 Osterman Research study, 112 Out of the Crisis (Deming), 371 outbound-only address rewriting, 132 outcomes in planning process, 61 Outlook Anywhere feature, 124,

275–277

Outlook Web Access, 124 outputs in planning process, 60 outsourced services comfort levels, 118–119 vs. in-house, 114–115 pros and cons, 115–116 service-level agreements,

116–118

overheating helicopters case, 41–42 ownership and control, 32

Exchange components, 350 mail archiving for, 113 memory usage, 347–348, 347 monitoring, 342–343 project team, 15–16 tools, 310–311, 311 performance-level guidelines in SLAs,

117–118

Performance Logs and Alerts, 342, 347 Performance Monitor, 310, 311, 347 Performance Object, 347–350 Performance Troubleshooter, 310 peripheral firmware revisions, 355 Permission Check scans, 304 permissions in deployment, 245 Personal Information Protection Act, 97 personnel assessment, 42–43 phased migration in moving mailboxes, 278 Philip Morris International, 111 physical environment, checking, 340, 406 physical location organization, 33 Placeholder Domain model, 94, 94 planning, 49 growth, 45–46 Lotus Notes migration, 256 mail archiving, 113 phases, 62–65 process overview, 59–62, 60 scope statements. See scope statement documents solution visualization, 52 summary, 75 terminology, 50–52, 62 Unified Messaging servers,

143–144

P Parker, Dorothy, 363 parochialism as change obstacle, 187 part-time consulting, 374 partners address rewriting for, 131 consulting, 374 relationships, 33 passive marketing, 380 passwords clusters, 335 counter logs, 348 PATRIOT Act, 44, 97 Patton, George S., 121 Patton, George S., Jr, 49 payroll services for consulting businesses, 376 PBX lines, 147 people skills for change management,

197–199

performance, 346 baselines, 344 checking, 407–408 CPU utilization, 348–349 disk usage, 349–350

upgrades, 358 Planning of Change, The (Bennis, Benne, and Chin), 199 policies ActiveSync, 277 in Exchange Server removal, 293–294 Security Configuration Wizard, 271 political climate, 64 political skills for change management, 196–197 politics, company, 33–34 POP3 considerations, 124 portable video player case, 50–52 ports for Edge Transport servers, 129–130 position papers, 377–378 positive attitudes for project teams,

17–18

postinstallation tasks, 266 authoritative domains, 268–270,

269

Exchange ActiveSync deployment,

277–278

POSTINSTALLATION TASKS

Exchange Management Console, 272–275, 272–273 installation verification, 266–268,

266

Outlook Anywhere deployment,

275–277

Security Configuration Wizard (SCW), 271 power, formal and informal, 196–197 power-coercive change strategy, 201 PowerPoint presentations, 176–177 practicing presentations, 177 premium journaling, 103 prescreening change requests, 231 presenting business cases, 175–178 preventive maintenance, 339 print materials in marketing, 378 priorities determination, 36 privacy requirements, 97 pro bono work, 379–380 proactive troubleshooting approach,

356–358

probability, risk, 70 problem statement in scope statements, 54 procedures in team effectiveness, 391 processes analyzing, 23–26 in planning, 60 processors for servers, 147–149 procurement delays, 68 product keys, 84–85, 272 product licensing considerations,

84–85

product life cycles, 25–26 productivity in business case presentations, 178 Unified Messaging servers for, 141–142 professional conduct, 383–384 professional help for consulting businesses, 376–377 professionals in change management,

183

profiles, user scope statements, 55 in troubleshooting, 353 project managers in change request process, 228–229 project sponsors, communication with, 211 project teams, 9–10 attitudes, 16–19 communication, 211 diplomacy, 14–15 discipline, 12–13 effectiveness measurements, 387 goal setting, 389 interpersonal relationships,

392

procedures, 391 roles, 390

goals, 16 group think, 11–12 member selection, 10–12 performance management, 15–16 structure, 13–14 project vision statements, 54–55 projections, 46 promptness for presentations, 177 proposed actions in business cases,

162

Proposed Cluster Configuration page, 334–335, 334 prototyping for user expectations, 213 provisioning PBX lines, 147 Public Folder Management Console, 304 public folders creating, 344 in Exchange Server removal, 293 for LCR, 330–331, 330 Mailbox servers, 138 Setup Wizard, 263 public speaking, 381 publishing for marketing, 380–381 purpose in business cases, 163

Q quality criteria in user expectations, 207 quarantine, spam, 133–134 questions in presentations, 178 Queue Viewer, 309–310, 408–409

R RAID (redundant array of inexpensive disks), 89 rationale in business cases, 164–165 rationalization in group think, 11 ratios, server role, 151–152 reaction to change, 184–185, 184 Readiness Check Exchange Server removal, 290 installation modification, 287 server roles, 288–289 Setup Wizard, 263, 264 transitioning, 252 rebuilding servers, 322 recipient policies in Exchange Server removal, 293 Recipient Update Services, 294 recognition at project completion, 65 recommendations in business cases, 174, 400 records management. See compliance RecoverServer option, 322 recovery. See disaster recovery recovery storage groups, 324–325 recovery time objectives (RTOs), 87 redundant array of inexpensive disks (RAID), 89 reengineering business processes, 24 references in marketing, 378

•

RISK TOLERANCE

Regional business model, 27 registry settings for SCW, 271 regulatory requirements. See compliance rejections in change request processes,

229

relationships change management, 198 nurturing, 367–368 team effectiveness, 392 Relevant characteristic in SMART, 54 reliability, simplicity for, 77 removing Exchange Server, 290–292 servers, 284, 286–289, 287,

292–294

replication Active Directory, 94–95 continuous. See continuous replication reports checklist, 410 in SLAs, 117 reprimands in team management, 17 requirements Active Directory, 90–96 business. See business requirements deployment, 245 disk storage, 87–90 gap analysis, 47–48 hardware, 81–82 operating systems, 82–83 in scope determinations, 56–57 understanding, 9 user expectations, 206 resistance to change, 188–190, 203 Resource Forest model, 93 resource mailbox moves, 279–280 resources planning, 62 in statements of work, 69 trade-off triangle, 56, 56 user expectations, 206 respect for team members, 16–17 responsibilities for objectives, 65 Restore-StorageGroupCopy cmdlet, 331 restores process, 320–321 testing, 343 results orientation in consulting, 370 Resume-StorageGroupCopy cmdlet, 336–337 retention policies, 44 retirement savings as revenue source, 374 return on investment (ROI) in business cases, 171–172 review process in SLAs, 117 rewriting, address, 129–132 risk assessment matrices, 39 risk tolerance, 39

423

424

RISKS

•

SETUP.COM COMMAND

risks in business cases, 158, 173–174,

400

in presentations, 178 in statements of work, 69–70 Rogers, Everett M., 193 ROI (return on investment) in business cases, 171–172 role-based deployment, 79 role models for teams, 16 roles consulting, 368–369 server. See server roles in SLAs, 117 team effectiveness measurements,

390

Rommel, Erwin, 244 Rossotti, Charles O., 198 routes, Active Directory for, 91–92 routing groups Exchange Server removal, 293 Large Organization model deployment, 250 Setup Wizard, 263 Standard Organization model deployment, 249 transitioning, 255 Routing Log Viewer, 310 RTOs (recovery time objectives), 87 rules, transport, 99–100, 101 rumors, 210

scope creep, 53 scope statement documents, 50, 52,

65–66

approval, 70 benefits, 57 budget summary, 70 in deployment, 243–244 design document, 70–73 goals summary, 67 implementation document, 73–75 outline, 66 overview, 52–53 problem statement, 54 project vision statements, 54–55 resource requirements summary,

69

risks and assumptions summary,

69–70

scope in, 56–59, 56 summary, 66–67 timeline and milestones summary,

68–69

user profiles, 55 validating, 58–59 Scott, David Meerman, The New Rules of Marketing and PR, 382 SCR (standby continuous replication), 325, 327–328, 328 Mailbox servers, 138–139 managing, 336–337 new feature, 79 SCW (Security Configuration Wizard),

271

S sabotage as change resistance tactic, 189 history, 208 safelist aggregation, 134 SARAH loss curve, 185–186, 186 Sarbanes-Oxley (SOX), 44, 96 satisfaction in user expectations, 206 savings as revenue source, 374 scalability, 144 SCCs (single copy clusters) configurations, 338, 338 multiple server roles, 149 scenarios business cases, 157 disaster recovery, 316–317 schedules implementation documents,

73–74

in trade-off triangle, 56, 56 schema preparation, 92 Schlesinger, Arthur, 12 Schneider, Greg, 366 Schutz, Will, 185 SCL (Spam Confidence Level), 134 Scoble, Robert, Naked Conversations, 382 scope business cases, 163–164 geographic, 27

SDL (Service Delivery Location) Large Organization model deployment, 250 Standard Organization model deployment, 249 Secure Sockets Layer (SSL) Outlook Anywhere certificates, 275–276 postinstallation tasks, 273 security ActiveSync, 277–278 Client Access servers, 125 deployment, 246 Edge Transport servers, 129–130, 135, 135 monthly checks, 343 Security Configuration Wizard, 271 updates checking, 411 Security Configuration Wizard (SCW), 135, 135, 271 Security Exchange Commission Rule 17a-4, 43–44, 96 security logs, 409 Select Computer page, 333 self-censorship in group think, 11 self-service features, 141 Senate Bill 1386 (SB 1386), 44 senior management for priorities, 36

sensitivities in business cases, 158, 173, 400 Sent items folder, 98 Server Cluster Wizard, 334–336 Server Role Selection page, 262, 262, 286–290, 287 server roles, 121–122, 122 Client Access. See Client Access servers (CAS) Edge Transport. See Edge Transport servers Hub Transport. See Hub Transport servers Mailbox. See Mailbox servers memory configuration, 149–151 processors, 147–149 ratios, 151–152 removing, 286–289, 287 Security Configuration Wizard, 271 summary, 152–153 tools, 152 Unified Messaging. See Unified Messaging servers server-side deleted item retention, 324 servers backups, 318–320 consolidation, 141 modifying and removing, 284 performance monitoring, 342 Service Delivery Location (SDL) Large Organization model deployment, 250 Standard Organization model deployment, 249 service-level agreements (SLAs), 323 elements, 117–118 parts, 116–117 user expectations, 217 Service Pack 1 in deployment, 245 Exchange Server 2007 installation, 258–266, 259–264 in-place upgrades, 242 new features, 79 service packs checking, 411 services in-house vs. outsourced, 114–115 life cycles, 25–26 SCW, 271 Set-ADSiteLink cmdlet, 91 Set-ExchangeServer cmdlet, 272 Set-MailboxServer cmdlet, 335 Set Password dialog box, 348 Set-TransportConfig cmdlet, 331–332 setup.com command Active Directory, 92 Exchange Server installation,

265–266

Exchange Server removal,

291–292

installation modifications,

285–286

SETUP.COM COMMAND

permissions, 245 server role removal, 289 Setup Wizard Exchange Server installation, 258–264, 259–264 Exchange Server removal,

290–291

server role removal, 288–289 shared mailbox moves, 279–280 silence as change resistance tactic, 189 Simple Exchange Organization model,

248–249

Simple Mail Transfer Protocol (SMTP) accepted domains, 268, 270 mailbox moves, 279 Simple Network Management Protocol (SNMP), 343 simplicity business cases, 158 for reliability, 77 single copy clusters (SCCs) configurations, 338, 338 multiple server roles, 149 single database failure recovery, 323 Single Domain model, 94 single forests, 93 SIP addresses, 146 site consolidation, 141 size Client Access servers, 148 Mailbox servers, 149 mailboxes, 88 server role memory, 149 SLAs (service-level agreements), 323 elements, 117–118 parts, 116–117 user expectations, 217 slots for server role memory, 150 SMART characteristics, 54 SMTP (Simple Mail Transfer Protocol) accepted domains, 268, 270 mailbox moves, 279 SNMP (Simple Network Management Protocol), 343 Society of Telecommunication Consultants (STC), 383–384 Socrates, 13 soft benefits in business cases, 169 software deployment requirements, 245 detect model problems, 355 incompatible, 353 procurement delays, 68 Solomon Smith Barney Inc., 111 solutions detect model testing, 355 visualizing, 52 sources of user expectations, 207 SOWs (statements of work). See scope statement documents spam Edge Transport servers for, 126,

132–134

Hub Transport server for, 267 Spam Confidence Level (SCL), 134 Specific characteristic in SMART, 54 speed of server role memory, 149 sponsor communication, 211 SSL (Secure Sockets Layer) Outlook Anywhere certificates, 275–276 postinstallation tasks, 273 staffing in SLAs, 118 Stagg, J. M., 244 stakeholders business cases, 158 communication with, 211 interviewing, 37 scope statement validation, 58–59 stakes factor in change management, 203 stamps, antispam, 133 standard journaling, 103 Standard Organization model, 249 standby continuous replication (SCR), 325, 327–328, 328 Mailbox servers, 138–139 managing, 336–337 new feature, 79 standby recovery servers, 322 Start page, 259–260, 260 startup consulting expenses, 375–377 statements of objectives in SLAs, 117 statements of requirements, 50 statements of work (SOWs). See scope statement documents status meetings, 410 STC (Society of Telecommunication Consultants), 383–384 stereotyping in group think, 11 storage mail archiving, 112 technology, 88–89 tools, 89–90 storage groups enabling, 328–329, 329 recovery, 324–325 Storage Requirements Calculator, 89 stories in business cases, 158–160 strategic business unit organizational structure, 30, 31 strategies change management, 199–203 in planning, 62, 65 streaming backups, 320, 323 Stress and Performance tool, 90 strong resistance to change, 188 structures analyzing, 27–34, 28–31 project team management, 13–14 subcontracting, 373 subject matter experts, 22 subscriptions Edge Subscriptions, 128–129 Unified Messaging servers, 145–146

•

THROWER, MITCH

Subsidiary business model, 27 success acknowledgement in scope statement development, 59 success criteria business cases, 165–166 change management, 297 in consulting, 369 summary checklist, 412 superficial resistance to change, 188 supplemental documentation in business cases, 175 support issues in scope statements, 55 Suspend-StorageGroupCopy cmdlet, 336–337 swing migration for mailbox moves, 278 symptom identification in troubleshooting, 352–354 system features, identifying and communicating, 34–35, 35 system history review in detect model,

354–355

System Information (MSInfo32) tool, 354 system log monitoring, 358 System Monitor, 342 system skills in change management,

199

System State Backup recovery, 322–323

T tactical benefits in business cases, 169 tangible benefits in business cases, 169 target population factor in change management, 203 targets in SCR, 139 Task Manager, 342 tasks ‘‘as needed’’, 343–345, 344 change management, 182 continuous replication monitoring, 345–346 daily, 339–343, 341 monthly, 343 in planning, 62 weekly, 343 TCO (Total Cost of Ownership), 81–82 teams. See project teams technical jargon, 8 technical skills for consulting,

370–371

technology bigotry, 369 termination procedures in SLAs, 117 Test-ReplicationHealth cmdlet,

345–346

testimonials, 377 Thatcher, Margaret, 202 third-parties brick-level backups, 324 product functionality, 86–87 Thrower, Mitch, 205

425

426

TIME-BASED CHARACTERISTIC IN SMART

Time-based characteristic in SMART, 54 time frame factor in change management, 203 timelines for objectives, 65 in statements of work, 68–69 ‘‘to-be’’ analysis, 47 Toolbox node, 301–302, 303 tools, 301–302 configuration, 302–304, 303 disaster recovery, 304–307, 305 mail flow, 307–310, 308 performance, 310–311, 311 troubleshooting, 311–314, 312 topologies Active Directory, 94–95 Edge Transport servers, 127–128 Total Cost of Ownership (TCO), 81–82 Tower of Pisa, 59, 60 tracking CPU utilization, 348–349, 406–407 disk usage, 349–350, 407 Exchange components, 350 memory usage, 347–348, 347, 406–407 trade-off triangle, 56, 56 training assessing, 42–43 in deployment, 246 Unified Messaging servers for, 141 for user expectations, 213–215 transaction logs, copying, 326 transitioning, 252 environment settings, 252–254,

253

miscellaneous tasks, 255 phases, 242 quick guide, 254–255 readiness checks, 252 support, 243 transmission of viruses disclaimers, 106–107 transport dumpster, 331–332, 332 transport rules, 99–100, 101 transport servers. See Edge Transport servers; Hub Transport servers Transport Settings Properties dialog box, 332, 332 trend analysis, 46 triple constraints in change request processes, 223, 224, 227, 229–230 troubleshooting, 350–351 methodology development, 351–356, 351 proactive approach, 356–358 tools, 311–314, 312

•

ZUBULAKE VS. WARBUNG (USB BANK)

Twain, Mark, 65 tweaking scope determinations, 56–58 Typical Exchange Server Installation option, 261

user profiles scope statements, 55 in troubleshooting, 353 user self-service features, 141

U

V

UM Dial Plan objects, 146 unanimity in group think, 11 unclear goals and performance measures as change obstacle, 187 unfreeze-change-refreeze change model, 190–191, 190 Unified Messaging servers, 140, 140 availability and scalability, 144 benefits, 141–143 deployment, 146–147 new features, 79–80 new organizations, 251–252 Office Communications 2007 Server integration, 144–146 planning, 143–144 postinstallation tasks, 274–275 ratios, 152 setup, 261, 265 transitioning, 255 unit directors, communication with, 211 unmet user expectations, 207–208,

208

untested software in troubleshooting, 353 update rollups, 411 Update-StorageGroupCopyStatus cmdlet, 337 updated firmware, 355 upgrades mailbox moves, 278 overview, 241–243 plans, 358 uptime requirements in SLAs, 118 U.S. Bancorp Jaffray Inc., 111 user benefits in Unified Messaging servers, 142–143 user expectations, 205 communication for, 209–212 criteria, 206–207 management guide, 217–219, 218 power of, 205–206 prototyping for, 213 service-level agreements, 217 sources, 207 summary, 219 training for, 213–215 unmet, 207–208, 208 user considerations, 208–209 user focus groups, 38 user functions in scope statements, 55

VAK (visual-audio-kisthethetic) learning style, 215–216 validating scope statements, 58–59 vendors in business cases, 159 relationships, 33 verifying installation, 266–268, 266 version selection, 83 virtualization considerations, 85–86 Virus Scanning Application Program Interface, 126–127 virus transmission disclaimers, 106 viruses Edge Transport servers for, 126,

132–134

protection checking, 410 vision/scope documents. See scope statement documents vision statements, 54–55, 63–64 visual-audio-kisthethetic (VAK) learning style, 215–216 visual learners, 215–216 visualizing solutions, 52 voice mail messages, 145 Volume Shadow Copy Service (VSS), 320, 323

W

waypoints. See objectives web designer services for consulting businesses, 376–377 websites for marketing, 378 weekly operations checklist, 410 messaging system tasks, 343 Weiss, Alan, Getting Started in Consulting, 373 white papers, 377–378 William of Occam, 93 Wilson, Woodrow, 181 Windows Management Instrumentation (WMI), 343 Windows servers, server role removal from, 287–289 workspace for consulting, 375 writing in marketing, 380–381

Z Zubulake vs. Warbung (USB Bank), 111