November 2009
Monthly Archive
written by admin on
Nov 30, 2009
With the release of Exchange 2007 SP2 we provided a Supportability Matrix which outlined the supported configurations for Exchange 2000 SP3, Exchange 2003 SP2, and Exchange 2007 (RTM, SP1, and SP2). But as many are aware, with the release of Windows Server 2008 R2 there have been a variety of questions raised about our support policies and a multitude of feedback. Two pieces of feedback occurred numerous times - the need to support Exchange 2007 on Windows Server 2008 R2 and the need to support Exchange 2003 against Windows Server 2008 R2 Active Directory servers.
In response to this feedback we will be making several updates to the supportability matrix.
- As I recently blogged about, we will be adding support for Exchange 2007 on the Windows Server 2008 R2 platform. While we had hoped to add this application/operating system combination quickly, unfortunately adding this support requires code changes to setup in Exchange 2007. Therefore, our vehicle for adding this support will be via a third Service Pack for Exchange 2007 in the second half of calendar year 2010.
- Exchange 2003 SP2 will now be supported against writeable Windows Server 2008 R2 Active Directory Servers. Additionally, with the General Availability of Exchange Server 2010, and those looking to standardize on Windows Server 2008 R2 we have enhanced the supportability of forest and domain functional levels up to Windows Server 2008 R2. This change is effective immediately on Exchange 2003 SP2.
- Exchange 2007 is now supported on servers running .NET Framework 3.5 SP1 provided that the .NET platform was upgraded from .NET Framework 2.0. This change is also effective immediately on Exchange 2007 SP2.
Each of these changes are being made to provide the flexibility you requested - to change your operating system architecture without changing your messaging architecture. In addition to the existing combinations, we will be adding supportability guidance for Exchange 2010 to the matrix. Note that all of these changes may not immediately appear on the supportability matrix, but be assured that any documentation update lag will not affect your supportability with Microsoft Support.
Finally I do want to update all on one other piece of feedback we have received - allowing the in place upgrade of the operating system under Exchange. Technically the work required to provide this capability is consistent with the work we would need to do to support an in-place upgrade of Exchange itself. As such the amount of work needed is outside the scope and complexity of what we can do in a post release product update. Still we do understand the demand and desire and it is something we will continue to look at for future versions of the product.
While we hope these changes are welcome news and address questions you may have had, we also understand we have areas to improve in. Our desire is to simplify and improve the support experience with Exchange. If you have more feedback, please continue to provide it.
Kevin Allison
General Manager, Exchange Customer Experience
written by admin on
Nov 21, 2009
It has been about a couple of months since we released Exchange Server 2007 Service Pack 2. About 3 years ago when we shipped Exchange Server 2007 we promised cumulative update rollups every couple of months. Keeping with that promise we have released Update Rollup 1 for Exchange Server 2007 Service Pack 2 (KB 971534) to the download center today. The release of the rollup via Microsoft Update will happen on November 24. Update rollups are service pack dependent, so you need to first upgrade to Exchange Server 2007 SP2 before deploying this Update Rollup.
While the bulk of the changes in this rollup are bug fixes we have also made some improvements to the experience when installing the patch. We laid the foundation for these improvements in the Exchange Server 2007 SP2 product MSI which also included requiring everyone to upgrade to Windows Installer 4.5. We are building upon it in this rollup and hope to improve your experience during installation of these patches.
1) Ability to cancel installation of a rollup - As most of you have noticed the cancel button in the rollup is disabled for most of the time. This is because the custom actions implemented in the patch did not have corresponding rollback versions. Hence a cancel of the install would have meant that the system state would not have been rolled back. We have redesigned this area of the code and enabled the administrators to cancel installation and rollback the system to the initial state whenever possible. Note that there are still some critical points during setup where we disable canceling, for example when we reach the end of the installation sequence where canceling install at that point would take longer than finishing up the rollup deployment.
2) Pre-installation checks for common issues faced by customers
a. We now check for the lack of internet connectivity, which can cause longer installation times due to the system trying to obtain the Certificate Revocation List from the HTTP URL specified in the signing certificate. If we detect the absence of internet connectivity we provide a warning (see below). The link points to the topic How to Install the Latest Service Pack or Update Rollup for Exchange 2007 in the Exchange Server 2007 TechCenter documentation which covers the steps to update the system configuration to not do the check under the section "When Exchange cannot connect to the Internet". We will also post a blog shortly on the technical details about this.
b. KB 970104 - We check if the user account initiating the install of the rollup has adequate permissions. If the user does not have Exchange Organizational Administrator permissions, the installation throws an error before making any changes to the system. The most common case of this is seen when users install the rollup using an account which is a local administrator and see that Outlook Web Access is not working because the user account did not have permissions to update the OWA component in Active Directory which requires running some cmdlets which require Exchange Server Administrator privileges.
3) Shorter downtime of Exchange Services during deployment of the rollup by doing a 2 step Native Image Generation. This is the place where the rollup installer seems to be stuck for a long time with the message "Creating native images for .NET assemblies. This process can take an extended period of time to complete." If NGEN is busy imaging non-Exchange .NET assemblies in the system due to a pending queue then Exchange services are down for a lot longer than they need to be.
a. Step 1 will keep Exchange services running while imaging non-Exchange .NET assemblies in the system.
b. Step 2 will stop Exchange services and then image the Exchange assemblies.
The advantage to this two step process is that if Step 1 takes a large chunk of the maintenance interval than expected, the administrator can cancel the rollup installation and reschedule the installation of the rollup to a future time.
4) Ability for Exchange administrators to execute custom PowerShell scripts before and after rollup installation to stop 3rd party services loading Exchange assemblies and causing a reboot. More on this in a blog post coming up soon.
Some of the other critical product bug fixes in this rollup which we would like to call out are
1) KB 971010 - Intermittent issue where a database does not mount when CCR failover happens due to missing temp log file
2) KB 941775 - Running Isinteg for the first time on a newly created DB fails with Error: FULLCHKMGR::EcReadRowCountGlobalFlag failed with error JET_wrnColumnNull
3) KB 972115 - Transport rule does not fire for Message Delivery Notifications if header is folded because the report-type is not evaluated
KB 971534 has more details about this release and a complete list of all fixes included in this rollup.
We welcome your feedback on the improvements we have made in this rollup. Also, a friendly reminder again that we will be watching our Exchange Software Updates forum which is available to provide assistance if you encounter issues when deploying the rollup.
- Exchange Customer Experience team
written by admin on
Nov 20, 2009
By now most of you have heard about the release of Exchange 2010. Those of you that are upgrading from Exchange 2003, Exchange 2007 or a mixture of the two, are probably curious about the client access upgrade strategy. To satisfy your curiosity, we are releasing a series of blog articles on the subject. The first in this series provides a summary of the steps that are required to introduce Exchange 2010 within your environment from a client access perspective. More detailed information about the upgrade process is discussed in TechNet and within the Deployment Assistant. The second and third parts in this series will discuss the end user experience for OWA and ActiveSync, respectively. Look for those in upcoming weeks.
Many of you have been asking how you can transition your existing Exchange environment to Exchange 2010 from a client access perspective. For most of you, this will also mean coexisting with legacy Exchange and Exchange 2010 for a period of time. This post will hopefully answer these questions by breaking down your transition into two scenarios:
- Transitioning an Exchange 2003 environment to Exchange 2010.
- Transitioning an Exchange 2007 (that may or may not contain Exchange 2003 mailbox servers) environment to Exchange 2010.
The underlying goal here is to move your primary namespace, mail.contoso.com and autodiscover.contoso.com, over to Exchange 2010 and introduce a new namespace for legacy access, legacy.contoso.com and associate it with your legacy Exchange client access infrastructure. Users will continue to use mail.contoso.com as their access point into the organization for messaging services. While Exchange 2003/2007 end users will see the legacy.contoso.com namespace in their browser address bar, ActiveSync settings, and Test Auto-Configuration output within Outlook, they only need to use the mail.contoso.com namespace as their primary entry point into the organization; in addition, IT should continue directing customers to utilize the mail.contoso.com namespace for all external connectivity mechanisms.
Note: The host names, mail.contoso.com or legacy.contoso.com, that are referenced in this document are not hard-coded or required. You can utilize whichever names make the most sense for your environment (e.g. owa.contoso.com and legacyowa.contoso.com). From a documentation perspective, we are going to utilize mail.contoso.com and legacy.contoso.com so that we are consistent in our transition story. For more information on Autodiscover namespaces, please see http://technet.microsoft.com/en-us/library/bb332063.aspx.
Transitioning an Exchange 2003 Environment to Exchange 2010
When you are ready to begin transitioning your organization to Exchange 2010, you must transition the "Internet Facing AD Site(s)" first, and then transition your internal Active Directory sites. It is not supported to transition an internal Active Directory site before all your Internet-accessible sites have been transitioned.
The steps for introducing Exchange 2010 into the environment are:
Note: These steps do not discuss how to set up your CAS2010 servers in a load balancing array. Please review your load balancing solution's instructions for how to properly create and join your CAS2010 servers in a load balancing array.
1. In order to support external client coexistence with CAS2010 and legacy Exchange in your "Internet Facing AD Site", you will (potentially) need to acquire a new commercial certificate. As a best practice, Microsoft recommends utilizing a certificate that supports Subject Alternative Names; however, you can utilize a wildcard certificate as well.
This commercial certificate that will be leveraged by external clients will contain at a minimum three SAN values (note that other scenarios may require you to add additional values):
- mail.contoso.com (your primary OWA/EAS/OA access URL)
- autodiscover.contoso.com
- legacy.contoso.com (your OWA/EAS namespace for legacy mailbox access)
Prior to Windows Vista SP1, the Windows RPC/HTTP client-side component required that the Subject Name (aka Common Name) on the certificate match the "Certificate Principal Name" configured for the Outlook Anywhere connection in the Outlook profile. Therefore, as a best practice, you should ensure that mail.contoso.com is listed as the Subject Name in your certificate unless you plan on changing the configuration which can be achieved by using the Set-OutlookProvider cmdlet with the EXPR parameter as described in http://msexchangeteam.com/archive/2008/09/29/449921.aspx.
2. Ensure all Exchange 2003 servers are at Service Pack 2 and that you meet all forest/domain pre-requisites.
3. Install CAS2010 and configure it accordingly:
- During the installation of CAS2010 you have the option to enter the external namespace that will be used for the virtual directories. You can enter this value in both the graphical user interface or the command-line setup:
- For the graphical user interface setup experience of CAS2010 you are asked to configure a Client Access external domain. At this point you canter the domain name of mail.contoso.com.
- If installing via the command line, you can utilize the setup property /ExternalCASServerDomain and specify mail.contoso.com
If you haven't already done so, install the RPC over HTTP proxy component. You can do this utilizing the ServerManagerCmd tool: ServerManagerCmd.exe -i RPC-over-HTTP-proxy Configure your OWA settings appropriately (e.g. forms based authentication vs. basic authentication). For the purpose of this document, the default OWA settings are assumed. Configure your EAS authentication settings appropriately (e.g. Basic vs. certificate authentication). For the purposes of this document, the default authentication mechanism, basic authentication, is assumed. Enable Outlook Anywhere (for the purposes of this document, the default authentication settings are assumed): Enable-OutlookAnywhere -Server:<CAS2010> -ExternalHostName:mail.contoso.com - SSLOffloading $false 4. If you chose to not specify the external domain name for CAS during setup, you will need to enable the following ExternalURLs to ensure that clients that leverage Autodiscover function correctly:
5. To ensure that Outlook Web Access functions correctly, you will need to enable the following URLs:
Exchange Control Panel: Set-ECPVirtualDirectory <CAS2010>\ECP* -ExternalURL https://mail.contoso.com/ECP 6. For your Outlook clients, you can configure CAS2010 to participate in an RPC Client Access Service array:
- Create a load balancing array for CAS2010, if one has not already been created.
- Create a DNS entry in your internal DNS infrastructure that resolves to the Virtual IP Address (VIP) of the CAS load balancing array. The DNS entry, for example, could be outlook.contoso.com.
- Configure your load balancing array to load balance the MAPI RPC ports:
- TCP 135
- UDP/TCP 1024-65535
Run the following cmdlet to create the Client Access Service array: New-ClientAccessArray -Name outlook.contoso.com -FQDN outlook.contoso.com -Site "Internet Facing AD Site" 7. Install the HT2010 and MBX2010 server roles into the "Internet Facing AD Site" and configure accordingly.
- You can change the Offline Address Book generation server and enable web distribution on CAS2010 by performing the following steps:
- To move the Offline Address Book: Move-OfflineAddressBook "Default Offline Address List" -Server <MBX2010>
- To add CAS2010 as a web distribution point:
- $OABVDir=Get-OABVirtualDirectory -Server <CAS2010>
- $OAB=Get-OfflineAddressBook "Default Offline Address List"
- $OAB.VirtualDirectories += $OABVdir.DistinguishedName
- Set-OfflineAddressBook "Default Offline Address List" -VirtualDirectories $OAB.VirtualDirectories
8. Create the legacy host record (legacy.contoso.com) in your external DNS infrastructure and associate it either with the FE2003 infrastructure (less likely) or your proxy infrastructure (more likely).
9. You will configure External DNS and/or your reverse proxy infrastructure's publishing rules to have the autodiscover.contoso.com namespace point to CAS2010.
10. If utilizing a reverse proxy infrastructure, you will publish the legacy namespace to the FE2003 infrastructure so that at this point the FE2003 infrastructure can be accessed either via mail.contoso.com or legacy.contoso.com namespaces.
11. You will then schedule Internet protocol client downtime (please note that this downtime window should be relatively small - enough time for you to make the change and validate that everything works as desired) and perform the following steps:
- You will reconfigure External DNS and/or your reverse proxy infrastructure's publishing rules to have the mail.contoso.com namespaces point to CAS2010.
- Users with mailboxes on an Exchange 2003 server who try to use Exchange ActiveSync through an Exchange 2010 Client Access server will receive an error and be unable to synchronize unless Integrated Windows authentication is enabled on the Microsoft-Server-ActiveSync virtual directory on the Exchange 2003 server. This allows the Exchange 2010 Client Access Server and the Exchange 2003 back end server to communicate using Kerberos authentication.
To enable this authentication change on Exchange 2003 you need to either:
- Install http://support.microsoft.com/?kbid=937031 and then use the Exchange System Manager to adjust the authentication settings of the ActiveSync virtual directory. Repeat this for each Exchange 2003 mailbox server in your organization.
- Or, set the msExchAuthenticationFlags attribute to a value of 6 on the Microsoft-Server-ActiveSync object within the configuration container on each Exchange 2003 mailbox server. An example script is provided at http://technet.microsoft.com/en-us/library/cc785437.aspx.
Note: It is important that you do not use IIS Manager to change the authentication setting on the Microsoft-Server-ActiveSync virtual directory as the DS2MB process within the System Attendant will overwrite the settings that are stored in Active Directory.
- Disable Outlook Anywhere by utilizing the Exchange System Manager and selecting the "Not part of an Exchange managed RPC-HTTP topology" radial button on the RPC-HTTP tab of the Front-End server's properties. Optionally, you can also remove the RPC over HTTP proxy component (refer to your Windows Server documentation for more information).
Important: This requires an up-front investment in CAS2010 architecture as all Outlook Anywhere clients will utilize CAS2010 once you transition the Outlook Anywhere endpoint. Be sure to follow all proper scalability planning documentation when deploying CAS2010 to ensure that you do not create a bottleneck in your CAS infrastructure due to Outlook Anywhere clients.
- Test all client scenarios and ensure they function correctly.
12. Complete downtime and enable Internet protocol client usage.
As a result of following these steps, the environment would look similar to this diagram:
Transitioning an Exchange 2007 environment to Exchange 2010
When you are ready to begin transitioning your organization to Exchange 2010, you must transition the "Internet Facing AD Site" that is associated with your external Autodiscover record, then regional Internet facing AD Sites, and then transition your internal Active Directory sites. It is not supported to transition an internal Active Directory site before all your Internet-accessible sites have been transitioned.
The steps for introducing Exchange 2010 into the environment are:
Note: These steps do not discuss how to set up your CAS2010 servers in a load balancing array. Please review your load balancing solution's instructions for how to properly create and join your CAS2010 servers in a load balancing array.
1. In order to support external client coexistence with CAS2010 and legacy Exchange in your "Internet Facing AD Site", you will (potentially) need to acquire a new commercial certificate. As a best practice, Microsoft recommends utilizing a certificate that supports Subject Alternative Names; however, you can utilize a wildcard certificate as well.
This commercial certificate that will be leveraged by external clients will contain at a minimum three SAN values (note that other scenarios may require you to add additional values):
- mail.contoso.com (your primary OWA/EAS/OA access URL)
- autodiscover.contoso.com
- legacy.contoso.com (your OWA/EAS namespace for legacy mailbox access)
Prior to Windows Vista SP1, the Windows RPC/HTTP client-side component required that the Subject Name (aka Common Name) on the certificate match the "Certificate Principal Name" configured for the Outlook Anywhere connection in the Outlook profile. Therefore, as a best practice, you should ensure that mail.contoso.com is listed as the Subject Name in your certificate unless you plan on changing the configuration which can be achieved by using the Set-OutlookProvider cmdlet with the -EXPR parameter as described in http://msexchangeteam.com/archive/2008/09/29/449921.aspx.
2. Ensure all Exchange 2007 CAS within the organization are at Service Pack 2, all Exchange 2003 servers (if they exist) are at Service Pack 2, and that all Exchange 2007 Mailbox, Hub Transport, and Unified Messaging servers are at Service Pack 2 in the "Internet Facing AD Site". Also, ensure you meet all the forest/domain pre-requisites.
3. Install CAS2010 and configure it accordingly:
- During the installation of CAS2010 you have the option to enter the external namespace that will be used for the virtual directories. You can enter this value in both the graphical user interface or the command-line setup:
- For the graphical user interface setup experience of CAS2010 you are asked to configure a Client Access external domain. At this point you canter the domain name of mail.contoso.com.
- If installing via the command line, you can utilize the setup property /ExternalCASServerDomain and specify mail.contoso.com
If you haven't already done so, install the RPC over HTTP proxy component. You can do this utilizing the ServerManagerCmd tool: ServerManagerCmd.exe -i RPC-over-HTTP-proxy Configure your OWA settings appropriately (e.g. forms based authentication vs. basic authentication). For the purpose of this document, the default OWA settings are assumed. Configure your EAS authentication settings appropriately (e.g. Basic vs. certificate authentication). For the purposes of this document, the default authentication mechanism, basic authentication, is assumed. Enable Outlook Anywhere (for the purposes of this document, the default authentication settings are assumed): Enable-OutlookAnywhere -Server:<CAS2010> -ExternalHostName:mail.contoso.com -SSLOffloading $false 4. If you chose to not specify the external domain name for CAS during setup, you will need to enable the following ExternalURLs to ensure that clients that leverage Autodiscover function correctly:
5. To ensure that Outlook Web Access functions correctly, you will need to enable the following URLs:
Exchange Control Panel: Set-ECPVirtualDirectory <CAS2010>\ECP* -ExternalURL https://mail.contoso.com/ECP 6. If you have Exchange 2007 deployed in "Non-Internet Facing AD Sites" then you must copy the Exchange 2007 OWA binaries to CAS2010:
- On the CAS2010 server(s), establish a connection to the CAS2007 server's drive that contains the Exchange binaries and navigate to the \Client Access\OWA directory (e.g. \\cas2007\c$\Program Files\Microsoft\Exchange Server\Client Access\Owa).
- Copy the highest version folder (e.g. 8.2.140.0) from the CAS2007 to CAS2010 Exchange binaries \Client Access\OWA directory (e.g. C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\Owa).
- Execute IISReset on all the CAS2010 machines.
7. For your Outlook clients, you can configure CAS2010 to participate in an RPC Client Access Service array:
- Create a load balancing array for CAS2010, if one has not already been created.
- Create a DNS entry in your internal DNS infrastructure that resolves to the Virtual IP Address (VIP) of the CAS load balancing array. The DNS entry, for example, could be outlook.contoso.com.
- Configure your load balancing array to load balance the MAPI RPC ports:
- TCP 135
- UDP/TCP 1024-65535
Run the following cmdlet to create the Client Access Service array: New-ClientAccessArray -Name outlook.contoso.com -FQDN outlook.contoso.com -Site "Internet Facing AD Site" 8. Install the HT2010 and MBX2010 server roles into the "Internet Facing AD Site" and configure accordingly.
- You can change the Offline Address Book generation server and enable web distribution on CAS2010 by performing the following steps:
- To move the Offline Address Book: Move-OfflineAddressBook "Default Offline Address List" -Server <MBX2010>
- To add CAS2010 as a web distribution point:
- $OABVDir=Get-OABVirtualDirectory -Server <CAS2010>
- $OAB=Get-OfflineAddressBook "Default Offline Address List"
- $OAB.VirtualDirectories += $OABVdir.DistinguishedName
- Set-OfflineAddressBook "Default Offline Address List" -VirtualDirectories $OAB.VirtualDirectories
9. Create legacy host record (legacy.contoso.com) in your external DNS infrastructure and associate it either with the CAS2007 infrastructure (less likely) or your proxy infrastructure (more likely).
10. If utilizing a reverse proxy infrastructure, you will publish the legacy namespace to the CAS2007 infrastructure so that at this point the CAS2007 infrastructure can be accessed either via mail.contoso.com or legacy.contoso.com namespaces.
11. You will then schedule Internet protocol client downtime (please note that this downtime window should be relatively small - enough time for you to make the change and validate that everything works as desired) and perform the following steps:
- You will re-configure your CAS2007 URLs in the "Internet Facing AD Site". This ensures that clients that leverage Autodiscover function correctly and that legacy mailboxes can be redirected to Outlook Web Access:
If you have Exchange 2003 mailbox servers in your environment, then users with mailboxes on an Exchange 2003 server who try to use Exchange ActiveSync through an Exchange 2010 Client Access server will receive an error and be unable to synchronize unless Integrated Windows authentication is enabled on the Microsoft-Server-ActiveSync virtual directory on the Exchange 2003 server. This allows the Exchange 2010 Client Access Server and the Exchange 2003 back end server to communicate using Kerberos authentication. To enable this authentication change on Exchange 2003 you need to either:
Note: It is important that you do not use IIS Manager to change the authentication setting on the Microsoft-Server-ActiveSync virtual directory as the DS2MB process within the System Attendant will overwrite the settings that are stored in Active Directory.
- Disable Outlook Anywhere on your Exchange 2007 CAS infrastructure in the "Internet Facing AD Site" by utilizing the cmdlet, Disable-OutlookAnywhere -Server <CAS2007>. Optionally, you can also remove the RPC over HTTP proxy component (refer to your Windows Server documentation for more information).
Important: This requires an up-front investment in CAS2010 architecture as all Outlook Anywhere clients will utilize CAS2010 once you transition the Outlook Anywhere endpoint. Be sure to follow all proper scalability planning documentation when deploying CAS2010 to ensure that you do not create a bottleneck in your CAS infrastructure due to Outlook Anywhere clients.
- You will reconfigure External DNS and/or your reverse proxy infrastructure's publishing rules to have the autodiscover.contoso.com and mail.contoso.com namespaces point to CAS2010.
- Test all client scenarios and ensure they function correctly.
12. Complete downtime and enable Internet protocol client usage.
As a result of following these steps, the environment would look similar to this diagram:
So why the additional namespace?
To understand why we are introducing a new namespace for the legacy Exchange environment, it is important to understand what the Internet client behavior will be by introducing Exchange 2010.
- For Outlook Web Access, Exchange 2010 CAS does not support rendering mailbox data from legacy versions of Exchange. Exchange 2010 CAS does one of four scenarios depending on the target mailbox's version and/or location:
- If the Exchange 2007 mailbox is in the same AD Site as CAS2010, CAS2010 will silently redirect the session to the Exchange 2007 CAS.
- If the Exchange 2007 mailbox is in another Internet facing AD Site, CAS2010 will manually redirect the user to the Exchange 2007 CAS.
- If the Exchange 2007 mailbox is in a non-Internet facing AD site, CAS2010 will proxy the connection to the Exchange 2007 CAS.
- If the mailbox is Exchange 2003, CAS2010 will silently redirect the session to a pre-defined URL.
For Exchange ActiveSync, Exchange 2010 CAS does not support rendering mailbox data from legacy versions of Exchange. Exchange 2010 CAS does one of four scenarios depending on the target mailbox's version and/or location, and device capabilities: - If the Exchange 2007 mailbox is in the same AD Site as CAS2010 and the device supports Autodiscover, CAS2010 will notify the device to synchronize with CAS2007.
- If the Exchange 2007 mailbox is in the same AD Site as CAS2010 and the device does not support Autodiscover, CAS2010 will proxy the connection to CAS2007.
- If the Exchange 2007 mailbox is in a non-Internet facing AD site, CAS2010 will proxy the connection to the Exchange 2007 CAS.
- If the mailbox is Exchange 2003, CAS2010 will proxy the connection to the Exchange 2003 mailbox server.
For Outlook Anywhere, you are going to move the Outlook Anywhere endpoint from the Exchange 2003 Front-End or Exchange 2007 CAS to the Exchange 2010 CAS. Exchange 2010 CAS will always proxy the Outlook MAPI RPC data that is embedded in the RPC-HTTPS packet to the target legacy mailbox server (regardless of AD site or version) or to the appropriate Exchange 2010 CAS. Important: This requires an up-front investment in CAS2010 architecture as all Outlook Anywhere clients will utilize CAS2010 once you transition the Outlook Anywhere endpoint. Be sure to follow all proper scalability planning documentation when deploying CAS2010 to ensure that you do not create a bottleneck in your CAS infrastructure due to Outlook Anywhere clients.
Conclusion
Hopefully this information improves your understanding of client access coexistence with legacy versions of Exchange while transitioning to Exchange Server 2010. Please let us know if you have any questions.
- Ross Smith IV
written by admin on
Nov 20, 2009
Hopefully you caught the news yesterday at PDC09 that Microsoft Office 2010 beta is now available for download! One of the cool new features added in the beta for Outlook 2010 is the Outlook Social Connector, which connects social network data into Outlook and displays relevant information to you based on the current context.
This is a great feature, and will enable all sorts of great scenarios. Even cooler, it’s a new platform that can be leveraged by developers looking to integrate with Outlook. Today Randy Byrne posted details over on the Outlook blog about how to integrate with the OSC.
Out of the box, Outlook will connect to SharePoint 2010, and we’ve announced a partnership with LinkedIn to connect with as well. However, anyone can build a provider to plug into the OSC and provide data from any data source. Some examples we’ve been thinking of include connecting to an internal CRM system, to show the latest updates about a customer when you receive an e-mail.
If you’re interested, make sure you download the beta and try building an OSC Provider. Click through to Randy’s post for more information.
written by :: Microsoft Outlook Forum :: on
Nov 20, 2009
I’m happy to announce that a new member has joined the Outlook platform family. The new arrival has a long and formal name known as Microsoft Outlook Social Connector Provider Extensibility, but the name shouldn’t stop you from getting acquainted with this exciting new extensibility feature for Outlook 2010!
What is an Outlook Social Connector (OSC) provider?
The Microsoft Outlook Social Connector is an add-in that surfaces social network data including friends, profiles, activities, and status information from social networks in Microsoft Outlook. The user interface of the OSC is shown below:

The OSC obtains social network data using an OSC provider, which provides the abstraction layer between the OSC and the APIs offered by social networks.
If the provider implements the required OSC provider extensibility interfaces and is registered with the OSC, the data from the social network becomes available to Outlook so that an end user can view social data in the context of the Outlook user interface. OSC providers can be developed by third parties or individual social networks that want to expose their social data in Outlook. Think of an OSC provider as a translation layer between Outlook and your favorite social network. Another great scenario for corporate customers is to create a provider that connects to a in-house business application, and surfaces business information about people directly inside of Outlook. The provider extensibility stack is represented by the following diagram:

How do I develop an OSC provider?
You can develop an OSC provider using the development tool of your choice. When you develop an OSC provider, you are not writing MAPI or Outlook Object Model code. The OSC core engine handles writing activity or contact information to the user’s default store. Your OSC provider simply hands back XML to the OSC core engine when methods are called on the required interfaces. The XML should conform to the OSC schema defined by OutlookSocialConnector.xsd. Each OSC provider is built on a set of required interfaces that must be implemented by your provider code. The interface contract is defined by a type library installed with the OSC, socialprovider.dll. The documentation for the required interfaces is available in the following MSDN technical article:
http://msdn.microsoft.com/en-us/library/ee829696(office.14).aspx
An OSC provider can be written using managed languages such as Microsoft Visual C# or Microsoft Visual Basic, or unmanaged languages such as Microsoft Visual C++. Any tool that can create a COM-visible DLL component can be used to develop an OSC provider. The decision to use a managed or unmanaged language to develop a provider should take into account the download size and dependencies of the provider installation package.
An OSC provider must be COM-visible as defined by the following:
- After installation, an OSC provider must be registered using COM self-registration or regsvr32.
- COM registration of an OSC provider DLL registers the provider under HKCU or HKLM.
- A provider’s ProgID is registered under HKCU\Software\Microsoft\Office\Outlook\SocialConnector\SocialProviders
- An OSC provider developed in a managed language (that is, a managed OSC provider) is COM-visible.
Is sample code available?
All developers love sample code that helps to unleash their creativity, so of course sample code is available! To get started, take a look at the sample code available on http://code.msdn.microsoft.com/odcOL14OSCProvider:
- TestProvider, a Visual C# sample provider that implements all interface members required for the Beta version of the OSC
- The OSC schema, OutlookSocialProvider.xsd
- Provider templates that you can use to develop your own provider in the following languages:
How do I learn more?
To learn more about OSC provider extensibility, read the technical article on MSDN and download the sample provider and provider templates. Be aware that the OSC interfaces and members might change between the OSC Beta and the final release of Outlook 2010.
If you represent a social network or are interested in developing an OSC provider for your favorite social network or line of business application, contact us at oscprex@microsoft.com and we will consider enrolling you in the OSC provider extensibility preview program.
Randy Byrne
Outlook Program Manager
written by admin on
Nov 19, 2009
Messageware's OWA Print, ActiveSend and AttachView--which are now compatible with Exchange 2010. Messageware OWA Print is the first and only quality printing solution for OWA and OWA Light, Messageware ActiveSend allows users to easily send files using OWA and Messageware AttachView significantly extends the functionality of OWA’s WebReady Document Viewing feature.
written by admin on
Nov 18, 2009
This one can be a bit counter intuitive for folks coming from any legacy version of Exchange...
Issue
You got your shiny new Exchange 2010 download and excitedly installed it on your 2010 hardware. You have setup all your CAS server settings, your DAG is up and running. Your pilot users have been moved over and everything went well.
Now you move over the executives and not two days later they are in your office complaining that they can't manage the distribution groups that they own. They were able to do it previously but now it isn't working.
A little bit of testing later and you see that they are right. You are hitting an error message in Outlook 2007 when trying to manage groups:
So what does the "Changes to the distribution list membership cannot be saved. You do not have sufficient permission to perform this operation on this object." error mean, when you are connecting to an Exchange 2010 server?
It means Exchange 2010 is doing its job - as designed...
Why is it doing this?
Exchange 2010 has quite a few features built in to allow your users to manage their own accounts and information. One of these features is the ability to manage distribution groups in a much richer format than Outlook 2007 provides.
This allows your users to join existing group, manage some of the properties of groups they own, membership in groups they own, and even create and remove groups. It is that last piece that got our beta customers a bit concerned. The ability to manage your own groups is good... the ability to create and remove groups - not so good.
Also this feature was turned on by default. So by default you would install Exchange 2010 Beta and any users you put on it could create and remove Distribution Groups. With that in mind the Product group decided to turn this feature off by default going forward and in RTM.
Turning it off is very easy... so is turning it on. All you have to do is assign the MyDistributionGroups RBAC role to the Default Role Assignment Policy. We even have the ability to do that in the ECP.
Since all of the built in RBAC roles have to function as parents to any roles that you create the product group had to leave the ability to create and remove distribution groups on this role to ensure that any customers that wanted their users to have that functionality would be able to assign it.
So how do I fix it?
"Fix" isn't really the right word. We need to modify the default solution to meet this specific need. For a number of customers the needs are going to be the following:
- I want my users to be able to manage distribution groups they own.
- I don't want them to be able to create distribution groups.
- I don't want them to be able to remove distribution groups even if they do own them.
To help customers fill these needs we have created a short little script. This script will allow you to make any combination of the above work in your environment.
Link to script
How do I run this thing?
To run the script you need to copy the contents of the script to a text file on the machine you are going to run it on. Then save the file as a .ps1... I recommend Manage-GroupManagementRole.ps1 .
To fill all of the above requirements with minimal effort run the following from an Exchange Powershell Prompt:
| Manage-Groupmanagmeentrole.ps1 -creategroup -removegroup |
This will create everything you need with the correct settings using the default names in the script. If you would like help on the script you can either look in the contents of the file or run it with no switches.
What does the script do?
What the script does is actually rather simple:
- Creates a new RBAC role that is a child of the MyDistributionGroups Role
- Removes the cmdlets remove-distributiongroup and new-distributiongroup from the new role that was just created.
- Assigns the new role to the Default Role Assignment Policy
When complete your users will be able to manage distribution groups but not create or remove them.
Each step the script takes is documented in the script and you are welcome to extract just what you need from it. It is designed to handle more than just the basic scenario to give it a bit more flexibility.
What do I end up with if I take the defaults?
When finished you end up with a new role and a new role assignment. If we look at these in PowerShell we see:
Here is the Role that is created by the script. By default it is named MyDistributionGroupsManagement and is a child of the MyDistributionGroups role.
Here we can see all of the cmdlet that the role authorizes users to use. You can see that remove-distributiongroup and new-distributiongroup are not listed.
This is the piece that glues everything together. The role assignment is created using the name of the role and the name of the policy we are assigning the role too. The Default Role Assignment Policy applies to all users in the org by default. So everyone on Exchange 2010 will now have the ability to manage their own distribution groups.
Conclusion
Hopefully this post and the attached script will help you in getting your 2010 environment up and running where you want it. If you have any questions about the script or this process please feel free to post them here and I will do my best to address them.
- Matt Byrd
written by :: Microsoft Outlook Forum :: on
Nov 18, 2009
We are excited to announce the Outlook Social Connector!
The Outlook Social Connector is a set of new features to help keep track of your friends and colleagues while enabling you to grow your professional network. The Outlook Social Connector is available now as part of the Microsoft Office 2010 Beta.
The Outlook Social Connector (OSC) brings social views of your colleagues and friends right to your Inbox. As you read your e-mail messages, glance down at the new People Pane to see the picture, name, and title of the sender. A rich, aggregated collection of information about the sender is included.

