Office 365 Hybrid Configuring Using Windows Azure – Part 4

In this part of the article series, we shall perform hybrid configuration. A hybrid deployment provides a unified email experience for your Office 365 deployment. It enables users who have mailboxes in their on-premises Exchange Server environment and users who have Exchange Online mailboxes to find one another in the global address list (GAL), and to send, receive, and reply to email, regardless of which system is hosting their mailbox.

Below is the list of activities performed in this article

I. Configure Hybrid between Exchange 2013 and Office 365

II. Add new DNS record to enable Office 365 to work with On-premises.

Other part of the Articles can be found at below link

Office 365 Hybrid Configuring Using Windows Azure – Part 1

Office 365 Hybrid Configuring Using Windows Azure – Part 2

Office 365 Hybrid Configuring Using Windows Azure – Part 3

Office 365 Hybrid Configuring Using Windows Azure – Part 5

Office 365 Hybrid Configuring Using Windows Azure – Part 6

Configure Hybrid between Exchange 2013 and Office 365

1. Login to the Exchange 2013 server KrisExch01.cloudapp.net

2. Before we start the hybrid configuration, we need to connect to both Exchange on-premises EAC and then connect to Office 365 console. Default Windows 2012 server Internet Explorer scripts blocks from accessing Office 365 consoles.

Given below is the fix for the same.

Internet Explore -> Internet Option -> Security -> Advance -> Add the below URL referenced in the snap.

3. Login to the Exchange EAC using Exchange organization admin account

4. Click on the Hybrid -> click on ‘Enable’ to start the hybrid configuration process.

5. This will first prompt to login to Office 365, click on ‘Sign in to Office 365’

6. Login to Office 365 using the admin credentials. With this we have connected to both Office 365 and on-premises on the same console.

7. Finally, we are now ready to start the hybrid configuration. Click on ‘Enable’ again to start the Hybrid configuration wizard.

8. Select ‘Yes’ on ‘Set up Exchange Hybrid’ to confirm the hybrid configuration

9. Before we continue with the hybrid configuration, we need to re-confirm the Domain ownership. In the next page it prompts with the below statement.

“Before proceeding to the next step, copy the following tokens and create a TXT record for each token

On the public DNS to confirm domain ownership”

Login to Go Daddy for the domain checkwhatsin.com and create a TXT entry for the token. Wait for 5 minutes at the hybrid configuration wizard and click on ‘Next’ to continue

10. Below is the snapshot of the Go daddy with the TXT entry with the Token specified above

11. Since we do not have the edge transport server in our organization, select ‘Configure my Client Access and Mailbox servers for secure mail transport(typical)’ and click on ‘Next’

12. Choose one or more on-premises Client Access server to host receive connectors for secure bi-directional mail transport with Office 365. Since, we have only one Multirole server , select the server EXCH01 by using browse… button and click on ‘Next’

13. Choose one or more on-premises Mailbox server to host Send connectors for secure bi-directional mail transport with Exchange online. Since we have only one multirole server, use the ‘Browse’ button to select the server EXCH01 and click on ‘Next’ to continue

14. We need a valid certificate from trusted Certificate Authority for the secure mail transport between on-premises and Office 365. Exchange 2013 is already configured with wildcard certificate, select ‘Checkwhatsin’ certificate for the same. Click on ‘Next’ to continue

15. Enter a fully qualified domain name for the on-premises exchange server to accept email from Exchange online Protection (EOP). In our scenario we have ‘KrisExch01.cloudapp.net’ as internet facing multi-role Exchange server and the internet alias name for the same is ‘mail.checkwhatsin.com’. Specify the same and click on ‘Next’

16. Hybrid configuration needs both on-premises and Office 365 account credentials with the permission of the ‘organization management’ permission. Enter the on-premises admin credentials and click on ‘Next’ to continue

17. Enter the Office 365 admin credentials and click on ‘Next’

18. Exchange Hybrid configuration settings are now completed. Click on ‘Update’ button to configure and enable the hybrid features between Enterprise and Office 365 organization.

19. This process may take several minutes to complete. Follow the status progress bar and wait for the configuration to be completed

20. Now with this execution, the hybrid configuration has been completed successfully.

Add new DNS record to enable Office 365 to work with On-premises

In this section, we shall switch back to Office 365 continue and complete the configuration where we had left at the end of the Part 1 of this article series. We will have to complete the domain configuration by making necessary changes at ‘Chechwhatsin.com’ DNS to allow Office 365 EOP to accept all emails for checkwhatsin.com and route the email based on the mailbox location in either Office 365 or On-premises.

1. Login to Office 365 console with Org admin credentials and click on ‘domains’ -> ‘Complete setup’

2. Click on ‘Start Step 3’ to ‘Set the domain purpose and DNS configuration’.

3. On set domain purpose page, select ‘Exchange online’ and ‘I plan to set up on-premises mailboxes to work with office 365 or make sure they’re protected with Exchange online protection’ and click on ‘Next’

4. On Configure connectors page click on ‘Done, go check’. It will verify the Office 365 Outbound connectors are set up correctly to work with on-premises exchange severs.

5. Since the hybrid configuration wizard has been completed successfully, we should get the message “we’ve successfully verified that an outbound connector is setup for checkwhatsin.com”.

Now we may need to perform Autodiscover and other connectivity test using ‘Microsoft Remote connectivity Analyzer’. As we have already performed this step at part 1 of the article series, we will skip this process.

