title:
`author:
`publisher:
`isbn10 | asin:
`print isbn13:
`ebook isbn13:
`language:
`subject
`publication date:
`lcc:
`ddc:
`subject:
`
`Smart Mobile Technologies LLC, Exhibit 2013
`Page 2013 - 1
`IPR2022-00807, Apple Inc. et al. v. Smart Mobile Technologies LLC
`
`
`author:
`publisher:
`isbn10 | asin:
`print isbn13:
`ebook isbn13:
`language:
`subject
`publication date:
`lcc:
`ddc:
`subject:
`
`Smart Mobile Technologies LLC, Exhibit 2013
`Page 2013 - 1
`IPR2022-00807, Apple Inc. et al. v. Smart Mobile Technologies LLC
`
`
`
`Page iii
`
`Managing Microsoft Exchange Server
`Paul Robichaux
`
`Beijing Cambridge Farnham Köln Paris Sebastopol Taipei Tokyo
`
`Smart Mobile Technologies LLC, Exhibit 2013
`Page 2013 - 2
`IPR2022-00807, Apple Inc. et al. v. Smart Mobile Technologies LLC
`
`
`
`Managing Microsoft Exchange Server
`by Paul Robichaux
`
`Page iv
`
`Copyright © 1999 O'Reilly & Associates, Inc. All rights reserved.
`Printed in the United States of America.
`Published by O'Reilly & Associates, Inc., 101 Morris Street,
`Sebastopol, CA 95472.
`Editor: Robert Denn
`Production Editor: Madeleine Newell
`Printing History:
` First Edition.
`July 1999:
`Nutshell Handbook, the Nutshell Handbook logo, and the
`O'Reilly logo are registered trademarks of O'Reilly & Associates,
`Inc. Many of the designations used by manufacturers and sellers
`to distinguish their products are claimed as trademarks. Where
`those designations appear in this book, and O'Reilly &
`Associates, Inc. was aware of a trademark claim, the designations
`have been printed in caps or initial caps.
`The association between the image of a bush baby and the topic
`of managing Microsoft Exchange Server is a trademark of
`O'Reilly & Associates, Inc.
`While every precaution has been taken in the preparation of this
`book, the publisher assumes no responsibility for errors or
`
`Smart Mobile Technologies LLC, Exhibit 2013
`Page 2013 - 3
`IPR2022-00807, Apple Inc. et al. v. Smart Mobile Technologies LLC
`
`
`
`omissions, or for damages resulting from the use of the
`information contained herein.
`
`This book is printed on acid-free paper with 85% recycled
`content, 15% post-consumer waste. O'Reilly & Associates is
`committed to using paper with the highest recycled content
`available consistent with high quality.
`ISBN: 1-56592-545-9
`
`Smart Mobile Technologies LLC, Exhibit 2013
`Page 2013 - 4
`IPR2022-00807, Apple Inc. et al. v. Smart Mobile Technologies LLC
`
`
`
`Table of Contents
`Preface
`1. Introducing Exchange Server
`Exchange Capabilities
`A Little Exchange History
`Exchange Server concepts
`2. Exchange Architecture
`Exchange Message Addressing
`Exchange Message Routing
`Exchange Security
`The Exchange Databases
`3. Exchange Planning
`Before You Start Planning
`Designing Your Exchange Organization
`Migration and Coexistence
`4. Installing Exchange
`Before You Start Installing
`Installing Exchange
`5. Using Exchange Administrator
`
`Page v
`
`ix
`1
`1
`3
`6
`16
`16
`18
`25
`31
`46
`46
`53
`77
`83
`83
`96
`114
`
`Smart Mobile Technologies LLC, Exhibit 2013
`Page 2013 - 5
`IPR2022-00807, Apple Inc. et al. v. Smart Mobile Technologies LLC
`
`
`
`Exchange Administrator Basics
`Getting Around in Exchange Administrator
`Creating and Deleting Objects
`Exporting and Importing Directory Data
`
`114
`123
`134
`140
`
`Smart Mobile Technologies LLC, Exhibit 2013
`Page 2013 - 6
`IPR2022-00807, Apple Inc. et al. v. Smart Mobile Technologies LLC
`
`
`
`Nifty Exchange Administrator Tricks
`Taming the Import and Export Features
`6. Mailboxes, Recipients, and Distribution Lists
`Creating and Managing Mailboxes
`Creating and Managing Custom Recipients
`Creating and Managing Distribution Lists
`7. Managing Connectors and the MTA
`MTA and Connector Concepts
`Managing the MTA
`Managing Connectors
`Configuring Site Addressing
`Message Journaling
`8. Managing the Internet Mail Service
`Understanding the IMS
`Installing the IMS
`Managing the IMS
`Connecting Without a WAN
`Rejecting Spam
`Performance and Registry Tuning
`9. Managing the Directory
`
`Page vi
`148
`165
`171
`171
`192
`195
`199
`199
`203
`214
`245
`247
`251
`251
`262
`267
`287
`294
`295
`298
`
`Smart Mobile Technologies LLC, Exhibit 2013
`Page 2013 - 7
`IPR2022-00807, Apple Inc. et al. v. Smart Mobile Technologies LLC
`
`
`
`Directory Management Basics
`Managing the Directory Service
`Providing Directory Access with LDAP
`Using Address Book Views
`Nifty Directory Tricks
`10. Managing Public Folders
`Public Folder Basics
`Managing Public Folders
`Controlling Public Folder Replication
`11. Managing the Information Store
`IS Basics
`Configuring the IS
`Viewing IS Resource Usage
`
`298
`312
`319
`322
`326
`331
`331
`337
`350
`359
`360
`364
`367
`
`Smart Mobile Technologies LLC, Exhibit 2013
`Page 2013 - 8
`IPR2022-00807, Apple Inc. et al. v. Smart Mobile Technologies LLC
`
`
`
`12. Managing the Internet News Service
`Understanding the INS
`Getting a Newsfeed
`Installing the INS
`Managing the INS
`13. Managing Exchange Clients
`Exchange Client Basics
`Managing Outlook
`Managing Outlook Web Access
`14. Managing Exchange Servers
`Server Management Basics
`Storage and Growth Management
`Increasing Availability
`Managing Your Server
`Routine Maintenance Tasks
`Changing Your Server Configuration
`Monitoring Your Servers
`15. Troubleshooting Exchange Server
`The Art of Troubleshooting
`When Your Server Stops
`
`Page vii
`369
`370
`374
`379
`383
`395
`395
`398
`421
`425
`425
`432
`437
`442
`445
`450
`465
`471
`471
`479
`
`Smart Mobile Technologies LLC, Exhibit 2013
`Page 2013 - 9
`IPR2022-00807, Apple Inc. et al. v. Smart Mobile Technologies LLC
`
`
`
`Troubleshooting Server Problems
`Troubleshooting MTA and Connector Problems
`Troubleshooting Internet Protocols
`Troubleshooting Client Problems
`16. Exchange Security
`Understanding Exchange Security
`Security Policy and the Wonderful World of
`Jurisprudence
`Using Advanced Security
`Protecting Against Viruses
`Useful Security Tasks
`17. Recovery and Repair
`Understanding Server Recovery
`Backing Up Exchange
`Maintenance and Repair Tools
`Recovering Your Data
`
`484
`489
`499
`505
`510
`510
`515
`
`519
`538
`542
`551
`551
`556
`563
`571
`
`Smart Mobile Technologies LLC, Exhibit 2013
`Page 2013 - 10
`IPR2022-00807, Apple Inc. et al. v. Smart Mobile Technologies LLC
`
`
`
`Directory Recovery
`Preventative Medicine
`18. Managing Exchange Performance
`What Influences Exchange Performance?
`Measuring Exchange Performance
`Performance Simulation
`Performance Tuning
`A. BORK Tools
`B. Useful Performance Monitor Counters
`Index
`
`Page viii
`581
`581
`584
`585
`599
`606
`608
`625
`641
`659
`
`Smart Mobile Technologies LLC, Exhibit 2013
`Page 2013 - 11
`IPR2022-00807, Apple Inc. et al. v. Smart Mobile Technologies LLC
`
`
`
`Page 425
`
`14
`Managing Exchange Servers
`The management of a balance of power is a permanent undertaking, not
`an exertion that has a foreseeable end.
`Henry A. Kissinger
`White House Years
`Exchange offers some unique capabilities compared to other
`email systems, but those capabilities come at a price. To get
`maximum reliability, stability, and performance, you must be
`proactive in managing your organization's servers, because if you
`just wait for something bad to happen, it may be too late to
`recover. Careful planning of your server configuration and
`ongoing maintenance is required to ensure that your environment
`is optimizing your server usage, with minimal data loss risk and
`best performance.
`Messaging is all about information flowpeople communicating
`with people, both inside and outside an organization. Getting to
`know user habits, activities, and trends is critical to delivering a
`messaging system that meets user needs. You should have
`evaluated user needs before you deployed Exchange; now it's
`time to see how those considerations affect server management.
`Server Management Basics
`Before we go into the details of the Exchange server management
`tools, let's talk about philosophical issues that affect what you do
`to your servers. There's no gray area when it comes to uptime
`
`Smart Mobile Technologies LLC, Exhibit 2013
`Page 2013 - 12
`IPR2022-00807, Apple Inc. et al. v. Smart Mobile Technologies LLC
`
`
`
`and performancemore is betterbut other management areas offer
`a little more flexibility.
`Microsoft has positioned Exchange as a one-size-fits-all solution
`for every customer from the small office market to very large
`corporate mail systems, but these
`
`Smart Mobile Technologies LLC, Exhibit 2013
`Page 2013 - 13
`IPR2022-00807, Apple Inc. et al. v. Smart Mobile Technologies LLC
`
`
`
`Page 426
`
`markets have different concerns. In particular, storage
`management, replication, and high availability features such as
`clustering are much more important to large sites than to small
`ones. Also consider that the smaller customer has to deal with the
`same backup complexity and data growth as a larger customer,
`but often with fewer staff.
`Most ongoing management of server hardware revolves around
`the I/O subsystem. For most applications, Exchange isn't
`particularly CPU-bound, and there's not much you can do to
`manage RAM except to add it when necessary. Because of
`dynamic buffer allocation, which you first encountered in
`Chapter 1, Introducing Exchange Server, Exchange 5.5 will
`productively use as much RAM as you install. Database backup
`and maintenance issues are a significant part of your day-to-day
`work, as are troubleshooting and (hopefully) implementing
`proactive fixes to problems before they bite you.
`It is important to distinguish between managing servers at the site
`level and at the individual server level. Exchange abstracts much
`of what you would associate with a single server in other
`products up to the site level, leaving mostly practical tasks like
`managing disks and backups. For many higher-level messaging
`functions, like limiting the use of connectors and message sizes,
`the site is the best level to work on, since site-level changes can
`apply to multiple servers.
`Centralized Storage: Pro and Con
`The most sophisticated form of Exchange implementation is a
`centralized storage model, where all user mail and public folder
`
`Smart Mobile Technologies LLC, Exhibit 2013
`Page 2013 - 14
`IPR2022-00807, Apple Inc. et al. v. Smart Mobile Technologies LLC
`
`
`
`data is stored on the server instead of on individual machines. In
`this model, clients just view mail; they don't keep their own local
`copies. As you learned in Chapter 13, Managing Exchange
`Clients, remote, low-bandwidth, or offline users can use
`Outlook's offline synchronization features to keep their local and
`server-based mail caches synchronized.
`Pro
`Centralized storage allows you to concentrate all your
`management efforts at the server level, not on the clients. When
`clients store their own mail data, you have less assurance that it's
`protected from loss, damage, or compromise than you do if it's
`on a stable, secure, managed server. Do you want to back up
`hundreds of clients or a single server?
`There are some compelling reasons for using centralized storage
`management:
`Exchange is built from the ground up to support centralized
`storage as a way of managing information flow and retention. It's
`designed to support very large Information Stores and to let you
`juggle mailboxes and servers to spread the load gracefully.
`
`Smart Mobile Technologies LLC, Exhibit 2013
`Page 2013 - 15
`IPR2022-00807, Apple Inc. et al. v. Smart Mobile Technologies LLC
`
`
`
`Page 427
`In a typical office environment, users want to be able to do their
`(often non-computer-related) job without concern for backups,
`disk storage, growth management, and so forth. Forcing each
`user to keep track of their own mail interferes with their real
`jobs.
`With centralized storage, you gain the benefits of single-instance
`storage, plus the management benefits of having all your data
`stored in, and available from, a small number of servers.
`PST files are fragile. They're easily corrupted and subject to loss
`or damage by other applications on the workstation. There's no
`way to recover accidentally deleted messages from a PST. (See
`"Using PST files" in Chapter 13 for more details on why most
`seasoned administrators say "PST BAD.")
`Con
`Centralized storage isn't perfect. There are three major arguments
`against centralizing all your mail data on your servers:
`It's possible to build such a big centralized store that you can't
`efficiently back it up or restore it. It's very difficult to deal with
`the practical backup and recovery solutions for a 100GB or
`200GB store; it would literally take days to run database tests, and
`the need to backup and restore the entire file makes it difficult to
`recover quickly from any sort of failure. You can empirically test
`how long backup and recovery takes on a test server loaded with
`a copy of your database; in some cases, upgrading your backup
`system can get you out of this particular problem.
`If you use centralized storage, you'll be held to a higher standard
`
`Smart Mobile Technologies LLC, Exhibit 2013
`Page 2013 - 16
`IPR2022-00807, Apple Inc. et al. v. Smart Mobile Technologies LLC
`
`
`
`for reliability and availability; when your server's down, users are
`prevented from using their mail at all, not just from sending and
`receiving new mail.
`Server redundancy is critical. The centralized storage model
`tempts many people to build one big server with lots of
`mailboxes, but if anything happens to that one server, you're dead
`in the water. You can fix this problem to some extent by using a
`larger number of smaller servers, thus distributing both load and
`risk.*
`Choosing the proper solution
`If there's any way you can avoid it, don't use PST files. If you
`use PST files, you lose all the benefits of centralized storage,
`including ease of backup, single-instance storage, and centralized
`security. If your users insist on keeping their own
`* Ed Crowley points out that if you split one server into two, you've
`doubled the overall odds of a failure, but when the failure occurs it
`will only affect half as many users.
`
`Smart Mobile Technologies LLC, Exhibit 2013
`Page 2013 - 17
`IPR2022-00807, Apple Inc. et al. v. Smart Mobile Technologies LLC
`
`
`
`Page 428
`local replicas of mail, strongly encourage them to use offline
`folders (if they're using Outlook) or IMAP (if they're not), since
`both of these allow each client to keep a local store that mirrors
`the contents of the client's mailbox on the server.
`If you must allow PST files, restrict their use as much as
`possible, and educate your users about the potential pitfalls, so
`they'll know what limitations PST files impose. Then be prepared
`for complaints and help requests once the inevitable happens and
`someone loses, or can't open, a PST file. You've been warned.
`Small Doesn't Always Mean Harder
`It might seem ridiculous to plan for 24/7 availability and uptime
`for a small Exchange implementation of 10 to 100 users. Users at
`small sites, though, don't need their email any less than users at
`big companies. Email has entered the mainstream, and users
`expect and demand that email be as available and reliable as the
`public telephone system.
`The good news is that it's often easier for small organizations to
`follow good server management policies. Smaller organizations
`usually find it less expensive to update clients, provide training,
`and so on. Small Exchange sites usually don't have to wrestle
`with the complexities of multisite networks, which is a savings
`both in administrative cost and hassle for the administrative staff.
`Two heads are better than one
`At a minimum, consider splitting the workload at your siteeven if
`it's a very small siteacross two Exchange servers. This may mean
`that you redefine what a server looks like. Chapter 3, Exchange
`
`Smart Mobile Technologies LLC, Exhibit 2013
`Page 2013 - 18
`IPR2022-00807, Apple Inc. et al. v. Smart Mobile Technologies LLC
`
`
`
`Planning, gave some pretty detailed guidance about the best
`kinds of hardware for running Exchange, but you may find a
`larger group of less-capable servers is better for your individual
`needs than a small number of bigger servers. I'm not suggesting
`trying to host 1500 users on a Packard Bell box you bought at
`Sears, but not every server application requires a stout server
`with lots of RAM and fast RAID storage.
`The former Soviet Union's strategy for military supremacy was to
`build large numbers of robust but feature-poor weapons, as
`opposed to the Western strategy of building a small number of
`highly capable but fragile weapons. While the theory was never
`tested in battle, you may find that the Red Army approach works
`to your advantage even if you're running a large Exchange site.
`Consider a server that runs the IMS or other connectors. These
`connectors are typically CPU-bound. As long as you don't store
`any public folder or mailbox data on them, disk redundancy and
`performance are relatively unimportant. Two good-quality
`desktop systems may actually provide better overall performance
`and redundancy than one larger connector server. Having two
`independent systems also makes it much easier to do scheduled
`maintenance on either machine. However, adding servers also
`
`Smart Mobile Technologies LLC, Exhibit 2013
`Page 2013 - 19
`IPR2022-00807, Apple Inc. et al. v. Smart Mobile Technologies LLC
`
`
`
`Page 429
`adds hardware and maintenance costs, so there's a tradeoff to
`evaluate. In general, whenever possible, I like to put connectors
`on their own server in each site.
`Scheduling Maintenance Time
`Microsoft's claims notwithstanding, Windows NT is not quite
`perfectly stable. If you put all your mail and Exchange resources
`on a single server, you run the risk of unplanned downtime
`caused by NT problems. Even if you don't run into NT problems,
`you're still guaranteed to have to reboot the system when you
`make configuration changes and do upgrades. Although
`Windows NT 4.0 Service Pack 4 is much better than previous
`versions in this regard,* ancillary services like Internet Explorer
`and IIS tend to offset SP4's improvements by requiring reboots
`when you update or reconfigure them.
`Since Exchange lets you do online backups without stopping its
`services, if you don't change the configuration of your servers,
`and if fortune smiles on you by keeping your hardware from
`breaking, you can run Exchange for months on end without
`shutting it down. However, it's important to factor scheduled
`maintenance like installing product upgrades or service packs, or
`even doing an offline defragmentation of the store, into your
`availability plan. Don't just take the server down at random
`intervals to install hardware or software upgrades; instead, make
`a schedule and stick to it. This minimizes your unplanned
`downtime and lets you plan updates and maintenance on your
`own terms.
`Managing Large Stores
`
`Smart Mobile Technologies LLC, Exhibit 2013
`Page 2013 - 20
`IPR2022-00807, Apple Inc. et al. v. Smart Mobile Technologies LLC
`
`
`
`When the combined size of your public and private store files
`starts getting up around the 12GB mark, the practical matters of
`backup, recovery, and storage management start to get a lot more
`important. The Standard Edition of Exchange is limited to 16GB
`per store file, but Enterprise Edition doesn't have any limit on the
`store size. However, there are practical limits to how much stuff
`you can physically back up. Let's say you have a 54GB store that
`you can back up at 6 GB/hour. That means that every full backup
`will take 9 hours, and restores will take up to twice as long,
`depending on how recent your backup is. If your server fails,
`you're looking at 9 to 18 hours just to reload the backup from
`tape and patch the databases! It could be worse if you have to
`spend time tracking down a replacement computer, installing
`Windows NT and Exchange, and doing whatever else is required
`to correct the actual cause of the problem.
`* Microsoft's quantitative data suggests roughly a tenfold improvement
`in mean time between unscheduled reboots, and I have seen nothing to
`disprove this.
`
`Smart Mobile Technologies LLC, Exhibit 2013
`Page 2013 - 21
`IPR2022-00807, Apple Inc. et al. v. Smart Mobile Technologies LLC
`
`
`
`Page 430
`You can plan for this eventuality in two ways. One way is to take
`advantage of Exchange's strengths and distribute your data: you
`can split your public IS across many servers by distributing
`folder replicas (see Chapter 10, Managing Public Folders, for
`details), or you can move user mailboxes to better distribute the
`load. The second way, upgrading your backup hardware, is
`initially less expensive, but it doesn't give you the same flexibility
`and redundancy as adding servers.
`Managing the Managers
`It's essential that everyone responsible for administering your
`Exchange servers agree on policies and procedures. It's far too
`easy to accidentally make undesirable changes, and in a multisite
`network those changes may quickly be replicated. How to
`coordinate server management depends on your organization: if
`you're the only Exchange administrator, or if you're in a position
`to develop and enforce a set of guidelines, management is easy. If
`you must build a consensus, reaching agreement and maintaining
`discipline to work together are a little harder. You can use the rest
`of this section to formulate a policy sensible enough for all your
`administrators to agree on.
`Controlling changes
`When you have multiple servers in a site, it's preferable to have
`all directory changes made to a single server. This lowers the risk
`of replication conflicts created by changes to more than one
`replica of the directory. Since you can install Exchange
`Administrator on any NT 4.0 machine, it's usually pretty easy to
`agree on centralizing directory changes. Of course, practically
`
`Smart Mobile Technologies LLC, Exhibit 2013
`Page 2013 - 22
`IPR2022-00807, Apple Inc. et al. v. Smart Mobile Technologies LLC
`
`
`
`everything you can change in Exchange Administrator is a
`directory change, so be specific about what kind of changes
`you'll allow.
`It's also a good idea to keep changes to permissions on directory
`objects to a minimum. The less often you change permissions,
`the less chance you have to make a mistake. One way to
`centralize permission management is to replace the permissions
`given to the account you used to install Exchange with those of a
`Windows NT global group, then put whomever you want to have
`administrative access in this group. This keeps changes to the
`Exchange Directory hierarchy permissions to a minimum: you
`just assign permissions to the group once, then add and remove
`accounts as necessary.
`To make this change, create the Windows NT group using User
`Manager, populate it with the proper accounts (including the
`account of the administrator making the change), and log off.
`Log back on as a member of the group, then use Exchange
`Administrator to make the appropriate changes to the
`organization and site Configuration container permissions.
`
`Smart Mobile Technologies LLC, Exhibit 2013
`Page 2013 - 23
`IPR2022-00807, Apple Inc. et al. v. Smart Mobile Technologies LLC
`
`
`
`Page 431
`
`Controlling who has administrative access
`Speaking of changing permissions, there are three objects in the
`directory whose permissions are particularly important: the
`organization, site, and site Configuration containers. To control
`who has administrative access to your servers, you can adjust
`permissions on these objects. Normally, after you install
`Exchange, there will be two accounts with permissions on these
`objects: the site service account and the account you used when
`installing Exchange. By opening the Permissions tab on these
`three objects, you can modify which groups and accounts have
`permissions on these objects.
`Modifying permissions on these three objects is particularly
`important because many items in the Exchange directory inherit
`permissions from one or more of these objects. If you haven't
`made any permissions changes since installing Exchange, these
`are the only objects that need to be changed, given this
`inheritance. On the other hand, if you have made changes, it
`would be prudent to spot-check other objects, especially the
`default Recipients container.
`
` Remember, the Exchange Administrator
`application won't show the Permissions tab on most
`objects unless you use the Tools ® Options. . .
`command to force it to do so.
`You can assign permissions to individual containers and leaf
`nodes. For example, you can set permissions so that a particular
`account or group could change connector settings and view their
`
`Smart Mobile Technologies LLC, Exhibit 2013
`Page 2013 - 24
`IPR2022-00807, Apple Inc. et al. v. Smart Mobile Technologies LLC
`
`
`
`queues without giving that account or group permission to make
`changes to mailbox objects.
`Documentation!
`Mainframe, minicomputer, and database administrators are
`usually pretty good about keeping detailed records of their
`system configurations and software loads. However, many NT
`and Exchange administrators don't have that background, so it's
`likely that your network is a little lacking in this respect. At a
`minimum, you should be keeping track of the following:
`How is NT installed on your Exchange servers?
`This should include information on what hardware is installed on
`the server, what its network settings are, any special drivers, the
`way hard disks are partitioned, what service packs are installed,
`and anything else you think you'd need to know to reconstruct a
`failed machine.
`
`Smart Mobile Technologies LLC, Exhibit 2013
`Page 2013 - 25
`IPR2022-00807, Apple Inc. et al. v. Smart Mobile Technologies LLC
`
`
`
`Page 432
`
`How was Exchange installed?
`What is the service account? Which server was the first one
`installed in the site?
`What connectors are you using?
`What remote systems do they talk to? Who can you call if the
`server on the other end of the connector starts acting up?
`What's your disaster recovery plan?
`A plan is never easy to produce (see Chapter 17, Recovery and
`Repair, for some hints), but having one on hand makes an actual
`recovery much less stressful.
`Apart from this workaday documentation, you should also
`outline your anticipated needs for future storage and upgrades,
`when possible. Try to decide when major upgrades like Windows
`2000 and Exchange 6.0 will be deployed, and document your
`reasoning. Try to define your rules governing when a server is
`too old or too slow and how to decide what to replace it with.
`Last, but certainly not least, write down your strategy for
`incremental Exchange Server and client upgrades. Do you apply
`new service packs 15 days after they ship, or do you wait 6
`months until they're stable? When Outlook 2001 ships, will you
`upgrade immediately, or wait for Outlook 2002?
`Storage and Growth Management
`It's an old chestnut that data expands to fill the space available,
`and this happens to be true when it comes to email systems.
`Users, by and large, don't do a good job of removing old email.
`The fault's not all theirs, though; email is seeing increasing use as
`
`Smart Mobile Technologies LLC, Exhibit 2013
`Page 2013 - 26
`IPR2022-00807, Apple Inc. et al. v. Smart Mobile Technologies LLC
`
`
`
`a transport and storage mechanism for other kinds of data, like
`voice mail and faxes. Between public folders and the ability to
`file personal mail into organized trees of folders, Exchange has
`become many users' tool of choice for filing medium-term data.
`Even if your users are well organized and diligent about cleaning
`up their mailboxes, and even if you impose storage limits to keep
`folder and mailbox sizes within reason, you'll probably find that
`the volume of messages and average message size are larger than
`you expected. As Exchange becomes more popular in your
`organization, you'll probably also find that mail system usage
`increases as people get more comfortable with the product and
`find new applications for it, like booking shared resources or
`holding votes.
`Managing the growth of your servers requires careful planning
`andforethought; namely, you must decide how big you'll let a
`server get beforeyou start moving mailboxes and services to
`other servers. You'll have to setyour own thresholds, but I can
`suggest a few ways to help you determine whatthose thresholds
`might be.
`
`Smart Mobile Technologies LLC, Exhibit 2013
`Page 2013 - 27
`IPR2022-00807, Apple Inc. et al. v. Smart Mobile Technologies LLC
`
`
`
`Page 433
`Normally, you'll probably let a server grow to the size you feel
`comfortable with. You may be constrained by the amount of disk
`space on a server or the perceived risk inherent in hosting lots of
`mailboxes or folders on a single server. More likely, you'll be
`limited by how much data you can back up and restore in the
`amount of time you have available. For example, if the best
`backup system you have available can back up a 10GB store in 7
`hours, you might be better off capping the store size at about 7GB
`(since at that rate you can back up 7GB in about 5 hours and
`restore it in about 10) by moving some users and data to other
`servers.
`You can use empirical data to tell you how fast the store on your
`server is growing: capture the Mailbox Resources and Public
`Folder Resources views to a text file once per month, and you've
`got an instant baseline for comparison. You can also use the
`Performance Monitor counters discussed in Chapter 18,
`Managing Exchange Performance, and Appendix B, Useful
`Performance Monitor Counters, to keep track of the load on
`your machines, including the average number of active users on a
`server and the inbound and outbound message traffic rates.
`When you add new servers to a site, Exchange imposes zero
`penalty on you, but the servers have to work a lot harder to move
`mail between users in diferent sites. Exchange components have
`been designed to allow you to spread the service load across
`multiple machines: connectors on one server, public and private
`IS databases on separate machines, and so on. My normal
`recommendation is to allow your servers to grow to around 70%
`of their capacity before expanding them or shifting some load
`
`Smart Mobile Technologies LLC, Exhibit 2013
`Page 2013 - 28
`IPR2022-00807, Apple Inc. et al. v. Smart Mobile Technologies LLC
`
`
`
`elsewhere. For example, if you have a server equipped with
`15GB of space, when the combined size of your public and
`private IS database files hits around 10.5GB, I'd start looking for
`a new place to move some mailboxes and folders. The same is
`true for response time: if your server starts bogging down
`because there are too many concurrent users for it to handle,
`move some mailboxes to another server.
`Knowing Your Users
`It's important to study traffic patterns on your servers, especially
`with regard to when users are most likely to receive and read
`their email. Some environments are strictly 8-to-5 (although they
`can receive incoming mail at any time of the day), while others
`have users who connect and actively use the server at all hours of
`the day and night.
`It's also valuable to spot-check the Mailbox Resources view of
`the private IS to see which mailboxes are growing the most in
`items or bytes. You can use Exchange Administrator's File Save
`Window Contents. . . command to save snapshots of this view
`every so often, comparing versions to see where growth is
`happening. Check the volume and size of public folders,
`distribution lists, and Usenet groups on your servers to help you
`understand how users are actually using the system.
`
`Smart Mobile Technologies LLC, Exhibit 2013
`Page 2013 - 29
`IPR2022-00807, Apple Inc. et al. v. Smart Mobile Technologies LLC
`
`
`
`Page 434
`
` If you have users who subscribe to Internet
`mailing lists, you may find significant benefits in
`subscribing a public folder to those lists. This
`centralizes storage of lists mail and makes its contents
`available to a wider range of people without any
`additional load on your server or the mailing list host.
`Microsoft has a white paper titled ''Subscribing
`Public Folders to Internet Mailing Lists," available at
`www.microsoft.com/exchange/55/gen/Subscribe.htm.
`One more suggestion: in Chapter 3, I suggested putting users who
`work together on the same server so they can exchange mail most
`efficiently. Consider how you can track and measure how often
`users are sending to each other; proper placement is beneficial to
`both you and the users, and it's easy to move mailboxes between
`servers when you need to. One way (albeit an imprecise one) to
`get this insight is to look at the Single Instance Ratio counter of
`the public and private IS objects (see Appendix B for a full
`explanation of these counters). Of course, it's not hard to send out
`a short survey to all the users on a particular server (hint: create an
`ABV or DL to group users by the server they're on) and just ask
`them how often they mail other users on the same server; while
`unscientific, this type of user poll can shed valuable light on what
`your users are doing.
`Mailbox Moving Magic
`One of Exchange Server's best-kept secrets is that it doesn't care
`what server is holding a particular mailbox. All addressing and
`security is based on an object's place within the site, not the
`
`Smart Mobile Technologies LLC, Exhibit 2013
`Page 2013 - 30
`IPR2022-00807, Apple Inc. et al. v. Smart Mobile Technologies LLC
`
`
`
`server's name. It's possible to introduce a new server, move some
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
Still Working On It
This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.
Give it another minute or two to complete, and then try the refresh button.
A few More Minutes ... Still Working
It can take up to 5 minutes for us to download a document if the court servers are running slowly.
Thank you for your continued patience.
This document could not be displayed.
We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.
Your account does not support viewing this document.
You need a Paid Account to view this document. Click here to change your account type.
Your account does not support viewing this document.
Set your membership
status to view this document.
With a Docket Alarm membership, you'll
get a whole lot more, including:
- Up-to-date information for this case.
- Email alerts whenever there is an update.
- Full text search for other cases.
- Get email alerts whenever a new case matches your search.
One Moment Please
The filing “” is large (MB) and is being downloaded.
Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.
Your document is on its way!
If you do not receive the document in five minutes, contact support at support@docketalarm.com.
Sealed Document
We are unable to display this document, it may be under a court ordered seal.
If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.
Access Government Site
