Cloud Architectures – Storage in the Cloud

roadchimp clouds


Cloud technology is deployed across a wide variety of industries and applications. The term ‘Cloud’ itself has become so widely prevalent that we’ve devised additional terms in an effort to describe what type of cloud we’re talking about. What’s your flavor? Iaas, Paas or Saas? Or perhaps it’s Public, Private or Hybrid?

Regardless of the type of cloud you’re using or planning to implement, there’s no denying that storage is an essential component of every cloud architecture that simply cannot be overlooked. In this post, we will look into some of the most common usages of storage in the cloud and peel back the layers to discover exactly what makes them tick. Our goal is to come up with a yardstick to measure storage design.

Drivers towards Cloud Storage adoption

dropbox box_logo

What do Dropbox and Box Inc have in common? Both companies are less than 5 years old, offer services predominantly centered around cloud storage and file sharing and have been able to  attract significant amounts of capital from investors. In fact, Dropbox raised $250 million at a $4 billion dollar valuation from investors with  Box Inc raising another $125 million in mid 2012. It looks like Silicon Valley sees Cloud Storage services as a key piece in the future of cloud. So why is there such a tremendous interest around cloud storage? Consumers are drawn to a number of benefits of using cloud:

  • Redundancy: Large clouds incorporate redundancy at every level. Your data is stored in multiple copies on multiple hard drives on multiple servers in multiple data centers in multiple locations (you get the picture).
  • Geographical Diversity: With a global audience and a global demand for your content, we can place data physically closer to consumers by storing it at facilities in their country or region. This dramatically reduces round trip latency, a common complaint for dull Internet performance.
  • Performance: Storage solutions in the cloud are designed to scale dramatically upwards to support events that may see thousands or millions more consumers accessing content over a short period of time. Many services provide guarantees in the form of data throughput and transfer.
  • Security & Privacy:  Cloud storage solutions incorporate sophisticated data lifecycle management and security features that enable companies to fulfill their compliance requirements. More and more cloud providers are also providing services that are HIPAA compliant.†
  • Cost: As clouds get larger, the per unit costs of storage go down, primarily due to Economies of Scale. Many service providers choose to pass on these cost savings to consumers as lower prices.
  • Flexibility: The pay as you use model takes away concerns for capacity planning and wastage of resources due to cyclical variations in usage.

It should be noted that a Draft opinion paper released by the EU Data Protection Working Party while not explicitly discouraging Cloud adoption, recommended that Public Sector agencies perform a thorough risk analysis prior to migrating to the cloud. You can read the report here.

Storage Applications for the Cloud

We’ve listed some of the most common applications for cloud storage in this section:

  • Backup: The cloud is perceived to be a viable replacement for traditional backup solutions, boasting greater redundancy and opportunities for cost savings. The Cloud backup market is hotly contested in both the consumer and enterprise markets.
    • In the consumer market, cloud backup services like Dropbox, Microsoft SkyDrive and Google Drive offer a service that takes part of your local hard drive and syncs them up with the cloud. The trend for these pay for use services are on the rise, with Dropbox hosting data for in excess of 100 million users within four years of launching their service.
    • In the Enterprise Space, Gartner’s magic quadrant for enterprise backup solutions featured several pureplay Cloud backup providers including Asigra, Acronis and i365. Even leading providers such as CommVault and IBM have launched cloud-based backup solutions. Amazon’s recently launched Glacier service provides a cost-effective backup tier for around $0.01 per gigabyte per month.
      01 Gartner Magic Quadrant
  • File Sharing: File sharing services allow users to post files online and then share the files to users using a combination of Web links or Apps.  Services like Mediafire, Dropbox and Box offer a basic cloud backup solution that provides collaboration and link sharing features. On the other end of the spectrum, full-blown collaboration suites such as Microsoft’s Office 365 and Google Apps feature real-time document editing and annotation services.
  • Data Synchronization: (between devices): Data synchronization providers such as Apple’s iCloud as well as a host of applications including the productivity app Evernote allow users to keep files  photos and even music synchronized across array of devices (Desktop, Phone, Tablet etc.) to automatically synchronize changes
  • Content Distribution: Cloud content distribution network (CDN) services are large networks of servers that are distributed across datacenters over the internet. At one point or another, we’ve used CDNs such as Akamai to enhance our Web browsing experience. Cloud providers such as the Microsoft Windows Azure Content Distribution Network (CDN) and the Amazon CDN offer affordable CDN services for serving static files and images to even streaming media to global audience.
  • Enterprise Content Management Companies are gradually turning to the cloud to manage Organizational compliance requirements such as eDiscovery and Search. Vendors such as HP Autonomy and EMC provide services that feature secure encryption and de-duplication of data assets as well as data lifecycle management.
  • Cloud Application Storage: The trend towards hosting applications in the cloud is driving innovations in how  we consume and utilize storage. Leading the fray are large cloud services providers such as Amazon and Microsoft who have developed cloud storage services to meet specific applications needs.
    • Application Storage Services: Products like Amazon Simple Storage Service (S3) and Microsoft Windows Azure Storage Account support storage in a variety of formats (blob, queue and table data) and scaling to very large sizes (Up to 100TB volumes).  Storage services are redundant (at least 3 copies of each bit stored) and can be accessed directly via HTTP, XML or a number of other supported protocols. Storage services also support encryption on disk.
      02 Azure storage
    • Performance Enhanced Storage: Performance enhanced storage emulates storage running on a SAN and products like Amazon Elastic Block Storage provide persistent, block-level network attached storage that can be attached to virtual machines running and in cases VMs can even boot directly from these hosts. Users can allocate performance to these volumes in terms of IOPs.
    • Data Analytics Support: Innovative distributed file systems that support super-fast processing of data have been adapted to the cloud. For example, the Hadoop Distributed File System (HDFS) manages and replicates large blocks of data across a network of computing nodes, to facilitate the parallel processing of Big Data. The Cloud is uniquely positioned to serve this process, with the ability to provision thousands of nodes, perform compute processes on each node and then tear down the nodes rapidly, thus saving huge amounts of resources. Read how the NASA Mars Rover project used Hadoop on Amazon’s AWS cloud here.

Storage Architecture Basics

03 Generic Storage Architecture

