Posts about:
Exchange Server is a very tolerant software product and allows for installation in different IT infrastructure environments. Some of the possible infrastructure environments are well suited for running Exchange Server, others are less good.
In my previous article in this series, we discussed Exchange “Alternative Architecture” options for medium-to-large businesses. We specifically covered common storage design options and which were ideal to design the best solution for a customer that has decided to remain on-premises and chosen to not follow the Preferred Architecture. To reiterate, I’m a big fan of Office 365 and the Preferred Architecture but I understand many customers will not follow either of these two routes. Therefore, if they deviate from either of these options they should at least follow the recommended guidance that can increase the uptime and better the performance of their solution.
In my first article in this series, I discussed Alternative Architecture options for Small Businesses who choose to stay on-premises. My intent was to ensure that if a business chose to remain on-premises but did not wish to implement Microsoft’s Preferred Architecture for Exchange, they would at least deploy in a way that will reduce complexity and increase uptime of the solution. While the first article focused on options for small businesses, this article will begin to discuss common deployment options seen in medium to large environments. We’ll focus on popular storage technologies found in this space; RAID and advanced storage solutions (SAN/NAS/Hyper converged). As the type of architecture found in this space is so varied, we’ll focus more on sound design principles and best practices.
This post is about a recent migration of legacy public folders hosted on Exchange Server 2007 to modern public folders hosted on Exchange Server 2013.
There are a few words Microsoft likes to use in several different situations. “Federated” is a great example of this. Federated can mean several different things in the Microsoft world, and it can sometimes be hard to tell what sort of “federation” you’re talking about.
“Supported” is another word Microsoft uses to mean different things in different situations, and what I’d like to talk about in this blog post.
This is a blog post I never thought I'd write, and just a short time ago, I couldn’t have imagined it would be something that you'd want to spend 10 minutes reading. Turns out “the cloud” really does keep us on our toes.
In part 1 of this series, I discussed how to connect to the Exchange database cache and the importance of transaction logs in database transactions. In this next part, you'll learn how transaction logging and recovery work in Exchange.
Exchange database internals might seem to be a complicated topic, but we’re going to briefly discuss database internals from a very practical perspective.
Despite the recent surge in popularity of the cloud, moving to Office 365 isn't a viable option for every modern-day business. For this reason, enterprise-based Exchange will continue to be a mission-critical platform for many companies, and Microsoft has shown no sign of abandoning the platform anytime soon.
Microsoft recently announced a new DAG copy activation feature that will be available in Exchange 2016 CU2, but before we talk about that, I’d like to do a quick refresher on how database copy activation works currently and will continue to work for Exchange 2013 and 2010.