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.
Each AD site where Exchange 2007 exist needs a GC that is at least Windows 2003 Sp1 or later.
The following applies to domain controllers:
RODC (Read-only domain controllers)
No version of Microsoft Exchange uses read-only domain controllers or read-only global catalog servers. However, Microsoft Exchange works in environments that include read-only domain controllers or read-only global catalog servers, as long as writeable domain controllers are available. In these environments, Exchange 2007 effectively ignores read-only domain controllers and read-only global catalog servers.
Domain functional level
You should use at least Windows 2000 Server native for all domains in the Active Directory forest where you will install Exchange 2007 or that will host Exchange 2007 recipients.
Forest functional level
If you plan to use any of the following advanced features, the forest functional level must be Windows Server 2003 in each forest that contains Exchange servers:
A disjoint namespace is the scenario in which the primary Domain Name System (DNS) suffix of a computer does not match the suffix of the domain name where that computer resides. Limited tests were performed to validate Exchange 2007 on a computer that has a disjoint DNS namespace. These tests showed that any issues resulting from this configuration may be resolved by ensuring that the DNS suffix search list on an Exchange server references all DNS namespaces that are deployed within the organization. The list of namespaces should include not only Active Directory and Exchange servers, but also the namespaces for other servers with which Exchange may interoperate, such as monitoring servers or servers for third-party applications. For detailed information about supported scenarios with disjoint namespaces, see Understanding Disjoint Namespace Scenarios with Exchange 2007.
Single-label DNS names
Single-label DNS names are not recommended for use with Exchange 2007 or Exchange 2007 SP1. For additional information about single-label DNS names, see Knowledge Base article 300684, Information about configuring Windows for domains with single-label DNS names.
AD Ratios to Mailbox Servers
Customer today asked me about Outlook 2007 clients. They are planning on doing there schema update for Exchange 2007 and curious what this does to the Outlook 2007 clients. The 'service-connection-point' class is defined in the schema and the SCP objects published in AD contain information that various applications can use to direct clients to bind to a particular service. Exchange 2007 makes use of SCP's to advertise autodiscover service information specifically.
Clients, such as Outlook 2007, will search against a GC to locate SCP's in the forest by querying AD for objectclass=serviceconnectionpoint. In E2K7 during the setup of the Client Access Server role autodiscover will create an SCP object (obviously with an objectclass of serviceconnectionpoint) under the container:
By default the serviceBindingInformation attribute of this object will be updated during setup with the autodiscover service url:
The client will follow this url to determine configuration information for some mobile devices for example, or to provide access to the OAB.
This url can be changed using the set-clientaccessserver cmdlet with the parameter -AutodiscoverServiceInternalURI.
Figure 1 The Autodiscover service process for internal access
For external access, the client locates the Autodiscover service on the Internet by using the primary SMTP domain address from the user's e-mail address.
Depending on whether you have configured the Autodiscover service on a separate site, the Autodiscover service URL will be either https://<smtp-address-domain>/autodiscover/autodiscover.xml or https://autodiscover.<smtp-address-domain>/autodiscover/autodiscover.xml. Figure 2 illustrates a simple topology with a client connecting from the Internet.
Figure 2 The Autodiscover service process for external access
Previously I posted information about Federating across Universities for collaboration. One of my colleagues at Indiana University, Matt Dixon, has setup a registry for Universities to understand who is federated and how to federate with them. This is a great as it allows Universities to education across borders and use tools like Instant Messaging, Audio and Video Conferencing, and whiteboarding to peer schools as well as open the door for tutor mentorship from Universities to K-12 schools.
The registry allows registered users to look up schools in which to federate with. Great Job, Matt!!!!
Go here to federate - https://accountmgmt.exchange.iu.edu/OCSEduRegistry/
The First Step after installation of the Access Edge and activating the server is to configure the server. Run the Configuration Wizard and enable the server for federation.
Before I start setting up Federation with Public IM it is important to note that both the External Edge of the Access Edge and Web Conferencing Edge need to have public certs. This is not needed for the A/V Edge Server. It is recommended to use a separate IP address for each role even if both services are collocated.
For the scaled single-site edge topology, it's recommended that each server role use a separate VIP address on the external load balancer. A separate certificate matching the FQDN of each VIP address used by each Access Edge and Web Conferencing Edge server role must be installed on that server. For example, the Web Conferencing Edge Servers must have a certificate that matches the VIP address used by the Web Conferencing Edge Servers on the external load balancer.
The Provider addresses are:
Yahoo - lcsap.msg.yahoo.com
AOL - sip.oscar.aol.com
Live - federation.messenger.msn.com
For the public certificate it is important to have both client and server authorization. This is because the AOL SIP Proxy requires both, the MSN and Yahoo can be done with a web certificate. I would plan for all three and use the client/server authorization.
After the certs are installed you need to setup federation on the Access Edge Server. You can setup with three different levels:
1. Automatic discovery - traffic is based at a trust level - this is the default.
2. Discovery with Allow List - discovery but trust level can be higher for Allowed List parties
3. Do not allow discovery and base access on the allow list.
To enable federation:
1. Log on to the Access Edge Server as a member of the Administrators group or a group with equivalent user rights.
2. Open Computer Management. Click Start, click All Programs, click Administrative Tools, and then click Computer Management.
3. In the console tree, expand Services and Applications, right-click Microsoft Office Communications Server 2007, and then click Properties.
4. On the Access Methods tab, select the Allow discovery of federated partners check box.
Adding Federated Partners:
3. On the Allow tab, click Add.
4. In the Add Federated Partner dialog box, do the following:
· In the Federated partner domain name box, type the domain of each federated partner domain.
· In the Federated partner Access Edge Server box, optionally type the FQDN of each Access Edge Server that you want to add to your Allow list. Remember if you configure the FQDN of a partner’s Access Edge Server and the FQDN changes, you must manually update your configuration for this partner.
· Click OK.
After that make sure you setup your Global settings to ensure that anonymous participants can join meetings.
After this is done you can setup users and enable them for federation and Public IM. To do this you can configure the users with the wizard and select both federation and federation with Public IM.
Keep in mind users that have the domain in their Live ID already will be notified that they have a domain name that belongs to the University. This is an example of the form letter.
Q&A on PIC:
Does everyone with a Windows Live ID (Passport Identity) with an email in my enterprise domain receive the email? A: Only legitimate email address will receive the notification. A legitimate address means anyone who currently has an inbox on your corporate email server. Q: Can I obtain the list of addresses that you find using my enterprise domain? A: No. These addresses are considered Personally Identifiable Information (PII) and our Terms Of Use restrict us from sharing them with you. Q: Where can I get more information? A: All the notification messages have links that point to http://support.microsoft.com/gp/Messenger/ for more detailed information. Should you have additional questions regarding LCS/PIC, please go to: http://www.microsoft.com/office/livecomm/prodinfo/publicim.mspx
I had this question asked by a large Midwestern university medical center with regards to health care penetration of Exchange. Here is what I dug up from a Ferris study of over 900 businesses representing 10.6 millions messaging users:
Exchange:
The study is here: http://www.ferris.com/?p=318858
While we are talking data points, I found some interesting information around OCS from Gurdeep Sing Pall, Corp VP of UC:
I got a chance to do a Tuesday Tech talk on Unified Communications for Education and they recorded it for your viewing pleasure. I turned on my RoundTable for the session and demoed several pieces of UC including web conferencing, ActiveSync, OWA, CWA, software powered VOIP.
We had around 60 schools participate so I was happy with the turnout.
To watch me give an overview of Exchange Server 2007 and Office Communications Server 2007 and some demos visit here. Drop me a blog comment if you have any questions or feedback good or bad. :)
To see other upcoming or recorded Tuesday Tech talks for Education go here.
This is was from a Midwestern university which asked a question around how does MOSS and OCS work together. Below is a sample of how presence or click to chat/call is surfaced in MOSS:
Based on above you would think there would be some server side configurations on MOSS required to surface OCS presence or click to chat/call functionality. The reality is this is all performed with client side controls and the Office Communicator client.
In order for rich presence and/or click to chat/call to work in SharePoint the following is required on the end user’s side:
How does it work?
When a SharePoint page is displayed, the ActiveX control is invoked on the client to display the presence icons on the web page such as above. The ActiveX control talks to Office Communicator locally on the client to request the presence status of the user(s) being shown. The ActiveX control also talks to Outlook (if Outlook is open) to gather additional information such as availability based on calendar. Outlook gets this information from Exchange Server. Because this information is collected from the other client-side applications that the user is already running, you can be sure that the presence controls only ever show information that the user already had permission to see
I found this useful TechNote on support boundaries for Exchange 2007 running on Hyper-V:
Terms You Should Know:
Hypervisor— a layer of software sitting just the hardware and beneath one or more operating systems
Root—the physical machine that runs the hardware virtualization software
Guest—a virtual machine that is running as a child machine of a hardware virtualization environment. The virtual machine typically runs at a second or third level above the hardware in the host machine
Pass-through—storage that is configured at the host level and dedicated to one guest machine
Microsoft supports Exchange Server 2007 in production on hardware virtualization software only when all the following conditions are met:
- The hardware virtualization software is Windows 2008 with Hyper-V technology, Microsoft Hyper-V Server, or any third party hypervisor that has been validated under the Windows Server Virtualization Validation program
-Exchange application is not Hyper-V aware (no plans to change Setup experience)
-Build out virtual machine configuration prior to installing Exchange
-Exchange sizing guidance is the same for physical and Hyper-V systems
Root OS Configuration:
-Separate LUN’s/Arrays for Root OS, Guest OS VHD’s and Hyper-V/VM Storage
-LUN’s should employ RAID to provide data protection and performance
-Snapshot creation and differencing disks for VM’s are not supported for production Exchange systems
-Oversubscribing CPU’s greater than 2:1 (Virtual Processor/Physical Core) is not supported for Exchange
-No Exchange (or other applications) running in Root OS
Guest OS Configuration:
-W2K8/E2K7 SP1 only
-Fixed VHD’s for Virtual OS
-Need to account for page file consumption in addition to OS requirements
15GB+VM Memory Size = Minimum VHD Size
Per VM Disk Requirements for Exchange Roles must include space for .VSV (even if it’s not used)
Exchange Storage Configuration:
-Storage should be on spindles separate from Guest OS VHD physical storage
-Exchange storage must be Fixed VHD, SCSI pass-through or iSCSI
-FC/SCSI HBA’s must be configured to Root OS and LUN’s presented to VM’s as pass-through or VHD
Backup for Virtualized Exchange
-No integration between Exchange VSS Writer and Hyper-V VSS Writer
-Must backup from within guest
-Hardware VSS/VDS does not work
Supported— Windows 2008 + Exchange 2007 SP1; Exchange 2003 SP2
Unsupported— Unified messaging server role; VHD Disks>2040 GB; dynamically expanding virtual disks; virtual disks that use differencing or delta mechanisms
A couple of other notes I have been informed about:
Exchange sizing rule of thumb is it runs at around 98% of physical on Hyper-V so using current sizing tools/guidelines of physical can be used.
For mailbox role, go physical where possible. More information around sizing the mailbox server for Hyper-V to come.