Exchange Online running on Microsoft’s Office 365 cloud platform operates more than 100,000 servers to support some 60 million mailboxes. At least, that’s the best-guess estimate based on information provided by Microsoft at the Exchange Conference 2014, data in their most recent financial reports, and consultant analysis.
Anyone who runs an on-premises Exchange environment today would be forgiven for wondering how long their job will last, at least in its current shape. The sales pressure from Microsoft and other vendors to influence CIOs to consider moving workloads to cloud platforms increases all the time and the inevitable fear is that jobs disappear once work is transitioned.
For as long as Microsoft Exchange has existed, Outlook meeting corruption has been a consideration for those who rely on calendaring. Meeting corruption can appear in many forms. However, meeting corruption typically occurs when meetings disappear, when duplicate meetings appear or through other unusual anomalies that users may experience with an appointment.
Exchange 2010 recently introduced a new feature called "cmdlet extension agents." These agents can be called when a cmdlet is running, and can also perform extra tasks as a part of the original cmdlet. A recent Microsoft article has great information on understanding the Cmdlet Extension Agents. You can see which cmdlet extension agents are available by running this command in the Exchange Management Console (EMC):
Many people want to use multiple IP addresses on a single NIC interface with Exchange 2013 and Windows Server 2012. There are several reasons for this multi-homed IP configuration, such as various receive connectors for diverse applications (fax, SharePoint, gateways, etc.), or for an additional IIS website, amongst other things.
Anyone who has participated in migrations or transitions to Exchange has most likely encountered or has had to work around potential issues caused by the nickname cache. A “cache,” also known by its file extension, NK2 in older Outlook clients, is a convenience feature in Outlook and Outlook WebApp (OWA) which lets users pick recipients from a list of frequently-used recipients. This list is displayed when the end user types in the first few letters.
Eventually all good things come to an end and that’s no exception to our 3rd party certificates that allow access to Outlook Web App and other web-based Exchange workloads such as Active Sync or Outlook. This article provides a step by step process on how to update your Exchange 2010 certificates from start to finish. This article also assumes we are using a DigiCert wildcard certificate. Most of this work can be pre-staged before the actual implementation and is highlighted below. With that, let’s begin!
“True wisdom is knowing what you don't know”
It’s an old maxim that traces back to the time of Confucius, but it is still a nugget of wisdom serving as the cornerstone of strategic operations for modern IT environments.
Microsoft first introduced the Edge Transport role as one of the five Exchange roles in Exchange 2007 and offered it again in Exchange 2010. The purpose of the Edge server role is to provide a solution for customers who require inbound SMTP connections to terminate in the perimeter network (DMZ), rather than in the internal network. Since most inbound SMTP connections are unauthenticated, some security departments are uneasy at allowing these connections directly to internal resources (your Exchange servers). Edge transport servers allow these customers to deploy Exchange without having to buy an SMTP gateway appliance.
If you have ever been in a situation where you have lost a physical Exchange 2010 server from your DAG then this document is critical to your ability to recover this server. Examples of how this could occur are through OS corruption, accidental overwrite or a true datacenter disaster. Even if you haven’t been in this situation this article will provide the insight to what it takes to recover an Exchange server that had once been a beloved member of your Exchange 2010 DAG.