-Authored by Achinta Chatterjee (link to Linkedin Profile)

Introduction

The following are the key features and functionality that have been included in Exchange 2010 SP2.

1. Hybrid Deployment

2. GAL Segregation using Address Book Policies

3. Cross-Site Silent Redirection for Outlook Web App

4. Mini Version of Outlook Web App

5. Mailbox Replication Service Improvements

6. Disable Auto Mapping to Multiple Mailbox

7. Introduces new Multi-Valued Custom Attributes

8. Litigation Hold Mailbox improvements

Below are the details of each of these new features and how you can benefit from these features by implementing them in your organization.

1. Hybrid Deployment

A hybrid deployment offers organizations the ability to extend the feature-rich experience and administrative control they have with their existing on-premises Microsoft Exchange organization to the cloud. A hybrid deployment provides the seamless look and feel of a single Exchange organization between an on-premises organization and a cloud-based organization. In addition, a hybrid deployment can serve as an intermediate step to moving completely to a cloud-based Exchange organization.

A hybrid deployment enables the following features:

- Mail routing between on-premises and cloud-based organizations.

- Mail routing with a shared domain namespace. For example, both on-premises and cloud-based organizations use the @abc.com SMTP domain.

- A unified global address list, also called a “shared address book”.

- Free/busy and calendar sharing between on-premises and cloud-based organizations.

- Centralized control of mail flow. The on-premises organization can control mail flow for the on-premises and cloud-based organizations.

- A single Outlook Web App URL for both the on-premises and cloud-based organizations.

- The ability to move existing on-premises mailboxes to the cloud-based organization.

- Centralized mailbox management using the on-premises Exchange Management Console.

- Message tracking, MailTips, and multi-mailbox search between on-premises and cloud-based organizations.

Exchange 2010 SP2 introduces the Hybrid Configuration Wizard which provides with a streamlined process to configure a hybrid deployment between on-premises and Office 365 Exchange organizations. Hybrid deployments provide the seamless look and feel of a single Exchange organization and offer administrators the ability to extend the feature-rich experience and administrative control of an on-premises organization to the cloud.

2. GAL Segregation using Address Book Policies

This feature was already available in Exchange 2007 and is very useful for hosting companies. But with Exchange 2010 this feature was not available. Now with Exchange 2010 SP2 this very useful feature is available and will greatly benefit organizations. The benefit of this feature is that you can have a single GAL with multiple organizations inside and each organization will not be able to see the addresses of the other hosted on the same server.

Exchange 2010 SP2 introduces the address book policy object which can be assigned to a mailbox user. The ABP determines the global address list (GAL), offline address book (OAB), room list, and address lists that are visible to the mailbox user that is assigned the policy. Address book policies provide a simpler mechanism to accomplish GAL separation for the on- premises organization that needs to run disparate GALs.

Global address list (GAL) segmentation (also known as GAL segregation) is the process whereby administrators can segment users into specific groups to provide customized views of their organization’s GAL. In Exchange Server 2007 and earlier, segmenting the GAL was complicated, requiring you to use either a Query Base DN (which acted as a root for directory searches) or access control lists (ACLs) to allow or deny access to each address list.

To simplify the process, Exchange Server 2010 Service Pack 2 (SP2) introduces address book policies (ABPs). When creating an ABP, you assign a GAL, an offline address book (OAB), a room list, and one or more address lists to the policy. You can then assign the ABP to mailbox users, providing them with access to a customized GAL in Outlook and Outlook Web App. The goal is to provide a simpler mechanism to accomplish GAL segmentation for on-premises organizations that require multiple GALs.

3. Cross-Site Silent Redirection for Outlook Web App

In a Microsoft Exchange Server 2010 organization, a Client Access server can act as a proxy for other Client Access servers within the organization. This is useful when multiple Client Access servers are present in different Active Directory sites in an organization and at least one of those sites isn’t exposed to the Internet.

A Client Access server can also perform redirection for Microsoft Office Outlook Web App URLs and for Exchange ActiveSync devices. Redirection is useful when a user connects to a Client Access server that isn’t in their local Active Directory site or if a mailbox has moved between Active Directory sites. It’s also useful if the user should be using a better URL, for example, one that’s closer to the Active Directory site their mailbox resides in.

Although the Client Access server’s response can vary by protocol, when a Client Access server receives a request for a user whose mailbox is in an Active Directory site other than the one the Client Access server belongs to, it looks for the presence of an ExternalURL property on the relevant virtual directory on a Client Access server that’s in the same Active Directory site as the user’s mailbox. If the ExternalURL property exists, and the client type supports redirection (for example, Outlook Web App or Exchange ActiveSync), the Client Access server will issue a redirect to that client. If there’s no ExternalURL property present, or if the client type doesn’t support redirection (for example, POP3 or IMAP4), the Client Access server will try to proxy the connection to the target Active Directory site.

With Exchange 2010 SP2, you can enable a silent redirection when a Client Access server receives a client request that is better serviced by a Client Access server located in another Active Directory site. This silent redirection can also provide a single sign-on experience when forms-based authentication is enabled on each Client Access server.

4. Mini Version of Outlook Web App

The mini version of Outlook Web App is a lightweight browser-based client, similar to the Outlook Mobile Access client in Exchange 2003. It provides access from simple HTML-compatible browsers that support cookies and it’s designed to be used on a mobile operating system.

The mini version of Outlook Web App provides users with the following basic functionality:

- Access to e-mail, calendar, contacts, tasks and the global address list.

- Access to e-mail subfolders.

- Compose, reply to, and forward e-mail messages.

- Create and edit calendar, contact, and task items.

- Handle meeting requests.

- Set the time zone and automatic reply messages.

The mini version of Outlook Web App is based on Outlook Web App architecture. Because it’s an application within Outlook Web App, it uses all the segmentation flags that exist in Outlook Web App.

In order to be compatible with the widest array of mobile phone browsers, the mini version of Outlook Web App is designed to use Basic authentication. Basic authentication allows the credentials to be exchanged within the header of the HTTP request. The request should always be sent using a secure socket layer (SSL) encrypted channel. Different browsers handle passing credential information differently. Some request that the user type the information for each new session. Others only request the information if it has changed.

5. Mailbox Replication Service Improvements

The Mailbox Replication Proxy (MRSProxy) service is installed on every Exchange 2010 Client Access server. MRSProxy helps to facilitate cross-forest move requests and runs on the remote forest’s Exchange 2010 Client Access server. However, by default, MRSProxy is disabled.

In Exchange 2010 SP1, if you wanted to move mailboxes from on-premises to xxx.com or to another forest, you had to enable MRSProxy on the remote Client Access server. To do this, you had to manually configure the web.config file on every Client Access server. In Exchange 2010 SP2, two parameters have been added to the New-WebServicesVirtualDirectory and Set-WebServicesVirtualDirectory cmdlets so that you don’t have to perform the manual configuration: MRSProxyEnabled and MaxMRSProxyConnections

6. Disable Auto Mapping to Multiple Mailbox

In Exchange 2010 Service Pack 1 (SP1) Exchange introduced a feature that allows Outlook 2007 and Outlook 2010 clients to automatically map to any mailbox to which a user has Full Access permissions. If a user is granted Full Access permissions to another user’s mailbox or to a shared mailbox, Outlook automatically loads all mailboxes to which the user has full access.

To accomplish this, Exchange populates the msExchDelegateListLink attribute in Active Directory to locate mailboxes for which the user has Full Access permission, and then provides this information to the Autodiscover service. Autodiscover then populates the AlternateMailbox attribute with the information necessary for Outlook to open the full access mailboxes. If the user has Full Access permissions to several mailboxes, performance issues may occur when starting Outlook. In Exchange 2010 SP1, there was no way to turn this feature off. However, in Exchange 2010 SP2, you can use the Shell to disable this feature.

Below is an example grants the user Raymond Lim full access permission to Mark Tan’s mailbox and disables the auto-mapping feature.

Add-MailboxPermission -Identity MTan -User ‘Raymond Lim’ -AccessRight FullAccess -InheritanceType All -Automapping $false

