Script: Exchange Server 2013 SP1 Prerequisites (Exchange2013SP1Prerequisites_W2008R2SP1_v1.0)


This script automate execute steps for installing the necessary Windows Server 2008 R2 SP1 operating system prerequisites for the Microsoft Exchange 2013 Mailbox, Client Access, Multirole and Edge Transport server roles. The prerequisites that are needed to install Exchange 2013 on a Windows Server 2008 R2 SP1 computer depends on which Exchange roles you want to install.

What do you need to know before you begin?

  • The Edge Transport server role is available starting with Exchange 2013 SP1.
  • Make sure that the functional level of your forest is at least Windows Server 2003, and that the schema master is running Windows Server 2003 with Service Pack 2 or later.
  • The full installation option of Windows Server 2008 R2 SP1 must be used for all servers running Exchange 2013 server roles or management tools.
  • You must first join the computer to the appropriate internal Active Directory forest and domain.
  • You must check and be sure your server has access to the internet
  • Some prerequisites require you to reboot the server to complete installation.

Let’s have a quick look how to execute the script Exchange2013SP1Prerequisites_W2008R2SP1_v1.0 on Windows PowerShell and what this script do for us.

  1. Login to Windows Server 2008 R2 SP1 with Enterprise Administrator credentials
  2. Start Windows PowerShell “As Administrator”

clip_image001

  1. Next step, copy the script Exchange2013SP1Prerequisites_W2008R2SP1_v1.0 on (C:\) drive
  1. Let’s start with running scripts from within Windows PowerShell itself.
    In case you get weird error messages when you try to run a script, the reason is only one, security settings built into Windows PowerShell include something called the “execution policy” the execution policy determines how (or if) PowerShell runs scripts. By default, PowerShell’s execution policy is set to Restricted that means that scripts – including those you write yourself – won’t run.
    Navigate back to Windows PowerShell and set the Execution policy to unrestricted in order to be able to run the script, in that case, use this command to set your execution policy to RemoteSigned or Unrestricted

clip_image002

Note: The Set-ExecutionPolicy cmdlet enables you to determine which Windows PowerShell scripts (if any) will be allowed to run on your computer.

Windows PowerShell has four different execution policies:

  • Restricted – No scripts can be run. Windows PowerShell can be used only in interactive mode.
  • AllSigned – Only scripts signed by a trusted publisher can be run.
  • RemoteSigned – Downloaded scripts must be signed by a trusted publisher before they can be run.
  • Unrestricted – No restrictions; all Windows PowerShell scripts can be run.
  1. The most common (default) way to run a script is by calling it:

PS C:\> & “C:\Admin\My first Script.ps1”

If the path does not contain any spaces, then you can omit the quotes and the ‘&’ operator

PS C:\> C:\Admin\Myscript.ps1

If the script is in the current directory, you must indicate this using .\ (or ./ will also work)

PS C:\> .\Myscript.ps1

In our case scenario we run the script in the current directory “C:\” so, we must indicate this using .\ and we click Enter

clip_image003

  1. Our script now it starts running, select an option from the menu. In my case scenario, I will select option 3 (E2013 Multirole installation) and click Enter

clip_image004

  1. As you can easy check bellow, my Multirole Prerequisites are in progress to be download and install

clip_image005

  1. After the Prerequisites successfully installed, we have to choose the option 10 in order to restart our server

clip_image006

  1. After restart your server, login as EA and proceed to install your Microsoft Exchange Server 2013 SP1

clip_image007

You can download the script from TechNet Gallery Script Center Capture

Advertisements

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


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


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.

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

Microsoft Exchange 2013 Public Folders Migration Scripts


    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