User Profile
SamErde
Iron Contributor
Joined Jan 09, 2018
User Widgets
Recent Discussions
Re: Exchange upgrading on the Same Server : Exchange 2010 to 2013
Exchange Server does not support in place upgrades. You'll want to take advantage of this opportunity to build a new server that is running a supported version of Windows Server, install Exchange Server 2013, create new mailbox databases, and then move your mailboxes to it.951Views0likes0CommentsRe: Still dont understand the federation between premise and EOL
Split DNS (aka split-horizon, split-view, or split-brain) usually refers to a configuration where one namespace, or DNS zone, has different name servers that respond with different IP addresses depending on where the query is coming from. For example, a company that uses "https://owa.example.org" as their OWA URL: users inside your corporate network would hit internal DNS servers, which would return the internal/private IP of your OWA load balancer users outside your corporate network would hit public DNS servers, which would return the public IP address of the OWA load balancer (of course, at a high level, this would be NATed through perimeter firewalls, etc to the internal OWA load balancer) Using the same namespace internally and externally (split DNS) actually would make the HCW simpler, because it has to handle numerous processes and you wouldn't need to track separate configuration for each of these: identity and access management mail flow (MX > Exchange Online > Exchange on-premises) AutoDiscover and EWS Every environment has its own unique components, so more information would be needed to determine what questions you need to ask and how best to move forward. I'd recommend professional services, but also--if you have a chance to consolidate your Exchange Server namespace into a single DNS namespace with split DNS, then this process will likely be a lot simpler in the long run.766Views0likes0CommentsRe: Exchange Server Sizing Calculator
PeterRising To be fair, this is something that I had read consistently with Exchange 2007 up through 2013. It has been a while since I've sized anything other than 2019, though--so the question of using "too much" memory hasn't been active in my mind for anything other than the new requirement recommendation of 128 GB. Still, a really quick search turned up these two well-seasoned articles: The Exchange Team's blog post "Ask the Perf Guy: How big is too BIG?" touches on the question. it begins with "...we recommend not exceeding the following sizing characteristics for Exchange 2013 servers..." Then, near the end of the post with this statement: "If you do decide to virtualize Exchange, remember to follow our sizing guidance within the Exchange virtual machines. Scale out rather than scale up (the virtual core count and memory size should not exceed the guidelines mentioned above) and try to align as closely as possible to the Preferred Architecture." Then, the post "Troubleshooting High CPU utilization issues in Exchange 2013" reminded me that the primary oversizing concern actually seems to be around having too many CPU cores. The last artifact that I found was an interesting, albeit old explanation about transactional IO vs non-transactional IO: "Why too much memory can hurt Exchange Server 2007 performance", by Brian Posey. TechTarget sits behind a frustrating survey wall, but the crux of his explanation is in the line, "The more physical memory a server has, the longer it takes for the cache to reach its optimal size. Until the cache reaches this point, end users may experience slower-than-normal performance." This, of course, was written in a very different era, so I'd be surprised if the advise is still relevant, given all of the work that has gone into Microsoft's preferred achitecture. So basically...these provided some interesting re-reading, but I would ultimately focus on the Exchange Sizing Calculator for your specific version of Exchange Server, and simply go with the recommendations that it provides for your specific environment.6.4KViews0likes0CommentsRe: Exchange Server Sizing Calculator
No, the calculator's recommendation covers the OS and Exchange Server. It actually is possible to negatively affect Exchange Server 2016 by giving it more then the optimal/recommended amount of RAM. (Exchange 2019 is a different beast entirely.)7.1KViews0likes2CommentsRe: Block Microsoft Exchange Server 2016 Exchange Admin Center (EAC) website from Internet
I would highly recommend using a reverse proxy between your perimeter firewall and your Exchange server[s]. You can configure the reverse proxy to only pass through OWA traffic and ignore/drop ECP URL requests. Once this is properly configured, you don't need to go through the hassle of disabling ECP on your Exchange Server or even creating a separate ECP site. (Although if you've already done that work, there's no reason to undo it.) Regardless of your choice, just be sure to set your external ECP URL values to null. Off the top of my head, two potential solutions for a reverse proxy (I'm sure there are many) might be Citrix ADC (Netscaler) or Traefik. This is essentially what AAP does, but AAP (Azure App Proxy) is running in Azure, whereas your reverse proxy could run on premises.6.4KViews0likes1CommentRe: Is it possible to install an Exchange CU using remote desktop via VPN?
To reinforce HidMov's answer: I have done almost all of my Exchange 2010 and 2016 CUs remotely using a VPN connection. If your servers are virtualized, you can use the hypervisor's console instead of RDP, which gives you extra flexibility and visibility if any issues do occur. Good luck!1.1KViews1like0CommentsRe: Upgrade Exchange Server 2016 DAG to 2019
Michael_Larrivee, thank you. Makes perfect sense. Just wish I could have found some documentation that explicitly noted "these steps also work with a DAG" and "a load balanced namespace" so I could assuage concerns from the change advisory board.16KViews0likes0CommentsRe: Upgrade Exchange Server 2016 DAG to 2019
Michael_Larrivee, the Exchange Deployment Assistant is a fantastic resource. I did go through it already, with two significant questions remaining unanswered. First, it doesn't speak about DAGs. Perhaps there is assumed knowledge that moving mailboxes from 2016 to 2019 can happen in the same manner regardless of having a DAG or no DAG. This is where my lack of experience comes into play and I was hoping for a clear answer. What kind of separation happens for an organization that has more than one DAG? Is a DAG simply considered a replication boundary, but otherwise able to to share full organization functionality such as address lists, policies, receive connectors, and namespace? Second, can multiple DAGs share the same namespace and load balancing topology? Meaning: for a migration from 2016 to 2019, can we build a new 2019 DAG, configure it to use the same namespace/URLs, and then add these 2019 nodes to our current load balancers alongside the 2016 servers? My gut optimistically suggests that the answer to this second question is "yes," but we're just looking for documented confirmation of that before beginning. Thanks again!16KViews0likes2CommentsUpgrade Exchange Server 2016 DAG to 2019
We are currently planning the upgrade of our Exchange Server 2016 DAG (on Windows Server 2012 R2) to Exchange Server 2019. I have found it surprising that there are a fair number of articles about migrating from 2010 or 2013, but very few resources for our current scenario. Is the only option to stand up a new DAG and use ECP to move mailboxes (or databases) to the new DAG? Can anyone point me to documentation about how to manage namespaces, load balancers, and clients during this transition? Thanks!Solved16KViews0likes4Comments
Recent Blog Articles
No content to show