7. Introduces new Multi-Valued Custom Attributes

Exchange 2010 SP2 introduces 5 new multi-value custom attributes that the administrator can use to store additional information for mail recipient objects. The ExtensionCustomAttribute1 to ExtensionCustomAttribute5 parameters can each hold up to 1300 values. The administrator can now specify multiple values as a comma-delimited list. The following cmdlets support these new parameters:

i. Set-DistributionGroup

ii. Set-DynamicDistributionGroup

iii. Set-Mailbox

iv. Set-MailContact

v. Set-MailPublicFolder

vi. Set-RemoteMailbox

8. Litigation Hold Mailbox improvements

In Exchange 2010 SP2, the administrator can’t disable or remove a mailbox that has been placed on litigation hold. To bypass this restriction, you must either remove litigation hold from the mailbox, or use the new IgnoreLegalHold switch parameter when removing or disabling the mailbox. The IgnoreLegalHold parameter has been added to the following cmdlets:

i. Disable-Mailbox

ii. Remove-Mailbox

iii. Disable-RemoteMailbox

iv. Remove-RemoteMailbox

v. Disable-MailUser

vi. Remove-MailUser

Conclusion

The above document provides the key new features that have been introduced in Exchange 2010 SP2. In addition to the features described in this topic, Exchange 2010 SP2 also includes fixes that address issues identified since the release of Exchange 2010 SP1 and that has been cumulatively fixed from Update Rollup 1 to 6.

Note: If you are looking for detailed instructions to upgrade to Outlook 2010 see;
Upgrading to Outlook 2010

Benefits of using the 64-bit edition of Outlook 2010

Using the 64-bit version of Outlook does not have any direct benefits. The functionality within Outlook is the same and there is also no (noticeable) performance increase by using the 64-bit edition.

Installing the 64-bit version only really makes sense when you also need the 64-bit version of Excel for large file support (>2GB) and/or several complex calculations.

If you do not use these 64-bit specific features, Microsoft recommends that you use the 32-bit version instead. Unless you specifically choose otherwise, the installer will automatically install the 32-bit version of Outlook even when your system supports the 64-bit edition (further details are discussed later in this article).

Downsides of using the 64-bit edition of Outlook 2010

If you choose for the 64-bit version, you’ll have to be aware of the following downsides;

• All add-ins that you want to use have to be recompiled as 64-bit add-ins by the vendor of these add-ins. You can contact the vendor of the add-in to verify if they supply 64-bit versions of their add-ins and if you are eligible for a free upgrade.
• Many sync applications for mobile phones and other mobile devices will not recognize the Outlook installation. These sync applications will require an update as well. Microsoft has announced that Windows Mobile Device Manager (WMDC) will not be updated for Outlook 64-bit compatibility. When you try to sync with Outlook 2010 64-bit, you’ll receive the following error;
  “Either there is no default mail client or the current mail client cannot fulfill the messaging request”
• Messaging Application Programming Interface (MAPI) calls can only be made at the 64-bit level. If you have an application which integrates with Outlook at MAPI level, this integration is lost when this is a 32-bit application. A common example is the integration with Microsoft Office Communicator as this is currently only available as a 32-bit application.
• Custom solutions which make use of existing ActiveX controls will not work and will require an update or rewriting.
• Existing Custom VBA solutions may not work when they contain the Declare statement and will require rewriting.

Installing the 64-bit edition of Outlook 2010

In order to install the 64-bit version of Outlook 2010, you must make sure that no previous version of Office still is installed on your computer and also that there are no 32-bit applications of Office 2010 still installed. If any such application is still installed, you will not be able to install the 64-bit version of Outlook.

When you start Setup from an installation medium that has both the 32-bit and the 64-bit version on it, you’ll be installing the 32-bit version of Outlook by default. When you press the Customize button in Setup, you’ll see the Platform tab if your system can support a 64-bit installation of Outlook 2010.

If it does and you want to start installing it, close the current Setup window and browse to the installation source (for instance on the CD or DVD-drive). Here you’ll find a folder called x64. Open it and run the setup.exe file located in this folder. The setup process is further the same as for the 32-bit version of Outlook.

Installation Information about the availability of the 64-bit version of Office 2010.
(click on image to enlarge)

-Authored by Achinta Chatterjee (link to Linkedin Profile)

Introduction

In this document we will go through the steps to execute a DR drill and an actual DR scenario. We have already detailed in the Part1 and 2 on Client connectivity and Mail Routing for Primary and DR site.

DR Drill

The DR Drill exercise can be divided into three sections:-

i. Preparation Steps for DR Drill

ii. DR Drill Execution Steps

iii. DR Drill Testing

i. Preparation Steps for DR Drill

1. Create a Mailbox database for DR drill purposes.

Once this database is created make it a part of DAG.

Make sure the RPCclientaccessserver for this database is the DR CAS Server. For eg, you can use the following command to set the RPCClientAccessServer for DRDB01 database to the DR CAS HUB Server.

Set-MailboxDatabase -identity DRDB01 – RpcClientAccessServer temexgcasr01.thdm.local

Temexgcar01.thdm.local is the DR CAS HUB Server.

2. Activate the database DRDB01 to DR site Mailbox server and swing it back to the Primary site. This is to test whether the database swing is working fine between the 2 sites.

3. Identify those production users who will participate on the DR drill

4. List domain names the DR drill users will be sending emails to the Internet.

We need to find this as we need the drill users to send emails to the Internet from the databases hosted on the DR servers and through the DR Internet Mail relays. As this is a separate exercise to test DR readiness we won’t affect the production users send and receiving emails.

In our DR drill we will use gmx.com as the domain name to which DR drill users will send outgoing emails. To accomplish we will need to create a Send connector entry on the Send Connector “DR SMTP Outgoing” in Part 2 of this article. Click Add in the Address Space tab and put the address gmx.com with a Cost of 1. Note the purpose of the “Cost” field here. We already have another send connector with * with a cost of 1 for the Primary Site. All Outgoing Internet emails go through that connector. But when you specify a domain name (for eg xxx.com) it takes priority over * and hence any emails for gmx.com will route through the DR site Internet Mail relays.

ii. DR Drill Execution Steps

1. Notify DR Drill users to exit their Outlook Clients and not to access emails.

2. Move all DR Drill participating users (identified in step 3) mailboxes from their Primary databases to the DR database DRDB01.

3. Activate the database created for DR drill purposes DRDB01 to be mounted on the DR Mailbox server.

4. All DR drill user mailboxes will failover to the DR site.

5. Notify the DR drill users to open their Outlook clients. The Outlook client when opens for the first time after the database has been moved to the DR site will take a few more seconds. The reason being now the Outlook client configuration will be pointing to the DR CAS Server (temexgcasr01.thdm.local) and Outlook anywhere URL will be dr.myemail.com.sg. Figures are show below.

iii. DR Drill Testing

Once the users have connected to the DR site they need to test the following items.

1. Outlook Connectivity – as shown in the previous section.

2. From Outlook client test sending and receiving emails between DR drill participating Exchange users.

3. Send Outgoing emails from Outlook client to gmx.com. The administrators need to check from the server logs whether these emails are routing through the DR Internet Mail Relay servers and confirm.

4. Reply emails from gmx.com to see whether they are being received back to the sender. Note this routing will be through the Primary site.

5. Administrators need to inject emails manually from the DR Incoming Internet Mail Relay servers to the DR drill users. This is done as the actual MX is still pointing to the Primary site. Confirm that these emails are received by the DR Drill users. This will confirm that the Incoming internet emails are being delivered properly from the DR Incoming Internet Mail Relay servers, and should be functioning during the actual DR.

6. Open DR Site OWA URL http://dr.myemail.com.sgand confirm the user can login and open mailbox.

7. Test step 2,3,4,5 again from OWA just to reconfirm your testing.

Disaster Recovery (actual scenario)

During actual DR we need to execute the following steps.

1. Outlook and OWA client connectivity will be lost all users. Ask all user s to exit their Outlook and OWA clients

2. When the Primary site is down all Mailbox databases will auto-failover to the DR mailbox server. The reason being the Activation preference on these databases is set to the DR mailbox server as the last resort. Confirm that all databases have been mounted on the DR mailbox server.

3. Take the list of all mailbox databases you are hosting and run the command below from the EMS for each database on the DR mailbox server. Replace the “databasename” with appropriate databases.

Set-MailboxDatabase -identity “databasename” – RpcClientAccessServer temexgcasr01.thdm.local

4. Once the above is completed open EMC and browse to Organization Configuration >Hub Transport> Send Connectors . Open the Send Connector already created “DR SMTP Outgoing” Properties. Change the Cost of the connector from 100 to 1.

5. Once the above is completed open EMC and browse to Organization Configuration >Hub Transport> Send Connectors. Open the Send Connector for Primary Site Mail routing “Outgoing” Properties. Change the Cost of the connector from 1 to 100. The above 2 steps will make sure that the Outgoing Internet emails will be routed through the DR Internet Mail Relay hosts.

6. Once the Primary Site is down the MX preference for the hosted domain names will make sure that incoming Internet emails get routed automatically to the DR Incoming Internet Mail server. As shown in the figure below postmantp1b is the DR Incoming Internet Mail server with the highest MX preference of 40.

7. All emails will start queuing on the DR Incoming Internet Mail server. Once the Exchange DR CAS HUB server is available the emails will get routed out to these servers and eventually to the respective user mailboxes hosted at the DR mailbox servers. To ensure all mails is getting routing properly check the incoming logs of the DR Incoming Internet Mail server and the Queue viewer on the DR Exchange CAS HUB servers, as shown below.

8. Once the above has been accomplised the administrators should do a few rounds of DR testing. Verfiy Outlook client connectivity by opening some Outlook clients and sending and receiving emails between themselves and the internet. Verfiy OWA URL dr.myemail.com.sg is accessible and can open mailbox databases.

9. Once all tetsing is confirmed notify the users to open their Outlook Clients or OWA (using the DR URL dr.myemai.com.sg). Business should be back to normal as far as end users are concerned.

Conclusion

This marks the end of the 3 part article on Deploying Disaster Recovery for Exchange 2010. We have tried to detail Exchange 2010 DR configurations, Client Connectivity, Mail Routing, DR Drill and Actual DR. You can customize you DR Startegy w.r.t your own environment with the above recommendations.

Here’s how to install Google’s Android OS on your iPhone. Be forewarned, though: This hack isn’t for the faint of heart.

By David Wang, PCWorld

May 20, 2010 8:00 am

Aside from using the Run command, there are also other ways to start Outlook in Safe Mode

Hold CTRL

When you hold he CTRL button on your keyboard when clicking the Outlook shortcut on your Desktop, Quick Launch toolbar or Start Menu, Outlook will detect this and asks you if you want to start Outlook in Safe Mode.

Windows Vista and Windows 7

If you are using Windows Vista or Windows 7, then there is a Search box in the Start Menu. Here type; outlook.exe /safe

Starting Outlook in Safe Mode via the Start Menu in Windows 7.

Create a shortcut

You can also create a new shortcut to outlook.exe and add the /safe switch;

First, determine the location of outlook.exe on your system. In general you’ll find it under;

• 32-bit version of Windows
  C:\Program Files\Microsoft Office\Office <version number>
• 64-bit version of Windows
  C:\Program Files (x86)\Microsoft Office\Office <version number>

If you can’t find it, do a search for outlook.exe or use OutlookTools (free) instead.

Once you’ve found outlook.exe we create a shortcut to it with the /safe switch to prevent Outlook from opening an extra window each time you click the shortcut or use your keyboard shortcut.

1. Right click on an empty space on your Desktop and choose New-> Shortcut
2. Type the path to outlook.exe between quotes or browse to its location via the Browse… button
3. Type a space behind that and /safe
4. The entire line should now look like this (example is for Outlook 2007 on a 32-bit Windows);
   "C:\Program Files\Microsoft Office\Office12\OUTLOOK.EXE" /safe
5. Click Next
6. Name your shortcut for instance: Outlook Safe Mode
7. Click Finish

-Authored by Achinta Chatterjee (link to Linkedin Profile)

Introduction

This document is a continuation of the previous article for setting up DR for Exchange 2010. In the previous article we detailed how Client Connections to the Exchange server works both on Primary and DR site. In this article we will begin with the mail routing planning and considerations we need to do for Exchange 2010 for our Disaster Recovery setup.

Disaster Recovery Planning & Considerations

i. Mail Routing

To setup Mail Routing you need to consider the following components:-

a. Exchange Internal Email Routing

b. Primary and DR Site Incoming and Outgoing email Routing

c. Internet Email Routing

a. Exchange Internal Email Routing

For mail routing between Exchange users , nothing has to be separately configured. Even if your users are in Primary and DR site they will be able to send /receive emails among themselves as the RPCClientAccessserver determines what is their Array and then routes the email to the respective databases.

b. Primary and DR Site Incoming and Outgoing email Routing

What we will consider here is Sending and Receiving of external SMTP Internet email routing. Four sections will be discussed here. Primary and DR Site Incoming and Outgoing emails.

Primary Site Incoming Emails

For external emails to be accepted by Exchange servers we need to create Accepted Domains and Receive Connectors.

Accepted Domains. They can be created in EMC under Organization Configuration> Hub Transport

Accepted domains need to be created to tell Exchange the email domains it hosts. Typically thee domain names would be the email address you give to your company for eg. Mycompanyname.com

Receive connectors. They need to be created to tell Exchange from which servers Exchange can receive emails and with what kind of authentication. They can be created in EMC under Server Configuration > Hub Transport. The figure below shows the receive connector that tells exchange from the server under “Receive mail from remote servers that have these IP addresses”. Typically these servers will be your Incoming Internet Mail Relay Servers, that receive Internet Emails. Note they are created under the primary site CAS servers (CAS1/CAS2).

Primary Site Outgoing Emails

Send Connector. For Primary Site Outgoing emails we need to create a Send Connector. In EMC go to Organization Configuration > Hub Transport> Send Connector.

We create a single Send Connector give it an address “*” so that it can send all Outgoing emails from through this connector.

Note we should give this Send Connector a cost of 1.

The Network tab contains the Primary Outgoing Internet Mail Relay Servers under Route Mail through the following Smart host.

The Source Servers contains the CAS/HUB server for which the Send Connector is created. This means emails generating from these servers (which contain the primary CAS server array too) will be directed through this Send Connector.

DR Site Incoming Emails

For external emails to be accepted by DR Exchange servers we need Accepted Domains and Receive Connectors in the DR site as well.

But Accepted Domains don’t need to be created a second time for DR as they are not server specific. They are all kept under the Active Directory configuration and are valid for both Primary and DRsite.

However we need to create Receive Connector for the DR site. This because we have a separate set of Incoming SMTP Internet Relay servers.

However take note we need to create the Receive Connectors under the DR CAS server as shown below.

The field “Receive mail from remote servers that have these IP addresses” should be the of Incoming SMTP Internet Relay servers.

DR Site Outgoing Emails

Send Connector. For DR Site Outgoing emails we need to create a Send Connector. Although this connector is created now, this will be not be used and will be kept as a preparation for DR.

In EMC go to Organization Configuration > Hub Transport> Send Connector.

We will create a single Send Connector give it an address “*” so that it can send all Outgoing emails from through this connector. However we should give this Send Connector a cost more than 1 say 100, as shown below.

The reason why this is done is because we don’t want all emails to go through the DR site during normal conditions. This Send connector will be activated during actual DR.

The Network tab of the Send Connector contains the DR Outgoing Internet Mail Relay Servers under Route Mail through the following Smart host.

The Source Servers contains the CAS/HUB server for which the Send Connector is created. This means emails generating from these servers (which contain the DR CAS server) will be directed through this Send Connector.

c. Internet Email Routing

Now that we have completed with Mail Routing configuration on Exchange Servers, we will briefly go through how the Internet Mail routing should be setup in accordance with DR strategy.

If you are hosting emails for a domain for you must have a MX record in the internet DNS that is pointing to you Incoming Internet SMTP Mail Relay Server.

Generally organizations will have 2 or more Incoming SMTP servers due to redundancy. The way to set this is to configure the MX records to have Priority. So if you have 4 Incoming mail servers 2 in Primary site and 2 in DR site you give higher priority to your servers on the Primary site and lower to the one’s on your DR site. The Priority is also known in DNS terms as Preference. As you can see in the figure below the MX Preference for the DR SMTP server is the least.

This configuration actually makes the DR Strategy for Internet Mail Routing. When your Primary site is down due to a calamity emails automatically starts to route to the lower preference Intenet SMTP Mail Relay servers ie. the DR Servers. This configuration makes it a robust site resilient strategy for any email loss due to a calamity.

This is actually a good question as the option is indeed no longer there and CTRL+P won’t trigger a print job either.

The way to print a Note in Outlook 2010 is to select it directly from the list in the Notes folder and then open “Backspace” by pressing the File tab and choosing Print.

This way of printing also allows you to print multiple notes on a single sheet of paper.

Personally, I’ve enabled the Reading Pane in the Notes folder as well (View-> Reading Pane) and have sorted my Notes as list. This allows me to quickly read them, copy text from them or print them without the need to open it first.

Goodbye Print… you’ve got to go…

Interface changes; No Ribbon, no Printing

If you wonder why this option was removed; interface changes.

As you might have noticed, printing and setting most of the printing options is now done directly from the File screen/tab (also know as Backspace). There is no separate printing dialog anymore which pops up.

As a Note window doesn’t have a Ribbon interface with a File tab and is often quite small, there is no room to show the new Printing screen. As maintaining the old printing dialog in the new version of Office/Outlook wasn’t an option either, the menu option had to go as well.

-Authored by Achinta Chatterjee (link to Linkedin Profile)

Introduction

The document will go through how you can setup Exchange 2010 Disaster Recovery in your organization. Most organizations already have High Availability setup for Exchange 2010 as they most likely will be using DAG. But you need to have a separate plan for Disaster Recovery for your organization.

Usually organizations will require not only a fully functional DR setup but also a DR drill just to prove to the organization that if disaster strikes what the organization needs to plan for and execute at that moment. This document will go through both the scenarios what the administrators will need to plan for and implement to make their infrastructure DR ready.

Disaster recovery architecture in Exchange

Overview of the Exchange architecture for Primary and DR Site

Primary Site:

The above figure is the entire architecture of Exchange in Primary and DR site. In the Primary site we have 2 Client Access Servers (CAS) and Hub Servers, 2 Mailbox servers (MBX) and 2 Threat Management Gateway (TMG) Servers. The Threat Management Gateway servers are in the DMZ.

The CASHUB servers are configured in a CAS Array, and the array name is temcaarray01.thdm.local

There are 2 Mailbox servers and they are in DAG configuration.

The TMG servers act as firewall allows HTTPS (443) traffic from the Internet to the CAS servers. The OWA URL https://myemail.com.sg is published through the TMG servers to the internet. Others services like Active Sync, also use the TMG to authenticate Exchange traffic to the CAS servers.

You can also see an External Internal SMTP Mail Relay Gateway. This is generally a unix box that faces the Internet to route Incoming and Outgoing SMTP email traffic from Exchange.

DR Site:

In the DR Site you have a single Mailbox Server, CAS HUB server, TMG server and Internet Mail Relay Server.

The third mailbox server MBX3 is configured in the same DAG as the Primary site. This ensures that all data is replicated across the 3 DAG members.

The CASHUB3 server in the DR is not in the same array as the Primary site. Take note this is done on purpose. DR Clients connect to the DR CAS server directly

The TMG server in the DR Site routes HTTPS (443) traffic for the domain registered for DR https://dr.myemail.com.sg . This is the DR OWA URL.

The DR External Internal SMTP Mail Relay Gateway is generally unix box that faces the Internet to route Incoming and Outgoing SMTP email traffic from Exchange in the DR site.

Disaster Recovery Planning & Considerations

When you are implementing a Disaster Recovery for your Exchange you need to consider two important factors:-

