Here in Part 5 of this blog series, I will take you through the process of installing Exchange on the first Client Access and Mailbox Server art-MBXCAS-01 – this includes Active Directory and Organization preparation. I will then round off with explaining how you can then go onto complete the installation on the remaining servers.
In this, Part 4 of this ENow blog series, I will take you through the provisioning of your Exchange Servers in Hyper-V, summarizing the install of Windows Server 2012 Data Centre (as we have covered the step by step install of Windows 2012 in the first part), and finally installing the prerequisites for Exchange 2013 on Windows Servers 2012.
Times change, people change – and as well all know, technology changes as well. The last part of that sentence could not be more true of Windows, Active Directory and Exchange Server recently.
Face it, most Exchange administrators look forward to their weekly patching projects about as much as you and I look forward to our next trip to the dentist. Throw in the extra complications of switching from a non-clustered environment to one that is clustered and the word root canal comes to mind. When working with non-clustered servers one can usually just use WSUS or other patching products which require simple install patches and then a restart or a reboot of the windows box. If this is done in an Exchange environment with clusters however, the same process could end in disaster.
I have been working on a large Exchange 2010 upgrade to Service Pack 2. The Exchange environment that I have been working within works well, but it has not had a lot of TLC in a while, and aside from the upgrade to Service Pack 2 for Exchange, I also needed to perform an upgrade to Service Pack 1 of the Windows 2008 R2 O/S.
When it comes to monitoring application administrators often disagree with system administrators on what to monitor and which thresholds to configure. By nature, system administrators focus on system related counters and objects to monitor. They do not care about application related monitoring as those information's are out of scope of their daily work. Vice versa the same is true for application administrators.
Exchange admins are from time to time doing mailbox moves. There could be several reasons for doing this, but the goal is often to create some white space in the mailbox databases.
Ever tried to publish Outlook Anywhere using NTLM with TMG and use Kerberos Constrained Delegation? Many people have tried and failed, or at least had some major trouble before they were finally able to get things going.
To help make things a little easier, here is a simple checklist on how to publish Outlook Anywhere using NTLM with TMG, using Kerberos Constrained Delegation.
For many generations, Outlook Web Access allowed users to change their password, but only after they had successfully logged on to OWA. With Exchange 2007 Service Pack 3 and the upcoming Exchange 2010 Service Pack 1, administrators now have the ability to change the password pretty much the same way users do when they log on to Windows on their PC.