Exchange 2013\2016 Server Role Requirements Calculator Explained – Part 2

We understood the various input options available in the Role requirement Calculator in part I. Exchange calculator uses the entire data from the input worksheet and performs the calculation based on the input data and updates details on the worksheet defined below. These worksheets are for review purpose only. Any change in the design has to be done in the input worksheet.

Let’s review the result worksheets and role requirements. We’ll provide examples via scenarios and a few visual aids too.

  • Role Requirements: Based on the input factor, the calculator will recommend the architecture and will break down the Role Requirement details into the below parts:
  • Environment Configuration: This configuration has detailed information of the number of CPU cores, Global Catalog, client access server, and the memory required to take up the load of the users for each site.
  • Active Database Copy Configuration: It has details of the number of HA copies in primary datacenter and secondary datacenter. It also has information on the total number of DBs /DAG and users / DB.
  • Server configuration: It has server hardware recommendations like RAM, CPU utilization and storage. It has detailed information of the number of database and mailboxes on each DB and IOPS required for each user on the database.
  • Log disk Space and IO Requirements: It has details of Disk space required for DB and logs for a complete environment. It also has the recommended IOPs /DB /Server for a complete environment.

Role Requirements:

  1. Activation Scenarios
  2. Distribution
  3. Volume Requirements
  4. Backup Requirements
  5. Log Replication Requirements
  6. Storage Design

1) Activation Scenarios: It has details of High availability and/or site resilience information, depending on the design inputs. Activation scenario has been defined for two scenarios

Scenario 1: DAG architecture with Active/Passive user within a single Datacenter or in site resilient model
Scenario 2: DAG architecture with Active/Active user in site resilient model

2) Distribution: This worksheet is an important worksheet, which has details of DB distribution layout. It helps us to determine the active copy distribution, when one or more server has failed or even in case of WAN failures within the environment. It also provides the PowerShell scripts to configure physical disk and mount points on the servers, create and configure DAG, create & configure active and passive database copies.
ESE_1
Active and Passive Database copy distribution

3) Volume Requirements: It has information on the volume architecture design for each server. Based on the input worksheet, it determines the volume design architecture with multiple DBs/volume or 1 Volume /DB or 2 volumes /DG etc. It also helps us to determine the DB size, log size with overhead and the required volume size. Microsoft recommends to keep DB and log at a same volume, if we have multiple HA copies of the DB.
ese_2png
Database Volume Requirement / server

4) Backup Requirements: It has details of the backup methodology and backup frequency defined for the organization.
ese_3
Backup Requirement configuration

5) Replication Requirements: This worksheet has information of the throughput required to replicate the transaction logs to each of the target database copies in the secondary datacenter. It calculates the peak log and content index replication throughput requirement. It also calculates the Recovery Point Objective (RPO) log and content index replication throughput requirement (it means how behind you could go in log shipping). Requirement: Higher the RPO- lesser bandwidth and lower the RPO- higher the bandwidth.

6) Storage Design: This worksheet helps you to determine the number of physical disks needed to support Database, transaction logs and restore volume configuration for each mailbox server ensuring that performance and capacity requirements are met within the design. Storage design recommends both RAID and JBOD storage solution. RAID storage Architecture recommends the required server, which has to be deployed in RAID and number of disks for each volume (database, log and resolute volume); for every mailbox server. JBOD storage architecture defines which server could be deployed in the JBOD storage architecture.

The Exchange 2013 server role requirement calculator is a comprehensive tool, which helps the Exchange administrator and architects provide a full proof architecture solution by meeting all best practices and recommendations from Microsoft. It is easy to understand, learn and design the solution quickly for the customers.

Until next time, Rob…

Exchange Server Role Requirements Calculator Explained – Part 1

