This is not a very productive post but while decluttering my office, I stumbled across my super-old Microsoft badge! I was on campus in Redmond a lot in the late 90’s getting prepared for the Exchange 2000 release and I honestly don’t remember being that young.
The Public Preview of Exchange 2019 has been available since late June and I’ve been running it through the ringer to learn all I can before the final release this year. In that time, I’ve not yet found that one thing the makes the release exciting for me but there are several things that come very close!
First, is the increase in server resources. While machine hardware continues to improve, Microsoft’s Preferred Architecture for Exchange also increases. Exchange 2019 supports 48 processes as its predecessor but the supported memory increases from 192GB to 256GB. We are condensing servers and moving further away from virtualization my friends! This is an important move for Microsoft since it better supports a cloud architecture plus it allows your large On-Prem environments to further reduce your own footprints.
Other density-driven improvements include using Solid State Drives (SSD) for specific indexing data and another “new” indexing engine. Sorry about the quotes, but this is not the first-time indexing has been changed and I’m holding out for more solid testing before I drink the Bing Kool-Aid. Indexing is back inside the store and so it replicates (again) to the secondary copies. I have high hopes this will speed up searches and Outlook launches. The Bing search engine is terrific of course but we’ll know more about its performance/stability once we see it in action and can perform some real-world testing inside Exchange.
Probably the most exciting change is the inclusion of Windows Server Core as a supported Operating System. While this will certainly lower the attack surface and help stabilize the server, I’m not sure it will reduce the patching cycles as I once hoped. Perhaps it was my own wishful thinking but I had concluded that OS security patches could be reduced if the OS has no UI! Unfortunately, the Windows Update Catalog shows no security patch distinction with Server Core so the same monthly patches are recommended for now. I am wondering if that will change.
At present, large organizations must use PowerShell to create a New-ComplianceSearch and then execute .\MBSearchFromComplianceSearch.ps1 to convert it to a Mailbox Search when the search scope is large. For large companies with tens of thousands of mailboxes, this usually means training for the legal teams or a 3rd party tool. The Office365 compliance tools are SAWWWEEET and don’t have this limitation so I’m still hoping some of that trickles down to On-Prem.
In the last 6 weeks, I’ve noted a few other questions and only a couple of concerns so I look forward to what information they release at Ignite. For example, the Bing indexing changes weren’t in the public preview so real-world testing is a bit limited. Honestly, this version is more dramatic of a change than 2013–>2016 and so most of us are impatiently awaiting the final release!
I’ll keep you posted as I learn more.
The onslaught of ransomware and devious social engineering efforts means it’s only a matter of time before your organization is hit with a major email virus outbreak.
Administrators should prepare on-premises Exchange — and themselves — to quickly stem the bleeding when that malware lands in a user’s inbox. And while the techniques to protect on-premises Exchange Server aren’t new, they are important steps to reduce the effects of an attack. Even if the antivirus scanner fails to detect the threat, there are ways to isolate affected mailboxes, slow the proliferation and even stop the spread of a virus. Have procedures, processes and scripts in place to fight off an email virus outbreak before trouble starts.
The risk chart also indicates the appropriate response based on the severity and distribution of the threat. For example, a widespread distribution of the destructive Locky ransomware warrants a far greater response than when the Tinba malware hits a single mailbox. Use this chart as a baseline to assemble a threat-response plan.
Follow this link to get the processes and scripts you can use to help slow down the attack.
Small problems can turn into large ones in Exchange environments that aren’t regularly monitored, causing the system to deteriorate quickly to the point of outage or even total failure.
There are a few areas to watch to prevent outages in single-sever Exchange environments and large enterprises with multiple servers. Here are three of the most common causes of extended Exchange outages.
A failed recovery is the most common cause of extended Exchange outages. It may sound like circular logic, but if the Exchange environment is down for multiple days, the root cause of the failure is no longer relevant. Don’t let indecision and untested processes fuel a crisis. Every Exchange shop needs to have a detailed plan to recover each of the following: single mailbox, single database, single server and the entire environment.
While there are a number of third-party products that handle disaster recovery, tools and processes included with Microsoft Exchange and Windows Server are good options because Microsoft offers support and documentation for different disaster scenarios. Microsoft provides guidance on how to restore the following — a single mailbox from a database backup, an Exchange Server, a DAG Member Server and dial tone portability, which can solve failures of a mailbox database, server or entire site.
Use these procedures regularly to understand the process and test backups. The processes to restore a database and a single mailbox are not invasive; administrators can perform these procedures on live servers. It’s best to perform these on weekends and after hours to minimize the potential effect on end users.
For the rest of the article, please follow this link to my complete article at Tech Target.
Recognition is always appreciated and last month Microsoft honored me by including me in the MVP Reconnect Program. Its a privilege to be included in the group once more and to be reconnected with so many brilliant and talented people again.
It was an honor and privilege to be included in a small gathering last night celebrating the 20th
Anniversary of Microsoft Exchange. The product group, MVPs and the writers/Rock-Stars were all there to commemorate the landmark achievement.
There were folks in that room who gave me opportunities many years ago to publish articles and chapters in books. Because of their trust and support I was able to branch off and write many more articles, to speak at events and to expand my own horizons within the field. In fact as I looked around the room and shook hands I was humbled by the realization of how many of them have helped me over the years.
This event was not about strategizing the future of email, our careers or even the future of Exchange. This gathering was a pure trip down memory lane and an opportunity for us to reacquaint and reconnect. I don’t know if there will be another version of Exchange but I will continue to help the Exchange community as we continue our migration into the cloud.
Many organizations contemplating a move to Office 365 have major concerns about security and compliance. Some may even abandon plans to move to the cloud because of compliance worries. Many of the legal and regulatory tasks administrators perform with on-premises Exchange Server can now be replicated with the updated Office 365 eDiscovery tool and other compliance utilities.
Microsoft recently shifted the location of Exchange management tools, and it put most of the retention and compliance utilities in the Office 365 Security & Compliance Center. In fact, the Office 365 eDiscovery feature has more power and versatility than similar tools in on-premises Exchange Server 2013 and 2016, and the Office 365 Exchange administrator console.
Last week, TechTarget published my entire article with walk-throughs, screenshots and lost of details. Follow this link for more details: Office 365 eDiscovery
For more detailed explanations, scripts and recommendations please follow this link to my article on TechTarget.
It’s tough to leave a good thing. Let’s face it: Exchange 2010 was a solid release. Not only did it bring native support for public folders but it also had direct Remote Procedure Call connections with the option of HTTPS, built-in antispam tools and great third-party support for just about anything we wanted — fax, antivirus and even BlackBerry Enterprise Services.
Unfortunately, Exchange 2010 and the organizations that depend on it are on borrowed time. Microsoft ended mainstream support in early 2015 and extended support is not an option for most of us, so it’s time to start planning an upgrade.
There are well-known compatibility and migration issues that can be solved in advance. With good preparation and planning, Exchange administrators can make the upgrade to Exchange 2013 or 2016 practically invisible to end users. If you follow my list of top five items to handle, then the switch should be fairly painless.
Load balancing is not an issue for smaller shops but there are specific differences between Exchange 2010 and later versions that need attention, depending on whether you use F5, NetScaler, or some other hardware or software options.
What we are really talking about is the names used for Outlook Anywhere (OA), Outlook Web App (OWA), Exchange Control Panel (ECP), ActiveSync (AS), EWS, Offline Address Book (OAB) and Autodiscover. It sounds like a lot but most administrators combine the namespaces for many of these.
An organization that relies heavily on a particular add-on should talk to its vendor as soon as possible to see if it can offer a transition plan. Vendors that provide fax, compliance, e-discovery, mobile synchronization or security services, antivirus, backup and recovery, unified messaging and other services do not always have a clear path to newer versions of Exchange.
I have rated public folders so high because I have seen companies struggle with the transition work in this area for more than a year and severely delay the move from Exchange 2010. The process of moving the folders is cumbersome but even more difficult is the effort needed to identify and determine if a folder and its contents can be removed instead of migrated.
Client software gets top billing in this list. Exchange 2013 and 2016 do not support direct RPC connections for MAPI so you will have to use Outlook 2007 or newer. Also, make sure the Outlook clients are patched.
This is the short list from the entire article but hopefully it helps you with your planning.
Moving your Exchange services to Office 365 seems to be a fairly simple decision for smaller companies; it just makes sense. Most of my larger customers however remain on-prem due to security concerns and higher estimated costs. In addition, there are often political challenges in eliminating local servers and eliminating jobs within IT departments and sometimes irrational fears of a global cloud shutdown or problem. (Blackberry/RIM problems come to mind.)
The slower adoption rate of Office 365 for larger entities is a huge topic and I would need some help in covering that completely, but I did find an interesting article today with price comparisons for small shops. It’s the first time I have seen calculations and a nice chart that shows the costs between the two options for various small company sizes. This article suggests that the price advantage with Office 365 starts to wither once you reach 1,000 mailboxes.
Anyway, check it out.
Comparing Cost for Exchange Online to On Premise for Small to Midsized Businesses
This article is intended to detail the mechanics behind an Service Level Agreement between a fictitious Company ABC and an outsourcing/hosting vendor. You may not have the luxury of getting an SLA with the vendor you have chosen but you may want to think about asking for one. Time to recovery, time to restore and up time guarantees are all just a few of the critical facets of IT we need to manage.
Several specific requirements have been assumed and documented in this article.Feel free to copy this content and edit it for your own use. My goal was to product a template that other companies could use to begin work on their own SLA.
There are two major parts to an SLA: the governing document and the process.
The SLA process represents a third of the total solution. It is up to the hosting vendor and your company to ultimately choose the correct people to manage the systems and the best technology for implementation. The people involved in managing the process must also manage the technologies and understand the importance of reporting and monitoring the entire system.
System management and service desk automation technology can provide a supporting environment for tracking, escalation, and management of service metrics. End user satisfaction surveys can also provide input that will help target appropriate service levels and cost controls.
Service Level Agreements are often categorized in the following manner:
For purposes of discussion, the remainder of this paper examines the considerations of a company evaluator who must complete an SLA document of the support requirements for Exchange/Outlook systems. We will call this company “ABC Company.” The evaluator works with one or more outsourcing companies to negotiate the final agreements recorded in the document. Recommendations and suggestions, which are based upon industry standards and project management experience, are provided throughout.
The primary objective of the SLA document is to correctly identify the support requirements for Company ABC in regards to supporting the Outlook/Exchange infrastructure.
The ABC company evaluator alone cannot determine the appropriate details for the SLA. The outsourcing vendor’s industry experience and project management capabilities will provide required information and guidance. In many cases, it will be required for Company ABC and management within Company ABC to conduct workshops on the issues to determine specific objectives.
Moreover, we should all use our best judgment in collecting ideas and suggestions from the appropriate people. For example, for specific questions regarding helpdesk requirements, the outsourcing vendor may need to be involved in order to correctly identify a requirement unknown to the Evaluator.
The processes in creating the SLA are broken down to ease the management of the project. The first four sections require the input of ABC Company management and, in some cases, end-user surveys. The next group of tasks may require the input of the current out-sourcing company in order to ensure all requirements have been identified. Next, theevaluator assembles the data in a document that can be easily read and understood.
The last sections take place during the negotiations with outsourcing vendors. Usually, a legal instrument will be created to bind both parties to a final Service Level Agreement. While the final SLA will be based upon the evaluator’s SLA document, it is likely that sections will be added or removed as negotiations dictate.
Management of the SLA is a critical part of supporting end users. Before we can determine if objectives have been met, we must first identify metrics and the specifics of the contract.
First, name the key contact to the Service Level Agreements and delegate SLA management tasks to others. Other contacts for the SLA include:
ABC Company:
Management
Exchange connection into other corporate systems
Management of 3rd Party Outlook/Exchange Development
Application Development
Remote and Mobile Access
The frequency and detail of reports must be identified as well. Reporting can then be further broken down into two techniques:
ABC Company may also require that an automatic mechanism be put into place to notify the named contacts when critical performance thresholds are met. Specific thresholds are discussed later in the document.
Questionnaires and end-user canvassing methods should also be performed by ABC Company and/or the Outsourcing Company as part of an overall customer service initiative.
Payment terms and contract length are negotiated with the outsourcing vendor. ABC Company may prefer a contract length of six months, but will consider contracts as long as one year. Renewals can be handled in many ways including automatic six month extensions. Both ABC Company and the outsourcing vendor should be able to request a formal renewal meeting to update the SLA with riders and to negotiate new terms.
There are two types of terminations possible:
Termination Options are described as follows:
Review Process
There should be a formal review to evaluate the performance and customer service levels as well as staff reviews. A quarterly review is sometimes formalized in order to include discussions on SLA fulfillment, staffing and future projects that may affect the SLA.
Service Level Management is accomplished by negotiating a change or additional to an existing Service Level Agreement. Out-of-scope or new projects need not be discouraged. A change process occurs during every review process and can also be instigated as needed. Several things could require a change or addendum to the existing SLA:
Changes are not made directly to the SLA. Instead, contract riders are appended to the SLA until such time that the SLA is rewritten to incorporate the addendums. The SLA can only be written during a renewal cycle with both parties present.
Most groups believe that the total cost of ownership (TCO) is more a function of cost of service and support of the system than a function of the cost of hardware and software. SLAs can drive down TCO by identifying damages for missed service levels.
In the case of ABC Company, a third party may be asked to provide evaluations to determine if service level objectives have been met. The costs associated with the third-party evaluations are the responsibility of the party requesting the evaluations.
Penalties and bonuses for SLA performance guidelines could be “paid” quarterly. Performance objectives are met based on a +10/-10 (percent?) allowance. Penalties are paid as a deduction of regular costs for the pay period immediacy following the review cycle. Bonuses are paid with four weeks of the review cycle and do not require a separate purchase order from ABC Company.
Because the outsourcing vendor may have little control over the stability of the hub servers, ABC Company may not require guaranteed delivery times for mail originating from, or addressed to, any mailbox outside of the ABC Company’s site.
However, inbound Internet email with legitimate addresses should not get returned as undeliverable from the Exchange systems within the supported (environment?). The outsourcing vendor should remedy any internal Exchange process that returns mail.
ABC Company requires that intra-site Exchange mail be delivered to the recipient’s server-based mailbox within 15 minutes of delivery to a server within the supported site.
Remote users who replicate the Offline Address Book should never wait more than thirty minutes for a complete refresh to transfer even over slow connections.
You should probably define the mailbox limits. In many cases, mailboxes are classified into two or more categories. For example:
Many companies configure directory replication so that the directory is current within a forty-eight hour time period. For example, a mailbox that is added at 3:00 p.m. on Tuesday must appear in the directory and Offline Address Book before 3:00 p.m. on Thursday. This should be defined in the SLA.
Administrative tasks, such as Exchange/NT username add/remove/change, should be able to be handled within one business day. The primary and backup responsibility may be divided up among the server support team and the helpdesk.
An matrix of administrative task groups and responsibilities should be created in order to identify the ability of each group, including:
The outsourcing company may want to define the maximum number of one-day requests that can be filled per business day. Additional requests will roll to the next business day and will take priority over new requests.
Note: Public Folder applications that require or use automation, such as routing or scripting, are considered a separate project. New projects, which are likely to incur extra costs, are not part of the SLA.
System availability can be an expensive requirement. It is important that we identify the specific requirements from a resource access standpoint and not necessarily on a server by server basis. The specifics dictate the availability of the servers.
Network connectivity between sites and for users should be defined clearly as to the required uptime. Redundant links may be required based on the connectivity requirements.
This specification details the amount of time a user cannot access his/her mailbox on an Exchange server in the supported site. Many companies define at least two types of mailbox classifications:
Information gathered from the previous specifications dictate the level of availability that is required. The services are then classified using the following availability classes.
| SYSTEM-TYPE
|
AVAILABILITY CLASS | UNAVAILABILITY MINUTES/YEAR | SYSTEM AVAILABILITY |
| Unmanaged | 1 | 50,000 | 90% |
| Managed | 2 | 5,000 | 99.0% |
| Well-Managed | 3 | 500 | 99.9% |
| Fault-Resilient | 4 | 50 | 99.99% |
| High-Availability | 5 | 5 | 99.999% |
While the table represents system availability, it is important to note that the figures represent unscheduled down time. It is critical that “windows” are allowed for scheduled maintenance and upgrades. The down time is always be scheduled on the same day every week over the weekend. Many companies detail acceptable times during the weekend such as 11 p.m. Saturday to 2 p.m. Sunday. The specific time needs to be negotiated.
The maximum allowable scheduled down time per week for the Exchange systems should also be defined. For example, you could specify an eight-hour maximum window during the week and 25 hours one weekend per month.
You may want to send out a user survey in order to determine the best time for scheduled maintenance.
The outsourcing vendor must balance the uptime requirements with the inevitable cost. The foundation for a mission-critical architecture has specifications for server availability, data accessibility, data protection and disaster tolerance.
ABC Company should require that named contacts be permitted physical access to the equipment at any given time. Moreover, overall access to the equipment must be secured and restricted. Access to the equipment must be available 24 hours a day, 7 days per week for the vendor’s support personnel.
Many companies require that the clients be able to request a “recovery of deleted items” for up to 30 days of deleted items. Moreover, backups and snapshots must be maintained and also retired based on company retention policies.
In some cases, there may be a need to recover items from backup. The outsourcing vendor should honor such a request from any of the named contacts on the SLA. The outsourcing vendor may accept requests from the user community for restores, but should then verify the request with the named ABC Company contacts.
ABC Company does not have any specific requirements in regards to the types of systems (hardware and/or software) used to monitor the equipment.
ABC Company requires that at least one person supporting the systems have current MCSE status. At least two of the support personnel must be certified on the current version of Microsoft Exchange Server.
Your company may have specific requirements in respect to Security and Privacy which could mandate the need for exclusive use of equipment. You may therefore need to add a line that specifies that the resources that support the ABC Company Exchange systems be exclusive to ABC Company and not used for non-ABC Company projects or tasks.
While ABC Company has no requirements as to the brands or types of equipment used for the Exchange Server environment, ABC Company does require that the equipment be included on the Hardware Compatibility List for the current version of Microsoft BackOffice.
The outsourcing vendor is responsible for the requisitions and costs associated with all equipment necessary to support the ABC Company Exchange Systems.
ABC Company requires that at least two entire servers be allocated for spare equipment and testing/recovery. The servers must match the current servers in production so that parts can be swapped and/or replaced. ABC Company further requires that the test equipment be updated as the production equipment and online at all times for testing.
There are not many templates like this out there since most hosting companies mandate the terms to the customer. However, there are Exchange shops out there that balk at a commodity hosting solution due to privacy and security concerns. My intention with this article was to lay some of that groundwork out and save some research and headache with SLA planning.
Exchange Server - Alive and well 