Select ‘I’ve run the tool and confirmed that my configuration is correct’ and click on ‘Next’ to continue.

6. At ‘Add DNS records’ page, it has all the necessary steps to create the manual entry at the DNS. We need to add all the DNS record specified except the autodiscover. This will allow us to keep the existing autodiscover entry point to the on-premises solution. This will help to continue the outlook configuration even after the movement of mailbox from on-premises to Office 365.

It will also add new MX record which sends all internet email for checkwhatsin.com to Office 365 Exchange online protection (EOP).

7. Below are the DNS entries at Go daddy for each of the DNS configuration specified above with the exception of Autodiscover.

8. Once the DNS entry has been added, wait for the 15 min of replication time and click on ‘Done, go check’ button for office 365 to verify the DNS entry.

We should get the successful status on all additional Office 365 records and failure status for just autodiscover entry, as we did not make the DNS entry for ‘autodiscover’ to point to address ‘autodiscover.outlook.com’.

With this we have made all the necessary changes at the Office 365 end and on-premises exchange server to work with hybrid mode.

In the next part of the article, we will be verifying and performing the final configuration at both on-premises exchange and in Office 365 in the hybrid mode.

Other part of the Articles can be found at below link

Office 365 Hybrid Configuring Using Windows Azure – Part 1

Office 365 Hybrid Configuring Using Windows Azure – Part 2

Office 365 Hybrid Configuring Using Windows Azure – Part 3

Office 365 Hybrid Configuring Using Windows Azure – Part 5

Office 365 Hybrid Configuring Using Windows Azure – Part 6

Office 365 Hybrid Configuring Using Windows Azure – Part 3

In the first part of the article series, we have configured the windows Azure lab and office 365 account and in the second part, we had configured ADFS and ADFS Proxy server.

Now, in this part of the series we will be configuring Single Sign on (SSO) and Directory synchronization between the On-Prem and Office 365.

I. Configuring SSO between office 365 and Exchange 2013 On-Premises

II. Configuring Directory Synchronization between Office 365 and Exchange 2013 On-Premises

Other part of the articles are be found below

Office 365 Hybrid Configuring Using Windows Azure – Part 1

Office 365 Hybrid Configuring Using Windows Azure – Part 2

Office 365 Hybrid Configuring Using Windows Azure – Part 4

Office 365 Hybrid Configuring Using Windows Azure – Part 5

Office 365 Hybrid Configuring Using Windows Azure – Part 6

Configuring SSO between Office 365 and Exchange 2013 On-Prem

1. Connect to server krisadfs.cloudapp.net and login with the domain admin credentials.

2. ‘Microsoft online service sign-in Assistant’ is a prerequisite for installing ‘Windows Azure Active Directory Module’ to configuring Single Sign On

Download and perform the default installation of Microsoft Online Services Sign-In Assistant for IT Professionals

3. Login to the Office 365 portal using Internet Explorer and click on “users and group” on the left pane and click on Single Sign-on “Set up”

4. Scroll down to select Windows 64-Bit version of ‘Windows Azure Directory module for Windows PowerShell’. Click on ‘Download’ to get the file into the local computer.

5. Perform the default installation of ‘Windows Azure Active Directory Module for Windows PowerShell’ by clicking ‘Next’

6. Click on ‘Finish’ to complete the installation.

7. To configure federation between Office 365 and On-Premise, run the ‘Windows Azure Active directory PowerShell’ shortcut from the desktop

8. Connect to Office 365 by executing the PowerShell Connect-MSOLService’ cmdlet. This execution will prompt for the credentials. Input the credentials as admin@checkwhatsin.onmicrosoft.com with password and click on ‘OK’

9. Once it is connected to the Office 365, we can manage it using PowerShell. Execute the command given below to get the details of all the domain registered in Office 365.

Get-MSolDomain

10. We also get a detailed information of the domain by executing the command. Since, we have not configured federation yet, authentication status is as ‘Managed’ for the domain checkwhatsin.com. Once federation is configured between Office 365 and on-premises, then the authentication status will change from managed to federated for the domain checkwhatsin.com

Get-MSolDomain –Domainname Checkwhatsin.com |fl

11. The Convert-MSOLDomainToFederated cmdlet converts the specified domain from standard authentication to single sign-on. To convert the domain checkwhatsin.com as Federated, execute the command that is given below.

Convert-MSolDomaintoFederation –DomainName checkwhatsin.com

12. Successful execution details can be verified using the command given below and the screen has the authentication details changed to Federated.

Get-MSolDomain –Domainname Checkwhatsin.com |fl

13. To verify if the ADFS federation is working , access the office 365 portal page from the browser and input the user name as admin@chekcwhatsin.com and just hit the tab button

14. This should automatically start the redirection process

15. Finally, this should connect us to the URL https://sts.chekwhatsin.com for the user authentication prompt

With this we have successfully completed the configuration of SSO between On-prem and Office 365.

Configuring Directory Synchronization between Office 365 and Exchange 2013 On-Prem

DirSync (Directory Synchronization) is a tool in making copies of local on-premises directory object into the Office 365 environment in a hybrid cloud deployment. DirSync service synchronizes object only from on-premises to Office 365 and it runs for every three hours to publish the changes from the on-premises to Office 365.