So how do these cloud based services run? If we were to peek under the hood, we would see a basic architecture that is pretty similar to the diagram above. All storage architectures comprise of a number of layers that work together to provide users with a seamless storage service. The different layers of a cloud architecture are listed below:

  • Front End: This layer is exposed to end users and typically exposes APIs that allow access to the storage. A number of protocols are constantly being introduced to increase the supportability of cloud systems and include Web Service Front-ends using REST principles, file-based front ends and even iSCSI support. So for example, a user can use an App running on their desktop to perform basic functions such as  creating folders,  uploading and modifying files, as well as defining permissions and share data with other users. Examples of Access methods and sample providers are listed below:
    • REST APIs: REST or Representational State Transfer is a stateless Web Architecture model that is built upon communications between clients and servers. Microsoft Windows Azure storage and Amazon Web Services Simple Storage Service (S3)
    • File-based Protocols: Protocols such as NFS and CIFS are supported by vendors like Nirvanix, Cleversafe and Zetta*.
  • Middleware: The middleware or Storage Logic layer supports a number of functions including data deduplication and reduction; as well as the placement and replication of data across geographical regions.
  • Back End: The back end layer is where the actual physical hardware is implemented and we refer to read and write instructions in the Hardware Abstraction Layer.
  • Additional Layers: Depending on the purpose of the technology, there may be a number of additional layers
    • Management Layer: This may supporting scripting and reporting capabilities to enhance automation and provisioning of storage.
    • Backup Layer: The cloud back end layer can be exposed directly to API calls from Snapshot and Backup services. For example Amazon’s Elastic Block Store (EBS) service supports a incremental snapshot feature.
    • DR (Virtualization) Layer: DR service providers can attach storage to a Virtual hypervisor, enabling cloud storage data to be accessed by Virtual Hosts that are activated in a DR scenario. For example the i365 cloud storage service automates the process of converting backups of server snapshots into a virtual DR environment in minutes.


This brief post provided a simple snapshot of cloud storage, it’s various uses as well as a number of common applications for storage in the cloud. If you’d like to read more, please visit some of the links provided below.

Roadchimp, signing out! Ook!


* Research Paper on Cloud Storage Architectures here.
Read a Techcrunch article on the growth of Dropbox here.
Informationweek Article on Online Backup vs. Cloud Backup here.
Read more about IBM Cloud backup solutions here.
Read about Commvault Simpana cloud backup solutions.

Cloud Architectures: Session Handling


Deploying applications to the cloud, requires a critical re-think of how applications should be architected and designed to take advantage of the bounty that the cloud has to offer. In many cases, this requires a paradigm shift in how we design the components of our applications to interact with each other. In this post, we shall explore how web applications typically manage session state and how cloud services can be leveraged to provide greater scalability.

Web Application Tiers

It is a common practice to design and deploy Scalable Web Applications in a 3-tiered configuration, namely as follows:

1. Web Tier: This tier consists of anywhere from a single to a large number of identically configured web servers that are primarily responsible for authenticating and managing requests from users as well as coordinating requests to subsequent tiers in the web architecture. Cloud-enabled Web Servers commonly utilize the HTTP protocol and the SOAP or REST styles to facilitate communication with the Service Tier.

2. Service Tier: This tier is responsible for managing business logic and business processing. The Service Tier comprises of a number of identical stateless nodes that host services that are responsible for performing a specific set of routines or processes.

3. Data Tier: The data tier hosts business data across a number of structured or unstructured formats and most cloud providers commonly host a variety of storage formats, including Relational Databases, NoSQL and simple File Storage, commonly known as BLOBS (Binary Large OBjects).

4. Load Balancing (Optional): An optional tier of load balancers can be deployed on the perimeter of the  Web Services tier to load balance requests from users and distribute load among servers in the Web Tier.

Managing Session State

Any web application that serves users in a unique way needs an efficient and secure method of keeping track of each user’s requests during active session.  For example, an e-commerce shopping site that provides each user with a unique shopping cart needs to be able to track the individual items in each user’s shopping cart for the duration of their active web session. More importantly, the web application that serves the user needs to be designed to be resilient to failures and potential loss of session data. In a Web Services architecture, there are a number of methods which can be employed to manage the session state of a user. We shall explore the most common methods below:

  • Web Tier Stateful (Sticky) Sessions: A web application can be designed such that the active Web Server node that a user get’s redirected to stores the session information locally and all future requests from the user are served by that node. This means that the Server Node becomes stateful in nature. Several disadvantages of this design are that the node serving the user becomes a single point of failure and also that any new nodes added to the collection of Web Servers can only share the load of subsequently established sessions since existing sessions continue to be maintained on existing nodes, thus severely limiting the scalability of this design and its ability to evenly distribute load
  • Web Tier Stateless Session Management: This design solves several limitations stated in the previous design by storing user session state externally, that can be referenced by any of the connected Web Server nodes. An efficient way to store small amounts of session data can be via a small cookie that stores a Session ID for the individual user. This Session ID can serve as a pointer for any inbound request between the user and the Web Application. Cloud Service Providers offer various types of storage to host Session State data, including NoSQL, Persistent Cloud Storage and Distributed Web Cache storage. For example, a web-tier request would be written to use AJAX to call REST services that would in turn pull JSON data relating to an individual user’s session state.
  • Service Tier Stateless Session Management: In most web architectures, the Service Tier is designed to be insulated from user requests. Instead, the Web Tier acts as a proxy or intermediary, allowing the Service Tier to be designed to be run in a trusted environment. Services running in this tier do not require state information and are completely stateless. Due to this statelessness, the service tier enjoys the benefits of the loose coupling of services, which allows individual services to be written in different forms of code such as Java, Python, C#, F# or Node.js based on the proficiency of the development teams and are still able to communicate with each other.


Stateless Session Management allows us to build scalable compute nodes within a Web Application Architecture that are easy to deploy and manage, and reduce single points of failure and take advantage of scalability and resiliency offered by Cloud Services providers to host session state data.

Cloud Architectures

Hiya, RoadChimp here!

I’ve spent a lot of time over the past few years working on building scalable computing systems and like many of you, lived through the proliferation of virtualization into mainstream technology infrastructure. In all these years of work around the globe across a variety of industries and scopes, I have not seen any other classification of technology that promises the same amount of technological advancement that Cloud  Platform Services provides. I strongly believe that the next few years in our industry will revolve mostly around building a new breed of services that rapidly make our lives easier and more efficient and that live and interact entirely in the cloud.

Therefore, I’ve decided to devote a section of this blog to Cloud Architectures and the paradigms that we must adopt in order to take advantage of this avalanche of new technologies.

Exchange 2013 in Azure Part 4 (Post-Install Configuration)

Okay, so now that we have completed the installation of Exchange 2013 in our environment, it looks like we have a couple more steps before we can actually get email flowing and our users logging in to check their email.


1. Verify that your installation completed successfully
Before you start configuring the features of Exchange 2013, it’s best to make sure that the installation completed successfully. In order to do so, it’s recommended to perform the following steps:

2. Restart the Server
A server reboot is required for your Exchange Server to properly register and startup all of it’s required services and dependencies. Some organizations configure policies explicitly preventing automatic reboots of servers. Please make sure that your server has rebooted after the installation.

