Office 365 Hybrid Configuring Using Windows Azure – Part 6

I tried to keep this article series as brief as possible and cover end-to-end configuration of Exchange and Office 365. This should give you a complete understanding to take the base on-premises exchange environment and integrate with the Office 365 in the hybrid mode.

This is the final and last part of this article series. We will continue with the discussion on the topics mentioned below.

I. Provisioning Office 365 mailbox from on-premises Exchange Admin center

II. Accessing provisioned mailbox using Single Sign On(SSO)

III. Migrating mailbox from on-premises to Office 365

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 4

Office 365 Hybrid Configuring Using Windows Azure – Part 5

Provisioning Office 365 mailbox from Exchange Admin Center

It is recommended to provision all the mailbox for both on-premises and Office 365 through On-premises Exchange Admin Center.

1. Login to on-Premises Exchange admin Center

2. Click on recipients -> mailboxes and click on ‘ + ‘ to select ‘Office 365 mailbox’

3. Provide all the necessary new user details and save to create the mailbox in Office 365

4. This will create an AD object at on-premises active directory and create the mailbox at Office 365. Given below is a reference snapshot of Exchange EAC with the new Office 365 mailbox.

5. The newly created object at on-premises has to be synced with Office 365. Scheduled synchronization happens every 3 hours. Follow the steps given below to force the directory synchronization immediately and allow users to login with the new accounts.

a. Login to the Dirsync server – Krisdirsync.cloudapp.net with the admin credentials

b. Access windows explore and navigate to the path “%programfiles%\Windows Azure Active Directory Sync”

c. Double-click on DirSyncConfigShell.psc1 to open a Windows PowerShell window with the cmdlets loaded.

d. In the Windows PowerShell window, type Start-OnlineCoexistenceSync, and then press ENTER

6. With force synchronization, we should be able to see the new account at Office 365 portal and given below is the reference screen shot.

These accounts need to be activated and assigned the license to allow users to login to their mailbox. Select the required ‘synced with Active Directory’ user and click on ‘Active Synced user’

7. Active the user by specifying the user location , assigning the required licenses and click on ‘Next’

8. The ‘Send result in email’ page is to send the mailbox creation with password detail to the authorized person. Since we have synced the objects from active directory, passwords are not reset for the users. Click on ‘Active’ to active the mailbox.

9. The ‘Results’ page has the mailbox activation confirmation with the message ‘The password wasn’t reset because its user’s password is synced with your on-premises’

Accessing provisioned mailbox using Single Sign on (SSO)

1. Login to the client machine and connect to the Office 365 portal via explore. Sign in with the new account rajesh.kumar@checkwhatsin.com and use the TAB key

2. Office 365 portal will check for ‘checkwhatsin.com’ SSO configuration and it will immediately redirect to the organization sign-in page

3. Input the domain\username and password and click on ‘Sign In’ to authenticate

4. The welcome page is ‘Get started with Office 365 page’, with all the necessary information to connect to Outlook, Outlook Web App, installing Office client software’s setting up the mobile device etc.

Click on ‘Outlook’ on the top ribbon to access the Outlook Web App

5. Shown below is the new and first look for users Outlook Web App

Migrating mailbox from on-premises to Office 365

The idea of having a hybrid environment is to have some or the majority of mailboxes in Office 365 and others in on-premises. Let understand how to migrate users from on-premises to Office 365 and understand as to how they continue to access their emails

1. Connect to the Exchange on-premises EAC with Organization admin credentials

2. The Mailbox Replication Proxy (MRSProxy) service is installed on every Microsoft Exchange Server Client Access server. MRSProxy helps to facilitate cross-forest move requests and it runs on the local Exchange Client Access server. However, MRSProxy is disabled by default.

3. To Enable MRS Proxy select Servers -> Virtual directories -> Double click on “EWS (Default Web Site)”