In this section, we will create a service account to configure Dirsync server on the server krisdirsync.cloudapp.net

Creating and configuring Service account for DirSync

1. Login to the Office 365 portal with the organization admin account and click ‘users and groups’ from the left pane and click on + symbol to create a new account

2. Input the service account name and other necessary details and click on ’Next’

3. Select the Assign Role as ‘Global Administrator’ and input other details like ‘Alternative email address, ‘location’ and click on ‘Next’.

4. Since, this is a service account, it does not need a mailbox/license. Do not select any license and click on ‘Next’ to continue

5. Click on ‘Create’ button to create a new service account and send the service account details to the admin.

6. New account has to be logged in once to activate the account and set the new password. Hence, login to the Office 365 portal using the new service account

7. This will prompt us for a password change. Update the new password and re-confirm the same password. Click on ‘Save’ to set the new password for the service account.

8. Office 365 has a password expiration policy set on all the accounts. Service accounts needed comply with the password expiration policy and they have to be disabled. To disable the password expiration, connect to the Office 365 Windows Azure Active Directory module for PowerShell and execute the below PowerShell cmdlet to set the password never expires to $false.

Get-MsolUser –UserPinrcipalName svr-dirsync@checkwhatsin.onmicrosoft.com | set-MsolUser –PasswordNeverExpires $false

Configuring Directory Synchronization between Office 365 and Exchange 2013 On-Prem

1. Login to Directory Synchronization server krisdirsync.cloupdapp.net with the domain admin credentials

2. Install .net Framework 3.5 Features from add ‘Roles and features’ wizard or we can use the below PowerShell cmdlet to install the same

Install-WindowsFeature NET-Framework-Core

3. To start the active directory synchronization , connect to the office 365 portal from the browser and click on users and group and select Active Directory Synchronization :Set Up

4. Select ‘Activate’ button to ‘Activate Active Directory synchronization’

5. Confirm the activation process by clicking on the ‘Activate’ button again

6. Once it is activated, we should be able to download the Directory Sync tool to and save the copy desktop

7. Dirsync is a small executable file, which needs to be setup to synchronize from an on-premises Active Directory to Microsoft Office 365

8. Start the installation of Dirsync by double clicking on it and click on ‘Next’ at the Welcome page.

9. Accept the licenses, default installation path and click on ‘Next’ to continue

10. Click on ‘Finish’ to complete the installation and make sure to “Start Configuration Wizard now” is checked to start the configuration immediately.

11. Start the Windows Azure Active Directory Sync tool configuration wizard with the click ‘Next’ on the Welcome page.

12. Provide Office 365 admin credentials at ‘Windows Azure Active Directory Credentials’ and click on ‘Next’

13. Type on-premises domain admin credentials at ‘Active Directory Credentials’ page and click on ‘Next’

14. Since we are configuring Hybrid between Office 365 and on-premises, we need to make sure that the ‘Enable Hybrid Deployment’ is checked and then click on ‘Next’

15. We do not need a password sync for SSO configuration. We create object at on-premises Active Directory and provision mailbox for the on-premises objects at Office 365. Hence, make sure to ‘Enable password Sync’ is unchecked and click on ‘Next’

16. Wait for the ‘Configure complete’ status on the configuration page and click on ‘Next’

17. Click on ‘Finish’ at the wizard and make sure to select ’Synchronize your directories now’.

18. The active directory sync will immediately synchronize the objects from on-premises to Office 365. Then, click on ‘OK‘

19. Login to the Office 365 portal to verify the synchronization of On-prem objects as “Synced with Active Directory” at users and groups. Shown below is the reference snap with marked red has the details of the objects ‘Synced with Active Directory’

With this we have come to the end of this article series, where we have successfully configured SSO and Directory synchronization between on-premises and Office 365. We are almost ready with the Windows Azure environment to configure Hybrid setup.

In the next part we will be creating and configuring Hybrid between Windows Azure and Office 365.

Other part of the articles are be found below

Office 365 Hybrid Configuring Using Windows Azure – Part 1

Office 365 Hybrid Configuring Using Windows Azure – Part 2

Office 365 Hybrid Configuring Using Windows Azure – Part 4

Office 365 Hybrid Configuring Using Windows Azure – Part 5

Office 365 Hybrid Configuring Using Windows Azure – Part 6

Office 365 Hybrid Configuring Using Windows Azure – Part 2

In the first part of the article series, we created new windows Azure LAB, installed and configured a new domain controller and Exchange server. We also created additional windows 2012 Azure servers for ADFS, ADFS Proxy and Directory synchronization (DirSync). ADFS (Krisadfs.cloupdapp.net) and Dirsync (krisdrisync.cloudapp.net) are joined to the windows domain ‘checkwhatsin.com’. ADFS Proxy (krisadfsproxy.cloudapp.net) is not joined to the domain, since it is designed to be placed in DMZ

Office 365 Hybrid Configuring Using Windows Azure – Part 1

Office 365 Hybrid Configuring Using Windows Azure – Part 3

Office 365 Hybrid Configuring Using Windows Azure – Part 4

Office 365 Hybrid Configuring Using Windows Azure – Part 5

Office 365 Hybrid Configuring Using Windows Azure – Part 6

In this part of the article series, we will perform the activities shown below to configure Single Sign on (SSO). With single sign-on (SSO), users in your organization will be able to use their corporate credentials to access the Office 365 service offerings, thereby, removing the burden of managing multiple logon identities and passwords. Without an SSO, an Office 365 user would have to maintain separate user names and passwords.