i. Client Connections to the Exchange Server

ii. Mail Routing

i. Client Connections to Exchange server

Before we go deep dive into how the Outlook client will connect to the Exchange server when a disaster happens we need to first understand how the client connects to the Exchange server in the Primary Site.

Outlook Client Connections to Primary Site

When a Mailbox Database is created on the Exchange 2010 server a field is automatically created in the database called RPCClientAccessServer. This field actually determines how a client connection request connects to a particular mailbox hosted on a particular mailbox database. Figure below shows the properties of a production database showing what the RPCClientAccessServer reflects.

Command: Get-MailboxDatabase -identity DB01| fl

From Outlook 2007/2010 the client uses a service called Autodiscovery to locate its Exchange server. When a client connects to a Exchange 2010 server the autodiscovery service connects to the CAS Array name (in the above eg it is temcaarray01.thdm.local). This array then uses the RPCClientAccessService running on the CAS server to connect to the actual active database hosted on a Mailbox server.

Above you can see from the Outlook client configuration that it connects to the Microsoft Exchange Server as the array name Temcaarray01.thdm.local.

As the user Achinta’s database is on a Mailbox database whose RPC clientaccess server is Temcaarray01.thdm.local the Outlook client automatically connects to the Database hosted on the Primary site Mailbox servers.

Also note under connection settings in Outlook client the Outlook Anywhere URL is pointed to the OWA URL : https://myemail.com.sg

Outlook Client Connections to DR Site

Now with the above knowledge let’s discuss how the Outlook client would connect to the DR site.

Again the RPCClientAccessserver plays a part to determine how to the Outlook client will connect to the DR site. When you want the Outlook client to connect to the DR site you need to ensure that the user’s database is hosted on a database whose RPCClientAccessserver is the CAS server on the DR site.

For DR purposes when the actual disaster occurs you need to manually run the command below to make the RPCClientAccessserver for the database as the CAS server name in Dr ie.temexgcasr01.thdm.local .

Set-MailboxDatabase -identity DB01 – RpcClientAccessServer temexgcasr01.thdm.local

Once the above command is executed we will have the below for the database that is now hosted on the DR Mailbox server

This makes database to listen RPCClientAccess service connections to the name temexgcasr01.thdm.local.

When the same Outlook2007/2010 client now connects for the user’s email , the autodiscovery service will automatically point to the DR CAS Array as the user’s database is hosted in the DR site.

From Outlook client what we see is the below. Note the new CAS array name and the URL pointing to the DR site.

OWA connections to Primary Site

The OWA connection is directly to the URL https://myemail.com.sg. When a user logs with this URL which is pointing to the primary site the TMG redirects the traffic to the primary CAS Array temcaarray01.thdm.local., which in turn directs to the Primary site mailbox database for the user. The same concept of RPCclientaccessserver works here as mentioned in the context of Outlook Clients.

OWA connections to DR Site

For DR the user keys in a separate URL https://dr.myemail.com.sg. The external DNS redirects the URL to the DR site and the DR TMG redirects the traffic to the DR CAS Server. Now only if your database is pointing to a DR hosted database whose RPCclientaccessserver is pointing to the DR CAS Server, you will be able to open your emails in OWA.

Conclusion

This completes the Client connections portion of the DR site Planning and Considerations and the end of Part1. In the next part look for how Mail Routing is setup for DR and what are the steps necessary to activate DR and the DR drill.

Will existing users pay the price for these devices to get the upgrade version with Camera? Why would you want a camera powered iPod in the first place when you are already carrying a phone with a camera (in most cases it’s true).

On the other side, you cannot label iPod as “just another MP3 player”, because most of us who owns iPod also use it to download applications, watching movies when you feel bored of listening to the music. I personally love the collections of applications in the App Store and its user experiences.

What people may worry is the size. Will it be thicker due to the camera integration? According to TechCrunch’s quote from a source in Asia “Apple has placed an order for a massive number of camera modules of the type that they include in the iPhone. These are inexpensive cameras, in the $10 range. And the size of the order, our source says, means they can only be used for one thing – the iPods.”