3. Verify the correct build/version of Exchange is installed
From PowerShell, run the command: Get-ExchangeServer | Format-List. The output returned will indicate the version number of Exchange installed on the server as well as any installed patches. For more information of this command, click here. For the Preview release version of Exchange 2013, the build number is 15.0,516,32. Here’s a great link that shows all of the Build numbers for the different versions of Exchange Server.

4. Check logs for errors
View the application logs on the server under Event Viewer as well as the ExchangeSetup.log file in the C:ExchangeSetupLogs folder of the Exchange Server using any text editor. You can perform a search to match the strings “Error” or “Failed”. This will help you to identify any potential errors. Be sure to visit the Microsoft Technet Exchange 2013 forums here to seek help from the awesome online community. (‘I have done so many a time’, says Road Chimp)

The Exchange Administration Center

In Exchange 2013, you have the option of configuring Exchange 2013 via a GUI using the Exchange Administration Center (EAC) or via the Exchange Management Shell. The EAC is a new web-based management interface that is a vastly improved version of the Exchange Control Panel that debuted in Exchange 2010.

To get started with the EAC, you can first find out the URL of your EAC by typing the following command in PowerShell:

Get-EcpVirtualDirectory | fl *URL*

The EAC URL should look something like Note that the URL ends in ‘ECP’ which is probably a throwback to the ECP in Exchange 2010. You can launch the EAC from a browser. Don’t forget to login via a domain user account and password.

Configuration Steps

So now we’re ready to begin configuring our Exchange 2013 Server. In this section we will configure the following:

1. Create a Send Connector
2. Configure Receive Connector
3. Add additional accepted domains
4. Configure the default email address policy
5. Configure an SSL certificate
6. Configure External URLs
7. Configure DNS

Now, on to our first configuration task:

1. Create a Send Connector

A Send Connector allows you to provide Exchange with instructions on how to send emails outside of your organization. For example, you can define that emails  intended for a specific recipient domain can get routed to a specific endpoint server, or simply you can configure the Send Connector to use DNS to make routing decisions for you. To configure a Send Connector via the following steps:

Click on Mail flow > Send connectors.

On the Send connectors page, click AddAdd Icon, which launches the New Send Connector wizard.

I specified the name “Default Internet” for the send connector. You have four options to select and each selection determines the default permission sets that are assigned on the connector and grants those permissions to trusted security principals (users, computers, security groups etc.).

The options are:

  • Custom: Typically when you want to when you want route messages to computers not running Microsoft Exchange Server 2013. You can choose to route mail through smart hosts running SMTP. Microsoft recommends that if you use basic authentication, you use an encrypted connection because the username and password are sent in clear text.
  • Internal: Allows you to send intranet mail
  • Internet: Allows you to send internet mail
  • Partner: Routes mail to allow connections only to 3rd party servers that authenticate with TLS certificates.

For our lab demo, I selected Internet and then clicked Next.

In the next screen, ensure that “MX record associated with recipient domain” is select and click Next.

This indicates that the connector uses DNS to route mail. Your other option is to route mail through a smart host*, which could be a dedicated SMTP server or cloud-hosted service that your organization uses to send all out-bound email (and perhaps perform malware and virus scanning).

* The “Use the external DNS lookup settings on servers with transport roles” may be used if you have both external and internal DNS zone files for a domain you need to route mail to and you want emails to be routed via the internet. I left this option unchecked.

Under Address space, click Add+. Select SMTP in the Type field and enter * in the Fully Qualified Domain Name (FQDN) field, with a cost of 1. Click Save.

Note: The Scoped send connector checkbox indicates that this connector is scoped to a specific group of servers (a delivery group) and only this group is allowed to route messages to destination defined by the connector. This delivery group may contain Exchange 2010 Hub Transport servers or Exchange 2013 Mailbox servers located in different Active Directory sites. Ensure that the checkbox isn’t selected and then click Next.

Under Source server, click AddAdd Icon. In the Select a server window, select a Mailbox server that will be used to send mail to the Internet via the Client Access server. I’ve selected my mailbox server CHIMPLABEXMB01. After you’ve selected the server, click Add and then click OK. Now you can click Finish to complete the wizard.

– Optional: Configure the Mailbox Server to proxy outbound messages through a Client Access Server .  We can perform this task through the shell by typing in the command:

     Set-SendConnector “Default Internet ” –FrontendProxyEnabled

By setting this command, you’re effectively configuring the behavior of the Transport service on the Mailbox servers to route outbound mail through the Front End Transport service on the CAS servers in the local Active Directory site. This is NOT set by default and is a good practice to consolidate and simplify mail flow, especially in large environments.

Simply typing Set-SendConnector provides more information on how to set parameters on a Send connector. It’s useful to note that the default maximum message size, specified by the MaxMessageSize parameter, has been increased from 10MB to 25MB. Another parameter TlsCertificateName has been added. It is used to authenticate the local certificate to be used for outbound connections and minimize the risk of fraudulent certificates.

*Note on SMTP Relays
In the old days, many organizations used to expose their Exchange servers directly to the Internet. Nowadays, you would have either an SMTP mail appliance (Anti-Spam/ Malware) or Cloud subscription service that relays inbound emails to your CAS server. As there is no Edge Server support in Exchange 2013, you might want to hold on to your Exchange 2010 Edge Servers for now! Also, you will need to ensure that inbound SMTP is configured on your firewall to enable your SMTP edge devices to relay emails into your CAS servers.