I. Installation and configuration of ADFS server

II. Installation and configuration of ADFS proxy server

Installation and configuration of ADFS server

Active Directory Federation Services (AD FS) is a server role in Windows Server that provides Web single-sign-on (SSO) technologies to authenticate a user to multiple Web applications over the life of a single online session. At the outset, we need to create a service account before configuring Exchange

1. Login to the Krisadc.cloudapp.net with the domain admin credentials

2. Using Active Directory users and computers, Create a new service account to configure ADFS federation server and set password never expires

Account name: svr-federation

3. Access DNS Manager and create a new ‘A’ record to point to the internal IP address of ADFS server.

4. Login to ADFS server Krishadfs.cloudapp.net with the domain credentials

5. ADFS server needs a Third Party CA Certificate. Since, we already have wild card certificate configured on the Exchange server, we will have to simply export it from the exchange server and import into the ADFS server

Export the wildcard certificate with the private key from the Exchange 2013 server and copy to the root (C:\) directory of the server krisadfs.cloudapp.net

6. Start the PowerShell on the server krisadfs.cloudap.net and execute the command given below. Type the certificate password which had been used to export the certificate. Given below is the command that imports the certificate into the local computer personal certificate folder

Certutil.exe –f –importpfx c:\checkwhatsin.pfx

7. Install Active Directory Federation Server is as simple as running a PowerShell command. Execute the below PowerShell cmdlet to install ADFS server

Add-WindowsFeature ad-federation-services

8. ADFS server need to be configured once is it installed. Start Server manager and click on the amber symbol -> click on ‘Run the AD FS management snap-in’ to configure it.

9. It will open a new ADFS Snap-in page. Click on “AD FS federation server configuration Wizard” to start the configuration wizard.

10. To create new federation service, select ‘Create a new Federation service’ on the welcome page and click on ‘Next’

11. Select ‘New Federation Server Farm’ on the Development type page and click on ‘Next’

12. At the Federation Service Name page, select the SSL certificate as ‘Checkwhatsin’ and provide the Federation service name as ‘sts.checkwhatsin.com’ and click on ‘Next’

13. Input the ADFS service account ‘checkwhatsin\svr-federation’ and password at ‘Specify service Account’ page and click on ‘Next’

14. Verify details at the summary page and click on ‘Next’ to start the installation

15. Wait for the installation to be completed and make sure that the entire component configuration is finished and click on ‘Close’ to finish the installation.

16. To validate the successful installation, click on the below link and make sure you get the page displayed below image on the Internet Explorer

https://sts.chekcwhatsin.com/FederationMetadata/2007-06/FederationMetadata.xml

With this we have created and configured ADFS server and it is ready to use.

Installation and configuration of ADFS proxy server

The AD FS 2.0 Proxy is a service that brokers a connection between external users and internal AD FS 2.0 server. It acts as a reverse proxy and typically resides in your organization’s perimeter network (aka DMZ). Since the Krisadfsproxy.cloudapp.net is not a domain joined computer, it does not know to resolve nodes at the internal network. We need to create a host entry to resolve internal ADFS server.

1. Login to Krisadfsproxy.cloupdapp.net using the local admin credentials

2. Create a manual host entry to connect to point to the AD FS server

Access the ‘Hosts’ file using the notepad from the path C:\Windows\System32\drivers\etc\. Add a new entry to point to the ADFS server IP address with domain name sts.checkwhatsin.com

.

3. ADFS Proxy server also needs a Third Party CA Certificate. Since, we already have wild card certificate on the Exchange server, we will just need to export it and configure on the ADFS server

Export the wildcard certificate with private key from the Exchange 2013 server and copy to the root (C:\) directory of the server krisadfs.cloudapp.net

4. Start the PowerShell on the server krisadfsproxy.cloudapp.net and execute the below command. Type the certificate password which was used to export the certificate. Shown below is the command that imports the certificate into the local computer personal certificate folder

c:\KrishnaCertutil.exe –f –importpfx c:\checkwhatsin.pfx

5. Configure the Imported certificate on the Internet Information Service (IIS) Manager

a. Start IIS from the control panel, select ‘Default Web Site’ and select ‘Bindings’ on the action pane

b. Click on ‘Add’ to add a new site binding. Make sure to select the type as “https” and “Checkwhatsin” for SSL certificate and click on “OK”.

c. Click on “Close” to finish the IIS configuration

6. Install ADFS proxy using the below PowerShell cmdlet

Add-WindowsFeature ADFS-Proxy

7. Post installation of ADFS Proxy, it needs to be configured. Start ‘Server Manager’ and click on the amber symbol and select ‘Run the AD FS Federation Server Proxy Configuration’

8. On the Welcome page of ‘AD FD Federation Server proxy configuration wizard’ click on ‘Next’

9. Specify Sts.checkwhatsin.com as the Federation Server name and click ‘Test Connection’ to get connection successful status. Click on ‘Next’ to continue

10. Input the ADFS service account credentials at the windows security credentials pop up and click on ‘OK’ to continue.

11. Verify the settings on the ‘Ready to Apply Page’ and click on ‘Next’ to start the configuration

12. Verify the ‘configuration results’ page with the successful completion status and click on ‘Close’

13. Since ADFS proxy server is the internet facing server and ADFS server is configured using STS.checkwhatsin.com as federation name. We need to create a CNAME record at DNS for STS.checkwhatsin.com to point it to ADFS proxy server ‘Krisadfsproxy.cloudapp.net’.

Below is the reference snap from Go Daddy DNS.

With this we have created and configured ADFS and ADFS Proxy server. We have also made all the necessary changes in configuration so as to deploy SSO.

In the next part of the article, we will be completing the configuration of SSO and Directory Sync between Office 365 and on-premises exchange server.

Office 365 Hybrid Configuring Using Windows Azure – Part 1

Office 365 Hybrid Configuring Using Windows Azure – Part 3

Office 365 Hybrid Configuring Using Windows Azure – Part 4

Office 365 Hybrid Configuring Using Windows Azure – Part 5

Office 365 Hybrid Configuring Using Windows Azure – Part 6

Office 365 Hybrid configuring using Windows Azure – Part 1

A hybrid deployment provides a wonderful experience for your Office 365 deployment. It enables users to have mailboxes in your on-premises Exchange Server environment and Office 365; find one another in the global address list (GAL); share calendar; send or receive; and reply to emails, regardless of the system your mailbox.

Simulating Office 365 with Hybrid configuration and testing can be a bit challenging, unlike an exchange 2013 lab, where you build a new virtual machine, install exchange 2013, configure it and play. Office 365 hybrid configuration has certain requirements like Office 365 account, certificates, public facing on-premises Exchange, ADFS, Public facing ADFS proxy server etc.

A majority of organizations is now looking for Hybrid solution for the interesting features it offers and has become a mandatory skill set for the Exchange administrator. Microsoft offers 30 days free Office 365 Enterprise E3 account and free 30 days Widows Azure trail with a $200 credit to create and configure virtual machines. In addition to the specified trial accounts, you also need the following listed particulars to start and build your own Office 365 – Exchange 2013 Hybrid lab environment using Windows Azure

1. Domain name: Register a domain name using ‘Go daddy’. We would need to own and manage a domain DNS. You can register a domain from any ISP. With Office 365 and Go daddy, some of the DNS registration has been made automated. In this lab, we will be using the domain name “CHECKWHATSIN.COM” which is registered using Go daddy.

2. Third Party SAN Certificate: A Third Party SAN certificate is required for Exchange server and Federation server. The certificate has to match the registered domain name. We can use SAN certificate with multiple SAN or a wildcard certificate. In this lab, we will be using wild card certificate with the name – *.Checkwhatsin.com

In this first part of the article series, you will perform the tasks given below:

I. Creating and configuring Exchange On-premises Serves at Windows Azure

II. Registering and configuring Office 365 trial account

Other part of the articles are be found below

Office 365 Hybrid Configuring Using Windows Azure – Part 2

Office 365 Hybrid Configuring Using Windows Azure – Part 3

Office 365 Hybrid Configuring Using Windows Azure – Part 4

Office 365 Hybrid Configuring Using Windows Azure – Part 5

Office 365 Hybrid Configuring Using Windows Azure – Part 6

Creating and configuring Exchange On-premises Serves at Windows Azure

1. Create a Windows Azure Trail account

2. Login to the Azure portal and create:

  • A new Affinity Group
  • A new Storage and link to the affinity group
  • A new virtual network 3. Create two “SMALL” VM’s for Domain Controller and Exchange 2013 server with base OS Windows 2012. Shown below is the screen shot of the lab with the server named Krisdc01.cloudapp.net and KrisExch01.cloudapp.net. These are the names used to connect from internet.4. Promote the new domain controller on server Krisdc01.cloudapp.net with the new domain name ‘CHECKWHATSIN.COM’ 5. Join the server KrisExch01.cloudapp.net to the domain ‘CHECKWHATSIN.COM’ 6. Install and configure new Exchange 2013 on the server KrisExch01.cloudapp.net7. Once the Domain Controller and Exchange is installed and configured, we need to configure DNS with MX and CName record.

    8. Login to Go daddy DNS manager for checkwhatsin.com

    9. Create a new MX record to point to KrishExch01.cloupdapp.net to allow users to send and receive email from internet

    10. Create a new CName for mail.checkwhatsin.com to point to KrisExch01.cloudapp.net. This is to allow users to connect to Outlook Web App (OWA) from internet.

    11. Create a new CName record for autodiscover.checkwhatsin.com to point to KrishExch01.cloudapp.net. This is to allow users Internet users to perform autodiscover for client configuration.

    12. Once the DNS is registered, we should be able perform the autodiscover and other test using Microsoft Remote Connectivity Analyzer below

    13. Create new 3 additional “SMALL” VM with Windows 2012 OS for Active Directory Federation Server (ADFS), Active Directory Federation Server Proxy (ADFS Proxy) and Directory Sync (DirSync) Server role. Below is the Windows Azure virtual machines with three additional VM – Krisadfs.cloupapp.net, KrisAdfsproxy.cloudapp.net and Krisdirsync.cloudapp.net

    Registering and configuring Office 365 trial account

    1. Connect to the below Office 365 URL to register for a new Office 365 Enterprise E3 account

    http://office.microsoft.com/en-in/business/compare-office-365-for-business-plans-FX102918419.aspx

    2. Provided all the necessary administrator account information

    3. Provide the account and the domain name to register. Verify your phone number by sending a txt message or call and click on “create an account”.

    4. Below is the first look of Office 365

    5. Click on the setup on the left ribbon and click on “Add domain”

    6. Click on Start Step 1 to specify the domain name and confirm the ownership

    7. Input the domain name as ‘Checkwhatsin.com and click on ‘Next’

    8. For auto DNS configuration, click on “Confirm Ownership”.

    9. It connects the Go daddy with the credentials

    10. Click on “Accept” to allow Office 365 to create the new TXT record for the domain ‘Checkwhatsin.com’ and to confirm the ownership.

    11. This completed the domain verification process and click “Finish” to return to the main screen

    12. We can verify again by clicking on the ‘setup’ on the left bar to see checkwhatsin.com is added and status is ‘domain verified’.

    13. We can also verify the TXT record entry created by Office 365 at the Go daddy DNS for the domain ‘Checkwhatsin.com’. Login to Checkwhatsin.com DNS manager to view the TXT entry for Office 365 validation.

    14. From the above point 12, we still have the setup to continue. Click on complete setup to get the below page and click on “Start Step 2”

    15. Select “I don’t want to add users right now” and click on Next

    16. Since we will be configuring ADFS and single sign-on (SSO), we need the hold the Step 3 and revisit this part at the Part 3 of the article.

    With this we have created and configured on-premises Exchange 2013 using windows Azure and also created the Office 365 trail account with the addition and configuration of new domain checkwahtsin.com.

    In the next part, we will be creating and configuring ADFS and ADFS proxy servers which is deployed with the name KrisADFS.cloudapp.net and Krisproxy.cloudapp.net

           Other part of the articles are be found below

