Microsoft Excel Functions and Formulas with Excel 2019 Office 365 5th Edition Bernd Held
https://textbookfull.com/product/microsoft-excel-functions-andformulas-with-excel-2019-office-365-5th-edition-bernd-held/ From IT Pro to Cloud Pro Microsoft Office 365 and SharePoint Online 1st Edition Ben Curry
All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means without the written permission of the authors.
The example companies, organizations, products, domain names, email addresses, logos, people, places and event depicted herein are fictitious. No association with any real company, organization, people, domain name, email address, logo, person, place, or event is intended or should be inferred. The book expresses the views and opinions of the authors. The information presented in the book is provided without any express, statutory, or implied warranties. The authors cannot be held liable for any damages caused or alleged to be caused either directly or indirectly by this book.
Although the authors are members of Microsoft’s Most Valuable Professional (MVP) program, the content of this book solely represents their views and opinions about Office 365 and any other technologies mentioned in the text and is not endorsed in any way by Microsoft Corporation.
Please be respectful of the rights of the authors and do not make copies of this eBook available to others.
Fifth (2019) edition. Previous editions:
Office 365 for Exchange Professionals (May 2015 and September 2015).
Office 365 for IT Pros (3rd edition – June 2016).]
Office 365 for IT Pros (4th edition – June 2017).
This is the companion volume for Office 365 for IT Pros (2019 edition). Its content is valuable, but we do not update it as often as we do for material in the main book.
This is update 1 published on 1 July 2018. You can find information about the changes made in each update in our change log.
Chapter 1: Introduction
Tony Redmond
Welcome to the Companion Volume
The fourth edition of Office 365 for IT Pros reached 1,150 pages. Some of the material had aged a little, and some of it was not as interesting to everyone. So, we took the decision to create this companion volume and use it as a home for information that we think is still valuable and should be shared, but might not warrant a place in the main book.
Office 365 History
Office 365 is not Microsoft’s first cloud platform. In fact, Microsoft got into the cloud application game in 2005 when it started to provide a managed service for Exchange to some customers. The first public information about this effort appeared in October 2007 when Microsoft announced “Exchange Labs”. Among other features, Microsoft said that Exchange Labs supported 5 GB mailboxes and used SSL to secure client communications. The commercial launch followed when Microsoft brought this effort forward into Business Productivity Online Services (BPOS), launched in 2008. BPOS included Exchange Online, SharePoint Online, Office Communications Server Online (an ancestor of Skype for Business), Forefront (anti-virus), and Office Live Meeting. Collectively, this set of applications was referred to as Microsoft Online Services.
The technology used by BPOS was an adapted form of the software sold at the time to on-premises customers as Exchange 2007, SharePoint 2007, and so on.
The big difference between Office 365 and BPOS is the stability and robustness of the current platform, largely due to the maturity of the workloads now running inside Office 365 combined with a highly developed automation framework to orchestrate operations. In a nutshell, BPOS was an example of how to take software designed to be deployed in a traditional on-premises environment and bend it so that it functioned in a multi-tenant infrastructure accessed through the Internet. The problem was that “bending” the software often made things break simply because the software was not designed to cope with the stresses and pressures generated by large-scale multi-tenant operations.
Office 365 is built around software designed with the unique demand of cloud-
scale operations in mind, so its delivery and reliability record is much better than BPOS ever managed. Still, BPOS proved to be extraordinary useful to Microsoft in educating engineers about how to build software to function in cloud environments, even if its reputation suffered due to the relatively poor performance against the Service Level Agreements (SLA) negotiated with customers. The value of attributes such as automation, simplification, and standardization quickly became recognized and valued through working through the trials and tribulations of BPOS. What’s absolutely certain is that without the experience gained through working through real-life customer deployments of BPOS, Microsoft could not have achieved as much as they have with Office 365 since.
A remnant of Exchange Labs: If you look at the properties of a mailbox, you’ll see that the LegacyExchangeDN property still has its roots in Exchange Labs. For example, you might see a value like this:
/o=ExchangeLabs/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/ cn=Recipients/cn=yourdomain.onmicrosoft.com-52094eea20
Apart from Exchange Labs, the other bit of Exchange history is the fact that an administrative group is still specified. Administrative groups appeared as a unit of server management in Exchange 2000 and were phased out in Exchange 2007. However, the LegacyExchangeDN property goes back even further to the X.500-like directory structure used by the first generation of Exchange (4.0 to 5.5 in 1996-99). All of this goes to show that you can’t really discard history too easily.
Although BPOS provided a healthy dose of customer reality to Microsoft’s engineers, you cannot take too many risks with a production offering. Microsoft therefore continued to operate “Exchange Labs” alongside BPOS to conduct experiments at scale and learn just what it took to transform Exchange from a somewhat stodgy but powerful email and collaboration server into software that could function in the cloud. Exchange Labs was the playground while BPOS attempted – sometimes quite well – to deliver a commercial offering, even if it was handicapped by its enterprise heritage. Together, BPOS and Exchange Labs constituted the greenhouse for what later evolved into Exchange Online and an operations framework that permeates throughout Office 365.
During the same period as they were figuring out how to execute their initial
cloud deployment strategy, the Exchange product group made a big bet on PowerShell by using it for many administrative operations in Exchange 2007. Exchange was the first major Microsoft server application to use PowerShell so extensively and did so at a time when “Monad” (the original code name) was often derided as a poor combination of UNIX-style scripting and impenetrable syntax. As it turned out, PowerShell has made a huge contribution to the success of Exchange in the cloud and Microsoft uses PowerShell scripts to automate many common administrative operations that run inside Office 365.
Office 365 is not Office 365: The power of marketing means that the Office 365 name is applied to a number of Microsoft offerings. This book is about Office 365 for business and not Office 365 Home (a five-user license for the Office desktop applications) or Office 365 Personal (a one-user license for the Office desktop applications). Both are worthy in their own right, but they have nothing to do with Office 365 cloud-based application services like Exchange Online.
Technical steps along the path to the cloud
Important as PowerShell is to Exchange Online, it’s not the only area of technical innovation that has allowed Microsoft to transform the enterprisecentric traditional-deployment model used by Microsoft on-premises server products into today's Office 365. Many threads have come together to deliver that work, many of which started in the 2003-2005 timeframe. Although you might delight in the notion of a grand technical plan that has come together to deliver Office 365, it’s much more of a case of blessed serendipity allied to some great engineering and visionary work delivered over a series of server versions.
The two base Office 365 workloads are Exchange and SharePoint. Thw two products share a common history in that SharePoint Portal Server 2001, the first version of SharePoint, used the Exchange ESE database engine. SharePoint subsequently moved to the SQL database engine and has used it since. Each of the two workloads has its own history and timeline in progressing from a product embedded in an on-premises ecosystem to becoming a cornerstone of Office 365. Table 1-1 outlines the areas of technical innovation in different versions of Exchange and notes why each area is critical to what we use today in Office 365.
Technical
innovation When introduced
Why important to Office 365
PowerShell Exchange 2007
Autodiscover Exchange 2007
ActiveSync Exchange 2003 SP1
The basis for automation of many common management operations. Remote PowerShell was introduced in Exchange 2010 and is used with Exchange Online and other applications.
Allows clients to connect to Exchange Online without knowing details of server names etc.
Although its importance to Office 365 lessened after the introduction of the Outlook apps for iOS and Android, ActiveSync is the de facto standard for mobile connectivity to Exchange Online.
Role Based Access Control (RBAC) Exchange 2010
Allows granular access to user and administrator functionality. Also used to control the display of UI in OWA and the Office 365 administration portals. Outlook
The original Exchange Web client goes back to 1997 and has evolved dramatically since to keep pace with web developments. Outlook Web App supports premium access to Exchange Online from Chrome, IE, Firefox, and Safari browsers and downgraded access for other browsers.
RPC over HTTP MAPI over HTTP Exchange 2003 Exchange 2013 SP1
Exchange Web Services (EWS) Exchange 2007
RPC over HTTP (Outlook Anywhere) removed the requirement for VPN connectivity to email servers across the Internet. Without it, you’d have to create a VPN to connect to Exchange Online. MAPI over HTTP is a more modern and effective replacement.
Allows programmatic access to items in the Exchange Store without having to resort to the far more complicated MAPI API. Although the Microsoft Graph is a more modern API for Exchange along with other Office 365 components, EWS persists and is used in migration and backup products for Office 365. ESE is the engine that lies at the heart of the Exchange
High Availability Exchange 2007
Information Store and has been extended and refined for more than 20 years to arrive at the point where 100GB-plus mailboxes are usable. Another important aspect is the work done in the 2004-2012 timeframe to drive the storage I/O profile of Exchange from being a fat slob to a svelte service and so enables the ability to exploit low-cost storage that delivers massive mailboxes at a very low price point.
The first HA implementation allowed just two copies of a database. The introduction of the Database Availability Group (DAG) in Exchange 2010 expanded this to 16 copies and introduced features like the lagged copy, single page patching, automatic failover, and so on. Exchange 2013 continued to improve matters with database autoreseed and greater automation to manage lagged database copy, including the introduction of the Replay Lag Manager in Exchange 2013. The HA features allow Exchange Online to operate with a basic model of four database copies spread across two datacenters (or more) and ensure that the 99.9% SLA is met or exceeded.
Managed Availability Exchange 2013
Some self-healing capabilities were introduced in Exchange 2010 but Managed Availability took the idea that servers could monitor their own health and take action when required to fix a failed component to a new level. Even if on-premises administrators don’t like its influence over servers very much, Exchange Online might not be manageable without this degree of automation.
Workload management (throttling) Exchange 2010
Modern public folders Exchange 2013
Multi-tenant environments operate on a fair usage basis. In other words, the workload of a single tenant should not be able to unduly affect others. Workload management makes this so.
Without a modernized version, on-premises customers who had invested heavily in the cockroaches of Exchange would never be able to move to the cloud.
Table 1-1: Technical innovation in Exchange that help Exchange Online work
Some technology developed for Office 365 is difficult to move to on-premises versions. The automatic filtering of inbound email performed by the Focused Inbox and the Teams, Planner, and Delve Analytics applications are examples of Office 365 software that will probably never run in a pure on-premises environment. On the other hand, as demonstrated by the hybrid features in SharePoint 2016 (hybrid sites, search, and OneDrive sites), it is possible to provide data taken from on-premises servers and process them in the cloud.
A number of reasons can exist to prevent the transfer of cloud-based software to on-premises deployments, including:
The technology is complex to deploy and requires substantial effort to sustain in production. Integrating different pieces of software together so that they all work as planned is often difficult when software changes all the time. Traditional IT discipline focuses on structured updates performed in change windows, something that doesn't work quite so well given the need to execute updates across many moving parts.
The technology requires a high cost in infrastructure (servers, network, storage, and automation) to deploy and keep running, which implies a high cost barrier. Applications that depend on machine learning and artificial intelligence are often difficult to deploy in an on-premises environment because of the resources they consume.
The technology needs to be fine-tuned on an ongoing basis to improve its performance and, in some cases, accuracy. This work usually requires engineers to be able to make frequent and ongoing software changes. Less importantly, the technology requires a skill set that might not be feasible to expect within customer environments.
Remember, Microsoft is able to operate and develop Office 365 by employing the full resources of the company in addition to a massive financial commitment to build out the infrastructure. It’s almost inevitable that some components developed for and implemented first in Office 365 will prove just too complex to transfer, but the good thing is that Microsoft has built a strong track record of transfer from cloud to on-premises and nothing indicates that this trend will not continue.
The importance of technology transfers to on-premises versions: Although onpremises customers often complain – sometimes bitterly – about the way that
features show up in Exchange Online and not in the latest on-premises update, it is undeniable that Microsoft has done a good job of transferring technology developed to help run Exchange Online at scale to on-premises customers. Most of the work transferred to date has been directed to Exchange 2013; even more is included in Exchange 2016. Although the nature of cloud services means that they will always be ahead of on-premises equivalents, the real question is how quickly will on-premises customers deploy the new versions to take advantage of the technology transfer? Traditionally, new server versions take several years before they reach general deployment across the entire customer base.
Wave 14: Office 365 launches
Microsoft put all of the experience gained in BPOS to advantage when it designed Office 365. When launched, Office 365 used the “Wave 14” set of Office server products that shipped to customers as Exchange 2010, SharePoint 2010, Lync 2010, and so on. The big difference was that Microsoft had had several years of operational experience to better understand the demands of the cloud. More automation was incorporated into the products, the code base was simplified, the economics were better, and great attention was paid to all aspects of design, build, and operation.
Another important point in the evolution of Office 365 was the adoption of a software development method based on the DevOps concept. In effect, this means that engineering group responsible for the development of Exchange are the go-to people for problems. In other words, if code fails then it is the engineer who wrote or maintains the code who has to wake up from blissful slumber to fix the problem. There’s no doubt that the direct association between code quality and responsibility for maintenance influenced the way that engineers created features. It’s obviously important for engineers to take personal pride in creating the best possible code at all times, but it becomes terribly personal for an engineer when they are hauled in at 3am to fix an irritating bug.
Some initial glitches occurred in Office 365 that interrupted service to customers in August and September 2011, but broadly speaking the performance, reliability, and scalability of the service has proven to be excellent. We will discuss how Office 365 measures performance against service level agreements in Chapter 2.
Exchange 2010 introduced a number of important technical advances that have contributed greatly to the subsequent success of Exchange Online. The Database Availability Group (DAG) is the most important because it allows Office 365 to
operate a highly available infrastructure for mailboxes. Exchange Online now spans several thousand DAGs positioned in Office 365 datacenters around the world; each database has four copies including a lagged copy; and the high availability features built into the DAG allows work to be transferred quickly and dependably to another server should a problem arise. It also underpins the concept of “native data protection”, meaning that Exchange Online does not use traditional backups to protect data. Instead, a combination of Exchange features such as user-driven recoverable items, single item retention, and multiple database copies protect user data so that it can be recovered in the case of inadvertent loss.
Apart from making sure that mailboxes stay online, the DAG also contributes to the economics of Office 365 by allowing the use of inexpensive JBOD disks for the massive amount of storage needed to allow users keep all the information they want inside massive mailboxes. The economics are such now that it is much cheaper to allow users as much storage as they want rather than invest in the time to manage storage. Gigabytes of storage cost a fraction of a penny per month (amortized over 24 or 36 months) when bought in the quantities consumed by cloud datacenters, so the fact that someone is using a 100 GB mailbox that costs a few cents for the storage is nothing when put into context with their monthly payment. The same is true for other services like OneDrive for Business or the consumer email services where the providers are happy to have users consume large amounts of storage in return for the chance to sell other services. Of course, cloud providers incur massive additional costs other than storage, but it is interesting to see how storage has become so cheap and plentiful in such a short time and the influence this has had on data management. Since its introduction, the DAG has steadily added features to improve its ability to support low-cost disks. For instance, single page patching arrived in Wave 14 to allow Exchange to detect and patch corrupt pages that appear in both active and passive database copies. Without single page patching, human administrators would have to take problematic databases offline and fix them manually. Traditionally, this would have been done by restoring a backup copy, but these don’t exist inside Office 365. Database autoreseed is another example. Introduced in Wave 15, this feature allows administrators to set aside disk space that Exchange can use to build a new copy of a failed database. The rebuild happens automatically, which is exactly what you need when the use of low-cost disks makes it easy to predict that disk and controller outages will be the most common form of failure inside Office 365 datacenters. And, as it turns out, they are.
Microsoft also introduced the Mailbox Replication Service (MRS) in Wave 14. Not quite as exciting or as technically compelling as the DAG, MRS still plays an enormous role through its ability to move mailboxes from on-premises servers to Office 365. The transfer is highly automated, batch-driven, happens in the background, and includes automatic delta synchronization to maintain the copied mailboxes in a current state until the switchover occurs. If MRS didn’t exist, it would be very much harder for large companies to transfer mailboxes to Office 365.
Wave 15: Cloud-Ready by Design
In late 2013, Microsoft launched the next generation of Office 365 based on the “Wave 15” set of Office servers. By this time the developers had gained an enormous amount of operational experience from BPOS and the first iteration of Office 365 and had factored it into the development of Exchange 2013. Wave 15 marked the first time that Office 365 moved ahead of on-premises products in terms of introducing new code into production. From this point on, new features appeared in the cloud first and then in an on-premises release.
A common code base was reintroduced to unite the cloud and on-premises versions of Exchange and a new supportability model was introduced where Microsoft shipped a cumulative update to Exchange on-premises customers every quarter that contained bug fixes and new features proven in Office 365. On-premises customers didn’t get every new feature because some depended on non-Exchange components (see below) but a continual flow of information from “the service” (the term used by Microsoft employees to refer to Office 365) is used by the developers to improve and refine on-premises Exchange.
Managed Availability is a Wave 15 feature that is also a good example of how Microsoft has transferred technology from the cloud to on-premises Exchange. Today, Microsoft operates over 200,000 Exchange servers inside its Office 365 datacenters. It would be impossible to have human administrators monitor the mailbox and other servers at the scale used by Exchange Online and be expected to detect and take rapid action when problems occur. Indeed, given the need for humans to sleep and our tendency to lose interest in boring and repetitive actions, many issues that occur on servers would go unnoticed. Managed Availability gathers a vast amount of health signals from its probes running on every Exchange server, decides whether the data indicates a problem, and responds to any problem that is found, all without human oversight or intervention. The idea is that Managed Availability should be able to take care of routine and common issues, leaving the most complex and difficult problems for
humans to solve.
Features such as database autoreseed, namespace rationalization, and the simplification of the DAG are other examples of how Office 365 has influenced the evolution of on-premises Exchange. Customers have also gained through the ten-year development effort to transform the disk and storage requirements of Exchange from a point where deployments required expensive “enterprise-class” disks to today where inexpensive JBOD-style storage is the norm. Microsoft had to change Exchange to be less of an I/O hog to make it feasible to use Exchange for cloud-based email. After all, if you need expensive disks, you won’t be able to offer users 50 GB mailboxes at the kind of price points that Office 365 charges today.
The change that occurred in client focus is also worth noting. Whereas Outlook remains the single most popular client used to connect to Exchange Online, its Windows-centric development model means that it is slow to adapt and change, especially in the context of a fast-moving cloud service. The problem is simple: it takes Microsoft far more time to update the Outlook user interface to introduce new features and even longer for customers to deploy the new software to user desktops than it does to make a change to the browser components that drive Outlook Web App.
Microsoft transformed Outlook Web App in the Wave 15 release. Some of the updates seemed retrograde at the time because functionality was reduced and performance was poor, but change was necessary to deliver a user interface that was capable of working on PCs, tablets, and “candy bar” smartphones. Over time, missing features have largely been restored alongside a range of new features and performance has steadily improved. Indeed, the rate of change in Outlook Web App and the difference that opened up between the version available to Office 365 users and that provided to on-premises Exchange customers made it obvious that Outlook Web App is regarded almost as an experimentation platform for Office 365. In other words, Outlook Web App is the client that Microsoft can use to introduce new features in a rapid manner, even when those features are not fully complete. Outlook is the more popular client, but it lags in the functionality stakes and is likely to always do so until customers adapt the “Click to Run” variant and accept the fact that desktop user interfaces are liable to change on almost a monthly basis – at least, when connected to Office 365.
After the transit to the Wave 15 products was complete, signs of the growing maturity of the platform can be seen in a growing concentration on technology
designed to function across the service. New features are developed for applications like Exchange but an increasing effort is dedicated to functionality that draws upon multiple parts of Office 365 such as Office 365 Groups, the Security and Compliance Center, and Delve or support functions like Unified Auditing. The provision of a suite of REST-based APIs gives programmers a consistent method to access and exploit various forms of Office 365 data, including the signals representing user activities that are accumulated in the Microsoft Graph.
Wave 16: Now in production
The Wave 16 set of the on-premises Office products first shipped to customers in October 2015. This wave includes Exchange 2016 and SharePoint 2016 as well as the Office 2016 desktop suite. Although the new generation of server products underpinned increased reliability and robustness in the base workloads, the appearance of “cloud-only” applications is the most interesting development during this period. Teams, Planner, Flow, PowerApps, Sway, and StaffHub are some of the examples of major change within Office 365 that will never appear on-premises.
During this time, Microsoft consolidated its cloud properties to bring Outlook.com to the Exchange Online infrastructure. The consumer and business email applications share the same servers, storage, and software base with functionality delivered to end users being controlled by different license tiers. OneDrive and OneDrive for Business also share many components. A good example fo the value of shared infrastructures is seen in the transfer of functionality between consumer and business applications, such as OneDrive’s Restore Files feature and Exchange’s Encrypt email feature, both of which are available across consumer and business platforms.
Another major change is the leaving behind of workload-specific compliance. Where SharePoint had the eDiscovery Center and Exchange had its eDiscovery searches, the Office 365 Security and Compliance Center became the focus for platform-wide compliance functionality. Not only does the new technology work for the base workloads and new applications, it introduces new features like manual disposition, event-based retention, and supervisory policies.
The Security and Compliance Center has taken over some functionality previously managed by Exchange like anti-malware. This is also part of a trend to move functionality away from workload administrative portals to Office 365 administration portals. You still need to use the Exchange Administration Center
or SharePoint Administration Center (now refreshed), but not as often as you used to, and you will visit them less in the future.
Finally, this wave marks the beginning of the transition from Skype for Business Online to Teams and the Microsoft Phone System. The roots for Skype for Business Online are in a long line of on-premises servers. The new voice and video platform is cloud-only and shared with the Skype consumer application. The new platform is more adaptable to the changing needs of businesses for voice and video communications, but the transition to Teams will take some years yet.
The Next Wave
With so much happening in Wave 16, speculation inevitably turns to what might happen in the next wave of product development. For on-premises customers, the answer lies in the 2019 generation of the Exchange, SharePoint, and Skype for Business servers. These products remain good at what they do and deliver good value to customers if they simply want an email server, a document management server, or a communications server.
The difference in the cloud is integration. Office 365 is a fabric that gives development groups a toolset to build new applications and functionality around. Teams is a great example of how to bring components from across Microsoft’s cloud properties together to create a new application. The intermingling of components from different places within Office 365 is a trend we can expect to continue.
The role of Exchange and SharePoint, the two basic workloads in Office 365, has diminished in some respects as Office 365 evolved. Exchange was the king in the early days of Office 365 because email was the first and easiest workload to move to the cloud. SharePoint followed as migration tools matured and customers became more used to the idea of managing documents in the cloud. Both applications came from a position on-premises where they sat at the center of ecosystems, surrounded by people and other applications. It is very different inside Office 365.
Today, Exchange is no more than an email server for Office 365 that happens to provide a convenient way to store some information (like Teams compliance records). SharePoint manages documents for other applications and itself. The focus is no longer on Exchange or SharePoint; it has shifted to the integration of the base workloads into other applications. Thus, we see Exchange deliver shared mailboxes to Teams and Groups, and SharePoint give Teams and Planner
a convenient place to store documents uploaded to these applications. Exchange and SharePoint are still extraordinarily important to Office 365 and every Office 365 administrator should understand how to manage these applications. This need will continue, but might become less critical as time goes by as Microsoft automates and simplifies cloud operations. There’s lots more to learn and master in your Office 365 journey, including:
Azure Active Directory (basic operations, plus extended functionality like conditional access policies).
Azure Information Protection. Teams. Planner.
Flow and PowerApps.
Enterprise Mobility and Security, including InTune. PowerShell and the Microsoft Graph to automate/script operations.
When we set out to write the first edition of this book in 2014, none of the topics listed above apart from PowerShell were covered. Now, they’re fundamental parts of the Office 365 landscape. It’s enough to keep everyone busy.
Microsoft 365
From a business perspective, the bundling of Office 365 into Microsoft 365 is the most important influence on Office 365 for the immediate future. Microsoft has invested heavily in cloud infrastructure to build out its datacenters and networks to support Office 365 and Azure. The need exists to achieve a return on that investment, and that means that Microsoft must continue to grow the number of paid subscriptions for Office 365 and increase the annual revenue for each subscription. Growing the revenue per seat is done by convincing customers to upgrade their subscriptions to a higher-priced plan (from E3 to E5, for example) or by buying add-ons for specific functionality. Many of the new features being added to Office 365 now require E5 licenses and a growing gap is developing between the functionality available to E3 and E5 tenants to justify the extra cost of E5 licenses.
Convincing Office 365 customers to embrace Microsoft 365 is another example of driving extra revenue, and to support the activity, you’ll see that Microsoft constantly emphasizes the value to customers of deploying Office 365, Enterprise Mobility and Security, and Windows 10 together. Marketing and
engineering support to illustrate the benefits of Microsoft 365 will appear in a continual flow to convince customers to embrace the program. If you want to continue using Office 365 on its own, you can, but a time might come when all you can buy is Microsoft 365.
Chapter 2: Exchange Mailbox Migration
Paul Cunningham
Office 365 is an attractive IT platform for new businesses because it avoids the time and expense of purchasing and deploying an on-premises infrastructure. A green field deployment of the core services of Office 365 is straightforward because the business is not burdened by any legacy infrastructure or data. On the other hand, organizations that have an on-premises infrastructure usually need a certain amount of planning before they can migrate anything to Office 365. For most customers, email is the first workload to move to the cloud, because the migration methodology and tools are well established and flexible enough to meet the requirements of almost any migration scenario. This chapter explores the various migration methods available from Microsoft and third parties to migrate email to Exchange Online.
Identity management is a key component of any Office 365 deployment. Many questions need to be answered about how identity will be managed during and after the migration. Of course, identity management is important from a security perspective, but it is also important to consider how it impacts the end user experience. Chapter 3 (main book) examines the different identity models available for Office 365. You should understand the material presented there before you choose a migration method. Take your time on these matters. It is possible that a specific identity model will cause you problems with your preferred migration method. Or you might choose a migration method, reach the end of your migration project, and discover that your ongoing identity needs have not been met. Be prepared to be flexible in your decision making, and if in doubt, always consider the user experience implied in your chosen approach. A poor user experience means a poor perception of the project outcome, even if the technical execution of the project goes well.
This chapter examines the decision-making process for choosing a migration method, reviews the cutover and staged migration processes, and provides an overview of hybrid configurations and other non-Exchange migration methods. Hybrid configurations are also covered in much more detail in chapter 4. You may well find that Hybrid is the best approach for your organization, but it is still well worth your time to read and understand the other options that are available, so that your decision is an informed one. Let’s begin with a look at the
different migration approaches for Exchange Online.
Migration approaches for Exchange Online
Office 365 supports a variety of migration methods. The choice of migration method is often influenced by a wide range of factors such as the chosen identity model, the number of objects (e.g. mailboxes, contacts, public folders) involved in the migration, the amount of data to be moved to Office 365, the version of Exchange (if any) running on-premises, long-term migration or co-existence requirements, whether the organization uses non-Exchange email servers, and even the budget available to spend on the migration project.
The migration methods that are available can be summarized as:
Cutover migration.
Staged migration.
Hybrid configuration.
PST-based migration.
IMAP migration.
Third party migration tools.
The best place to start is with the business requirements for the migration project. Business requirements should include factors such as the need to complete the migration by a particular date, whether a back-out option for the migration needs to be included, or if some email workload will remain onpremises. As you will see, each migration method has different benefits and constraints, and they may not all suit the business requirements of the project. Technical requirements are considered next. These often eliminate some of the migration methods and allow the organization to zero in on the feasible approaches. Figure 2-1 provides an example of the decision-making process you can work through based on your technical requirements to understand the available migration methods for your scenario. Even if you find that you meet the technical requirements of a migration method, you should continue to research the actual processes involved in performing that migration, because you might still discover some undesirable element that steers you in another direction.
Figure 2-1: Decision tree for choosing a migration method
The decision-making process begins by determining which version(s) of Exchange exist in the environment (if any) because the version(s) of Exchange in use can narrow the available migration methods, or at least those provided by Microsoft. A specific question is whether Exchange 2003 or 2007 servers exist within the organization. These are now very old servers, so it is unsurprising that the need to migrate data from these servers would limit the available options. Hosted Exchange providers complicate matters further, because the hosting
provider usually limits a customer from performing the types of configuration and preparation that are required for built-in migration methods. Unless the Hosted Exchange provider is very cooperative, a third-party migration tool might be needed to migrate from a Hosted Exchange service to Office 365. That said, third party migration tools have their own set of requirements and limitations, which will vary depending on the product, not to mention the additional cost involved, which needs to be factored in to your project budget.
Table 2-1 summarizes the built-in migration methods available for different versions of on-premises Exchange. The Exchange versions listed refer to the highest version of Exchange in the organization. For example, if an organization runs a mixed Exchange Server 2010 and 2007 organization, then they can use the migration methods supported for Exchange 2010 and are not limited to the options available for Exchange 2007. Some additional requirements and constraints are mentioned in Table 2-1 that will be explained in more detail later.
Exchange Version Cutover Staged Hybrid IMAP
Exchange 2003 Yes (if under 2,000 mailboxes) Yes No (unless a Hybrid server running Exchange 2010 is deployed) Yes
Exchange 2007 Yes (if under 2,000 mailboxes) Yes No (unless a Hybrid server running Exchange 2010 or 2013 is deployed) Yes
Exchange 2010 Yes (if under 2,000 mailboxes) No Yes Yes
Exchange 2013 Yes (if under 2,000 mailboxes) No Yes Yes
Exchange 2016 Yes (if under 2,000 mailboxes) No Yes Yes
Table 2-1: Available migration methods for on-premises Exchange versions
In addition to the built-in migration methods, you can consider:
Migrating user PSTs using the Office 365 Import Service, Microsoft’s PST Collection tool, or a third-party migration tool. PST-based migrations are discussed later in this chapter. Third party migration tools that use protocols like Exchange Web Services (EWS) to ingest data into Exchange Online mailboxes. Third party tools often provide solutions to very complex migration scenarios that built-in
migration methods cannot handle. A list of third party migration vendors is included later in this chapter.
Note: Although IMAP is included in Table 2-1, it is the least preferable migration method when you migrate from an Exchange server, and is generally only suitable when migrating from non-Exchange platforms such as Gmail or Yahoo!. We discuss the limitations of IMAP migrations later in this chapter.
The next consideration is whether there are more than 2,000 mailboxes. Organizations with fewer than 2,000 mailboxes are supported for cutover, staged and hybrid migrations, while organizations with more than 2,000 mailboxes are only supported for staged or hybrid migrations. The 2,000-mailbox limit does not mean that organizations with less than 2,000 mailboxes should automatically choose a cutover migration. For example, if the organization wants to migrate their users in smaller batches instead of one big batch then a cutover migration is not suitable.
Real World: 2,000 mailboxes is the threshold specified by Microsoft in terms of support for cutover migrations. The logistics involved in handling an outage for such a large number of users, as well as the desk-side support needed to assist with reconfiguring Outlook profiles and mobile devices after the cutover, may simply make a cutover migration too risky and complex for the organization. In fact, many experienced Office 365 consultants consider the practical limits of both the cutover and staged migration methods to be as few as 150 mailboxes. Organizations larger than 150 mailboxes should give strong consideration to using a hybrid migration instead of a cutover or staged migration.
When cutover is either not possible or not desirable for an Exchange 2003/2007 organization, the remaining options are staged and hybrid migrations. For an Exchange 2003 environment an Exchange 2010 server can be deployed to create a Hybrid configuration. If you want to use an Exchange 2013 or Exchange 2016 server to host the hybrid configuration, you will have to complete a full migration to Exchange 2010 first. For an Exchange 2007 organization at least one server running either Exchange 2010 or Exchange 2013 must be installed to provide the hybrid functionality. Both staged and hybrid options require the implementation of directory synchronization. Without directory synchronization, your migration options are limited to the use of third party migration tools.
An organization migrating from Exchange 2003 or Exchange 2007 can choose to take advantage of the free Hybrid license available from Microsoft. This license
allows an Exchange 2016, 2013 or Exchange 2010 SP3 server to be deployed in the organization to facilitate a hybrid connection with Office 365 (depending on the supported versions that can co-exist in an organization). The Hybrid license can’t be used for a server that hosts mailboxes, but the server can be used during the migration to Office 365 and retained afterwards to manage the Exchange attributes of the on-premises Active Directory objects. A server assigned with a Hybrid license can also be used as an SMTP relay server for applications or devices on the corporate network.
If the implementation of a Hybrid server is not possible, for example due to server capacity constraints, then a staged migration is the way forward. The staged migration method is not available for organizations that run Exchange 2010 or later. Exchange 2010 or later environments with fewer than 2,000 mailboxes to migrate can still choose to perform a cutover migration. However, as we’ve already discussed, large cutover migration projects can be logistically very difficult to perform.
Given that Exchange 2010 (or later versions) is capable of hybrid configuration with Office 365 you should give strong consideration to using the hybrid approach instead of a staged or cutover migration. Although hybrid is the most complex of all the migration options in terms of initial setup and configuration, it delivers the best user experience during the migration. Hybrid configurations allow the on-premises Exchange organization and Office 365 to function as though they are the same environment with seamless mail flow, a shared address book and calendar free/busy federation. In fact, most users would not even be aware that they are working in a hybrid configuration with mailboxes deployed in both on-premises and Office 365. A hybrid configuration is also the only option that allows mailboxes to be off-boarded from Office 365 to Exchange onpremises without using third party migration tools. Cutover and staged migrations can’t off-board or roll back to an on-premises server without significant effort and the risk of data loss.
Hybrid configurations require directory synchronization of the on-premises Active Directory objects into Azure Active Directory, so that they can be used in Office 365. If for some reason the organization can’t implement directory synchronization, then the choices are limited to third party migration tools.
Finally, businesses using non-Exchange email platforms such as Gmail or Google Apps for Business can’t use the cutover, staged or hybrid options. For those businesses Microsoft provides the IMAP migration option to move mailboxes to Office 365. Alternatively, a third-party migration tool can be used.
If you’re engaging the Microsoft Onboarding Center or an outside consultant to assist with the migration, they will usually recommend a specific tool or method for the migration, which will probably be the tool for which they have most experience.
All aspects of the decision-making process require careful consideration. Beyond the technical considerations are also other factors such as whether the migration project will be handled in-house or by an external consultant, whether extra training is required for IT staff to understand new features such as hybrid configurations, and whether funding is available to pay for third party migration tools if built-in migration options can’t be used.
If you want some specific recommendations to get you started, it is generally recommended to use:
Hybrid configuration for Exchange 2010 or later.
PST-based migration if a non-Exchange email system can extract data to PST files.
IMAP or third-party tools for any non-Exchange email systems that can’t extract data to PST files.
Third party solutions for very complex migration scenarios.
Note: Before you finalize your decision on which migration method to use it is strongly recommended that you read through the example migration scenarios from start to finish, so that you can learn about any risks or timing issues that you need to be prepared for. Do not start a migration before you have read through the process from start to finish at least once, and you understand the support implications of your migration method and ongoing identity management. You should also consider creating a test environment and signing up for a separate Office 365 trial tenant so that you can perform a hands-on test run of your chosen migration method.
Managing a Migration Project
Every migration project needs some degree of project management ranging from a large project with a dedicated project management team to a small project that you self-manage. Before you launch into the details of figuring out the various configuration and migration tasks it is wise to start with a project planning exercise.
During the planning phase, you should hold a kick-off meeting with the
stakeholders of the project. This will ensure that everyone has a chance to discuss what the Office 365 migration will mean for them, identify any key success criteria, and to flag any concerns or potential issues that they foresee with the migration. It’s always helpful to know what the stakeholders’ biggest worries are so that you can address them with a technical solution or simply by providing more communication about that matter.
The planning phase is also the opportunity to collect information about the current environment such as the size and number of user mailboxes, shared mailboxes, public folders, other mail-enabled objects such as contacts and distribution groups, delegates, and any applications or systems that rely on email, and network connectivity for the sites involved. If your migration is for more workloads than just email, then you can also collect information about file shares, SharePoint sites, or Skype for Business configurations that will be needed. The information collected during this stage can also feed into the decision-making process for choosing an identity model and migration method. After your planning is complete, you should begin communicating with end users about what they can expect from the migration, and give them some advanced warning about anything they will need to do as part of the migration. Good communication can be the difference between a successful project and one that is considered unsuccessful. A flawless technical migration will still attract criticism from end users if they are surprised by outages during the migration or different user experiences afterwards.
Develop a checklist of migration tasks to follow throughout your migration project. This will help you to avoid missing any crucial steps that might slip your mind during the busy parts of the migration. Every organization’s checklist will be different in some way, and if you’re doing multiple migration projects for different customers you will develop a good checklist of your own over time. Microsoft also publishes a checklist for Office 365 deployments that can be used as a starting point for creating your own.
Finally, ensure that you create a test plan based on the information that you collected during the planning phase. A good test plan describes how services are used in your organization, beyond their basic functionality. For example, testing that email works when sending to or from external addresses confirms that the basic functionality works, while testing that email notifications from your CRM work correctly is a test that is relevant to your specific organization. The more scenarios you can think of for your organization that are more than just basic functionality, the more robust your test plan will be. You can use this test plan
during the migration project to ensure that important business systems continue to work correctly, and to verify that end users will have the experience they are expecting post-migration.
Preparing to Migrate to Exchange Online
Before you can migrate to Office 365, you need to sign up for a tenant. At this stage, you can opt to sign up for a free trial that will run for 30 days, or you can decide to start paying immediately. The free trial period has full functionality, and is a chance to try out features that you are unsure whether you will need. For example, you can sign up for an Enterprise E5 trial, but then you might discover during the first 30 days that you only need E1 or E3 licenses instead.
If you are unsure of your ability to work with Office 365 and need to gain experience, it’s best to create a separate trial tenant at the start and use it to experiment with different services and settings. Then, after you’ve acquired sufficient experience, you can create a tenant that you intend to use for production services, and begin to prepare it for the migration of on-premises workload.
During the signup process, you’ll be asked where your organization is located. Selecting the right country for your organization will determine where your Office 365 tenant is located around the globe. For organizations that span multiple geographic regions you should choose the country where most of your end users will be located. In Chapter 1 you learned that Microsoft operates many datacenters in different regions to provide Office 365 service to end users. Your proximity to your datacenters is a factor in the quality of the user experience for your Office 365 services, but not a defining one. A more important consideration for organizations that reside in countries with strict data sovereignty regulations, for example Germany, is ensuring that the Microsoft datacenters hosting your services are the appropriate ones.
As you move through the signup process you will be asked to create the first administrator account for your tenant. This step also involves choosing the service domain (or tenant name) for your tenant, which is the *.onmicrosoft.com domain assigned to every Office 365 tenant. The service domain will be visible to your end users in the SharePoint Online URL, Skype for Business meeting invites, and OneDrive for Business libraries, so choose a name that aligns with your organization’s company name or brand. The service domain name must be unique within Office 365. Unfortunately, if another tenant already has the name that you would like to use there is no way to get the name
for yourself.
The service domain also cannot be changed later. Some customers make the unfortunate error of signing up for a tenant with a service domain such as “contosotest.onmicrosoft.com”, then begin using it for production services before they realize it cannot be changed. A similar naming problem can occur when the company goes through a rebranding, or is acquired by another company. If it is important to your organization to change tenant names, the only options are to perform an off-boarding migration to on-premises servers, then migrate to a new Office 365 tenant, or alternatively to perform a tenant-to-tenant migration. Both options involve considerable effort and cost, and are best avoided unless necessary. It's possible that in future Microsoft will develop a tenant renaming process that makes the situation easier for customers, but considering the complexity of Office 365 and the number of integrated services involved it could be quite some time before that capability arrives.
Real World: Companies that operate with multiple parent-child companies and different brand identities have some challenges with Office 365 tenant naming to consider. If the companies do not share an email domain or any other data and resources, then it’s feasible to consider separate Office 365 tenants. However, if there are shared domains and resources, and a single Office 365 tenant is deemed necessary, then a common approach is to use a single parent company as the tenant name, such as “contosoholdings.onmicrosoft.com” .
Adding Domain Names
Migrating to Exchange Online usually means moving across an existing email domain to Office 365, but some migration scenarios can also involve migrating to a new domain name, for example when a portion of a company is divested and moves to its own corporate brand. In either case, the domain names that will be used by email recipients need to be added to Office 365. Exchange administrators will be familiar with this requirement from managing Accepted Domains in on-premises Exchange environments. For Office 365 the domain names are used by multiple services, not just by Exchange Online, so they are managed through the Office 365 admin center and are referred to as “vanity domains”, or simply as “domains”. A domain name can only be verified in one Office 365 tenant at a time.
Domains are added to a tenant by logging in to the Office 365 admin center and navigating to Settings and then Domains. Click the Add domain button to start the wizard that will guide you through the process. As part of this process you’ll need to validate the domain by adding a record to the DNS zone to prove your
ownership and control. There are two validation records offered; an MX record, and a TXT record. Adding an MX record that points to Office 365 at this early stage of a migration is likely to cause disruption to your existing mail flow, so I recommend that you use the TXT record method instead.
Microsoft can host the DNS for your Office 365 domains. You have the option to use Office 365 DNS services, or continuing to manage your own DNS records with your existing host. For domains that are already in use by an organization there are no immediate advantages to moving the DNS hosting to Office 365, but it’s an option you might consider if you are adding a brand-new domain to Office 365 in the future, or if you want to move all aspects of your messaging service to Office 365.
As additional tasks after adding domain names to your Office 365 tenant, you can consider:
Adding administrator user accounts. Having multiple administrators in Office 365 is quite common, especially in larger IT organizations. As explained in Chapter 5 (main book), you can use different administrator roles to control the access that administrators have. Adding user accounts. This will depend on the identity model and migration approach you are using. For example, the cutover, staged, and hybrid migration approaches all have specific steps for provisioning users in Office 365, while other methods such as third-party tools might require you to manually provision the user accounts. You should check the requirements of your chosen migration method first, before you create any accounts, so that you don’t cause errors and unnecessary rework later.
Configuring the On-Premises Infrastructure
The migration service for cutover and staged migration methods uses Outlook Anywhere to connect to an on-premises Exchange server and synchronize the mailbox contents. Outlook Anywhere (also called RPC-over-HTTP in Exchange 2003) is not enabled by default on Exchange 2010 or earlier, so you need to review your server configuration and enable Outlook Anywhere. A valid thirdparty SSL certificate will also be required for your server, if one is not already installed. Self-signed certificates simply won’t work. This is a nominal cost from most certificate authorities such as Digicert. You do not need to spend thousands of dollars on a new, high-end SSL certificate just to satisfy the requirements of a migration to Exchange Online.
Outlook Anywhere requires TCP port 443 (HTTPS) to be open on your firewall and NATing or port forwarding to the on-premises Exchange server. The hybrid migration method uses Exchange Web Services (EWS), which also operates over HTTPS. EWS is used by several third-party tools as well, but you should always check the documentation provided by those vendors for specific firewall requirements. If you have not already opened firewall access for services such as Outlook Web Access and ActiveSync, then you should review your firewall configuration at this stage and make any necessary changes to allow the HTTPS connections.
The Exchange Remote Connectivity Analyzer (ExRCA) can be used to test the connection to Outlook Anywhere or Exchange Web Services so that you can verify that your on-premises infrastructure is configured correctly before you attempt any further migration steps.
Some organizations that do not already have HTTPS open for external connections to an on-premises Exchange server may resist the notion of opening firewall ports to the entire world. In such cases the firewall access can be restricted to the IP address ranges for Office 365. Using IP address filtering may be an acceptable temporary measure while the migration is performed, but it becomes difficult to maintain this configuration over a long period due to the rate of change that occurs with the Office 365 IP address ranges. Firewalls that can only filter based on IP addresses may require changes as often as weekly. Firewalls that can filter based on FQDNs, or DNS names, will require far less maintenance on an ongoing basis.
Creating Migration Service Accounts
For cutover and staged migrations, the Office 365 migration service needs a set of user credentials to connect to your on-premises organization and access mailboxes. It is recommended to create a dedicated service account for this purpose. Service account requirements for Hybrid scenarios are covered in chapter 4.
The first step is to create a new service account in the on-premises Active Directory with a meaningful name, for example “O365Migration”. Make sure that this account has a strong password, and set the password to never expire so that you can avoid problems if you have a password policy in Active Directory that would expire the password before the migration is complete.
One method suggested by Microsoft’s TechNet documentation to grant the service account the necessary permissions is to add it to the Domain Admins
group in Active Directory. However, this makes the account very powerful and increases the risks if the credentials are compromised, so it is not recommended. A lower risk approach that aligns with best practices is to grant the user permissions only to the mailboxes in Exchange. You can perform this on each mailbox, or on each mailbox database. The advantage of doing it at the database level is that any new mailboxes created after the permissions are granted will automatically inherit the required permissions, while the per-mailbox method requires you to manually add the permissions to any new mailboxes created later.
To grant the service account permissions for a mailbox database, you can run this command.
Applying the permissions at the database level is simpler, however, if you decide to grant the service account permissions for each mailbox instead you can run a single PowerShell command.
Note: If you are migrating from Exchange 2003, PowerShell is not available to run the commands shown above. Instead, you can use the Exchange System Manager console to add the permissions to each database.
Reducing the Migration Load
The more data that is migrated to Exchange Online the longer it will take. To enable a speedier migration, you can undertake a clean-up process to reduce the overall size of mailbox data that will need to be migrated. Emptying deleted items from mailboxes is a quick win, and in some customer environments I’ve worked in this has reduced the overall load by as much as 20%. Aged data is also a prime candidate for clean-up. If emails older than a certain number of years are no longer required, then retention policies can be used to remove them from the on-premises mailboxes ahead of the planned migration.
One of the most common causes of skipped items during a migration is the size of the item itself. Office 365 has an advertised, default per-item size limit of 25 MB, which amounts to approximately 35 MB once the combined size of the message contents, file attachments, and other metadata are considered. Administrators can increase this up to 150 MB (see Chapter 17 of the main book) to allow larger email attachments to be sent and received.
Another random document with no related content on Scribd:
zelfs de geheele kop ontbreekt: oester en mossel zijn koplooze weekdieren en, als zoodanig, geestelijk ongetwijfeld de minderwaardigen van de geheele familie.
Toch hebben zij zich tegen de gevaren voor hun weeke lichaam weten schadeloos te stellen, door de afscheiding van een schelp aan de buitenzijde van hun lichaam en daarom noemt men ze schelpdieren. Om te verklaren, hoe zij in het bezit van die schelp gekomen zijn en ook om de overige organisatie duidelijk te maken, zullen wij de mossel eens wat van naderbij bekijken, met behulp van fig. B op bladz. 12
Het dier is tusschen de twee platen van de schelp besloten als een snede ham tusschen twee sneden wittebrood en nog treffender kunnen wij het geheele dier vergelijken met een boek, dat wij thans willen doorbladeren, om er zijn signalement uit te lezen. De schelpkleppen (Sch.) stellen dan den band voor en evenals deze, zijn zij in den rug beweeglijk met elkaar verbonden door een soort van scharnier, dat in fig. C, op bladz. 13, de linkerschaal van de Venusschelp, bij a te zien is. Bij een levend dier kunnen die kleppen met alle macht tegen elkaar aangedrukt worden door de samentrekking van twee stevige sluitspieren, die dus, bij het openen van een oester of mossel, eerst met een mes doorgesneden moeten worden en wier aanhechtingspunten wij, tegen de binnenzijde der schelpkleppen, duidelijk kunnen zien (fig. C bij g). Doch rondom de buitenranden van het slot is de zeer veerkrachtige slotband bevestigd, waarvan wij in fig. B bij Sch. en in fig. C bij c de aanhechtingsplaats zien en die de beide kleppen, door zijn veerkracht, van elkaar tracht te trekken. Wil het dier dus de schelp openen, dan behoeft het de inwendige sluitspieren slechts een weinig te laten verslappen, en daar dit bij het doode dier van zelf gebeurt, ziet men, dat dan de schelp steeds „gaapt”, open is. Slottanden (Sb.) van de ééne schelp grijpen in holten van de andere, om het verschuiven te beletten.
B
Dwarsdoorsnede van een mossel (Schets)
Als wij nu den band van het boek opengeslagen hebben, beginnen wij met de lezing en wij ontmoeten dan weer aan beide zijden een
Fig
blad, het titelblad en het achterste blad, en wel: de beide helften van den mantel (fig. B, Mt), waarvan wij in fig. C bij h den indruk op de schelp en bij c een inbuiging voor de straks te noemen adembuizen zien. Dezen mantel vinden wij, in verschillenden vorm, bij alle weekdieren weer, het is een kenmerkend orgaan voor deze afdeeling en wordt zoo genoemd, omdat hij het geheele lichaam binnen de mantelholte (Mh. fig. B) inhult. Die mantel nu scheidt aan zijn buitenoppervlakte een laag koolzure kalk af, vermengd met een chitine-achtige stof (zie bladz. 4), de conchyoline, waardoor zij minder oplosbaar in water wordt en dit is dan de schelp, die dus geheel en al den vorm van den mantel weergeeft.
Fig C
Linkerschaal van de Venusschelp.
Doch wij zetten de lectuur van ons boek voort. Binnen den mantel volgen nu aan weerszijden weer twee bladen van het boek: de plaatvormige kieuwen, die voor de ademhaling dienen (fig. B bij K), waartoe het water door de schelpspleet in de mantelholte gevoerd wordt, tengevolge van een strooming, veroorzaakt door de beweging van millioenen trilharen, waarmede de binnenzijde van den mantel bezet is. Naar den vorm der kieuwen wordt deze klasse ook wel de plaatkieuwigen genoemd.
Binnen de kieuwen volgt eindelijk de eigenlijke tekst van het boek, de romp van het dier (R) en in dien tekst lezen wij nu verder het volgende. Bij D zien wij eenige doorgesneden gedeelten van den darm, die het voedsel verteert, dat met het ademhalingswater naar binnen komt en uit fijnverdeelde of kleine plantjes of diertjes bestaat. Het dier heeft dus geen kaken of kop noodig, maar natuurlijk wel een mond, die—hier wel eenigszins misplaatst—vlak bij den voet gelegen is. Zoo noemt men het dikke en gespierde, kielvormige orgaan (fig. B bij F), dat een verlengsel van het lichaam is en zich
sterk kan uitzetten, tot buiten de schelp, en daarna weer samentrekken, ten einde de schelp in het zand of den modder— uiterst langzaam—voort te bewegen, als ’t ware voort te „ploegen”, waarbij zij dan ook een duidelijke groef of vore achterlaat. Sommige schelpdieren brengen het in die uitzetting en samentrekking van den voet zelfs zoover, dat zij over den bodem voort kunnen springen. Door middel van datzelfde orgaan kan de mossel de schelp eerst op haar kant zetten, zooals de vijvermossel op de plaat bij figuur 4 en haar dan zéér langzaam—dikwijls eerst na eenige uren!—bijna geheel loodrecht in den modder of het zand graven, waar het dier dan meestal onbeweeglijk blijft zitten.
In die positie zou onze vijvermossel het spoedig te benauwd krijgen, door gebrek aan versch water en zuurstof voor de ademhaling, doch ook daarin is op praktische wijze voorzien. Tusschen de beide kleppen der schelp is, aan de achterzijde, de rand van den mantel tot twee buisjes uitgegroeid (in fig. C, bij i), die adembuizen of sipho’s genoemd worden en waarvan de onderste dient, om het versche water, met het daarin aanwezige voedsel, toe te laten, de bovenste om het onbruikbare water, met de spijsresten, af te voeren. Bij sommige mossels, die zich soms geheel in het zand onderploegen, zijn die sipho’s zeer lang, zoodat zij tot boven de zandlaag in het water uitgestoken kunnen worden. De vijvermossel is vrij groot (10 centim. lang), breed ovaal van vorm en de schelp is dun, groenachtig bruin van kleur, met groene stralen en bruine dwarsbanden. Het slot heeft geen tanden. Zij komt in onze vijvers veel voor en plant zich, zooals alle oesters en mossels, door eieren voort, waaruit zich nog binnen de kieuwplaten de larven ontwikkelen, die reeds een schelpje bezitten en heel wat beweeglijker zijn dan de moeder. Uit de ademhalingsruimte naar buiten in het ruime sop gekomen, zwemmen zij daar eerst geruimen tijd lustig rond. Dan hechten zij zich aan visschen vast en laten zich door dezen nog maandenlang door het water spelevaren, totdat de zwaarte van hun schelpje hen dwingt die levende plezierjachten los te laten en zij op den bodem van het water vallen.
In onze binnenwateren komt bijna overal ook de riviermossel (Dreissena polymorpha), fig. 5, overvloedig voor, die veel kleiner is dan de vorige en uiterlijk wel eenigszins op onze gewone eetbare
mossel gelijkt, tot wier naaste familie zij dan ook behoort, ook door een bijzonderheid, die aan alle echte mossels eigen is. Zij bezitten namelijk, dicht bij den voet, een klier, waaruit een kleverig vocht afgescheiden wordt, dat, bij aanraking met het water, tot een bundel van 100 tot 200 strak gespannen draden stolt, die men „baarddraden” of „byssusdraden” noemt en waarmee de schelp zich aan de steenen vasthecht, terwijl daardoor ook de riviermosselen zich dikwijls in grooten getale aan elkaar vasthechten en opeenhoopen. De vorm van deze schelp is driehoekig, schuitvormig, groenachtig geel van kleur met bruine golvingen, de mantel is over zijn geheele lengte vergroeid, behalve de openingen voor de adembuizen en den voet. Deze schelpdieren verplaatsen zich veel meer dan de vijvermossel, zooals reeds daaruit volgt, dat zij eerst in betrekkelijk lateren tijd, uit de streken rondom de Zwarte Zee, naar onze streken gekomen en zich hier overal verspreid hebben. Daarom noemt men ze ook wel: trekmossels. Links, in den ondersten hoek van de plaat, liggen op den bodem nog een drietal mossels van een andere soort: de rivierfijnschaal, (Pisidium amnicum), fig. 13, naar den vorm ook wel „erwtenschelp” genoemd (pisum—erwt), een kleine, gezwollen ronde schelp, met dwarse groeven over de oppervlakte en een aschgrijze tot olijfbruine kleur. De sipho’s zijn kort en vergroeid en de schelp is dikwijls zoo doorschijnend, dat men er de kieuwen en het hart van het dier doorheen ziet. De soorten van dit geslacht zijn over de geheele aarde verspreid; het zijn de kleinste van al onze zoetwaterschelpen en de kleinste soort is een ware dwerg en niet meer dan 2 millim. lang.
Wij vinden op onze plaat ten slotte nog vertegenwoordigers van een andere diergroep afgebeeld, die insgelijks tot de weekdieren behoort, doch tot een geheel andere klasse dan de mossels, n.l. tot die der
SLAKKEN.
Zij staan, in alle opzichten, op een veel hoogere sport van de ladder dan de schelpdieren, al ware het alleen reeds door het bezit
van een kop, met beweegbare voelhorens en oogen; vergeleken met een dommen oester of mossel is een slak, in haar soort, althans reeds een genie. Ter opheldering van haar lichamelijke ontwikkeling, maken wij gebruik van de schets in fig. D, hoewel dit eigenlijk de doorsnede van een landslak voorstelt. Doch er zijn ook zoetwaterslakken, die door longen ademen, terwijl er verder, behalve de kieuwslakken, ook nog tweeslachtige slakken bestaan, die longen en kieuwen tegelijk bezitten.
Fig. D.
Schets van een long-slak, in doorsnede.
Wat wij slakken noemen, is een eigenaardig slag van volkje. Als rechtgeaard weekdier, is het uitwendige kleedingstuk van de slak ook weer de mantel, die het geheele lichaam inhult, maar deze heeft hier een eigenaardigen vorm, namelijk dien van een spiraal (fig. D, Mt) en hij sluit bij Mh de mantelholte in, terwijl RMt den rand of zoom voorstelt. Die mantelholte vervult hier de rol van long en bij At dringt de lucht daarin, om in aanraking te komen met de, zich daarin verspreidende bloedvaten. Uitwendig wordt door den mantel, uit koolzure kalk, met veel hoornachtige stof, weer de schelp afgescheiden, die hier dus ook spiraalvormig is en den naam draagt van huisje En werkelijk huist daarin de geheele romp R, met de
ingewanden en in het, naar voren meer verwijde gedeelte, den mond van het huisje, kan zich ook de kop Ko en de voet F, die er anders buiten uitsteken, geheel terugtrekken.
Zulk een longslak veroorlooft zich de weelde van twee paren terugtrekbare voelhorens Fü te bezitten, twee kortere voorste en twee achterste langere, en daarbij komt nog, als verdere eigenaardigheid, dat boven op den top van de beide laatste de oogen, als zwarte puntjes, geplaatst zijn. Bij M zien wij verder den mond, die in het darmkanaal D voert, welks aarsopening bij A ligt. De slakken verkeeren in het gelukkige geval, dat zij, in letterlijken zin, „op een grooten voet” kunnen leven, want haar bewegingsorgaan, de voet (F) is zeer groot en gespierd en is voorzien van een breede kruipzool, onder den geheelen buik. Daarom noemt men de slakken ook wel buikpootige weekdieren.
Tot de longslakken van het zoete water behoort nu de kleine, napvormige ronde kaphorenslak (Ancylus fluviatilis), fig. 10, die slechts 4-8 millim. lang is en een slaapmutsvormig huisje heeft, dat zeer dun en hoornachtig van kleur is. Zij zit op steenen of planten in beken of rivieren, want zij houdt van stroomend water.
Een geheel andere ademhaling en levenswijze hebben de kieuwslakken, waarvan wij in fig. 9, 12 en 14 vertegenwoordigers afgebeeld zien. Kieuwen zijn de typische waterademhalingswerktuigen, maar waardoor onderscheiden zij zich eigenlijk van longen? Bij de longen verspreiden zich de bloedvaten over de buitenzijde van de oppervlakte (bij ons de vliezige longblaasjes), in wier binnenste de versche buitenlucht doordringt, terwijl bij de kieuwen de lucht, die in het water is opgelost, de deelen, waarin zich de bloedvaten verspreiden, uitwendig omspoelt. Om echter zooveel mogelijk aanrakingspunten tusschen de lucht en het bloed te hebben, moeten hier de deelen, waarin zich de bloedvaten verspreiden, een groote oppervlakte aan het water aanbieden en in den regel is dus de oppervlakte, waarin die bloedvaten gelegen zijn, door een groot aantal sterk vertakte, fijne huidplooien, aanzienlijk vergroot.
Doch een bijzonder geval vertoonen, onder de kieuwslakken, de pluim- of vederdragers, hieronder in fig. E voorgesteld en
waarvan op de plaat in fig. 9 de vijver-pluimdrager (Valvata piscinalis) afgebeeld is.
Fig E
De platte pluimdrager, een kieuwslak
Wij zien in fig. E, hoe hier de kieuwen zeer lang en veervormig vertakt zijn en, ver uit de kieuwholte naar buiten uitgestoken en als een opstaande piramidale vederbos, door het dier gedragen worden. De voet is klein en naar voren in twee lobben verdeeld (fig. E), het huisje is rond, kegelvormig, met vele windingen, terwijl de mond van het huisje, zooals bij vele waterslakken, bij het terugtrekken door een hoornachtig dekseltje afgesloten wordt. De kieuwslakken hebben slechts twee voelers en hier zijn de oogen aan de binnenzijde der basis van deze geplaatst.
Onder de grootste van de zoetwaterslakken behoort de levendbarende moerashorenslak (Paludina vivipara) van fig. 12 en 14, een kieuwslak met eivormigen horen en niet spitse punt en 4 tot 5 sterk gezwollen windingen of „omgangen”. De kleur is fraai glimmend, doorschijnend, geelachtig groen of bruin, met donkerbruine banden over de omgangen. Fig. 12 stelt het iets kleinere mannetje, fig. 14 het grootere wijfje voor, het laatste in het huisje teruggetrokken, dat door een dik, hoornachtig, concentrisch gestreept dekseltje gesloten is. Opmerkelijk is, dat de eitjes reeds in het lichaam van het wijfje uitkomen, dat dus levendbarend is; gedurende den geheelen zomer kan men in het moederdier eieren en jongen in verschillende ontwikkelingstoestanden vinden, doch er wordt er telkens slechts één tegelijk geboren. Men vindt deze slakken in modderige, stilstaande wateren, waar zij over het slib of waterplanten rondkruipen, bij zonneschijn ook wel aan de oppervlakte komen.
PLAAT II. HET LEVEN IN SLOOTEN EN BEEKJES.
Hier hebben wij een geheel ander tooneeltje vóór ons uit het leven der waterdieren, dat zich echter ook weer afspeelt in zoet water, deels in slooten, doch voor een deel ook in kalm voortkabbelende beekjes.
En daar treft ons oog vooreerst een zonderling klein wezentje, uiterst eenvoudig in haar maaksel en bescheiden in haar optreden, maar waarvan toch een schat van wetenswaardige en interessante bijzonderheden te vertellen valt. Aan waterplanten bevestigd, zien wij, bovenaan links, in fig. 1, schijnbaar een paar onaanzienlijke aanhangsels, maar die in werkelijkheid vastgehechte diertjes zijn, die behooren tot de
ZOETWATERPOLIEPEN.
Deze vormen zelf weer een klasse van de hoofdgroep, die den weinig aristokratischen en onwelluidenden naam draagt van: holzakdieren of darmholtedieren, maar daar die term toch juist zoo goed onze bedoeling weergeeft, willen wij er in berusten en hem op den koop toe nemen. Want de dieren van deze afdeeling, waartoe ook de, nog later te behandelen, kwallen en bloempoliepen behooren, bestaan feitelijk inderdaad uit niets meer dan een hollen zak, waarin slechts enkele eenvoudige organen liggen. Fig. F op bladz. 21, die de doorsnede van een zoetwaterpoliep, in schets, voorstelt, zal ons dit duidelijk maken.
De lezer kan trouwens ook zelf dit interessante diertje gemakkelijk in zijn doen en laten bespieden. Men schept uit een vijver of sloot wat waterplanten, eendenkroos enz. op en plaatst die in een diep
bord vol water; na eenige oogenblikken van rust strekken de diertjes hun armen begeerig uit en blijven stil zitten, aan een blad of tegen den wand van het bord gehecht.
Zulk een poliep is eigenlijk niets meer dan een enkele holte of zak (fig. F, H), die van onderen gesloten en aan bladeren of stelen van waterplanten vastgehecht is en waarin alleen van boven een soort van mond (M) uitkomt. Men zal begrijpen, dat het dier in onze figuur op zijn hoofd staat, of liever, daar van een kop geen sprake is: met den mond naar beneden hangt, want in fig. 1 op de plaat zien wij, dat het, als een echte wateracrobaat, allerlei standen kan innemen en tevens, dat er zich om den mond vangarmen, in den regel 6 tot 8 in aantal, bevinden, die het dier bij die zittende of hangende levenswijze, wel verplicht was zich aan te schaffen, om
aan den kost te komen en zijn vereischt rantsoen aan versch water binnen te krijgen.
Fig. F.
Doorsnede van een zoetwaterpoliep Schets (vergroot)
Die zaak is hier namelijk volgenderwijze geregeld. Ook die vangarmen zijn hol en hun holte is, zooals wij in fig. F bij A zien, één met de lichaamsholte, waarin zij ook volkomen teruggetrokken kunnen worden. Zij zijn voortdurend in levendige beweging, waardoor een strooming van het versche water naar den mond voortgebracht wordt, niet slechts ten dienste van de ademhaling—die eenvoudig binnen in den hollen zak plaats heeft—doch ook voor den aanvoer van allerlei kleine waterdiertjes: kreeftachtigen, wormen, larven enz., waarmede het dier zich voedt. Tevens zijn die vangarmen echter, ook op meer directe wijze, behulpzaam bij het bemachtigen der prooi, want hun buitenzijde—en trouwens ook die van het geheele overige lichaam—is voorzien van talrijke
netelorganen, welke, bij aanraking, een prikkelend gevoel, als van een brandnetel, teweegbrengen, terwijl bovendien, uit kleine blaasjes aan de vangarmen, hengeldraden kunnen uitgezonden worden, zijnde lange, holle draden, met een scherp zuur gevuld, dat, bij het naar buiten slingeren, de prooi verlamt. Daar deze merkwaardige strijd- en verdedigingsmiddelen bij de geheele groep der darmholte-dieren aangetroffen worden, dragen dezen ook wel den naam van neteldieren.
De zoetwaterpoliepen of armpoliepen zijn, zoo klein als zij zijn, buitengewoon vraatzuchtig en haar honger is eigenlijk onverzadelijk. Geen prooi laten zij voorbijgaan, ook al hebben zij zoo juist haar maaltijd geëindigd. Onpartijdigheidshalve voegen wij er echter bij, dat zij, in geval van nood, ook zeer lang kunnen vasten.
Als nu het een of ander waterdiertje gevangen en door één of meer vangarmen naar den mond getransporteerd en opgeslokt is, dan komt het onmiddellijk in de lichaamsholte (H), die hier de rol van maag vervult en wier binnenwand het voedsel op dezelfde wijze verwerkt en verteert, als onze maagwanden dit met een biefstuk of kippeboutje zouden doen. De wand van den lichaamszak bestaat namelijk uit twee lagen van cellen, zooals wij in fig. F kunnen zien: de buitenste laag (aS) is zeer dun en dient als huidlaag en zij bevat de netelorganen, de binnenste (iS), van de buitenste door een tusschenruimte (St) gescheiden, noemt men de „darmlaag”, omdat zij het voedsel verteert. En deze laatste laag werkt ook krachtdadig mede tot de water-ademhaling, want haar cellen zijn met tallooze trilhaartjes bezet, die in voortdurende beweging zijn, waardoor het voedings- en ademhalingsvocht voortdurend door de geheele lichaamsholte heen bewogen wordt.
Is nu het voedsel verteerd, dan moeten de onverteerde resten ook weer uit het lichaam verwijderd worden; dit zou een lastig vraagstuk kunnen zijn, daar er zich aan de tegenovergestelde lichaamspool van den mond geen uitweg bevindt en er dus geen aars-opening is. Doch de poliep heeft dit vraagstuk, langs radikalen weg, opgelost, door den mond zoowel voor in- als voor uitgang, dus ook als aarsopening, te gebruiken en langs dezen minder gebruikelijken weg worden dus ook de uitwerpselen naar den grooten vergaarbak: het water, weggevoerd. Dit moge, voor onze begrippen, een minder
smakelijke uitweg zijn, maar nood breekt wet, en een poliep is gelukkig minder kieskeurig dan een mensch, want noch van een zenuwstelsel, noch van zintuigen zijn bij deze wezens de geringste sporen aanwezig.
De bruine armpoliep (Hydra fusca), fig. 1, op de plaat, is één van de vele soorten dezer familie, die in onze zoete wateren voorkomen. Zeer algemeen is ook de groene armpoliep (H. viridis), in wier huidcellen bladgroenkorrels voorkomen. Vroeger werden al deze dieren—zelfs nog anderhalve eeuw geleden—, en met hen ook de bloem- en koraalpoliepen, nog algemeen tot de planten gerekend, of liever: als een overgangsvorm beschouwd, want men noemde ze „plantdieren”. Niet alleen gaf de plantachtige vorm en de overeenkomst van de zee-anemonen en koraaldieren met bloemen, daartoe wel eenige aanleiding, doch bovendien herinnert de merkwaardige wijze van voortplanting der armpoliepen zeer veel aan die der planten en, evenals bij velen van deze, heeft zij op tweeërlei wijze plaats. Evenals men een geraniumplant niet alleen door bloemzaad (de eitjes) kan vermenigvuldigen, doch ook door stekken, waaraan zich knoppen bevinden, zoo brengt ook de kleine Hydra vooreerst eitjes voort, die in het water komen en daar bevrucht worden door de voortplantingsstoffen van een ander individu, doch in de tweede plaats kunnen er ook nieuwe wezens door knopvorming ontstaan. Heeft men eenige armpoliepen, met eendenkroos of waterplanten en voldoend voedsel, in water gebracht, dan ziet men, na eenige dagen, ergens aan het lichaam van zulk een diertje een kleine uitwas ontstaan (zie fig. F op bladz. 21, bij K), wier holte met die van het lichaam samenhangt en aan het uiteinde eerst armen en dan een mond krijgt. Zulk een knop laat later los en leeft dan zelfstandig verder.
Deze dieren zijn overigens zeer zelfgenoegzame en weinig veeleischende wezens, en volstrekt niet teergevoelig, want zij laten zich, schijnbaar zonder er zich iets van aan te trekken, op alle mogelijke manieren be- en mishandelen. Bepaald verbazingwekkend is hun onbegrijpelijk herstellingsvermogen; het is bijna onmogelijk, een poliep zoo te kwetsen, dat de toegebrachte wond niet in korten tijd geneest. Doch bijna ongelooflijk is het feit, dat afgesneden stukken van het dier, ja, zelfs afgesneden vangarmen, weer tot
zelfstandige en volledige dieren kunnen uitgroeien. Juist daarom heeft men aan dit nietige, onschadelijke diertje den naam van één der afzichtelijkste monsters uit de Grieksche fabelleer gegeven en het genoemd naar de Lernaeïsche Hydra, een kolossale, vergiftige veelkoppige waterslang, die in het moeras Lerna, bij Argos, leefde en die voor elken kop, dien men haar afsloeg, er twee terugkreeg, totdat zij eindelijk door Hercules gedood werd.
Fig G
Herstellingsvermogen van de zoetwaterpoliep 5 malen vergroot
Dit alles is echter nog niets bij het verbazende herstellingsvermogen van de zoetwaterpoliepen. Het was een Zwitsersch onderwijzer, Trembley, die, in het jaar 1740, dit wonderbare feit ontdekt heeft en wel: op vaderlandschen bodem, in de vijvers van het bekende buitengoed „Sorgvliet” bij den Haag. Het uiterst taaie leven van de Hydra bewees hij niet slechts daardoor, dat hij haar, zonder dat het haar deerde, als een vinger van een
handschoen het binnenste buiten kon keeren, doch dat hij het zelfs in een aantal stukken kon snijden, zonder dat het leven verloren ging, ja zelfs, dat die dieren weer tot nieuwe levende dieren uitgroeiden.
Bepaald verbluffend echter is een proefneming van den jongsten tijd, die in fig. G op bladz. 24, bij 5-malige vergrooting voorgesteld is en die genomen werd met de groene armpoliep. Uit het lichaam A van de Hydra werd bij a een stuk overdwars uitgesneden en ook uit dat, op een willekeurige plaats afgesneden, stuk ontwikkelde zich weer een volledig dier. Eerst rondde het zich af, zooals bij a, a₁ en a₂, vervolgens rekte het zich in de lengte uit (a₃ en a₄), begon daarna vangarmen te vormen (a₄ en a₅) en was eindelijk tot een nieuwe poliep (a₆) uitgegroeid.
Nog veel eenvoudiger van maaksel dan de poliepen, ja zelfs, na de mikroskopische oerdieren, de primitiefste van de geheele dierenwereld, zijn de
SPONSEN.
Daarvan geeft fig. 3 een voorbeeld uit het zoetwater, doch men ziet, dat het iets geheel anders is dan onze gewone waschspons, die wij later, in woord en beeld, aan onze lezers zullen voorstellen, zoodat wij de nadere bespreking dezer dieren tot zoolang zullen uitstellen.
Hier dus slechts een enkel woord over de gewone zoetwaterspons (Spongilla lacustris), die onregelmatige, meer of minder boomachtig vertakte korsten vormt over steenen, boomwortels, balken van bruggen of badinrichtingen enz. in rivieren, slooten of vijvers. Uiterlijk gelijken deze sponsen wel eenigszins op waterplanten, door haar geweiachtig vertakte lichamen. De takvorming is het duidelijkst in rustig water; bij sterke strooming vermindert zij en vormen de dieren—want wij hebben hier steeds met een talrijke kolonie te doen—meer onregelmatige klompen. Zulk een spons is dus eigenlijk ook een dierstok, op dergelijke wijze als
een poliepenstok, en de vermenigvuldiging geschiedt ook hier door knoppen, die met elkaar verbonden blijven en uitgroeien. De kleur is grijsachtig-wit tot geel, hier en daar ook met groene stukken.
In het inwendige van deze kolonie bevinden zich talrijke holten, zoogenaamde trilkamers, waarin, door de beweging van trilharen, het water van buiten, door kleine poriën en kanalen aan de oppervlakte, toegevoerd wordt en daarmede ook het voedsel, uit kleine waterdiertjes en rottende plantenstoffen bestaande. De onverteerde spijsresten en het verbruikte water verlaten, met den waterstroom, door groote uitstroomingsopeningen, het gemeenschappelijke lichaam weer. De eigenlijke lichaamsmassa is week, doch deze verkrijgt een zekere vastheid door de afscheiding van harde deelen, hier door talrijke kiezelnaalden. Bij de waschspons is dit een hoornachtige stof en wat wij gebruiken, is dus eigenlijk het skelet van de geheele kolonie. Behalve door knopvorming geschiedt de voortplanting ook door eieren of kiemen, dus langs geslachtelijken weg. Deze zinken ’s winters, als de diertjes zelf van de spons sterven, op den bodem en overwinteren in den modder.
In fig. 2 zien wij nog een andere soort van zoetwaterspons: de rivier-zoetwaterspons (Ephydatia fluviatilis). Zij is zeer algemeen en vormt vlakke, groenachtige korsten, die als een kussen over haar onderlaag uitgebreid zijn. Alle sponsen behooren, evenals de poliepen, tot de minst ontwikkelden onder de dieren; zij zijn zeer eenvoudig van maaksel, missen zelfs zenuwen en spieren, en ook de netelorganen van de poliepen.
Doch wij treffen op onze plaat ook nog hooger en edeler gezelschap aan en op den bodem van het water zien wij, in fig. 4 en 5, een goeden bekende: den rivierkreeft (Astacus fluviatilis). Het mag trouwens een wonder heeten, dat wij hem werkelijk nog kennen en nog wel op onze tafel ontmoeten, want dit patriciërsgeslacht onder de dieren is, evenals er reeds zoovele onder de menschen verdwenen zijn, het uitsterven nabij. Vroeger kwam de rivierkreeft, zelfs in ons land, in beekjes in Limburg en in de rivier de Berkel, tamelijk veel voor, maar nu is hij, ook in Duitschland, zoo goed als uitgeroeid, deels als gevolg eener vreeselijke ziekte: de
kreeftenpest, doch vooral ook door de onverstandige roofvangst van den mensch. Toch zijn er in Duitschland nog enkele beken en rivieren, waar die ziekte nog niet is doorgedrongen en dit is de reden, dat wij hem nog wel eens te zien—en te eten—krijgen. Over de kreeften, in ’t algemeen, hebben wij reeds vroeger, bij de vlookreeften (bladz. 3) het een en ander verteld, zoodat wij ons nu tot eenige bijzonderheden van den rivierkreeft kunnen bepalen.
De rivierkreeft is in elk geval van veel hoogere afkomst dan de nietige vlookreeftjes. Hij, en zijn welgedane neef uit de zee, de zeekreeft, zijn de edellieden van hun geslacht, ook in uiterlijk voorkomen. In hun hard uitwendig pantser, uit chitine en koolzure kalk bestaande, bezitten zij een uitstekend verweermiddel tegen vijanden en, naar het bezit daarvan, worden de kreeftachtige dieren, in ’t algemeen, ook wel schaaldieren genoemd. Daarom leeft de rivierkreeft ook gaarne in kalkhoudend water, dat ondiep en zwak stroomend is, en welks bodem hem, onder steenen en in holten, gelegenheid aanbiedt, om zich te verschuilen. Bij het levende dier heeft die schaal een groenachtig bruine, hier en daar zwarte, kleur en het is voor menigeen een raadsel, hoe zij, na het koken, zulk een prachtige roode kleur vertoont, die het dier tot een waar sieraad van onze schotels maakt. Toch is de verklaring daarvan zeer eenvoudig: de kleurstof van de schaal is een mengsel van groen, bruin, blauw en rood, waarvan alleen het laatste onoplosbaar is in water; bij het koken lossen dus al de andere kleurstoffen in het water op en slechts het rood blijft in de schaal achter.
Aan het groote voorste pantser, dat het vergroeide kop-borststuk bedekt, ziet men vooraan twee paren sprieten, een kenmerk van alle kreeftachtigen en daarvan zijn de twee binnenste kleiner en nog van 2 of 3 aanhangsels voorzien, terwijl de twee buitenste bestaan uit een breedere basis, waarop een zeer lange en dunne, buigzame draad ingeplant is. Deze laatsten vooral zijn uiterst gevoelig en daardoor van groot nut, om onophoudelijk en naar alle richtingen, te tasten en te speuren. Doch bovendien zetelt daarin ook de reuk, en hoewel dit zeker een ongewone plaats is, valt het doelmatige daarvan toch niet te ontkennen, want de dieren zijn daardoor in staat, om, reeds op een afstand, overal „den neus in te steken”. In de basis van het binnenste paar sprieten liggen de
gehoororganen. De oogen zijn zeer scherp en bovendien op beweeglijke steekjes geplaatst, zoodat zij, naar alle richtingen, terdege kunnen speuren en spieden.
Het kop-borststuk bestaat uit 13 leden, waarvan de 5 voorste de 5 paar, zeer ingewikkelde mondledematen dragen, dat wil zeggen: ledematen, die vervormd zijn tot kaken, dienende om het voedsel te betasten en verder te verdeelen, vóór het in den mond verhuist. Daarop volgen 3 leden, voorzien van zoogenaamde „kaakpooten”, die het midden houden tusschen kaken en pooten en dienen, om het voedsel van de scharen over te nemen en naar den mond te brengen. De 5 laatste leden van het kop-borststuk dragen de 5 paar stevige en krachtige borstpooten, die, behalve voor de verdediging en het grijpen der prooi, voor het loopen dienen. Op deze zonderlinge beenen stapt het dier, langzaam en deftig, gelijk een edelman betaamt, over den bodem voorwaarts, in een waren „kreeftengang”, doch niet achterwaarts, zooals de legende het veel miskende dier heeft aangewreven. Alleen als er plotseling gevaar dreigt, zwemt hij snel achterwaarts weg, want dan wordt het smallere, uit 7 leden bestaande achterlijf, dat, wegens de weekere deelen tusschen de leden, zeer buigzaam en beweeglijk en van breede, platte aanhangsels voor het zwemmen voorzien is, met kracht naar onderen, dus naar voren geslagen, waardoor zich het lichaam dan, stootsgewijs, naar achteren beweegt, hetgeen tot die verkeerde gevolgtrekking aanleiding gegeven heeft. Die beweging wordt nog bevorderd door de breede, in vijf stukken gespleten staartvin, waarin het laatste lid van het achterlijf eindigt.
Het voorste paar borstpooten draagt de geweldige scharen, die niet slechts dienen om den buit te grijpen en in stukjes te knippen, doch ook als geduchte wapens ter verdediging. Aan het 2e en 3e paar borstpooten bevinden zich nog kleinere schaartjes, waarmede de stukjes voedsel aan de kaakpooten overgereikt worden, die ze, op hun beurt, weer aan de monddeelen overhandigen. Zooals men ziet, is het een tamelijk ingewikkelde bewerking, vóór de mondvoorraad te bestemder plaatse en in goede orde bezorgd is. De ademhaling geschiedt natuurlijk bij alle kreeftachtigen door kieuwen. Deze liggen hier, als fijne vertakte plaatjes, aan de beide zijden van het kopborststuk, in de zoogenaamde „kieuwholte”. Toch
kan het dier ook, zonder nadeel, geruimen tijd op het droge vertoeven. Het kleurlooze of groenachtige bloed stroomt van het hart, dat in den rug ligt, bij de kreeften door gesloten bloedvaten naar de kieuwen; dit is een uitzondering op den algemeenen regel bij de gelede dieren, waar het bloed anders eenvoudig door de lichaamsholte stroomt. Ook in dit opzicht hebben de kreeften dus reeds een hoogeren trap van ontwikkeling bereikt.
De kreeft is een nachtdier; vandaar dat hij ’s nachts, bij het licht van een lantaren, gevangen wordt. Want over dag houdt hij zich schuil onder steenen, kribben, boomwortels enz. of ook wel in zelf gegraven holen, aan wier ingang hij, verdekt opgesteld, voortdurend zit te loeren op een voorbijtrekkende prooi, met de scharen tot den aanval of de verdediging gereed, terwijl de lange sprieten er buiten uitsteken en onophoudelijk bezig zijn, met de omgeving, in alle richtingen, te verkennen (zie fig. 4 op de Plaat). Eerst tegen het duister verlaat hij zijn schuilplaats, om een wandeling over den bodem te maken, ten einde meer doortastend naar buit uit te zien. En daarbij betoont hij zich een ware roover, want bijna alles is hem lief: levende en doode waterdieren van allerlei aard, wormen, visschen, larven, waterslakken, kikvorschen, keukenafval, ja zelfs waterratten valt hij aan en houdt deze, met zijn venijnige knijpende scharen, zoolang onder water, tot zij gestikt zijn. Zooals men ziet, is deze edelman niet bepaald kieskeurig in zijn middelen en, hoewel hij ons de heerlijkste tafelgeneugten bereidt, evenmin zwaartillend in de keuze van zijn eigen menu. In den winter vertoeft de rivierkreeft diep onder het water in een hol, doch zonder een eigenlijken winterslaap te houden. Integendeel: dan wordt van die rustperiode juist voor de paring gebruik gemaakt. Tegen dien tijd heeft het wijfje de eieren, door middel van een soort slijm, aan de aanhangsels van haar achterlijf bevestigd, en daaraan draagt zij die tot aan het voorjaar mee. Dan komen de jongen uit, die 1 à 1,5 centim. lang zijn en reeds grootendeels den vorm van het moederdier hebben, daar de rivierkreeft, bij uitzondering, geen gedaanteverwisseling ondergaat, zooals de overige kreeften. Zij voeden zich met zeer kleine waterdiertjes. De moederlijke bescherming kunnen zij echter nog in langen tijd niet ontberen en daarom hechten zij zich, met hun scharen, aan de
borstels van de achterlijfsleden der moeder vast en verlaten die eerst na het eerste vervellen of „ruien”. Zij groeien zeer langzaam; een kreeft van 10 centimeters is zeker 10 jaren oud.
Het genoemde „ruien” moet ook later nog herhaaldelijk plaats hebben en, hoewel dit voor het dier een alles behalve aangename bezigheid mag heeten, zoo is het toch een noodzakelijk kwaad, dat te danken is aan het harde, onbuigzame keurslijf, waarin de kreeft gekneld zit. Terwijl de groei van het dier zelf voortgaat, kan het pantser dien natuurlijk niet meemaken; het wordt te nauw en de eenige uitweg is, om dezen te engen rok, waar het dier uitgegroeid is, af te werpen en zich een nieuwen, wijderen te laten aanmeten. En zoo verkeert deze edelman dus in de harde noodzakelijkheid, om, gedurende zijn geheele leven, herhaalde malen „uit zijn vel te springen.”
Gedurende dit proces is het dier tijdelijk volslagen hulpeloos en weerloos en het wekt ons medelijden op, als een werkelijk beklagenswaardig schepsel. Want de, thans naakte en nog zeer dunne, huid is nu zeer gevoelig en week en kan licht beschadigd worden, de zoo gevreesde scharen zijn insgelijks week en dus totaal onbruikbaar. Hij doet dus, wat in zijn geval ongetwijfeld de verstandigste partij is, en, alsof hij zich voor zijn naaktheid schaamde, kruipt hij weg en verbergt zich zorgvuldig, totdat de verharding der huid, door het afzetten van kalkdeelen, weer tot stand gekomen is. Dit heeft betrekkelijk spoedig, binnen 6 tot 8 dagen, plaats, want reeds vóór het vervellen heeft zich in den maagwand een kalkvoorraad verzameld, in den vorm van twee platte, ronde korrels, de zoogenaamde „kreeftsoogen,” die vroeger wel in de geneeskunde gebruikt werden. De inhoud van die korrels wordt nu door den bloedstroom naar de huid gevoerd en, na het verharden daarvan, vormen zich, uit de kalkdeelen van het water, in de maag weer nieuwe kreeftsoogen voor een volgende verwisseling van kostuum. Het merkwaardigste is echter, dat het vervellen zich ook uitstrekt over de voelers, de oogen, de kieuwen, ja zelfs over het darmkanaal.
Van het gezelschap op plaat II vragen ook weer eenige schelpdieren en slakken onze aandacht. Beneden, rechts in