– You can verify that this works by logging in to Outlook Web App ( with a valid user account and sending an email to an external recipient.

2. Configure Receive Connector

A receive connector listens for inbound connections that match the settings of a receive connector through a particular IP address and port and from a specified address range.  You can configure multiple receive connectors to control which servers receive messages from a particular IP address or IP address range. A receive connector can be created on a Mailbox Server running the Transport service or a Client Access Server running the Front End Transport service.

receive connectors are configured automatically after you install a Mailbox Server running the Transport Service in Exchange 2013. They are:

  • Default<server name> Accepts connections from Mailbox servers running the Transport service and from Edge servers.
  • Client Proxy <server name> Accepts connections from front-end servers. Typically, messages are sent to a front-end server over SMTP.

Three receive connectors are configured automatically after you install a Client Access Server running the Frontend Transport Service in Exchange 2013. They are:

  • Default FrontEnd <server name> Accepts connections from SMTP senders over port 25. This is the common messaging entry point into your organization.
  • Outbound Proxy Frontend <server name> Accepts messages from a Send Connector on a back-end server, with front-end proxy enabled.
  • Client Frontend <server name> Accepts secure connections, with Transport Layer Security (TLS) applied.

Each connector is assigned a TransportRole value. You can use it to determine the role the connector is running in. This can be helpful in cases where you are running multiple roles on a single server. In the case of each Receive connector running on a Mailbox Server, their TransportRole value is HubTransport. For each Receive connector running on a Client Access Server, their TransportRole value is FrontEndTransport. You can view this information by typing the Get-ReceiveConnector command.

3. Add additional accepted domains

By default, Exchange uses the domain name of the Active Directory Domain where the setup /PrepareAD command was run prior to installing Exchange. Your Organization may want to use a different email address to send and receive emails from. Perform the following steps to configure an accepted domain:

From EAC, click on Mail flow > Accepted domains. On the Accepted domains page, click AddAdd Icon. Specify a name for the accepted domain in the New accepted domain wizard. Now specify the SMTP recipient domain you want to add in the Accepted domain field. If this Exchange Server will be receiving all emails for the domain that you just added, select Authoritative domain and then click Save.

4. Configure the default email address policy

A couple of posts back, we explored the setup PrepareSchema command and how it extends the schema to provide support for mail-enabled objects in Active Directory.  The default email address policy enables you to setup rules to assign every recipient in your organization with a default email address based on the accepted domain that you configured previously. For example:

If you added an accepted domain in the previous step and you want that domain to be added to every recipient in the organization, you need to update the default email address policy. Perform the following steps in the EAC:

Go to Mail flow > Email address policies. On the Email address policies page, select Default Policy and then click EditEdit Icon.

Click Email Address Format on the Default Policy Email Address Policy page. Click the SMTP address you want to change and then click EditEdit IconUnder Email address format. Specify the SMTP recipient domain you want to apply to all recipients in the Exchange organization.

On the Email address format page in the Email address parameters field. (This domain must match the accepted domain you added in the previous step.) Click Save.

Click Save again and then click Apply in the Default Policy details pane.

You can verify that this works by selecting a mailbox in EAC (Recipients>Mailboxes) and verifying  that the User Mailbox field has been set to Alternatively, you can try creating a mailbox in EAC (Recipients>Mailboxes and Add+). You can now provide all the information required to create a new mailbox.

5. Configure an SSL certificate

Services such as Outlook Anywhere and ActiveSync require certificates to be configured on your Exchange 2013 server. The following steps show you how to configure an SSL certificate from a third-party certificate authority (CA):

– Go to Servers > Certificates. On the Certificates page, select the Client Access server in the Select server field, and then click AddAdd Icon
– This launches the New Exchange certificate wizard. Now select Create a request for a certificate from a certification authority and then click Next.
– Specify a name for this certificate then click Next.
– You can request a wildcard certificate by selecting Request a wild-card certificate and then specifying the root domain of all subdomains in the Root domain field. Alternatively, leave this page blank and click Next.
– Click Browse and specify an Exchange server to store the certificate on. You must select an Internet-facing Client Access server. Click Next.
– For each service in the list shown, specify the external or internal server names that users will use to connect to the Exchange server. For example, for Outlook Web App (when accessing over the Internet), you might specify For OWA (when accessing over the Intranet), you might specify These domains will be used to create the SSL certificate request. Click Next.
– Add any additional domains you want included on the SSL certificate. Click Next.
– Provide information about your organization. This information will be included with the SSL certificate. Click Next.
– Specify the network location where you want this certificate request to be saved. Click Finish.

After you’ve saved the certificate request, submit the request to your certificate authority (CA). This can be an internal CA or a third-party CA, depending on your organization. Clients that connect to the Client Access server must trust the CA that you use. After you receive the certificate from the CA, complete the following steps:

– On the Server > Certificates page in the EAC, select the certificate request you created in the previous steps.
– In the certificate request details pane, click Complete under Status.
– On the complete pending request page, specify the path to the SSL certificate file and then click OK.
– Select the new certificate you just added, and then click EditEdit Icon.
– On the certificate page, click Services.
– Select the services you want to assign to this certificate. At minimum, you should select SMTP and IIS. Click Save.
– If you receive the warning Overwrite the existing default SMTP certificate?, click OK.

To verify that you have successfully added a new certificate, do the following:
– In the EAC, go to Servers > Certificates.
– Select the new certificate and then, in the certificate details pane, verify that the following are true:
Status shows Valid
Assigned to services shows IIS and SMTP

6. Configure External URLs

Now that you’ve published the external domain names in a certificate and installed them into Exchange, you need to configure the external domains on the Client Access server’s virtual directories and then configure your domain name service (DNS) records.

The steps below configure the same external domain on the external URL of each virtual directory. To configure different external domains on one or more virtual directory external URLs, you will have to configure the external URLs manually. For more information, see Virtual Directory Management.

– Go to Servers > Servers and then click on the Wrench > Configure external access domain.
– Under Select the Client Access servers to use with the external URL, click AddAdd Icon
– Select the Client Access servers you want to configure and then click Add. After you’ve added all of the Client Access servers you want to configure, click OK.
– In Enter the domain name you will use with your external Client Access servers, type the external domain you want to apply, for example: Click Save.
– Go to Servers > Servers, select the name of the Internet-facing Client Access server (CHIMPLABEXCA01 in my case) and then click EditEdit Icon.
– Click Outlook Anywhere.
In the Specify the external hostname field, specify the externally accessible FQDN of the Client Access server. For example, You can also verify the internal FQDN that users will access the host from .Click Save.

7. Configure DNS

After you’ve configured the external URL on the Client Access server virtual directories, you need to configure DNS records for Autodiscover, Outlook Web App, and mail flow. The DNS records should point to the external IP address of your Internet-facing Client Access server and use the externally accessible FQDNs that you’ve configured on your Client Access server. The following are examples of recommended DNS records that you should create to enable mail flow and external client connectivity.

FQDN DNS record type Value MX A <external ip> A <external ip> A <external ip>

To verify that you have successfully configured the external URL on the Client Access server virtual directories, do the following:

– In the EAC, go to Servers > Virtual directories.
– In the Select server field, select the Internet-facing Client Access server.
– Select a virtual directory and then, in the virtual directory details pane, verify that the External URL field is populated with the correct FQDN and service as shown below:

Virtual directory External URL value
Autodiscover No external URL displayed

To verify that you have successfully configured DNS, do the following:

– Open a command prompt and run nslookup.exe.
– In nslookup, look up the A record of each FQDN you created. Verify that the IP address that’s returned for each FQDN is correct.
– In nslookup, type set type=mx and then look up the accepted domain you added in Step
– Verify that the value returned matches the FQDN of the Client Access server.


So in this post, we’ve gotten past all the configuration steps to get Exchange 2013 up and running. We’ve configured Send and Receive connectors, as well as accepted email address policies. We configured a SSL Certificate to support client access via ActiveSync and OutlookAnywhere. Finally, we configured external DNS settings to enable Exchange to receive emails from the rest of the world.

In the next post, we will peer behind the hood of Exchange 2013 and learn a bit more abou the Mail Routing and Mail Flow behavior of Exchange as well as Exchange’s new Storage Engine.

Road Chimp, signing out.

Exchange 2013 in Azure Part 3 (Installing Exchange 2013)

Okay, now that we’ve gotten past the Installation Prerequisites and we’ve run the setup /PrepareSchema; /PrepareAD and /PrepareDomain scripts and verified that our AD forest is ready for installation, we’re ready for the next step: Installing Exchange 2013.

Installing the First Exchange 2013 Server (Mailbox)
Okay, so I’ve decided to demo installing Exchange 2013 via both the Setup Wizard as well as via PowerShell. For the first Exchange Server in my Organization, I will use install the Mailbox Server Role via the setup wizard. If you want to see how Exchange 2013 is installed via PowerShell, please scroll down to the next section.

1. On my designated ‘first’ Exchange 2013 server in the Forest, I have installed all of the prerequisites and also downloaded the Exchange 2013 binaries and expanded them to a local folder.

2. To install the first Exchange 2013 server, your account must either be a member of the Enterprise Admins group. For subsequent installations of Exchange 2013, you can use an account that is the member of the Exchange 2013 Organization Management role group.

A quick word about the setup logs here before we begin our install process. These logs are invaluable in troubleshooting failed installations. It’s a great practice to take a look at the logs after performing an Exchange Server Installation in order to identify the status of your install. Simply perform a search for [WARNING] or [ERROR].

3. Run setup from a command line.

4. In the first screen, you are asked to check for updates.

5. On the next page, the install daemon begins copying files and initializes setup

6. You will now see the Introduction page, where you can read Release notes and learn more about Exchange 2013.  Click Next.

7. In the License Agreement page, don’t forget to read the EULA before clicking on the “I Acccept” button and then Next.

8. I chose to use the recommended settings for providing feedback to Microsoft.

9. Under Server Role Selection, I checked the “Mailbox Server” box and also left the “Automatically install Windows Server roles and features that are required to Install Exchange Server“. If you want to install a dual-role server, you can select both checkboxes under Exchange Server roles.

10. Under Installation Location, you get to select where your Exchange Server Binaries are installed. It’s a good idea to allocate Exchange Server to it’s own dedicated Volume (Not partition) to ensure that there is no hardware resource contention. In this case, I accepted the default location on my C drive.

11. I chose to disable Anti-Malware settings as I have an external Cloud service to do the work for me. If you would like to find out more about Malware Control in Exchange 2013, click here.

12. The installation wizard now begins some readiness checks and subsequently launches the installation process.

13. Once the installation process has completed, you will have to restart the server.

Installing the Exchange 2013 Client Access Server Role
For the next installation of a server role, I will be performing the installation via the setup unattended mode in PowerShell.

The code block for the setup file in Exchange has a considerable number of parameters. For our installation of our first CAS server role, we will use the following:

setup.exe /mode:install /roles:ClientAccess, ManagementTools /IAcceptExchangeServerLicenseTerms /InstallWindowsComponents /OrganizationName:SSCorp /TargetDir:”C:Program FilesMicrosoftExchange ServerV15″

More information on the Setup.exe parameters can be found here.

In this case, setup runs without prompting you for any further options. If there are any errors, Setup will fail and return an error message in the command prompt of PowerShell. You can also access the ExchangeSetup logfile in the C:ExchangeSetupLogs folder for more detailed debugging information.

Okay, so to recap for this post, we completed installing the Exchange 2013 Mailbox Server role via the Setup Wizard and also a CAS Server role via the unattended setup method.

We’re now ready to begin configuring Exchange 2013 to send and receive emails! For our next post, we will perform some post installation checks, followed by setting up Send and Receive Connectors, Default Email Policies as well as installing SSL certificates.

Don’t forget to leave a comment if you felt this was helpful. 🙂

Road Chimp, over and out.

Exchange 2013 in Azure: Part 2 (Preparing Active Directory)

In this part of the posting, we will prepare the Active Directory environment for Exchange 2013. Before you begin, make sure to read the posting in the previous section in order to take note of Exchange 2013 prerequisites.

Domain Considerations:
– If you are going to install Exchange Server 2013 on in a Forest that hosts multiple domains, Microsoft recommends that you perform the preparation steps in a Active Directory Site that hosts all of the domains. This will greatly facilitate replication across Domain boundaries. In several production sites that I’ve worked in, we deployed a number of virtualized child domain controllers in a physical hub network site to facilitate replication.

Installation Steps:

1. Extend the Active Directory Schema
The schema is an essential part of Active Directory, as it ensures that attributes for each class of objects in the forest are standardized and consistent, to prevent replication errors from happening. Before you can install Exchange 2013, you need to update the schema so that existing object classes (such as users) can now have email-enabled attributes and new object classes specific to Microsoft Exchange can be created.

To perform this task, you will need to:
– Log into a DC that has the schema master FSMO role†, with an Administrative account that has both Enterprise Admin and Schema Admin privileges.

  • †You can locate the Schema Master role by connecting to a Domain Controller and using the dcdiag /test:knowsofroleholders /v command. The identity of the schema master is listed as:
  • Role Schema Owner = CN=NTDS Settings,CN=XYZDC01, CN=Servers,CN=Default First-Site-Name,CN=Sites,CN=Configuration,DC=CorpXYZ,DC=com

There are a number of alternative ways to obtain the identity of the Schema Master and other FSMO role holders, check out this Knowledge Base article for more information.

– After logging in, ensure that you download the Microsoft Exchange Server installation file locally to the DC and extract the contents into a local folder.

– I’ve also fired up ADSI edit in order to review the Schema changes.

– From a command line prompt, navigate to the directory that you extracted the installation files to and type in the following command:

setup /IAcceptExchangeServerLicenseTerms /Prepareschema

This command will connect to the Schema Master and update the schema with Exchange 2013 Specific Attributes.

You can see this in action by viewing the Schema Partition in ADSI Edit and looking for attributes with the following prefix “CN=ms-Exch”. You can track the progress of the schema updates via ms-Exch-Schema-Version-Pt, which is a pointer that increments as each schema update is made. When the RangeUpper value gets to 15137, you will know that all of the schema updates have run smoothly. has a great posting on the schema versions corresponding to the different builds of Microsoft Exchange here.

Okay, now that we’ve completed updating our Schema, it might take a bit of time for replication to complete. There are a number of ways to verify that the Exchange 2013 schema updates have successfully replicated across the domain. One simple way is to check your replication event logs on destination DCs. Another way is to use the Repadm command line tool. Within the same domain, I like to use the command:

 Get-ADReplicationUpToDatenessVectorTable :domaincontrollername

You can validate replication consistency by comparing the UsnFilter attributes of the various domain controllers in the domain.

2. Prepare Active Directory for Exchange
The Active Directory Configuration Partition contains information about specific services (like Microsoft Exchange or Certificate Services) that Active Directory is aware of. We need to prepare the Active Directory Configuration partition to support Exchange 2013 servers by running the command:

     setup /IAcceptExchangeServerLicenseTerms/PrepareAD

The OrganizationName refers to the Instance name of your Microsoft Exchange Server installation. Note that you can only have one OrganizationName value per Active Directory Forest, so if you have an existing Exchange implementation in your AD forest, you would specify the OrganizationName of that implementation here.

In order to perform this task, you need to log on to a Domain Controller in the same domain as the Schema Master, and with Enterprise Admin group credentials. (As you will be making modifications to the Configuration partition of Active Directory which get replicated throughout the forest).

The PrepareAD process performs the following actions:

  • Creates the Microsoft Exchange Services container under  CN=Services,CN=Configuration,DC=<root domain>.
  • Creates the Exchange organization container with the OrganizationName parameter that you specify above, under CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=<root domain >
  • Validates the schema has been updated in CN=<your organization>,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=<domain> container to 15449.
  • Sets the msExchProductId of the Exchange organization object in the CN=<your organization>,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=<domain> container to 15.00.0516.032.
  • Creates the following containers which are required for Exchange Server 2013 to function in the Configuration Partition of Active Directory: Address Lists Container, AddressBook Mailbox Policies, Addressing, Administrative Groups, Auth Configuration, Client Access, Connections, ELC Folders Container, ELC Mailbox Policies, ExchangeAssistanceGlobal Settings, Hybrid Configuration, Mobile Mailbox Policies, Monitoring Settings, OWA Mailbox Policies, Provisioning Policy Container, RBAC, Recipient Policies, Remote Accounts Policies Container, Retention Policies Container, Retention Policy Tag Container, ServiceEndpoints, System Policies, Team Mailbox Provisioning Policies, Transport Settings, UM AutoAttendant, UM DialPlan, UM IPGateway, UM Mailbox Policies, Workload Management Settings.
  • Assigns extended rights for Exchange to install into Active Directory and creates the “Microsoft Exchange Security Groups” OU for each domain that you run this command in.
  • Creates a number of Management Role Groups into the “Microsoft Exchange Security Groups” OU and adds them to the otherWellKnownObjects attribute stored on the CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=<root domain>.
  • Creates the Unified Messaging Voice Originator contact in the Microsoft Exchange System Objects container of the root domain.
  • Prepares the local domain for Exchange 2013. For information about what tasks are completed to prepare a domain, see Step 3.

You can view the updates to the Configuration Partition by firing up ADSIEdit.msc and connecting to the Configuration Partition. (Rightclick > ADSI Edit > Select Connect to > Select a well known Naming Context > Configuration).

Note that the configuration partition of Active Directory is consistent throughout the entire Forest, so note that any changes you make may take time to replicate throughout the forest too.

3. Prepare Active Directory Domains
We now need to prepare the individual Active Directory domains that will be hosting Exchange 2013 servers by running the command:

     setup /PrepareDomain:<FQDN of Domain>
     setup /PrepareAllDomains

The former command prepares a single domain and requires Domain Admin credentials for the specified domain; while the latter command prepares all domains in your forest and requires Enterprise Admin credentials.

Either variant of the PrepareDomain command performs the following tasks:

  • Creates the Microsoft Exchange System Objects container in the root domain partition in Active Directory and sets permissions on this container for the Exchange Servers, Exchange Organization Administrators, and Authenticated Users groups. This container is used to store public folder proxy objects and Exchange-related system objects, such as the mailbox database’s mailbox.
  • Sets the objectVersion property in the Microsoft Exchange System Objects container under DC=<root domain>. This objectVersion property contains the version of domain preparation. The version for Exchange 2013 is 13236.
  • Creates a domain global group in the current domain called Exchange Install Domain Servers. The command places this group in the Microsoft Exchange System Objects container. It also adds the Exchange Install Domain Servers group to the Exchange Servers USG in the root domain.
  • Assigns permissions at the domain level for the Exchange Servers USG and the Organization Management USG.

Run the command from a command prompt and at completion you should see the following:

To verify that this command successfully worked, you should be able to verify the following:

  • A new global group in the Microsoft Exchange System Objects container called Exchange Install Domain Servers. (Don’t forget to click Advanced Features in the View menu in Active Directory User and computers first.)
  • The Exchange Install Domain Servers group is a member of the Exchange Servers USG in the root domain.
  • The Exchange Servers USG has permissions on the Domain Controller Security PolicyLocal PoliciesUser Rights AssignmentManage Auditing and Security Log policy.

So to summarize, we performed the following tasks so far:

1. Performed /setup PrepareSchema on the Schema Master DC to extend the AD Schema
2. Performed /setup PrepareAD to prepare the Configuration Partition
3. Performed /setup PrepareDomain to create specific Security Groups and assign permissions to these groups

As you can see, the preparation steps are fairly straightforward and also similar to installation steps for older versons of Microsoft Exchange. In the next post, we will install Exchange 2013.

Road Chimp, over and out.

Exchange 2013 in Azure: Part 1 (Installation Prerequisites)

*Note that as of this time, production deployments of Exchange 2013 on Windows Azure are NOT supported. This implementation is purely for evaluation and testing purposes.

Okay, so how do we go about installing Exchange 2013 in the cloud you might ask? Well the first thing to do is to consult the System Requirements and Installation Prerequisites for Exchange 2013. The full list of System Requirements can be found here on Microsoft Technet and the list of Installation Prerequisites can be found here. The Exchange 2013 preview help files can be found here.

I. Exchange 2013 – System Requirements

1. Older versions of Exchange:
Exchange 2003 and older: NOT SUPPORTED
Exchange 2007: Requires SP3* and update rollup* installed on ALL E2k7 servers in the organization.
Exchange 2010: Requires SP3* to be installed on ALL E2k10 servers in the organization.
Mixed Exchange 2007/2010: Prerequisites above should be installed for all servers.
* At the time of writing, neither Service Packs nor rollups were available for downlevel versions of Exchange, so I had limited ability to test interop capabilities of Exchange.
Hybrid Exchange: Exchange 2013 supports hybrid implementations of Exchange on-premise and on the cloud

2. Directory Service Requirements
Exchange 2013 requires an Active Directory Forest Functional mode of 2003 or higher. The following Operating System versions are supported by Exchange 2013 for the Active Directory server roles listed below:
-Schema Master (One Per Forest)
-Global Catalog Server (One per each site you plan to run Exchange 2013)
-Domain Controller  (One per each site you plan to run Exchange 2013)

  • Windows Server 2012 Standard or Datacenter/ Windows Server 2008 R2 Standard or Enterprise/ Windows Server 2008 R2 Datacenter RTM or later/ Windows Server 2008 Standard or Enterprise (32-bit or 64-bit)/ Windows Server 2008 Datacenter RTM or later/ Windows Server 2003 Standard Edition with Service Pack 2 (SP2) or later (32-bit or 64-bit)/ Windows Server 2003 Enterprise Edition with SP2 or later (32-bit or 64-bit)

Note on Exchange Server Placement on DCs: Microsoft does not recommend installing Exchange 2013 on a Domain Controller. Once Exchange is installed on a Domain Controller, the server cannot be demoted to a member server and vice versa.

3. IPv6 Support:
Exchange 2013 provides full support for IPV6, meaning to say that all servers can communicate with each other end-to-end in an Exchange 2013 environment via IPv6. Click here for more information.

4. Hardware Requirements:
CPU: x64/ AMD64 or Itanium64 platforms supported
Memory: Mailbox (8GB min) Client Access (4GB min) Mailbox/Client combined (8GB min) Page File size: Page file minimum and maximum should be set to Physical RAM plus 10MB Disk Space: 200MB of available disk space on the system drive. 30GB on the Drive that will host the Exhange binaries with an additional 500MB for each UM language pack. A message queue database with at least 500MB of free space. (NTFS formatting for the following: System Partition; Exchange Binary Files; Transaction Log Files; Database Files; other Exchange Files.) DVD Rom Drive. Supported Screen resolution of 1024×768 pixels.

5. Supported Operating Systems:
Exchange 2013 is supported only for full installations of Windows Server 2008 R2 and Windows Server 2012 editions. For a Windows Server 2012 Core server, you must run the following command to convert the server into a supported installation:

     Install-WindowsFeature Server-Gui-Mgmt-Infra, Server-Gui-Shell -Restart

For Mailbox and CAS Server roles, the supported Operating Systems are Windows Server 2012 Standard or Datacenter†; Windows Server 2008 R2 Standard with SP1; Windows Server 2008 R2 Enterprise with SP1; Windows Server 2008 R2 Datacenter RTM or later.

†The Database Availability Group (DAG) feature of Exchange 2013 requires that the Mailbox Server role be installed with a Windows Server 2012 Datacenter or Windows Server 2008 SP1 Enterprise edition OS.

6. Management Tools:
(Note that support is for 64-bit editions) Windows Server 2012 Standard or Datacenter; Windows Server 2008 R2 Standard with SP1; Windows Server 2008 R2 Enterprise with SP1; Windows Server 2008 R2 Datacenter RTM or later; 64-bit edition of Windows 8; 64-bit edition of Windows 7 with SP1

7. Client Versions:
Exchange 2012 supports the following versions of Microsoft Outlook: Outlook 2013; Outlook 2010 SP1 with April 2012 Cumulative Update ; Outlook 2007 SP3 with July 2012 Cumulative Update; Entourage 2008 for Mac, Web Services Edition; Outlook for Mac 2011

8. Server Hostnames:
While this might seem painfully obvious to some, the hostname of your Exchange Server cannot be changed once you install Exchange 2013. It’s a good design principle to finalize your naming conventions prior to implementing Exchange 2013.

9. Virtualization Support:
Please refer to the note on Virtualization for Exchange 2013 here.

10. Infrastructure Requirements
There’s some additional information that you ideally would want to hash out prior to commencing your Exchange 2013 installation.

  • Storage: How you plan to allocate storage (Spindles/IO) on your Exchange Servers
  • Connectivity: The number of Networks and VLANs to support Exchange (Client Access/Intra-Server/High-Availability/Backup & Management) to name a few.
  • IP Address allocations
  • Monitoring, Management and Backup: What devices, agents would need to be installed on the servers.
  • DNS Namespaces: DNS affects how clients access your services and also how Active Directory advertises these services to the rest of your network.
  • Security: Exchange 2013 relies very heavily on Web Services to support a number of features, including Exchange ActiveSync and Outlook Anywhere. You will need to obtain and register SSL certificates on your Exchange Servers.

II. Exchange Lab Configuration

Here’s a bit of information about my Lab environment prior to installation of Exchange 2013

1. VM Hosts:
All are running Windows Server 2012 Datacenter Edition virtual server instances on the Microsoft Azure cloud service.
chimplabdc01: Domain Controller (Forest Root + Global Catalog)
chimplabexmbx01: Exchange Mailbox Server Role
chimplabexmbx02: Exchange Mailbox Server Role
chimplabexcas01: Exchange Client Access Server Role
chimplabexcas02: Exchange Client Access Server Role

2. Domain Name:
I’ve configured chimplabdc01 as the first Domain Controller for the domain and joined my other VMs as member servers to this domain.  For more information on how to setup an Active Directory Forest in Windows Azure, please refer to the following article.

3. Active Directory prerequisites:
Microsoft Exchange 2013 requires that the functional level of your forest is at least Windows Server 2003. Click here to read more about verifying and raising your Domain and Forest functional levels.

Prior to installing Exchange 2013, we need to prepare the Active Directory Domain Services directory store (fancy word for the database) by running a couple of commands:

Forest Prep – Helps to extend the schema (user accounts now have email-enabled attributes such as a mailbox location) Schema changes propagate throughout your forest to all Domain Controllers, so be ware that this could set off replication traffic on your environment.

Domain Prep – Sets up special administrative groups and accounts, as well as assigns permissions to specific OUs. Take note that Domain Prep must be run once for each domain in your Active Directory Forest that you want to install Exchange 2013 in.

Windows Components – Each host that you run these commands on must have the following prerequisite components installed ahead of time:
– Microsoft .NET Framework 4.5††
– Windows Management Framework††
– Windows Remote Administration Pack
††FYI these components are already installed on Windows Server 2012.

You can install the Remote Administration Pack by launching PowerShell on your selected server and typing:

Windows Server 2012: Install-WindowsFeature RSAT-ADDS
Windows Server 2008: Add-WindowsFeature RSAT-ADDS

Don’t forget to reboot your computer once you’re done. You can type restart-computer from the command prompt.

4. Windows Server Components:

A. The Windows Mailbox Server role requires a number of Prerequisites to be installed. You can perform this task quite simply by launching powershell on the target server and pasting this code (Windows Server 2012):

Install-WindowsFeature AS-HTTP-Activation, Desktop-Experience, NET-Framework-45-Features, RPC-over-HTTP-proxy, RSAT-Clustering, RSAT-Clustering-CmdInterface, Web-Mgmt-Console, WAS-Process-Model, Web-Asp-Net45, Web-Basic-Auth, Web-Client-Auth, Web-Digest-Auth, Web-Dir-Browsing, Web-Dyn-Compression, Web-Http-Errors, Web-Http-Logging, Web-Http-Redirect, Web-Http-Tracing, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Lgcy-Mgmt-Console, Web-Metabase, Web-Mgmt-Console, Web-Mgmt-Service, Web-Net-Ext45, Web-Request-Monitor, Web-Server, Web-Stat-Compression, Web-Static-Content, Web-Windows-Auth, Web-WMI, Windows-Identity-Foundation

For corresponding code blocks for Windows Server 2008, please click here and scroll down to the heading “Windows Server 2008 SP1 Prerequisites” .

Once you’ve completed running these components, you will need to download and install the following:

– You need to uninstall the Visual C++ 2012 Redistributable (x64) – 11.0.50727 package on your computer as the Exchange 2013 Preview does not support it.

– For installations running Windows Server 2008 R2, you must also register ASP.NET with .NET Framework 4.5 in Internet Information Services (IIS).  This must be done after you’ve uninstalled Microsoft Visual C++ 2012 Beta Redistributable (x64)”, but before you run Exchange 2013 Preview Setup.

To register ASP.NET with .NET Framework 4.5 in IIS, do the following:

– Open a Windows Command Prompt.
– Run the following command: %SystemDrive%WindowsMicrosoft.NetFramework64v4.0.30319aspnet_regiis.exe-ir -enable
– Run IISReset from the shell to restart IIS services.

B. The Windows Client Access Server role requires a number of components as well. Copy and paste the following block of code into a PowerShell prompt on your target CAS servers (Windows Server 2012):

Install-WindowsFeature AS-HTTP-Activation, Desktop-Experience, NET-Framework-45-Features, RPC-over-HTTP-proxy, RSAT-Clustering, Web-Mgmt-Console, WAS-Process-Model, Web-Asp-Net45, Web-Basic-Auth, Web-Client-Auth, Web-Digest-Auth, Web-Dir-Browsing, Web-Dyn-Compression, Web-Http-Errors, Web-Http-Logging, Web-Http-Redirect, Web-Http-Tracing, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Lgcy-Mgmt-Console, Web-Metabase, Web-Mgmt-Console, Web-Mgmt-Service, Web-Net-Ext45, Web-Request-Monitor, Web-Server, Web-Stat-Compression, Web-Static-Content, Web-Windows-Auth, Web-WMI, Windows-Identity-Foundation

For corresponding code blocks for Windows Server 2008, please click here and scroll down to the heading “Windows Server 2008 SP1 Prerequisites” .

Once you’ve completed running these components, you will need to download and install the following:

– You need to uninstall the Visual C++ 2012 Redistributable (x64) – 11.0.50727 package on your computer as the Exchange 2013 Preview does not support it.

– For installations running Windows Server 2008 R2, you must also register ASP.NET with .NET Framework 4.5 in Internet Information Services (IIS).  This must be done after you’ve uninstalled Microsoft Visual C++ 2012 Beta Redistributable (x64)”, but before you run Exchange 2013 Preview Setup.

To register ASP.NET with .NET Framework 4.5 in IIS, do the following:

– Open a Windows Command Prompt.
– Run the following command: %SystemDrive%WindowsMicrosoft.NetFramework64v4.0.30319aspnet_regiis.exe-ir -enable
– Run IISReset from the shell to restart IIS services.

5. Configure Windows Firewall

A firewall rule must be manually added to allow Exchange to access the registry of the Windows 2012 Client Access server. Do the following:

  1. Open Control Panel > Windows Firewall.
  2. Click Advanced Settings.
  3. In Windows Firewall with Advanced Security, click Inbound Rules and then click New Rule.
  4. Select Port and then click Next.
  5. Select TCP, and in Specify local ports, type 139. Click Next.
  6. Select Allow the connection and then click Next.
  7. Make sure Domain, Private, and Public are selected and then click Next.
  8. Enter a name and description for the new rule and then click Finish.

Next Section
Okay, now that we’re done with the operating system prerequisites, let’s move on to Part 2 of this series: Preparing Active Directory for Exchange 2013

Road Chimp, over and out

Installing Exchange 2013 in Windows Azure

Following up on Justin Gao’s excellent post on installing Microsoft Exchange 2013, I’ve decided to post a few additional steps for those of you who want to get Exchange up and running in Microsoft Azure.

Install Sequence Overview:
Microsoft recommends a sequence for installing Exchange 2013 in the following article.
1. Configure all of the Exchange Server Prerequisites
2. Configure disjoint namespaces.
3. Install the Mailbox Server Role
4. Install the Client Access Server (CAS) Role
5. Configure Transport
6. Configure Email Address Policies
7. Install Digital Certificates on the CAS Server
8. Configure Virtual Directories
9. Configure Unified Messaging
10. Post Installation steps

This is a notable change to installation sequence from Exchange 2010 Server, when Microsoft recommended an install sequence of CAS, HUB and then MAIL servers.

I’ve decided to split my installs into a few separate posts:

Part 1: Prerequisites
This covers all the nitty gritty of getting the environment up and running:
– Installing Virtual Machine Instances (VMIs)
– Getting the VMs to communicate with each other
– Infrastructure requirements: DNS and Active Directory Domain Services
– Installation Prep for Exchange (Reviewing prerequisites)

Part 2: Active Directory Preparation
Exchange 2013 is an Active Directory – aware application and a number of configuration steps are required in order to prepare Active Directory prior to installing Exchange 2013. In this section, we cover:
– setup /PrepareSchema
– setup /PrepareAD
– setup /PrepareDomain

We also look at some techniques to verify that the installation has completed.

Part 3: Installing Exchange 2013
This part covers the installation of Microsoft Exchange 2013 Server
– Mailbox Server
– CAS Server
– Post-installation tasks
– Configuring basic Email Services and policies
– Testing communications

Part x: Advanced Configurations
I’m still contemplating what to post at this point, but I think that I will explore some of the following features:
– User Workload Policies
– Load Balancing/High Availability Features
– Simulating a database failure

If you haven’t done so already, feel free to go to Microsoft Azure’s site to sign up for a free trial account here. You will need a Microsoft Passport account as well as a Credit Card and reachable mobile phone number that can receive a text message. (Amazon’s AWS does the same thing here).

So get ready for an interesting ride!

Road Chimp, over and out.