Office 365 Hybrid Configuring Using Windows Azure – Part 2

Office 365 Hybrid Configuring Using Windows Azure – Part 3

Office 365 Hybrid Configuring Using Windows Azure – Part 4

Office 365 Hybrid Configuring Using Windows Azure – Part 5

Office 365 Hybrid Configuring Using Windows Azure – Part 6

CodeTwo Exchange Migration

CodeTwo Exchange Migration tool is one of the great products from CodeTwo, which allows us to migrate Exchange mailboxes from one version of Exchange to the other version of Exchange. It can be a direct migration from Exchange to Exchange or from the SBS to Exchange and can be used in exchange cross-forest scenario as well. It also supports to migrate from non-Microsoft products like Google apps or Gmail to Exchange servers. It is easier and faster to use; and safer to migrate exchange in the below supported scenario.

· Exchange 2003, 2007 to Exchange 2010 migration

· Exchange 2003, 2007 to Exchange 2013 migration

· Exchange 2010 to Exchange 2013 migration

· Google Apps to Exchange migration

I think the most interesting feature is the support for cross-forest migration. Cross-forest migration using traditional tool it more complex, tedious and can be extremely slow and time consuming.

In this article we will perform cross-forest migration using the CodeTwo Exchange Migration tool. Normally, organizations perform cross-forest migration when there is a merger or acquisition, a security reason or when leaving the old environment and when starting a fresh one, etc.

Our lab environment consists of two forest Green.com – Source forest and blue.com – Target forest, which allow users to migrate from source forest to target forest.

As part of the migration, we need to prepare our environment to perform the cross-forest migration. Given below are the configurations necessary between the two forests which help to perform the smooth migration.

1. Configure DNS resolution between green.com and blue.com

2. Configure Trust between the two forests, green.com and blue.com

3. Configure the mail flow between source to target using the send and receive connectors

4. At the green.com domain, change the accepted domain as an internal relay to make sure that emails continue to be received even after the migration of mailbox to blue domain.

5. Configure Free busy sharing between blue.com and green.com

6. Configure GAL Sync between blue.com and green.com

7. Install and Configure ADMT and password export server which will export the password to the target account after user account migration.

8. Migrate users AD account from source to Target forest using ADMT

9. Finally, enable the mailbox for all the migrated users at the target forest. This can be done using PowerShell or using Exchange management console.

 

We are almost done with the environment configuration. Next, install CodeTwo Exchange Migration tool on any machine on the source forest with the necessary prerequisites:

Given below are the step by step instruction to configure CodeTwo Exchange migration tool and migrate the users to the target forest.

1. Login the machine where Exchange migration tool is installed with the Domain admin account

2. Run “ Exchange Migration Administrator Panel” from the start menu

3. Source server connection wizard helps to connect to the source forest. Select the option “on-Premises” Exchange server and click on Next

4. Select the Exchange 2010 server from the green.com (source) forest and make sure to select the Administrator account which has necessary permission to enumerate mailboxes in the source forest and then click on “Next”

5. Select the necessary folder for migration and by default, most of the folder is selected except the junk folder. Keep the default settings and click on “Next”

6. “Email address rewriting” has to be checked when mailbox has to be migrated to the different forest, it rewrites the email address based on the target forest. Since the new forest has a different domain and its email address is different, these settings are mandatory.

7. Finally, verification checks the source server connection and validates administrator account for the necessary permission and group membership.

8. Target server connection helps to connect to the target forest servers.

9. I would prefer to connect manually using FQDN of the Target exchange 2010 server. Exchange Web service URL (EWS URL) gets auto filled based on the target exchange server name and click on “Next”. EWS URL is necessary to connect and access the mailbox during the migration.

10. Enter the User Principal Name (UPN) and password of the target forest administrator account at the Admin’s credentials, and click on “Next”

11. Final verification allows us to validate the target server connection, impersonation rights to access the migration mailboxes through PowerShell.

With this we are almost ready to start the migration. Identify the source mailbox which you want to migrate and associate it with the new target mailbox in the CodeTwo Exchange Migration Administration panel. Association can be done both manually and automatically. Manually, you can select the source mailbox from the list and then highlight target mailbox in the window. This process is painful, when you have larger number of users to migrate. Automatically, association can be done by selecting all the users and click on Automatch button on the Administration Panel’s ribbon. This automatically matches the all the users account from the source forest to the target forest and generate the report for the reference. Once the association is done, you can start the migration. By default, it can only migrate two mailboxes at a time and this count can be increased by modifying the settings at the administration panel.

I personally feel I like the tool and it helps me to perform migration tasks in a simpler, easier and more effective way than using the traditional migration tool. It has a simple GUI which helps the administrator to perform the operation much easier. Again, it supports various migration scenario and even perform the direct upgrade from Exchange 2003 to Exchange 2013. It voids any kind of caveats which occur during the migration and also avoids the complexity of two step migration. CodeTwo also has a great support team which can help us to address any queries, issue or problem whenever there is a situation

Download CodeTwo Exchange Migration

 

 

Product Review – Lepide Exchange Reporter Tool

Lepide Exchange Reporter Tool is the proactive tool for the Exchange administrator. It provides some good reports to monitor the exchange environment and proactively helps administrators to keep the environment healthy and secure. Let’s delve deep into understanding some of the greatest features it offers.

The trial version of Lepide Exchange Reporter tool can be downloaded from the Lepide Website, which supports all legacy versions right from Exchange 2000, Exchange 2003, Exchange 2007, Exchange 2010 and to the latest version of Exchange 2013. It is a simple installable tool which can be installed on any server or client OS with the mandatory requirements demanded of outlook and SQL server. The requirement of the Outlook and SQL server versions needed to suit Exchange environment can be found at the download link given above.

The Lepide Exchange Reporter Tool generates various reports and has been divided as follows:

· Dash View

· Report View

· Mailbox Folder

Let’s get into each of these reports in detail to understand what it is able to provide its Exchange Administrators.

DASH VIEW

The Dash View provides some quick summary view for the administrator to get the following information:

1. Top 5 senders by number of the messages.

2. Top 5 receivers by number of messages.

3. Information Store by EDB and STM Size.

4. Information Store by Mailbox store and Public folder size.

5. Top 5 mailboxes by size.

6. Top 5 OWA users by usage count.

Figure 1. Dash View

REPORT VIEW

The Report View provides detailed information about the exchange environments, which we may need to focus more here. This report view is further divided into three parts: Email flow, OWA Report and General Report.

Email Flow

The Email Flow report is generated from the message-tracking logs and archives all the history log information into the SQL database. The email flow information queries can be filtered on the basis of the required time stamp.

It has mail flow information based on the user, subject, receivers’ and senders’ messages from within and outside an organization. This information can be sorted based on their date and size. Shown below is a reference snap shot.

OWA Report

The OWA Report is one of the important components of Exchange since many of the remote clients can connect OWA through Web browser in order to access their emails. Since these OWA connections majorly come from the internet, it is important to closely monitor them. For instance, sometimes, cyber attaches can happen over OWA, which in turn can adversely affect a user’s access.

The OWA Reports includes information of heavy OWA users, clients and server computers sending high OWA request and download the maximum data.

General Report

The General Report has a lot of information, which is necessary for day-to-day activities and can also be used for upgrades or transitions. It generates many reports, such as:

Directory Reports

It has detailed information of every user’s mailbox, distribution group and other directory objects in the organization.

Message Delivery Reports

It has detail information on every message sent/received in an organization. It also keeps track on the time taken for the message delivered to the target recipient.

Mailbox Information Reports

It provides detail information about every mailbox in an organization. It has information on each and every mailbox’s permission, rules, folder size, item age graph, item size graph, attachment per mailbox, etc.

I found this part to be informative, and hence it is imperative for users to take note on this. Shown below is the reference snapshot.

Mailbox Traffic Reports

It has detailed information on the daily traffic, mailbox-traffic growth, traffic between users and other such useful data.

Shown below is a reference snapshot.

Outlook Web Access

Outlook Web Access has important information to perform the strategic decision on the usage. It has information on the hourly and daily usage and also has information based on every OWA user.

Public Folder Reports

Monitoring public folders is very important to keep them in control. Many organizations do not monitor public folders and these folders grow enormously over a period of time. Public folder reports provide vital information like growth graph, along with the size, content, permission and restriction of the public folder.

Server Traffic Reports

Server Traffic Reports help to understand an email sent from and received of every domain based on the count and also has the traffic comparison graph between the domains.

Given below is the reference screen shot.

Storage Reports

Storage Reports have the most important report to keep the storage growth under control. Generally after the initial build of an Exchange server, expansion of storage is not easy. Sometimes there can be limitation of expansion slots or companies may not have the budget for expansion. Sometimes database grow enormously over a period of time for various reasons. Storage reports helps to provide information on Mailbox size growth graph and Information store size growth graph. Monitoring these reports will help to predict the data growth to plan for the expansion. They also help in identifying abnormal mailbox growth.