4. Select ‘Enable MRS Proxy endpoint’. This is the important configuration to allow cross forest migration of users from on-premises to Office 365.

5. Identify the user for the migration to Office 365 and click on “To Exchange Online” under ‘Move Mailbox’ to start the move mailbox wizard.

6. Confirm the migration endpoint with the Remote MRS Proxy server. Internet facing CAS server with MRS proxy enabled is Krisexch.cloudapp.net and the Internet alias name for the same is mail.checkwhatsin.com. Specific the ‘Remote MRS proxy server’ and click on ‘Next’

7. Specify the ‘New migration batch name’, ‘Target delivery domain’ name and other necessary details. In our case, Target delivery domain is ‘checkwhatsin.mail.onmicrosoft.com’. Specify the same and click on ‘Next’

10. Specify the account to deliver the batch competition status report. Also select the preferred option to start and complete the batch. Click on ‘New’ to start the migration batch

11. Click on ‘Yes’ to go to the migration dashboard to see the status of the migration batch.

12. This will automatically redirect the page to Office 365 Migration page with details of the migration batch status as syncing.

Syncing: The migration batch has been started, and mailboxes in the migration batch are being actively migrated.

13. Once synchronization of the selected mailbox is completed, click on ‘Complete this migration batch’ to perform the final migration process.

14. Confirm with ‘Yes’ to start the process.

15. Wait for the completed status to make sure the mailbox is migrated from on-premises to office 365.

16. Once mailbox is migrated to Office 365, users should start to use the Office 365 portal to connect to Outlook Web App application. Users can still connects to on-premises OWA portal to connect to the Office 365 OWA

17. Once you login to on-premises OWA, it determines the location of the mailbox in Office 365 and specifies the Office 365 portal URL to access their mailbox.

18. Click on the link to open then the new Office 365 authenticate page. This URL can be saved in the favorites for the further usage. Enter the user email address and press the Tab key

19. Since, Federated SSO is configured for the domain checkwhatsin.com, it will redirect to the on-premises reverse proxy server for authentication

20. Once authenticated using on-premises credentials, it will redirect back to Office 365 OWA page

21. Accessing Office 365 OWA seems to be a bit completed with the redirection happening forth and back in the hybrid mode. It is not the same experience for outlook users and user can continue to access the same profile and OST without changing the profile configuration

22. Once the migration is completed, the user will lose connection and it prompts the user to restart outlook.

23. When outlook is started again, it will prompt for the basic authentication popup. Input the user UPN(username@checkwhatsin.com) and password then click on ‘OK’

24. This will allow outlook to communicate, authentic and connect office 365 for email access. Below snap has the details of outlook with ‘Connected to Exchange server’ status.

25. We can connect to ‘Outlook Connection Status’ to verify the Office 365 connection. We should be able to see the connection proxy server as outlook.office365.com, which are office 365 servers.

With this we have come the end of the article series. I suppose if you want to learn Office 365 and configure Hybrid, then this is one of the best and easiest ways to learn it. Hope you have got some sound understanding as to how to build and configure Office 365 hybrid environment using Windows Azure.

It was a great experience for me to work on this article series and hope it will help you greatly to deploy and configure Office 365 hybrid mode in the production environment.

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 4

Office 365 Hybrid Configuring Using Windows Azure – Part 5

Office 365 Hybrid Configuring Using Windows Azure – Part 5

We are almost done with the preparation of the environment to work in the hybrid mode. In this part, we will be performing the final configuration of enterprise on-premises Exchange servers and Office 365 to work in the hybrid mode.

Given below is a list of activities to be performed in this series:

I. On-premises hybrid configuration verification and tweaking

II. Office 365 hybrid configuration verification and tweaking

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 4

Office 365 Hybrid Configuring Using Windows Azure – Part 6

On-premises hybrid configuration verification and tweaking

Hybrid configuration has made the necessary configuration changes in the on-premises exchange organization and Office 365. Let us verify some of these configurations and also make necessary changes to suit the requirement.

