Mark posted earlier about Exchange 2007 virtualization.
My goal is to extend that post with information on the MBX Server Role. Microsoft support virtualization of all roles but the UM Server role. With respect to virtualization of the MBX role it's important to configure HA options that don't combine Exchange availability options with Hyper-V virtualization options. In other words Microsoft doesn't support using CCR or SCC with Hyper-V quick migration. Both CCR and SCC are supported in hardware virtualization environments.
Virtualization snapshots are not application aware and can't be used with CCR for recovery.
Many hardware virtualization products allow you to specify the number of virtual processors that should be allocated to each guest virtual machine. The virtual processors located in the guest virtual machine share a fixed number of logical processors in the physical system. Exchange supports a virtual processor-to-logical processor ratio no greater than 2:1. For example, a dual processor system using quad core processors contains a total of 8 logical processors in the host system. On a system with this configuration, do not allocate more than a total of 16 virtual processors to all guest virtual machines combined.
The Exchange Server guest virtual machine must still be sized appropriately to handle the workload.
For details and guidance about sizing Exchange server roles, see:
Supporting large mailboxes (for example, 1 GB and larger) requires the use of cluster continuous replication or hardware-based VSS solutions. Using hardware-based VSS is not possible in a hardware virtualization environment.
LCR, CCR, SCC, and SCR are all supported for virtualization environments.
Some hardware virtualization software includes features that support the clustering or portability of guest virtual machines across multiple physical root machines. For example, Hyper-V includes a clustered solution called quick migration, which combines Hyper-V host machines with Windows failover clustering. For more details about quick migration, you can download the Quick Migration with Hyper-V White Paper.
We recommend using the built-in Exchange Server high availability solutions for virtualized Exchange servers instead of hypervisor-provided clustering or portability solutions (such as Hyper-V's quick migration feature). The features found in Exchange Server (in particular, cluster continuous replication (CCR)) provide greater benefits than those found in hypervisor solutions that move virtual machines between physical root machines.
It is supported to deploy CCR or SCC using a combination of physical nodes and virtual nodes. As with all Exchange high availability configurations, you must ensure that all nodes are sized appropriately to handle the full workload during scheduled or unscheduled outages.
More info on virtualization for Exchange 2007 can be found on technet.
I had an Ivy league university ask about this. There is a way to do this documented below:
General split permission model - http://technet.microsoft.com/en-us/library/aa996881(EXCHG.80).aspx.
UM Split Permission model - http://technet.microsoft.com/en-us/library/bb266903(EXCHG.80).aspx
They also had a specific question around delegating the Auto Attendant wave files. Here is a potential workaround:
You can re-record UM custom prompts (Dial Plan and/or Auto Attendant) over the phone, i.e. by calling in to the system.
So it might be easier to accommodate the “low privilege UM prompt admin” role by doing the following:
1. Create a domain account (e.g. CONTOSO\umpromptadmin)
2. Disable the ability for the account to log in interactively
3. Make the account an Exchange org admin
4. Create a mailbox for the account and UM enable it
5. Give the prompt administrators the pilot number, extension number and PIN they need to log in to change prompts
Lack of interactive login means they’ll never get to run EMC or Exchange Management Shell – only use the TUI to rerecord the prompts.
There are some upcoming administration delegation changes in Exchange14 that we can blog in a few weeks that help with these scenarios.
One of the best ways to estimate the number of channels needed to handle your call workload is to use an Erlang traffic model. This well-known call-statistics calculation method helps you to determine how many channels you need to support call traffic and gives you a good starting point for investigating your deployment requirements.[1] Keep in mind these are great tools but working with your voice partner can help determine proper sizing for your OCS deployment.
Erlang calculations use a unit of measurement called the Erlang. An Erlang describes traffic through telephony equipment (such as incoming calls into a phone switch or PBX).
1 Erlang = 1 continuous 3600 second (60 minute) call
To determine the maximum number of Erlangs that you need to accommodate, multiply the number of calls during the busy hour (B)[2] by the average call length in seconds (L), and then divide by 3600:
Erlangs = (B*L)/3600
For example, if you estimate that your deployment will receive 1000 calls during the busy hour and the average length of a call is two minutes (120 seconds), the estimated number of Erlangs is determined as:
(1000*120)/3600 = 33.3 Erlangs
When you have established the number of Erlangs your deployment will process, you can use an Erlang traffic calculation to determine the number of required telephony channels. The Erlang traffic formula is a mathematical algorithm that incorporates the number of Erlangs you estimated plus a percentage of blocked calls (or busy signals) that you think is acceptable. For example, if you take the 33.3 Erlangs from above and you can tolerate 1 percent call blockage, the Erlang traffic calculation determines that your deployment needs to scale to 45 concurrent channels.
In OCS the Mediation server needs to be sized against the gateway for call traffic.
Start with campus average busy hour Erlang from/to OCS users
For small deployment assume all calls across GW link; proportion will decrease with size of deployment
Allow resources for call forwarding, simultaneous ringing of mobile (tromboning)
Suggested orders of magnitude
Mediation Server is key in sizing!!!!
Mediation Server supports about 230 simultaneous calls with dual proc dual core this represents about 2300 “medium” users. T1 carries 23 calls so one Mediation Server can support about 10 T1 (8 E1)
[1] More about the Erlang methods including calculators are available online at http://www.erlang.com/.
[2] The busy hour (B) is the hour of operations during which the highest number of phone calls are arriving into your call center.