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.
I believe the real question is how can I prevent my organizations messages from being tampered. The answer is PKI. Public Key Infrastructure. In Exchange 2007 PKI is used for a number of things from self-signing on install to PKI for TLS for the Edge Transport Server. PKI has been traditionally used for "Sign and Sealed" for message traffic. What does this mean? The first question to ask is, "How do you know the message truly came from the suspected source?" and second "How do you know the message has not been intercepted or tampered with?"
These questions are answered with digital signatures and encryption. Digital signatures provide authentication, nonrepudiation, and data integrity, encryption of the traffic keeps the message contents confidential.
In Exchange this is provided via S/MIME - Secure/Multipurpose Internet Mail Extensions.
S/MIME is the only option for Outlook 2007 to digitally sign a message. With IRM (Information Rights Management) protection is more limited because there is no authority to verify the identity of the sender. With IRM the interface doesn't show information about the identity of the sender as it does with S/MIME.
You can also encrypt messages so they aren't sent in the clear. The purpose of this blog is to focus on digital signatures.
To setup digital signatures across your organization you can use GPOs. The Outlk12.adm template provides the cryptography options needed to secure mail in the org. Under User Configuration\Administrative Templates\Microsoft Office Outlook 2007\Security\Cryptography, double-click the policy setting you want to set.
In our case we can set to sign all messages.
For more information on this http://technet.microsoft.com/en-us/library/cc179034.aspx
I thought this was pretty amazing to watch with some very simple items you can have an amazing smartboard for any surface.
I love gadgets so I am taking this project on. I figured it may be an interesting way to kick off a demo of OCS/Exchange with schools when I am onsite. :)
Here is a great link on how to set this up for your school here.
They are selling whiteboard IR pens here already and if you want to make your own IR pen go here.
Some cool free whiteboard software for download here.