562 Networks

vSphere4 Unleashed: 01 – Installing ESX4.0 from Hany Michael on Vimeo.

Wanted to share some notes on Vmware Vsphere. First you need to install your first ESXI machine. After that log into that ip via browser to download V center. We have posted a video below for a easy know how.

vSphere4 Unleashed: 02 – Installing vCenter 4.0 from Hany Michael on Vimeo.

With the release of Exchange Server 2010, organizations that are on Exchange 2007 are weighing when they are going to shift to Exchange 2010 to take advantage of the new features of capabilities, and organizations who are on earlier versions (like Exchange 2003 or even Exchange 2000) are considering their options to leapfrog over Exchange 2007 and go straight to Exchange 2010.

As with any migration process, there are things that work, and there are things that don’t work.  This article will cover the high level good, the bad, and the ugly with upcoming blog posts where I’ll provide specific migration steps, tips, tricks, and best practices.  For now, this post is to give you the overall view of the migration.

The Good

• Exchange 2010 from an overall design perspective is really nothing more than a service pack type revision of Exchange Server 2007.  Server roles like Client Access, Hub Transport, Mailbox, and Edge server roles are the same between Exchange 2007 and Exchange 2010
• With similar server roles, if you have already deployed Exchange 2007, you would just build out Exchange 2010 server roles similar to what you have today.  So if you have 2 CAS servers today in Exchange 2007, you’d build out 2 CAS servers for Exchange 2010.  If you have combined your CAS and Hub Transport (HT) roles into a single server today in Exchange 2007, you’d likely combine your CAS/HT server roles into a single server in Exchange 2010.  If you virtualized your CAS, HT, and Edge servers today in Exchange 2007, you’d virtualize those server roles in Exchange 2010
• For organizations that have planned their migration from Exchange 2003 to Exchange 2007 but haven’t completed the migration, you can for the most part just search/replace Exchange 2007 to Exchange 2010 in your architecture and design documentation and deploy Exchange 2010 instead of Exchange 2007 (note: you will make changes to the way the Mailbox role is handled as Exchange 2010 no longer supports Single Copy Clusters or Cluster Continuous Replication but instead uses Database Availability Groups, however for the most part, the design of Exchange 2010 is similar to that of Exchange 2007 with some (pretty significant) improvements)
• Because Exchange 2010 now writes data to the EDB databases sequentially (instead of as random disk writes), Exchange 2010 is SIGNIFICANTLY more efficient at disk read/write IO.  Where we used to recommend organizations get extremely high IOPS supported SAN storage, with Exchange 2010, we have deployed the same configurations on iSCSI (instead of Fibre Channel) or even local storage SATA drives (this has resulted in significant savings in the cost of storage for organizations migrating to Exchange 2010)
• If you’re familiar with the Exchange 2007 Management Console, the management console for Exchange 2010 is identical, no relearning the administrative interface
• If your client systems are running Outlook 2003 or Outlook 2007, you can effectively make the change from Exchange 2003 or Exchange 2007 to Exchange 2010 without the users ever knowing you have upgraded the backend servers because if migrated properly, the client connections automatically connect to Exchange 2010 without the user ever knowing the backend was upgraded
• I noted in an earlier posting on the top features and functions of Exchange 2010, but in a snapshot, the big movers are the database availability groups (DAGs) that effectively does away with the need for 3^rd party high availability and disaster recovery solutions and drastically lowers the cost of Exchange TCO.  And the archiving along with the support for non-Windows clients has been a big draw for organizations to jump on their migration to Exchange 2010.

The Bad

• It was a toss up whether I put this in the Bad or the Ugly column, you decide.  With Exchange 2010, when you migrate from Exchange 2003 or Exchange 2007 you must maintain your old Exchange 2003/2007 environment until you are completely migrated to Exchange 2010.  In a migration from Exchange 2003 to Exchange 2007, the minute you put in a CAS frontend to Exchange 2007 for Outlook Web Access, that CAS server would also host Outlook Web Access for the Exchange 2003 mailboxes, so you could just remove the Exchange 2003 Frontend server(s) once Exchange 2007 CAS servers were in place.  Or an Exchange 2007 Hub Transport server would route messages for both Exchange 2007 as well as Exchange 2003 bridgehead servers. But with Exchange 2010, the Exchange 2010 CAS server will only frontend an Outlook Web App web session for a mailbox on Exchange 2010, and for users with their mailbox still on Exchange 2003 or 2007, you must have an Exchange 2003 FE or 2007 CAS server for those users.  Likewise, an Exchange 2010 Hub Transport will only route messagesfor Exchange 2010 backend mailbox users, that users on Exchange 2003 still need an Exchange 2003 bridgehead server, and users on Exchange 2007 still need an Exchange 2007 Hub Transport server in parallel to the Exchange 2010 environment for messages to route.  Microsoft did not build in backwards compatibility on server roles because to do so would have meant that the Exchange 2010 server roles would have to be “dumbed down” to support legacy server roles forever, and if you only do the migration once, just get migrated completely to Exchange 2010 and be done with. What we found is that since we can virtualize the CAS/2010 and HT/2010 roles, we could build out the parallel environment pretty easily.  Most E2007 CAS/HT roles today are virtualized, so it hasn’t been like most organizations have dedicated hardware these days.  And Exchange 2003 servers typically can’t be reused for Exchange 2007 or Exchange 2010 due to the age and support for 64-bit, so orgs migrating from Exchange 2003 to Exchange 2010 have had to buy new hardware or virtualize anyway.  Your call if this is Bad or really Ugly.  When we did our first migration to Exchange 2010 a year+ before RTM under the early adopter program we thought it would be really ugly, however Microsoft built-in proxying to the CAS/2010 server so that you point all users to hit the CAS/2010 server for things like Outlook Web Access and they get redirected to the CAS/2007 or FE/2003 if their mailbox hasn’t been migrated yet
• For some, this might be bad although most orgs it’s been a non-issue.  Exchange 2010 requires that your Active Directory be on 2003 Native mode.  Most orgs have gone to 2003 Native already, although amazing how many organizations still have AD/2000 or never flipped the switch to get out of 2003 Mixed mode.  Come on folks, I hardly doubt there are NT4 “domain controllers” still in your environment to be running in Mixed mode.  You can run NT4 member servers in a Native Mode environment so if you happen to have a really old legacy application, you can still run NT4 member servers in 2003 Native.  So this might be a pre-req to get your AD to at least 2003 Native mode before you deploy Exchange 2010.  In the scheme of things, a migration to AD/2003 Native mode is typically a Friday night cutover type of thing, so hopefully this isn’t too bad of a requirement.
• By the way, I’m always asked if migrating to AD/2008 or AD/2008R2 is better for Exchange 2010, the answer is “no”.  Exchange 2010 doesn’t require AD/2008 or AD/2008R2 features, and while there are some really great things in AD/2008 (like fine grain passwords where you can set password policies “per group” instead of having the same password policy for your entire domain) or AD/2008R2 supports AES256 encryption.  So these are more like Windows things, not particularly Exchange things that you get when you go beyond AD/2003 Native mode for your migration to Exchange 2010
• I’m going to put this in the bad column however for a product that is “just” releasing to the public, you’d think that 3^rd party vendor support or basic functionality support would be in the ugly column but it isn’t.  For the release of Exchange 2010, 3^rd party vendors like RIM Blackberry, Symantec, and the like are releasing updates to their products almost immediately after product general availability.  The Exchange Team has learned from the past where they’ve released products and it was a year or two before mainstream vendors had support for the product, so with Exchange 2010, they got their 3^rd party vendors very involved in the beta so that their products were tested and working by the time the product released.

The Ugly

• Okay, had to come up with something in the “ugly” column here.  What I’d identify as something that has been an issue for some organizations is the lack of support of a direct migration from anything prior to Exchange 2003, so effectively if you are still running Exchange 2000, Microsoft does not have a migration wizard to get you to Exchange 2010. There are many ways we’ve accomplished the migrations from Exchange 2000 to Exchange 2010 including using 3^rd party tools like the Quest Exchange Migration Wizard (EMW) product, or we’ve had organizations migrate from Exchange 2000 to Exchange 2007, and then just add Exchange 2010 servers to the Exchange 2007 environment and move mailboxes over (if you don’t plan on to stay Exchange 2007, you don’t have to build out a hugely robust environment, we’ve done it completely on virtual servers for Exchange 2007 as a pass thru up to Exchange 2010).  So it’s not pretty if you have Exchange 2000, however you aren’t dead in the water either.  Just as a side note, if you haven’t noticed, Microsoft has been supporting migrations from the last 2 version to the new release but nothing prior.  So Exchange 2010 supports migrations from Exchange 2007 and 2003.  Windows 7 supports migrations from Windows Vista and XP (but not from Windows 2000), etc.  So here forward, you need to make sure you are not more than 1 version behind.

In upcoming posts, I’ll cover specific best practices on migrating from Exchange 2003 to Exchange 2010, and for migration from Exchange 2007 to Exchange 2010.  I’ll provide some step by step guidance as well as migration tips and tricks based on a couple years of early adopter experience with Exchange 2010.  Stayed tuned for more…

New to Exchange 2010 is the Exchange Control Panel, or ECP.  This is a component of Outlook Web App 2010 where an administrator can sit in their OWA screen and not only check their emails, calendar appointments, and contacts, but can perform administrative tasks.  So instead of the administrator having to find a computer and terminal server remote into a system to add a user, delete a user, make configuration changes in public folders, delegate administration or the like, the administrator can now run those tasks straight within OWA 2010.

The ECP is primarily targeted to be used by

End users—Personnel granted the authority to self-manage aspects of their accounts such as the ability to track messages they have sent and received, create and manage distribution lists, or edit aspects of their personal account information.

Hosted tenants—Tenant administrators for hosted customers.

Specialists—Personnel such as Help Desk operators, Department Administrators, and eDiscovery Administrators who have had the appropriate level of access delegated by administrators.

The ECP can be accessed through Outlook Web Access 2010 by logging into OWA and selecting the Options link. It can also be accessed directly via a URL which, by default, is located at   https://CASServerName/ecp

The Exchange Control Panel (ECP) is a web-based management console that can be accessed from web browsers that have no Exchange specific client-side software installed. It can be accessed from the same Internet browsers that are support the Outlook Web Access premium client—Internet Explorer 7+, Mozilla Firefox, and Apple Safari 3+. This AJAX-based application is built into the Client Access Server role in an Exchange environment and, although it shares some code with OWA, it is a separate application.

It is important to note the Exchange Control Panel is RBAC-aware, meaning that administrative options are available only to those who have the appropriate permissions to utilize them.  ECP can show a user logged in with full administrative access several administrative tasks (note the Select What to Manage option in the top-left corner and the Manage your Organization option in the bottom-right corner) which shows the same interface as viewed by a standard user.

By default, the standard user does have the ability to self-administer his account, as shown by the Edit link that when clicked allows the user to modify his Account Information. This default ability can be removed (or limited to certain fields only) using RBAC. For example

• If a user has been restricted from message tracking, that button does not appear in the ECP.
• If a user can edit mailboxes, but not create new ones, the New mailbox button will not display, but the Details button does.
• If users are allowed to edit their department but not their display name, the display name is visible but grayed out and read-only.

After an administrator elects to manage My Organization, the four main components of the Exchange Control Panel display, as shown in 18.6. These components are:

• UI Scope Control—At the top of the screen, identified by the text stating “elect What to Manage (and the drop-down box beside it), the UI Scope Control enables those with the appropriate RBAC permissions to select whether they want to manage themselves, their organization, or another user.
• Primary Navigation Panel—To the left of the screen is the Primary Navigation panel, enabling the administrator to select which area of administration she wants to work with.
• Secondary Navigation Panel—Next to the Primary Navigation Panel and identified by icons in the figure labeled Mailboxes, Groups, External Contacts, and so on, is the Secondary Navigation Panel, which enables the user to further specify the area to administer.
• The Slab—At the bottom of the pane, identified in the figure by the list of Display Names and E-mail addresses, is the slab  the list of items that can be administered based on the preceding selections.

Creating a New Mailbox in the Exchange Control Panel

Creating a new mailbox in the Exchange Control Panel is so easy that it’s hardly worth the time to explain it. However, because the ECP is brand new, this section runs through the process to show how quick and easy it is.

To create a new mailbox user in the Exchange Control Panel, perform the following steps:

1. Log in to the OWA server with administrative credentials.
2. From the OWA page, select Options.
3. Select Manage Your Organization.
4. Ensure My Organization is selected in the UI Scope Control, Users & Groups is selected in the Primary Navigation Panel, and Mailboxes is selected in the Secondary Navigation Panel.
5. Click the New Mailboxes icon.
6. On the New Mailbox page, enter the information for the new account. Those marked with asterisks (*) are required fields. An example of the New Mailbox page
7. When finished, click the Save button.

The ECP passes the information on to the CAS server, which, in turn, uses Remote PowerShell commands to perform the actual operation and create the account.

Creating Distribution Groups in the ECP

New in Exchange Server 2010 is the ability to create and manage distribution lists from within the Exchange Control Panel web interface.

Before we discuss the process, there are a few items to note:

• Although both Mail Universal Distribution Groups and Mail Universal Security Groups are visible from within the ECP, there is no noticeable differentiation between the two.
• All distribution groups created from within the ECP are created as Mail Universal Distribution Groups; there is no option to create a security group.
• Dynamic Distribution Groups are not visible from within the ECP, nor can new ones be created there.

To create a new distribution group in the ECP, perform the following steps:

1. Connect to the ECP by logging into OWA as an administrator and selecting the Options page, clicking Manage Your Organization, and selecting the Groups icon. Alternatively, you can go directly to https://{CAS server name}/ecp and authenticating through OWA.
2. Under Groups, click the New button.
3. In the New Group window complete the following fields:

• Display Name—(Required)—This name must be unique in the domain. This is the name that displays in the address book and on the To: line when mail is sent to the group. The display name should be user-friendly to help people recognize the purpose or membership of the group
• Alias—(Required)—This is the name portion of the e-mail address that appears to the left of the @ symbol. The alias must be unique in the domain and, because it is part of the e-mail address, cannot contain any spaces.
• Description—(Not Required)—This description populates the Notes field for the object. This descriptive name can be viewed by employees who view the properties of the distribution list. If populated, the field should describe the purpose or membership of the group.
• Ownership—(Required)—Owners can add members to the group, approve or reject requests to join, and approve or reject messages sent to the group.

By default, the person creating the group is added as a group owner. If an administrator creates the group at the request of an employee, the administrator can add the employee as an owner and then remove herself.

• Membership—(Not Required)—By default, all group owners are added as group members. If this behavior is not desired, deselect the check box for this option. Add or remove members to the group as desired.
• Membership Approval—(Required)—New to distribution groups in Exchange Server 2010 is the ability for users to self-manage their distribution lists, joining those that interest them and leaving those that don’t.

During the creation of the distribution group using the ECP, the following options are available:

• Owner Approval—Open—Anyone can join the group without being approved by the group owners.
• Owner Approval—Closed—Members can be added only by the group owners. All requests to join will be rejected automatically.
• Owner Approval—Owner Approval—All requests are approved or rejected by the group owners.
• Group Open to Leave—Open—Anyone can leave the group without being approved by the group owners.
• Group Open to Leave—Closed—Members can be removed only by the group owners. All requests to leave will be rejected automatically.

After all fields have been populated and all options selected, click Save to create the distribution group.

By integrating the two applications, users can simply go to OWA 2010 to get their email, calendar appointments, contacts, etc as they normally do, AND they can also see who in their IM list is online and initiate instant messaging conversations straight from within OWA.

The pre-requisites for this capability is to obviously be running Exchange 2010 with Outlook Web App 2010, and you need to be running OCS 2007 R2.

For this configuration to work, there are four high-level steps needed:

Properly Configure the Exchange 2010 Client Access Server.

Properly Configure the OCS 2007 R2 Server.

Modify Windows Firewall on the Client Access Server.

Confirm User Configuration.

Configuring the Exchange Client Access Server

There are five steps that must be taken to configure the Exchange Server 2010 Client Access Server:

1. Download and install the “Microsoft Office Communications Server 2007 R2 Web Service Provider” on your Exchange 2010 CAS server (this adds special DLLs and configuration files needed to link OWA 2010 to your OCS 2007 R2 environment)

2. Gather Information about the certificate used by the Client Access Server.

3. Edit the OWA Web Config file.

4. Enable OCS Integration.

5. Restart Internet Information Services.

Step 1:- Downloading/Installing the OCS 2007 R2 Web Service Provider Files

Download and install the “Microsoft Office Communications Server 2007 R2 Web Service Provider” from Microsoft http://www.microsoft.com/downloads/details.aspx?FamilyID=ca107ab1-63c8-4c6a-816d-17961393d2b8&displaylang=en and install this update on your Exchange 2010 CAS server (this adds special DLLs and configuration files needed to link OWA 2010 to your OCS 2007 R2 environment)

Step 2: Gather Certificate Information

The Client Access Server needs to use a certificate that is trusted by the OCS server. Effectively, you should be able to sit on the CAS server, run Internet Explorer, and access Communicator Web Access (CWA) and be able to logon to CWA with a user account without any certificate errors. If you sit on the OWA server and access CWA and you get an error that the certificate is not trusted, then you need to add the RootCA of the CWA certifcate to your “Trusted Root Certificates” on the OWA server, effectively letting the OWA server know that the CWA is a trusted server. If you get any CWA errors from a browser as a CWA user sitting on the OWA server, then the link between CAS and OCS won’t work.

NOTE: To simplify the configuration, the certificate used by the Client Access Server should be issued by the same Issuer as the certificate used by OCS 2007 R2.

Assuming you have no errors running CWA from the CAS server, then using Exchange PowerShell, gather certificate information of the Exchange Server by running the following command:

Get-ExchangeCertificate | fl

(The last character of the command is an L, not a one.)

Sample Output, with only relevant information shown:

IsSelfSigned : False

Issuer : CN=ca1, DC=companyabc, DC=com

SerialNumber : 71652G3R00000000001A

Services : IMAP, POP, IIS, SMTP

Status : Valid

Subject : CN=e2010w2k8

Locate the certificate that will be used and make note of the following information:

Issuer of the certificate
Serial Number assigned to the certificate
Subject of the certificate
Document this information for use in later steps.

Step 3: Edit the OWA Web Config File

On the Client Access Server, navigate to the following directory:

C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\OWA

Open the web.config file using Notepad and perform the following steps:

1. Search for OCS (IM) Server Name. You see the following three entries:

2. Populate the server name:

In the

3. Populate the Certificate Issuer:

In the

4. Populate the Certificate SerialNumber:

In the

Important: You must manually add spaces in the Serial Number string to separate each octet or the system cannot locate the certificate.

5. Save and close the Web.config file.

Step 4: Edit the OCS Integration

To enable the OWA Virtual Directory to use OCS IM integration, from Exchange PowerShell, type the following command:

Get-OwaVirtualDirectory -server SERVERNAMEHERE Set-OwaVirtualDirectory –InstantMessagingType 1

Step 5: Restart Internet Information Services

Although the preceding changes should be detected automatically, administrators might need to restart IIS on the Client Access Server. However, doing so can cause any current OWA sessions to be logged off, so care should be taken.

From the command prompt on the Client Access server, issue the IISRESET command to restart the services.

Configure the OCS Server

The Exchange Server 2010 OWA IM integration component is implemented as an OCS 2007 end-point. For the integration component to sign in to OCS 2007 R2, the OCS server must be configured to trust the Client Access Server.

This is accomplished by adding the Exchange Client Access Server as a trusted server on the OCS 2007 R2 front end. To do so, perform the following steps:

1. While logged in as an OCS administrator, start the OCS Management Console by selecting the following:

Start\All Programs\Administrative Tools\Office Communicator Server 2007 R2

2. Navigate to the OCS 2007 R2 Pool. Right-click the OCS Pool name and select Properties; then select Front End Properties

3. Click on the Host Authorization tab; then click the Add button.

4. In the Add Authorized host window

Select the FQDN radio button.

Type the name of the Client Access Server, basically what you type in to run OWA, such as owa.companyabc.com (note: you could use the IP address button instead of the FQDN button but this is less secure as it does not rely on certificate authentication, so use the name you use to access OWA externally as that’ll likely use https SSL security and will work)

Select (checkbox) the following options: Treat as Authenticated and Throttle as Server.

5. Click OK to save the configuration changes.

6. To allow changes to take effect immediately, stop and restart the OCS front-end services; note that doing so will disconnect any active users.

Note: If you install OCS 2007 R2 on Windows 2008 R2, you have to download a hotfix for UcmaRedist.msi; UcmaRedist.msp from the Microsoft Office Communications Server 2007 R2 Hotfix KB 968802. If you don’t, everything works except IM communication back to OWA, you would receive an Error id: 504. With UcmaRedist.msp installed, the issue is resolved. {this point added Dec 5, 2009 thanks to input from Jahad Suboh who commented on my blog to add this point of additional accuracy!}

Troubleshooting the Installation

Next are a few troubleshooting steps that can assist with some of the more common problems encountered with Exchange/OCS integration.

Configuring the Firewall on the CAS Server

If the Client Access Server has the Windows Firewall enabled, it might need an exception to enable OCS 2007 R2 to communicate with it. To create the exception, perform the following steps:

1. From the Control Panel, open Windows Firewall.

2. On the left side of the Windows Firewall window, click .“Allow a Program Through Windows Firewall.

3. Click Add Program; then click Browse.

4. Browse to C:\Windows\System32\inetsrv and select w3wp.exe.

5. Click Open and then click OK twice to apply changes and close the window. Be sure to perform this step on all CAS servers with IM integration enabled.

User Configuration

Before the user community can utilize the IM features, they must be “provisioned” for Office Communications Server R2 and must be enabled for Enhance Presence. When the user is initially enabled on OCS 2007 R2, he will automatically be enabled for Enhanced Presence.

Users must also have a valid SIP proxy address for the OWA IM integration component to enable the IM Integration UI.

Instant Messaging Not Available

When attempting to view the Instant Messaging contact list, a user might receive a notification that states:

Instant Messaging Isn’t Available Right Now. The Contact List Will Appear When the Service Becomes Available.

If this occurs, perform the following steps:

1. Using the same user account, confirm that you can access the IM services using the Office Communicator 2007 R2 client.

2. If functional, confirm that the OCS Server name is properly entered in the Web.Config file of the CAS server.

3. Also confirm the configuration of the Authorized Hosts option on the OCS pool contains all IM Integrated Client Access Servers.

OWA Certificate Error

If OWA cannot locate the certificate, an error stating The Local Certificate Specified Was Not Found in the Store for the Local Computer appears.

In this case, confirm that the value of the OCSCertificateIssuer and OCSCertificateSerialNumber fields in the Web.Config file are correct. Also ensure that there are blank spaces between every two characters in the serial number to separate octets in the string.

The preceding procedures were taken (AND Updated 12/3/2009) from my book “Exchange 2010 Unleashed” from Sams Publishing where I cover, in 1300-pages, everything on Exchange 2010 from architecture planning to migrations from Exchange 2003 and 2007 to securing Exchange 2010 to the latest in administration, management, high availability, and recoverability

My next post will be on the Exchange Control Panel component of Outlook Web App 2010 that provides administrators the ability to perform administrative tasks like adding users, disabling users, configuring public folders, etc right from the OWA 2010 screen.

It came as a surprise to many of us on the early adopter program with Microsoft when on one of the very last builds of Exchange 2010 all of a sudden Outlook Web Access was renamed Outlook Web App. Same OWA for web mail as we’ve used for years, but just a different name. Why the different name? Because Microsoft is branding all of their Web applications as Web Apps like the new Terminal Services Web Access is Remote Desktop Web App and the like. Made for a lot of fun when we had written the Outlook Web Access chapter for my Exchange 2010 Unleashed book and were about to send the book off to final print when we caught the name change. Meant we had to scour thorugh the chapters for all uses of the term “Outlook Web Access” and change the name AND we had to redo 40+ screenshots for the book, but we caught it in time.

What what’s new in Outlook Web App other than the name? The biggest thing is that OWA now supports more than just Internet Explorer for Windows. In fact, OWA in Exchange 2010 (which we frequently shorten to OWA/2010) supports Safari for the Apple Mac, FireFox for various operating systems (including Windows, Mac, and Linux), and Google Chrome! And not just that it supports these various browsers, but it supports thebrowers in full “Premium Mode”, not in the limited basic “Light mode”. So for non-Windows users, you are no longer 2nd class OWA citizens!

Some of the other things you’ll find in the new Outlook Web App 2010:

• Conversation View:  this is new to Outlook 2010 and Outlook Web App 2010 has the same look and feel, that basically email threads are grouped together by conversation so that all emails, replies, replies of replies are all clustered together in your view
• Mail Tips:  this is also new to Outlook 2010 and OWA 2010 where the client software tracks policies and if you try to send an email with an attachment greater than the supported attachment size, rather than attemping to send the attachment only to have it bounce back to you, Mail Tips pops up and tells you the attachment is too big and tells you what the policy is regarding the attachment size allowing you to fix the problem before it is a problem.  Similarly, Mail Tips will notify you when you “reply all” and potentially send a message back to everyone when you really didn’t intend to do so
• Integrated Instant Messaging:  For organizations that have Office Communications Server 2007 R2, you can configure OWA/2010 and OCS/2007 R2 to have the “presence” screen embedded right within OWA.

All other traditionally known features are included in OWA/2010 like email, calendar, contacts, configuration options, out of office rules, spell check, etc.

In my next blog entry, tomorrow, I’ll post how to configure Outlook Web App 2010 with OCS 2007 R2 for integration of presence and Instant Messaging in the single OWA/2010 screen.

And I’ll post a third entry later this week on the new “Exchange Control Panel” in OWA/2010, a really slick feature that allows administrators to do administrative tasks right within OWA.  So instead of having to find a workstation and “terminal server” into an Exchange server or AD Global Catalog server to do things like add a user, delegate rights, create a public folder, modify public folder rights, look at Exchange queues, etc, you can now just go to Outlook Web App 2010 and go into the “Exchange Control Panel” to perform administrative tasks.

For this blog post, I’m going to jump right into a topic of most interest to organizations deploying Exchange Server 2010, which is Disaster Recovery of databases. New to Exchange 2010 is the concept of the Database Availability Group, or DAG, which effectively allows an organization to have up to 16 replicated copies of an Exchange Database (EDB).

With Exchange 2003 and prior, there was only a single EDB that held a user’s mailbox. If the EDB got corrupt, was offline due to a server or disk failure, or offline because of a site failure, the user(s) could not access their mail, calendars, or contact type information. A whole industry arose around Exchange database recovery of a single database that included Storage Area Network (SAN) vendors doing snapshots of Exchange databases with Network Appliance (NetApp) having their SnapManager for Exchange (SME) that effectively allows their SANs to replicate Exchange databases for redundancy. Other solutions include software-based database replication from companies like DoubleTake. Or appliance-based Exchange availability solutions from companies like Teneros. All of these 3rd party products effectively replicated the Exchange database so that the organization could either quickly recover from a server or database failure, or have real time failover to a secondary copy of mail.

Then Exchange 2007 came out where Microsoft replicated the entire Exchange EDB database from a primary active server to a secondary passive server. This technology, called Cluster Continous Replication (CCR) provided an organization with a duplicate copy of the Exchange database on a secondary system with the failover from the primary to the secondary server that occurred in about 1-2 minutes. Nice about CCR is that it also provided failback from the secondary system back to the primary system also in a 1-2 minute timeframe. And with Exchange 2007 SP1 and the support for Windows Server 2008 failover clustering, an organization was able to failover and failback Exchange CCR between sites in different geographies.

As an organization, my company has helped hundreds of organizations (including some of the largest companies in the world) setup, test, and implement geo-cluster failovers of Exchange 2007 databases so that if a server in Site A fails, a server in Site B would come online and host the organization’s email automatically.

Microsoft also released Standby Continous Replication, or SCR with Exchange 2007 SP1 that provided a 3rd copy of the mail in yet another location so that effectively an organization would now have an active and passive copy of their mail, plus a replica of their mail in a 3rd location for purely DR reasons. CCR and SCR were revolutionary in terms of providing “out of the box” high availability and disaster recovery of Exchange databases and servers.

The major challenge with CCR and SCR is that the failover is done server to server, and primary to secondary in nature. So Site A / Server 1 fails to a backup server in Site B / Server 2, however if Site B wanted to have a local copy of their mail, they had to setup a completely separate server so Site B / Server 3 would failover to Site A / Server 4. This meant that an organization would have several servers running that were completely under-utilized as the passive nodes would only be online in the event of an Active node failure.

This is where Exchange 2010 Database Availability Groups come in. Database failover is now done at the database level, and each Exchange 2010 Enterprise license server can have 100 databases running on a system. So effectively Site A / Server 1 could have 10 databases of which 5 databases failover to Site A / Server 2, and 5 database failover to say Site B / Server 3. AND, since the failover is done database by database, the server in Site B / Server 3 can also host say 20 databases of which 10 of those databases failover to Site A / Server 2, and 10 databases failover to Site A / Server 1. In this fully meshed failover / failback environment and the support for up to 16 copies of a database across the enterprise, an organization could have full meshed high availability and disaster recovery of Exchange databases. The failover and failback of Exchange 2010 databases is between 30-60 seconds, and running on top of Exchange 2008 SP2 or higher, the organization can failover and back across a wide area network.

The basic process of creating a Database Availability Group is as follows:
Install Exchange 2010 on to a Windows 2008 SP2 or higher server with the Mailbox Server role.
1. Launch the Exchange Management Console.

2. Expand Organization Configuration.
3. Click Mailbox.
4. In the middle pane, click the Database Availability Group tab.

5. In the right pane, click New Database Availability Group
6. When prompted, enter a unique name for the Database Availability Group along with the file share witness path and directory which were created earlier. Click New.

. When the wizard has completed, click Finish.

At this point, the DAG has been created, however it has no members. Add member mailbox servers to the DAG with the following steps:
1. Launch the Exchange Management Console.
2. Expand Organization Configuration.
3. Click Mailbox.
4. In the middle pane, click the Database Availability Group tab.
5. Right click the DAG created in the previous steps and choose Manage Database Availability Group Membership.
6. When the wizard appears, click Add and choose the mailbox servers from the list that you want to join to the DAG. Click Manage.

7. The wizard might take several minutes to complete. When it had added all the necessary nodes, click Finish.
 
When this process has been completed on one or more nodes, the system(s) are ready for the rest of the configuration process to continue.
1. Return to Exchange Management Console and expand Organization Configuration.
2. Click Mailbox. In the middle pane, click the Database Management tab.

3. In the lower pane, right-click the database you wish to replicate within the DAG.
4. Choose Add Mailbox Database Copy.
5. When the wizard launches, browse for the server in the DAG to which you want to replicate the mailbox database. Pick a Replay lag time and a truncation lag time.

6. Enter a unique preferred list sequence number and click Add.
7. When the wizard completes, click Finish.
When the Database Availability Group is created, a computer object is created in Ac-tive Directory to represent the Failover cluster virtual network name account. If a DAG is going to be recreated with the same name, it is necessary to disable or delete this computer account or the process will error out and fail.

{note: the preceding content is excerpts from my book “Exchange Server 2010 Unleashed” from Sams Publishing (authors: Morimoto, Noel, et al) where I cover DAG specifics in more detail such as getting into the pre-requisites, debugging, creating failover sites, etc}

While the failover of the Mailbox Server role makes sesnse, the next question that is asked is “what about Client Access Server (CAS) failover and Hub Transport Server (HT) failover?”  The answer is quite simple, that CAS and HT servers by basic definition can be setup to failover across a LAN or WAN through simple Network Load Balancing (NLB).  As a new CAS or HT is added to a Site, the server(s) take on the failover and redundancy of other CAS and/or HT servers in the Site.  By default, the CAS server frontending Mailboxes for a user will allow client communications to pass through the CAS server into the Mailbox server.  In the event of a CAS server failure, NLB will fail the user’s connection over to another CAS server.

Over the past 2-yrs that we have been on the early adopter program for Exchange 2010, we tested the DAG failover and failback process including site to site failover.  This is a proven process that leverages the same failover cluster continuous replication technology that originally released with Exchange 2007 for server to server failure, but instead has expanded the same failover cluster continuous replication across multiple servers.

Some Best Practices we’ve come up with relative to using Database Availability Groups:

• Run an additional network adapter in the DAG member nodes to properly support Windows clustering.
• Ensure that hardware is chosen to not only support its dedicated load, but to take over additional loads when its acting as a replica for other master copies of a mailbox database.
• Base your disk subsystem primarily on storage, as the performance requirements have dropped drastically.
• Always plan for a sufficient amount of TCP/IP addresses in advance to support current and future cluster needs.
• Do not run both clustering and NLB on the same computer; it is unsupported by Microsoft because of potential hardware-sharing conflicts between MSCS and NLB.
• Always plan for the additional WAN traffic created by adding another DAG replica that isn’t on the local LAN.
• To avoid unwanted failover, power management should be disabled on each of the cluster nodes, both in the motherboard BIOS and in the power applet in Control Panel.
• Thoroughly test failover and failback mechanisms after the configuration is complete and before migrating users to a Database Availability Group.
• Make sure that mailbox databases have unique names.
• When utilizing load balancing, make sure to only load balances the ports necessary. This will avoid the possibility of network related issues when talking to Active Directory.
• Be sure to regularly monitor replicate between DAG nodes to ensure that rep-lication is healthy.
• Periodically test the move of master status between various copies of mailbox database groups to ensure that the data is valid and the cluster is working correctly.

I’ll post more on DAGs and Storage in general in upcoming postings as Database Availability Groups is one of the most innovative technologies coming out of Redmond in a very long time.  A technology that has helped organizations save hundreds of thousands of dollars on 3rd party high availability and disaster recovery products while providing better failover and failback capabilities straight out of the box.  Stay tuned for more on best practices around strategies to leverage DAGs and the use of cheap storage that drive down costs and increases recoverability.

Through the month of November (2009) I will be dedicating my blog on the topic of Microsoft Exchange Server 2010.

Join my blogs for the latest and greatest tips, tricks, best practices, and lessons learned on Exchange 2010!

In my last blog post I covered the migration process from Exchange 2003 to Exchange 2010. In this post, I’m going to outline the sequence and provide tips, tricks, and best practices to look forward to in the migration process from Exchange 2007 to Exchange 2010.

A lot of confusion exists about placing Microsoft Exchange servers in a network demilitarized zone (DMZ). Questions range from whether you should place Exchange servers in the DMZ to how you configure such servers. This week, I discuss the reasons you might locate Exchange servers in the DMZ and some protective measures you need to take if you do.

Planning the connection and deployment of Exchange services in the DMZ can seem daunting. A good place to start is your Exchange Server documentation. Also, read the following Microsoft articles for more details about configuring Exchange services with firewalls.