1. Login go krisexch.green.com with the organization admin credential and connect to the Exchange admin center.

2. Click on Mail flow -> Email address policies. Hybrid configuration wizard updates the email address policy with the secondary email address as alias@checkwhatsin.mail.onmicrosoft.com. Hence forth every mailbox object created will also get the secondary email address stamped with the domain checkwhatsin.mail.onmicrosoft.com

3. Click on mail flow -> accepted domains. We should see that the new entry checkwhatsin.mail.onmicrosoft.com has added an accepted domain and it is marked ‘Authoritative’.

4. Authoritative accepted domain is to allow exchange organization to accept emails and deliver them within the exchange organization. This is not the desired configuration at on-premises for the domain checkwhatsin.mail.onmicrosoft.com. Since it is the authority’s domain at Office 365, change the checkwhatsin.mail.onmicrosoft.com as internal relay.

Internal Relay: If the target mailbox resides locally, then it will be delivered. If the target mailbox is in a remote organization, then it will use a send connector to route email to the remote office 365 domain.

5. Let us verify the connector to send an email to Office 365. The hybrid configuration creates a new “Outbound to Office 365” connector to route emails to the remote Office 365 domain.

To verify the same, click on mail flow -> send connectors.

6. Hybrid configuration does not make any configuration changes or additions to the receive connector to accept email from Office 365. Default <Servername> receive connector  will be used to accept email on port 25 from Office 365

7. Organization sharing settings allow everyone in the organization to share free/busy and calendar information between the federated exchange organizations.

Office 365 hybrid configuration verification and tweaking

Hybrid configuration has made some necessary configuration changes in the Office 365 to work with exchange on-premises organization. It allows the mail flow, free/busy and other calendar information between the organizations.

Let us verify some of the configuration and make the necessary changes, if required.

1. Connect to the ‘Office 365 Exchange admin center’ and click on ‘mail flow’ -> ‘accepted domains’.

2. Hybrid configuration adds the new authoritative accepted domain as checkwhatsin.com

3. Authoritative accepted domain is to allow exchange organization to accept emails and deliver them within the exchange organization. This is not the desired configuration for the domain checkwhatsin.com. Since, its authoritative domain is at on-premises domain.

In the Part 4 of the article series, we have changed checkwhatsin.com MX record to point to Office 365. If checkwhatsin.com is marked ‘Authoritative’, then only will it deliver to the target mailbox in Office 365. If it is not able to find the target mailbox in office 365, then it will send an NDR message to the sender

This is not the desired configuration since, all the mailbox for checkwhatsin.com is residing on on-premises. Hence, it has to be set to ‘Internal relay’. If the target mailbox is not found in Office 365 then, it will be routed to the on-premises exchange organization, via an outbound connector

4. Hybrid configuration also creates Inbound and outbound connects at Office 365 to send /receive email from premises exchange servers.

The Inbound connector is to accept email from on-premises Exchange Send connectors for the recipients with the email address @checkwhatsin.mail.onmicrosoft.com

The Outbound connects is to send emails to on-premises exchange receive connector for the recipients with the email address @checkwhatsin.com

5. Office 365 Inbound connector can be tweaked to accept emails only from the specific on-premises exchange server and domain

The snapshot shown below has the details with sender domain set to checkwhatsin.com and sender IP address set to the IPaddress Exchange 2013 server. (It’s a Krisexch01.cloupdapp.net windows Azure IP address)

6. With this configuration , we should be able to send and receive emails between office 365 and on-premises exchange organization

Email flow from cloud on non-Premises

Mail flow from on-premises to cloud.

Thus, we have completely prepared and configured on-premises and Office 365 to work on a hybrid mode.

In the next and final part of the article service, we shall be trying to understand how to make provision for a mailbox in the hybrid mode, and in that series, how to migrate the mailbox from on-premises to Office 365

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 4

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

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: