Moving past parts 1 and 2, I now have all my clients using my new inventory classes I created. I’ve verified with a few clients that they are successfully sending this data to the site server. What’s next? The next piece of this process is to query the database, however this is an optional step. What we'll discuss next is setting up the SSRS report, but I always like to setup a SQL query in the SCCM console first. It’s a quick and easy way to figure out what’s in your database.
ENow Software's Exchange blog built by Microsoft MVPs for IT/Sys Admins.
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.
Microsoft SCCM (and MDT) are great tools that provide a robust system to lay down OS images onto many clients. Once setup, SCCM admins and technicians can easily image computers all day every day without thinking about how much time and money they’re saving the company. Rather than just telling your boss you’re making progress on something like the Windows XP replacement project you’ve got going on why not give her/him real, hard numbers of how many devices you’ve been knocking out over the past 6 months?
To do this we’re going to need to build a SCCM report. We need a report that will show us, historically, how many PCs we’ve imaged over a set amount of time. I’m also going to go out on a limb and say we want this report to update automatically and to not require any kind of intervention. Do I have your interest? I hope so!
Before we get started building this boss-loving and beautiful report we should first outline how it will work. Retrieving historical data from the database server in a report requires a few different steps which I’ll be discussing in this article series. In part 1 of the series I’ll show you where the information is stored on the client that you’ll need to gather to determine if the client was imaged with SCCM or MDT. Once I know what I’m looking for I’ll then go over how to get this information into the SCCM database through creating a custom hardware inventory class.
In part 2 of the series, I’ll go over how to verify that the hardware inventory class was setup correctly by going over the pertinent logs and show you what query I created inside the SCCM console to quickly ensure the clients are sending the right information to the database.
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)
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.
Disk space is vital to the health of an Exchange Server. Without disk you don’t have email, thus Exchange monitoring - disk space is vital. Exchange is dependent on having disk because every time an email is sent it’s written to disk, without it you’re S.O.L.
When exchange databases run out of disk space the databases will dismount. Dismounted databases are usually not a good thing because that means email is down for the users in that database. Systems with low disk space can also impact overall performance of the server. Any of these events happening to an exchange server is not good. We all know that when email is slightest bit slow or down, the users will react like the zombies are attacking and the sky is falling.
Keep the zombies away…
If you are using tools such as ENow Exchange Monitoring, System Center Operations Manager, or Spotlight, monitoring Exchange disk space can be pretty easy. If your budget does not allow for third party software, however, you are left to monitor their servers manually. Manual Exchange monitoring can be a pain and not practicable for some shops due to the size of their environment. This is especially true if you’re running an environment with multiple Exchange 2010 DAG nodes, with replicating databases across many mount point paths.