Email1
The Exchange Server Role Requirement Calculator is your one stop calculation tool for Exchange 2013\2016 design. The tool covers design calculations for both the Mailbox and Client Access server role. Exchange 2013 reduced the number of roles from previous versions of Exchange by making the design and implementation as simple as possible and Exchange 2016 furthers that into a single role.  The Server Role Requirement Calculator helps us to size virtually and it provides in-depth sizing of every component of the hardware like CPU, Memory, Network, Storage, Backup, servers, datacenter etc.

Exchange Server Role Calculator is an excel spread sheet with an option to input your requirements.  The current version v7.8 of the calculator introduces support for Exchange 2016! Yes, that’s right, you don’t need a separate calculator, v7.8 and later supports Exchange 2013 or Exchange 2016 deployments.
When you open the calculator you will find a new drop-down option in the Input tab that allows you to select the deployment version. Simply choose 2013 or 2016:
calcdrop
When you choose 2016, you will notice the Server Multi-Role Configuration option is disabled due to the fact that Exchange 2016 no longer provides the Client Access Server role.

As discussed in the Exchange 2016 Architecture and Preferred Architecture articles, the volume format best practice recommendation for Exchange data volumes has changed in Exchange 2016 as they now recommend ReFS (with the integrity feature disabled). By default, for Exchange 2016 deployments, the calculator scripts will default to ReFS (Exchange 2013 deployments will default to NTFS).
Before we can properly size, we need to understand the below criteria and input to build our design:

Once we have determined all of the above, we should be ready to input those details into the input worksheet of Exchange Server Role Requirement Calculator. The Input worksheet is divided into 7 Parts:

1. Environmental configuration: This is where you input details of the AD architecture, Server roles, Vitalization, number of DAGs, number of nodes in the DAG, number of nodes in primary and DR datacenter. It also includes the number of DB copies in both primary and secondary datacenter with some transport message configurations like message queue expiration and safety net expiration.SRC1
Environmental Configuration

2. Mailbox Configuration: This is where you may need to input user profile details based on your existing profile and the projected mailbox growth percentage. There is an option to input different types of Tier profiles. The Existing user profile can be determined by using the Exchange profile analyzer scripts, mentioned above. Profile analyzer helps us to determine the messages sent & received per mailbox /day and average message size.

This part also has an important on IOPS and CPU Megacycles multiplication factor, which plays an important role for the users while designing mobile users & application users- as there is no clear information about the CPU and IOP’s requirement.
SRC2Mailbox Configuration

3. Backup Configuration: There is where we need to input the details of the required backup type, backup frequency and the log truncation tolerance days, in case of backup failure.
SRC3Backup Configuration

4. Storage configuration: Storage configuration is one of the most important factors during the design. This is where we input the type of disk you have for the Exchange database. Microsoft recommends an inexpensive SATA Just Bunch of Disk (JBOD) in the event there are three or more database copies. Exchange 2013\2016 also provides an option of multiple Database / volume, allowing for more than one database/volume on high disk capacity of 2-4 TB.
SRC4
Storage configuration

5. Processor Configuration: While this is considered “optional” to input factor, I would highly recommend you have the CPU cores determined with SPECint2006 Rate using the processor query tool and input under processor configuration for both primary and secondary datacenter mailbox servers.
SRC5Processor Configuration

6. Log Replication Configuration: This configuration is optional and it is only used if the database is replicated between physical locations. You just have to input the logs generated/ hour percentage, network bandwidth type, and available latency between the primary and secondary datacenter.
SRC6
Log Replication Configuration

7. Environment Customization: The Environmental Customization is actually optional. You’ll need to input the server names from both primary and secondary datacenter and DAG names, which will be used in the production environment. These names will be used for pictorial representation of the DAG, servers, and database. It is also used for DB creation scripts, which we will be discussing in the next part.

In this part we have covered all available input options in the Exchange Server Role Requirements Calculator. The Exchange calculator will use the imputed data and calculate the role requirement, storage design, network configuration, backup configuration, DAG configuration etc. for the organization and updates the results in the result worksheets.