The OSC presents useful information including:
- Communication history Your mailbox is searched and the recent messages you’ve exchanged with that person appear. Can’t remember the last time you e-mailed this person? A quick look at the OSC reveals the last time you received an email from them, and one click opens up the message.
- Meetings When is the next scheduled meeting with this person? The OSC shows upcoming appointments that include you and the message sender.
- Attachments Can’t find the attachment that the person is referring to in a message? With the OSC you can quickly review attachments that you and the sender have exchanged. One-click access quickly opens the attachment or you can see the message that it is attached to.
- Activity feeds Stay on top of activities involving your colleagues and friends in real time. The OSC connects to business and consumer social networks.
- Did you say activity feeds? Yes we did! The OSC makes Outlook 2010 a social networking tool by connecting to the new social experiences in SharePoint 2010. That connection allows the OSC to download activity feeds for colleagues and display them inside the new People Pane:

You’ll see rich information about your colleagues’ activity such as profile updates to their MySite, documents and websites they tag, and changes to their personal status message.
Know who you’re meeting with. Use the OSC’s Gallery View to see all of the people you’ll be interacting with in an upcoming meeting:

One click on any of those pictures puts you into the single-person view, providing easy access to their activities and communication history. You can easily switch in and out of Gallery View by clicking on the little double-arrow icon in the upper-right corner of the People Pane.
Build your network. The OSC makes it easy to grow your network; by clicking the ‘+’ symbol underneath a person’s picture, you can send a request to be their colleague on any of the networks you are connected to. The OSC also automatically synchronizes your colleagues from each of your connected networks and saves them as contacts in Outlook. This allows you to easily send messages, call, or synchronize contacts just as you would any other Outlook contact.
Open Connectivity. The OSC in Outlook 2010 will connect by default to the new social networking experiences in SharePoint 2010. We are happy to announce that connectivity to any network, including SharePoint, is built using our public ‘provider’ extensibility platform:

This means that anyone can build a provider to connect the OSC to a social network, their company’s line-of-business applications, or literally any system that can produce streams of activity about its users. The SDK will be publically available tomorrow on MSDN, and my colleague Randy Byrne will be making a more detailed post on provider development with links to the SDK at that time. We are excited to make this platform public and are looking forward to feedback as our customers begin developing providers for their networks and business solutions.
Go Live! Next year we will be releasing a provider for Windows Live, enabling you to connect to your friends and colleagues on Windows Live right inside of Outlook:
You see pictures, profile updates, and personal status messages of your friends from Windows Live Messenger. See their Office application and document activity through SkyDrive integration, and the aggregation of dozens of other third-party sites from around the world.
Are you working with other social networks? You bet! Outlook has partnered with LinkedIn, the online professional networking site, to provide an amazing connected experience for our shared customers. The LinkedIn team has built a provider for the OSC using our public SDK, providing you with pictures and activity information for your colleagues directly from their network. Simply click on a message from a co-worker to discover what new connections they’ve made on LinkedIn, or click the LinkedIn badge underneath a photo to jump right to a person’s profile page on the Web.

Keep watching the Outlook Team Blog for an announcement about when the LinkedIn provider is available to Outlook 2010 users. You can learn more about the LinkedIn provider here on their website.
Customize it! Does your company use a large system for managing information about its users or customers? By building an OSC provider to connect to your ERP or CRM solution, you can easily sync down people-related information into Outlook and see it in the People Pane when you’re reading your mail. Randy will have more information in his post about how to build a custom provider.
Let’s recap! The Outlook Social Connector, new to the Outlook 2010 Beta, provides you with:
- The People Pane A name, picture, and title for your colleagues whenever reading a message from them.
- Rich history See a rich communications history for each person that sends you messages with one-click access to the most recent messages and attachments.
- Activities Download and see real-time activity for your colleagues from business and social networks.
- Get friendly Request someone as a colleague or friend with one click. Synchronize those colleagues with Outlook and keep them up-to-date as their information changes.
- SharePoint 2010 Connect to the new MySite social networking experience right out of the box with the OSC & SharePoint 2010.
- Extensible A public SDK allows anyone to build a connection to business or consumer social networks.
On behalf of the entire Outlook Social Connector feature team, thanks for trying the Outlook 2010 Beta. Have fun using the OSC!
Michael Affronti
Social Networking Addict & Outlook Program Manager
written by :: Microsoft Outlook Forum :: on
Nov 18, 2009
Today, we are thrilled to announce the release of the public Beta of Microsoft Office 2010! Betas for Office 2010, as well as SharePoint Server 2010, Visio 2010, and Project 2010 are available for download at www.microsoft.com/2010. This is an exciting and significant milestone for both the Office and Outlook teams, because it means that for the first time, anyone can download Office 2010! You can learn more about the complete release of the Office 2010 beta on our Office blog.
The Outlook team is particularly excited for a number of reasons – the beta release represents the latest and best version of Outlook 2010 we’ve been working on. Features that we’ve discussed on this blog in recent months – Conversation Arrangement, Quick Steps, Mail Tips, Calendar Preview, Multiple Exchange Accounts and more – are all now publicly available and accessible through the beta for anyone to try today. In addition to the features we’ve already discussed here, we’ve invested a great deal between the Technical Preview release and today’s beta around the user interface, performance, and overall fit and finish. Finally, we are introducing a great new feature today, the Outlook Social Connector.
In addition to the beta release, the Office team has also done a great deal of work to improve our online content and experience, and you can see the latest information on Office 2010 and more by visiting the newly designed Office.com.
The beta is a significant milestone in the development of Office and Outlook 2010, but we’re not done yet! Our final and official release of Office 2010 is still slated for the first half of 2010, and I encourage you to keep in touch with us on this blog to learn more as we enter the final phases of our development efforts to release Office 2010.
Finally, I’d like to personally thank everyone who has been involved with our efforts to release the beta today – in addition to the Outlook engineering team, there have been countless customers and partners who have given us invaluable feedback along the way to help make this beta what it is today. I know I speak for all of them when I say go download the beta of Office 2010 and enjoy!
Dev Balasubramanian
Outlook Product Manager
written by admin on
Nov 18, 2009
The Office 2010 Beta is now available for the general public to download. I highly recommend users not install it on their “production” system. If you ignore this advice, install the 32-bit version, especially if you use add-ins or sync with devices. Existing add-ins will not work with the 64-bit build.
Next Page »