Office 365 "W15" Hybrid Deployment (Part VI) – Configuring a Microsoft Exchange Online Hybrid Deployment

Posted on June 20, 2014 by catastrophicerrors

After having in Part 5 configure part of Microsoft Exchange Server, in Part 6 and final part we will continue with Exchange Server configuration based migrations to Office 365 or more precisely Exchange Online, we ran the Exchange 2010 SP3 hybrid configuration wizard in order to set up the basic Exchange hybrid configuration.

Let’s go.…

Look at Current Hybrid Configuration

Let’s take a look at the stuff that was created behind the scene, when we ran the Hybrid Configuration Wizard (HCW).
Let’s first look at the hybrid configuration object itself. We can do so by launching the Exchange Management Shell (EMS), and run the following command: Get-HybridConfiguration

As you can see above, the settings (such as hybrid Client Access and Hub transport server, on premise smart host and federation domains) you specified when we ran the wizard have been set on the hybrid configuration object. But, this is not the only thing that have been configured. You can also see which features have been enabled (FreeBusy, MoveMailbox, MailTips, MessageTracking, OwaRedirection, OnlineArchive, SecureMail and CentralizedTransport), which are features we wish to enable between the on premise Exchange organization and the Exchange Online organization in Office 365.
In addition, the following has also been performed in the on premise Exchange organization:
A federation trust with the Microsoft Federation Gateway (MFG) has been established for the specified domain:

Creating a federation trust with the MFG is required in order to be able to set up an organizational relationship, which again is required in order to share free/busy information and calendars between the on premise Exchange organization and the Exchange Online organization in Office 365. With this said, it’s important to note that a trust isn’t set up with the MFG, instead the MFG merely acts as a trust broker between the involved Exchange organizations.

“tenant_name.mail.onmicrosoft.com” has been added as an accepted domain:

Adding the “tenant_name.mail.onmicrosoft.com” domain to the “Accepted Domains” list as an authoritative domain is required in order for the on premise Exchange organization to accept inbound e-mail messages destined for a mailbox user located in Exchange Online. When a mailbox is moved from the on premise Exchange organization to Exchange Online, the source mailbox user object is converted to a mail user object, which is configured with an external address of “alias@office365labdk.onmicrosoft.com“. We will look more at this later in this article series.

“tenant_name.mail.onmicrosoft.com” and “onprem.local” has been added as a remote domain:

A remote domain is an SMTP domain that is external to our Exchange organization. When a new remote domain is created, it’s possible to specify the remote domain is used for Exchange Online purposes. With a remote domain, we can configure out of office and message formatting settings. The HCW sets the ideal setting for a hybrid and enables the SMTP domain as the domain used for an Office 365 tenant, which is important in relation to provisioning of new remote mailbox users (users that get a mailbox created directly in Exchange Online).
The default E-Mail Address policy has been updated, so that it stamps a secondary proxy address (alias@tenant_name.mail.onmicrosoft.com) on mailbox user objects:

The SMTP address “alias@lacosanostra365.mail.onmicrosoft.com“ is added to the default E-mail address policy, so that it can be stamped as an additional proxy address on the mail objects in the organization. As mentioned earlier, when a mailbox is moved to Exchange Online, the source mailbox user object is converted to a mail user object and in order to be able to set “alias@office365labdk.mail.onmicrosoft.com“ as the external e-mail address, it must already be stamped on the object. The HCW also creates a receive connector on each of the hybrid servers. The purpose of this receive connector is to accept inbound mail that comes directly from Exchange Online in Office 365. The receive connector accepts anonymous connections secured using TLS, but only from the IP range used by Office 365.
In addition, the HCW will create a send connector that will route all e-mail messages destined for “tenant_name.mail.onmicrosoft.com” to Exchange Online in Office 365.

And finally, an organizational relationship has been established with the Exchange Online organization in Office 365:

The organization relationship is used to configure what kind of features should be enabled between the on premise Exchange organization and Exchange Online and for availability sharing at what level.
Let’s take a closer look at the organization relationship that has been created. We can do this by running the following command in the Exchange Management Shell (EMS): Get-OrganizationRelationship | fl
By default, free/busy is enabled with limited details. In addition, mailbox moves, delivery reports, MailTips and online archive are enabled. Moreover, a target OWA URL is specified and by default, it will be set to: “http://outlook.com/owa/tenant_name.onmicrosoft.com”. The target OWA URL is the URL that a user will be non-transparently redirected to (we will look at this later in this article series), when he tries to access his mailbox using the existing OWA namespace (i.e. http://mail.domain.com/owa) after his mailbox has been moved to Exchange Online. Lastly, a target autodisocver has been set by the HCW.
This is the endpoint used to reach out to the Exchange Online organization for the configured features, when a request comes from the on premise Exchange organization to the Exchange Online organization.
In Office 365, the following was configured, when we ran the HCW
Just like for the on premise Exchange organization, the domains used for routing between on premise and Exchange Online has been added as “Accepted Domains” in the Exchange Online organization.