Check out Part 2 – Exchange Server Role Requirements Calculator Explained

Until next time, Rob…

Understanding Windows Azure Pack – Reconfigure portal names, ports and deploy certificates – Part 6

happynewyear1 Windows Azure Pack
Happy New Year Everyone!!!  I know Azure Stack is just around the corner, but I still get lots of questions around configuring WAP and portals. So to follow-up my Windows Azure Pack (WAP) series, I am going to talk about reconfiguring server names and ports as well as assigning trusted certificates to my WAP Portals.

If you missed other parts of the series, check links below:
Part 1 – Understanding Windows Azure Pack
Part 2 – Understanding Windows Azure Pack – Deployment Scenarios
Part 3 – Understanding Windows Azure Pack – How to guide with Express Edition on Nutanix – Environment Prep
Part 4 – Deploying Service Provider Framework on Nutanix
Part 5 – Understanding Windows Azure Pack – How to guide with Express Edition on Nutanix – Windows Azure Pack Install

In this blog post, we will look at how you can change portal names and ports for the Tenant and Admin portals in WAP.

Once we are done with that, we are going to issue certificates from an Enterprise CA to the Admin portal as well as issuing a certificate to the Tenant Portal. As I don’t have a Public CA Certificate,  I’m going to use one from my Enterprise CA, but the concept for a Public CA is exactly the same as if I was using certificates from a trusted CA like VeriSign, DigiCert or similar.
wap-reconfig1 Windows Azure Pack
Windows Azure Pack Tenant Portal


Architecture:

Windows Azure Pack has different components which serve various functions as I mentioned in previous blog posts.
By looking at the roles being installed on a WAP Server for an express install, we can see a long list of Web Services running on the WAP Server. These different Web Services provide various roles within the WAP Infrastructure
In this lab scenario, we will be working with the following Web Services:

  • WAP Tenant Portal Service (MgmtSvc-TenantSite): Hosts the WAP Tenant Portal
  • WAP Tenant Authentication Service (MgmtSvc-AuthSite): Hosts the authentication for tenants
  • WAP Admin Portal Service (MgmtSvc-WindowsAdminSite): Hosts the Admin Portal
  • WAP Admin Authentication Service (MgmtSvc-WindowsAuthSite): Hosts the Admin Authentication

wap-config2 Windows Azure Pack

When a tenant accesses the WAP Tenant portal (exposed to the Internet) they will be redirected to the WAP Tenant Authentication Service to validate if the user is allowed to access the system, once the WAP Tenant Authentication service has validated the user, it will be redirected back to the WAP Tenant portal with access to WAP services. The tenant authentication service uses claim based authentication and can use different authentication methods like Active Directory Federation Services (ADFS) or .Net. In this scenario we are using default authentication (.Net), in the future blog post, I will tie in ADFS.

In the my lab setup these services are running on the same server (WAP01.contoso.com) as shown above..

A similar scenario happens when a WAP Administrator accesses the WAP Admin portal (only accessible on the internal network), the WAP admin portal will redirect the admin to the WAP Admin Authentication service which by default uses Windows Authentication. Once Windows Authentication service has authenticated the user, the user is redirected back to the WAP Admin portal with access to WAP.


Scenario:

After Installing and configuring Windows Azure Pack with the basic settings for the Contoso.com lab setup, the next steps are to configure the following:

  • Change WAP portal name.
  • Configure tenant and admin portals to run on port 443 (Https).
  • Replace the self-signed certificates with certificates provided by the enterprise CA (and consequently remove the warnings displayed in Internet Explorer due to the self-signed certificates).
  • Change the WAP Tenant Portal to use an internet facing url.
  • Change the WAP Tenant Authentication site to use the public web address that is also used by the WAP Tenant Portal.

The servers for this lab are configured as follows:

RoleNameFunction
Active DirectoryDC01.contoso.comActive Directory, ADFS, Certificate Server
Windows Azure PackWAP01.contoso.comWindows Azure Pack Express Install
Service Provider FoundationSPF01.contoso.comService Provider Foundation
SQL ServerDB02.contoso.comSQL Instance hosting the WAP databases
Virtual Machine ManagerVMM01.contoso.comVirtual Machine Manager 2012 R2 managing one Nutanix Hyper-V Cluster

The portals DNS names will be renamed to the following:

  • WAP Admin Portal: wapadmin.contoso.com port 443
  • WAP Tenant Portal Internal: WAPCloud.contoso.com port: 443
  • WAP Tenant Auth: wapcloud.contoso.com port: 444

Disclaimer: This environment is meant for testing only. This should not be considered guidance for production use, as several decisions made in this blog post are not targeting a production environment.

Reconfigure portal names for Windows Azure Pack

As the two WAP Portals by default (in our lab setup) are installed with https://wap01.contoso.com:30081 for the Tenant Portal and https://WAP01.contoso.com: 30091 for the Admin Portal we want to change these to use more portal friendly names.

To accomplish this, we need to do the following:

  • Create a DNS record for the new portals.
  • Install and configure an enterprise CA.
  • Request certificates for WAP Web Services from the CA.
  • Change ports and assign certificates for WAP Services.
  • Update Windows Azure Pack with the new web service modifications.

Create a DNS record for the new portals

  1. Logon to the DNS server.
  2. Start DNS Manager
  3. Expand dc01 > Forward Lookup Zone > <Yourdomain> (e.g. contoso.com)
  4. Right click on <Yourdomain> and select New Host (A-Record)
  5. Provide the DNS name and the IP address of the WAP Admin Server (e.g. Name: wapadmin, IP: 192.168.1.40)
    wap-reconfig4 Windows Azure Pack
  6. Create the other DNS name for the remaining portal (e.g. wapcloud,) and provide the WAP01 IP address as all roles are installed on the same server in the lab setup.
  7. Verify that the DNS records shows in the list.
    5wap-reconfig4 Windows Azure Pack
  8. Close the DNS Manager.

Use trusted certificates for the Windows Azure Pack

In order to use CA signed certificates in our Lab environment we need to do the following:

  • Install a CA Server
  • Configure the CA Server
  • Request Web Server certificates from the CA Server
  • Change Web Sites to use certificate.

Install a CA Server

  1. Logon to the server that will be running the CA Server (e.g. DC01)
  2. Start Server Manager.
  3. Select Dashboard on the left.
  4. Click Add roles and features.
  5. Click next to: before you begin, Installation type and server selection.
  6. In Server Roles select Active Directory Certificate Services under Roles.
  7. Click next to features.
  8. Under Role Services Select the following: Certification Services, Certificate Enrolment Policy.., Certificate Enrolment Web, Certification Authority..
  9. Accept the add-ons and click next to Web Role Services.
  10. Click Install.
  11. Verify that the install finishes with success.

Configure CA Server

  1. On the CA Server start Server Manager as a user that is member of Enterprise Admins.
  2. Select AD CS on the left.
  3. A message will show in the main window:
    wap-reconfig6 Windows Azure Pack
  4. Click on More.
  5. In the server task details click on Configure Active Directory Cert.
  6. Select All Roles to configure except for Web Service and click Next.
  7. Select Enterprise CA.
  8. Select Root CA.
  9. Select Create a new private key and click next.
  10. Click next to cryptography.
  11. Click next to CA Name and keep default. wap-reconfig8 Windows Azure Pack
  12. Keep 5 years and click next
  13. Click next to Certificate Database
  14. Select Windows Integrated auth.. and click next
  15. Under Server Certificate Select Choose and assign a certificate for SSL later and click next
  16. Click Configure
  17. Click Close

Change WEB Sites to use Certificate

Issue Certificate for the WAP Admin Portal

  1. Logon to the WAP Server as an administrator (e.g. wap01.contoso.com)
  2. Open IIS Manager on the WAP Portal Server
  3. Select the IIS server under connections
  4. In the main window select server certificates under IIS
  5. In the right windows select create a domain certificate
  6. Specify the following:
  7. WAPAdmin FQDN under common name (e.g. wapadmin.contoso.com)
  8. Organization: Contoso
  9. Organ unit: NA
  10. City NA
  11. State NA
  12. Click Next
  13. Select a CA and provide the friendly name for the certificate (e.g. wapadmin.contoso.com) wap-reconfig9 Windows Azure Pack
  14. Click Finish
  15. Verify that the certificate shows in the list of certificate wap-reconfig10 Windows Azure PackWe now have a web certificate, which we can use for the WAP Admin Portal.
  16. Request two more certificate following the same procedure:
    1. WAP Authentication: wap01.contoso.com
    2. WAP Tenant Portal Internal: WAPCloud.contoso.com
  17. There should now be three certificates in the Web Server Certificate list from Contoso CA. wap-reconfig11 Windows Azure Pack

Change ports and certificates for the WAP Admin Portal

  1. Logon to the WAP server as Administrator (This assumes it’s an express install).
  2. Start ISS Manager.
  3. Expand IIS Server > Sites.
  4. Right click on MgmtSvc-AdminSite and select edit bindings.
  5. Select https 30091 and select edit.
  6. Change port to 443.
  7. Set hostname to wapadmin.contoso.com.
  8. Select the certificate from the drop down list which was created earlier from the CA. wap-reconfig12 Windows Azure Pack
  9. Click Ok.
  10. Restart the Web Site.
  11. Right click on MgmtSvc-WindowsAuthSite and select edit bindings.
  12. Select the certificate from the list wap01.contoso.com.
  13. Click Ok.

Change ports and certificates for the WAP Tenant Portals

The following steps needs to be done in order to change ports and certificates for the tenant portal.

  1. Logon to the WAP server as Administrator (This assumes it’s an express install).
  2. Start ISS Manager.
  3. Expand IIS Server > Sites.
  4. Right click on MgmtSvc-TenantSite and select edit bindings.
  5. Select https 30081 and select edit.
  6. Change port to 443.
  7. Set hostname to wapcloud.contoso.com.
  8. Select wapcloud.contoso.com in the drop down list for certificates
  9. Click Close
  10. Right click on MgmtSvc-AuthSite and select edit bindings
  11. Select https 30071 and select edit.
  12. Change port to 444.
  13. Select wapcloud.contoso.com in the drop down list for certificates.
  14. Restart the MgmtSvc-TenantSite Web Site from the action menu.
  15. Restart the MgmtSvc-AuthSite Web Site from the action menu.

Update Windows Azure Pack with the new settings

Updating the Windows Azure Admin Portal

The TechNet documentation can be found here: Reconfigure FQDNs and Ports in Windows Azure Pack
To update WAP with our modifications the following commands needs to be executed, where we will use the values used in the scenario.

  • Set-MgmtSvcFqdn: This command will update the FQDN names for the modified services in the WAP Database.
  • Set-MgmtSvcRelyingPartySettings: This command will set the relay location for the WAP authentication service (Tenant or Admin)
  • Set-MgmtSvcIdentityProviderSettings: This command will update the authentication service where redirects will be redirected once verified.
