Exchange Center

Most organizations are spread across multiple locations in today’s business world. Exchange being such a critical application, it’s essential to make sure that it is up and running around the clock without any downtime. Regarding High Availability and Disaster Recovery, Exchange 2013 has many features due to new improvements and some changes with DAGs as compared to Exchange 2010. How would you provide a redundant path to send and receive emails from the Internet if an entire primary site goes down and exchange is running from the DR site?  Of course we can add additional servers in the DMZ to take up the load if one or more server goes down. What though could you do if the complete Datacenter goes down?

Let’s consider an example where we have two datacenters where Exchange servers are hosted.  The primary datacenter is in New York and has internet access to send and receive external emails through the internet and the other datacenter in Dallas. Both are interconnected by a high speed WAN network.

While handling employee separation is generally a process controlled or handled by human resources, IT has to get involved somehow to manage email, contacts, and other knowledge items stored within Exchange. Here are some suggestions on how to gracefully handle the technical side of employees transitioning out of your organization.

Now that you've looked over part 1's information on how to build a SCCM report of let's proceed with part 2.

Once you’ve properly extended the SCCM hardware inventory you should now focus your attention on the clients. In order for the clients to pick up their new marching orders they will need to retrieve a new machine policy. You can either wait for this to happen naturally or force refresh a few immediately. I recommend refreshing a couple just to make sure the 2 new inventory classes you’ve created were configured correctly.

Once you refresh the machine policy on a few clients go ahead and request a hardware inventory cycle as well. If you know off hand a couple of clients you know were imaged via SCCM/MDT, use those as the initial tests as well as a couple you know were done via other methods. This way you can confirm if the imaged clients are reporting and the non-imaged clients are not.

Check your logs

After the policy refresh and hardware inventory cycle, check the clients’ inventoryagent.log file. In this file you should see a couple references like these:

Collection: Namespace = \\.\root\cimv2; Query = SELECT __CLASS, __PATH, __RELPATH, KeyName, CM_DSLID FROM OSD_History_2; Timeout = 600 secs.
Collection: Namespace = \\.\root\cimv2; Query = SELECT __CLASS, __PATH, __RELPATH, InstanceKey, DeploymentMethod, DeploymentTimeStamp, DeploymentType, TaskSequenceID, TaskSequenceName, TaskSequenceVersion FROM Microsoft_BDD_Info; Timeout = 600 secs.

If you do, that’s good! That means the client knows about your new inventory classes! The next log you need to look at is dataldr.log. This log file is located in C:\Program Files\Microsoft Configuration Manager\Logs or related directory on your site server.

We understood the various input options available in the Role requirement Calculator in part I. Exchange calculator uses the entire data from the input worksheet and performs the calculation based on the input data and updates details on the worksheet defined below. These worksheets are for review purpose only.  Any change in the design has to be done in the input worksheet.

Outlook Web App (OWA) has been a mandatory requirement for every organization. When Exchange 2013 is introduced in an existing environment, it needs to be configured for OWA co-existence with legacy Exchange servers like Exchange 2010 or Exchange 2007. OWA co-existence configuration will provide a single namespace for users accessing OWA, regardless of where their mailbox is located. This document is for the administrator to configure OWA co-existence using single name space for both Exchange 2013 and legacy Exchange servers (Exchange 2010 and Exchange 2007)

In this article, we will share the prerequisites and guidelines you must meet to ensure a successful deployment of either Exchange 2016 or Exchange 2019.

The Exchange 2013 Server Role Requirement Calculator is a one stop calculation tool for Exchange 2013 design. The tool covers design calculations for both the Mailbox and Client Access server role. Exchange 2013 reduced the number of roles from previous versions of Exchange by making the design and implementation as simple as possible. The Server Role Requirement Calculator helps us to size both physically and virtually and it provides in-depth sizing of every component of the hardware like CPU, Memory, Network, Storage, Backup, servers, datacenter etc.

Built-in tools for CAS Monitoring in Exchange 2016/2019

With some small and medium size businesses unable to afford larger, enterprise solutions for Exchange monitoring, we will explore the local tools built into Exchange to help you leverage Exchange CAS monitoring from within the Exchange program itself. This article is meant as an overview detailing the built-in tools available and may require more independent reading and learning before making any changes to your organization’s solution.