Likewise, for remote domains, these have been configured in Exchange Online. An organization relationship has been configured in Exchange Online, so the sharing requests etc. from an Exchange Online mailbox user to an on premise mailbox user is sent to the on premise Exchange organization.

Just like is the case with the on premise Exchange organization, we can get additional information about the configuration of the organization relationship by running the following command: Get-OrganizationRelationship | fl

Update Hybrid Configuration

If you at some point wish to update the hybrid configuration in your environment, you can do so via the HCW or EMS.
If you want to use the HCW, you simply click on the hybrid configuration object in the EMC, and select “Manage Hybrid Configuration” in the context menu.

If you want to use EMS, you first set the required configuration using the Set-HybridConfiguration cmdlet and then you run the Update-HybridConfiguration cmdlet to push the new configuration to Office 365.
Read more about the Set-HybridConfiguration cmdlet here and the Update-HybridConfiguration cmdlet here.

That is we will move an on premise Exchange mailbox to Exchange Online and then we will test the browser and client behavior and see what to expect when a mailbox has been moved from on premise Exchange to Exchange Online. Moreover, we will be provisioning a new mailbox in Exchange Online using the “New Remote Mailbox” wizard and the “New-RemoteMailbox” cmdlet.
Lastly, I explain what to consider when it comes to decommissioning your Exchange on premise servers or just the legacy Exchange servers within your on premise environment.

Moving a Mailbox

Now that we have configured a hybrid deployment, let’s test things out to ensure they work as expected. First, we will move an on premise mailbox to Exchange Online using the “New Remote Move Request” wizard. This can be done by right-clicking on an on premise mailbox and selecting “New Remote Move Request” in the context menu as shown in

On the “Introduction” page, click “Next”.

On the “Connection Configurations” page, make sure “Target forest” is set to “the name you gave the additional Exchange forest”, then enter the FQDN for the Exchange hybrid server that has the Client Access server role installed. Also, enter the credentials for an on premise administrator and click “Next”.

On the “Move Settings” page, click “Browse” and then select the target delivery domain (in this case “office365labdk.mail.onmicrosoft.com”). Since, we’re moving a mailbox to Exchange Online, we cannot select the target database (it will be picked randomly). Click “Next”

On the “Configuration Summary” page, click “New” in order to create the remote move request in Exchange Online.

On the “Completion” page, click “Finish”

Let’s go and see how to migrate mailbox data by using the Exchange Admin Center in Office 365