We will be using the following arguments while executing the commands:
WAP Database Server:  db02.contoso.com
WAP Database user:    sa
Admin Portal FQDN:    wapadmin.contoso.com
Admin Portal Port:    443
Admin Auth Service:   wap01.contoso.com:30072
To update the modification made to WAP Services in the WAP database do the following.

  1. Logon to the WAP Server as a WAP Administrator.
  2. Start a PowerShell window.
  3. Import the WAP PowerShell module:

    Import-Module -Name MgmtSvcConfig

  4. Update WAP Admin Portal with the updated FQDN settings by running the following command:

    Set-MgmtSvcFqdn -Namespace “AdminSite” -FullyQualifiedDomainName “wapadmin.contoso.com” -Port 443 -Server “db02”
    3wap-reconfig12 Windows Azure Pack

  5. To set the WAP authentication service FQDN for the admin portal run the following command.Set-MgmtSvcRelyingPartySettings –Target Admin –MetadataEndpoint ‘https://wap01.contoso.com:30072/FederationMetadata/2007-06/FederationMetadata.xml’ -ConnectionString “Data Source=db02.contoso.com;User ID=sa;Password=*******”
    wap-reconfig2 Windows Azure Pack
  6. To set the authentication service redirection location to the admin portal run the following command:Set-MgmtSvcIdentityProviderSettings –Target Windows –MetadataEndpoint ‘https://wapadmin.contoso.com/FederationMetadata/2007-06/FederationMetadata.xml’ -ConnectionString “Data Source=db02.contoso.com;User ID=sa;Password=********”
    wap-reconfig17 Windows Azure Pack

Updating the Windows Azure Tenant Portal

The following attributes are used for configuring the WAP Tenant Portal.
WAP Database Server: db02.contoso.com
WAP Database user: sa
Tenant Portal FQDN: wapcloud.contoso.com
Admin Portal Port: 443
Admin Auth Service: wapcloud.contoso.com:444
To update the tenant portal do the following:

  1. Logon to the WAP Server as an Administrator.
  2. Start PowerShell.
  3. Import the WAP PowerShell module:
    Import-Module -Name MgmtSvcConfig
  4. Update WAP Tenant Portal with the updated settings by running the following command:

Set-MgmtSvcFqdn -Namespace “TenantSite” -FullyQualifiedDomainName “wapcloud.contoso.com” -Port 443 -Server “db02”
wap-config1 Windows Azure Pack

5. Update WAP Tenant Auth Site with the updated settings by running the following command:

Set-MgmtSvcFqdn -Namespace “AuthSite” -FullyQualifiedDomainName “wapcloud.contoso.com” -Port 444 -Server “db02”
wap-config2 Windows Azure Pack

6. To set the WAP authentication service FQDN for the tenant portal run the following command.

Set-MgmtSvcRelyingPartySettings –Target Tenant –MetadataEndpoint ‘https://wapcloud.contoso.com:444/FederationMetadata/2007-06/FederationMetadata.xml’ -ConnectionString “Data Source=db02.contoso.com;User ID=sa;Password=********”
wap-config3 Windows Azure Pack

7. To set the authentication service redirection location to the admin portal run the following command.

Set-MgmtSvcIdentityProviderSettings –Target Membership –MetadataEndpoint ‘https://wapcloud.contoso.com/FederationMetadata/2007-06/FederationMetadata.xml’ -ConnectionString “Data Source=db02.contoso.com;User ID=sa;Password=********”wap-config4 Windows Azure Pack

Verify the WAP modification works.

Pre-requisite: As we don’t have a public certificate for my lab setup we are going to install the CA certificate on the computers in the Trusted Certificates store from where we will access the WAP Portals.

  1. Login to a computer as a user that has WAP Admin Portal access.
  2. Start a browser.
  3. Type the URL that the WAP Admin Portal was changed to (E.g. https://wapadmin.contoso.com)

    Verify that the WAP Admin Portal loads using the new URL

wap-config5 Windows Azure Pack
Verify that the tenant portal works by opening a browser and go to https://wapcloud.contoso.com.
During the authentication sign-in process note the redirection to the wapcloud.contoso.com:444 authentication site.
wap-config6 Windows Azure Packwap-config7 Windows Azure Pack

Verify that after login the login redirects you back to the WAP Portal.

wap-config8 Windows Azure Pack

Summary

The goal with this blog post was to show how it’s possible to reconfigure portal names, ports and use certificates after deploying the Windows Azure Pack and I think I’ve done that.  But, as always, if you have any questions or comments, let me know…..

Until next time, Rob.