Microsoft announced the release of Exchange 2013 last fall, but this was not very useful to most of us, because there was no support for previous versions of Exchange until new Service Packs and Hotfixes were available. In other words, you could not install Exchange 2013 into your current Exchange organization. In February Microsoft finally released Exchange 2007 SP3 RU10 and Exchange 2010 SP3, to enable coexistence between the platforms. As is typical of Microsoft, they support an N-2 upgrade path. This means you can upgrade to 2013 from two versions back. Exchange 2003 (and prior) version will not allow upgrade to Exchange 2013. In-place upgrades of Exchange 2007 and 2010 versions are not supported either. This is typical and even if it was supported I would never recommend it. It’s nice to start from scratch and deploy a new Exchange environment and apply the things you’ve learned from previous installs.
My test environment includes Forefront Threat Management Gateway 2010, so the upgrade path will include the steps for modifying and testing client access through the TMG as well. Here is a general diagram of my lab environment. It is running:
- Two Exchange 2010 servers running combined CAS/HUB role, behind a Kemp Technologies VLM1000 for load-balancing
- Two Exchange 2010 mailbox role servers configured in a single Database Availability Group (DAG)
- One Exchange Unified Messaging role server connected to a Lync 2010 environment
As I mentioned, an in-place upgrade is not recommended or supported, so we will be building Exchange 2013 side-by-side in the same Active Directory (AD) site as Exchange 2010.
Some things to note:
- Each organization requires at a minimum one Client Access server and one Mailbox server in the Active Directory forest. Additionally, each Active Directory site that contains a Mailbox server must also contain at least one Client Access server. If you’re separating your server roles, we recommend installing the Mailbox server role first.
- The computer you install Exchange 2013 on must have a supported operating system (such as Windows Server 2008 R2 with Service Pack 1 (SP1) or Windows Server 2012), have enough disk space, be a member of an Active Directory domain, and satisfy other requirements. For information about system requirements, see Exchange 2013 System Requirements.
Which version of Windows Server 2012?
When installing on Windows Server 2012 you now have two options compared to older versions of Windows: Standard Edition and Datacenter. In the past we had to use Enterprise edition for clustering, etc. Microsoft has done away with Enterprise edition. All aspects of Exchange 2013 will run on Windows 2012 Standard edition.
Checklist for updating from Exchange 2010:
- Prepare your Environment
- Verify your prerequisites
- Install Exchange 2010 SP3 across your organization
- Prepare Active Directory with the Exchange 2013 schema
- Validate existing client access
- Deploy Exchange 2013 servers
- Install both Exchange 2013 CAS and Mailbox
- Obtain and Deploy Certificates
- Obtain and deploy certificates on your E2013 CAS servers
- Switch Primary Namespace to Exchange 2013 CAS
- Exchange 2013 fields all traffic, including traffic from Exchange 2010 users
- Validate client access
- Move Mailboxes
- Build out your Exchange 2013 Database Availability Groups (DAGs)
- Move Exchange 2010 mailboxes to Exchange 2013
- Repeat for additional sites
Installing Exchange 2013 Prerequisites on Windows 2012
Microsoft TechNet recommends running two different cmdlets based on server role, but if you compare the two they are exactly the same. Therefore, I recommend running the following on each Exchange 2013/Windows 2012 server.
- Open PowerShell
- Run the following cmdlet:
Install-WindowsFeature AS-HTTP-Activation, Desktop-Experience, NET-Framework-45-Features, RPC-over-HTTP-proxy, RSAT-Clustering, RSAT-Clustering-CmdInterface, RSAT-Clustering-Mgmt, RSAT-Clustering-PowerShell, Web-Mgmt-Console, WAS-Process-Model, Web-Asp-Net45, Web-Basic-Auth, Web-Client-Auth, Web-Digest-Auth, Web-Dir-Browsing, Web-Dyn-Compression, Web-Http-Errors, Web-Http-Logging, Web-Http-Redirect, Web-Http-Tracing, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Lgcy-Mgmt-Console, Web-Metabase, Web-Mgmt-Console, Web-Mgmt-Service, Web-Net-Ext45, Web-Request-Monitor, Web-Server, Web-Stat-Compression, Web-Static-Content, Web-Windows-Auth, Web-WMI, Windows-Identity-Foundation
Client Access Role
Install the following software:
Mailbox role
Install the following software:
Prepare Active Directory for Exchange 2013
Starting with Exchange 2010 I believe these steps are built into the GUI install, but call me old-school, I still prefer to use the command-line to perform Schema updates. This is a very good practice especially if you run Exchange in multiple AD sites where AD replication might not be instantaneous.
NOTE: Something new for Exchange 2013, you must add the /IAcceptExchangeServerLicenseTerms switch when running Setup.exe |
- Run Setup.exe /PreparedSchema /IAcceptExchangeServerLicenseTerms
- Run Setup.exe /PreparedAD /IAcceptExchangeServerLicenseTerms
- Before running this step I was required to reboot. Run Setup.exe /PreparedAllDomains /IAcceptExchangeServerLicenseTerms
Now your environment is ready to install Exchange 2013. Click on the link below for Part 2 in this series.
Upgrading from Exchange 2010 to Exchange 2013 on Windows 2012 (Part 1)
Upgrading from Exchange 2010 to Exchange 2013 on Windows 2012 (Part 2)
During a recent discussion on monitoring for devices which can be monitored with Operations Manager (but without installing an agent) one of my co-workers mentioned that we can use the new Operations Manager 2012 network monitoring for non-SNMP devices by using ICMP only mode. This approach lets you monitor devices which can only be monitored via ping type monitors (similarly to the discussion on the free OpsLogix ping management pack). When I think of network monitoring in Operations Manager my brain automatically goes to SNMP – I had forgotten completely that Operations Manager can do ICMP access mode which is a pretty useful tool to have available.
This blog post will explain how we discover network devices using only ICMP, what we get from using network monitoring with ICMP only mode in Operations Manager, and what can be configured for this functionality.
How to discover network devices via ICMP only monitoring
You can create a new network discovery or add an entry for the new items to an existing network discovery. Use the Access Mode of ICMP to specify that it will be ICMP only monitored device.
What do we get from using Network Monitoring running in ICMP only mode in OpsMgr 2012?
Where do we see the device if we are monitoring it only via ICMP? It appears in the Network Monitoring folder in the Hosts view as shown below.
Since it is a network device, it also appears on the Network Summary Dashboard.
Since it’s part of the Operations Manager framework, we can use Health Explorer to see it’s health and details on what the interval, number of retries and timeout information as shown below.
Health explorer:
The existing dashboards also work for this type of a device such as the vicinity view and average availability.
What performance counter(s) are collected?
The ICM ping response time counter is gathered for the ICMP only monitored device as shown below in the ICMP Ping Response Time performance view.
Configuration of the ICMP only monitored device:
You can also configure different ways to use this functionality through overrides as shown below where the network device can be configured to create an alert, or you can change the interval, number of retries, timeout, packet size and more.
Summary: Using the built-in network ICMP only network monitoring capabilities for Operations Manager makes it easy to add devices which can only be monitored via ping. This approach integrates with the pre-built network monitoring dashboards in Operations Manager and can be customized through the use of overrides.
Thank you to Brian Pavnick for bringing this question to my attention!