1. Sign in to the Office 365 portal (https://portal.microsoftonline.com).

2. Click Admin, and then click Exchange.

3. Click Migration, click New (+), and then click Onboarding.

4. Select the migration option that you want, and then click Next. Migration options are as follows:

· Remote move

· Staged migration

· Cutover migration

· IMAP
The following screen shot shows the migration options:

In New migration batch window, click New (+)

Select the user/s that you want to move and click add and then ok and Next

In the next window enter on premise account credentials and click Next

After the wizard finish, the mailbox will be moved successful to Office 365

Enjoy…

How to hide and unhide all hidden contacts from GAL by using PowerShell script

Posted on March 19, 2014 by catastrophicerrors

How to hide contacts from GAL by using PowerShell

1.Follow the article to access Exchange Online through PowerShell:

Connect Windows PowerShell to the Service
http://help.outlook.com/en-us/140/cc952755.aspx

To hide a contact from Global Address List, type the cmdlet bellow

Command:
Set-Mailbox -Identity jv@itprodev.onmicrosoft.com -HiddenFromAddressListsEnabled $true

To check if your contact is hidden for the address list, type the command bellow

Command:
Get-Mailbox -Identity jv@itprodev.onmicrosoft.com | fl

How to unhide all hidden contacts from GAL by using PowerShell script

Summary
Contacts that are hidden from Global Address List (GAL) are not visible to Office 365 Exchange Online users. This article provides a method that unhide all hidden contacts from GAL by using PowerShell script.

1.Follow the article to access Exchange Online through PowerShell:

Connect Windows PowerShell to the Service
http://help.outlook.com/en-us/140/cc952755.aspx

2. Export a list for contacts hidden from GAL by running the following cmdlet:

Command:
Get-Mailcontact -Filter {HiddenFromAddressListsEnabled -eq $true} | Select identity,alias,HiddenFromAddressListsEnabled | Export-Csv -Path C:\HiddenContacts.csv -NoTypeInformation

3. Unhide the contacts from C:\HiddenContacts.csv file by running the following cmdlet:

Command:
$users = import-csv C:\HiddenContacts.csv
Foreach($_ in $users) {Set-mailcontact $_.identity -HiddenFromAddressListsEnabled $false}

Command:
Set-Mailbox -Identity jv@itprodev.onmicrosoft.com -HiddenFromAddressListsEnabled $false

More Information

Get-MailContact
http://technet.microsoft.com/en-us/library/bb124717.aspx

Set-MailContact
http://technet.microsoft.com/en-us/library/aa995950.aspx

Office 365 Hybrid Deployment (Part II ) – Installing and Configuring Active Directory Federation Services

Posted on September 4, 2013 by catastrophicerrors

In this Part 2, we will continue where we left off in Part 1. That is we will install and configure Active Directory Federation Service (ADFS) 2.0 on ADFS serve.
After we have configured the servers, we will verify they work as expected.

Create a new ADFS certificate

In my case scenario, I will create a Domain Certificate for ADFS.
In order to create a Domain Certificate follow the steps bellow:

a. On DC (Domain Controller), click Start, point to Administrative Tools, and then click Internet Information Services (IIS) Manager.

b. In the navigation pane, click Name of the DC (domain\Administrator).

c. In the results pane, under IIS, double-click Server Certificates.

d. In the actions pane, click Create Domain Certificate (The local domain certification authority will be used for this certificate)

e. In the Create Certificate window, on the Distinguished Name Properties page, in the Common name box, type sts.yourchilddomainname (for example: sts.onprem.contoso.com).

f. Type your information in the Organization, Organization Unit, City/locality State/province boxes, and then click Next.

g. On the Online Certification Authority page, under Specify Online Certification Authority, click Select.

h. In the Select Certification Authority window, click your Certification Authority (onprem-DC1-CA) and then click OK.

i. On the Online Certification Authority page, in the Friendly name box, type sts.yourchilddomainname.

j. Click Finish

Assign the certificate to the Default Website into IIS

Since all client authentication against ADFS occurs via SSL, we need to import a server authentication certificate on each ADFS server.
Because all clients should trust this certificate, it’s recommended to import a certificate from a 3rd party certificate provider.
Although we use a wildcard certificate in this article series, a single name SSL certificate is sufficient.
If you use a single name certificate, the FQDN included should match the FQDN we configured in the previous article (in this example sts.losgrecos.cloudns.org).

To assign the certificate to the Default Website follow the steps bellow:

a. In the Internet Information Services (IIS) Manager, in the navigation pane, expand DC1 (ONPREM\Administrator), expand Sites, and then click Default Web Site

b. In the actions pane, click Bindings

c. In the Site Bindings window, click Add.

d. In the Add Site Binding window, click the Type drop-down menu and then click https.

e. Click the SSL certificate drop-down menu and then click sts.yourchilddomainname

f. In the Add Site Binding window, click OK.

g. In the Site Bindings window, click Close.

h. Close the IIS Manager.

Installing the Active Directory Federation Services

Download Active Directory Federation Services 2.0 RTW from Microsoft Download Center

After the download finish launch “AdfsSetup.exe” and then accept the license agreement

On the “Server Role” page, we need to specify which to configure. Since these are the two internal ADFS servers, we wish to configure a “Federation server” so select that and click “Next”

On the “Welcome to the AD FS 2.0 Setup Wizard” page, click “Next”

As you can see on the next page, the wizard will now install a couple of prerequisites on the server. Click “Next”

After a minute or so the wizard will complete successfully and we can now click “Finish”
Make sure to uncheck “Start AD FS 2.0 Management snap-in when this wizard closes” as we want to install Update 2 for AD FS 2.0 before we continue.

When the update has been applied, launch the AD FS 2.0 management console by going to “Start”–> “Administrative tools” and in here selecting “AD FS 2.0 Management”
In the AD FS 2.0 Management console, click “AD FS 2.0 Federation Server Configuration Wizard”

Configure Active Directory Federation Services

a. On DC, click Start, point to Administrative Tools, and then click AD FS 2.0 Management

b. In the AD FS 2.0 management console, in the results pane, click AD FS 2.0 Federation Server Configuration Wizard

c. On the Welcome page, verify that the Create a new Federation Service radio button is selected and then click Next

d. On the Select a Stand-Alone or Farm Deployment page, click the Stand-alone federation server radio button and then click Next

e. On the Specify the Federation Service Name page, verify that the SSL Certificate and Federation Service name are sts.yourchilddomainname and then click Next

If the certificate name is not correct, do not continue. You must cancel the wizard and create the correct certificate using the procedure in tasks 5 and 6.

f. On the Ready to Apply Settings page, review the configuration and then click Next

Wait for the configuration to complete.

g. On the Configuration Results page, review the results and click Close

h. Close the AD FS 2.0 management console and log off DC

Be in tune for Part 3….

Office 365 "W15" Hybrid Deployment Exchange Server 2010 SP3 (Part I ) – Prerequisites

Posted on September 4, 2013 by catastrophicerrors

Introduction

Office 365’s Exchange Online is a compelling product from Microsoft that can be integrated with your existing on-premises Exchange Server 2010 organization to extend your Exchange deployment to the cloud.

In this five-part series, we’ll be looking more into Microsoft’s Hybrid Configuration Wizard (HCW), new in Exchange 2010 Service Pack 3 , which automates the process of configuring both your existing Exchange organization and Exchange Online to interact smoothly with little impact on your end-users.

A Hybrid Exchange deployment allows Office 365 to act as an extension of your existing on-premises deployment. This means users don’t necessarily need to know where their mailbox is hosted, and can continue to connect to Exchange in the same way they’ve always done. Mail routing can flow through your existing Exchange on-premises deployment, the process to configure clients like Outlook and ActiveSync clients remains the same, and end-users use existing Outlook Web App web addresses to sign in with a browser. In addition, services like Exchange Online Archives can be deployed to allow a user’s primary mailbox to be hosted on premise, whilst the archive mailbox is located in the cloud. In part one, we’re going to look at the pre-requisites required for a hybrid configuration and perform necessary checks against your Exchange deployment to help ensure a successful configuration.

Before we begin

There are a few pre-requisites to consider before we run the Hybrid Configuration Wizard. First, we’ll need an Office 365 subscription, known as a tenant. If you’ve not got one yet, and want to try it out – I’d recommend signing up for trial of the service. Even if you’ve already signed up for your production tenant, you’ll find a trial useful to allow you set things up in your test lab.

Once we’ve got the tenant, you’ll need to work through the basics covered in the Office 365 deployment guide, including executing the Office 365 Deployment Readiness Tool to check for any organizational issues and registering the accepted domains in Office 365 and Exchange that you’re going to use for your hybrid deployment.

I’d also recommend setup of Active Directory Federation Services 2.0 to provide authentication of your Office 365 mailboxes against your local Active Directory, a must for any Hybrid Deployment. Finally, you’ll need to setup and configure the Microsoft Online Services Directory Synchronization Tool (DirSync) so that local Active Directory accounts will be synchronized to Office 365.

Ensuring you are running the right Exchange 2010 Service Pack

If you are running a Wave 15 tenant – that’s an Office 365 tenant that’s running the latest version of Office 365 available -you’ll need to make sure you are running Exchange 2010 Service Pack 3 on the servers you’ll use for your Hybrid Configuration. As a minimum this will mean an upgrade to Service Pack 3 across all Exchange Servers within your Internet-facing site. You can tell which version your tenant is by logging onto the Office 365 portal easily, as illustrated below:

Figure 1

Hybrid Deployment Prerequisites

Before you create and configure a hybrid deployment using Microsoft Exchange Server 2013 and the Hybrid Configuration wizard, your existing on-premises Exchange organization must meet certain requirements. If you don’t meet these requirements, you won’t be able to complete the steps within the Hybrid Configuration wizard and you won’t be able to configure a hybrid deployment between your on-premises Exchange organization and the Exchange Online organization in Microsoft Office 365.

Important:

This feature of Exchange Server 2013 is currently not compatible with Office 365 operated by 21Vianet in China. For more information, see Learn about Office 365 operated by 21Vianet.

Prerequisites for hybrid deployment

The following prerequisites are required for configuring a
hybrid deployment:

On-premises Exchange organization Hybrid deployments can be configured for on-premises Exchange 2007-based organizations or later. For Exchange 2007 and Exchange 2010 organizations, at least one Exchange 2013 Client Access and one Exchange 2013 Mailbox server must be installed in the on-premises organization to run the Hybrid Configuration wizard and support Exchange 2013-based hybrid deployment functionality. We recommend combining the Exchange 2013 Client Access and Mailbox server roles on a single server when configuring hybrid deployments with Exchange 2007 and Exchange 2010 environments. All on-premises Exchange 2013 servers must have installed Cumulative Update 1 (CU1) or greater for Exchange 2013 to support hybrid functionality with Office 365. For more information, see Cumulative Updates for Exchange 2013.
For a complete listing of Exchange Server and Office 365 for enterprises tenant hybrid deployment compatibility, see the requirements listed in the following table for Exchange 2013-based and Exchange 2010-based hybrid deployments.

Note: To verify your Office 365 tenant version and status, see Verify Office 365 tenant version and status later in this topic.

Note:
1 Blocked in Exchange 2013   setup
2 Tenant upgrade   notification provided in Exchange Management Console
3 Requires at least one   on-premises Exchange 2010 SP2 server
4 Requires at least one   on-premises Exchange 2010 SP3 server
5 Requires at least one   on-premises Exchange 2013 CU1 or greater server

Office 365 for enterprises An Office 365 for enterprises tenant and administrator account and user licenses available on the tenant service to configure a hybrid deployment. The Office 365 tenant version must be 15.0.620.28 or greater to configure a hybrid deployment with Exchange 2013. Additionally, your Office 365 tenant status must not be transitioning between service versions. For a complete summary, see the preceding table. To verify your Office 365 tenant version and status, see Verify Office 365 tenant version and status later in this topic.
Learn more at Sign up for Office 365.
Custom domains Register any custom domains you want to use in your hybrid deployment with Office 365. You can do this by using the Office 365 Administrative portal, or by optionally configuring Active Directory Federation Services (AD FS) in your on-premises organization.
Learn more at Add your domain to Office 365.
Active Directory synchronization Deploy Office 365 Active Directory synchronization in your on-premises organization.
Learn more at Active Directory synchronization: Roadmap.
Autodiscover DNS records Configure the Autodiscover public DNS records for your existing SMTP domains to point to an on-premises Exchange 2013 Client Access server.
Office 365 organization in the Exchange admin center (EAC) The Office 365 organization node is included by default in the on-premises EAC, but you must connect the EAC to your Office 365 organization using your Office 365 tenant administrator credentials before you can use the Hybrid Configuration wizard. This also allows you to manage both the on-premises and Exchange Online organizations from a single management console.
Learn more at Hybrid Management in Exchange 2013 Hybrid Deployments.
Certificates Install and assign Exchange services to a valid digital certificate purchased from a trusted public certificate authority (CA). Although self-signed certificates should be used for the on-premises federation trust with the Microsoft Federation Gateway, self-signed certificates can’t be used for Exchange services in a hybrid deployment. The Internet Information Services (IIS) instance on the Client Access servers configured in the hybrid deployment must have a valid digital certificate purchased from a trusted CA. Additionally, the EWS external URL and the Autodiscover endpoint specified in your public DNS must be listed in Subject Alternative Name (SAN) of the certificate. The certificate installed on the Mailbox and Client Access (and Edge Transport if deployed) servers used for mail transport in the hybrid deployment must all use the same certificate (that is, they are issued by the same CA and have the same subject).
Learn more at Certificate Requirements for Hybrid Deployments.
EdgeSync If you’ve deployed Edge Transport servers in your on-premises organization and want to configure the Edge Transport servers for hybrid secure mail transport, you must configure EdgeSync prior to using the Hybrid Configuration wizard.

Important: Although EdgeSync is a requirement in deployments with Edge Transport servers, additional manual transport configuration settings will be required when you configure Edge Transport servers for hybrid secure mail transport.
Learn more at Edge Transport Servers with Hybrid Deployments.

After you’ve made sure your Exchange organization meets these requirements, you’re ready to use the Hybrid Configuration wizard. For more detailed guidance, see Create a Hybrid Deployment with the Hybrid Configuration Wizard.

Recommended tools and services

In addition to the required prerequisites described earlier, other tools and services are beneficial when you’re configuring hybrid deployments with the Hybrid Configuration wizard:

Remote Connectivity Analyzer tool The Microsoft Remote Connectivity Analyzer tool checks the external connectivity of your on-premises Exchange organization and makes sure that you’re ready to configure your hybrid deployment. We strongly recommend that you check your on-premises organization with the Remote Connectivity Analyzer tool prior to configuring your hybrid deployment with the Hybrid Configuration wizard.
Learn more at Remote Connectivity Analyzer Tool.
Single sign-on Although not a requirement for hybrid deployments, single sign-on enables users to access both the on-premises and Exchange Online organizations with a single user name and password. Single sign-on provides users with a familiar sign-on experience and allows administrators to easily control account policies for Exchange Online organization mailboxes by using on-premises Active Directory management tools.
Single sign-on is also highly recommended for organizations that plan on deploying Exchange Online Archiving (EOA) in their Exchange organization.
If you decide to deploy single sign-on with your hybrid deployment, we recommend that you deploy it with Active Directory synchronization and before using the Hybrid Configuration wizard.
Learn more at Prepare for single sign-on.

Verify Office 365 tenant version and status

To verify the version and status of your Office 365 tenant, follow the steps below:

Connect to the Office 365 tenant using remote Windows PowerShell. For step-by-step connection instructions, see Connect Windows PowerShell to the Service.
After connecting to the Office 365 tenant, run the following command.
Copy
Get-OrganizationConfig | Format-List AdminDisplayVersion,IsUpgradingOrganization
Verify that your Office 365 tenant and status meet the following requirements:
- AdminDisplayVersion parameter value is equal to or greater than 15.0.620.28
- IsUpgradingOrganization parameter is False
  For example, “0.20 (15.0.620.51)” and “False”.

Warning:

If your Office 365 tenant version and status don’t meet the hybrid deployment requirements, the Hybrid Configuration wizard won’t complete successfully.

Disconnect from the Office 365 tenant remote PowerShell session. For step-by-step disconnection instructions, see Connect Windows PowerShell to the Service.

Pre-flight checks against your Exchange environment

With your Office 365 prerequisites in place, it’s time to check over your Exchange environment to verify that everything you need for the Hybrid Configuration Wizard to successfully execute is in place, and help ensure that features work after your hybrid configuration has been implemented.

Auto Discover and Exchange Web Services Checks

The first thing we need to check is connectivity to Auto Discover and Exchange Web Services from outside your organization. If you’ve already got external clients working correctly, there’s a fair chance this is already configured, but it doesn’t hurt to test.

To test Auto Discover and Exchange Web Services, we’ll use Microsoft’s Remote Connectivity Analyzer to simulate Exchange Web Services connectivity, using AutoDiscover as part of the process. First create a test Exchange mailbox, and then run the EWS General Test (as shown below) to verify connectivity, and remediate if necessary.

Figure 2

Reverse Proxy, ISA or TMG checks

If you’re using a reverse proxy that uses pre-authentication for your deployment, you’ll also need to examine it’s configuration. That’s because the federated components of Exchange use token-based authentication to connect from Office 365 to your Exchange On-Premises organization rather than traditional authentication against your Active Directory, and services such as the MRS Proxy don’t support SSL Offload for the EWS virtual directory.

Although there are more complicated ways of achieving it, the simplest way to ensure TMG doesn’t cause any problems is to move your rules for the EWS and AutoDiscover virtual directories into a dedicated rule, with the following key settings:

Allow All Users

Figure 3

Authentication Delegation set to “No delegation, but client may authenticate directly”
Figure 4

Publishing the paths /ews/* and /autodiscover/*
Figure 5

Hub Transport checks

Moving onto the Hub Transport components, we need to consider how Exchange will be able to route mail inbound and outbound to and from Office 365.

As part of the Hybrid Configuration Wizard, a new receive connector will be created, pre-populated with the correct IP address ranges to allow mail to be received from Office 365. We’ll also need to allow our Hybrid Server, or Exchange 2010 servers hosting the hub-transport role to send and receive mail to those IP address ranges at the network firewall level. The method to accomplish this varies based on your network design, but you will typically need to expose at least one Hub Transport server to the internet with a public IP address, with firewall restrictions to only allow Office 365 to communicate both to and from it on the SMTP port, TCP port 25.

Additionally, we’ll need to ensure the correct certificates are installed and in place for TLS-secured mail transport. When we tested EWS and AutoDiscover earlier, certificates were tested on the Client Access roles, but you’ll also need to ensure that a suitable certificate is available on the Hub Transport servers if they are on different Exchange Servers; and that the certificate name is suitable. This may mean you need to ensure the Fully Qualified Domain Name (FQDN) you use for your Hub Transport roles is present on the Subject Alternative Name (SAN) certificate. If you’re currently using a wildcard certificate, although it’s not a best practice, this should work fine.

Address Book Policy checks

If you’re in the process of upgrading to Exchange 2010, or have only installed the Exchange 2010 Hybrid server role into your existing environment, you will also need to give your Email Address Policies (or Recipient Policies in Exchange 2003 terminology) some consideration. During the Hybrid Configuration Wizard, your Default Email Address Policy will be upgraded and then one of your Office 365 tenant domains will be added to the policy, before applying it to your Exchange organization.

Therefore it’s important to make sure that the Email Address policies are in good order before you begin and you should be confident that when the Hybrid Configuration Wizard applies the Default Email Address policy it will complete successfully.

Outbound HTTP connection and proxy checks

Next, we need to consider any network infrastructure that might prevent our Exchange 2010 Hybrid servers from communicating with Office 365 via HTTPS. The number one issue I usually see is proxy server related, so it’s worth ensuring that you’ve tackled this up-front before you run into issues.

If at all possible, I’d recommend allowing the Exchange Servers to communicate with Office 365 directly via HTTPS and avoid proxy servers for this communication altogether, however if that’s not possible, ensure you do the following:

Ensure all Exchange servers participating in the Hybrid Configuration, and installations of the Exchange Management Console you’ll use to manage the environment can by-pass proxy servers for the Office 365 and Exchange Online IP addresses and URLs.
Configure the correct proxy settings using the netsh command. An easy way to do this is by configuring Internet Explorer on the server with the correct settings, testing the settings in IE and then using an elevated command prompt executing the following command:
netsh winhttp import proxy source=ie
Configure the correct proxy server settings within the Exchange 2010 Hybrid servers, using the following Exchange Management Shell cmdlet:
Set-ExchangeServer <servername> -InternetWebProxyURL:http://proxy:port

If you’re using a proxy server in your environment already, there’s a good chance you’ve already performed some of this configuration, but even if you think it’s right, it’s worth double checking settings before you continue.

Once making sure relevant proxy settings are configured correctly, you’ll need to make sure you can connect the Exchange Management Console to your Office 365 tenant. This will not only test proxy settings you’ve configured, but it’s also necessary later on when we use the Exchange Management Console to run the Hybrid Configuration Wizard.

To connect the Exchange Management Console to your Office 365 tenant:

Right click on the “Microsoft Exchange” root node, and choose “Add Exchange Forest”
Enter a friendly name, such as “Office 365”
From the drop-down, select “Exchange Online”

After entering your tenant credentials, you should see your tenant alongside your on-premises Exchange organization:

Figure 6

Summary
In part one, we’ve looked at the pre-flight checks we need to perform to help ensure a successful execution of the Hybrid Configuration Wizard. In the following parts of this series, we’ll take a quick look at what goes on under the hood of the Hybrid Configuration Wizard itself, walk through its execution and then finally test functionality.

To be continue Wink

How to Create Public Folder’s in Office 365 W15

Posted on June 13, 2013 by catastrophicerrors

The Public Folders pages is a new feature for Exchange Online introduced with Office 365 Preview. It provides an easy and effective way to collect, organize, and share information with other people in your workgroup or organization. It is not designed for Archiving Data or Document sharing and Collaboration.

In Office 365 Preview every public folder must live in a Public Folder mailbox. You will need to create at least one Public Folder mailbox before you can create Public Folders.

To create a Public Folder Mailbox
Navigate to the Exchange Admin Center (EAC)

Click Public Folders > Public Folder Mailboxes > Click (+) New

Enter a Name and click Save

Check the list to ensure the new Public Folder Mailbox is available

To create a Public Folder
Click Public Folders > Public Folders > Click (+) New

Enter a Name and click Save.

Verify that the folder has been created

In the Public Folder window, note that several new options will be available, e.g:

General: Public Folder name etc
Statistics: Count of Deleted Items etc
Limits: Warning Quotas etc
General mail properties: Edit Alias, Display Name, add custom attributes
Emails Addresses: Add/Edit additional SMTP Addresses for the public folder
Member Of: Add the public folder to distribution groups
Delivery Options: Configure Send As, Send on behalf, and Forwarding on the public folder
Mail Flow Settings: Enable/Edit delivery restrictions on for the public folder mailbox.

To view Public Folders on Outlook 2013, navigate near to Tasks and you’ll see "………" > click on "…….." and choose Folders

Now you can view your Public Folders on Outlook 20013

Note

Kiosk plan users are not licensed for public folders
You are limited to 50 public folder mailboxes with a maximum size of 1.25 TB.
See the Exchange Online Service Description for more

How To: Give Users Send As Permission

Posted on June 13, 2013 by catastrophicerrors

Send As permission, also known as SendAs permission, gives a user permission to use another recipient’s e-mail address in the From address. For example, when you give the user Chris Send As permission on the mailbox of a user named Michelle, Chris can send e-mail messages that appear to be sent by Michelle, with no indication to the recipient that anyone other than Michelle sent the message. Or, if your organization uses a Help Desk distribution group, you can give Help Desk staff Send As permission on the Help Desk distribution group. That way, replies to messages sent to the Help Desk group appear to come from the group instead of an individual Help Desk technician.

To give a user Send As permission, you use Windows PowerShell

Before you begin

To learn how to install and configure Windows PowerShell and connect to the service, see Use Windows PowerShell in Exchange Online.
The Send As permission is different than the Send on Behalf permission. If the user Chris has Send on Behalf permission on Michelle’s mailbox, when Chris sends an e-mail as Michelle, the From address shows Chris on behalf of Michelle. Microsoft Outlook users can configure Send on Behalf permissions on their own mailbox using delegates. Administrators can configure Send on Behalf permissions on any recipient type using the GrantSendOnBehalfTo parameter.
Want more information about parameters? See An explanation of parameters.

Give a user Send As permission
Launch Windows PowerShell and perform the following steps:

Import-Module msonline
$cred = Get-Credential
Connect-MsolService -cred $cred
Get-Command –Module msonline

1) Import the module.
2) Create a credential-object stored in the variable $credimp
3) Create a new remote PowerShell connection against the PowerShell endpoint for Office 365
4) List the cmdlets available

A shortcut to the module is also available on the Start-menu (you can skip step 1 if launching this shortcut):

Run the following command:
Command:
Add-RecipientPermission <identity> -AccessRights SendAs -Trustee <user>

For example, to give the user named Joanna Vathis Send As permission for the Test mailbox , run the following command:
Example:
Add-RecipientPermission test@itprodev.onmicrosoft.com -AccessRights SendAs -Trustee joannav@itprodev.onmicrosoft.com

OR
Command:
Add-RecipientPermission "TEST" -AccessRights SendAs -Trustee "Joanna Vathis"
Joanna can now send messages that appear to come directly from the TEST mailbox.
Note By default, you are asked to confirm the addition of the Send As permission. To skip the confirmation prompt, use -Confirm:$false.

View Send As permissions

Use the Get-RecipientPermission cmdlet to display all the Send As permissions configured in your organization. You can filter the list to show Send As permissions granted to a specific user and to see the Send As permission on a specific recipient.

View Send As permission for a specific user

Run the following command:
Command:
Get-RecipientPermission – Trustee <user>
For example, to list the recipients for whom the user named Kim Akers has Send As permission, run the following command:
Command:
Get-RecipientPermission -Trustee joannav@itprodev.onmicrosoft.com
Joanna can send messages that appear to come directly from the recipients

View Send As permission on a specific recipient

Run the following command:
Command:
Get-RecipientPermission <identity>

For example, to list the users who have Send As permission on the TEST mailbox, run the following command:
Command:
Get-RecipientPermission "TEST"
The users listed can send messages that appear to come directly from the TEST mailbox.

View all Send As permissions you’ve configured in your organization

Run the following command:
Command:
Get-RecipientPermission | where {($_.Trustee -ne ‘nt authority\self’) -and ($_.Trustee -ne ‘null sid’)}

Note The filter hides the automatic Send As permission that allows a user to send messages from their own mailbox, and also any results from system objects like mailbox plans.

Revoke Send As permission

Run the following command:
Command:
Remove-RecipientPermission <identity> -AccessRights SendAs -Trustee <user>

For example, to revoke Joanna’s Vathis Send As permission for the TEST mailbox, run the following command:
Command:
Remove-RecipientPermission "TEST" -AccessRights SendAs -Trustee joannav@itprodev.onmicrosoft.com

Now Joanna can’t send messages that appear to come directly from the TEST mailbox.
To skip the confirmation prompt, use -Confirm:$false.

How people use the Send As permission

Individual users or members of security groups with Send As permission can open their own mailboxes and send messages using the From address of the recipient.
Send As permission doesn’t give a user access to another user’s mailbox. To give an individual or members of a security group access to a mailbox, use the following command:
Command:
Add-MailboxPermission <mailbox> -User <user or security group> -AccessRights FullAccess

When you give someone access to a mailbox and Send As permission on the mailbox, that person can open the mailbox using their own credentials, compose new messages, and reply to messages in the mailbox.
An explanation of parameters
You use the Add-RecipientPermission, Remove-RecipientPermission, and Get-RecipientPermission cmdlets to add, remove and view Send As permissions. These cmdlets use the same basic parameters:

Identity This parameter specifies the target recipient. The user or group specified by the Trustee parameter can operate on this recipient.
You can specify any type of recipient. For example:

Mailboxes
Mail users
External contacts
Distribution groups
Dynamic distribution groups
The Identity parameter is a positional parameter. The first argument on a cmdlet is assumed to be the Identity parameter when no parameter label is specified. This lets you specify the parameter’s value without specifying the parameter’s name.

Trustee This parameter specifies the user or group to whom you’re granting the permission. This allows the user or group to operate on the recipient specified by the Identity parameter.
You can specify the following types of users or groups:

Mailbox users
Mail users with a user account
Security groups

For the Identity and Trustee parameters, you can use any value that uniquely identifies the recipient.

For example:

Alias
Distinguished name (DN)
GUID
Name
Display name
LegacyExchangeDN
E-mail address

Additional Information’s:

Give Users Send As Permission
http://help.outlook.com/en-us/140/ff852815.aspx

How to get the list for SMTP address and Last connection time for all the users

Posted on June 13, 2013 by catastrophicerrors

Summary
This article describes how to use PowerShell Commandlet to get the list for SMTP address and Last connection time for all the users.

Steps to implement the request
Step 1: Run the following to authenticate yourself and import PowerShell commands to your local session:

$LiveCred = Get-Credential
$Session = New-PSSession -ConfigurationName Microsoft.Exchange-ConnectionUri https://ps.outlook.com/powershell/ -Credential $LiveCred -Authentication Basic -AllowRedirection
Import-PSSession $Session

Image 1

Step 2: Run the Commandlet to get the SMTP address and Last connection time for all the users
Commandlet to get SMTP address:
Get-Mailbox | fl EmailAddresses, identity > C:\Emailaddress.csv

Image 2

Image 3

Image 4

Commandlet to get Last connection time:
Get-Mailbox -ResultSize unlimited | Get-MailboxStatistics | select-object identity,lastlogontime,lastlogofftime,DisplayName | sort-object DisplayName -descending | export-csv C:\Lastlogontime.csv

Image 5

Image 6

Image 7

Enjoy Wink

Microsoft Exchange 2013 Public Folders Migration Scripts

Posted on June 12, 2013 by catastrophicerrors

Microsoft recently release the necessary support scripts to migrate Exchange 2007/2010 Public Folders to Office 365.

Microsoft Exchange 2013 Public Folders Migration Scripts

Use these scripts to migrate public folders from Exchange 2010 or 2007 to Exchange 2013.
In order to migrate Exchange 2010 or 2007 Public Folders to Exchange 2013 on O365, we need to analyze the existing
Public Folder hierarchy for size to figure out the number of Public Folder mailboxes that are required on O365 and the distribution of folders across mailboxes.

Microsoft Exchange 2013 Public Folders Directory Sync Support Scripts

Use this scripts if you need to do one of the following
Initial creation of mail enabled public folder objects in the destination Active Directory for public folder migration from Exchange 2007 or 2010 to Exchange 2013
Synchronization of mail enabled public folder objects from cloud to on premise Active Directory
Synchronization of mail enabled public folder objects from on premise to cloud Active Directory
Synchronization of public folder mailbox objects from cloud to on premise Active Directory