Mailbox Folders

Mailbox folders are the last report on Lepide Exchange Reporter tool which help administrators to access public folders and content of various mailboxes. It allow administrators to review the details of every mailbox folder and generate a report in the easy understandable format. For instance, report can be filtered on the basis of its date; and exported in various standard formats like CSV, PDF, and DOC etc. These reports are great helpful when huge amount of data needs to be tracked and it’s generate the report with all the minute change in the exchange mailboxes. For example sometimes we may wanted to get the report of mailbox size and its growth or unused mailboxes.

Majority of the reports from this tool are generated from the SQL Server, which is installed along with this tool. This help to generate various history report, where logs are no longer available on the Exchange servers. It scans all the necessary logs from the Exchange servers on the regular basics or based on the schedule time and updates into the SQL servers. Logs Scan schedule can be configure to run “Full Scan” once and incremental scan for the next consecutive runs.

Various logs it scans from the Exchange servers are:

· Messaging Tracking logs

· IIS Logs

· Information Store

· Mailbox Information

In my opinion, Lepide Exchange Reporting tool (http://www.lepide.com/exchange-reporter/) is an excellent tool which can help administrators to keep the environment under control and help in generating various reports for the management, as and when required, without writing any complex scripts. This is a tool that needs to be configured once and schedule it to collect reports on a day-to-day basis in order to generate a customized report, whenever needed. The reports, thus generated, can also be used for sizing, when you are upgrading your Exchange environment to a higher or to the latest versions of Exchange.

Why Exchange Server backups are important

Most of the business communications are these days carried out through emails. Even in the organizations that have full-fledged enterprise level CRM system in place, many sales related communications takes place through emails, particularly in the initial phase. Many of the emails contain critical client related information as email attachments that can be required anytime in the contract phase. Hence, Exchange Server data protection should be of primary importance for all the Exchange Server administrators.

When it comes to Exchange Server data protection, there are different measures that you can take. All these measures can be broadly classified into two parts based on the approach: pre-emptive measures where you try to prevent the occurrence of a disaster situation that can put the data to risk; and reactive measures where you make provisions after a disaster has struck.

Here we will discuss how backups can be a used a very effective methods to deal with any unforeseen circumstances. Exchange Server backups can be used in any of the following situations:

To recover from disaster situation: If your Exchange environment experiences a hardware or software failure, Exchange Server backups can help you to restore to a point-in-time with zero loss of data.

Recover any accidently deleted item: If any User deletes an email item accidentally, it can be restored from the correct backup. With Exchange 2013, the recovery of accidentally deleted items is even faster with Recoverable Item folder and the Hold policy that can be applied to it.

Uphold Compliance: Compliance requirements require you to archive email data for extended period of time. Backup is an excellent way to archive email communication to satisfy compliance requirements.

With Exchange 2013, many such features have been decentralized and even end Users can archive, perform granular recovery and search across mailboxes.

Let’s see what all options are available to backup Exchange Server data:

Normal backup: Normal backup process backups the entire Exchange Server and directory in its entirety. The log files are also backed up. You can restore mailboxes from just a normal backup.

Creating a Copy: A Copy backup is similar to the normal backup without the incremental and differential context. It can be used to backup the entire Exchange Store without disturbing the state of any incremental or differential backups that might be going on.

Incremental: This type of back up only backups the components that have changed since last normal or incremental backup. To restore from an incremental backup, normal backup and all incremental backups created in between are required.

Differential: This kind of backup captures the changes that have occurred since last normal backup and the current state. To restore from this kind of backups, one normal backup the specific differential backup is required.

While recovering data from backups, you may require to setup a recovery server apart from the production Exchange Server; this causes additional cost for setting up an expensive recovery server. There are some third-party software that can restore data directly from backups, thus doing away the need of recovery server and save significant cost. Lepide Exchange Recovery Manager is a third-party application that can be tried in such situations.

PowerShell Bangalore User Group (PSBUG) monthly meeting

 

To register use below link :

https://www.eventbrite.com/e/powershell-bangalore-user-group-psbug-monthly-meeting-tickets-12220565039

Event Details

This is the invitation a monthly PSBUG meeting. In this meeting, we focus on System Center and Azure with PowerShell.

Agenda:

9AM – 9.30AM – Registrations

9.30AM – 9.45AM – Welcome Note

9.45AM – 10.30AM – Getting Started with Azure Automation, Ravikanth Chaganti

10.30AM – 11.15AM – Getting started with PowerShell for System Center Configuration Manager, Deepak Dhami

11.15AM – 11.30AM – Break

11.45AM – 12.30PM – Getting started with PowerShell for System Center Service Manager, Vinith Menon

12.30PM – 12.45PM – Open House and Closing Notes

Venue:

Hamilton Room,

4th Floor, Microsoft MTC,

Signature Building,

EGL, Domlur.

RSVP:

PowerShell to Customize RBAC Permission in Exchange 2013

RBAC is the new permission model in Exchange 2013. With RBAC, we don’t need to modify and manage access control lists (ACLs). It enables us to control at both broad and granular level, what administrator and end user can do. In Exchange 2013, RBAC now controls both the administrative tasks that can be performed and extent to which users can now administer their own mailbox and distribution groups.

Go through following link to understand more on the RBAC Permission in Exchange 2013

PowerShell to Customize RBAC Permission in Exchange 2013

Regards,

Krishna